Feature Request: Provide possibility to define custom locale imports for i18n builds

[kyubisation]

🚀 Feature request

Command (mark with an x)

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

Description

Switzerland has four national languages ((swiss-)german, french, italian and romansh) and english as an official language. Switzerland however has no official locale specification, so as far as I know the CLDR data is just a "best effort" for specifying the locale.
For example the date format in en-CH is simply wrong (dd/MM/y should be dd.MM.y).
However there are also minor issues with the data; e.g. floating point numbers can be separated by both , or ., but . is more common. Also date and time are not usually separated by ,, but can be.

Since Angular and the Angular CLI limits the customization of locale information, this becomes a problem for the projects at SBB (national public transport provider), since the locales are specified by business for SBB projects.

Describe the solution you'd like

I would like to have a feature to provide our own locales, maybe with a warning for possible imcompatibility.

e.g.

      ...
      "i18n": {
        "locales": {
          "de-CH": {
            "translation": "src/i18n/messages.de-CH.xlf",
            "baseHref": "/de/",
            "localeImport": "example-library/locales/de-CH"
          },
          "fr-CH": {
            "translation": "src/i18n/messages.fr-CH.xlf",
            "baseHref": "/fr/",
            "localeImport": "example-library/locales/fr-CH"
          },
          "it-CH": {
            "translation": "src/i18n/messages.it-CH.xlf",
            "baseHref": "/it/",
            "localeImport": "example-library/locales/it-CH"
          }
        },
        "sourceLocale": {
          "code": "en-CH",
          "baseHref": "/en/",
          "localeImport": "example-library/locales/en-CH"
        }
        ...

This sould be doable, by changing configureI18nBuild in packages\angular_devkit\build_angular\src\utils\i18n-options.ts, so that it tries to resolve custom locale imports before calling findLocaleDataPath.
I'm also fine with printing a warning to point out possible incompatiblity issues.

If you are not opposed to this feature I can also provide a PR.

Describe alternatives you've considered

Either patch the locale data after startup or register all custom locales with registerlocaledata, which is cumbersome.

[petebacondarwin]

Another workaround would be to patch the locale data files in node_modules/@angular/common/locales/global/... as a postinstall step?

[kyubisation]

The issue is that we have +100 Angular projects at SBB.
It would be possible for us to provide a package that patches the locales after installation, but that is a hack and will be met with some resistance from the projects.
A cleaner solution would be something I have suggested above.

[petebacondarwin]

I agree it would be a hack. It was just another workaround in the meantime.

It is not my place to say, but I think that your proposal is worthy. You would need to ensure that it has the correct format, etc. But I could imagine these "patch" files could be quite small, since you could import the originals and only change the bits you want.

With that in mind, how about a fallback mechanism, where you simply provide a folder to look in first for locale data files? The CLI could then load your files if available, and fallback to the Angular ones otherwise. This would keep your angular.json file much simpler and avoid the need to keep it in sync with the files in your own locales folder.

Also, in the long run, I would propose that if the CLDR data is wrong then you should be encouraging that project to update its definitions to be correct, since that is where Angular gets its locale data.

[kyubisation]

I agree it would be a hack. It was just another workaround in the meantime.

I didn't mean to dismiss the workaround suggestion and I will discuss this with my team.

It is not my place to say, but I think that your proposal is worthy. You would need to ensure that it has the correct format, etc. But I could imagine these "patch" files could be quite small, since you could import the originals and only change the bits you want.

With that in mind, how about a fallback mechanism, where you simply provide a folder to look in first for locale data files? The CLI could then load your files if available, and fallback to the Angular ones otherwise. This would keep your angular.json file much simpler and avoid the need to keep it in sync with the files in your own locales folder.

That seems reasonable. Should I change my feature request? Or should I directly try to provide a PR?

Also, in the long run, I would propose that if the CLDR data is wrong then you should be encouraging that project to update its definitions to be correct, since that is where Angular gets its locale data.

I tried to explain this in the issue above; apart from the date format in en-CH the date is not per se wrong. And as far as I can tell the CLDR definition is kind of a majority vote with its survey.
So changing the data is most likely a complicated process.

[petebacondarwin]

I would wait on feedback from the CLI team before modifying your suggestion or attempting an implementation.