[Ivy] [i18n] Translated messages are not loaded for library components

🐞 bug report

Is this a regression?

Yes, the translated messages are picked up by Angular 6-8 and in Angular 9 with Ivy disabled.

Description

Messages for third-party components are extracted successfully when running ng xi18n, but the compiler fails to locate the translated strings during compilation.

Possibly related: https://github.com/angular/angular/issues/32311, https://github.com/angular/angular/pull/32881

🔬 Minimal Reproduction

1. Clone https://github.com/tsvetomir/ivy-i18n-messages
2. Run npm ci
3. Run ng serve --configuration=es or ng serve --configuration=es,production

Result:

• None of the messages declared in CalendarModule are translated.
• The message declared in the application (“Hello, World!”) is translated.
• If enableIvy is set to false in tsconfig.json messages are translated normally.

🔥 Exception or Error

No run-time errors.

🌍 Your Environment

Angular Version:

Angular CLI: 9.0.0-rc.3
Node: 12.13.1
OS: darwin x64
Angular: 9.0.0-rc.3
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.0-rc.3
@angular-devkit/build-angular     0.900.0-rc.3
@angular-devkit/build-optimizer   0.900.0-rc.3
@angular-devkit/build-webpack     0.900.0-rc.3
@angular-devkit/core              9.0.0-rc.3
@angular-devkit/schematics        9.0.0-rc.3
@angular/localize                 9.0.0-rc.0
@ngtools/webpack                  9.0.0-rc.3
@schematics/angular               9.0.0-rc.3
@schematics/update                0.900.0-rc.3
rxjs                              6.5.3
typescript                        3.6.4
webpack                           4.41.2

[petebacondarwin]

Some background…

The “legacy message id format” (used for XLIFF 1.2) has message ids that can only be computed from the original template source. By the time we have compiled a component to ivy there is not enough information left to compute these ids.

The code generated by the Angular compiler (which is used by ngcc) looks like:

I18N_0 = $localize(ɵngcc5.__makeTemplateObject(
    [
      ":kendo.calendar.today|The label for the today button in the calendar header:TODAY"
    ],
    [
      ":kendo.calendar.today|The label for the today button in the calendar header:TODAY"
    ]
));

We can compute “non-legacy” message ids from the information in this generated code, but not legacy message ids. The workaround is that we can tell the Angular compiler that we want to use legacy message ids, and so it will compute them from the template and add them to the generated code. Resulting in code that looks like:

I18N_0 = $localize(ɵngcc5.__makeTemplateObject(
    [
      ":kendo.calendar.today|The label for the today button in the calendar header@@2df64767cd895a8fabe3e18b94b5b6b6f9e2e3f0:TODAY"
    ],
    [
      ":kendo.calendar.today|The label for the today button in the calendar header@@2df64767cd895a8fabe3e18b94b5b6b6f9e2e3f0:TODAY"
    ]
));

Note the addition of @@2df64767cd895a8fabe3e18b94b5b6b6f9e2e3f0, which is the legacy message id.

For this to happen the Angular compiler needs to know that legacy ids are required, ahead of the actual translation merging, which will happen much later in the build pipeline (at the end, in fact).

Currently ngcc has no way to know that the final application is expecting legacy message ids and so is not telling the Angular compiler to add them.

[petebacondarwin]

I think I know what is going on here…

This is what the warnings look like:

No translation found for "826701167553276328" ("TODAY" - "kendo.calendar.today").
No translation found for "589112377451589685" ("Increase value" - "kendo.dateinput.increment").
No translation found for "6980524091606682769" ("Decrease value" - "kendo.dateinput.decrement").

Note that the message IDs are not XLIFF 1.2 format, which is the format that the translation file is using.

---

Normally when compiling we convert the IDs to use the appropriate message ID format for XLIFF 1.2 (aka i18nLegacyMessageIdFormat) which would mean that the compiled template uses the correct message ids.

The problem here is that these templates are being compiled by ngcc, which doesn’t know to use the i18nLegacyMessageIdFormat, so it is just using the regular message id format for these templates.

I think we should be able to get the CLI to tell ngcc what format to use…