search

angular / angular

Deliver web apps with confidence 🚀
https://angular.dev
MIT License
94.71k stars 24.68k forks source link

[i18n] plans #16477

Closed ocombe closed 4 years ago

ocombe commented 7 years ago

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

Not prioritized

Features

ocombe commented 6 years ago

I need to update the roadmap but it's a bit confused right now (even for me). This feature in particular is clearly not a priority, don't expect us working on it anytime soon

Karamuto commented 6 years ago

@ocombe Yeah this would be great. We too are very interested in the runtime i18n, as its the only blocking point for us. Could you maybe give a guess about its completion in %?

Thank you very much for your hard work!

ofuangka commented 6 years ago

@ocombe

This feature in particular is clearly not a priority, don't expect us working on it anytime soon

Could you clarify what feature you're talking about here? I don't want to make any assumptions.

ocombe commented 6 years ago

@ofuangka the feature "Ignore leading and trailing spaces" is not a priority. @Karamuto hard to guess for now, we're working on it right now

hotspurs commented 6 years ago

@ocombe Could you please share your milestone about Runtime i18n (one bundle for all locales with AOT)

Now we on decide to using xi18n tools or using 3rd party libriaries for huge multilanguage project. We hope to be able to use canonical tooling, but, aware of it's too raw.

Also we would like to be able to split xlf files (one file per module), is it possible?

ghost commented 6 years ago

up up will runtime i18n be released in Angular 6?

thanks and happy coding!

Karamuto commented 6 years ago

Losing hope here, that this will be finished in time, as there is not much time left and there were no realeses so far regarding this feature.

The version 7 release would be pretty late for us.

sandangel commented 6 years ago

@Karamuto #22654 I think it will be release in v6, but they have to finish Ivy first.

ocombe commented 6 years ago

We should have a hello world working this week, but with minimal features (no ICU support for example). But since it's released with ivy which is behind a flag, we'll keep working on it and release as soon as we finish a new feature, there's no need to wait for v7

Karamuto commented 6 years ago

@ocombe That sounds great! It doesn't need to be complete with ICU from the get go. If it will advance in the latter realeses of v6 this is completly fine by us.

Thanks for the great work again!

sarunint commented 6 years ago

@Karamuto see #22654 for a sneak peak!

kekraft commented 6 years ago

Dumb question: Is there a way to have an i18n directive for string based inputs to custom components. An example when forwarding aria-labels:

I wrap a custom button that does cool things: <custom-button i18n-input=aria-label [aria-label]="Does customy button things">

Custom button's template just does: <button [aria-label]="aria-label" (click)="customyStuff">

Is there a way to do this already?

eppsilon commented 6 years ago

@kekraft I think with static inputs you can use the i18n attribute syntax:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

In the component:

<button [attr.aria-label]="ariaLabel">Some button</button>
pmccloghrylaing commented 6 years ago

@ocombe do you need contributors to get any of the runtime i18n work done?

keatkeat87 commented 6 years ago

Yeah ! v6 published ~~~ any update here ?

sandangel commented 6 years ago

the example i18n angular 6 is here https://github.com/angular/angular/pull/23660

MrCroft commented 6 years ago

@sandangel did you mean simply "everything" or "everything that is checked", from the plans at the beginning of this thread? Was really looking forward to having a single application, I think that's one of the most important things. Went to the #23660 you linked and then reached https://pr23660-e12f469.ngbuilds.io/guide/i18n But there it still says:

When you internationalize with the AOT compiler, you must pre-build a separate application package for each language and serve the appropriate package based on either server-side language detection or url parameters.

Is it possible to have a single application for multiple languages or not yet?

JanEggers commented 6 years ago

@MrCroft looks like runtime i18n is still work in progress. I read it like you some more options but not one bundle for all localizations :(

ocombe commented 6 years ago

We have a working hello world but it's for the new renderer (ivy) only and since ivy is not ready for prime time, you will have to wait for that unfortunately :(

fetis commented 6 years ago

@ocombe so, unless we don't have Ivy in production (probably around v7) we will not have runtime translations. is this correct?

feloy commented 6 years ago

@ocombe are the hello world and ivy stuff publicly available? It would be cool to try and understand this new i18next implementation😃

actra-gschuster commented 6 years ago

@fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

ocombe commented 6 years ago

@fetis yes :( @feloy yes, the simple hello world is here: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n but very minimal you can find the tests here: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts and some refactoring + extraction here: https://github.com/angular/angular/pull/22931

vamshee-m commented 6 years ago

@ocombe we are trying to implement i18n in our application, but wherever I read about it I see that we need one messages.xlf file per language. Wouldn't that become a overhead to maintain considering a complex applications with various customer facing screens etc.. I am looking to see if we can breakdown the messages file per component or per module ? Is that supported already ?

fetis commented 6 years ago

@stickler-v this file it's just transport for your strings to your translations software. don't consider to translate it manually.

vamshee-m commented 6 years ago

I see, where do we have actual text in different languages though ? We need to manage this text manually in contrast to have translators doing it.

vamshee-m commented 6 years ago

Sorry, but i am little lost. Based on the original documentation here https://angular.io/guide/i18n. src/app/app.component.html will only have english text. messages.fr.xlf is the file that has french text but it's auto generated and not advisable to touch it.

If I want to have app.component.html rendered using french text instead of english, where would I specify french messages "Bonjour" etc. ?

fetis commented 6 years ago

@stickler-v it's really offtopic, please create a question on StackOverflow. I will be happy to answer there.

ocombe commented 6 years ago

Can you please not discuss this here, it's not the topic here, thanks As for your question @stickler-v, one file per module / component is not possible right now, it might be in the future but it's not on the list of things that we are working on right now

2f4f4f commented 6 years ago

Any plans to support route translations?

santhony7 commented 6 years ago

Sorry if this was already answered but are translations in JS possible with this version or is it still templates-only?

actra-gschuster commented 6 years ago

@santhony7 It's still not possible as Ivy isn't ready.

mjschranz commented 6 years ago

One question I have about the intent/functionality of runtime i18n here is if that means we will essentially be able to select the language at runtime and "flip" it without reloading the app as was the functionality in the old ng-translate for AngularJS and in ngx-translate? Or does this mean something else entirely?

ocombe commented 6 years ago

No, you will have to reload the app to change the language.

With the current i18n, when you build and provide your translations, we replace the strings in the bundle code, meaning that the bundle is localized. Runtime i18n means that the translation files are loaded when the app starts and not at build time like it is right now. Because of that, you will be able to lazy load the translation files before the app starts which means that the bundle is separated from the language, you only get one bundle for your app. You can also choose to have one bundle per language, and bundle the language file with your app (like we are doing right now), you'll avoid the delay required to lazy load the translations file. In one case you do an extra http request, and in the other case not, but I don't think there will be a big enough difference to justify having one bundle per language.

Advantages of runtime i18n:

Disadvantages:

Theoretically you could change the language without reloading the whole app, but you'll have to recreate the existing components because the templates are generated when the component is created, or you could bind the service in your template (instead of using i18n attributes) and it would be updated when you change the language. It would be possible to write a library that works like ngx-translate but uses Angular i18n internally and allows you to change the language at runtime. It would use more memory to keep the templates in sync with the language, like it's the case with ngx-translate. I'll probably write a library like this.

figuerres commented 6 years ago

also for folks to think on is that some changes from one language to another may be small other may be large, say going from english to spanish is might be a "small" but from english to say Chinese or Arabic will be large. to clarifiy for some languages it's not just the text, you may also need to design a different layout to accommodate that language and it's rules for alignment, left to right or right to left and other details.

so for most real world use i would expect the app to have at the app load a language detection step that will lead to loading the right resources and some layouts.

mjschranz commented 6 years ago

@ocombe Thank you very much for clarifying! I've implemented the current Angular i18n within our application and have hit a snag because of changes/unknown requirements. I'm also using the https://github.com/ngx-translate/i18n-polyfill library in conjunction to help bridge the current gap.

While the multiple bundles is a slight annoyance, you can work around it easily enough currently. The snag in particular is the potential to have one component (and all child components of it) to be displayed in a language that is different than the currently used language.

Frankly I'm uncertain yet if ngx-translate can help accomplish this for me but I wanted to message you about the upcoming changes just to make sure I had as much information possible before making any pivots.

ocombe commented 6 years ago

We don't have any plan to support apps translated in multiple languages at the same time, it might be possible in the future if we can load translations / module, but it would be a side effect of the architecture, not something that we specifically tried to achieve.

TomDemulierChevret commented 6 years ago

Is there any ETA for Ivy + runtime i18n ? I understand perfectly if it's not the case, but I need to know if (given the timeframe of my current project) I can wait for it or need to start using one of the current solution and postpone the migration to runtime i18n for a future version.

ocombe commented 6 years ago

I won't try to give an exact time frame, every time I've tried it was wrong :D It won't be before v7 now (will be available before as a beta)

TomDemulierChevret commented 6 years ago

No problem, we all know how estimations are always wrong. :D Do you think it will be easier to migrate from the current i18n (+ i18n-polyfill) to runtime 18n or from ngx-translate ?

ocombe commented 6 years ago

probably from the current i18n, but I'll write a version of ngx-translate that uses the internals of Angular i18n, if it's possible (not sure yet)

justageek commented 6 years ago

Hi, I've tried to traverse this thread to understand the current state. Is the ngx translate code currently the most viable "workaround" for a single app with dynamic loclalization?

sachingavas99 commented 5 years ago

Hi, Is it possible to change the localization at run time using ngx-translate/i18n-polyfill?

mjschranz commented 5 years ago

@suchg Not at runtime. You're able to do translations at runtime but you can't change the locale used.

sachingavas99 commented 5 years ago

@mjschranz thanks for the quick reply even the run time translations is fine for now. can you share any example for the same. I tried the example shared at https://github.com/ngx-translate/i18n-polyfill, and did change in language of chrome browser but no luck. is there any specific method for translation ??

ocombe commented 5 years ago

Please, keep the discussion here about Angular, not external libraries. If you need any help with that, post the messages on their github repositories

ValentinFunk commented 5 years ago

Hey, are there any other tracking issues or design docs on what the feature will look like in the future? Perhaps we can help with implementation or prepare ourselves to make sure the transition in v7 will be as smooth as possible.

mattiLeBlanc commented 5 years ago

Hi, I am currently running Angular 5 and we need to add multi language to our project. I have added a solution that works for me now, which is almost elegant. https://github.com/angular/angular/issues/24549.

Ideally, I would like to lazy load the language files based on a country sniffer service (based an a hostname map lookup). If that would be possible in Angular 6, that would be great.

zverbeta commented 5 years ago

@mattiLeBlanc How you resolve dynamic messages, for example messages from component or services?

mattiLeBlanc commented 5 years ago

@zverbeta Please excuse me for not fully understanding Angular Core or the context for this discussion. I can only approach it from my context for starters.

In answer to your question, I would assume that we are only interested in lazy loading the translation files (xlf) in a nice fashion, based on a locale which can be deduced from the URL or a language queryparam. ( I currently use an URL map to decide what the locale is).

A message from a component or service is not tagged like we tag the markup with i18n. I have some experience with i18n for Wordpress and PHP. There we use the __( 'text' to translate, 'text domain' ) approach to get the correct translation. This __() could also be scanned for by the CLI command creating the message file.

Is this one of issue you where referring to?