Bug 812730 - RFE: translation memory merge : pre-fill new version with existing translations from the previous version of same project
Summary: RFE: translation memory merge : pre-fill new version with existing translatio...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Usability
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
: 1.7
Assignee: Patrick Huang
QA Contact: Ding-Yi Chen
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-16 06:11 UTC by Hedda Peters
Modified: 2012-09-13 01:18 UTC (History)
6 users (show)

Fixed In Version: 1.7-SNAPSHOT (20120711-0026)
Doc Type: Bug Fix
Doc Text:
Cause User wants to reuse previous translation work from translation memory(TM) Consequence User need to click one by one to reuse TM even if they know most of the entries should have TM available from previous work. Change We will perform TM merge one page at a time so that user can see the result on screen. We will check following rules when auto-filling untranslated or fuzzy(rhbz856043) text flow. If one of below is true, we won't set status to 'approved' automatically. 1. match percentage is not 100% 2. project name is different 3. doc id (full path of file) is different 4. resource id or message context is different Condition 2, 3, 4 will be configurable. Options are: 1. Set as fuzzy 2. reject auto translation 3. Set as approved (ignore the difference) For fuzzy translations, it will be auto translated if and only if TM merge can find a match that can be set as approved. What now happens when the actions or circumstances above occur. User can reuse TM results on a page by page basis and saves time to select and click on each row.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-11 05:14:13 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 831035 0 unspecified CLOSED RFE: On-Demand copy trans. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 856043 0 unspecified CLOSED Translation Memory Merge - enhancement and bug fix 2021-02-22 00:41:40 UTC

Internal Links: 831035 856043

Comment 1 Runa Bhattacharjee 2012-04-16 06:27:24 UTC
The translations from an earlier version is now available as matches from Translation Memory. What we could perhaps have is a manual 'auto-fill from TM' feature with tunable settings. For instance, 
1. only allow autofill for translations with 100% matches,
2. allow autofull for translations with x-100% match, but add a 'needs review' flag to the strings modified etc.

Does that serve the purpose here?

Comment 2 Hedda Peters 2012-04-16 06:35:26 UTC
That sounds good, Runa, I would also strongly suggest to then being able to specify the project/version I want the translations to be taken from.

Comment 3 Sean Flanigan 2012-06-14 07:41:15 UTC
If you push a project version v1, then translate it, then push another version v2 which is very similar (including the same filenames), copyTrans should already be capable of reusing most of it.  It's when you enter v1 translations after v2 has been created that copyTrans really lets you down.  (Or when the filenames change for some reason.)

The original description for this bug sounds like a request for manual "copyTrans" [1].  

Autofill (or TM merge) is certainly a very useful idea too, and could reuse translations in cases where copyTrans can't.

But as far as TM merge goes, our TM is currently global, so it's somewhat expensive to limit it by project/version for this one case.  But if we're careful to mark the reused translations as 'needs review' when the text or metadata (eg project name) doesn't quite match, it shouldn't be a big problem.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=831035

Comment 4 Patrick Huang 2012-06-15 02:26:55 UTC
We will perform TM merge one page at a time so that user can see the result on screen.
We will check following rules when auto-filling untranslated text flow. If one of below is true, we won't set status to 'approved' automatically. 
1. match percentage is not 100%
2. project name is different
3. doc id (full path of file) is different
4. resource id is different

Condition 2, 3, 4 will be configurable. Options are:
1. Set as fuzzy
2. Skip auto fill
3. Set as approved

Comment 5 Patrick Huang 2012-07-01 23:39:26 UTC
committed into master:
https://github.com/zanata/zanata/tree/3cb21a01db4a358a71f8fe4d8adb408c8484e7c8

Comment 6 Sean Flanigan 2012-07-02 06:35:16 UTC
The following is the original description from Hedda Peters (with project names removed):


User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

Feature Request:

As a project maintainer, I want to pre-fill a new version of a given project with existing translations from the previous version of that same project, in order to save myself and the translators time for maintaining/translating.

i.e, creating version RHEL Installation Guide 6.3 on Zanata, I want to be able to auto-fill the files with existing translations from RHEL Installation Guide 6.2. 

Currently the merge of old/new version has to be done outside of Zanata, using scripts written a long time back by Manuel. Pitfalls:
- scripts need to be installed first
- process of using those scripts is prone to user errors
- process is time consuming
- technical issues with those scripts, not a reliable merge [1]

If the merge is not done outside of Zanata, the existing translation of the previous version will only be presented as 100% TM matches, which then can be copied for each message individually by the translator. Pitfalls: 
- does not scale for bigger projects (too much copy & paste required).
- unable to estimate workload, as Zanata shows 100% untranslated for the whole project


[1] Example: We ran a manual merge of $old_version and $new_version using those scripts. The manual merge resulted in ~43 hours of workload. We dismissed those results and instead just created new .pot files of $new_version and pushed them onto the existing $old_version on Zanata using "zanata publican push". The resulting workload was ~11 hours. Clearly the manual merge process did not produce the best result. 

Reproducible: Always

Steps to Reproduce:
1. Existing version project XYZ version 1
2. Create new version project XYZ version 2
3. 
Actual Results:  
Existing translations from previous version shows up only as 100% TM matches. No way to trigger an automatic re-use

Expected Results:  
There should be a way inside of Zanata to trigger an automatic re-use of translations from previous version

Comment 7 Patrick Huang 2012-07-05 02:50:41 UTC
Added feature:
For all TM merged translation, it will have comment in the result file as "auto translated by TM merge"
Committed into master:
https://github.com/zanata/zanata/commit/f6df79ef146ea9caeba9317d0340aa765d5acdd2

Comment 8 Ding-Yi Chen 2012-07-09 04:44:14 UTC
Regarding "selected TM match..." dialog:

The last condition shows: Appproved, which does not reflect the actual behavior, which is:
  
   If not downgrade to Fuzzy, then approve.

Please states this in the dialog.

REASSIGNED.

Comment 9 Patrick Huang 2012-07-10 01:13:22 UTC
Change label to:
If not Reject or downgrade to Fuzzy:

Change button text and added tooltip.

Committed into master:
https://github.com/zanata/zanata/commit/9d381dac98990ee6f04c62a967380c5d95065920

Comment 10 Ding-Yi Chen 2012-07-11 03:59:16 UTC
VERIFIED with Zanata version 1.7-SNAPSHOT (20120711-0026)


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