I18N File Translation
Source Files:
Accepts ZIP archives or individual files: JSON, JSONC, XML, YAML, ARB, PO/POT, XLIFF, Properties, CSV/TSV, MD, TXT. Maximum size is 5 MB.
Source Language: en-US (English, United States)
The code of the source language. Example: fr, fr-FR, fil, zh-Hans-CN. Type to search.
Generate & Save Glossary:
Translate only new strings:
Indicates whether to translate only new and changed strings.
Target Languages:
de (German), zh-Hans-CN (Chinese, Simplified Chinese, China)
Generate plural forms:
Translate Metadata:

Supported File Formats

Our I18N File Translation service supports a wide range of file formats used across different platforms and frameworks.

FormatUsed By Supports translating only new strings Supports comments Supports metadata translation control
JSON / JSONCJavaScript, TypeScript · i18next, React, Vue, Angular
XMLAndroid strings.xml · iOS plist · Generic XML · .NET ResX
YAML / YMLRuby on Rails · Node.js · Configuration files
ARBFlutter · Dart
PO / POTGNU Gettext · PHP, Python, WordPress, Ruby
XLIFFProfessional CAT tools · Localization platforms · Angular
.propertiesJava · Spring Boot · Android
CSV / TSVSpreadsheets · Custom localization workflows
MDDocumentation · README files · Jekyll, Hugo, Docusaurus
TXTPlain text files used for app localization

How to translate i18n files

Translating i18n files is a straightforward process provided by our service. Follow these steps to translate your internationalization files and ensure consistency across your projects.

  1. Upload Files: Use the "Source Files" section to upload your i18n files or a ZIP archive. Supported formats: JSON, JSONC, XML, YAML, ARB, PO/POT, XLIFF, Properties, CSV/TSV, MD, TXT. If the file name contains a language code, it will be automatically used as the source language.
  2. Set Source and Target Languages:
    Choose your source language (e.g., en-US). Add one or more target languages (e.g., fr-FR, de-DE), and configure translation options.

    Incremental Translation: This feature is ideal for ongoing projects. By uploading the existing target files, you can ensure that only new and changed strings are translated, while previously translated content remains unchanged. This not only saves costs but also preserves any manual adjustments made to existing translations. We store hashes of source strings, so the system can detect which strings are new vs. old based on the presence of their hashes.

    Important: If you enable "Translate only new strings", the target files you upload must already contain the previously translated strings for that language (e.g., your French file should already include all old French translations).

    If you simply upload the same source file as the target file (which has no French content), nothing will be translated, because there's no way to detect which strings are new vs. old.

    Note: Uploading target files is optional. If you do not upload any target files, first time all strings will be translated, regardless of whether "Translate only new strings" is enabled or not.

    File Naming Rules:
    If your uploaded files are not named exactly as language codes (e.g., fr.json, de.json), their names must match the source files' names so the system knows they contain the same strings in different languages. For example:

    /en/common.json
    /fr/common.json
    /de/common.json

    This makes sure translations line up correctly. If the file names are different from the source file name, the system will treat them as belonging to different namespaces. In i18n, a namespace is simply a separate file used to organize strings by parts of your app (for example: common.json for general strings, auth.json for login, dashboard.json for dashboard).

    Each namespace should have a matching file in every language folder:

    /en/common.json
    /en/auth.json
    /fr/common.json
    /fr/auth.json

    Using the same file names for each language ensures the system can correctly match strings.

  3. Start Translation: Click the "Translate" button to begin. Our service carefully manages files to preserve string order, preventing unnecessary changes. Progress is displayed in real-time.
  4. Download Translated Files: After the translation is complete, click the "Download Translated Files" button to retrieve your translated content. The downloaded file is a ZIP archive named after the job ID (for example: 0196e881-fb54-7150-a292-5b1e8f70a8ae.zip). The archive contains translated files for each target language, organized into separate folders by language code.

Why our i18n translation service

  • AI-powered contextual translation: Our AI intelligently interprets i18n format placeholders, and adapts translations to cultural norms based on the language, script, and region are specified in the language code.
  • Wide format support: Our service handles all major i18n file formats. It accurately manages plural forms, preserves HTML tags and comments, retains line breaks, and keeps the structure of your files intact.
  • Locale-specific adjustments: Numbers and dates in text are automatically converted to match the target locale format.
  • Error handling: We detect AI errors and retranslate if necessary, ensuring high-quality result.
  • Cost-effective: Our service is more affordable than other machine translation solutions. Users receive 10,000 characters free monthly. See Pricing
  • Optimized for large files: Our system efficiently processes large i18n files by dividing them into manageable chunks, ensuring each segment fits within the AI's output window. This approach maintains translation consistency by leveraging predefined terminology and context, even for large files.

Our platform streamlines the localization of your i18n files with advanced AI-powered translation, delivering accurate and efficient result while preserving your file structure and context.

What Is i18n? Internationalization and Localization Explained

Internationalization (i18n) is the process of designing software so it can be adapted to different languages and regions without code changes. Localization (l10n) is the process of actually adapting the software for a specific locale — translating strings, adjusting date formats, currencies, and cultural references. The "18" in i18n stands for the 18 letters between the "i" and "n" in "internationalization".

i18n file translation is at the heart of the localization workflow. Instead of hardcoding text in source code, developers externalize all user-facing strings into resource files — JSON, YAML, PO, XLIFF, ARB, or Properties files. These files become the single source of truth for all translations and are managed, versioned, and deployed alongside the application.

For global products, i18n files may need to be translated into dozens of languages. Managing this at scale requires automation, consistency, and format-aware tooling — which is exactly what our AI-powered I18N File Translation service provides.

i18n File Formats: Which One Should You Use?

The choice of i18n file format typically depends on your technology stack. Each format has different strengths for structure, tooling, and platform support:

  • JSON — the most popular format for web applications. Used by i18next, React Intl, ngx-translate, and Vue i18n. Supports nested keys and interpolation. Recommended for React, Angular (ngx-translate), Vue, and Next.js projects.
  • YAML — the native format for Ruby on Rails i18n and widely used in Symfony (PHP) and Vue i18n. Human-readable with support for comments, nested keys, and multi-line strings.
  • PO / Gettext — the standard for WordPress plugins, PHP applications, Python (Django, Flask), and Linux desktop software. Built-in support for plural forms, translator comments, and source file references.
  • XLIFF — the industry standard for professional translation workflows. Used by Angular's built-in i18n, iOS/Xcode, and all major CAT tools (SDL Trados, memoQ, Memsource). Ideal for enterprise projects involving translation agencies.
  • ARB — Flutter's Application Resource Bundle format. JSON-based with localization metadata. The standard for Flutter and Dart app localization, compiled by flutter gen-l10n.
  • Properties — Java's native localization format. Used by Spring Boot, Android (legacy), and enterprise Java applications with ResourceBundle.

Incremental Translation: Translate Only New Strings

One of the most powerful features of our I18N File Translation service is incremental translation — the ability to translate only new or changed strings without re-translating content that is already localized. This significantly reduces translation costs and processing time for actively developed projects.

To use incremental translation, upload both your source file and the existing target file for each language. Our system compares the keys present in both files and translates only the strings missing from the target. This is especially valuable during continuous development cycles where new strings are added with each sprint or release.

Supported formats for incremental translation are listed in the table above. For other formats, uploading a target file is still useful for glossary context, ensuring consistent terminology across translation runs.

Common Use Cases for i18n File Translation

Our I18N File Translation service handles the full range of modern localization scenarios:

  • Web Application Localization: Translate JSON, YAML, and Properties files for React, Angular, Vue, Next.js, and Nuxt.js single-page apps. Support for i18next namespace structure allows translating all language files from a single ZIP upload.
  • Mobile App Localization: Translate ARB files for Flutter apps, Properties files for Android, and XLIFF files exported from Xcode for iOS and macOS app localization.
  • Documentation and Content: Translate Markdown files for static site generators like Docusaurus, VitePress, Jekyll, and Hugo to deliver multilingual documentation websites.
  • WordPress and PHP Projects: Translate PO/POT files for WordPress themes and plugins, Symfony applications, and other PHP-based projects using gettext-based localization.
  • Angular Applications: Translate XLIFF 1.2 and 2.0 files generated by ng extract-i18n for Angular's built-in internationalization system.
  • Enterprise and CAT Workflows: Process XLIFF files exchanged with professional translation agencies and CAT tools (SDL Trados, memoQ, Memsource) using our structure-preserving AI translation.
  • Open Source Projects: Translate PO files for GNU gettext-based open source projects, desktop applications (GTK/GNOME/KDE), and developer tools distributed across language communities.
  • CI/CD Automation: Integrate i18n file translation into your release pipeline using the L10n.dev REST API to automatically translate new strings on every merge or deployment.

Frequently Asked Questions

What i18n file formats are supported?

We support JSON / JSONC, XML (Android strings.xml, .NET ResX, generic), YAML / YML, ARB (Flutter), PO / POT (GNU Gettext), XLIFF 1.2 and 2.0, .properties (Java), CSV / TSV, Markdown (.md), and plain text (.txt). Files can be uploaded individually or as a ZIP archive up to 5 MB.

Can I translate into multiple languages at once?

Yes. You can add multiple target languages in a single job. Our service processes all language pairs and packages the results in a ZIP archive organized by language code (e.g., fr/, de/, ja/).

How does "Translate Only New Strings" work?

Upload your source file and the existing target file (which already contains your previous translations) for each language. Our system identifies strings present in the source but missing from the target and translates only those — avoiding re-translating content you've already paid for and preventing overwrites of manual edits.

What is the maximum file size?

The maximum upload size is 5 MB per file or ZIP archive. For very large projects, consider splitting files by namespace or uploading multiple jobs. You can monitor job progress in real-time on this page and access all completed jobs on the Files page.

How does file namespacing work?

Files with the same name in different language folders are treated as the same namespace (e.g., /en/common.json and /fr/common.json). Files with different names are treated as separate namespaces. Use consistent file names across all language folders to ensure correct string matching.