Supported file formats

Weblate supports a wide range of translation formats. Each format is slightly different and provides a different set of capabilities.

Hint

When choosing a file format for your application, it’s better to stick some well established format in the toolkit/platform you use. This way your translators can additionally use whatever tools they are used to, and will more likely contribute to your project.

• Android string resources
• Apple iOS strings
• App store metadata files
• ARB File
• CSV files
• DTD files
• Excel Open XML
• Flat XML files
• Fluent format
• GNU gettext
• go-i18n JSON files
• gotext JSON files
• GWT properties
• HTML files
• i18next JSON files
• IDML Format
• INI translations
• Inno Setup INI translations
• Java properties
• Joomla translations
• JSON files
• Laravel PHP strings
• Markdown files
• mi18n lang files
• OpenDocument Format
• PHP strings
• Qt Linguist .ts
• ResourceDictionary files
• .NET resource files (RESX, RESW)
• Ruby YAML files
• Stringsdict format
• Subtitle files
• TermBase eXchange format
• Text files
• WebExtension JSON
• Windows RC files
• XLIFF
• YAML files

See also

Translation Related File Formats

Automatic detection

Weblate tries to detect file format during Adding translation projects and components. The detection might be wrong for different variants of the same serialization format (JSON, YAML, properties) or file encoding, so please verify that File format is correct before creating the component.

Translation types capabilities

Capabilities of all supported formats

Format	Linguality [1]	Plurals [2]	Descriptions [3]	Context [4]	Location [5]	Flags [8]	Additional states [6]
GNU gettext	bilingual	yes	yes	yes	yes	yes [9]	needs editing
Monolingual gettext	mono	yes	yes	yes	yes	yes [9]	needs editing
XLIFF	both	yes	yes	yes	yes	yes	needs editing, approved
Java properties	both	no	yes	no	no	no
mi18n lang files	mono	no	yes	no	no	no
GWT properties	mono	yes	yes	no	no	no
Joomla translations	mono	no	yes	no	yes	no
Qt Linguist .ts	both	yes	yes	no	yes	yes	needs editing
Android string resources	mono	yes	yes [7]	no	no	yes
Apple iOS strings	both	no	yes	no	no	no
PHP strings	mono	no [10]	yes	no	no	no
JSON files	mono	no	no	no	no	no
i18next JSON files	mono	yes	no	no	no	no
go-i18n JSON files	mono	yes	yes	no	no	no
gotext JSON files	mono	yes	yes	no	yes	no
ARB File	mono	yes	yes	no	no	no
WebExtension JSON	mono	yes	yes	no	no	no
.NET resource files (RESX, RESW)	mono	no	yes	no	no	yes
ResourceDictionary files	mono	no	no	no	no	yes
CSV files	both	no	yes	yes	yes	no	needs editing
YAML files	mono	no	no	no	no	no
Ruby YAML files	mono	yes	no	no	no	no
DTD files	mono	no	no	no	no	no
Flat XML files	mono	no	no	no	no	yes
Windows RC files	mono	no	yes	no	no	no
Excel Open XML	mono	no	yes	yes	yes	no	needs editing
App store metadata files	mono	no	no	no	no	no
Subtitle files	mono	no	no	no	yes	no
HTML files	mono	no	no	no	no	no
Markdown files	mono	no	no	no	no	no
OpenDocument Format	mono	no	no	no	no	no
IDML Format	mono	no	no	no	no	no
INI translations	mono	no	no	no	no	no
Inno Setup INI translations	mono	no	no	no	no	no
TermBase eXchange format	bilingual	no	yes	no	no	yes
Text files	mono	no	no	no	no	no
Stringsdict format	mono	yes	no	no	no	no
Fluent format	mono	no [11]	yes	no	no	no

[1]

See Bilingual and monolingual formats

[2]

See Pluralized strings

[3]

See Source string description

[4]

See Context

[5]

See Source string location

[6]

See String states

[7]

XML comment placed before the <string> element, parsed as a source string description.

[8]

See Translation flags.

[9] (1,2)

The gettext type comments are used as flags.

[10]

The plurals are supported only for Laravel which uses in string syntax to define them, see Localization in Laravel.

[11]

Plurals are handled in the syntax of the strings and not exposed as plurals in Weblate.

Bilingual and monolingual formats

Both monolingual and bilingual formats are supported. Bilingual formats store two languages in single file—source and translation (typical examples are GNU gettext, XLIFF or Apple iOS strings). On the other side, monolingual formats identify the string by ID, and each language file contains only the mapping of those to any given language (typically Android string resources). Some file formats are used in both variants, see the detailed description below.

For correct use of monolingual files, Weblate requires access to a file containing complete list of strings to translate with their source—this file is called Monolingual base language file within Weblate, though the naming might vary in your paradigm.

Additionally this workflow can be extended by utilizing Intermediate language file to include strings provided by developers, but not to be used as is in the final strings.

String states

Many file formats only differentiate “Untranslated” and “Translated” strings. With some formats it is possible to store more fine-grained state information, such as “Needs editing” or “Approved”.

Source string description

Source string descriptions can be used to pass additional info about the string to translate.

Several formats have native support for providing additional info to translators (for example XLIFF, GNU gettext, WebExtension JSON, CSV files, Excel Open XML, Qt Linguist .ts, go-i18n JSON files, gotext JSON files, ARB File, .NET resource files (RESX, RESW)). Many other formats extract closest comment as source string description.

Explanation

The Explanation on strings can be stored and parsed from a few file formats.

Currently supported only in TermBase eXchange format.

Source string location

Location of a string in source code might help proficient translators figure out how the string is used.

This information is typically available in bilingual formats where strings are extracted from the source code using tools. For example GNU gettext and Qt Linguist .ts.

Translation flags

Translation flags allow customizing Weblate behavior. Some formats support defining those in the translation file (you can always define them in the Weblate interface, see Customizing behavior using flags).

This feature is modelled on flags in GNU gettext.

Additionally, for all XML based format, the flags are extracted from the non-standard attribute weblate-flags. Additionally max-length:N is supported through the maxwidth attribute as defined in the XLIFF standard, see Specifying translation flags.

See also

Customizing behavior using flags, PO files documentation

Context

Context is used to differentiate identical strings in a bilingual format used in different scopes (for example Sun can be used as an abbreviated name of the day “Sunday” or as the name of our closest star).

For monolingual formats the string identifier (often called key) can serve the same purpose and additional context is not necessary.

Pluralized strings

Plurals are necessary to properly localize strings with variable count. The rules depend on a target language and many formats follow CLDR specification for that.

Hint

Pluralizing strings need proper support from the application framework as well. Choose native format of your platform such as GNU gettext, Android string resources or Stringsdict format.

Read-only strings

Read-only strings from translation files will be included, but can not be edited in Weblate. This feature is natively supported by few formats (XLIFF and Android string resources), but can be emulated in others by adding a read-only flag, see Customizing behavior using flags.

Supporting other formats

Most formats supported by translate-toolkit which support serializing can be easily supported, but they did not (yet) receive any testing. In most cases some thin layer is needed in Weblate to hide differences in behavior of different translate-toolkit storages.

To add support for a new format, the preferred approach is to first implement support for it in the translate-toolkit.

See also

Translation Related File Formats