ng xi18n Xliff no longer produces empty <target/> translations causing the Xliff parser to fail

[chriskyndrid]

I'm submitting a...

[X] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

As a result of 15754 ng x18n no longer produces empty <target/> translation tags. Given the direction of the the I18n support, as per the new i18n-polyfill, 4, this creates issues with the development lifecycle of internationalized Angular applications.

Expected behavior

When developing internationalized applications it's common to develop in a single "root language", and once complete extract the specific words and dispatch the appropriate language files to a translator for languages translation. The resulting language files are then loaded into the application and support for additional languages is achieved.

Due to the direction I18n support appears to be heading, throughout the core development lifecycle of applications utilizing the Angular framework, it's anticipated to generate many cycles of the root languages .xlf file.

Unfortunately as it stands, the as extracted xlf file is not valid(to the Angular Xliff parser, although omitting the tag is valid to the standard, from my understanding), and upon load causes a fatal error by the translation indicated "missing translations". The MissingTranslatoinStrategy has no effect as that impacts things post Xliff parsing. Therefore the developer must manually add appropriate <target/> tags in each instance a given Xliff file(corresponding to an appropriate <source> tag) for the root language file.

Recommendations:

1:

Allow the developer to pass an argument to the ng x18n that allows the developer to make an informed decision about generating the resulting empty <target/> to ensure the Xliff parser can parse the Xliff file.

OR

2:

Enhance the Xliff parser to not require a <target> as it does not appear to be required by the standard.

Minimal reproduction of the problem with instructions

1:

Setup an application for internationalization(taken from #4) the example below utilizes the new speculative polyfill:

// app.module.ts
import { BrowserModule } from '@angular/platform-browser';

import {
  NgModule,
  TRANSLATIONS,
  LOCALE_ID
} from '@angular/core';

import { I18n } from '@ngx-translate/i18n-polyfill';

declare const require;
export function translationsFactory(locale: string) {
  locale = locale || 'en'; // default to english if no locale
  return require(`raw-loader!../locale/messages.${locale}.xlf`);
}

@NgModule({
  imports: [BrowserModule]
  declarations: [
    AppComponent,
  ],
  providers: [
        {provide: LOCALE_ID, useValue: 'en'},
        {provide: TRANSLATIONS_FORMAT, useValue: 'xlf'},
        {provide: MISSING_TRANSLATION_STRATEGY, useValue: MissingTranslationStrategy.Ignore},

        {
            provide: TRANSLATIONS,
            useFactory: translationsFactory,
            deps: [LOCALE_ID]
        },
        I18n
  ]
  bootstrap: [AppComponent]
})
export class AppModule { }

2:

Generate an appropriate xlf file(requires using I18n service provided by Pollyfill or i18n template attributes):

ng xi18n -of i18n/messages.en.xlf -f xlf --locale en

3:

Attempt to load the application,and navigate to a specific component that utilized I18n, Angular will produce an error similar to the following:

Missing translation for message "160f1ffbd26df073d0fbd02cf8ce0d8cea7603b0"
Missing translation for message "8aaab7900b39fc1307d70bd5886ba66396668b1f"
...

What is the motivation / use case for changing the behavior?

Ensuring an effective, straightforward, and easy to use approach to the lifecycle of developing internationalized Angular applications.

Environment

ngular CLI: 1.6.3
Node: 9.1.0
OS: win32 x64
Angular: 5.2.0
... animations, common, compiler, core, forms, http
... platform-browser, platform-browser-dynamic, router

@angular/cli: 1.6.3
@angular/compiler-cli: 5.0.0
@angular-devkit/build-optimizer: 0.0.36
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.42
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.3
@schematics/angular: 0.1.11
@schematics/schematics: 0.0.11
typescript: 2.4.2
webpack: 3.10.0

Browser:
- [X] Chrome (desktop) version XX
- [X] Chrome (Android) version XX
- [X] Chrome (iOS) version XX
- [X] Firefox version XX
- [X] Safari (desktop) version XX
- [X] Safari (iOS) version XX
- [X] IE version XX
- [X] Edge version XX

[ocombe]

Please note that the polyfill lib that I wrote is in no way endorsed by Google as an official polyfill for Angular or anything.
That being said, the problem is the same with Angular i18n, independently from that polyfill lib.

[chriskyndrid]

Thank you for the information and your efforts. Without the ability to handle translations outside of the template, it makes Angular quite challenging to achieve a fluid approach to internationalization. Notwithstanding other third party libraries, your initial polyfill is working quite well and as far as what I’ve experimented with provides the most cohesion to the development process.

[steveblue]

I can reproduce this issue just using ./node_modules/.bin/ng-xi18n --i18nFormat=xmb -p tsconfig.json. I wrote a script as a workaround that reads the file and spits out target tags.

[TomDemulierChevret]

Any update on this ?
Because of this issue the "i18nMissingTranslation" param in build config is quitte useless since a newly xlf generated file will make any build fail.

[Exotelis]

I'm working on a frontend for the storage technology Ceph. We are about to add i18n support to our project. This issues is an absolute showstopper for us, because manually adding the tags leads to an empty translated string, but without the tags the compiler fails. So, it seems there is no way that missing translation will be replaced by the default/source language, or am I wrong? We cannot guarantee that all string are translated for every release.

[ocombe]

You should use ngx-i18nsupport that @martinroob developed, it will do that for you and a lot more!

[TomDemulierChevret]

I've used it myself to solve the issue and I can confirm that it does the trick.

[BinaryBrain01]

Any updates on this? I don't want to use another tool to be able to work with this....

[penkin]

On @BinaryBrain01's note above, I'm not keen to have to use another tool to work with Angular's xi18n tools. If I do have to however I'm not sure which tool does what and how to ensure I don't get the errors here.

@TomDemulierChevret how did you get it to not throw the missing target errors?

Thanks.

[TomDemulierChevret]

@penkin I had the following script :

ng xi18n --output-path i18n && ngx-extractor -i src/**/*.ts -o src/i18n/messages.xlf && xliffmerge fr en

which

It uses :

1. the official xi18n tool to extract strings from templates
   2.ngx-extractor from https://github.com/ngx-translate/i18n-polyfill to extract strings in component used with the i18n-polyfill library
2. xliffmerge from https://github.com/martinroob/ngx-i18nsupport to merge the new string to translate with existing translations files

In my setup, since I supported only en and fr, I had therefore 3 files generated/updated by this process :

• i18n/messages.xlf which contains all the keys but no target nodes and therefore no translations
• i18n/messages.fr.xlf and i18n/messages.en.xlf which contains all the keys AND the translations, it does have target nodes and therefore won't make the build fail

The syntax of the commands may have changed thought because the projet hasn't been updated for several months.

[ricardosaracino]

just a note .. i had already generated a messages file with translations without targets and xliffmerge did not fix it .. i needed to delete and start over... this "Target" missing from the original file should be fixed

[neil-119]

Any updates on this? I am getting Missing required <target> element with Angular 9 RC3 since ng xi18n doesn't output empty <target />s. I have to open the .xlf file in notepad and do a find/replace manually by searching for </source> and replacing with </source><target />.

[neil-119]

This issue still exists in Angular 9 RC7. After every ng xi18n, I have to open the generated file and then do a find and replace for </source> and replace with </source><target />.

[koolkabin]

Has this issue been resolved.....?? m fed up with re-working on same stuff repeatedly

[petebacondarwin]

I am soon to work on revamping the translation extraction to better support the new ivy translation pipe-line. I will ensure that these empty <target> tags can be included in the generated output (possibly via an option). Keep an eye on #32912 for progress. Hopefully I can start working on this before the end of the month.

[ronnyek]

I'm still seeing that target problem on cli 9.1.6, and angular 9.1.7

[M-BENNOUR]

I'm still seeing that target problem on cli 9.1.6, and angular 9.1.7

I also use cli 9.1.6 and the command "ng xi18n" generates an xlf file without <target> tags
So when I first use the locl command "npx locl convert ..." to transform xlf into a usable json, I also have target errors.

After some research, it seems (in my case) that xlf generated is not v1.2 strict. The target-language attribute is missing from <file> tag generated xi18n file.
ex: <file source-language="en" target-language=" fr "...>
With that, my locl command works and no need to manually add a <target> tag for each <source> tag (in my case), the source tag is used.

I hope it's useful for someone

[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.}