Migrating your translation memory

The biggest reason teams stay on a localization platform they dislike is not the platform. It is the years of approved translations sitting inside it. This page is how you get them out.

If you would rather not do this yourself, write to hello@textsetu.com with your export files attached and we will do the import and send you back what landed.

What you are actually moving

Four things, in the order that matters:

1. Translation memory: every source segment and its approved translation. This is the asset. It is what stops you paying to translate the same sentence a second time, and what keeps new drafts sounding like the ones you already signed off.
2. Glossary: product names, preferred terms, forbidden terms, do-not-translate entries.
3. Your current translations: the live files your product ships today.
4. Screenshots and context: the least portable of the four, and worth planning for separately.

Step 1: Export the translation memory as TMX

TMX is the industry's interchange format for translation memory, and essentially every localization tool can write it. In most platforms the export lives under the project or organisation settings, near the translation memory itself, and produces one .tmx file per language pair or one combined file for all of them.

Export all language pairs, not just the ones you are migrating first. TMX is small, the export is free, and having the file means you are no longer dependent on that vendor's continued goodwill.

Two things worth checking before you leave:

• Does the export include metadata? Good TMX carries the creation date and the author of each segment. Some exports drop it. It is not fatal, but you lose the audit history.
• Are there several memories? Teams often accumulate one per project. Export each; you can decide later whether to merge them.

Step 2: Export the glossary

Glossary exports are usually CSV or TBX. CSV is fine. What matters is that each row keeps its term, its translation, its language, and any flag marking it forbidden or do-not-translate. If the export flattens those flags into a notes column, keep the notes; re-deriving that intent later means asking legal again.

If your terminology currently lives in a spreadsheet rather than a tool, you are in a better position than you think: that spreadsheet is already the export.

Step 3: Export your current translations

Export in the format your product actually consumes: JSON, XLIFF, Excel, Android XML, Apple .strings, .xcstrings, Gettext PO, YAML, ARB, i18next, RESX, Qt .ts, .properties, INI, or the others TextSetu reads. Exporting in the format you already ship means the round-trip through TextSetu is verifiable: you can diff what comes back out against what went in.

Do not restructure anything to suit the import. If your keys are nested five levels deep, leave them nested five levels deep.

Step 4: Import into TextSetu

Import the three artefacts in this order:

1. Translation files first. They establish your keys and languages.
2. Translation memory (TMX) second, so the approved wording attaches to keys that already exist.
3. Glossary last, so terminology rules apply on top of everything present.

Then run one language before you run nine. Pick the language you can check best, usually the one someone in the building speaks, and look at what the drafts do with your glossary terms. That single run tells you more about the quality of the migration than any amount of reading.

Step 5: Screenshots and context

This is the part with no clean export path. Screenshot associations are stored differently by every tool, and most do not export them at all.

Two honest options:

• Re-capture the important ones. In practice a minority of your keys carry real ambiguity: buttons, short labels, anything where the same English word could be a noun or a verb. Attach screenshots to those and leave the rest.
• Capture them as you review. Screenshots attach to keys at any time, so the coverage builds while your team is reviewing rather than in a separate project nobody has time for.

What to check once it lands

• Segment count. Compare the number of memory entries you exported against what arrived. A large drop usually means language-pair filtering during export.
• Do-not-translate entries. Verify a handful by running a language and confirming your product name came back untouched.
• Round-trip fidelity. Export one file immediately after import and diff it against the original. Structure, keys and ordering should match; if they do not, tell us, because that is a bug rather than a limitation.
• Placeholders. Check that {count}-style variables and markup tags survived. They are the most common casualty of any migration, whoever runs it.

Leaving again

Everything above works in reverse, and it is deliberately not our business what you do with it. You can export your translations in the format you imported and your memory as TMX, whenever you want, with no export fee and no notice period. A platform that makes leaving expensive is telling you what it thinks of its own product.

Start free, no credit card →