-
Notifications
You must be signed in to change notification settings - Fork 12k
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 IVY - Next.12 LocaleID not set #15896
Comments
Fwiw issue also present in next-11, next-10 |
@spock123 did this ever work in previous version of Angular (e.g. v7?) |
Hi @petebacondarwin yes, I'm using this in an Angular 8.x production application (non IVY). |
So serving, building is done like this:
We support 3 languages so we run this for each language when we build the application. |
@petebacondarwin I'm pretty sure the locale is supposed to be set in angular.json, so you can have different build configurations for i18n language versions. Thank you for looking into this |
Btw I use Aot for both development and production.. maybe that makes a difference... I don't use runtime i18n |
Thanks for reporting this issue @spock123. I moved this issue to Angular CLI repo for further investigation. Thank you. |
I'm not sure that this is fixed by #15884 ... should we reopen? |
The ivy compile time inlining tools work on the code after it has been compiled and bundled (potentially minified and mangled). It is only at this point in the processing that the current locale can be specified. The cleanest way for the tooling to provide this locale value is by setting a well-known global property (e.g. `ɵNG_LOCALE_ID`) which is then read at runtime by Angular and provided as the `LOCALE_ID` token and also passed to the ivy machinery via `setLocaleId()`. // FW-1639 See angular/angular-cli#15896
In the post-$localize world the current locale value is defined by setting `$localize.locale` which is then read at runtime by Angular in the provider for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`. The $localize compile-time inlining tooling can replace occurrences of `$localize.locale` with a string literal, similar to how translations are inlined. // FW-1639 See angular/angular-cli#15896
In the post-$localize world the current locale value is defined by setting `$localize.locale` which is then read at runtime by Angular in the provider for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`. The $localize compile-time inlining tooling can replace occurrences of `$localize.locale` with a string literal, similar to how translations are inlined. // FW-1639 See angular/angular-cli#15896
In the post-$localize world the current locale value is defined by setting `$localize.locale` which is then read at runtime by Angular in the provider for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`. The $localize compile-time inlining tooling can replace occurrences of `$localize.locale` with a string literal, similar to how translations are inlined. // FW-1639 See angular/angular-cli#15896
In the post-$localize world the current locale value is defined by setting `$localize.locale` which is then read at runtime by Angular in the provider for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`. The $localize compile-time inlining tooling can replace occurrences of `$localize.locale` with a string literal, similar to how translations are inlined. // FW-1639 See angular/angular-cli#15896
In the post-$localize world the current locale value is defined by setting `$localize.locale` which is then read at runtime by Angular in the provider for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`. The $localize compile-time inlining tooling can replace occurrences of `$localize.locale` with a string literal, similar to how translations are inlined. // FW-1639 See angular/angular-cli#15896
@petebacondarwin issue still present in next.13 |
This issue has not yet been corrected and is still in progress. |
@clydin thanks .. |
In the post-$localize world the current locale value is defined by setting `$localize.locale` which is then read at runtime by Angular in the provider for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`. The $localize compile-time inlining tooling can replace occurrences of `$localize.locale` with a string literal, similar to how translations are inlined. // FW-1639 See angular/angular-cli#15896 PR Close #33314
This is fixed in the latest .next build. |
@vikerman ^9.0.0-next.15 Injecting localeID gives me "en-US" when using IVY. |
Can you share a repro? Thanks |
@vikerman I will try, have to strip a lot from my app.. will try later, thanks |
|
@clydin the translation files were only empty in this demo, they were not empty in my project. That I could not use ng serve was the issue - thanks. I assume it will be working at some point, will lay off testing Ivy for now then. Thanks Just should note for people seeing this, that it's pretty important to know that localeID will be set to 'en-US' when using "ng serve", no matter the configuration. Some people might expect otherwise. For example, many people use ngx-translate with runtime translation, and they often rely on this localeID to determine language file to download. It has nothing to do with core Angular features, but it will break those who depend on the localeID to be set. |
@clydin could you plz explain a bit more on it? I have next config for the serve
where for In my understanding result of btw, |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
🐞 bug report
Description
Setting locale in angular.json is ignored by the compiler.
No matter the locale, injecting the localeID token gives "en-US" .
🔬 Minimal Reproduction
Set locale in angular.json
Serve the app, inject localeID token and print it out, gives "en-US"
🌍 Your Environment
Angular Version:
The text was updated successfully, but these errors were encountered: