Supported File Formats
Import your existing translations and export to any format your stack requires. Locize supports various import/export formats and different i18n framework formats.
Which format should you use?
Use the format your framework already reads. Locize imports and exports all of them, so the format in your repository and the format you hand to translators can differ.
| Your stack or task | Format |
|---|---|
| i18next, react-i18next, next-i18next and most JavaScript frameworks | JSON (i18next v4) |
| react-intl (FormatJS) and other ICU-based libraries | JSON with ICU MessageFormat |
| Angular built-in i18n | XLIFF |
| iOS and macOS, Xcode 15 or later | String Catalogs (.xcstrings) |
| iOS and macOS, older projects | .strings |
| Android | Android Strings (strings.xml) |
| .NET (ASP.NET, WPF, .NET MAUI) | RESX |
| WordPress, Python (Django), C/C++ and other gettext-based projects | Gettext PO |
| Laravel | Laravel PHP arrays |
| Ruby on Rails, Hugo, static site generators | YAML |
| Java and Spring Boot | Java Properties |
| Projects using Mozilla Fluent | Fluent (.ftl) |
| Handing work to an agency or a CAT tool | XLIFF (1.2 is the safer default) |
| Review by non-technical people in a spreadsheet | XLSX or CSV |
| Moving translation memory or glossaries between tools | TMX (memory) or TBX (glossary) |
Import & Export Formats
Many file formats for importing existing translations and exporting to your deployment target. All formats support both import and export unless noted otherwise.
i18n Framework Formats
A lot of framework-specific formats so your translations match the syntax your code expects.
Migrating existing translations?
Locize can import your existing translation files directly: XLIFF, Gettext, Android strings, RESX, and 13 other formats. No conversion scripts needed.
Frequently asked questions
Use the format your framework already reads: JSON for i18next and most JavaScript frameworks, .xcstrings for iOS and macOS apps built with Xcode 15 or later, strings.xml for Android, RESX for .NET, Gettext PO for WordPress, Python (Django) and C/C++, YAML for Rails, and .properties for Java. Use XLIFF when translations go to an agency or a CAT tool, and TMX or TBX to move translation memory or glossaries between tools. Locize imports and exports all of them, so the format in your repository and the format you hand to translators can differ.
JSON is a plain key-value structure that JavaScript frameworks load directly; i18next adds conventions for plurals and context on top. Gettext PO is a text format from the GNU project in which each entry carries the source message, optional context (msgctxt), plural forms and translator comments. XLIFF is an XML exchange format standardized by OASIS for handing translation work between tools, with a stable id per translation unit. Teams often keep JSON or PO in the code and use XLIFF only for the exchange with translators.
For the widest tool compatibility, XLIFF 1.2 is still the safer default. The 2.x line (2.0 and 2.1 as OASIS Standards, 2.2 as a 2025 Committee Specification) is cleaner and more extensible, but some agencies and CAT tools accept 2.0 and not 2.1 or 2.2 yet. Ask your translation partner which version they prefer; if you cannot, use 1.2.
New projects should use String Catalogs (.xcstrings), introduced in Xcode 15 (June 2023), which replace the older Localizable.strings and Localizable.stringsdict pair. Xcode compiles them into the same runtime resources, so NSLocalizedString and String(localized:) keep working. .strings remains supported and is still common in older projects. Locize supports both.