What is software localization?
Software localization is the process of adapting a software product — its user interface, error messages, onboarding, notifications, help content and store listings — so that it works naturally for users in another language and market. It covers desktop software, SaaS and web apps, mobile apps for iOS and Android, games, and the developer-facing resource files those products are built from.
Software localization differs from translating a document in three ways. The content is a set of keys (strings) rather than pages. It changes with every sprint rather than once. And it is consumed by a build rather than by a reader, so a broken placeholder or a mangled tag can crash an app or block a release. That is why a dedicated software localization platform manages strings, keys and file formats instead of documents.
Software vs. app vs. file-format localization
“Software localization” is the umbrella term. “App localization” usually means mobile apps on iOS and Android, with their own resource formats and app-store listings. “File-format localization” is the practical layer underneath both: translating XLIFF, JSON, PO, XML, YAML and string files without breaking their structure. This guide covers all three.
Where this fits in your localization stack
Software localization is one workload inside a broader localization program. If you are choosing the platform that runs it — translation management, CAT editor, translation memory, terminology and vendors — start with our localization platform and TMS guide, which this guide builds on. Here we focus on what is specific to software: strings, formats, developer workflows and release cadence.
Smartcat’s approach is to make the platform the system of record for product copy. Its product localization workflow uses a Product & Engineering Coworker that automates extraction, translation and publishing of product and app content and integrates with your CI/CD pipeline, while the localization project management software page shows how developers, managers and reviewers share one workspace with API and connector access for GitHub, Figma and more. The March 2023 release that introduced collaborative software localization projects explains why: UX writers and product managers can change copy themselves, without distracting developers.
Internationalization (i18n) basics
Internationalization — abbreviated i18n, for the 18 letters between the “i” and the “n” — is the engineering work that makes software ready to be localized. Localization (l10n) is the work of adapting it for each market. The difference matters: internationalization is a development task done once in the codebase, while localization is a repeating content task done for every language and every release. Smartcat’s starter guide to internationalization in software design breaks i18n into three areas — user interface design, data format and storage, and processes and tools — and explains how to find an internationalization champion inside your company.
An i18n checklist before you localize
Externalize every user-facing string
Move text out of the code into resource files — JSON or YAML for web apps, strings.xml for Android, .strings or String Catalogs for iOS, PO files for gettext-based projects. Give every string a stable key so translations survive refactoring.
Use placeholders and plural rules, not concatenation
“You have ” + n + “ files” cannot be translated correctly. Use named placeholders and plural-aware syntax such as ICU MessageFormat, which Smartcat supports natively or as raw strings in software localization projects.
Design for expansion and direction
German and Finnish run longer than English; Arabic and Hebrew run right to left. Avoid fixed-width buttons and test layouts early — ideally in the design file, before code (see Figma & UI localization).
Store and format data by locale
Use UTF-8 throughout, and format dates, numbers, currencies and addresses with locale-aware libraries rather than hard-coded patterns.
Internationalization is also an organizational problem. Zendesk’s localization team describes how it embeds localization in product and engineering in the Zendesk approach, also available as a recorded talk, and the panel on global-ready product strategy brings localization leaders together to discuss professional development and mentorship in the globalization industry.
How software localization works in Smartcat
Alongside regular document projects, Smartcat offers software localization projects that manage keys directly. Keys live in collections; a project can hold several collections; and Smartcat enforces unique keys within each one. The typical workflow, described in the developer documentation for software localization projects, looks like this:
Create a project and import keys
Create a software localization project, choose source and target languages, and import keys in JSON, YAML, iOS .strings, Android XML or LocJSON — manually, through the API or CLI, or automatically from a GitHub, GitLab or Bitbucket repository.
Add context and edit source copy
Add labels and context such as screenshots, and create or edit keys and source text directly in the CAT editor — including keys with all plural forms.
Translate with AI and review
The Software Localization Agent translates using your translation memory and glossaries; internal reviewers or specialists you hire through the application localization services marketplace approve the result.
Export or sync back to code
Developers export the subset of keys they need in the format of their choice, or let the Git integration push translations back automatically — when complete, or as soon as a chosen workflow stage is reached.
Smartcat calls this approach “the source of truth for your software copy”: product managers and UX writers own the words, developers consume them. For a business-level overview, see application localization, which pairs AI translation with expert reviewers and app-store content localization.
Mobile app localization for iOS and Android
App localization brings its own constraints: platform-specific resource formats, tight UI space, app-store listings and screenshots, and frequent releases. Smartcat’s mobile app localization workflow has four steps — create an account, connect your Android, iOS or Java app, translate with the Software Localization Agent and reviewers, and upload the translated content back to your app. The long-form guide mobile app localization: everything developers need to know covers strategy and process for both platforms.
iOS app localization
iOS apps keep their strings in .strings and .stringsdict files, and newer projects in Xcode String Catalogs (.xcstrings) — all three appear in Smartcat’s list of supported file formats. The Git integration for iOS automatically finds and pulls .strings files from your repository and pushes translated resource files back, either when they are complete or when a chosen workflow stage is reached — useful if you want machine-translated strings in the repo before human review finishes. The Xcode localization page covers key management and plurals, and the iOS translation plugin for Xcode and Git summarizes setup. For a step-by-step walkthrough, read how to localize iOS app content, which covers implementation, testing and debugging, launch and best practices.
Android app localization
Android apps store strings in res/values/strings.xml, with one values folder per locale. The Git and Android integration pulls XML string resources from your repository into Smartcat and pushes translated files back automatically, including partially complete translations if you run a hybrid machine and human workflow. The Android translation plugin connects via an SSH key registered on your Git server (or a Smartcat user added as a repository collaborator), lets you choose an AI-only or AI-plus-review workflow, and can schedule automatic syncs. Related pages cover Android localized strings, Android app localization services, Android app translation and the Android Studio localization plugin. The guide to Android app localization explains locales, tools, steps, success metrics and common challenges.
App store listings and product pages
Localization does not stop at the binary. Store titles, descriptions, keywords and screenshots decide whether users in a new market download the app at all. The product localization workflow includes app product page localization with localized screenshots, titles, descriptions and keywords, and the same AI-plus-review setup applies to application localization generally.
App localization in practice
Two customer stories show what this looks like for consumer apps: how the women’s health app Flo streamlined localization, where accurate medical terminology is essential, and how the team behind Simple: Intermittent Fasting App localized it into six languages and why a well-built team was key.
Localization file formats: XLIFF, JSON, PO, XML, YAML and more
Software rarely arrives as Word documents. It arrives as resource and interchange files whose keys, tags, placeholders and nesting must survive translation untouched. Smartcat’s help center lists every supported file format; for localization work that includes XLIFF 1.2 and 2.0, SDLXLIFF, MQXLIFF, PO/POT, Android XML, RESX, JSON, LocJSON, YAML, Apple .strings, .stringsdict and .xcstrings, Java .properties and Markdown. Each of the main formats below has a dedicated page explaining what is preserved.
| Format | Typically used for | What Smartcat preserves |
|---|---|---|
| XLIFF 1.2 / 2.0, SDLXLIFF | Exchange between CMSs, authoring tools and CAT tools | Inline codes protected; translate="no" units locked; exports XLIFF 1.2 |
| JSON | Web and app locale files | Same keys and nesting; only string values translated; placeholders locked by regex rules |
| Gettext PO / POT | Open-source and server-side software (GNU gettext) | Variables such as %s and {name} become protected tags; developer comments shown as context |
| XML | Configs, content exports, Android resources | Markup, attributes and CDATA intact; translatable elements chosen by XPath |
| YAML, iOS .strings, Android XML | App and framework string resources | Imported and exported as keys in software localization projects |
| IDML | Adobe InDesign layouts (manuals, UI guides, packaging) | Text extracted from stories; translated IDML exported with formatting preserved |
XLIFF and SDLXLIFF
XLIFF (XML Localization Interchange File Format) is the standard way to move translatable content between systems. Smartcat’s XLIFF editor imports XLIFF 1.2 and 2.0, shows source and target side by side with inline codes protected, leaves translate="no" units locked, and exports XLIFF 1.2 — the flavor most tools import cleanly. Support for XLIFF 2.0 was announced in 2022; Smartcat detects the version automatically whether you upload manually or through the API. If you need a quick, browser-based option, see the free online XLIFF editor and the XLF translator; Trados users can bring .sdlxliff files to the SDLXLIFF translator, which applies translation memory, glossaries and human review.
To learn the format itself, start with what is an XLIFF file?, then read XLIFF for software localization, which explains when XLIFF makes sense for strings and how AI agents automate the workflow. eLearning teams exporting from authoring tools will find multi-language XLIFF for course translation and the help article on how to translate XLIFF files useful; the latter recommends XLIFF 1.2 for the cleanest round trip.
JSON
JSON is the default locale format for most web and JavaScript apps. The JSON translator parses your file, translates only string values, and returns a file with the same keys and nesting, with placeholder tokens locked as tags using regex rules you define once. Because strings keep their key IDs, translation memory can match on the key as well as the text. One en.json in, de.json, ja.json and pt-BR.json out.
For a single file, the free JSON translator is the same engine with a browser-first flow, available during the 15-day trial with 15,000 Smartwords and no credit card. Related pages cover translating JSON online, AI JSON file translation, the JSON translation file editor, the JSON localization platform for dev teams, the AI JSON translator for app localization, and a JSON-to-Excel workflow for teams whose reviewers prefer spreadsheets.
Gettext PO files
A PO (Portable Object) file is the plain-text format used by GNU gettext: each entry pairs a source string (msgid) with its translation (msgstr), so one PO file holds one language. Smartcat’s gettext PO file translation turns variables like %s and {name} into protected tags, shows developer comments to translators as context, and offers three parsers — Default PO, Serge.io PO and Monolingual PO. With the Serge.io parser, re-uploading a file only reprocesses strings whose source changed. The help article on translating PO files in Smartcat explains each parser and how to upload a .pot template.
XML and YAML
XML breaks in ordinary translators because markup, attributes and CDATA get treated as text. The XML translator uses a configurable parser: you specify by XPath, once, which elements and attributes hold translatable text, and everything outside those paths is left alone, so the file you download is well-formed XML your system can ingest. YAML configuration and locale files — common in Ruby on Rails, Symfony and many static-site generators — go through the YAML translator, which imports, edits and exports YAML inside the same software localization workflow.
InDesign and IDML
Software teams also ship printed and PDF material — quick-start guides, packaging, UI reference cards — usually built in Adobe InDesign. The IDML translator extracts text from the file’s stories and exports a translated IDML you open in InDesign for one layout pass. See also Adobe InDesign translation with AI, InDesign file localization and the InDesign translation service with expert reviewers. For Word, PowerPoint, Excel and other office formats, see the document translation guide.
Developer workflows: API, CLI and Git integrations
Manual file exchange does not scale past a handful of releases. Smartcat gives developers several ways to connect localization to their pipeline, from no-code connectors to a REST API.
Git-based localization
For most product teams, the Git integration is the fastest route to automation: Smartcat syncs source files from the repository, translates them, and pushes localized content back with no manual file handling. Mobile teams can use the platform-specific Git for Android and Git for iOS integrations covered above.
The Smartcat CLI
The Smartcat CLI lets you run localization steps from a terminal or CI job. After smartcat login, you can import and export key collections, upload and download files, and run pull and push synchronization steps; a .smartcat file in the working folder stores per-project settings. The developer guide to software localization projects shows the CLI and API side by side, including a Postman collection, file-path templates, adding target languages and plural support.
Translation APIs
When you need programmatic control — creating projects from your own system, sending content on publish, or getting instant machine translation inside a product — use the API. The API guides cover authentication, rate limits, documents, statistics, status tracking, export, callbacks and the real-time API; note that the API is available from company accounts, not freelancer accounts. The free translate API page explains how to evaluate the integration during the 15-day trial, documents a rate limit of 4 requests per second on every method, and lists the software localization formats the API adds (json, structured-json, yaml, structured-yaml, ios-strings and android-xml).
Language- and stack-specific pages show the same platform from different angles: a translate API for JavaScript, a translation API for PHP, a translation API for Gujarati and Urdu, and a translation API for CMS that detects new or updated content and pulls it for translation automatically. For websites, the language translation API for websites explains when an API is only the starting point — and the website translation guide covers web apps, CMSs and multilingual sites in depth. To see API-driven workflows from a language service provider’s side, watch the talk on API-driven translation workflows.
Connectors for the rest of the stack
Not every source of strings is a repository. The Jira translation plugin fetches documents attached to Jira tickets that match your criteria, translates them with your glossaries and memories, and pushes the files back to the original tickets; the Jira integration announcement notes it syncs every 15 minutes. Teams already using another string-management tool can connect it through the Lokalise integration, which syncs Lokalise projects into Smartcat via an API key and pushes translations back. Developer hubs and API docs built on ReadMe can be translated with the ReadMe translation plugin.
Continuous localization for agile teams
Continuous localization means translation runs alongside development instead of after it: new or changed strings are detected, translated and returned automatically, so every release ships in every language. The hardest part is usually process, not tooling. The localization project management software page explains how integrating localization into agile cycles lets teams release multilingual products simultaneously, with built-in automated checks and in-context review.
Three building blocks of continuous localization
(1) an automatic trigger — a Git sync, CLI step in CI or API call on every merge; (2) incremental processing, so only new or changed strings are translated (for example, the Serge.io PO parser reprocesses only changed source); and (3) automatic return of translations to the repo, ideally without blocking the build if review is still in progress.
Real-world examples show how teams got there:
Xsolla, a global video games distributor, set up continuous localization with Smartcat and the open-source Serge tool to keep pace with release cycles measured in weeks. Infobip, a global communications platform, ran a low-risk experiment to make localization work within its agile framework — and later presented how it redefined collaboration with vendors in the translation triangle talk. Kaspersky’s documentation and localization team, which writes and localizes UI texts and help articles for its mobile security apps, describes how it moved to a more reliable, agile and automated process. And Dataduck shows continuous localization is not only for software: a digital agency used the same approach for advertising material.
Figma and UI localization
Localizing at the design stage catches text expansion, truncated buttons and right-to-left problems before they reach code. Smartcat’s Figma translation plugin translates designs into 280+ languages while preserving layout and generates live previews, so reviewers can check translations in context in the Smartcat Editor without extra Figma seats.
For software teams, the important part is that Figma connects to the same software localization workflow as your code. The developer-friendly Figma integration (2023) lets you specify keys right in Figma, send them to a Smartcat software localization project for translation, and pull them back into your UI. In October 2026 the plugin added key management, variants and JSON export: every text object gets a renamable key, one element can hold several content states (empty, loading, error), duplicate keys are merged, conflicts are flagged, and the finished localization exports as a developer-ready JSON file.
The February 2024 update added the ability to exclude elements or frames (brand names, CTAs) from translation, multi-step workflows, support for Figma components and rich formatting. Setup and the Software Localization and Asset Translation modes are documented in the help guide to connecting Figma with Smartcat.
Localization testing and quality assurance
Translated strings are only half the job; the localized build has to work. Localization testing checks linguistic quality (accuracy, terminology, tone), visual quality (truncation, overlap, fonts, right-to-left layout) and functional quality (placeholders, plurals, date and number formats, sorting, input). The guide to localization testing walks through a step-by-step process, a three-step checklist and how to automate testing with Smartcat.
| Check | What goes wrong | How to catch it earlier |
|---|---|---|
| Placeholders & tags | Variables translated, moved or deleted; build fails | Format-aware parsers that lock placeholders as tags (JSON, PO, XML, XLIFF) |
| Plurals | Grammatically wrong counts in languages with several plural forms | Native plural keys or ICU MessageFormat in the editor |
| Text expansion | Truncated buttons and labels | Translate and preview in Figma before code; in-context review |
| Terminology | Product names and UI terms translated inconsistently | Glossaries and translation memory applied to every string |
| Context | Ambiguous short strings (“Open”, “Save”) translated wrongly | Screenshots, labels and developer comments attached to keys |
Human review remains the safety net for UI copy. Teams without in-house reviewers can hire specialists through the application localization services marketplace, which uses AI matching to find localization specialists for any language pair.
Software localization use cases, including games
The same building blocks — keys, formats, connectors and review — serve very different teams.
SaaS and product teams
SaaS companies localize UI strings every sprint, plus in-app messages, emails and help content. The product localization workflow, the software localization platform and localization project management pages describe how product, engineering and localization share one workspace. The Zendesk, Infobip and Kaspersky stories in this guide are all examples.
Mobile apps
Consumer apps localize strings, store listings and screenshots, often into many languages at once. Start with mobile app localization and the Flo and Simple case studies in the app localization section.
Game localization
Games combine every hard localization problem: large volumes of UI strings, dialogue and lore that need creative adaptation, character limits, and simultaneous launches. Two talks from Smartcat’s Localization Hub cover the practice: building a centralized localization team in video gaming, presented by the head of a major studio’s localization department, and trials and tribulations of translating in the game industry, a studio’s account of localizing an award-winning title. Game strings can be managed in the same software localization projects and Git workflows described above, and Xsolla’s continuous localization setup comes from the games industry.
Developer docs and eLearning
Developer portals built on ReadMe can be translated with the ReadMe plugin, while eLearning teams exporting XLIFF from authoring tools can follow the XLIFF guide for course creators. Websites and web apps that render content from a CMS are covered in the website translation guide.
Software localization tools & resources
Every Smartcat page for software, app and file-format localization, grouped by job.
Software & product localization
Mobile apps (iOS & Android)
XLIFF & bilingual formats
JSON, PO, XML & YAML
InDesign & IDML
APIs & integrations
Software localization guides, case studies & talks
In-depth guides, customer stories and recorded Localization Hub talks on software and app localization.
Help center and developer documentation
Step-by-step product and developer documentation for software localization in Smartcat.