Description of problem: When pushing XLIFF content, it is possible for the translation files to have older source strings than the source files, but with the same trans-unit ids. For instance: source file: ... <trans-unit id="greeting"> <source>Hello World</source> </trans-unit> ... trans file: ... <trans-unit id="greeting"> <source>Hello</source> <target>Hallo</target> </trans-unit> ... NB: even though the ids match, "Hallo" is not a valid translation of the current source "Hello World". Version-Release number of selected component (if applicable): 2.0.0 How reproducible: 100% Steps to Reproduce: 1. Push both files above 2. Pull the translation Actual results: greeting has the incorrect translation "Hallo" Expected results: greeting should be untranslated Additional info: We may need to change the way we generate resIds for XLIFF files, to be similar to the Gettext approach, so that the server will reject the outdated translation. If so, we will need a migration path for existing content in the database. Alternatively the client may be able to load source and target files and compare the source element. We will need to weigh both approaches. We have a similar problem for Properties files.
See bug 873500 for Properties files.
We should add sourceContentHash to TextFlowTarget, and have the XLIFF and Properties clients pass a hash of the source content. Then the server could verify that the sourceContentHash matches the current version of the HTextFlow, else reject the translation.
*** Bug 873500 has been marked as a duplicate of this bug. ***
*** Bug 873930 has been marked as a duplicate of this bug. ***
As of Zanata 3.2.0, TextFlowTarget includes a sourceHash property. If sourceHash is provided, TranslatedDocResourceService on the server will check that the sourceHash matches the HTextFlow before persisting the HTextFlowTarget. The gettext formats (including offlinepo) now provide sourceHash when pushing to the server, but this still needs to be implemented for xliff and properties files.
Pull request (WIP): https://github.com/zanata/zanata-common/pull/1
Also https://github.com/zanata/zanata-client/pull/14
Both pull requests have been updated.
Note that the required changes for PO files were in server commit 0a3971e, common commit 24c7951 and client commit 880c69a157. Source content checking for PO files requires client >= 3.2.0, and only works with Zanata server >= 3.2.0. (Note that there was no bz for that change.)
We have similar bug 1194543 that is implementing the solution for formats that use positional identifiers.
(In reply to Michelle Kim from comment #10) > We have similar bug 1194543 that is implementing the solution for formats > that use positional identifiers. That bug is about source text that changes which identifier it uses (e.g. due to position change), but this bug is about translations being pushed that were translated from an old version of the source. I do not think they are related since the cause and the fixes for them are different.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-336