Angular Translations: a novel approach

Using ngx-translate for language files

Introduction

I’ve been playing around with how to handle translations and for now, I’ve had to settle for the wrong way… That is to say, managing translation files within an application (vs. what I think is the appropriate way, an API abstraction powered by a third party CMS, etc.). Managing translations within an app means developers have to likely roll out changes to translations, a build is involved, testing, etc. etc. — dev cycles. Managing these types of concerns isn’t the responsibility in all likelihood of your application.

For the purposes of this article, I went out in two phases, one is to load the translations up front and a second (and upcoming phase — support on the fly language translations.)

As I developed the solution for translations, I discovered several nuanced aspects that forced me to come up with a solution to handle translations a slight bit differently than as prescribed by the ngx-translate library. The prescribed way to manage translations that load asynchronously is to using async piping.

This technique will respond to changes asynchronously without doing any manual coding. The problem we ran into was primarily with setting up our third party grid column header grids — where we needed to provide translations in components and not directly in the views.

Component Translation File

I decided to create a translation file for each component (and as part of a schematic) and I have a build script that will concatenate all these translations into one file (my plan is to break this down by module and let each lazy module loaded handle all their own translations but for the sake of this discussion, it’s not required).

Script for concatenating language files throughout the app

Problem

In some cases, we need to add translations via the component, and not in the view as such:

Example of fetching translations via the component — this is sync, since all is preloaded.

This means we need upon component initialization, immediate synchronous translations available for the grid column headers (third party @grapecity wijmo flexgrid) component. The synchronous aspect conflicts however (using the instant method) with the loading of language file translations as it’s an asynchronous process. How do we solve this without the contention of race conditions getting in the way of our translated output?

Solution

I decided to add a resolver to our lazy loaded routes to load all translations into memory prior to route resolution — in an observable $cache.

The TranslationsResolver will make an http call via a get and load the results into $cache — the translations are now instantly available within the related module (using the instant method via the ngx translation service). The ‘OTP’ get is the root node of the translations — i.e. the ***.en.lang.json file has a root OTP node which means it will load everything into memory — if this file gets really big, there might be some optimizations to better handle this as all the translations may not be needed per a given lazy loaded module — but it’s loaded once per module and the result is cached -YMMV

Translations resolver will load translation file into memory.

Below is a route resolver than can be explicitly applied to any lazy loaded module as needed. It will cache the translations per route resolution.

Add the resolver for the lazy loaded route.

Conclusion

You may now use translations in your applications with impunity — no need to wait or worry about the async process of loading the translation files into memory. You can now use the instant method below without any worry that a translation won’t be available, on demand.

Use the instant method to load translation without any async wait time.

Part 2: Handling on demand / on the fly language translations — re-bind new translations per user input directed language selection.