Here at cap hpi we’re in the process of transforming and expanding the business, taking the solid base as the UK market leader and expanding out into new countries to become a global vehicle data provider. This means we need to build a lot of new applications to deliver the data that we’re providing to our customers. This is nothing new, we’ve been providing our UK customer base with great applications that allow them to consume our data for years.
What is new is that now that we’re moving into the global marketplace, we can no longer assume that all our customer base can or will want to use our applications in English. Well, we could, but that would not be particularly helpful in allowing us to build long lasting customer relationships with businesses around the globe.
At cap hpi, the focus is on delivering best-in-class applications written in the latest technologies; SQL Server databases, microservice tiers in C# or Java plus a front end in the latest version of Angular.
Each of the apps that we want to deliver should be simple to provide in each different language with the minimum of development and delivery overhead, be quick and easy for the end user to use to change their language and be available to change at the click of a button.
As this is a UI concern, we investigated what Angular 2+ support is provided for i18n, and what external libraries are out there – we disregarded commercial products as the licensing costs could quickly spiral and become prohibitive.
It came down to a choice between the native support in the current Angular core and the ngx-translate package.
Current Out-of-the-box Angular Support
This provides full localisation and translation, through setting up a locale for the app and then applying a translation file to the angular templates. Implementation is straightforward, with the simple addition of attributes within the page templates, and translations for the text being stored in XLFF files for each language.
The big limitation with the native i18n support is that it does not allow for changing language on the fly – it requires a separate version of the app for each language to be built and deployed side-by-side, alongside some kind of method to allow the user to swap between each instance when they chose the appropriate language.
- Part of core Angular functionality.
- Straightforward to implement.
- Handles translations and localisation of dates/numbers/percentages and currencies.
- Support for different pluralization rules
- Does not offer on the fly switching between languages easily (this should be implemented in Angular 6.x)
- Additional overhead and potential risk of building and deploying each separate language version of the app.
- XML based translation files – XLFF – another syntax to learn.
This is a 3rd party package that allows on the fly internationalisation of templated text within an Angular app. It provides a translation service which can be used in a variety of ways for maximum flexibility in providing translations. The text for the various translations are held in JSON files, one for each language to be supported.
On the downside, it doesn’t deal specifically with the localisation of dates/numbers/percentages and currencies. It is no longer in active development, as the developer who wrote it has now been recruited onto the Angular Core team to build in similar i18n support to the core in an upcoming version.
The translation service is flexible and can be used as a service, a pipe or a directive with straightforward template substitution of key – value pairs in a JSON file.
- On the fly translation with multiple languages supported within the same instance of the site.
- Straightforward to implement.
- Flexibility in how it can be used.
- Single application to deploy.
- Easy to maintain.
- JSON based translation files.
- Separate module – not part of the Angular core.
- Need to separately handle translations and localisation of dates/numbers/percentages and currencies.
- Package no longer actively developed – developer is now working as part of core Angular team to implement functionality as core into a forthcoming version of Angular. No guarantee that it will be implemented the same when this arrives.
The current out of the box Angular support does not offer a readily maintainable solution – trying to maintain a separate app per language is neither desirable or sustainable, this is a killer blow for this option.
Using ngx-translate has now been successfully validated with a proof of concept application. It is straightforward to implement, easy to maintain and is performant, offering a slick and easy to use way to quickly and easily translate applications. There is a recommendation to adopt ngx-translate here at cap hpi as our method for providing i18n internationalisation for our apps.
It should be noted that this decision will need to be reviewed when an upcoming version of Angular is released that contains the new internationalisation code within the Angular core.