XLIFF and Translation File Formats — Vocabulary

The trans-unit is the atom of XLIFF — it pairs a source string with its translation and carries metadata the translator needs.

Example XLIFF 1.2 snippet: <trans-unit id="btn.submit" resname="btn.submit"><source>Submit</source><target state="translated">Enviar</target></trans-unit>. Key attributes: id (unique within the file), resname (the string key in your app), translate="yes/no" (mark non-translatable segments). The state attribute on <target> tracks workflow: new → needs-translation → translated → final. CAT tools and TMS platforms use this state to drive the translation workflow.

Key vocabulary:
• trans-unit — XLIFF element pairing source string with target translation; the basic unit of localization
• resname — attribute on trans-unit identifying the string key in the source application
• translate="no" — marks non-translatable segments (brand names, code snippets, placeholders)

In gettext .po files, msgid = the source string (lookup key), msgstr = the translation. An empty msgstr means the string is not yet translated.

Example: msgid "Welcome back, %(name)s" / msgstr "Bienvenido de nuevo, %(name)s". The msgid is used verbatim in the application code: gettext("Welcome back, %(name)s"). At runtime, gettext looks up the msgid in the compiled .mo file and returns the msgstr for the active locale. If msgstr is empty (""), gettext returns the msgid — so the source language text is displayed, which is the correct fallback behaviour. The .pot file (template) contains only msgids with empty msgstrs; translators fill in the msgstrs.

Key vocabulary:
• msgid — the source string in .po files; used as the lookup key at runtime
• msgstr — the translated string; empty string means untranslated (falls back to msgid)
• .pot file — .po template with all msgids and empty msgstrs; distributed to translators

TM leverage is the business metric for how much existing translation can be reused — directly impacting cost and speed.

When a new batch of content arrives for translation, the TMS compares each segment against the TM. The report shows: 100% matches (exact) — typically charged at 0-25% of the full rate or free; fuzzy matches (85-99%) — translator reviews and edits; new content (below 85% or no match) — full translation cost. A release with 70% TM leverage means 70% of the content was already translated before — only 30% is new work. Engineering decisions that affect leverage: keeping existing string keys stable when wording changes slightly vs. creating new keys (new key = no TM match even if translation is the same).

Key vocabulary:
• TM leverage — percentage of new content matching existing TM segments; reduces cost and time
• 100% match — exact segment match in TM; typically free or very cheap to translate
• fuzzy match — 85-99% similar; translator edits the existing translation; charged at reduced rate

ARB's @key metadata entries are what distinguish it — they give translators context and format information alongside the source string.

Example ARB entry: {"welcomeMessage": "Welcome, {name}!", "@welcomeMessage": {"description": "Greeting shown on the home screen", "placeholders": {"name": {"type": "String", "example": "Maria"}}}}. The @welcomeMessage entry tells the translator: this string has a placeholder called {name} that will be a person's name. CAT tools and TMS platforms use these metadata entries to protect placeholders from accidental translation and provide context. Supported by Crowdin, Phrase, and Lokalise natively.

Key vocabulary:
• ARB — Application Resource Bundle; JSON format for Flutter/Dart localization
• @key metadata — description and placeholder info for translators; prevents placeholder corruption
• ICU MessageFormat in ARB — plural and select patterns written directly in ARB string values

translate="no" is the XLIFF mechanism for protecting strings that must not be changed — brand names, URLs, code snippets, and technical identifiers.

Without this protection, translators may attempt to translate brand names (translating "Firebase" into a localized term) or modify API endpoint strings (changing /api/v1/users to /api/v1/utenti in Italian). These modifications break the application. The translate="no" attribute causes CAT tools to lock the segment and auto-populate the target with the source value. It is also useful for segments that are already in the target language (e.g., an English error code that should appear in English in all locales). XLIFF 2.0 uses the same attribute on <segment> elements.

Key vocabulary:
• translate="no" — XLIFF attribute locking a segment against translation; CAT tool displays it as read-only
• non-translatable segment — brand names, URLs, code, technical IDs that must appear unchanged in all locales
• locked segment — CAT tool term for a segment the translator cannot modify; source is copied to target