Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n Ivy extactor: missing type="fmt" inside <source> #38791

Closed
mstawick opened this issue Sep 10, 2020 · 3 comments
Closed

i18n Ivy extactor: missing type="fmt" inside <source> #38791

mstawick opened this issue Sep 10, 2020 · 3 comments
Labels
area: i18n freq2: medium P2 The issue is important to a large percentage of users, with a workaround regression Indicates than the issue relates to something that worked in a previous version state: has PR type: bug/fix
Milestone

Comments

@mstawick
Copy link

馃悶 bug report

Is this a regression?

Kind of. Makes translation system (Crowdin in my case) treat the extracted text as a new string

Description

Given following HTML:
<div i18n>You're using a web browser<br/>that we don't support.</div>

Old extractor would produce:
<source>You&apos;re using a web browser<ph id="0" equiv="LINE_BREAK" type="fmt" disp="&lt;br/&gt;"/>that we don&apos;t support.</source>

But with the --ivy flag it produces:
<source>You&apos;re using a web browser<ph id="0" equiv="LINE_BREAK" disp="&lt;br/&gt;"/>that we don&apos;t support.</source>

so the type="fmt" is missing, changing into a new string.

馃實 Your Environment

Angular Version:


Angular CLI: 10.1.0
Node: 14.10.0
OS: linux x64

Angular: 10.1.1
... animations, common, compiler, compiler-cli, core, forms
... language-service, 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
@angular/cdk                       10.2.0
@angular/cli                       10.1.0
@angular/material                  10.2.0
@angular/material-moment-adapter   10.2.0
@ngtools/webpack                   10.1.0
@schematics/angular                10.1.0
@schematics/update                 0.1001.0
rxjs                               6.6.3
typescript                         4.0.2
webpack                            4.44.1
@ngbot ngbot bot added this to the needsTriage milestone Sep 10, 2020
@petebacondarwin petebacondarwin added engine: ivy regression Indicates than the issue relates to something that worked in a previous version type: bug/fix labels Sep 10, 2020
@petebacondarwin
Copy link
Member

@mstawick thanks for sending this in. I will look into it. It is a bit difficult to accurately identify these "type" attributes for placeholders since the $localize tagged strings do not contain HTML related information.

Can I ask, does the id of the message change? If not, which is what I would expect, why does your tool (Crowdin) treat it as a different message?

@mstawick
Copy link
Author

@petebacondarwin It's because Crowdin doesn't understand anything between the tags - it's just a string. So even though the ID is the same, it thinks that the string has changed, marking it as needing translation. So I guess I can have someone just go through all the languages and approve all the "changed" translations. Thanks for looking into this.

@ngbot ngbot bot modified the milestones: needsTriage, Backlog Sep 17, 2020
@jelbourn jelbourn added the P2 The issue is important to a large percentage of users, with a workaround label Oct 1, 2020
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Oct 23, 2020
The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.

This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder.  This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.

Fixes angular#38791
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Oct 24, 2020
The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.

This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder.  This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.

Fixes angular#38791
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Oct 26, 2020
The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.

This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder.  This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.

Fixes angular#38791
alxhub pushed a commit that referenced this issue Oct 27, 2020
)

The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.

This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder.  This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.

Fixes #38791

PR Close #39398
@alxhub alxhub closed this as completed in 0ed2c4f Oct 27, 2020
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Oct 27, 2020
The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.

This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder.  This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.

Fixes angular#38791
alxhub pushed a commit that referenced this issue Oct 27, 2020
)

The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.

This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder.  This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.

Fixes #38791

PR Close #39459
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: i18n freq2: medium P2 The issue is important to a large percentage of users, with a workaround regression Indicates than the issue relates to something that worked in a previous version state: has PR type: bug/fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants