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