Detect changed source string in bilingual XLIFF

[nijel]

With xliff it's a bit different - the strings are identified by IDs, so people tend to expect Weblate to do this kind of thing, but it behaves same as with other formats. The easy fix for this is to configure the translation as monolingual, it will then work as expected.

Originally posted by @nijel in https://github.com/WeblateOrg/weblate/issues/3330#issuecomment-568038543

[nijel]

I need some clarification on the specification - what is actually intended behaviour here.

Weblate currently supports XLIFF files without an id attribute on the <trans-unit> tag. These violate XLIFF specification, but exist in the real life. There will be no change for such files.

For files with id (or resname as those are treated similar in this regard), what is the actual expected workflow. Let's have this content:

            <trans-unit id="hello">
                <source>Hello</source>
                <target>Ahoj</target>
            </trans-unit>

It then changes (either via the repository or replace upload) to:

            <trans-unit id="hello">
                <source>Hi</source>
                <target>Ahoj</target>
            </trans-unit>

Right now, Weblate assumes it is a new string because strings are identified by id and source for bilingual files.

When tracking changes, the assumption would be that the string has changed. The question is how to deal with the translation:

• Should it be kept as needing editing? That does not match XLIFF specification, as such state is not set on the unit.
• Should be kept as translated? That might make translators miss the change.

[github-actions[bot]]

This issue has been added to the backlog. It is not scheduled on the Weblate roadmap, but it eventually might be implemented.

In case you need this feature soon, please consider helping or push it by funding the development.

[rsr-cs]

I think it should be marked as "Needs Editing". To match the XLIFF spec (1.2) the state can be set at the -Tag. Would fulfill our requirement. We have currently a stand alone Python-Tool that diffs two XLIFFs. There we add "state="needs-l10n" in the -tag when the source strings do not match.

[nijel]

Okay, in this case I think the cleanest approach will be an add-on which will set the state attribute to the XLIFF in this case.