i18n and Angular defaults hurt

Up until now, most of my work on Angular has either been prototyping work, or fixing bugs and working with business logic. So, I've been spared the hassle of localizing Angular UIs.

My first thought was already that a series of static files providing the localizations was a janky solution.

Some context; I've worked at 2 companies where localization was a part of the process. And in both cases, the companies used in-house solutions. In both cases, the localizations could be updated dynamically and from a database and one even had a nice process for getting the localizations to flow from dev providing the initial, default values to a dedicated team performing the translations to having them approved and finally pushed to production.

Needless to say, I was a bit confused when I extracted my i18n translations, created separate json files per locale and fired up my app and nothing happened.

Read the documentation a bit and realize that the default use case is to pre-compile the translations and run a separate version of the app PER LOCALE. Just wow.

I can appreciate that precompiled is faster. I really can. However, translations ARE NOT A CODE CONCERN. Your build should NOT be dependent upon the compilation of static text on a language by language basis.

Of course, the root of the problem is a bit bigger than that. Why is this default? Well, because the translations are stored in one massive file per language. By compiling the localizations at build time you are able to, indirectly, load only the translations you need as you need them. If you were to load the localization file at runtime, you need to load the whole application's localizations. And that could be a bit much depending the scale of the application.

Another flawed process is the tooling itself. The expectation is that you will tag what you want to localize, extract it, perform the localizations and store them locale specific files. Great! Or at least, it is the first time. When you need to add, change or remove text... how do you know which keys need to be addressed and how?

I'll wager that there are some 3rd party tools out there to help manage. Realistically, static files are not a great experience for a site or web application of any size. Which probably explains why the companies I have worked with, including the one using Angular for front end development, are not using i18n for internationalization. 

To play the devil's advocate though, I will admit, localization processes can differ greatly from company to company and would typically require an external database to manage the localizations in an efficient fashion. Also, i18n is a bit more flexible than the default implementation.

That being said... what you get out of the box... sucks.

We already have a localization service at the current company. I figure that we'll just end up writing a pipe and a caching layer for that in the long run for our Angular apps and then throw this i18n crap in the rubbish bin.