skip to content

In Angular i18n, what does ng extract-i18n produce, which file formats can it write, and how do you create each language's translation file?

level: juniorimportance: should knowfreq 35%

answer

  1. one source-language file for the app
  2. XML is the default family
  3. one extraction format, one translation format
  4. copy, rename by locale, fill in targets

basics

~20 s

ng extract-i18n collects every marked message into one source-language file, messages.xlf in XLIFF 1.2 by default. It can also write XLIFF 2.0, XMB, JSON or ARB. Each language gets a copy, such as messages.fr.xlf, whose targets a translator fills in.

solid answer

~40 s

`ng extract-i18n` compiles the app, collects every `i18n`, `i18n-<attr>` and `$localize` message, and writes one **source-language file**; by default that is `messages.xlf` in XLIFF 1.2. Other supported formats are XLIFF 2.0, XMB (whose translations come back as XTB files), a simple JSON map and ARB. To add a language you copy the source file, rename it with the locale, such as `messages.fr.xlf`, keep it under something like `src/locale`, and send it to the translator, who adds a `<target>` next to each `<source>` without touching the IDs. The build then merges one translation file per locale. The format is mostly a question of what the translation tooling reads: XLIFF carries descriptions, meanings and source locations as notes, while the simple JSON format carries only ID-to-text pairs.

code

bash · 7 lines
bash
# Source-language file: messages.xlf (XLIFF 1.2) at the project root
ng extract-i18n

# Create the per-locale copies the translators will fill in
mkdir -p src/locale
cp messages.xlf src/locale/messages.de.xlf
cp messages.xlf src/locale/messages.ja.xlf

go deeper

for a junior

Recall that extraction writes one source file, messages.xlf in XLIFF 1.2 by default, and that each language gets a renamed copy with targets filled in.

for a middle

Compare the formats by what they carry: XLIFF and ARB keep descriptions and meanings, JSON keeps only ID and text, and XMB pairs with XTB.

for a senior

Explain how re-extraction and diffing against each translation file fits a release process, and why the chosen format must match the translation tooling.

for a principal

Weigh format choice against vendor tooling, review workflow and diff readability, and decide who owns keeping translation files in step with releases.

## Where extraction fits Angular's i18n workflow has four stages: **mark** text in templates and code, **extract** the marked messages, **translate** one copy per language, and **merge** the translations into per-locale builds. Extraction is the hand-off point between developers and translators, so its output format decides what translators actually see. ## What `ng extract-i18n` produces The command builds the application, finds every marked message (`i18n` attributes, `i18n-<attr>` attributes and `$localize` tagged strings) and writes them to a single **source-language file**. With no options, that is `messages.xlf`, in **XLIFF 1.2**, at the project root. Each message becomes one translation unit keyed by its **message ID**: the custom `@@id` if one was given, otherwise an ID generated from the text and meaning. ## The supported formats | Format | Extension | Shape | Carries description/meaning? | | --- | --- | --- | --- | | XLIFF 1.2 (default) | `.xlf` | `<trans-unit id>` with `<source>` and later `<target>` | Yes, as `<note>` elements, plus source locations | | XLIFF 2.0 | `.xlf` | `<unit id>` with a `<segment>` holding `<source>`/`<target>` | Yes, in `<notes>` | | XMB | `.xmb` for extraction, `.xtb` for translations | `<msg id>` with `desc` and `meaning` attributes | Yes | | JSON | `.json` | `{ "locale": ..., "translations": { id: text } }` | No, ID and text only | | ARB | `.arb` | ID-to-text entries plus `@id` metadata | Yes: `description`, `x-meaning`, locations | Points worth stating in an interview: - **XLIFF is the agency format.** Computer-assisted translation tools read it natively, and the notes give translators context. - **XMB is asymmetric.** You extract `.xmb`, but the translated files you feed back to the build are `.xtb`. - **JSON is minimal.** It is easy to diff and edit by hand, but translators lose the descriptions and meanings you wrote while marking. - The format is chosen once per project and should match what the translation-management system imports. ## Creating a translation file per language The documented procedure is deliberately simple: 1. Run `ng extract-i18n` to produce the source file. 2. Copy it once per target language. 3. Rename each copy with its locale ID: `messages.fr.xlf`, `messages.de.xlf`. 4. Keep the copies together, conventionally in `src/locale`. 5. Send each copy to its translator. In XLIFF the translator adds a `<target>` element beside each `<source>`: ```xml <trans-unit id="cartCheckoutButton" datatype="html"> <source>Proceed to checkout</source> <target>Zur Kasse gehen</target> <note priority="1" from="description">Primary button on the cart page</note> </trans-unit> ``` Two rules the translator must follow: - **Never change the `id`.** The ID is how the build matches a translation to a message; an edited ID is an orphaned translation plus a missing one. - **Keep placeholders.** Elements like `<x id="INTERPOLATION"/>` stand for code-driven values and markup; they can move within the sentence but must not be deleted or renamed. ## Keeping files current Extraction is repeated every time marked text changes. The new source file is compared with each translation file: units whose IDs are new need translating, and units whose IDs disappeared are stale. That comparison is exactly why message-ID stability matters, and why teams usually automate it in the translation-management system rather than by hand. ## Summary - One source file per app, one translation file per locale. - XLIFF 1.2 by default; XLIFF 2.0, XMB/XTB, JSON and ARB are alternatives. - Translators fill targets, never IDs, and keep placeholders. - The build reads the per-locale files and merges them into localized output.

  • Why can a team that picked the JSON format regret it once an agency is involved?
    The JSON translation format stores only message IDs and text. The descriptions and meanings developers wrote while marking never reach the translator, so short or ambiguous strings lose their context, and the agency's tooling usually expects XLIFF anyway. XLIFF or ARB keep that metadata.
  • In the XMB workflow, which file do you give the Angular build as the German translation?
    An XTB file. XMB is the extraction format listing source messages; the translated counterpart for each language is an `.xtb` file, and that is what the build reads for the locale.

saying these in an interview costs you the question

  • Each component gets its own translation file
  • JSON output keeps descriptions and meanings for translators
  • Translators may rename IDs to something more readable
  • XMB files are also the translated files you merge back
  • Extraction only needs to run once, at project start