Bug 874342 - TM "number of times a translation has been used" is wrong
TM "number of times a translation has been used" is wrong
Status: CLOSED CURRENTRELEASE
Product: Zanata
Classification: Community
Component: Component-Logic (Show other bugs)
2.0
Unspecified Unspecified
high Severity unspecified
: ---
: 2.0
Assigned To: Alex Eng
Sean Flanigan
: Reopened
: 872040 877848 (view as bug list)
Depends On:
Blocks: 877848
  Show dependency treegraph
 
Reported: 2012-11-07 19:33 EST by Hedda Peters
Modified: 2013-02-25 22:46 EST (History)
4 users (show)

See Also:
Fixed In Version: 2.0.3-SNAPSHOT (20121128-1124)
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-25 22:46:08 EST
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)

  None (edit)
Description Hedda Peters 2012-11-07 19:33:16 EST
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-07 19:35:45 EST
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-07 19:39:42 EST

*** This bug has been marked as a duplicate of bug 872040 ***
Comment 3 Alex Eng 2012-11-07 19:40:21 EST
This is a known bug. See https://bugzilla.redhat.com/show_bug.cgi?id=872040
Comment 4 Sean Flanigan 2012-11-07 22:25:44 EST
*** Bug 872040 has been marked as a duplicate of this bug. ***
Comment 5 Sean Flanigan 2012-11-07 22:33:04 EST
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 01:56:32 EST
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-27 20:04:52 EST
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-27 20:37:49 EST
Deployed to  2.0.3-SNAPSHOT test machine.
Comment 13 Sean Flanigan 2012-11-29 20:31:01 EST
*** Bug 877848 has been marked as a duplicate of this bug. ***

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