Bug 1023258

Correction to the workflow described above: The step that translates B.1 is incorrect.

Project A, version A.1 Created and translated on 2013
Project B, version B.1 Created and translated on 2012

Create a new Project and version C and C.1. which contains the exact source string 'trans'.
Run copy trans on it.
The expected result is that the most recent translation (the one from A.1) is taken. Instead, the copied translation is the one from B.1.

Yuko / Einav


Do you think that as long as the string matches, the newest strings should be used even if it come from other projects? or it should pick the newest translation in the same project? 

In other words, suppose:

Project A, version 1: Document ReadME, has TransA1 (translated in 2013)
Project B, version 1: Document ShowME, has TransB1 (translated in 2012)
Project C, version 1: Document ShowME, has TransC1 (translated in 2011)

The Project C, version 2 is created,
Which translation should Document ShowME used?
Is it TransA1 (the newest in the whole system)
or TransB1 (the newest that share the document name)
or TransC1 (the newest in the same document within same project)

(In reply to Ding-Yi Chen from comment #2)
> Yuko / Einav
> 
> 
> Do you think that as long as the string matches, the newest strings should
> be used even if it come from other projects? or it should pick the newest
> translation in the same project? 
> 
> In other words, suppose:
> 
> Project A, version 1: Document ReadME, has TransA1 (translated in 2013)
> Project B, version 1: Document ShowME, has TransB1 (translated in 2012)
> Project C, version 1: Document ShowME, has TransC1 (translated in 2011)
> 
> The Project C, version 2 is created,
> Which translation should Document ShowME used?
> Is it TransA1 (the newest in the whole system)
> or TransB1 (the newest that share the document name)
> or TransC1 (the newest in the same document within same project)

Hi Ding-Yi,

Are you referring to Zanata project, not versions within the same project?
If so, we need to keep our strings within the same "ovirt" project.
We don't want any other products' strings to be copied to ours.

Kind regards,

Yuko

I think that for the oVirt project this is not an issue because in their copy trans options they are explicitly asking for strings that come from the same project (https://translate.zanata.org/zanata/project/view/ovirt-engine-jrs-branding/copy_trans_opts).

But in general terms, Zanata currently tries to get the 'best match' for any translation. This means: 

1. The match that will be in the 'highest' possible state (i.e. Approved beats fuzzy)
2. The match that meets most of the criteria. So for example, if copy trans is ran with the least conservative options (All conditions are are marked as 'Next Condition'), then copy trans will first try to find a match that meets all three conditions (context, project and document id match); if not found, then one that only meets the last two conditions (project and doc id match); if nothing is found still, then it looks for one with just the last condition, and so forth until it finds something suitable.
3. In the event of finding more than one possible 'best matches', Zanata should (and this is the part that this bug addresses) pick the most recent one.
4. In the very unlikely event of finding more than one possible 'best match' with the exact same translation date, then Zanata just picks one randomly.

The problem is that Zanata has been copying translations based on the highest ID, which is equivalent to selecting translations based on their creation time.  We should have been using their modification time instead.

This is what we think happened:

Strings A1 and B1 were uploaded to the Master version in Zanata and translated there, with translation bugs.

Branch 3.2 created, strings A2 and B2 uploaded, copied from Master with bugs.

QA event #1: String A2's translation is corrected *in Branch 3.2*.  The creation time and ID are unchanged, but the modification time is updated.  The buggy translation is still in A1 in Master.

QA event #2: String B1's translation is corrected *in Master*.  The creation time and ID are unchanged, but the modification time is updated.  The buggy translation is still in B2 in Branch 3.2.

If CopyTrans is run at this point, it will select A2 and B2 from Branch 3.2 because their IDs are higher than the Master versions.  It should instead select A2 and B1, because they were the most recently modified.

NB: If CopyTrans is run at this point, it will copy A2 and B2 to create A3 and B3.  After that happens, even a fixed version of CopyTrans would copy these strings (one of them buggy), because they are the most recently modified.

Bug-Fix implemented. See:
https://github.com/zanata/zanata-server/pull/253

Technical details:
This fix will mean a slight performance hit for copy trans, but it should be negligible on smaller documents. It also means it's a bit more scalable as the query done to perform copy trans will only return a single "best" result for a text flow.

Testing notes:
Although unit tests are taking care of numerous 'simple' scenarios for copy trans, maybe we should try and set up some manual tests for other more complex ones.

This has been merged into both the release and master branches.

Please test the copy trans functionality from both the client and the Web UI.

VERIFIED with Zanata version 3.2-SNAPSHOT (20131114-0037)

Note that the 3.1 test servers are down at the moment.

Ding, is there a reason why you changed this back to ON_QA from verified?

As stated in comment 9, I was not able to verify the release branch.

VERIFIED with Zanata version 3.1.3-SNAPSHOT (20131118-0023)

Closing VERIFIED bugs for Zanata versions <= 3.1.

Closing VERIFIED bugs for Zanata versions <= 3.1.

Closing VERIFIED bugs for Zanata versions <= 3.1.

Closing VERIFIED bugs for Zanata versions <= 3.1.

Closing VERIFIED bugs for Zanata versions <= 3.1.

Closing VERIFIED bugs for Zanata versions <= 3.1.