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.

[snebjorn]

Sorry, but I'm not entirely sure I understand how to migrate.

If I had this in version 9

import { LOCALE_ID, NgModule } from '@angular/core';
import { registerLocaleData } from '@angular/common';
import locale from '@angular/common/locales/da';

registerLocaleData(locale, 'da-DK');

@NgModule({
 providers: [
    // Used for standard Angular pipes.
    { provide: LOCALE_ID, useValue: 'da-DK' }
 ]
})
export class AppModule {}

Then in version 10 it's

import { NgModule } from '@angular/core';
// tslint:disable-next-line: no-import-side-effect
import '@angular/common/locales/global/da';

@NgModule({
 providers: []
})
export class AppModule {}

Is that correct?

[petebacondarwin]

@snebjorn - you do not actually need to do anything migration here.
That being said, if you are building localized versions of your application (i.e. by setting up the "i18n" configuration in angular.json) each localized version will have the appropriate locale data already loaded and available. So depending upon your setup it is possible that you do not need to import any locale.

[snebjorn]

I see. And the scary warning goes away in the next CLI release. Thank you ❤️

I tried setting up "i18n", but it requires the localize package and it changes the compile dir. So it broke the CI. It also appears to be intended to be used when you need the i18n directive.

In my app I'm only interested in the DatePipe formatting dates according to the 'da' locale. Because all text is in English anyway, but having dates formatted in non-sense order is confusing :)

On another note.
If all I'm really interested in is changing the configured LOCALE_ID. Am I doing it the easiest way then?

[DenysVuika]

@petebacondarwin I still don't get it, sorry. We have a bunch of applications that do not use native Angular i18n, but we still need support for Date pipes and other areas.

The only way for that to work before Angular 9-10 was like this: https://github.com/Alfresco/alfresco-content-app/blob/master/src/app/app.module.ts#L82

Should we keep using the old approach or the new one?

[petebacondarwin]

Hmm, so if this application will need to support multiple locales without reloading, then I guess you do need to load and register all of these. In that case, there is nothing for your to do.

But if you are just doing this because each user might be in a different locale, then you could consider using the new built in localisation tooling of the CLI, that will create multiple copies of the application - one for each locale. In that case the CLI will register the appropriate locale data for each copy of the application.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}