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

i18n tagged sub component inputs are bleeding interpolation values #41869

Closed
calummm opened this issue Apr 29, 2021 · 1 comment
Closed

i18n tagged sub component inputs are bleeding interpolation values #41869

calummm opened this issue Apr 29, 2021 · 1 comment
Assignees
Labels
area: i18n P2 The issue is important to a large percentage of users, with a workaround state: has PR
Milestone

Comments

@calummm
Copy link

calummm commented Apr 29, 2021

🐞 bug report

Affected Package

Relating to @angular/localize and Ivy rendering

Is this a regression?

Unsure, as this project was created for Angular 11.

Description

When passing multiple interpolated values into a sub component and marking those inputs as i18n-, the dynamic portion of the input is bleeding into the next dynamic input.

<app-sub-component 
  firstTest="This string contains number 1 {{ numberOne }}" 
  i18n-firstTest
  secondTest="This string should contain number 2 but instead includes 1 {{ numberTwo }}" 
  i18n-secondTest
></app-sub-component>

This error occurs when running before and after extraction and in develop or production configurations. This issue disappears when disabling Ivy but we would prefer to continue with Ivy given its benefits.

🔬 Minimal Reproduction

A stackblitz has been created but does not present the problem. This is likely due to stackblitz and Ivy issues. A github repo has been provided to present the problem locally with Ivy running correctly.

The application can be started with the standard npm i npm start commands.

There is a single page displaying a subcomponent with expected and actual values. The first sub component has i18n attributes, the second does not.

test with i18n "braces again" is showing an incorrect actual of 1 instead of 3.
test with i18n "multi" is showing an incorrect actual of 1 3 1 instead of 1 2 3

🔥 Exception or Error

No explicit error message

🌍 Your Environment

Angular Version:



Angular CLI: 11.2.11
Node: 12.18.3
OS: win32 x64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1102.11
@angular-devkit/build-angular   0.1102.11
@angular-devkit/core            11.2.11
@angular-devkit/schematics      11.2.11
@angular/cli                    11.2.11
@schematics/angular             11.2.11
@schematics/update              0.1102.11
rxjs                            6.6.7
typescript                      4.0.7

@petebacondarwin petebacondarwin self-assigned this Apr 29, 2021
@ngbot ngbot bot modified the milestone: needsTriage Apr 29, 2021
@petebacondarwin petebacondarwin added the P2 The issue is important to a large percentage of users, with a workaround label Apr 29, 2021
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Apr 29, 2021
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Apr 29, 2021
When there are multiple attributes that are marked for i18n translation,
which contain expression bindings, we were generating i18n update op-codes
that did not accurately map to the correct value to be bound in the lView.
Each attribute's bindings were relative to the start of the lView first
attributes values rather than to their own.

This fix passes the current binding index to `generateBindingUpdateOpCodes()`
when processing i18n attributes to account for this.

Fixes angular#41869
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Apr 29, 2021
When there are multiple attributes that are marked for i18n translation,
which contain expression bindings, we were generating i18n update op-codes
that did not accurately map to the correct value to be bound in the lView.
Each attribute's bindings were relative to the start of the lView first
attributes values rather than to their own.

This fix passes the current binding index to `generateBindingUpdateOpCodes()`
when processing i18n attributes to account for this.

Fixes angular#41869
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Apr 30, 2021
When there are multiple attributes that are marked for i18n translation,
which contain expression bindings, we were generating i18n update op-codes
that did not accurately map to the correct value to be bound in the lView.
Each attribute's bindings were relative to the start of the lView first
attributes values rather than to their own.

This fix passes the current binding index to `generateBindingUpdateOpCodes()`
when processing i18n attributes to account for this.

Fixes angular#41869
mhevery pushed a commit that referenced this issue Apr 30, 2021
…41882)

When there are multiple attributes that are marked for i18n translation,
which contain expression bindings, we were generating i18n update op-codes
that did not accurately map to the correct value to be bound in the lView.
Each attribute's bindings were relative to the start of the lView first
attributes values rather than to their own.

This fix passes the current binding index to `generateBindingUpdateOpCodes()`
when processing i18n attributes to account for this.

Fixes #41869

PR Close #41882
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue May 1, 2021
When there are multiple attributes that are marked for i18n translation,
which contain expression bindings, we were generating i18n update op-codes
that did not accurately map to the correct value to be bound in the lView.
Each attribute's bindings were relative to the start of the lView first
attributes values rather than to their own.

This fix passes the current binding index to `generateBindingUpdateOpCodes()`
when processing i18n attributes to account for this.

Fixes angular#41869
mhevery pushed a commit that referenced this issue May 3, 2021
…41912)

When there are multiple attributes that are marked for i18n translation,
which contain expression bindings, we were generating i18n update op-codes
that did not accurately map to the correct value to be bound in the lView.
Each attribute's bindings were relative to the start of the lView first
attributes values rather than to their own.

This fix passes the current binding index to `generateBindingUpdateOpCodes()`
when processing i18n attributes to account for this.

Fixes #41869

PR Close #41912
@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 May 31, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: i18n P2 The issue is important to a large percentage of users, with a workaround state: has PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants