i18n extraction not working for one way binding attributes
See original GitHub issue🐞 bug report
Description
i18n extraction not working for one way binding properties. In my case for the following markup:
<input
formControlName="email"
i18n-placeholder="@@text_emailAddress"
[placeholder]="'E-Mail Adresse'"
type="email">
After calling the extraction tool ng xi18n --format=xlf --output-path=src/locales --out-file=messages.xlf
the part is completely missing in the xlf files. I know i can just use placeholder="E-Mail Adresse"
without square brackets but then i have the issue with IE11 and untouched form fields that are not pristine. And with one way binding this issue is fixed in IE11, but then the translations no longer working 😦
A thing that partially works is when i use i18n-[placeholder]
but then i also have the single quotes within the xlf file…
Here’s a repo with reproduction. Checkout and call the extraction tool ng xi18n
and check the message.xlf file which is generated in the projects root location.
https://github.com/dyingangel666/angular-i18n-extraction-issue
🌍 Your Environment
Angular Version:
@angular-devkit/architect 0.900.4
@angular-devkit/build-angular 0.900.4
@angular-devkit/build-optimizer 0.900.4
@angular-devkit/build-webpack 0.900.4
@angular-devkit/core 9.0.4
@angular-devkit/schematics 9.0.4
@angular/cdk 9.1.0
@ngtools/webpack 9.0.4
@schematics/angular 9.0.4
@schematics/update 0.900.4
rxjs 6.5.4
typescript 3.7.5
webpack 4.41.2
Issue Analytics
- State:
- Created 4 years ago
- Reactions:5
- Comments:10 (6 by maintainers)
I discussed with with @AndrewKushnir and we feel that changing core to handle such cases is not the best way forward. In general inputs are dynamic by nature, it just happens that in this case you are using the fact that it doesn’t apply an attribute to the DOM as a workaround for the IE11 issue.
Instead we should look to fix the IE11 issue in
@angular/forms
so that the pristine state of an input is not broken by having a placeholder there.We would also need to check that the value being passed to the input (attribute with square brackets 😈) is a literal string, so it is not completely trivial. But I am going to discuss with @AndrewKushnir as to whether we can add support for this case.