extract-i18n produces file that breaks build (when two <a href=""> tags are embedded inside the translation)

[mstawick]

🐞 Bug report

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Not sure if it's the extraction process or the build process

Is this a regression?

I don't think so - I think it's been there since localize was introduced

Description

Having a specific combination of tags within the translation unit will produce a translation file that breaks the build. Please see the reproduction section.

🔬 Minimal Reproduction

Since it has to do with localize and building the project, I'm attaching a zipped reproduction.

Having such a piece of HTML:
<div class="some-class" i18n>This breaks build <a href="https://foo.com">One link</a> the second link causes error <a href="https://bar.com">Another link</a></div>

Will produce such translate unit (xlf2, with target duplicated from source):

    <unit id="4984752463945187369">
      <notes>
        <note category="location">src/app/app.component.html:1</note>
      </notes>
      <segment>
        <source>This breaks build <pc id="0" equivStart="START_LINK" equivEnd="CLOSE_LINK" type="link" dispStart="&lt;a href=&quot;https://foo.com&quot;&gt;" dispEnd="&lt;/a&gt;">One link</pc> the second link causes error <pc id="1" equivStart="START_LINK_1" equivEnd="CLOSE_LINK_1" type="other" dispStart="&lt;a href=&quot;https://bar.com&quot;&gt;">Another link</pc></source>
        <target>This breaks build <pc id="0" equivStart="START_LINK" equivEnd="CLOSE_LINK" type="link" dispStart="&lt;a href=&quot;https://foo.com&quot;&gt;" dispEnd="&lt;/a&gt;">One link</pc> the second link causes error <pc id="1" equivStart="START_LINK_1" equivEnd="CLOSE_LINK_1" type="other" dispStart="&lt;a href=&quot;https://bar.com&quot;&gt;">Another link</pc></target>
      </segment>
    </unit>

which then causes the build to fail (ng build --localize) with error message:
There is a placeholder name mismatch with the translation provided for the message "8220418496226875748" ["ae049955b00b7c32e119cf04537cb0de7609cdb2", "4984752463945187369"] ("This breaks build {$START_LINK}One link{$CLOSE_LINK} the second link causes error {$START_LINK_1}Another link{$CLOSE_LINK}"). The translation contains a placeholder with name CLOSE_LINK_1, which does not exist in the message.

When tested with bare tags: <a>Text</a>, without the href attribute, it worked fine.

🔥 Exception or Error

There is a placeholder name mismatch with the translation provided for the message "8220418496226875748" ["ae049955b00b7c32e119cf04537cb0de7609cdb2", "4984752463945187369"] ("This breaks build {$START_LINK}One link{$CLOSE_LINK} the second link causes error {$START_LINK_1}Another link{$CLOSE_LINK}").
The translation contains a placeholder with name CLOSE_LINK_1, which does not exist in the message.

🌍 Your Environment

Angular CLI: 11.0.7
Node: 14.14.0
OS: linux x64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.7
@angular-devkit/build-angular   0.1100.7
@angular-devkit/core            11.0.7
@angular-devkit/schematics      11.0.7
@angular/cli                    11.0.7
@schematics/angular             11.0.7
@schematics/update              0.1100.7
rxjs                            6.6.6
typescript                      4.0.7

i18n-tags-bug.tar.gz

[petebacondarwin]

Thanks for posting this issue. I'll look into it tomorrow.

[petebacondarwin]

Thanks for the great reproduction. I confirm this is a bug. I think it should be fairly straightforward to fix. I'll work on it later today.

[petebacondarwin]

Note to self: the second link is being rendered in the XLIFF as <pc type="other">, with no dispEnd attribute, rather than type="link".

I have lots to learn. It have to fully understand everything you mentioned .My iOS is compromised I know my clipboard altered I’m getting a third-party keyboard Sent from ProtonMail Mobile

…

On Wed, Mar 10, 2021 at 3:42 AM, Pete Bacon Darwin ***@***.***> wrote: Note to self: the second link is being rendered in the XLIFF as <pc type="other">, with no dispEnd attribute, rather than type="link". — You are receiving this because you are subscribed to this thread. Reply to this email directly, [view it on GitHub](#41142 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ATAGXAA5Z3TUVIEJV7WGC3TTC4WHLANCNFSM4Y4MQY4A).

I just realized it’s not the iOS jaykali/ I have the infection : i’m very good at taking now we’re on I’ve done it for years for fun. I didn’t mean to get this though, I almost got to figure out what to do Sent from ProtonMail Mobile On Wed, Mar 10, 2021 at 3:38 AM, Pete Bacon Darwin <notifications@github.com> wro”Thanks for the great reproduction. I confirm this is a bug. I think it should be fairly straightforward to fix. I'll work on it later today.

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, [view it on GitHub](#41142 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ATAGXACIZ3CZSPG36Y3WOD3TC4VZJANCNFSM4Y4MQY4A).

[petebacondarwin]

Next note to self... the problem is that in the template compiler we are assuming that the first and second </a> closing tags can be considered equal, while the XLIFF serializer does not.

We could hack the serializer to workaround this, but it would result in the source-span for the 2nd closing tag being incorrectly mapped to the first closing tag.

I think the correct solution is to repair the template compiler. Unfortunately, this change would change the generated message IDs for such messages, which would be a breaking change, and not so easy to automatically migrate.

Perhaps we could mitigate the breaking change by avoiding a change to the legacy message IDs, which are due to be migrated anyway. This would result in only affecting users who had turned off legacy message IDs in their projects, which includes all newly created CLI projects.