Bug 874342

Summary: TM "number of times a translation has been used" is wrong
Product: [Retired] Zanata Reporter: Hedda Peters <hpeters>
Component: Component-LogicAssignee: Alex Eng <aeng>
Status: CLOSED CURRENTRELEASE QA Contact: Sean Flanigan <sflaniga>
Severity: unspecified Docs Contact:
Priority: high    
Version: 2.0CC: aeng, sflaniga, ykatabam, zanata-bugs
Target Milestone: ---Keywords: Reopened
Target Release: 2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 2.0.3-SNAPSHOT (20121128-1124) Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-26 03:46:08 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:
Bug Depends On:    
Bug Blocks: 877848    

Description Hedda Peters 2012-11-08 00:33:16 UTC
Description of problem:
The value in the TM results showing how often a particular TM result has been used must be wrong. When entering a whole new translation, then revisiting that entry, the TM result for that particular new translation appears to have been used 10 times already, which is impossible.


Version-Release number of selected component (if applicable):
2.0

How reproducible:
always

Steps to Reproduce:
1. open any document in editor
2. enter a new translation for a string - use a unique test translation
3. move away from that string, then open it again in the editor
  
Actual results:
The TM shows as a result the existing translation (that we have only just entered) along with the information that this has been used 10 times.

Expected results:
This new translation can only have been used 0 times, or 1 time if you want to count the original occurance.

Comment 1 Hedda Peters 2012-11-08 00:35:45 UTC
And just a question: How is this supposed to be calculated? Do re-uses from copytrans and TMmerge count towards it, or just manual re-use by translators via TM?

Comment 2 Alex Eng 2012-11-08 00:39:42 UTC

*** This bug has been marked as a duplicate of bug 872040 ***

Comment 3 Alex Eng 2012-11-08 00:40:21 UTC
This is a known bug. See https://bugzilla.redhat.com/show_bug.cgi?id=872040

Comment 4 Sean Flanigan 2012-11-08 03:25:44 UTC
*** Bug 872040 has been marked as a duplicate of this bug. ***

Comment 5 Sean Flanigan 2012-11-08 03:33:04 UTC
The number is supposed to indicate the number of identical translations in the current locale (from any source, including copytrans and TM merge), for that string, but the problem is that it is actually counting across all languages.

The underlying bug has a more serious effect, because we limit TM matches to 10 in the initial query, then we post-process the results to remove matches for obsolete projects and wrong languages.  If the top 10 matches are all taken from different translations of the same string, Zanata will only show one TM match, or perhaps none at all.

It may not be easy to change the initial query to filter out obsolete projects, but we should at least fix the query to make sure the top 10 matches are coming from the correct locale.

Comment 6 David Mason 2012-11-12 06:56:32 UTC
Fixed in 2.0 branch and merged to 2.1.

Locale is now included in the query so results should only count translations for the current workspace locale. Pre-aggregation result limit has also been increased to 25, i.e. numbers in the '#' column of TM results can now total up to 25.

See: https://github.com/zanata/zanata/commit/c19e6ef43aba690a21d7d64966731684a0745b88
https://github.com/zanata/zanata/commit/2e0c96104769d8c4113f1ea0d10667a7b312d2ba

Comment 11 Sean Flanigan 2012-11-28 01:04:52 UTC
Commits are shown (rolled up) here: https://github.com/zanata/zanata/compare/950ed6efbf...rhbz874342

VERIFIED on 2.1-SNAPSHOT (20121128-1048).  Please merge the feature branch into 'release' as well.

Comment 12 Alex Eng 2012-11-28 01:37:49 UTC
Deployed to  2.0.3-SNAPSHOT test machine.

Comment 13 Sean Flanigan 2012-11-30 01:31:01 UTC
*** Bug 877848 has been marked as a duplicate of this bug. ***