In the following post I will show how to combine i18n translations with Ahead of Time Compilation (AoT).
i18n deals with Internationalization of content and is important for multilingual applications.
I will not cover the details of Angular's implementation of i18n since it's already covered well in the documentation.
Instead I will focus on how to combine i18n with AoT application bundles.
For the purposes of this post I have created a trivial sample application where I will show how to use i18n to display a greeting in Norwegian and English.
I am only showing the app.component for brevity, but the whole source can be found here
app.component.ts
app.component.html
As you can tell the template is annotated with i18n attributes. This is how we tell the i18n compiler that this is a template where we want to leverage i18n functionality.
The default language is English, so any English text is inlined directly in the template.
Loading Translations
Many existing translation frameworks take a standard data driven approach to translations. Based on language preferences you typically load a separate json file per language. The json file contains language “keys” that are used to look up translated text.
Basically translations are treated like regular data from any random api.
In Angular's AoT based i18n implementation things work differently.
Instead of deploying a single application and pull in json files at runtime, the approach is to deploy a separate application per language. In my example I will have two different applications. One for English and a second application for Norwegian.
Don't be scared, but this means supporting 20 languages requires 20 different versions of your application.
Luckily all the applications can be generated from a single code base. In the next section I will show you how.
English Version
The first thing we have to do is build an application based on the default language.
This is pretty straightforward since all you have to do is AoT compile the application without even worrying about i18n
AoT compile the application using a standard ngc command:
ngc will AoT compile the application, but we still need to create an application bundle. In this example I will be using Rollup, a popular bundler.
Rollup needs some configuration in order to process the application. It's easiest to specify the necessary Rollup configurations in a configuration file. I have put the configuration in rollup-config.js
rollup-config.js
The Rollup config is pretty standard. But you may have noticed that I didn't specify a dest attribute. I intentionally left that out of the config since I want to reuse it for all languages.
Instead I will pass in an override from the command line.
The Rollup process can be triggered by running:
The -o setting specifies where to output the English version of the application.
It may be preferable to combine the AoT and Rollup steps into one by &&-ing them together like so:
Other languages
We now have a working English version of our application.
To generate applications for the other languages we have to make a few additional tweaks.
The first step is to generate an xlf file where we can specify translations for each language by running:
This outputs a generic xml template that can be used to create language specific versions. In my sample I only have one version called messages.no.xlf. This is where Norwegian language translations will go.
The next step is to tell ngc to generate a new application where the English default text is overridden with Norwegian translations.
This is very similar to regular AoT compilation, but we have to pass the location of the xlf file to the compiler.
This can be by passing the following switches:
The combined command is as follows:
I also specified a different -o switch. This tells Rollup to output the Norwegian version of the application in a different location.
Application
We now have two different versions of the application. The first one supports English text and the second one supports Norwegian text.
How do you know which version to run?
Multilingual applications must have a concept of language preference. Based on the user's language preference you decided which version to serve at runtime.
The actual implementation of this depends on your tech stack. I have created a sample to illustrate a very simple approach.
My UI is super simple, but it allows the user to toggle a greeting between English and Norwegian.
In this example I am basing the language preference on a query string parameter. Based on the query string I dynamically load the correct application bundle.
My index.html ends up looking like this:
I have deployed a live demo of this here
In the demo the conditional loading was done client side. A great alternative would be to generate the src url of the application bundle on the server. Depending on your server technology you could use server rendering to resolve the url of a script tag.