Consider switching back to Intl browser APIs for internationalization
#49143
Comments
|
I agree. I find it ridiculous that I cannot dynamically load a LOCALE_ID and have to manually import it using @angular/common/locales/{localeId} as mentioned above. I do not require the locale data for translations, all I need this for is number, currency, percent and date pipe formatting. Why isn't there an option to just make the built in currency/number pipes to work without importing the whole locale package?? The local ID and currency code are both something I get from an API. I have had to write my own custom pipes as well just using the Intl.* browser APIs as well. Please allow for dynamic locales!!! |
|
I'm closing this in favor of #54470, hoping we can land this in the next major. |
|
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. |
Which @angular/* package(s) are relevant/related to the feature request?
common
Description
Back in the days Angular used Intl APIs in their pipes, but due to different browser implementations this led to many issues. So in 2017, Angular decided to go for a custom implementation, which I think was the right decision at the time. But today we are in a quite different situation. Internet Explorer support has been dropped from Angular, browser support has evolved and the browsers heavily worked on unification of their APIs. In my opinion, it should be re-evaluated whether to switch back to the Intl APIs.
This would have an effect to all pipes which require locale data, namely
date,currency,decimalandpercent. For developers who don't use compile-time translations it's quite inconvenient to feed those pipes with locale data. Developers need to import from@angular/common/locales/{localeId}, and register the data withregisterLocaleData(). When supporting multiple locales, either they all need to be added to the bundle (which bloats up the bundle size), or alternatively they can be loaded with a dynamic import. With the latter solution, additional chunks containing the locale data for each language are generated. Those chunks need to be loaded at runtime depending on the locale of the user. This can lead to missing locale data during the time when the main bundle is already loaded, but the request loading the chunk with the locale data is still pending. The handling of locale data is the main reason why I personally don’t use any of these Angular pipes anymore and wrote own pipes instead based onIntl. I assume I’m not the only one.Additionally, after a quick search in the GitHub issues, I found that there are some issues with the implementation of the pipes, which could be resolved: #47479 #48279 #48250 #45409 #54114 and more
To list some of the benefits:
Proposed solution
Angular refactors existing pipes to use the
Intl.*browser APIs. As this might lead to breaking changes, maybe it would make sense to offer them as an opt-in.Angular could also consider adding new pipes based on the Intl APIs such as
country,language,relativeTime, ..., as they should be relatively easy to implement and maintain.Alternatives considered
Could also be solved by a community npm package. I'm currently developing one, feedback is very welcome!
https://github.com/json-derulo/angular-ecmascript-intl
The text was updated successfully, but these errors were encountered: