You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which @angular/* package(s) are the source of the bug?
localize
Is this a regression?
No
Description
When a component's html file has an async pipe in it, all the items in the file marked for i18n extraction get incorrect equiv-text contents if they have a variable in them.
This makes it difficult to maintain code as adding an async pipe in a file throws a bunch of diffs in the xlf file. This is also problematic for our translators when the equiv-text blocks do not contain their expected context.
Observed Conditions that trigger this problem / Steps to reproduce: (Check test-bad.component.html in the linked project)
The html file should have an async pipe in it, like:
The item tagged for extraction should contain a variable or nested HTML or both to trigger placeholders in the xlf file.
The variable or nested HTML should be the first item in the tagged HTML element and should have no leading whitespace, for example: <span i18n="@@test"> {{test}} hello</span> will extract properly, but: <span i18n="@@test">{{test}} hello</span> will not have accurate equiv-text in its extraction.
Stackblitz link to a minimal reproduction of the bug
Please notice the xlf file linked and compare the <source> of trans-units with id badComponentTitle and goodComponentTitle in the linked stackblitz project. This is one of the more "colorful" examples that make our work inconvenient with the unexpected characters it has extracted. The only difference is that test-bad-component has an async pipe in its HTML file, while test-good-component does not.
Please provide the environment you discovered this bug in (run ng version)
Which @angular/* package(s) are the source of the bug?
localize
Is this a regression?
No
Description
When a component's html file has an async pipe in it, all the items in the file marked for i18n extraction get incorrect equiv-text contents if they have a variable in them.
Example:
For the HTML content
Expected
<source>
for the trans-unit in the xlf file is:But the
<source>
I get is:This makes it difficult to maintain code as adding an async pipe in a file throws a bunch of diffs in the xlf file. This is also problematic for our translators when the equiv-text blocks do not contain their expected context.
Observed Conditions that trigger this problem / Steps to reproduce: (Check
test-bad.component.html
in the linked project)<span i18n="@@test"> {{test}} hello</span>
will extract properly, but:<span i18n="@@test">{{test}} hello</span>
will not have accurate equiv-text in its extraction.Stackblitz link to a minimal reproduction of the bug
https://stackblitz.com/edit/stackblitz-starters-1zcqro?file=angular-hello%2Fsrc%2Flocale%2Fmessages.xlf
cd angular-hello
npm i
To generate xlf file: ng extract-i18n angular-hello
To run the app: ng serve --open
Please notice the xlf file linked and compare the
<source>
of trans-units with idbadComponentTitle
andgoodComponentTitle
in the linked stackblitz project. This is one of the more "colorful" examples that make our work inconvenient with the unexpected characters it has extracted. The only difference is thattest-bad-component
has an async pipe in its HTML file, whiletest-good-component
does not.Please provide the environment you discovered this bug in (run
ng version
)The text was updated successfully, but these errors were encountered: