Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 896332

Summary:	CopyTrans should use the most recent matching translation
Product:	[Retired] Zanata	Reporter:	Tim Hildred <thildred>
Component:	Performance	Assignee:	Alex Eng <aeng>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ding-Yi Chen <dchen>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	aeng, camunoz, pahuang, sflaniga, ykatabam, zanata-bugs
Target Milestone:	---
Target Release:	2.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	2.1.3-SNAPSHOT (20130122-0944)	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-26 04:06:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tim Hildred 2013-01-17 04:20:55 UTC

Description of problem:
Currently, if there are more than 1 100% matches for a string, the most used one is prefilled in the translation. 

If something has changed in how a document is translated, the more recent 100% match might be more appropriate then the most used. 

The ability to set this preference at several different levels would be helpful, and save translators time.

Comment 2 Sean Flanigan 2013-01-17 06:33:37 UTC

Are we talking about TM merge (in the editor), or about CopyTrans (which happens on document upload, and can be run manually from the project management page)?

Comment 9 Carlos Munoz 2013-01-21 09:56:17 UTC

After looking at this in detail, I've found a possible solution for you to try out Alex:

1. Remove the grouping by 'match' at the end of the query. (Leave the other grouping by text flow)

2. Remove the 'match' column in the select portion of the hql query. 
The fact that we are getting the Text Flow Target match from that column instead of the max column is the problem.

3. In CopyTransServiceImpl.copyTransPass (around line 230) remove the line that reads 

HTextFlowTarget matchingTarget = (HTextFlowTarget)results.get(0);

and replace it with something like

HTextFlowTarget matchingTarget = entityManager.findById((Long)results.get(1));

Hibernate Cache should help us minimize the impact of that extra query.

Keep in mind that because of step #2, those indexes have changed, so the line that reads

HTextFlow originalTf = (HTextFlow)results.get(1);

should now read

HTextFlow originalTf = (HTextFlow)results.get(0);


I have not been able to test this, but try it out and let me know if it solves the issues.

Comment 10 Alex Eng 2013-01-21 22:37:11 UTC

Test with Prod data, it appears to be issue with copyTrans query. Implementing fix now.

Comment 11 Alex Eng 2013-01-21 22:59:36 UTC

Implemented fix in 2.1.3-SNAPSHOT and 2.2-SNAPSHOT

See
https://github.com/zanata/zanata/commit/1d0fcd558fd00d5da0f42f83e25af13426149867
https://github.com/zanata/zanata/commit/446f04a0d05037ad8ef0efa5bf015fe903ec89a3

Comment 12 Ding-Yi Chen 2013-01-22 05:19:57 UTC

VERIFIED with Zanata version 2.1.3-SNAPSHOT (20130122-0944)