8000 Missing XLIFF translations if state is needs-translation · Issue #54541 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

Missing XLIFF translations if state is needs-translation #54541

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

Closed
kevinpapst opened this issue Apr 10, 2024 · 1 comment
Closed

Missing XLIFF translations if state is needs-translation #54541

kevinpapst opened this issue Apr 10, 2024 · 1 comment

Comments

@kevinpapst
Copy link

Symfony version(s) affected

6.4

Description

A recent change added a BC break in the XLIFF translation reader, which suddenly stopped returning translations in the state needs-translation.

I am giving a real world example, why I think this might not be the best solution:

Weblate (probably known to most users of the community) will switch all language versions of a key to this state, if the source language is updated.

This example in the source version en was changed (a comma was added):

      <trans-unit id="d9m85KE" resname="locale" xml:space="preserve">
        <source>Format for time, date and currency</source>
        <target>Format for time, date, and currency</target>

Afterward more than 20 language version were switched to <target state="needs-translation">, e.g. de:

      <trans-unit id="d9m85KE" resname="locale" xml:space="preserve">
        <source>Format for time, date, and currency</source>
        <target state="needs-translation">Format für Zeit, Datum und Geld</target>

Before this recent change the language variant was still used. Now, instead of showing the de translations, the english version is used. The translators see an existing translation in their tool, but an english text in the software itself, which makes them ask if the software / translation is broken.

@nicolas-grekas you mentioned

I added state="needs-translation" to all that aren't translated, as defined by the xliff spec for this purpose.

I tried to find reasoning here (search for needs-translation on the page) and it says Indicates that the item needs to be translated.. Which doesn't necessarily mean it shouldn't be used, if it exists.

For my application this a major BC change, because now I cannot allow anyone to change base translations, as it always removes the existing translations in one of the 25+ languages from the frontend. I already had to patch dozens of translations, which were suddenly english in all frontend languages, while in reality they have translations.

I'd argue against this check entirely, as the XLIFF reader shouldn't make assumptions about the usage of this flag (or the workflow of the used translation tool), but I understand why it was introduced (still a BC break though).
But can we please make this behavior configurable?

How to reproduce

See explanation above. Translations with the attribute state="needs-translation" are now ignored.

Possible Solution

Remove the check or make the behavior configurable.

Additional Context

No response

@nicolas-grekas
Copy link
Member

Thanks for the report. In #54564, I'm proposing to fix this by skipping state=needs-review entries only when the source and the target are the same.

nicolas-grekas added a commit that referenced this issue Apr 12, 2024
…en source == target (nicolas-grekas)

This PR was merged into the 5.4 branch.

Discussion
----------

[Translation] Skip state=needs-translation entries only when source == target

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix #54541
| License       | MIT

Commits
-------

155d23f [Translation] Skip state=needs-translation entries only when source == target
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
0