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

fix(ivy): i18n - correctly parse XLIFF placeholders #34155

Closed

Conversation

@petebacondarwin
Copy link
Member

petebacondarwin commented Nov 29, 2019

The ViewEngine translation extractor does not convert - to _ for
placeholders that represent custom elements. For example
<app-component> gets converted to placeholders like
START_TAG_APP-COMPONENT.

In $localize placeholders are expected to be snake-case,
not kebab-case. So we must normalize them when parsing
a translation file that might have been created via the View
Engine translation extractor.

The $localize extraction code will normalize these
placeholders when creating translation files in the first
place.

Fixes #34151

@googlebot

This comment has been minimized.

Copy link

googlebot commented Nov 29, 2019

☹️ Sorry, but only Googlers may change the label cla: yes.

@googlebot googlebot added the cla: yes label Nov 29, 2019
@ngbot ngbot bot modified the milestone: needsTriage Nov 29, 2019
The ViewEngine translation extractor does not convert `-` to `_` for
placeholders that represent custom elements. For example `<app-component>`
gets converted to placeholders like `START_TAG_APP-COMPONENT`.

In `$localize` placeholders are expected to be snake-case, not kebab-case.
So we must normalize them when parsing a translation file that might have
been created via the View Engine translation extractor.

The `$localize` extraction code will normalize these placeholders when
creating translation files in the first place.

Fixes #34151
@petebacondarwin petebacondarwin force-pushed the petebacondarwin:i18n-placeholders branch from 7894e98 to a8399a1 Nov 30, 2019
@petebacondarwin petebacondarwin marked this pull request as ready for review Nov 30, 2019
@petebacondarwin petebacondarwin requested a review from angular/fw-i18n as a code owner Nov 30, 2019
Copy link
Contributor

AndrewKushnir left a comment

LGTM 👍

@thekip

This comment has been minimized.

Copy link

thekip commented Dec 2, 2019

Thanks for fixing, BTW, you wrote

the ViewEngine translation extractor does not convert - to _

Means there might be Ivy message extractor as well which should not have such problem, how to use it?

Now for non-AngularCLI project I use this snippet to extract messages from template HTML:

const {DEFAULT_INTERPOLATION_CONFIG, HtmlParser, MessageBundle, Xliff} = require('@angular/compiler');

//...
catalog.updateFromTemplate(html, relative, DEFAULT_INTERPOLATION_CONFIG);
//...
@petebacondarwin

This comment has been minimized.

Copy link
Member Author

petebacondarwin commented Dec 2, 2019

The next-generation message extraction is still a WIP which will land after v9.0.0 - see #32912

mhevery added a commit that referenced this pull request Dec 2, 2019
The ViewEngine translation extractor does not convert `-` to `_` for
placeholders that represent custom elements. For example `<app-component>`
gets converted to placeholders like `START_TAG_APP-COMPONENT`.

In `$localize` placeholders are expected to be snake-case, not kebab-case.
So we must normalize them when parsing a translation file that might have
been created via the View Engine translation extractor.

The `$localize` extraction code will normalize these placeholders when
creating translation files in the first place.

Fixes #34151

PR Close #34155
@mhevery mhevery closed this in d529b55 Dec 2, 2019
@petebacondarwin petebacondarwin deleted the petebacondarwin:i18n-placeholders branch Dec 2, 2019
@angular-automatic-lock-bot

This comment has been minimized.

Copy link

angular-automatic-lock-bot bot commented Jan 2, 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 Jan 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.