Explain Internationalization in Angular in Angular

99 / 100

Advancedintermediate

Internationalization in Angular

Explain Angular's built-in i18n approach (marking text, locale data, build-time translation) and how it compares to runtime i18n libraries.

Angular ships with a built-in internationalization (i18n) system, and understanding both how it works and how it differs from popular runtime-based i18n libraries (like ngx-translate) is a recurring interview topic for any team building products for multiple locales/languages, since the trade-offs between the two approaches are genuinely significant and worth being able to articulate clearly.

Angular's built-in i18n is like printing an entire separate edition of a book for each language, professionally typeset and proofread ahead of time; a runtime i18n library is like a single universal book with a live, page-by-page translation overlay that can be swapped instantly, at the cost of occasionally being caught without a translated overlay for a specific page.

Key Concepts

Angular's built-in approach is fundamentally build-time: you mark translatable text in templates with the i18n attribute (or i18n-attributeName for translating element attributes), extract all marked text into a translation source file (ng extract-i18n, producing an XLIFF or similar format) for translators to work from, and then Angular's build process produces a completely separate, fully-compiled application bundle per locale — meaning a French build genuinely contains only French text baked directly into the compiled templates, with no runtime translation lookup or switching mechanism at all.

i18ni18n-attributeNameng extract-i18n

This build-time approach has real advantages: no runtime translation-lookup performance cost, no risk of a missing translation key silently showing a raw key string to users, and translated text benefiting from Angular's full compile-time optimization the same as any other template content — but the corresponding cost is that switching a user's language requires reloading an entirely different build of the application (typically via a different URL path or subdomain per locale, like /fr/ versus /en/), which rules out any in-page, no-reload language switcher.

/fr//en/

Runtime i18n libraries flip this trade-off: translations are loaded as data (typically JSON) and looked up dynamically at render time via a pipe or directive, which enables instant, no-reload language switching and doesn't require a separate build per locale, at the cost of a small runtime lookup overhead and the real risk of missing/mistyped translation keys only surfacing as a bug at runtime rather than being caught at build time. A well-rounded interview answer states the deciding factor plainly: choose Angular's built-in i18n when per-locale builds and build-time correctness matter more, and a runtime library when instant language switching without a page reload is a hard product requirement.