New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[i18n] plans #16477
Comments
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 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 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:
|
Points 2 and 3 will be resolved with the feature "Use translation strings outside of a template - #11405". |
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 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 |
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! |
Hey @rjsteinert! Glad to know that! |
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: My idea: 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 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? |
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... |
Yes, didn't think of that. It's ugly but works...can't wait for ng to support it natively. |
I came up with a "solution" that suits my needs until there's an implementation. Repo: https://github.com/actra-development-oss/ng-i18n-aot-loader |
possibly a component could have an attribute that tells the system / compiler that it needs a service. if a component does not have the attribute no locale run-time. 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. |
I had that idea, too. 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. |
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. Keep it simple, make it work for 95% of all users first then figure out the edge cases. |
I don't see that as an edge case, it's business as usual.
Separating those chunks would:
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. |
We have a meeting tomorrow to find a solution to this problem. |
@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! |
@ocombe , is it possible to change language without relaoding the entire document ? I explain : |
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 @ocombe as you seem to be very active on this topic would you mind having a look at the PR and giving feedback? |
Thanks, I'll take a look at it. |
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. |
@vicb is working on it right now, it'll be in 5.x (not 5.0 but most likely 5.1) |
@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. 😃 |
yes, good idea, I'll update it |
You can extract translations from templates. |
@vekunz - the forecast is still valid. Moreover, as @ocombe points out, the current CLI translation extraction mechanism works just fine for any translation that is within an Angular template (i.e. stuff that is marked by the |
The The tooling that does translations and extraction (specifically at compile time) is still non-public. But this is not a concern unless you are planning on building your own tooling around it (like @ocombe is doing at Locl!). |
Thank you @petebacondarwin, with this, we could duplicate the texts from code into a "hidden" component template for extraction. Then the extraction and the translation both should work, shouldn't it? @ocombe With the forecast that extraction works with Angular 9.1, our manager wouldn't pay for your solution. Especially because we don't need live switching of languages and translated routes. |
Yes indeed, this workaround would work for now. |
I'm confused: Will the runtime translation also be possible in 9.1? Or just the extracting outside of templates? Or none of these? For me the runtime translations would be a killer feature. To deploy multiple bundles and forcing the user to reload the whole page is not a good usability I think. |
@JustDoItSascha |
Hi! I'm trying to call main.ts imports AppModule that imports AppComponent (where I'm using To make it work I'm doing: loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule); Now this works but causes Angular's "complier.js" bundle to be included in the vendor bundle. Any way to avoid that? Thanks |
Currently, |
It's even worse than that, it needs to be called before any module file is imported, that's why it works if you put it in polyfills.ts (which is executed before the main app file), but if you want to use it in your "main" file then you need to use a dynamic @vekunz it's a good reason to not use my lib for now 😊 that being said Locl is not just about extraction, I intend to add a lot of other tools to simplify i18n |
Is there any intention of implementing runtime i18n in Angular ever? We've been expecting the feature for almost three years and now Ivy's here and it's still only half-baked. |
My understanding is that Ivy, in many ways, is an enabler for things to come. Unsurprising that the i18n needle did move incredibly with the release of Ivy, but it should unleash the potential for big changes down the road. That's been my read of it, and my hope, anyway. |
@Karasuni - I think we need to clarify what runtime translation actually means for the core Angular framework because there is quite a bit of confusion about it. The changes that we made for v9 involve the The first of this, which is immediately available to all users of v9, is to speed up generation of translated applications. Previously, the entire build pipeline had to be run for each language that you wanted to translate your app into. Now the main compilation of your application only has to be run one and the final translation process, which is significantly shorter is run for each language on the output of the build. To support this there is the new Secondly, since the Note that this "runtime" translation can also be used on lazy loaded routes so it might be feasible to have different routes in different languages depending upon how you set things up. Since there is not a single approach to this loading of translations that works for all scenarios, we have not baked this into the CLI or provided stable public APIs to support this yet. Once we get a better understanding of the use cases then we might be able to add more support for this. In the meantime things like Locl might help if you don't want to venture into working it out for yourself. Finally, note that dynamic changing of translated strings at runtime is specifically not supported (by design) by the core Angular framework. Hooking the translated strings into Angular's change detection system would put too much strain on most applications and ruin performance. From my interactions with the community I have seen hardly any real world scenarios where this is actually needed over and above restarting the application on language change. If this is a requirement for your application then you could achieve it by using a custom built pipe on your strings in templates that pulls in translations, and maybe even calls The main changes coming in the next minor version of Angular will be improved translation extraction, which will be able to identify and extract localized strings from TS code - currently the CLI extraction only handles localized strings in templates. Changes to improve runtime translation, as described above, would not appear until after 9.1 at the earliest. |
I might be mistaken but in this thread alone many people expressly showed interest in the ability to change the language live, at runtime, without having to rebuild or reload the application. Or does everyone here have a different definition of I do not want to reload an application just to switch a language. For example when a user is on a page with a form a full page reload for a switch in translation will be jarring to the user. |
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? |
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." |
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. |
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. |
yes they can be loaded asynchronously, but you need to delay the start of your application until they have been loaded |
Technically you can reload the entire app and still keep the user where he was. The only trick would be to keep scroll position but that's feasable too. |
@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. |
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. |
I don't see changing language live (without page reload) to be such a deal breaker. 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;
|
@Karasuni |
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 :
|
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. |
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. |
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
Issues
Not prioritized
Features
#
andoffset
#9117 [blocked, requires "Allow escaping ICU messages - [i18n] escaping in ICU message #9286"]Issues
The text was updated successfully, but these errors were encountered: