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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

i18n: localize message extraction producing incorrect equiv-text values #39195

Closed
petebacondarwin opened this issue Oct 9, 2020 · 5 comments
Closed

i18n: localize message extraction producing incorrect equiv-text values #39195

petebacondarwin opened this issue Oct 9, 2020 · 5 comments
Assignees
@petebacondarwin
Labels
comp: i18n P3 state: has PR type: bug/fix
Milestone
Backlog

Comments

@petebacondarwin
Copy link
Member

@petebacondarwin petebacondarwin commented Oct 9, 2020

(See #38711 (comment) for original report)

Extraction of i18n messages from the following template HTML:

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

Without ivy: (ctype attributes removed for clarity)

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

With ivy:

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

It seems that there is some offsetting going on, which is making the start and end points in the equiv-text appear in the wrong place. I'll need to debug into this but since these equiv-text attributes are primarily to aid the translator's job, it will not be high on my priority list. Hopefully I can take a look at it later next week or the week after.
@ngbot ngbot bot added this to the Backlog milestone Oct 9, 2020
@ngbot ngbot bot added this to the Backlog milestone Oct 9, 2020
@petebacondarwin petebacondarwin self-assigned this Oct 9, 2020
@petebacondarwin petebacondarwin mentioned this issue Oct 13, 2020
Closed
15 tasks
@petebacondarwin petebacondarwin mentioned this issue Oct 24, 2020
Closed
@petebacondarwin
Copy link
Member Author

@petebacondarwin petebacondarwin commented Oct 26, 2020

OK, so I did some debugging and this issue is caused by us skipping "leading trivia characters" thanks to this 304a12f.

The problem appears because the i18n message begins with a leading space, which is skipped when computing the source-span for the start of the i18n message. This appears to make the source-spans for the inner pieces out of sync.

@petebacondarwin
Copy link
Member Author

@petebacondarwin petebacondarwin commented Oct 26, 2020

Actually things are more complex than just that, although that is part of it...
It seems that there are various places where we are mapping back and forth between source-spans and parsed content, which is causing some source-spans to get out of sync.
I think this needs some considerable thought...

petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Oct 29, 2020
@petebacondarwin
fix(compiler): skipping leading whitespace should not break placehold…
715b90d 
…er source-spans

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes angular#39195
@petebacondarwin petebacondarwin mentioned this issue Oct 29, 2020
Closed
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Oct 31, 2020
@petebacondarwin
fix(compiler): skipping leading whitespace should not break placehold…
9260b6c 
…er source-spans

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes angular#39195
josephperrott added a commit to petebacondarwin/angular that referenced this issue Nov 4, 2020
@petebacondarwin @josephperrott
fix(compiler): skipping leading whitespace should not break placehold…
04a6d42 
…er source-spans

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes angular#39195
mhevery added a commit that referenced this issue Nov 5, 2020
@petebacondarwin @mhevery
fix(compiler): skipping leading whitespace should not break placehold…
b8e9b3d 
…er source-spans (#39486)

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes #39195

PR Close #39486
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Nov 6, 2020
@petebacondarwin
fix(compiler): skipping leading whitespace should not break placehold…
18d2395 
…er source-spans

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes angular#39195
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Nov 6, 2020
@petebacondarwin
fix(compiler): skipping leading whitespace should not break placehold…
c392654 
…er source-spans

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes angular#39195
mhevery added a commit that referenced this issue Nov 6, 2020
@petebacondarwin @mhevery
fix(compiler): skipping leading whitespace should not break placehold…
2b684b7 
…er source-spans (#39589)

Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.

This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.

Fixes #39195

PR Close #39589
@bougnat12
Copy link

@bougnat12 bougnat12 commented Nov 16, 2020

I made some tests with last Angular 11 and I always have bad translation:

    <unit id="MAD.confirmDeleteModalMsg">
      <notes>
        <note category="location">src/app/components/setup/zone/detail/zone-detail.component.html:14,16</note>
        <note category="location">src/app/components/setup/wall/panel-setup/panel-setup.component.html:56,58</note>
        <note category="location">src/app/components/setup/vc/setup-panel/vc-setup-panel.component.html:10,12</note>
        <note category="location">src/app/components/setup/ps/setup-panel/ps-setup-panel.component.html:7,9</note>
      </notes>
      <segment>
        <source> Confirm delete <ph id="0" equiv="INTERPOLATION" disp="e {{uiName"/>?
</source>
      </segment>
    </unit>

for the original text to translate:

<mad-modal-confirm i18n="@@MAD.confirmDeleteModalMsg" i18n-title="@@psSetupPanel.modalConfirmTitle" title="Delete Power Supply" size="md" id="deletePowerSupplyButton" (closed)="deletePowerSupplyConfirm($event)">
  Confirm delete {{uiName}}?
</mad-modal-confirm>

I'm really disappointed because I like the new Angular 11 version but I cannot migrate my project with this show stopper.

For me it's not corrected and I don't understand why this issue was closed.

@petebacondarwin
Copy link
Member Author

@petebacondarwin petebacondarwin commented Nov 16, 2020

@bougnat12 see #39671

@angular-automatic-lock-bot
Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Dec 17, 2020

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 Dec 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@petebacondarwin petebacondarwin

Labels
comp: i18n P3 state: has PR type: bug/fix
Projects
None yet
Milestone
Backlog
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@petebacondarwin @bougnat12