i18n resource file formats

Here at LingoHub, we support all the file formats commonly used in software internalization and localization. Some of these formats have well-defined standards, but for others, we had to adopt best practices instead. After providing the general information concerning the file formats, we will describe each of them, one post per file format. If the format used by your application is not currently supported by LingoHub or if the syntax you use is different from ours, please don’t hesitate to contact us. As always, we will be happy to tailor LingoHub to your needs.

Resource files are generally used for storing parameters. For the purposes of internationalization and localization, the parameters stored are key-value pairs: the name of the phrase that is being translated, and the translated phrase itself. The key-value pairs are usually delimited by new lines or some special characters. Each key normally holds a single value, although some formats may allow multiple values. Key nesting is also allowed by some formats.

Placeholders are positions within the translated phrase to which a programmer can dynamically insert some content during run-time, for example a current user’s name. Not all formats support placeholders.

Content that should be ignored by parsers can be commented out. Since these comments usually contain information that is intended for either developers or translators, instead of discarding that information, we process it, store it and export it back to the resource files generated on the file download.

A comment is usually “assigned” to the key-value pair directly after it (without the blank lines in between), and is stored as a translation description for that pair. There is also one additional special use for translation comments, but it will be described in a next article of its own.

Please note that currently only the comments in the master locale resource files are being processed.

For some file formats a specific encoding is defined by the standard or is traditionally used. While we adopt this as a default behavior, our users can choose the encoding that suits their needs best. You can read more about it in the previous post.