Localize Explore Single Page App

Executive Overview

When a non-English speaker uses the DX, the non-English assets on the explore page are displayed with English headers, footers, buttons, and column text. For example, below is a Japanese language Asset page and Asset card. Notice the English text that comes from the Single Page App (SPA).

Figure - A Japanese Asset Page with English Column Text, Headers, and Footers.

Figure - A Japanese Asset Card with English Column Text, Headers, and Footers.

When this problem is examined closely, we see that there are two issues at play:

We need to provide a translation of the Explore page and the SPA into the official DX site languages which are English and Japanese (with others in the future).
We need to be able to help Automators to find Assets in local languages independent of the language they use on the DX Web Site.

2. User Personas

For this feature, the following personas need to be considered:

Contributor - this is the DX Developer who creates and submits the Asset.
Automator - this is the DX Developer who will look for Assets and download the ones that meet their need.
Approver - this is the individual that will approve the Asset for publication.

3. User Stories

3.1 Local Language SPA

Providing the ability to localize the DX Explore Single Page Application (SPA) would finish off the translation of the DX site. This is something for consideration but could be done either in parallel or after the localization of Assets.

There are a number of resources available for the I18N (Internationalization) and L10N (Localization) of Angular SPA. These include:

NGX-Translate is the most popular I18N/L10N library for Angular and can be found at http://www.ngx-translate.com/
Native Angular I18N/L10N features can be found at https://angular.io/guide/i18n
I18next is a generic JavaScript I18N/L10N library can be found at https://www.i18next.com/

Below are independent assessments of the three solutions presented on the blog at https://phrase.com/blog/posts/best-libraries-for-angular-i18n/.

Based on the information, all three candidates are solid. Although there is no specific preference, it seems that using native capability is a solid, long-term choice.

3.1.1 NGX-Translate

NGX-translate is a mature and viable solution. Initially, it was created to overcome problems with the Angular built-in i18n module, such as support for the JSON format and the ability to write custom loaders. It has evolved into a full-scale extensible solution and many developers are fond of it.

However, the built-in Angular I18N module is steadily evolving and now it can be seen as a production-ready solution. NGX-translate was initially viewed as a temporary solution. It means that sooner or later, the built-in module will supersede it. Interestingly enough, the creator of Ngx-translate joined the Angular team, so he works on the built-in i18n support now.

Therefore, while Ngx-translate is still a good candidate to pick, you should bear in mind the information above. If you are planning to develop a long-term application, sticking to this third-party solution may not be the best option. Why? Well, it simply may not be maintained anymore. One exception would be Ionic 4 apps, which are not compatible with the built-in module at all. In this case, your options are quite limited.

3.7.2 Native Angular I18N

The built-in Angular I18N module is convenient and feature-rich. It is more complex and has fewer bugs than Ngx-translate (citing the words of the library’s creator). It would seem an obvious choice to many developers because it’s the solution you already have — there’s no need to add some third-party libraries. This module allows you to easily extract your translations, use JiT compiler, and serve localized apps with very little effort…

However, this module does have some downsides. First of all, there is no easy way to write a custom translation loader (and this was one of the reasons Ngx-translate was initially created). Next, there is uses XML. Not sure about you, but I find this format quite ugly and too heavy in contrast to JSON or, say, YAML. Of course, this is not really a problem but rather a matter of taste. Still, it might be important for some people.

But, honestly, even taking these disadvantages into consideration, I would still recommend starting a new project with the built-in i18n module. I am pretty sure it will become a de-facto standard very soon. And, believe me, this tool is not complex at all: You’ll get the grip in no time.

3.7.3 I18next

I18next is a powerful and popular solution for Angular I18N/L10N, but I would still call it the least preferable of all three presented here. I18next is quite complex and heavy, and probably you would not want to add even more complexity to an Angular app. After all, it already has loads of dependencies, configurations, etc. My point is: There are basically no features that I18next supports and the built-in I18n Angular module doesn’t. So if there is a relatively little difference, why would you make your life more complex and include some third-party I18n framework? Especially, when it relies on a separate plugin (maintained by another person) to make everything working? To me, it seems a bit strange.

Still, if you are a big fan of I18next and have used it a lot in your other projects, then this solution is still viable. For instance, it is one of my first candidates when translating pure JS apps. It does have many useful features, and, in contrast to Ngx-translate, it is not planned to be superseded any time soon.

4 Migration and Organizational Issues

Once the SPA is Internationalized (I18N) we need to immediately create a Japanese L10N file using the localization company. We also need to consider if we want to do the same for any other languages in connection with the other product groups.

Additionally, the language selector will need to be placed on the Explore Page.