Drop Locale

XLIFF translator that runs in your browser

Drop a .xlf or .xliff file in below, pick a target language, download the translated file. The XLIFF file stays on your device.

Loading translator...

How it works

Drop a .xlf or .xliff file on the page, click to choose one, or paste the contents straight in. The parser reads the file in your browser and tells you how many strings still need translation. Pick a target language and translation starts immediately. The translated file is reassembled from the same parsed structure so comments, attributes, namespaces, and notes survive the round trip.

Quality Warning

Please don’t rely on the quality of these translations to ship a finalized product. This is just a starting point. It’s machine translation and there are no guarantees about its quality.

What we do not do

The file itself never leaves your device. We do not see what you are translating, we do not store any of the strings, and there is nothing about your file in our logs. The privacy wedge in DropFormat is structural: the XLIFF parser, the Google Translate caller, and the file writer all run inside your browser tab.

What does leave your device: the individual strings go to translate.googleapis.com the same way they would if you pasted them into translate.google.com yourself. We are not in the middle. If your file contains internal product strings you do not want a third party to see, do not translate it here; use an offline tool.

What it supports

XLIFF 1.2 specifically. The parser is hand-written for the XLIFF subset, so it is tolerant of common real-world variations: optional XML declaration, missing or wrong namespace declarations, BOM-prefixed files, Windows line endings, mixed quote styles on attributes, inline tags inside <source> and <target> (<g>, <x/>, <ph>, <bpt>, <ept>), and CDATA sections.

Plural forms via <group restype="x-gettext-plurals"> are first-class: a plural group collapses into one entry in the review pane with one slot per plural form. The target language’s gettext plural rules drive the number of slots. If you ship to Arabic (6 forms) from an English 2-form source, the output has 6 forms (filled in with the best machine guess we have). Override any of them in the review pane before downloading.

Multiple <file> elements in one document are supported. Each gets its own entries, namespaced by the original attribute so collisions across files do not collapse rows. Comments, attribute order, and existing target text on entries you don’t touch are preserved on round trip.

Not yet: inline-tag-aware placeholder protection (right now inline tags are passed through to the translator as part of the source text), and CAT-tool-specific extensions beyond the core XLIFF 1.2 surface. XLIFF 2.0 lives at a separate translator: /translate/xliff2/.

What we tolerate, and what we reject

Some malformed files we repair on the way in. Others we refuse to load so we do not make things worse. This list is the parser’s actual behaviour, generated from the format module itself, not aspirational copy.

Repaired automatically:

  • UTF-8 byte order mark (BOM) at the start of the file
  • Windows (CRLF) line endings
  • Missing <?xml … ?> declaration
  • Missing or wrong xmlns on the <xliff> element
  • Mixed or unusual namespace prefixes
  • Mixed single and double quotes on attributes
  • Numeric character entities (&#nn;, &#xNN;)
  • CDATA sections inside <source> or <target>
  • Inline tags inside <source> (<g>, <x/>, <ph>, <bpt>, <ept>)
  • XML comments anywhere in the document
  • Indented or whitespace-heavy formatting
  • xml:space="preserve" attributes
  • Multiple <file> elements in one document
  • Multiple <xliff> root elements (we use the first)
  • Deeply nested <group> elements
  • Self-closing <trans-unit/> shorthand
  • <trans-unit> entries with no id attribute
  • <trans-unit> with no <target> element
  • Empty <source> text content
  • Duplicate <trans-unit> id values across files
  • Mis-decoded text (we pass through, not re-encode)

Refused with an explanation:

  • Empty or whitespace-only file. Add at least one <trans-unit> and re-upload.
  • DOCTYPE or DTD declaration present. Remove the <!DOCTYPE …> line (we do not fetch or expand external DTDs) and re-upload.
  • XML syntax error (unescaped < or &, unbalanced tag, truncated entity). Fix the XML so it parses, then re-upload. The error message names the location.
  • No translatable <trans-unit> entries found. Confirm the file has at least one <trans-unit> with <source> and re-upload.
  • Non-UTF-8 encoding declared (e.g. UTF-16 BOM). Re-save the file as UTF-8 and re-upload.
  • Looks like a different translation format (PO, JSON, etc.). Use the /translate/ hub to pick the right translator.

Common questions

Why is the translation in some cases worse than the Google Translate website? The free endpoint we use is the same one the Google Translate website uses, but the API does not always know about the context the website’s interface provides. For names, branded terms, or jargon, expect to override in the review pane.

What if I am translating something Google’s endpoint will not accept? The free endpoint occasionally returns the source unchanged for content it would rather not translate. Those entries show “kept original” in the review pane so you can hand-translate just those.

Does it cache anything? No. Each run starts fresh.

What about XLIFF 2.0? XLIFF 2.0 has its own translator at /translate/xliff2/. The 2.0 grammar adds a <segment> indirection (and renames almost every element) so the two formats do not share a parser. If you drop a 2.0 file here by mistake, the page detects it and points you to /translate/xliff2/.

Why is my Trados / MemoQ / WPML file accepted but the round trip output differs in places like apostrophe encoding? XML allows multiple valid encodings for the same character. A literal ' in source text is equivalent to &apos;. We decode entities on parse and emit literal characters on serialize unless the character is structurally significant. Your CAT tool will re-import the file correctly.

Why this exists

Most XLIFF tooling is paid, desktop-only, or cloud-based and demanding of upload. CAT tools like Trados and MemoQ run great but are heavyweight for someone who just wants a first-pass machine translation to clean up. Cloud platforms like Smartling and Phrase want your XLIFF uploaded to their servers. This tool sits in between: free, browser-based, no upload, designed for the “I just need a fast first pass on this XLIFF” workflow.

What is XLIFF?

XLIFF (“XML Localization Interchange File Format”) is an OASIS standard XML schema for moving translatable content between localization tools. Each <trans-unit> has a <source> (text to translate) and a <target> (the translation), plus optional <note> elements for translator context. The format is used by CAT tools (Trados, MemoQ, OmegaT, Lingohub, POEditor), cloud TMSes (Smartling, Phrase, Lokalise, Crowdin), and WordPress translation plugins (WPML, Polylang, TranslatePress) as their primary interchange format. Apple Xcode also exports localizable strings as XLIFF 1.2 for round-tripping with translators.