Weblate supports any format understood by Translate-toolkit, however each format being slightly different, there might be some issues with not well tested formats.
Weblate does support both monolingual and bilingual formats. Bilingual formats store two languages in single file - source and translation (typical examples is GNU Gettext, XLIFF or Apple OS X strings). On the other side, monolingual formats identify the string by ID and each language file contains only mapping of those to given language (typically Android string resources). Some file formats are used in both variants, see detailed description below.
For correct use of monolingual files, Weblate requires access to 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 application.
Most widely used format in translating free software. This was first format supported by Weblate and still has best support.
Weblate supports contextual information stored in the file, adjusting it’s headers or linking to corresponding source files.
Some projects decide to use Gettext as monolingual formats - they code just IDs in their source code and the string needs to be translated to all languages, including English. Weblate does support this, though you have to choose explicitly this file format when importing components into Weblate.
XML based format created to standardize translation files, but in the end it is one of many standards in this area.
XLIFF is usually used as bilingual.
Native Java format for translations.
Java properties are usually used as bilingual.
Qt Linguist .ts¶
Translation format used in Qt based applications.
Qt Linguist files are used as both bilingual and monolingual.
Android string resources¶
Android specific file format for translating applications.
Android string resources are monolingual, the Monolingual base language file file being stored in different location than others res/values/strings.xml.
Android string-array structures are not currently supported. To work around this, you can break you string arrays apart:
<string-array name="several_strings"> <item>First string</item> <item>Second string</item> </string-array>
<string-array name="several_strings"> <item>@string/several_strings_0</item> <item>@string/several_strings_1</item> </string-array> <string name="several_strings_0">First string</string> <string name="several_strings_1">Second string</string>
The string-array that points to the string elements should be stored in a different file, and not localized.
This script may help pre-process your existing strings.xml files and translations: https://gist.github.com/paour/11291062
Apple OS X strings¶
Apple specific file format for translating applications, used for both OS X and iPhone/iPad application translations.
Apple OS X strings are usually used as bilingual.
Apple OS X strings are half broken in translate-toolkit 1.9.0 (it will generate corrupted files while saving), please use Git snapshot for handling these.
PHP files can be processed directly, though currently Translate-toolkit has some problems writing them properly, so please double check that your files won’t get corrupted.
PHP translations are usually monolingual, so it is recommended to specify base file with English strings.
Sample file which should work:
<?php $string['foo'] = 'This is foo string';
JSON translations are usually monolingual, so it is recommended to specify base file with English strings.