How does Angular support internationalization (i18n)?

Angular provides robust, built-in support for internationalization (i18n), enabling developers to create applications that can be adapted to different languages and regions without requiring engineering changes. This includes features for translating text, handling pluralization, selecting gender-specific messages, formatting locale-specific data, and generating locale-specific application builds.

Core Concepts and Tools

Angular's i18n capabilities are primarily driven by the i18n attribute in templates, the @angular/localize package, and the Angular CLI. Together, these tools provide a streamlined workflow for marking translatable content, extracting messages, managing translation files, and generating locale-specific application bundles.

• i18n attribute: Used in component templates to mark elements or attributes for translation.
• @angular/localize: A runtime library that provides APIs for parsing and managing localized messages.
• Angular CLI: Offers commands like ng extract-i18n to extract translatable messages and ng build --localize to build the application for multiple locales.

Translating Template Text

The most fundamental aspect of Angular i18n is marking text within HTML templates for translation using the i18n attribute. This attribute can be applied to any HTML element to identify its content as translatable.

<h1 i18n="@@welcomeMessage">Welcome to our application!</h1>
<p i18n>This paragraph will be translated.</p>
<button i18n="Proceed button|Action to continue with the form">Proceed</button>

You can also include an optional meaning and description for context, and an explicit message ID using @@ID for better management of translation strings. Attributes can also be marked for translation using i18n-attr syntax, e.g., i18n-title.

Pluralization and Selection

Angular provides special syntax for handling pluralization (i18n-plural) and gender/choice selection (i18n-select), which are crucial for natural-sounding translations in different languages.

• i18n-plural: Allows defining different messages based on a numeric value (e.g., 'no items', 'one item', 'many items').
• i18n-select: Enables choosing messages based on a category string value (e.g., 'male', 'female', 'other').

<!-- Pluralization example -->
<p i18n-plural="{ 
  '=0': 'No messages', 
  '=1': 'One message', 
  'other': '{{count}} messages' 
}"
  >Number of messages: {{ count }}</p>

<!-- Selection example -->
<p i18n-select="{ 
  'male': 'He is a developer.', 
  'female': 'She is a developer.', 
  'other': 'They are a developer.' 
}"
  >User gender: {{ gender }}</p>

Date, Number, and Currency Formatting

Angular's built-in pipes (DatePipe, NumberPipe, CurrencyPipe) automatically format data according to the current locale's rules. This ensures that dates, numbers, and currencies are displayed correctly for the user's region.

• DatePipe: Formats dates based on locale (e.g., 'MM/DD/YYYY' vs. 'DD/MM/YYYY').
• NumberPipe: Formats numbers, including decimal and thousands separators.
• CurrencyPipe: Formats currency values with correct symbols and decimal places.

<p>Today's Date: {{ today | date:'fullDate' }}</p>
<p>Formatted Number: {{ 12345.678 | number:'1.2-2' }}</p>
<p>Price: {{ 99.99 | currency:'EUR':'symbol':'1.2-2' }}</p>

To enable full locale-specific formatting, locale data must be registered in the application's root module using registerLocaleData from @angular/common/locales.

Translation File Management and Deployment

After marking all translatable content, the Angular CLI extracts these messages into a source translation file using ng extract-i18n. This file, typically in XLIFF (recommended), ARB, or JSON format, is then handed over to translators.

• Extraction: ng extract-i18n generates a base translation file (e.g., messages.xlf).
• Translation: Translators create locale-specific translation files (e.g., messages.fr.xlf, messages.de.xlf).
• Building: The Angular CLI is configured to build a separate version of the application for each locale using ng build --localize. This command takes the translated files and injects them into the application, creating distinct bundles for each language (e.g., /en/, /fr/).

This build-time approach ensures optimal performance, as all translations are embedded directly into the application bundle, avoiding runtime lookups or additional network requests for translation data.