What is translation vendor lock-in?

It is a situation where leaving your translation provider would cost you the translations, the translated URLs or the workflow you built on top of them. Typical signs are translations stored only on the vendor's servers, no complete export, and translated pages that exist only while you pay.

Which export format should I ask for?

Ask for more than one. XLIFF carries source and target text between tools, PO files suit software that uses gettext, JSON is convenient for web apps, CSV is easy to inspect, and TMX preserves translation memory. Which is best depends on where you plan to import the data.

Does an export guarantee I can keep my translated URLs?

No. A text export covers strings, not routing, slugs, redirects or hreflang markup. You need to confirm separately whether your translated URLs and metadata can continue working on your own site if you leave.

How do I test an exit path before signing up?

Translate a small sample, export it, then import it into a different tool or a plain file on a test site. If the data round-trips with source, target, keys and context intact, the exit path is real. If you cannot try it before buying, treat that as a warning.

Avoid Translation Vendor Lock-In: Exit Paths and Formats

Translation vendor lock-in means that leaving a provider would cost you your translations, your translated URLs or the workflow built around them. You can reduce the risk by checking, before you commit, that you can export every string with its source text and keys, that your translated URLs can keep working on your own infrastructure, and that the export imports cleanly somewhere else. The test is practical: try the exit before you need it.

What does translation lock-in look like?

Lock-in is rarely stated in a pricing page. It shows up in how the product stores and serves your content.

Translations stored only on the vendor's servers. The text never exists in your database or repository. If the account ends, so does the text.
No export, or a partial export. Some tools export only the strings you edited by hand, or only one language at a time, or omit context such as keys and screenshots.
Translated pages that exist only through the vendor's runtime. If your French page is produced when a vendor script or proxy runs, the page disappears when the script does. This is the same dependency discussed in what happens when your translation provider goes down, but permanent.
URLs that vanish. If the translated slugs and paths are defined only in the vendor's system, search engines may have indexed URLs that stop resolving. Redirects and canonical signals are then yours to rebuild.
Proprietary formats. An export that only the same vendor can read is not a real export.
Translation memory kept private. Reused phrases, glossaries and approved terms represent real paid work. If they cannot leave with you, you pay for them again.
Contract terms. Ownership of translations, data retention after cancellation and the notice period are all things to read in the terms. We cannot tell you what any particular contract says; check the one you are signing.

Why does lock-in matter more for SEO than for content?

Moving text between tools is mostly a data task. Moving a live multilingual site is a search task. Google's multilingual guidance asks that each language version has its own crawlable URL and that versions reference each other with hreflang. If a migration changes those URLs without redirects, or drops the alternates, you can lose the signals you built. The practical lesson is that exit planning has two layers: the strings, and the URLs, redirects, canonical and hreflang markup around them. Our multilingual SEO checklist lists the elements to keep intact.

What export formats should you look for?

No single format is best. The right question is whether the export is complete and whether the tool you want to move to can read it.

XLIFF

XLIFF (XML Localization Interchange File Format) is an OASIS standard for carrying localizable text between the steps of a localization process, with a focus on lossless interchange. XLIFF 2.1 became an OASIS Standard on 13 February 2018. A file has an <xliff> root with a required version and srcLang, one or more <file> elements, and within them <unit> elements containing <segment> elements, each pairing a <source> with an optional <target>. It is the closest thing to a common interchange format between translation tools. Check which XLIFF version a vendor writes, because tools differ in what they read.

PO and POT (gettext)

PO files come from GNU gettext. Each entry pairs a msgid (the original string) with a msgstr (the translation), and may carry translator comments, tool-generated comments, source references and flags. Plural entries add msgid_plural and numbered msgstr[N] lines. A POT file is the template: source strings without translations, from which a PO file for each language is created. PO is the usual format for WordPress themes and plugins, so it is a natural exit format if you run WordPress; see making WordPress multilingual for where it fits.

#: templates/cart.php:12
msgid "Add to cart"
msgstr "Ajouter au panier"

JSON

JSON is not a localization standard, it is a general data format. Web applications commonly store translations as key-value JSON, one file per language, but the exact shape (flat or nested keys, how plurals and placeholders are written) varies between frameworks. JSON is easy to diff and to serve as a static file. Its weakness is that there is no standard place for context, status or translator notes, so ask what an export includes.

CSV

CSV is a plain table, typically columns for key, source and one column per language. It opens in any spreadsheet and is convenient for review and for bulk edits. It carries little structure: no markup protection, awkward handling of commas and line breaks, and encoding pitfalls, so confirm the export uses UTF-8 and that non-Latin scripts survive a round trip.

TMX

TMX (Translation Memory eXchange) is an XML format for exchanging translation memory between tools. Its purpose is to lose little or no critical data in the exchange. A file has a <header> and a <body> of <tu> translation units, each holding a <tuv> per language (identified by xml:lang) that wraps the text in a <seg>. The latest version is 1.4b, from 2005, and a 2.0 draft from 2007 was never finished. TMX stores paired text, not page structure, so it complements an XLIFF or JSON export rather than replacing it.

Format	Best for	Carries	Watch out for
XLIFF	Moving between translation tools	Source, target, units, markup	Version differences between tools
PO / POT	gettext-based software, WordPress	Source, translation, comments, references	Plural rules and header settings
JSON	Web apps, static bundles	Key-value strings	No standard for context or status
CSV	Review, bulk edits	Flat table	Encoding and escaping
TMX	Reusing translation memory	Aligned source/target pairs	No page or key structure

How do you evaluate an exit path before you buy?

Do it with a real, small sample rather than a sales answer.

Translate a representative sample. Include a page with markup, a product with variables, and a string with a plural.
Export everything. All languages, including strings you edited by hand and any glossary or memory.
Inspect the file. Are keys, source text and placeholders intact? Is the encoding UTF-8?
Import it somewhere else. A different tool or a plain JSON file on a staging site is enough. If it renders, the exit works.
Check the URL story. Ask how translated slugs, redirects and hreflang would continue if you left, and test it on staging.
Read the cancellation behaviour. What happens to translated pages and data the day after the plan ends, and for how long can you still download?

Pre-purchase checklist

[ ] I can export all strings, in all languages, without contacting support.
[ ] The export includes keys or identifiers, source text, translations and status.
[ ] At least one open format (XLIFF, PO/POT, JSON, CSV) is supported, and translation memory exports as TMX.
[ ] Translations are stored somewhere I control, or can be copied there automatically.
[ ] Translated URLs and hreflang can be kept on my own site after cancellation.
[ ] Pages do not depend on the vendor's runtime to display translated content, or a fallback to cached/static files exists (see static translation bundles).
[ ] The contract says who owns the translations and what happens to the data on cancellation.
[ ] I have run a test export and import successfully.

Whether the translations came from machines, people or both also affects how much they are worth to you; machine vs human vs hybrid translation explains why. We are building ResilientLang with this in mind, designed so that translation files live on your own site, but it is not released, so treat it like any other tool and run this checklist on it too.

Key takeaways

Lock-in is about where your translations and translated URLs live, and whether you can take both with you.
Ask for complete exports in open formats and test an import before you pay.
XLIFF is for interchange, PO/POT for gettext software, JSON for web apps, CSV for review and TMX for translation memory; none replaces your URL and hreflang plan.
A runtime dependency on a vendor's script turns an outage or a cancelled plan into a loss of translated pages.
Read the contract for ownership and post-cancellation access; we cannot tell you what it says.

Sources

XLIFF Version 2.1 (OASIS Standard) – XLIFF purpose, status and element structure
Translation Memory eXchange (TMX) – TMX origin, version 1.4b and structure (secondary source; the specification is hosted by GALA)
GNU gettext manual: PO files (older copy) – PO entry structure, msgid and msgstr, comments, plural entries (an older mirror of the manual; the POT template convention is common practice)
Managing multi-regional and multilingual sites – separate URLs per language and why they matter