angular / angular-cli

CLI tool for Angular
https://cli.angular.io
MIT License
26.68k stars 11.98k forks source link

support file replacement in i18n locales #17126

Open xiaoxiangmoe opened 4 years ago

xiaoxiangmoe commented 4 years ago

πŸš€ Feature request

Command (mark with an x)

Description

please support file replacement in i18n locales.

https://github.com/angular/angular-cli/blob/2998e5e0602168c2f63cde2a5f123bfb885bbcb7/packages/angular/cli/lib/config/schema.json#L416-L444

clydin commented 4 years ago

The file replacement option affects the behavior of the initial TypeScript compilation and bundling. Multiple separate builds would need to be performed to allow for distinct file replacement options since JavaScript output of each pre-localized build would be unique. This, however, can be accomplished currently by using separate configurations per locale and building each one.

xiaoxiangmoe commented 4 years ago

This, however, can be accomplished currently by using separate configurations per locale and building each one.

we should add --delete-output-path=false in all configurations.

if --delete-output-path=true, we'll remove en dir if we start build zh-Hans dir.

@clydin

zencakd commented 4 years ago

So, if I need to do file replacement for each locale (e.g. Global Terms & Condition or other language dependent source), I loose the benefit of --localize and there will be a build for every locale?

I also tried to create a configuration for every language with own outputPath param but then the locale directories were deleted after finishing a build or the locale sub-directories were doubled. This could be fixed with --delete-output-path=false?

petebacondarwin commented 4 years ago

I have an extension to the @angular/localize tooling that should support file replacement - https://github.com/angular/angular/pull/33670 - if we got this merged and the CLI integrated it, I think that could support your use case @zencakd, right?

xiaoxiangmoe commented 4 years ago

@petebacondarwin Can we use locales field with loadTranslations? it seems that loadTranslations will not work if we use locales field with another translation file.

petebacondarwin commented 4 years ago

So what I am talking about is allowing file-replacement at the point of translation, which is after the TS builds have completed. This would mainly be for providing translated assets, such as images and non-source text files. It would run as part of the compilation time translation step not at runtime in the browser as part of loadTranslations().

zencakd commented 4 years ago

@petebacondarwin People will probably have many different use cases for file replacements. How do you plan to set file format allowance? Today, I do file replacement for global terms and conditions (language dependent) that are stored in html template (because every language version comes different formatting). I understand that this require compilation but maybe I can put it out to JSON/txt file and load it on the fly...or even from the server. But to allow file replacements for specific non-source files would be a superb feature with new --localize!

petebacondarwin commented 4 years ago

@zencakd - sorry I am confusing matters. The implementation I am referring to (angular/angular#33670) replaces whole files, not strings within files. See a test case here https://github.com/angular/angular/pull/33670/files#diff-9bec794d577871fac9eea3d355ef4361R157.

zencakd commented 4 years ago

@petebacondarwin No, it is clear, I got it :-) Thank you!

clydin commented 4 years ago

To clarify a couple points:

There is no current support for localized assets within the CLI but it is something that is planned. Since asset copying is something that happens after the code is built, it can be configured per locale and not need multiple builds. This would allow images, JSON, etc. to be changed on a per locale basis.

bbarry commented 3 years ago

@clydin is there an issue for supporting locale files within fileReplacements?

      ...
      "configurations": {
        "whitelabel": {
          "fileReplacements": [
            {
              "replace": "src/locale/messages.en.xlf",
              "with": "src/whitelabel/locale/messages.en.xlf"
            }
          ],
         ...

our current workaround is using multiple projects with the same sourceRoot and prefix and most of the same options...

clydin commented 3 years ago

@bbarry The recommended method for this use-case is to use private use subtags for the locale. This locale can then be specified in relevant configurations or on the command line as needed. For example:

      "i18n": {
        "locales": {
          "en": "./locales/en.xliff2",
          "en-x-wlabel": {
            "baseHref": "en",
            "translation": "./whitelabel/locales/en.xliff2"
          }
        }
      },
breningham commented 3 years ago

@bbarry The recommended method for this use-case is to use private use subtags for the locale. This locale can then be specified in relevant configurations or on the command line as needed. For example:

      "i18n": {
        "locales": {
          "en": "./locales/en.xliff2",
          "en-x-wlabel": {
            "baseHref": "en",
            "translation": "./whitelabel/locales/en.xliff2"
          }
        }
      },

this does not seem to be a viable solution in angular 11.2.x

i have my i18n object set up like:

{
 "i18n": {
                "sourceLocale": "en-GB",
                "locales": {
                    "en-US": {
                        "translation": "packages/aspect/src/locale/en-US.xlf",
                        "baseHref": "en-US/"
                    },
                    "en-GB-tenantname": {
                        "baseHref": "en-GB",
                        "translation": "tenants/tenantname/i18n/en-GB.xlf"
                    }
                }
            },
}

and a config that makes use of it:

{
  "tenantname-en-gb": {
      "localize": [ "en-GB-tenantname" ]
  }
} 

but the build will fail due to it not matching the pattern. with pre-ivy i18n this was possible to do, just change the i18n-file.

are there any known solutions to this?

dougamos commented 3 years ago

@breningham an -x- is required to specify that it is private-use language tag. Try en-GB-x-tenantname instead of en-GB-tenantname

angular-robot[bot] commented 2 years ago

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

angular-robot[bot] commented 2 years ago

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.