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

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

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

[BinaryBrain01]

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