Skip to content

[Translation] Support name attribute on the xliff2 translator loader #35373

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.

Sign up for GitHub

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
Merged
merged 1 commit into from
Feb 9, 2020
Merged

[Translation] Support name attribute on the xliff2 translator loader #35373

merged 1 commit into from
Feb 9, 2020

Conversation

Taluu
Copy link
Contributor

@Taluu Taluu commented Jan 17, 2020

Q A
Branch? master
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fix #32048
License MIT
Doc PR not done yet

Support using the name attribute on the unit element in xliff 2.0 to use as the "translation key" rather than always relying on the <source> content, as was done on the xliff 1.2.

@Taluu Taluu force-pushed the translator/xliff-2-support-name-as-key branch 2 times, most recently from 06f4b27 to 715f670 Compare January 17, 2020 16:50
@nicolas-grekas nicolas-grekas added this to the next milestone Jan 20, 2020
nicolas-grekas
nicolas-grekas reviewed Jan 20, 2020
View reviewed changes
Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name seems the way to go.

What happens when there are multiple segments in the <unit>?
Can we find any loader in another technology that uses "name" like that?
E.g. do software for translators work this way?
I think we should check this before.

@Taluu
Copy link
Contributor Author

Taluu commented Jan 20, 2020 •
edited
Loading

In the xliff 1.2 loader, there is a support for resName which isn't there anymore on xliff 2. But, on 1.2, there is no name.

According to http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#name :

Resource name - the original identifier of the resource corresponding to the Extracted or .

For example: the key in the key/value pair in a Java properties file, the ID of a string in a Windows string table, the index value of an entry in a database table, etc.

So seems fitting here... But it is not available for <segment> (only for <unit> and <group>). We could probably detect if there is more than one segment and then deny ? Or use id instead, as it's optional for <segment> according to the xliff2 specs ?

The problem comes with indeed translator tools (e.g memsource in my case) and ICU handling : We would like to use the ICU notation, and proceeding on xliff2 with how it's proposed in the doc doesn't do well with translator tool.

They base themselves on the source element, and provide a translation in target... so for them, the source is not translatable. While having support for the name key allows to use the ICU basic string in the source, so the tool can translate how it can.

@Taluu Taluu force-pushed the translator/xliff-2-support-name-as-key branch 2 times, most recently from 6174bac to 37b3114 Compare January 20, 2020 12:02
@nicolas-grekas nicolas-grekas changed the title Support name attribute on the xliff2 translator loader [Translation] Support name attribute on the xliff2 translator loader Feb 7, 2020
@fabpot
Copy link
Member

fabpot commented Feb 9, 2020

Thank you @Taluu.

@fabpot fabpot mentioned this pull request Feb 9, 2020
Closed
fabpot added a commit that referenced this pull request Feb 9, 2020
@fabpot
feature #35373 [Translation] Support name attribute on the xliff2 tra…
9bfa258 
…nslator loader (Taluu)

This PR was merged into the 5.1-dev branch.

Discussion
----------

[Translation] Support name attribute on the xliff2 translator loader

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | Fix #32048
| License       | MIT
| Doc PR        | not done yet

Support using the `name` attribute on the `unit` element in xliff 2.0 to use as the "translation key" rather than always relying on the `<source>` content, as was done on the xliff 1.2.

Commits
-------

37b3114 Support name attribute on the xliff2 translator loader
@fabpot fabpot merged commit 37b3114 into symfony:master Feb 9, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
@fabpot fabpot mentioned this pull request May 5, 2020
Merged
@idybil idybil mentioned this pull request Jun 2, 2020
Closed
@Taluu Taluu deleted the translator/xliff-2-support-name-as-key branch July 6, 2020 09:40
@Nyholm Nyholm mentioned this pull request Feb 24, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nicolas-grekas nicolas-grekas nicolas-grekas left review comments

@fabpot fabpot fabpot approved these changes

Assignees
No one assigned
Labels
Feature Status: Reviewed
Projects
None yet
Milestone
5.1
Development

Successfully merging this pull request may close these issues.

[Translation] Support name attribute in XLIFF 2.0 loader
4 participants
@Taluu @fabpot @nicolas-grekas @carsonbot