Understanding software internationalization and localization
You might already know, separating text from code is a basic principle of internationalization (i18n), or making your app translation-friendly. In practice, this means that software developers need to store localization strings, such as UI labels and error messages, as variables in one or more separate files.
This way, the application can retrieve the strings from a single source and the translation can’t mess up the code. The resulting files are often called i18n files.
The actual translation of i18n files is called localization (l10n), since it also involves local adaptation of the user experience.
Choosing the right translation file format
i18n files can have multiple formats; JSON is one popular choice. But PO, CSV, YAML or Java .properties are other popular file formats. Here is a quick overview of the pros and cons of each file format:
Building a good workflow to translate software
One of the software localizations best practices in SaaS is to create separate i18n files for each target language version and find an intuitive directory structure and naming convention. This is an architectural challenge in and of itself.
For example, you could have all source files with UI strings in a separate folder and then add a subfolder called “i18n” with the localized files for each target language. Or you could store all texts in a single file.
Once that is set up, you need to get the original texts out of your code repository (e.g. GitHub) into a translation environment and then send back the translated texts. This gets especially tricky when you’re constantly pushing small, incremental changes.
The interplay between the various tools for creating content, version control systems and translation software is complex and usually requires some type of custom software in the middle.
>> Learn more about software localization
Why use a centralized, multilingual content management system?
To simplify your translation process, you can use an all-in-one authoring and localization tool such as Gridly. Gridly isn’t solely a content operations platform that lets you create, edit and maintain localization files in multiple formats, it also has the functionality of a TMS (translation management system), in case you need to actually translate these files.
Gridly can also work as a content platform to enable SaaS localization. You can choose whether to translate directly in Gridly or use an integration with pure-play translation software, such as Phrase or memoQ.
In other words, you can do all your authoring and translation in Gridly, or use it as a go-between.
Besides using Gridly’s interface or our file uploader to upload files directly to your grid, you can automate the connection between Gridly and any other system that features an API. If you’ve ever depended on an external vendor to build a custom integration, you might see the benefit. Using Gridly’s API allows you to automate your content operations and reduce file handling.
Gridly’s customizability is enhanced by Lambda functions. They let you add code in a wide range of programming languages to do basically anything with your content.
For example, you can set a trigger to automatically retranslate all target language cells and then add a Lambda function with an API call to any MT provider of your choice. Below you see how a workflow for this could look:
Figure 1
Besides using Lambda functions to leverage custom tools, you can use various integrated services, such as Google Translate, AWS translate or ChatGPT on your content without any need to code.
>> Explore how to leverage AI-assisted translation in Gridly
Comparing centralized translation content management to traditional methods
So broadly speaking, Gridly can be customized to cover all your content and translation needs. Let’s have a look at the following two diagrams and see how Gridly works:
In Figure 1, you see a mix of manual and automated processes in a traditional localization workflow. This may even require the customer to write their own middleware. They’ll never have all their content in one place and might need to buy licenses for different translation software providers, because one is specialized for software UI strings, while the other is for website and documentation content. They might even need to buy additional licenses for tools that offer advanced features, such as screenshot management and localization quality assurance (LQA), which are already included in Gridly.
Figure 2
In Figure 2, you see a localization process in Gridly. Regardless of where you produce or store text content, you can easily create your own integrations with Gridly or use what we offer out of the box. You then have the choice of whether to do the translation directly in Gridly or hook up an existing translation management system.
A tech stack for software development can include GitHub for hosting translation files, a custom CMS to maintain the documentation and a website CMS like Typo3 or Wordpress. You’ll work with various plugins that push authoring content and translatable strings to a translation environment and retrieve the translated content.
On top of that, you might have to translate multilingual support tickets in tools like Zendesk and team communication in Google Sheets or tools from the Microsoft Office suite, such as Excel or OneNote. The challenge with this content is that it’s not written for publication, so you don’t want to invest too much or spend a lot of time waiting for human translation. So machine translation is the natural choice. On the other hand, such texts are often written in a casual tone, therefore the quality of user-generated content translated with plugins for DeepL or Google Translate can vary significantly.
Gridly covers a wide user base and can be tailored to many content types. Thanks to customizable views, you can have all experts working in Gridly or let them use their tools of choice. You can narrow down the displayed data to what’s relevant for writers, translators, etc. or define your own user type.
Lambda functions mean you don’t have to rely on out-of-the-box integrations, but can easily connect to any system with an API, just by uploading your own scripts.
Frequently asked questions
What is a software localization workflow?
A software localization workflow is the end-to-end process of extracting translatable strings from a codebase, routing them through translation, and returning the approved translations to the application — continuously, as the product evolves. It spans the engineering work of internationalization (separating strings from code), the translation and review work of localization, and the operational infrastructure that connects those two sides: file format handling, version control integration, translator tooling, and quality assurance. For software teams shipping to multiple markets, the workflow is never a one-time project — it is an ongoing pipeline that runs in parallel with product development.
What is the difference between internationalization (i18n) and localization (l10n)?
Internationalization is the engineering preparation that makes a software product translatable: separating all user-facing text from the application code and storing it as variables in external resource files, supporting Unicode character encoding, building flexible UI layouts that accommodate text expansion, and handling locale-specific formatting for dates, numbers, and currencies programmatically. Localization is the subsequent process of actually adapting those externalized strings — and other product elements — for each target language and region. Internationalization is a prerequisite: without it, localization requires code changes for every language, which creates bottlenecks and technical debt that compound with every release.
Which translation file format should software teams use for i18n files?
The right format depends on the technology stack and workflow requirements. JSON is one of the most popular choices for web and mobile applications — it is lightweight, human-readable, and well-supported across frameworks. PO files (used with the GNU gettext system) are common in open-source projects and support translator comments and context annotations natively. YAML is often used in Ruby on Rails applications and is readable but can be sensitive to formatting errors. Java .properties files are standard for Java applications. CSV is broadly compatible and easy to open in spreadsheet tools, but lacks context support. XLIFF is the most metadata-rich option and is the format of choice when passing content to professional translation tools. The decision should account for developer familiarity, translator tooling compatibility, and the ability to carry context alongside source strings.
How do you extract strings from a code repository for translation and return them efficiently?
The standard approach is to export translatable strings from the repository — typically from i18n resource files stored in GitHub or another version control system — into a translation environment, and then import the completed translations back. In practice, this handoff is where most localization bottlenecks occur: it requires tooling to detect which strings are new or changed, format them correctly for the translation tool, and map the translated output back to the correct keys in the original file structure. For teams pushing frequent, incremental changes, manual file handling quickly becomes unmanageable. API-based integrations that automate this push-pull cycle — triggered by repository events — eliminate the manual overhead and keep translations synchronized with the current state of the codebase.
How should software development teams organize i18n files within their project?
A common pattern is to store all source-language i18n files in a dedicated folder within the project, then add a subfolder — often named “i18n” or “locales” — containing one file per target language, each following a consistent naming convention such as the BCP 47 language tag (e.g., en-US.json, fr-FR.json, de-DE.json). Another approach stores all translations in a single file organized by locale key. The most important principle is consistency: whatever structure is chosen should be documented and enforced across the team, because inconsistent file organization creates mapping errors when translations are imported and makes it harder to detect missing or outdated strings automatically. A clear directory structure also makes it straightforward to add new languages without restructuring the project.
Why is continuous localization particularly challenging for software teams?
Software products update constantly — new features ship, UI copy changes, error messages are revised — and each change potentially invalidates existing translations or creates new strings that need translating. In a batch-based workflow, these changes accumulate until someone manually exports the updated files, coordinates with translators, and re-imports the results. The gap between when a string is written and when it is translated grows with every release cycle. In teams shipping weekly or biweekly, this gap means localized versions consistently lag behind the source, and translators frequently receive context-free strings from features they have never seen. Continuous localization solves this by automating the detection and routing of changed content as it is committed, keeping translations in sync with development rather than running as a parallel catch-up process.
What is the best-of-breed versus best-of-suite trade-off in localization tooling?
The best-of-breed approach means purchasing multiple specialized tools — one for software string management, another for website and documentation content, another for screenshot management, another for LQA — each with deep feature sets tailored to their specific function. The trade-off is integration complexity: these tools must be connected through custom middleware or manual file handoffs, and maintaining those connections as each tool updates is an ongoing engineering cost. The best-of-suite approach consolidates content management, translation management, CAT tooling, and QA into a single platform — reducing integration overhead and keeping all content in one place, at the cost of some depth in specialized features. For most software teams, the operational cost of managing a fragmented tool stack — duplicate licenses, custom integrations, scattered content — outweighs the marginal feature advantage of best-of-breed tools in each category.
When should software localization use machine translation versus human translation?
The choice should be driven by content type, publication risk, and update frequency. Machine translation is a strong choice for high-volume, structured content — UI strings, error messages, system notifications, and internal documentation — where output is predictable and post-editing by a human reviewer is a realistic step in the workflow. It is also the natural choice for user-generated content, support tickets, and informal communications that need to be understood quickly but do not justify the cost of professional translation. Human translation remains important for customer-facing marketing copy, legally sensitive content, onboarding experiences, and any text where brand voice, cultural nuance, or precision matters enough to justify the additional cost and turnaround time. Most mature software localization workflows use both: machine translation as a first pass, human review and post-editing as a quality gate.
What role do Lambda functions play in a software localization workflow?
Lambda functions are small, custom code snippets that can be attached to automation triggers in a localization platform to extend its behavior beyond what is available out of the box. In a software localization context, they enable teams to connect to any MT provider via API — not just those natively integrated into the platform — trigger retranslation of specific string batches when source content changes, pipe content through a grammar checker or LLM-powered quality pass, notify stakeholders in external systems when specific events occur, or add custom push-and-pull logic to repository integrations. Lambda functions effectively remove the dependency on vendor-provided integrations for anything non-standard, allowing engineering teams to build exactly the workflow logic their product requires without writing a full custom middleware layer.
What content types beyond UI strings require attention in a software localization workflow?
Software products generate a broader range of multilingual content than UI strings alone. Help documentation and knowledge base articles require localization and must stay synchronized with product changes that alter the features they describe. In-app tooltips, onboarding flows, and empty-state messages are often written separately from core UI copy and can be overlooked. Push notifications and email templates have character constraints and tone requirements that differ from in-product text. Support ticket content — often user-generated and in mixed languages — may need machine translation for triage. Legal content such as terms of service, privacy policies, and cookie notices may require certified human translation and regional legal review. Each of these content types may require different translation approaches, different review processes, and different delivery mechanisms back into the product.
How does Gridly streamline software localization workflows?
Gridly functions as a centralized content and translation management platform that replaces the fragmented tool stack — separate content repositories, translation tools, and QA systems — with a single environment covering the full workflow. Teams can upload i18n files directly in JSON, PO, CSV, YAML, and other supported formats, or automate content ingestion from GitHub and other systems via API. Translation can be handled natively in Gridly’s CAT interface with translation memory, glossary enforcement, and automated QA checks, or routed to existing translation management systems such as Phrase or memoQ through integrations. Lambda functions extend automation to any API-connected system without custom middleware. Customizable views restrict what each team member sees to the content relevant to their role — developers, translators, and reviewers all work in the same platform without interface complexity. The result is fewer tools, less manual file handling, and a localization pipeline that runs continuously alongside software development rather than periodically catching up with it.
Fewer tools, less complexity
Navigating the world of software localization requires you to balance internationalization principles with efficient translation workflows, and find the right mix of machine translation and human translation.
Following sound localization practices, such as separating text from code and choosing the right translation file format can make your job a lot easier. With its customizable features and automation capabilities, Gridly lets you streamline workflows and customize your message for international users.
Beyond sheer technical skills, such as translation or engineering, tool procurement is an often-overlooked cost factor. Usually, less is more, but it’s always a best-of-breed vs. best-of-suite trade-off: either you purchase many specialized tools with a great depth of features or you choose fewer tools that are very versatile but don’t have that many specialized features.
Gridly doesn’t just offer sophisticated translation and content management features, it also lets you cover many use cases, so your content doesn’t get buried under your tech stack. Whether you want to translate JSON files or any other format, whether you already have a translation process or are new to the field, you’ll find it’s designed with developers in mind to avoid bottlenecks and enable continuous localization.
