[i18n] plans

[ocombe]

Here is the list of features / fixes planned for i18n.

If you want new i18n features to be added to Angular, don't hesitate to ask below and I'll let you know if that's feasible and if you should open an issue for it.
If you have a bug, open an issue (no need to discuss about it here).

For Ivy

Note: runtime translations and most of the new features will only be available with ivy

Features

• Runtime i18n (one bundle for all locales with AOT) - [working on it]
• ID migration tool (for when we break ID generation) - [PR fix(compiler): fix i18n IDs generation, add a migration tool #15621]
• Use translation strings outside of a template - i18n: Able to use translation strings outside a template #11405 - [working on it]
• Generate the same ID for xmb/xlf - ng-xi18n should generate same IDs when using xlf or xmb format #15136 [breaking change PR fix(compiler): fix i18n IDs generation, add a migration tool #15621]

Issues

• Ignore ph/ICU expressions when generating i18n ids - i18n translation duplicated #15573 [breaking change PR fix(compiler): fix i18n IDs generation, add a migration tool #15621, blocked]

Not prioritized

Features

• Allow ICU messages in attributes - ICU messages don't work on attributes #21615 [blocked, requires an update of the parser]
• Improve Html Parser (add a new INTERPOLATION_TOKEN to the lexer output for interpolations) - Html Parser improvements #9340
• Opt out of translation (use translate="false" attribute) - I18n: Opting out of translation #7814
• I18nPluralPipe should localize numbers when using "#" - I18nPluralPipe should localize numbers when using # #11761
• ICU plural format (add offset & #) - [i18n] ICU plural format - support # and offset #9117 [blocked, requires "Allow escaping ICU messages - [i18n] escaping in ICU message #9286"]
• Implement ICU ordinal messages
• Auto detect TRANSLATIONS_FORMAT - I18n: remove TRANSLATIONS_FORMAT #11695
• Providing TRANSLATIONS at NgModule level - Feature Request [i18n]: Support providing TRANSLATIONS at NgModule level #11431
• Add scientific number pipe - Add scientific number format pipe #18276
• Opening the API - [PR feat(compiler): open the serializer API for i18n #14281]
• Throw during i18n extraction if two different contents have the same @@id - Throw during i18n extraction if two different contents have the same @@id #18272

Issues

• Ignore leading and trailing spaces - i18n ignore leading and trailing spaces #13114
• allow numbers for select-icu - i18n: numbers for select-icu fail to compile (template parse error) #17799
• Allow escaping ICU messages - [i18n] escaping in ICU message #9286 [blocked, requires an update of the parser]
• Template Parser: Error when passing object literal as pipe parameter - False-Positive: Parser Error: Missing expected } at the end of the expression #9571

[jlutz777]

I would like to see the ability to do dynamic bindings in aot mode. There are two use cases in particular to back up why this should be added to the roadmap.

The first is the basic use case where you don't want separate applications for every language. This requires some sort of redirect logic outside the app and doesn't allow dynamic changing of the language without a complete reload of the site.

The second is the case where you are embedding the app in mobile using cordova. As far as I know your choice is to jit, thus slowing down the site, creating a separate app for every language, or including every language in the app (which of course bloats it). None of these are good options. It seems Ionic doesn't use i18n, and I wonder if this is the reason why.

[ocombe]

@jlutz777 those are 2 valid use case, this subject has been discussed internally lately and I've been advocating for that too. It is not easily possible yet given how i18n and AoT work in Angular, but it might be in the future once we get the new compilation process for AoT in v5.
I'll add it to the roadmap once/if we have something official and concrete about it.

[vishalbhardwaj26]

I am working on Electron + Angular 2 app and now trying to add support for Localization for multiple langauge using i18n feature with Angular. Actually extraction of template-string and converting them in different language file formats are clearly documented, though I am still not able to much clear about and looking for:

• Can i switch language dynamically? or do I need to build application separately for different language.
• Can I manage/consolidate all strings at one place (in the form of key/value pair), so that I can change
  the string at one place to be effected at multiple place?
• Can i access the localized file from anywhere other than template to get specific language string with
  provided key? (same as i asked above).

[ocombe]

Points 2 and 3 will be resolved with the feature "Use translation strings outside of a template - #11405".
For the point 1 see the answer I gave to @jlutz777 above. For now you still have to build the app in multiple languages, or use JIT which can dynamically load translations at bootstrap (it's not switching at runtime, but it's still better than having to bundle it x times).

[figuerres]

the UI language used in an application should be something that does not require building multiple versions of the same application. this should not in any way be a "compiler" issue. if it is then the compiler is flawed. the issues should be one of making the application design such that the text can be loaded from a data file at run time. that should be done with a module / library that can be loaded and used like any other. do not make that a compiler function at all.

[ocombe]

@figuerres it's something that will be changed in the future, no promises yet but we are aware of this issue and we are looking at possible solutions, using an external file is one of them

[rjcorwin]

Hi @ocombe - It looks like we're probably going to use i18n in Angular for our application. Are there any features in the docs you think might become deprecated or have breaking changes in the coming months? Any info would be greatly appreciated. And thanks again for the DVD!

[ocombe]

Hey @rjsteinert! Glad to know that!
There's only one breaking change planned for now, it's the auto generation of IDs. The method will change and the IDs will not match anymore, but there will be a cli migration tool to update your translation files (and a parameter that you can use to only migrate when you're ready).

[actra-gschuster]

I googled a lot about this topic today and am wondering if there could be a "simple" solution like replacing i18n-tags with a call to a service instead of the translation?

Current:
<span i18n>Hello world</span> => rendered to <span>Hello world</span>

My idea:
<span i18n>Hello world</span> => rendered to <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

This way the real translation could be done dynamically in AOT as the service could be filled from an API, file etc. and even switching locales wouldn't be much more than i18nservice.setLocale('de-DE') with loading a new source.
Text extraction with xi18n-tool would still work as before and we could leverage the message ids generated anyways to use as index for the translation service.
The current implementation would also still work flawlessly as ngc could simply look for a "--use-i18nservice" flag and otherwise compile as until now.

One problem I can currently identify is the injection of the i18nservice into each and every component as it has to exist in the components context to be callable, but that should be solvable in one way or another.

Any thoughts on this?

[ocombe]

It is one of the things that we're considering yes, there's still the problem of how to treat code blocks inside of those translations when the compiler isn't available at runtime (AOT). It would mean that we cannot use angular components/directives/pipes inside of translations...

[actra-gschuster]

Yes, didn't think of that.
I'm currently developing a POC/workaround that inlines all translations into the HTML at the build step (webpack), wrapping them into ng-containers with ng-switch.
For i18n-attributes it's using a directive setting them on nativeElement.
The translations themselves also get "rendered" then to replace all those <x id=".. "/> placeholders.

It's ugly but works...can't wait for ng to support it natively.
Will publish the POC later this week, maybe it can be of use for your further conception.

[actra-gschuster]

I came up with a "solution" that suits my needs until there's an implementation.
The pre-loader now renders HTML for all locales before handing over to the compiler, works like a charm so far.

Repo: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng-i18n-aot-loader