Repository navigation
[i18n] plans #16477
Description
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
#andoffset#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
Activity
jlutz777 commentedon May 9, 2017
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 commentedon May 9, 2017
@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 commentedon May 11, 2017
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:
the string at one place to be effected at multiple place?
provided key? (same as i asked above).
ocombe commentedon May 11, 2017
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 commentedon May 22, 2017
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 commentedon May 22, 2017
@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 commentedon May 31, 2017
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 commentedon Jun 1, 2017
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 commentedon Jun 23, 2017
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 commentedon Jun 26, 2017
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 commentedon Jun 26, 2017
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 commentedon Jun 26, 2017
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
figuerres commentedon Jun 28, 2017
possibly a component could have an attribute that tells the system / compiler that it needs a service.
that service then takes and id and a locale and returns the localized text / markup.
all the localized text is stored on the server as resources that the service can read from.
if a component does not have the attribute no locale run-time.
if the component has it then it call get the localized data at run-time.
the compiler just builds the data files and hooks up the service.
this seems to me like a good way to handle the most common need for most applications and not require sites to build and maintain multiple copies of the same app.
actra-gschuster commentedon Jun 28, 2017
I had that idea, too.
Problem is that translations can contain bindings and thus would open the system for code injection when loading translation files from external resources.
Additionally, a compiler would be needed to resolve those bindings dynamically depending on the translation.
IMHO a valid solution could be the way I implemented as POC (see comment above) to inline translations at compile time, just in a more elegant, integrated way.
Both problems mentioned above would be eliminated, only downside I can imagine is possibly the bundle size, it'd grow to "plain bundle" + (translated html-size * locales).
That could be lowered by only
ng-switching thei18n-tagged html instead of the whole document but still there's a problem fori18n-*-tags.292 remaining items
petebacondarwin commentedon Feb 12, 2020
Just to be clear. What I meant to say is that lots of people have come up to me to say that they absolutely need live language changing in their application. But when you dig into the reasons it turns out that they don't. I am not saying that there are no scenarios that require this, but in my experience over the last year, I have come across very few.
Question: why would a user need to switch languages when the go to a particular form on your app?
vekunz commentedon Feb 12, 2020
I don't think that live switching is necessary also. How often do you change the language of a website? Usually one time, at maximum. And for this one time, a page reload is not that critical. As @petebacondarwin said, almost all scenarios for live switching are not relevant real-world scenarios but only "nice to have."
ewok-janitor commentedon Feb 12, 2020
I absolutely need runtime translations. Our customers need to be able to edit and update translations in the field, not just on the build server. So, runtime, as opposed to compile time.
Actual switching of languages after page load is a nice-to-have.
Karasuni commentedon Feb 12, 2020
You might be right that it not a solid requirement. I might attempt deploying translations on load but it will completely transform the user experience of the applications that are currently able to switch language dynamically - without reload or changing position in the page - with an external library. Translations has been a heated topic for a very long time.
I do have an important question: Can translation files be loaded asynchronously? All my translations are stored in a database as being able to update them without a rebuild is important.
ocombe commentedon Feb 12, 2020
yes they can be loaded asynchronously, but you need to delay the start of your application until they have been loaded
TomDemulierChevret commentedon Feb 12, 2020
Technically you can reload the entire app and still keep the user where he was.
You "just" need to have a state-driven app (with ngxs, ngrx, or any other state management library) which is stored somewhere and retrieved at startup.
The only trick would be to keep scroll position but that's feasable too.
mlc-mlapis commentedon Feb 12, 2020
@petebacondarwin I have to say that I agree with you. I don't know real end-users (except testers in dev phase) who are switching an app permanently between languages when using it. Sure, they do it probably at the beginning if they open it in a different one somehow, but later, it's a rare case.
vekunz commentedon Feb 12, 2020
I'm not sure, what your customers are doing, but "editing of translations live in the production website" doesn't sound like a common scenario.
Alir3z4 commentedon Feb 12, 2020
I don't see changing language live (without page reload) to be such a deal breaker.
Changing a language for a user happens only once;
Think about it, how many times you have changed your phone language ? probably once or you just rolled with the default language.
Watching for language changes in order to do live change without page reload brings a lot of performance penalty for something that is barely used for the lifetime of a user.
Ultimately, in comes down to 3 things for me;
albyrock87 commentedon Feb 12, 2020
@Karasuni
You can fetch translations async and only then load the angular app.
See my comment above on how to load the app.module asynchronous using
import(...).tatsujb commentedon Feb 12, 2020
personally I use Wikipedia to figure out what the title of a movie that I know was "translated" to in another language.
in this day and age being bilingual or trilingual is more than commonplace (aside from within the US, no harm meant).
the user might want to live switch languages it's completely plausible. the Wikipedia example is a positive result of having enabled this, I don't see why we should stifle other potential uses before they live to see the light of day under the pretext of performance.
even ocombe's ngx-translate which has to be the tantamount example for you guys of "poor performance translations" ran perfectly fast enough for the everyday user.
I personally am trilingual and I can't settle on using one language : all languages are beautiful to me
with all that said I cannot agree with this :
vekunz commentedon Feb 12, 2020
Wikipedia is the worst example of this because the different languages of an article are actually independent articles. Normally you don't need different languages of the exact same site. Even if you work quadrilingual.
And if you actually need live switching, you can use either the workaround with the custom translation pipe, which @petebacondarwin mentioned or the new tool from @ocombe.
petebacondarwin commentedon Feb 12, 2020
OK, so I don't think that this is really the best place to have this discussion. I am concerned that (while have all been very reasonable so far) we might slip into negative discussion. I'm afraid that for the foreseeable future the Angular framework will not provide a live language switching solution out of the box.
I feel that the value of this issue has run its course. I have moved the open issues and PRs that are linked in the description of this issue to https://github.com/angular/angular/milestone/101 and I am going to close and lock this PR.
If you have new issues of feature requests then please do open up a new issue and tag me in it.