[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 #15621]
• Use translation strings outside of a template - #11405 - [working on it]
• Generate the same ID for xmb/xlf - #15136 [breaking change PR #15621]

Issues

• Ignore ph/ICU expressions when generating i18n ids - #15573 [breaking change PR #15621, blocked]

Not prioritized

Features

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

Issues

• Ignore leading and trailing spaces - #13114
• allow numbers for select-icu - #17799
• Allow escaping ICU messages - #9286 [blocked, requires an update of the parser]
• Template Parser: Error when passing object literal as pipe parameter - #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.

[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.

[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).

[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).

[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.

[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

[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

[rjsteinert]

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!

[rjsteinert]

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).

[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?

[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...

[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]

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

[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

[figuerres]

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.

[figuerres]

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]

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 the i18n-tagged html instead of the whole document but still there's a problem for i18n-*-tags.

[actra-gschuster]

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 the i18n-tagged html instead of the whole document but still there's a problem for i18n-*-tags.

[figuerres]

well here is the thing; some times you have limits ....

from a practical stand point it might be better to not have that, you can have a chunk of text that can be given in multiple languages. end of the story.

you need to have a data bound chunk ? ok but that is not inside the internationalized text, it has to be separate. you can still use html and css to style and format the result. but you can't embed or combine them in every way you can think of.
like say a div or a p tag can have a number of spans one span is the text and another span is a bound date the text span is bound to the i18n locale service, the date is bound to some date service the two spans are in a paragraph tag that formats them.

Keep it simple, make it work for 95% of all users first then figure out the edge cases.

[figuerres]

well here is the thing; some times you have limits ....

from a practical stand point it might be better to not have that, you can have a chunk of text that can be given in multiple languages. end of the story.

you need to have a data bound chunk ? ok but that is not inside the internationalized text, it has to be separate. you can still use html and css to style and format the result. but you can't embed or combine them in every way you can think of.
like say a div or a p tag can have a number of spans one span is the text and another span is a bound date the text span is bound to the i18n locale service, the date is bound to some date service the two spans are in a paragraph tag that formats them.

Keep it simple, make it work for 95% of all users first then figure out the edge cases.

[actra-gschuster]

I don't see that as an edge case, it's business as usual.
Angular is a business-grade framework so many, if not all, of the i18n-users will require bindings, or at least pluralization and selects, inside texts.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
How would you solve that with separated strings?
Simple answer: you can't, as you cannot know the rules of the target language, not every language follows the format 'greeting', 'gender', 'name'.

Separating those chunks would:

• kill context, the translator wouldn't get the meaning of the complete sentence
• merging the chunks in the right order by CSS isn't possible, you'd have to specify rules for each and every translation, so either the CSS-guy needs to know the target languages or the translation-guy needs to know CSS, neither is acceptable.

The core i18n works in angular as expected and is usable for business-grade apps, the only thing missing apparently is AOT-compatibility, so I don't get your standpoint why a powerful, working system should be replaced by something not half that capable requiring multiple times the work to get it done.

[actra-gschuster]

I don't see that as an edge case, it's business as usual.
Angular is a business-grade framework so many, if not all, of the i18n-users will require bindings, or at least pluralization and selects, inside texts.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
How would you solve that with separated strings?
Simple answer: you can't, as you cannot know the rules of the target language, not every language follows the format 'greeting', 'gender', 'name'.

Separating those chunks would:

• kill context, the translator wouldn't get the meaning of the complete sentence
• merging the chunks in the right order by CSS isn't possible, you'd have to specify rules for each and every translation, so either the CSS-guy needs to know the target languages or the translation-guy needs to know CSS, neither is acceptable.

The core i18n works in angular as expected and is usable for business-grade apps, the only thing missing apparently is AOT-compatibility, so I don't get your standpoint why a powerful, working system should be replaced by something not half that capable requiring multiple times the work to get it done.

[ocombe]

We have a meeting tomorrow to find a solution to this problem.

[ocombe]

We have a meeting tomorrow to find a solution to this problem.

[figuerres]

@ocombe glad to hear this, i hope this leads to some good stuff for a future release of Angular , here at work we are really loving how most of it works for our development needs!

[figuerres]

@ocombe glad to hear this, i hope this leads to some good stuff for a future release of Angular , here at work we are really loving how most of it works for our development needs!

[Tryptich]

@ocombe , is it possible to change language without relaoding the entire document ? I explain :
I'm on page named "about" but when I change the language, i'm redirected to main entry page of my application .

[Tryptich]

@ocombe , is it possible to change language without relaoding the entire document ? I explain :
I'm on page named "about" but when I change the language, i'm redirected to main entry page of my application .

[actra-gschuster]

While working on my i18n-app I also came across the known "bug" that external stylesheets from e.g. @angular/material (residing in node_modules) could not be resolved and thus the ng-xi18n-tool failed.
I implemented an "ignore missing files"-HostContext for the extraction tool, also as POC but added as PR #17845 to have it linked to the main repo.

@ocombe as you seem to be very active on this topic would you mind having a look at the PR and giving feedback?

[actra-gschuster]

While working on my i18n-app I also came across the known "bug" that external stylesheets from e.g. @angular/material (residing in node_modules) could not be resolved and thus the ng-xi18n-tool failed.
I implemented an "ignore missing files"-HostContext for the extraction tool, also as POC but added as PR #17845 to have it linked to the main repo.

@ocombe as you seem to be very active on this topic would you mind having a look at the PR and giving feedback?

[ocombe]

Thanks, I'll take a look at it.

[ocombe]

Thanks, I'll take a look at it.

[RAJKUMAR-PATTNAIK]

It's been few days searching a way to implement internalization on whole project including dynamic data, but found nothing concrete. Can you please suggest me something else that at least help me for the time being. Thank you.

[RAJKUMAR-PATTNAIK]

It's been few days searching a way to implement internalization on whole project including dynamic data, but found nothing concrete. Can you please suggest me something else that at least help me for the time being. Thank you.

[jean-philippe-bousselin]

Hello @ocombe! Can we have a follow up concerning the point raised by @jlutz777 (about dynamic bindings, thus not having one app per language) ?

Thanks a lot for your work!

[jean-philippe-bousselin]

Hello @ocombe! Can we have a follow up concerning the point raised by @jlutz777 (about dynamic bindings, thus not having one app per language) ?

Thanks a lot for your work!

[ocombe]

@vicb is working on it right now, it'll be in 5.x (not 5.0 but most likely 5.1)

[ocombe]

@vicb is working on it right now, it'll be in 5.x (not 5.0 but most likely 5.1)

[trotyl]

@ocombe Should the checklist be updated? I can see some of them already been merged in newer versions. And that'll better reflect your hard works. 😃

[trotyl]

@ocombe Should the checklist be updated? I can see some of them already been merged in newer versions. And that'll better reflect your hard works. 😃

[ocombe]

yes, good idea, I'll update it
edit: updated

[ocombe]

yes, good idea, I'll update it
edit: updated

[mattiLeBlanc]

Finally, looking at couple of the formats. XLIFF 2 looks pretty nice, bit cleaner than 1.2. The XMB looks confusing, horrible documentation that looks like it was styled in 1995.
I did notice when using XLIFF 2 that the TARGET text was not rendered like it does in version 1.2.

Have you guys looked at .pot and .mo files? Pretty simple format and also used by translated with POEdit tool.

[mattiLeBlanc]

Finally, looking at couple of the formats. XLIFF 2 looks pretty nice, bit cleaner than 1.2. The XMB looks confusing, horrible documentation that looks like it was styled in 1995.
I did notice when using XLIFF 2 that the TARGET text was not rendered like it does in version 1.2.

Have you guys looked at .pot and .mo files? Pretty simple format and also used by translated with POEdit tool.

[shobhit12345]

i need to convert my application in English and Spanish using toggle button . Did all the changes ,working file separately . i have created two build under .dist/en and dist/es .Can anyone tell me , what i need to do for deployment and how to switch between both the build ?

What i need to do on click of toggle button

[shobhit12345]

i need to convert my application in English and Spanish using toggle button . Did all the changes ,working file separately . i have created two build under .dist/en and dist/es .Can anyone tell me , what i need to do for deployment and how to switch between both the build ?

What i need to do on click of toggle button

[Toub]

@shobhit12345 please post your assistance request on https://stackoverflow.com

[Toub]

@shobhit12345 please post your assistance request on https://stackoverflow.com

[mattiLeBlanc]

@zverbeta the solution I posted at #24549 doesn't work when I build with --prod. Kind of obvious since I am using require which probably is not available?
Without the --prod flag the solution does work because it includes webpack related code?

[mattiLeBlanc]

@zverbeta the solution I posted at #24549 doesn't work when I build with --prod. Kind of obvious since I am using require which probably is not available?
Without the --prod flag the solution does work because it includes webpack related code?

[zverbeta]

@mattiLeBlanc I found this lib https://github.com/ngx-translate/i18n-polyfill and it resolve my problem with dynamic text

[zverbeta]

@mattiLeBlanc I found this lib https://github.com/ngx-translate/i18n-polyfill and it resolve my problem with dynamic text

[shobhit12345]

Hi , how we can can translate dynamic values(interpolation) using i 18 n .

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

[shobhit12345]

Hi , how we can can translate dynamic values(interpolation) using i 18 n .

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

[Gahen]

Hey! There's any place where we can track and/or help with the tasks that are been worked on? (the ones with working on it tag)

[Gahen]

Hey! There's any place where we can track and/or help with the tasks that are been worked on? (the ones with working on it tag)

[marcelnem]

Any updates on a time frame for releasing of a beta version of runtime i18n?

[marcelnem]

Any updates on a time frame for releasing of a beta version of runtime i18n?

[Kamshak]

@marcelnem i can't find the comment but iirc ocombe mentioned that the runtime i18n is merged for ivy so you can likely test it on the v7 beta with the ivy flag

[Kamshak]

@marcelnem i can't find the comment but iirc ocombe mentioned that the runtime i18n is merged for ivy so you can likely test it on the v7 beta with the ivy flag

[ocombe]

The runtime part is done but not the compiler part, which means that you can't test it yet with ivy

[ocombe]

The runtime part is done but not the compiler part, which means that you can't test it yet with ivy

[fabiopcarvalho]

Hi, I am working with Angular 6 i18n. I am working with multi-language, meaning that I followed cookbook:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!#ng-xi18n

My current implementation is using AOT, so I generated a messages.xlf file and a messages.pt.xlf. Everything is working fine, when I run

ng serve --configuration=pt

I get texts translated as expected. But I feel like there is something very wrong with the way it works. I am probably missing something. As far as I understood, everytime I add a new string to be translated and mark it with i18n attribute, i need to re-generate the messages.xlf file running "ng xi18n" and then update manually the messages.pt.xlf. The xlf file also holds the line number where the source is, so it looks like if i it changes the row, i will also need to re-generate the file and manually update my pt file.

<context context-type="linenumber">16</context>

That doesn't look smart, it will give me a lot of extra work to keep it working. Do you understand my concern? Am I missing something?
I know Angular 7 i18n will have a big update with Ivy being incorporated, should i wait for it?

Best Regards,
Fabio

p.s. I really hope this is not off topic, but if you feel it is, please give me at least a direction. Where should I be asking this for example? Or if there is a link that might answer my doubts.

[fabiopcarvalho]

Hi, I am working with Angular 6 i18n. I am working with multi-language, meaning that I followed cookbook:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!#ng-xi18n

My current implementation is using AOT, so I generated a messages.xlf file and a messages.pt.xlf. Everything is working fine, when I run

ng serve --configuration=pt

I get texts translated as expected. But I feel like there is something very wrong with the way it works. I am probably missing something. As far as I understood, everytime I add a new string to be translated and mark it with i18n attribute, i need to re-generate the messages.xlf file running "ng xi18n" and then update manually the messages.pt.xlf. The xlf file also holds the line number where the source is, so it looks like if i it changes the row, i will also need to re-generate the file and manually update my pt file.

<context context-type="linenumber">16</context>

That doesn't look smart, it will give me a lot of extra work to keep it working. Do you understand my concern? Am I missing something?
I know Angular 7 i18n will have a big update with Ivy being incorporated, should i wait for it?

Best Regards,
Fabio

p.s. I really hope this is not off topic, but if you feel it is, please give me at least a direction. Where should I be asking this for example? Or if there is a link that might answer my doubts.

[mjschranz]

@fabiopcarvalho One thing I've realized is it's wise to use custom IDs for every single translation to make it easier to keep track of changes in HTML layout.

But yes, you will need to routinely update the translations file.

[mjschranz]

@fabiopcarvalho One thing I've realized is it's wise to use custom IDs for every single translation to make it easier to keep track of changes in HTML layout.

But yes, you will need to routinely update the translations file.

[PedroJesusRomeroOrtega]

@fabiopcarvalho I use xliffmerge to help me with the merge of the translations

[PedroJesusRomeroOrtega]

@fabiopcarvalho I use xliffmerge to help me with the merge of the translations

[fabiopcarvalho]

Perfect, i used that tool and It worked great. I am also using the ids and they do help. Thanks for the reply !!

…

On Thursday, August 30, 2018, Pedro Romero ***@***.***> wrote: @fabiopcarvalho <https://github.com/fabiopcarvalho> I use xliffmerge <https://github.com/martinroob/ngx-i18nsupport> to help me with the merge of the translations — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16477 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk> .

[fabiopcarvalho]

Perfect, i used that tool and It worked great. I am also using the ids and they do help. Thanks for the reply !!

…

On Thursday, August 30, 2018, Pedro Romero ***@***.***> wrote: @fabiopcarvalho <https://github.com/fabiopcarvalho> I use xliffmerge <https://github.com/martinroob/ngx-i18nsupport> to help me with the merge of the translations — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16477 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk> .

[kylelix7]

Allowing ICU messages in attributes is critical for accessibility because attribute aria-label is used a lot in accessibility. Is there an issue for followup?

[kylelix7]

Allowing ICU messages in attributes is critical for accessibility because attribute aria-label is used a lot in accessibility. Is there an issue for followup?

[ocombe]

I don't think there is an issue for that, could you open one? I'm working on ICU expressions for ivy right now, so I added a TODO, but a feature request would be better

[ocombe]

I don't think there is an issue for that, could you open one? I'm working on ICU expressions for ivy right now, so I added a TODO, but a feature request would be better

[LastDragon-ru]

@ocombe, #21615

[LastDragon-ru]

@ocombe, #21615

[ocombe]

Perfect thanks (the Github search is really bad!)!

[ocombe]

Perfect thanks (the Github search is really bad!)!

[Sef1995]

Will we be able to lazy load the translation files from an external source for example via HTTP with the new version of i18n?

[Sef1995]

Will we be able to lazy load the translation files from an external source for example via HTTP with the new version of i18n?

[AhmadShahid]

@ocombe as you said you are working on Runtime i18n (one bundle for all locales with AOT). it's been over a year we are waiting. when we can expect that feature is it coming in angular 7 release?

[AhmadShahid]

@ocombe as you said you are working on Runtime i18n (one bundle for all locales with AOT). it's been over a year we are waiting. when we can expect that feature is it coming in angular 7 release?

[ocombe]

@Sef1995 it's one of the things that we want to enable
@AhmadShahid it'll require ivy which will be released independently from v7 and ivy won't be ready for the release of v7. Some parts of ivy are already in v6 behind a flag, but it's not feature complete and you should not use it in a real world application. We don't have a release date for ivy yet.

[ocombe]

@Sef1995 it's one of the things that we want to enable
@AhmadShahid it'll require ivy which will be released independently from v7 and ivy won't be ready for the release of v7. Some parts of ivy are already in v6 behind a flag, but it's not feature complete and you should not use it in a real world application. We don't have a release date for ivy yet.

[aaniceto]

@ocombe a quick question, if we implement i18n as of today (angular6), which will require different builds (one for each language), is the effort lost when ivy gets out and i18n runtime? I mean the way i18n would be implemented now will differ from what's coming? Trying to plan some sprints in advance and prioritise work. Thanks

[aaniceto]

@ocombe a quick question, if we implement i18n as of today (angular6), which will require different builds (one for each language), is the effort lost when ivy gets out and i18n runtime? I mean the way i18n would be implemented now will differ from what's coming? Trying to plan some sprints in advance and prioritise work. Thanks

[ocombe]

We don't want to create breaking changes if we can avoid it. The ids of the extracted translations might change as we fix bugs that we've had for a long time, but we'll offer a migration tool. I cannot say for certain that it'll be 100% compatible, but expect most things to work the same, with new options available to use if you want.

[ocombe]

We don't want to create breaking changes if we can avoid it. The ids of the extracted translations might change as we fix bugs that we've had for a long time, but we'll offer a migration tool. I cannot say for certain that it'll be 100% compatible, but expect most things to work the same, with new options available to use if you want.

[mattiLeBlanc]

@ocombe a quick question, if we implement i18n as of today (angular6), which will require different builds (one for each language), is the effort lost when ivy gets out and i18n runtime? I mean the way i18n would be implemented now will differ from what's coming? Trying to plan some sprints in advance and prioritise work. Thanks

Hi, you can use the webpack require to load in files dynamically (as a temp workaround) with one build:
Example can be found here: #24549 (comment)

You do have to build with --prod --aot=false, since AOT=true will remove the webpack stuff.

[mattiLeBlanc]

@ocombe a quick question, if we implement i18n as of today (angular6), which will require different builds (one for each language), is the effort lost when ivy gets out and i18n runtime? I mean the way i18n would be implemented now will differ from what's coming? Trying to plan some sprints in advance and prioritise work. Thanks

Hi, you can use the webpack require to load in files dynamically (as a temp workaround) with one build:
Example can be found here: #24549 (comment)

You do have to build with --prod --aot=false, since AOT=true will remove the webpack stuff.

[sheikalthaf]

@ocombe Hi,

A7 release candidate is out, As promised shall we test the runtime translation?. Runtime i18n (one bundle for all locales with AOT). How can i test this. Please help

Thanks

[sheikalthaf]

@ocombe Hi,

A7 release candidate is out, As promised shall we test the runtime translation?. Runtime i18n (one bundle for all locales with AOT). How can i test this. Please help

Thanks