-
Notifications
You must be signed in to change notification settings - Fork 27.1k
ng xi18n Xliff no longer produces empty <target/> translations causing the Xliff parser to fail #21690
Description
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