About localization files and how they’re used

Localization files, also known as resource files, are important components of software development because they enable developers to create applications that can be easily adapted to different languages. That is, in fact, their main function—to facilitate language translations. But they’re not limited to simple text translations, as localization files can also handle multiple cultural adjustments. We’ll discuss all this and more, below.

The structure of localization files

At its core, a localization file is a simple text file that pairs a unique identifier (or key) with a text string (or value). When the application runs, it looks up the appropriate key and displays the corresponding value in the user’s language.

Keys should be descriptive enough to provide context but concise enough to avoid clutter. The value is the actual text or content to be displayed in the user interface. Often, these values include placeholders for dynamic content.

Beyond the basics, localization files can become more complex to handle various language nuances. We’re talking things like plural forms, currency formats, date and time formats, as well as text direction (for RTL localization).

You should also know that proper naming of localization files is important. Based on the platform you’re using, you could have different ways of storing your language files. For Android localization, language files are stored in the res directory which will contain a values-[LANGUAGE_CODE] directory for each localized language, like this:

/res/values-language_code/strings.xml

For other platforms, the format might look like this:

/languages/<base_filename>_<language_code>_<region_code>.<extension>

How localization files work

Now let’s take a look at the localization files’ journey through the internationalization and localization realms. It all begins by identifying and extracting the text strings that need to be translated. This process is often automated using specialized tools and involves scanning the source code for text that is likely to be localized (e.g., user interface labels, error messages, and help text). These extracted strings are then stored in a structured format, usually as key-value pairs.

Many file formats allow you to include comments or metadata to provide context for translators. Context helps translators make better decisions because you’re providing them with additional information that clarifies the purpose, usage, and nuances of the text.

Once the text strings have been extracted, they are imported to a translation management system where professional translators and/or machine translation systems translate the text strings into the target languages. The translated strings are then reviewed for quality, consistency, and adherence to language standards.

If everything looks alright, the translated strings are integrated back into the application using the unique keys that were assigned to them during the extraction process. When the application runs, it looks up the appropriate key in the localization file and displays the corresponding translated string.

Common formats you’ll encounter

Localization files come in various formats, depending on the platform and tools used. At POEditor, we’ve observed that the most frequently used formats by our clients are KV-JSON, PO/POT, XML, XLIFF, and Strings files.

KV-JSON is a specific type of JSON file that stores translations as simple key-value pairs. This format is widely favored for its simplicity and compatibility with web applications, especially those using JavaScript frameworks. KV-JSON is highly flexible and easy to parse, so it’s easy to see why it’s so popular.

PO files are part of the GNU gettext system and are a standard format for managing translations in open-source projects. Each entry in a PO file includes a message ID (original text) and a message string (translation), often accompanied by comments providing context.

POT files serve as templates for PO files and are used to distribute source strings without translations. They allow developers to provide translators with a baseline set of strings, which can then be localized into different languages by generating corresponding PO files.

YAML offers a more human-readable alternative and is often favored in scenarios where manual editing is common, XML—used for Android apps and legacy systems, and properties files—extensively used in Java-based applications. XLIFF (XML Localization Interchange File Format) files come in different formats that include platform-specific customizations. XLIFF allows for the storage of source text and its translated counterpart in an XML structure, making it easier for translators and software developers to manage and collaborate on the localization process.

Alas, it’s also worth mentioning XLSX files, which are commonly used by translators. These are Excel spreadsheets commonly used for localization due to their versatility and ease of collaboration. Each row typically represents a translation unit, with columns for keys, source text, and translations. This format is especially useful for non-technical users that prefer a familiar spreadsheet environment for managing translations.

A few tips on how to manage these files

There are a few best practices when it comes to localization files too. If you’re a developer, make sure to:

• Avoid hardcoding text directly into your application’s logic. Instead, use descriptive keys to reference strings stored in localization files.
• Avoid dynamic string construction. It’s better to use placeholders within the localization file because it allows for more flexible translations.
• Organize files logically, typically by language and region.
• Maintain consistency in key naming conventions across all locales.

Why use a translation management system

A translation management system (TMS) allows you to manage all localization files in one place, which helps maintain consistency and simplifies updates. By importing source files, you can track translations across different languages and versions without manually handling each file. POEditor is known for its versatility and support for various file formats.

You can upload and download localization files in multiple formats, such as JSON, PO, POT, and XLSX, depending on your project needs. Thanks to the multiple integrations with development tools, it’s easier to automate the process. You can also use APIs to automate tasks like uploading new strings or fetching translations.

A TMS promotes collaboration by allowing multiple users to work on translations simultaneously. It’s possible to assign different roles (e.g., project owner, project admin, contributor) to maintain control and oversight. The team working on the project sees the updates in real-time, which helps keep everyone on the same page.

See how investing in a good TMS is a smart way to streamline the localization process.