Drop Locale

TMX translator that runs in your browser

Drop a .tmx file in below, pick a target language, download the translated file. The TMX file stays on your device.

Loading translator...

How it works

Drop a .tmx file on the page, click to choose one, or paste the contents straight in. The parser reads the file in your browser and lists every translation unit that needs a target-language variant. Pick a target language and translation starts immediately. The translated file is reassembled from the same parsed tree so existing variants in other languages, notes, properties, and tu attributes 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 TMX 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 TMX 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

TMX 1.4 specifically (the LISA OSCAR standard, also handles 1.4b and earlier 1.x revisions). The parser is hand-written for the TMX 1.x 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 both xml:lang and the older lang attribute spellings on <tuv>.

Multi-language translation units. A TMX file is a translation memory: each <tu> can carry variants of the same source segment in many languages, with each variant in its own <tuv xml:lang="..."> wrapper. This translator preserves that structure. The source variant is selected by the header’s srclang attribute. The user-chosen target language is added as a new <tuv> when the file does not already have one, or the existing target-language <tuv> has its <seg> replaced when one is already present. Every other language variant round-trips untouched.

Per-unit source language. When the header declares srclang="*all*", each <tu> may declare its own srclang attribute that wins over the header’s. The parser honors this so a polyglot memory file with English source for some units and French source for others works correctly.

Language-code matching is case-insensitive. xml:lang is case-insensitive per XML 1.0, so a header srclang of en-US matches a tuv tagged en-us, EN-US, or en-Us. When no exact tag matches, prefix matching kicks in: a target of en will match a tuv tagged en-GB if no plain en tuv exists, so a TM that only carries regional variants still works.

Existing target-language tuvs on entries you do not touch are preserved verbatim. <note> children on a <tu> surface in the review pane as translator context. <prop> elements and unknown attributes round-trip unchanged.

Not yet: inline-element-aware handling for <bpt>, <ept>, <ph>, and <it> placeholders (inline elements pass through to the translator as part of the source text), CAT-tool-specific extension namespaces beyond the core 1.4 surface, and TMX 2.x (no public consensus standard exists; CAT tools still ship 1.4).

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 <tmx> root elements (we use the first)
  • Indented or whitespace-heavy XML formatting
  • XML comments anywhere in the document

Refused with an explanation:

  • Empty or whitespace-only file. Add at least one <tu> with two <tuv> language variants 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.
  • <header> element missing or missing required srclang. Add a <header srclang="xx-XX" …> element above <body>.
  • No translatable <tu> entries with source-language <tuv>. Confirm each <tu> has a <tuv xml:lang> matching the header srclang.
  • Non-UTF-8 encoding declared. Re-save the file as UTF-8 and re-upload.
  • Looks like a different format (XLIFF, etc.). Use the /translate/ hub to pick the right translator.
  • Not a TMX 1.x file. This translator handles TMX 1.4 / 1.4b. Re-export from your TMS as TMX 1.x.

Common questions

What is a TMX file? TMX is the file format CAT tools (Trados, MemoQ, OmegaT, Wordfast, Phrase, Smartling) use to exchange translation memory. Each translation unit holds the same segment in multiple languages, so a CAT tool can look up a previous translation when it sees the same source string again. TMX is to translation memory what XLIFF is to in-progress localization work: both are XML, but the data model is different.

I have an XLIFF file. Will this translator accept it? No. XLIFF is a separate format with different element shapes (<trans-unit>, <source>, <target> on the same unit) and there are dedicated translators at /translate/xliff/ and /translate/xliff2/. If you drop XLIFF here by mistake, the parser detects it and points you at 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? TMX 1.4 has no built-in plural mechanism. Tools that need plurals encode them as separate <tu> entries (often with a <prop type="x-plural-form"> sibling) or in extension namespaces. This translator treats every <tu> as singular; vendor-specific plural conventions pass through verbatim.

What if my file already has a target-language tuv for the language I am translating to? The existing target-language <seg> text shows up in the review pane as the pre-filled translation. On download, the existing tuv is replaced rather than duplicated, so you do not end up with two tuvs in the same language on one <tu>.

What about PO, XLIFF, ARB, .xcstrings, .properties, JSON, .strings, Fluent? Each has its own translator at /translate/po/, /translate/xliff/, /translate/xliff2/, /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 CAT tools have built-in TMX export, but pre-populating that TMX with first-pass machine translation usually means routing through a paid plan in the same tool or uploading to a SaaS post-editing service. This sits in between: free, browser-based, no upload, designed for the “I just exported a TMX of new source strings; give me a first-pass target draft I can clean up” workflow.

What is TMX?

TMX (Translation Memory eXchange) is the XML interchange format defined by the Localization Industry Standards Association (LISA) and maintained today by OSCAR (Open Standards for Container/Content Allowing Re-use). The most current published revision is 1.4b. A TMX file holds a header that describes the file (creation tool, segment type, source language) and a body containing one or more translation units; each unit holds the same string in multiple languages as separate <tuv> variants. CAT tools use TMX to share memory across projects, vendors, and tools; localization engineers use it as a canonical export from one system into another. TMX is older than XLIFF and serves a different purpose: TMX stores aligned translation memory, XLIFF stores in-progress translation work.