Extractor no longer extracts the parameter/expression of the interpolated string into disp attribute

🐞 bug report

Is this a regression?

Yes. This used to work in 10.0 and earlier.

Description

Extractor no longer extracts the parameter/expression of the interpolated string into disp attribute

🔬 Minimal Reproduction

Repo is here.

Write an interpolated string that has any parameter. For example

<p i18n>My name is {{name}}</p>

Then run the extractor

ng xi18n --format=xlf2 --output-path src/locale --ivy

The result XLIFF no longer contain disp attribute of it does not contain the parameter/expression used in the interpolated string

      <segment>
        <source>My name is <ph id="0" equiv="INTERPOLATION" disp="&quot;\uFFFD0\uFFFD&quot;"/></source>
      </segment>

This used to be

      <segment>
        <source>My name is <ph id="0" equiv="INTERPOLATION" disp="{{name}};"/></source>
      </segment>

🌍 Your Environment

Angular Version:

Angular CLI: 10.1.0
Node: 12.9.1
OS: win32 x64

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

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.1001.0
@angular-devkit/build-angular     0.1001.0
@angular-devkit/build-optimizer   0.1001.0
@angular-devkit/build-webpack     0.1001.0
@angular-devkit/core              10.1.0
@angular-devkit/schematics        10.1.0
@ngtools/webpack                  10.1.0
@schematics/angular               10.1.0
@schematics/update                0.1001.0
rxjs                              6.6.2
typescript                        4.0.2
webpack                           4.44.1

[Niklas187]

Hey guys, I still have a problem with the “equiv-text” attribute. I am using the latest tag 10.1.6 from the CLI but some translation messages still have incorrect values.

eg.: <ng-container i18n="Update @@update"> <b>{{value1}}:</b> current {{value2}} to new {{value3}} </ng-container>

will be extracted as (with --ivy):

        <source>
                <x id="START_BOLD_TEXT" equiv-text="  &lt;b&gt;{{value1"/>
                <x id="INTERPOLATION" equiv-text="b&gt;{{value1"/>:
                <x id="CLOSE_BOLD_TEXT" equiv-text="}:&lt;/b&gt;"/>
                 current <x id="INTERPOLATION_1" equiv-text="t {{value2"/> 
                 to new <x id="INTERPOLATION_2" equiv-text=" to new {{"/>
       </source>

will be extracted as (without --ivy):

        <source>
                <x id="START_BOLD_TEXT" ctype="x-b" equiv-text="&lt;b&gt;"/>
                <x id="INTERPOLATION" equiv-text="{{value1}}"/>: 
                <x id="CLOSE_BOLD_TEXT" ctype="x-b" equiv-text="&lt;/b&gt;"/>
                current <x id="INTERPOLATION_1" equiv-text="{{value2}}"/>
                to new <x id="INTERPOLATION_2" equiv-text="{{value3}}"/>
        </source>

Is this an issue in my code or in the cli extraction command?

Example Repo https://github.com/Niklas187/ng-xi18n-ivy-bug.git

version:

Angular CLI: 10.1.6 Node: 12.16.0 OS: win32 x64

Angular: 10.1.3 … animations, common, compiler, core, forms, localize … platform-browser, platform-browser-dynamic, router Ivy Workspace: Yes

Package Version

@angular-devkit/architect 0.1001.6 @angular-devkit/build-angular 0.1001.6 @angular-devkit/core 10.1.6 @angular-devkit/schematics 10.1.6 @angular/cli 10.1.6 @angular/compiler-cli 10.1.5 @schematics/angular 10.1.6 @schematics/update 0.1001.6 rxjs 6.6.3 typescript 4.0.3

[petebacondarwin]

OK, I worked out what is going on. The localize stuff relies upon a FileSystem, which the CLI is mocking up to get everything to work. But… internally the extraction is calling absoluteFrom(), which looks for a “current” FileSystem by calling getFileSystem(). This is a kind of global that should be set via setFileSystem() before running the localize code.

But CLI is not calling this and so the “current” FileSystem is different to the one being passed in and it is converting backslashes to forward slashes in paths. So the source-maps are not being loaded from the fake file system that the CLI is providing.

Arguably the CLI shouldn’t have to worry about the “current” FileSystem. I’ll look into the best way to fix this…