ng extract-i18n extracts incorrect equiv-text value

[kamilchlebek]

🐞 bug report

Affected Package

The issue is caused by package @angular/localize

Is this a regression?

Yes, the previous version in which this bug was not present was: v10

Description

Component template (it's usually formatted like this by prettier):

<div i18n>
  test {{ title }}
</div>

Running ng xi18n in angular v10, produced output that contained source element that looked:

<source>
   test <x id="INTERPOLATION" equiv-text="{{ title }}"/>
</source> 

Now after running ng extract-i18n it's:

<source> test <x id="INTERPOLATION" equiv-text="t {{ title "/>
</source>

🔬 Minimal Reproduction

https://github.com/kamilchlebek/equiv-text-angular11 (see messages.xlf)

🌍 Your Environment

(it's a brand new project created using ng new)

Angular Version:

Angular CLI: 11.0.1
Node: 12.16.1
OS: linux x64

Angular: 11.0.0
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.1
@angular-devkit/build-angular   0.1100.1
@angular-devkit/core            11.0.1
@angular-devkit/schematics      11.0.1
@angular/cli                    11.0.1
@schematics/angular             11.0.1
@schematics/update              0.1100.1
rxjs                            6.6.3
typescript                      4.0.5

[petebacondarwin]

I can confirm this bug. I am looking into it now.

[petebacondarwin]

Just to give an update... these equiv-text properties are computed via the source-map from the generated code (e.g. app.component.js) back to the original source (e.g. app.component.html). In this case the source-map that was generated for this file is not accurate. See this visualization.

I think this is a bug in the Angular compiler, similar to one that I fixed recently. See #39486.

Investigating further...

[kamilchlebek]

That's bad 😞

As I workaround I could switch prettier htmlWhitespaceSensitivity to strict. Then the markup will look ugly:

<div i18n
  >test {{ title }}</div
>

but messages.xlf are okay.

Of course I'd rather avoid that for div and other elements being display:block by default.

https://prettier.io/blog/2018/11/07/1.15.0.html#whitespace-sensitive-formatting

[petebacondarwin]

I have found the cause of the problem. When we process the i18n tags, we run the processing twice. Once before whitespace has been removed (which results in correct source-spans) and then again after whitespace has been collapsed (which results in incorrect source-spans for placeholders).

See

angular/packages/compiler/src/render3/view/template.ts

Lines 2085 to 2088 in 1f95618

	if (i18nMetaVisitor.hasI18nMeta) {
	rootNodes = html.visitAll(
	new I18nMetaVisitor(interpolationConfig, /* keepI18nAttrs */ false), rootNodes);
	}

A fix is in the works...

[petebacondarwin]

Here's the fix: #39717. It was not trivial so it took a bit longer than I thought.

[kamilchlebek]

Great, thank you! Can't wait to see it released 🚀

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