Drop Locale

XLIFF 2.0 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 segments still need translation. Pick a target language and translation starts immediately. The translated file is reassembled from the same parsed tree so comments, attributes, notes, groups, and the original segment layout 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 2.0 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 2.0 specifically (the OASIS standard, namespace urn:oasis:names:tc:xliff:document:2.0). The parser is hand-written for the XLIFF 2.0 subset, so it is tolerant of common real-world variations: BOM-prefixed files, Windows line endings, mixed quote styles on attributes, CDATA sections, namespace prefixes on element names, and segment elements with or without id attributes.

Segment indirection. The 2.0 grammar wraps every <source> and <target> in a <segment> element so that a single <unit> can hold multiple translatable sentences. This translator preserves that structure: each segment becomes its own row in the review pane with a stable key, and writes back into the same segment element on download. Multi-segment units round-trip with their segment ids intact.

Groups. Nested <group> containers are walked transparently; their child units surface as flat entries while the wrapping structure is preserved on output.

Multiple <file> elements in one document are supported. Each gets its own entries, namespaced by the file’s id so cross-file collisions on unit ids do not collapse rows. The target language is written to trgLang on the root <xliff> element (XLIFF 2.0 carries language at the root, unlike 1.2 which carries it per-file).

Existing target text on entries you do not touch is preserved verbatim. Notes inside the <notes> wrapper surface in the review pane as translator context for the matching unit’s segments.

Not yet: inline-tag-aware placeholder protection (inline elements like <ph/>, <pc>, <sc/>, <ec/> are passed through to the translator as part of the source text), the Format Style module, and CAT-tool-specific extension namespaces beyond the core 2.0 surface.

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) or mixed line endings
  • Leading blank lines before the XML declaration
  • Multiple <xliff> root elements (we use the first)
  • Empty <segment> elements with no source text

Refused with an explanation:

  • Empty or whitespace-only file. Add at least one <unit> with <segment><source> and re-upload.
  • DOCTYPE or DTD declaration present. Remove the <!DOCTYPE …> line (we do not fetch external DTDs) and re-upload.
  • XML syntax error or truncated document. Fix the XML so it parses, then re-upload.
  • No translatable <unit> entries found. Confirm the file has at least one <unit> with a <segment> and re-upload.
  • Non-UTF-8 encoding declared. Re-save the file as UTF-8 and re-upload.
  • Looks like a different translation format (PO, etc.). Use the /translate/ hub to pick the right translator.
  • XLIFF 1.2 file uploaded to the XLIFF 2.0 translator. Use /translate/xliff/ for XLIFF 1.2 files.

Common questions

I have an XLIFF 1.2 file. Will this translator accept it? No. XLIFF 1.2 uses a different grammar (<trans-unit> directly inside <body>, with no segment indirection). Drop 1.2 files at /translate/xliff/ instead. If you drop a 1.2 file here by mistake, the parser detects it and points you to the right page.

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.

How are plurals handled? XLIFF 2.0 core has no built-in plural mechanism (unlike PO or XLIFF 1.2’s x-gettext-plurals convention). Tools that need plurals typically rely on separate units, the ITS module, or a vendor-specific extension. This translator treats every unit and every segment as singular; if your tool encodes plurals in extension namespaces, those will pass through verbatim.

Why is my Lokalise / Phrase / Smartling 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.

What about PO, ARB, .xcstrings, .properties, JSON, .strings, Fluent? Each has its own translator at /translate/po/, /translate/arb/, /translate/xcstrings/, /translate/properties/, /translate/json/, /translate/strings/, and /translate/fluent/. Drop your file at the page that matches it.

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 2.0 file” workflow.

What is XLIFF 2.0?

XLIFF 2.0 is the OASIS standard that succeeded XLIFF 1.2 in 2014. It tightens the schema, drops legacy element shapes that had grown ambiguous (<alt-trans>, <mrk> as a translation marker), and adds segment indirection: every translatable string lives inside a <segment> element, so one <unit> can carry multiple segments and a translator can split or merge them without losing the unit identity. The language attributes moved from per-<file> to root-level srcLang and trgLang, which makes multi-file documents simpler to reason about. The 2.0 spec is modular: tools opt into named modules (Translation Candidates, Glossary, Format Style, Metadata, Resource Data, Change Tracking, Size Restriction, Validation, ITS) so a producer and consumer can negotiate exactly which extensions they understand. The two versions are not interchangeable, which is why XLIFF 1.2 and XLIFF 2.0 have separate translators on DropFormat.