Automatic upgrade of the global variants of the locale data

[DenysVuika]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Description

In Angular 9 and earlier the recommended use of the global variants of the locale data was as following:

import { registerLocaleData } from '@angular/common';

import localeFr from '@angular/common/locales/fr';
import localeDe from '@angular/common/locales/de';

registerLocaleData(localeFr);
registerLocaleData(localeDe);

With Angular 10 there's a new way (and a breaking change):

import '@angular/common/locales/global/fr';
import '@angular/common/locales/de';

Describe the solution you'd like

• Given it's a breaking change, provide an automatic upgrade support from the Angular 9 to Angular 10.
• Provide information about this breaking change in the Update tool (https://update.angular.io/)

Describe alternatives you've considered

The only alternative is to manually upgrade the code and to inform the customers about breaking changes (for the lib authors)

[petebacondarwin]

This is not strictly how localisation works in Angular 10+...
Now the CLI will automatically inject the "global" locale into the distributable that you generate for each language.
You only need to use registerLocaleData() if you want to register an additional locale other than the one for the current language. Also you do not need to use the "global" version if you are registering a locale manually.

Therefore this is not a breaking change:

• You can continue to use the previous approach for registering a locale.
• You can "choose" not to bother registering the locale of the current language if you wish, but you don't have to.
• The import paths for manually registering locales has not changed.

[clydin]

Both options are still viable and they can actually be used together if desired. As a result, there is no breaking change currently present.

For the majority of use cases, neither method is actually needed since the localization (“—localize”) build process will automatically inject the appropriate locale data. Within the build process, the LOCALE_ID token will also be automatically set as well the “lang” attribute in the index HTML.

The situations with the direct use of the locale data tend to be uncommon/application-specific and determining developer intent can be non-trivial and combined with both options being currently viable, no migrations are currently present. If deprecating of the methods are considered in the future, then this may change.

[DenysVuika]

I am trying to upgrade to Angular 10 and having a lot of warnings in the output. Steps from this thread helped me: https://stackoverflow.com/questions/62643866/angular-10-register-custom-locale

[petebacondarwin]

I'm really sorry everyone, our messaging has been a bit confusing here.

As @clydin said, there is no breaking change.

It is unfortunate that the "old" locale imports triggered the CommonJS/AMD warning, since those files are actually coming from the Angular framework. The fact that the "global" locale data files do not trigger the import is not necessarily the right reason for using them over the "old" locale data files. The "global" files are not ESM modules either and so do not take part in dead code elimination either.

Further we have not been very clear about what you should be doing with regards to these locale data files: in most projects you should not need to register any locale data unless you are doing something with a specific locale in your application.

So a lot of projects could probably just remove the registering of a locale, especially if they are only using the one that is the same as the current language being translated. It is not possible to provide an automatic migration for this scenario since it is very hard to tell if the developer is actually importing the locale data for some other reason. We think we could add a runtime check (dev-mode only) to warn the developer if they try to register the same locale data that was already registered globally automatically by the CLI.