Bug 896332 - CopyTrans should use the most recent matching translation
Summary: CopyTrans should use the most recent matching translation
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Performance   
(Show other bugs)
Version: unspecified
Hardware: Unspecified Unspecified
unspecified
medium
Target Milestone: ---
: 2.1
Assignee: Alex Eng
QA Contact: Ding-Yi Chen
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-17 04:20 UTC by Tim Hildred
Modified: 2013-02-26 04:06 UTC (History)
6 users (show)

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: ---


Attachments (Terms of Use)

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 12 Ding-Yi Chen 2013-01-22 05:19:57 UTC
VERIFIED with Zanata version 2.1.3-SNAPSHOT (20130122-0944)


Note You need to log in before you can comment on or make changes to this bug.