10000 Incorrect XLIFF documents · Issue #20076 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Incorrect XLIFF documents #20076

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
Closed
ysavourel opened this issue Sep 28, 2016 · 8 comments
Closed

Incorrect XLIFF documents #20076

ysavourel opened this issue Sep 28, 2016 · 8 comments
Labels
Bug Status: Needs Review Translation

Comments

@ysavourel
Copy link
ysavourel commented Sep 28, 2016 •
edited by javiereguiluz
Loading

It seems the XLIFF documents generated by Symfony, whether 1.2 or the new 2.0 are not using the <source> element correctly. It is meant to hold the original text to translate, But in the Symfony files it is used to place some ID (and resname can be used to store the ID).

For example:

<trans-unit id="1">
 <source>homepage.title</source>
 <target>Title - the best place for page titles on the internet.</target>
</trans-unit>

Should be:

<trans-unit id="1" resname="homepage.title">
 <source>Title - the best place for page titles on the internet.</source>
 <target>Title - the best place for page titles on the internet.</target>
</trans-unit>

It's OK to have the original text in <target> when creating the file, but not putting it in <source> makes those XLIFF documents pretty much not usable with most translation tools.
@xabbuh
Copy link
Member
xabbuh commented Sep 29, 2016

How would you know which string to put into the source element if the translation functions have been called with an identifier, but not with a sentence to be translated?

@nvloff
Copy link
nvloff commented Sep 29, 2016

A workflow we use:

  1. Developers add new element with a placeholder for the text
  2. Product team decides the exact wording of the text in the company's base locale(usually en)
  3. Translation files are generated and sent for translators to translate the wording from the production team to a specific language

So there are two distinct steps in the process:

  • Copywriting - create human appropriate text for the translation keys
  • Translation of that text to various languages

Copywriting is very dependent on the project workflow.

If that step needs to be compliant with CAT tools the source text must be present. There are a few approaches for this.

  1. Task that generates the default locale file can add a new entry with empty source that needs to be filled in manually. This is a developer placeholder text. This file can then be passed to the product team that can add the exact wording in the target using a CAT tool.
  2. The default locale file keeps translation keys in <source> as it's now and the product team fills the target with the exact wording needed for the text. This is more inline with current locale files and a bit more native to the idea of using XLIFF for copywriting content. Where the source of the work is an internal key and the output is a client visible text.

What happens here is actually not important at all. The original text for an element is almost never sent to external vendors to be copywrited.

@xabbuh Whatever you use in Symfony to handle step to get key -> text doesn't matter.

Translating contents it's what core to this issue. Translation vendors need a standard compliant XLIFF files to properly handle the translation. So when handling different locales it's key that the source is always a human text that needs to be translated.

Handling XLIFF files from Symfony has always been an issue for us due to the non-standard use of the source. Placing the translatable text in target is quite inconvenient for both vendors and individual translators to handle.

The minimal change we would love to have is that the generator/update tasks for translations can have an output where the source is the text to be translated. And the translation key be determined by the resname attribute of the translation unit. This way XLIFF files can be handled by all CAT tools.

Even if not the default, we can always ask clients to provide us with "proper" XLIFF files if Symfo 8000 ny has mechanisms to generate and use them.

@ysavourel
Copy link
Author

How would you know which string to put into the source element if the translation functions have been called with an identifier, but not with a sentence to be translated?

I suppose you would call the translation function for the source/default language to get the original string.

@tingley
Copy link
tingley commented Oct 5, 2016

Looking at the code XliffFileDumper.php#L85, it looks like this is the current behavior:

  • Each message in the catalogue has an id and a value for the given locale. When the XLIFF is created, that locale is the source locale.
  • Each message is put in its own trans-unit
  • The message id is used for the resname attribute .
  • The message id is also used for the <source> content.
  • The message value in the source locale is used for the <target> content.

As others have said, this is an unusual XLIFF construction that won't be supported well by many tools, which expect to be able to use the <source> content to assist in translation (for example, by looking it up in a translation memory, etc.) So a more standard way to write the XLIFF out would be like this:

  • The message id is used for the resname attribute. (Unchanged)
  • The message value in the source locale is used for the <source> content.
  • For the <target> content, either use the message value again, or leave it blank. (Either one is ok.)

The other issue I noticed is that currently the message value data is enclosed in a CDATA section if it includes any of &<>. This may cause problems in some tools - it's probably better to write those values as entities.

I can put together a pull request along these lines if there's interest.

@mvrhov
Copy link
mvrhov commented Oct 5, 2016

AFAIR, If you set the target to blank, this will be the translation used by symfony. So It should be set to source.

@tingley
Copy link
tingley commented Oct 5, 2016

Good point, thank you @mvrhov.

@xabbuh
Copy link
Member
xabbuh commented Apr 14, 2017

IMO when you want to have some original text in this place you need to pass text and not IDs to the trans() method/filter etc. From the translator's point of view the message key is the string you want to translate.

@symfony/deciders What do you think?

@javiereguiluz javiereguiluz mentioned this issue Apr 28, 2017
Closed
@thewilkybarkid thewilkybarkid mentioned this issue Nov 24, 2018
Merged
fabpot added a commit that referenced this issue Nov 26, 2018
@fabpot
bug #29308 [Translation] Use XLIFF source rather than resname when th…
c0bfdeb 
…ere's no target (thewilkybarkid)

This PR was merged into the 2.8 branch.

Discussion
----------

[Translation] Use XLIFF source rather than resname when there's no target

| Q             | A
| ------------- | ---
| Branch?       | 2.8
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

Relates to #20076 (comment). If there's no `<target>` in an
8179
 XLIFF but there is a `@resname` then that's used rather than the `<source>`.

If I'm using translation keys and my source locale is `en`, then it's a bit redundant to duplicate the `<source>` in the `<target>` in the `en` file (since there is no translation).

This isn't changing the behaviour when `<target>` is present but empty.

(Caveat: I'm definitely not an expert on XLIFF.)

Commits
-------

8633ebb Use XLIFF source rather than resname when there's no target
@javiereguiluz
Copy link
Member

I agree with the latest comment from @xabbuh. This is also one of the "best practices" recommended by Symfony about i18n: https://symfony.com/doc/current/best_practices/i18n.html#translation-keys Including the original content in all translation files may look convenient at first ... but if you have several translation files, it's cumbersome ... because whenever you want to tweak the original translation content, you need to change both the templates and all the translation files. Using translation keys means that you only have to change 1 file, the one corresponding to the "translation" of the main language.

So, let's close this one. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Status: Needs Review Translation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@javiereguiluz @nvloff @mvrhov @tingley @ysavourel @xabbuh @carsonbot
0