Can't use translation file for en-US: "An i18n locale ('en-US') cannot both be a source locale and provide a translation"

[MartinJaskulla]

🐞 bug report

I can't use a translation file for en-US:

i18n": {
    "locales": {
      "en-US": {
        "baseHref": "delete/us/en_us",
        "translation": "messages.en-us.xlf"
      }
    }
}

Description

• Our app is translated into 40+ languages
• We want our translation department to be responsible for all strings
• We want to ignore the strings our developers have written in the HTML files
• Therefore we need one build per messages.xlf file and no build for the "sourceLocale"
• At the moment we are forced to manually copy the strings from the messages.en-us.xlf file back into our HTML every time our translation department makes a change to en-US

Possible solutions:

• Allow "translation" as a property of "sourceLocale"

"sourceLocale": {
  "code": "en-US",
  "translation": "messages.en-us.xlf"
}

• Add option to prevent the build of the source locale

🔬 Minimal Reproduction

https://github.com/MartinJaskulla/angular-issue-38316

🔥 Exception or Error

An unhandled exception occurred: An i18n locale ('en-US') cannot both be a source locale and provide a translation.

🌍 Your Environment

Angular Version:

Angular CLI: 9.0.7
Node: 12.13.1
OS: darwin x64

Angular: 9.0.7
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.7
@angular-devkit/build-angular     0.900.7
@angular-devkit/build-optimizer   0.900.7
@angular-devkit/build-webpack     0.900.7
@angular-devkit/core              9.0.7
@angular-devkit/schematics        9.0.7
@angular/localize                 9.1.12
@ngtools/webpack                  9.0.7
@schematics/angular               9.0.7
@schematics/update                0.900.7
rxjs                              6.5.5
typescript                        3.7.5
webpack                           4.41.2

Anything else relevant?
I know that there are several workarounds. For example we could provide a non-existent source locale "sourceLocale": "aa-aa" and delete the build afterwards. However our app is very big and we want to save the build time.
Furthermore our actual setup is more complex than the example provided above. For example the translations for the same locale e.g. my-app.com/de/en-US and my-app.com/us/en-US can be different. It would be useful for angular.json to provide some sort of nesting of the locales.

[doliG]

I have the same problem, and agree with the suggested solution

Allow translation as a property of sourceLocale

[simonpeters]

Same issue here, we only have one language but would like to use i18n so we can use translation tools to have non developers change the strings we use.

[praxem]

We have the same problem...

It is strange to think that in a huge complex application the main source of the language will be in HTML ...

[nelisbijl]

Same issue here, we only have one language but would like to use i18n so we can use translation tools to have non developers change the strings we use.

My workaround:
Configure a fake sourceLocale in angular.json. I used zxx, which is actually a valid ISO639-2 code (https://www.loc.gov/standards/iso639-2/php/code_list.php)
Only downside is a warning during ng extract-i18n:

Warning: AngularCompilerPlugin: Unable to load the locale data file "@angular/common/locales/zxx", please check that "zxx" is a valid locale id.
If needed, you can use "registerLocaleData" manually.

That will possibly disappear when you choose a different valid locale code not used by your application

[doliG]

I use the same workaround as @nelisbijl with aa-AA as ISO code and it works.

But this is not a correct solution, can maintainer have a look at this ticket and give us a status ?

poke @alan-agius4 @clydin @filipesilva @hansl and so on...

[stefan-schweiger]

Any potential update on this issue? It's really annoying to manage all your text with a service like lokalise.com when you can't have the source locale as a translation target.

[clydin]

Private use subtags can be used to describe the unique nature of the source locale in these type of cases. For example, the following configuration section provides for a translated de locale while also describing the content within the source code as untranslated.

“i18n”: {
	“sourceLocale”: “de-x-source”,
	“locales”: {
		“de”: “./locales/de.xliff2”,
		“en”: “./locales/en.xliff2”,
		“fr”: “./locales/fr.xliff2”
	}
}

[stefan-schweiger]

@clydin I needed to change a few things in my extraction and upload scripts but this works well. Thank you very much :)

[martijn19811]

@clydin Hi, I'm having the same issue here. Would like to use a default translations file for my sourceLocale. Although Im not sure how.

      "i18n": {
        "sourceLocale": "nl-x-source",
        "locales": {
          "nl":  "src/locale/messages.nl.xlf"
        }
      }

The build works and the NL language is being used, but it does not use the translation file. what am I missing here?

Oh, and Im actually not using the --localize flag in the application. I just want the default build to have a few translations. That's it :). Thanks for your help in advance!

[damsad]

Hi, I'm facing a similiar issue.
I have a multilanguage app supporting many different languages.
Now aside of the other language versions I my app to have a different specific variants of en locale.
For example I will have en-US, en-GB, en-ZA, etc..
I expect that 95% of the phrases between this locales will be shared and only few percent will differ and specific to region.
Not to duplicate all the phrases and repeat the translations within multiple en files I supposed I could utilize "en" as a source locale and put there all shared words and translations and then only put the phrases with specific regional words to target translation files (en-GB, en-US,...).
However it appeared you cannot specify a translation file for a source locale and you have tu put the phrases directly into the views.
Doing this instead of using resource ID's seems like an anti pattern and a maintenance nightmare.
Is there a way I can achieve this kind of shared resource behavior now?