The translation pipeline: strings, files & memory

Translation starts with a handoff, and the handoff has a shape. What travels is a record per message, never your code: a stable key (cart.summary), the source string with its variable parts as placeholders, and a context note saying where the string appears and what the ambiguous words mean. Everything downstream (file export, translation memory, review, import) operates on that record. A string that never becomes a record, because code assembles it from fragments at runtime, is invisible to the whole pipeline.

That is why concatenation is the core failure here, not a style nit. "You have " + count + " item" + (count === 1 ? "" : "s") contains no translatable sentence: an extraction tool finds four shards, the plural logic is English-only, and the fragment order is frozen into code that German or Japanese would need to rearrange. The externalized version moves all of that into the string (You have {count, plural, one {# item} other {# items}} in your cart.), where a translator can rewrite grammar and order without touching your program.

Context travels too, because the translator sees your strings without your screen. Archive alone could be a noun (a folder) or a verb (a button). The note "button label, verb" is the difference between a correct translation and a QA bug three weeks later. Every string change after handoff re-opens files in every target language, so teams declare a string freeze before a release goes out for translation. Teams batch late wording edits instead of trickling them.

Three formats carry that record, one per era of the problem. gettext PO is the Unix veteran: a bilingual text file of msgid (source) and msgstr (translation), with context in #. extracted comments and #: source references. Plurals get msgid_plural, indexed msgstr[0], msgstr[1], and so on, plus a Plural-Forms: header that declares how many forms the language has and which index a count maps to. German declares nplurals=2; plural=n != 1, so 1 fills msgstr[0] and everything else msgstr[1]. A Russian PO file declares more forms and more indexes. The grammar knowledge lives in the file header, outside your code.

XLIFF 2.0, an OASIS standard, is the tool-interchange format: xliff → file → unit → segment → source/target, built so any translation tool can open any exporter's strings. Context gets a first-class element (<notes><note>), and inline codes sit inside <ph> placeholders so a translator cannot edit them by accident. What it has no room for is plurals. The 2.0 core defines no plural element, so an ICU plural message either travels whole inside <source> or the tool splits it into one unit per category. ICU JSON is the other shape you will meet, the runtime's own: the message carries its grammar inline ({count, plural, …}), but plain JSON has nowhere to put a comment, so context needs a sidecar convention. That is why so many pipelines export JSON to XLIFF for the translator round-trip, then import the result back.

The translation memory is why any of this bookkeeping pays. A TM stores every segment pair ever translated, and the tool scores each new source segment against it. An identical segment is an exact match: the tool reuses the stored translation, typically billed at a small fraction of the new-word rate. A close one is a fuzzy match: the tool pre-fills the stored translation for editing at a graduated discount (gettext's #, fuzzy flag is the same move in PO form). Below roughly 75, editing a bad suggestion costs more than translating fresh, so it counts as new words. The thresholds are industry convention, and no standard fixes them. Every CAT tool computes its own score. The economics are universal: reworded sentences cost money in every target language, and consistent source English is a budget decision.