fix(localize): render placeholder types in extracted XLIFF files - #39398
petebacondarwin wants to merge 1 commit into
Conversation
AndrewKushnir
left a comment
There was a problem hiding this comment.
LGTM, thanks for the fix @petebacondarwin 馃憤
|
I see that you just added the If you want your PR to be merged, it has to pass all the CI checks. If you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help. |
ec3a0f6 to
c18ac2a
Compare
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
c18ac2a to
ec5ce76
Compare
|
Hi @petebacondarwin! This PR conflicts with |
) 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
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
The previous ViewEngine extraction tooling added
ctypeandtypeattributes 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