|Summary:||RFE: Merge changed translations from one version to another|
|Product:||[Retired] Zanata||Reporter:||Greg Sheremeta <gshereme>|
|Component:||Usability||Assignee:||Alex Eng <aeng>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Ding-Yi Chen <dchen>|
|Version:||unspecified||CC:||aeng, camunoz, dchen, djansen, ecohen, gshereme, mkim, ykatabam, zanata-bugs|
|Fixed In Version:||3.7.0-SNAPSHOT (git-jenkins-zanata-server-github-pull-requests-3028)||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||5|
|Last Closed:||2015-07-22 02:20:10 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Greg Sheremeta 2014-08-26 15:18:21 UTC
Description of problem: A merge feature would be most useful in Zanata. It would save a lot of work if we could copy 'changes' to translated strings from one version (let's call it v1) onto another (v2). Currently we can only push manually merged files, which results in ambiguity w/r/t what ends up as 'translated' vs 'fuzzy'.
Comment 2 Damian Jansen 2014-08-27 06:26:29 UTC
Sounds like a useful feature. It may be difficult to find the definition of "changed".
Comment 3 Ding-Yi Chen 2014-08-28 03:01:25 UTC
Questions: 1. Should I merge different projects? e.g. merge ProjXX.Ver01 with ProjYY.Ver02 2. Is the difference between this and copy trans: Copy Trans: If target entry is translated or approved, then don't copy Merge: If target entry is translated or approved, yet it is older than translated/approved source, then copy source to target. 3. Should we overwrite translated/approved with newer empty/fuzzy
Comment 4 Greg Sheremeta 2014-08-28 12:20:03 UTC
Einav and Yuko are the experts who can answer these questions.
Comment 5 Yuko Katabami 2014-08-29 00:49:17 UTC
Hi Ding-Yi, (In reply to Ding-Yi Chen from comment #3) > Questions: > 1. Should I merge different projects? > e.g. merge ProjXX.Ver01 with ProjYY.Ver02 In our use case, we need merging between versions within the same project, but I can imagine it might become useful to have merge between versions over different projects as well. (For example, if two books share many common strings, updates in one book can be merged into another will save translator's time -- you might want to have more input from other team leads) > > 2. Is the difference between this and copy trans: > Copy Trans: If target entry is translated or approved, then don't copy > Merge: If target entry is translated or approved, yet it is older than > translated/approved source, then copy source to target. Yes, that's what we need. Translators work on newly added string, as well as edit previously translated strings (fixing some errors found) during the translation cycles. > > 3. Should we overwrite translated/approved with newer empty/fuzzy Yes, I think it should overwrite, however it might be better to have Einav's opinion on this as well. (She is on PTO until 8 Sep)
Comment 6 Einav Cohen 2014-09-30 13:08:00 UTC
(In reply to Yuko Katabami from comment #5) > > > > > 3. Should we overwrite translated/approved with newer empty/fuzzy > > Yes, I think it should overwrite, however it might be better to have Einav's > opinion on this as well. (She is on PTO until 8 Sep) [apologies for the late response] sounds OK to me, as long as it is marked as "fuzzy" in the target as well, of course. however, in general, it seems to me that fuzzy translation should probably not be used as a source translation for anything, especially not to override translated/approved translations... so maybe worth setting this one as configurable, just in case (default to override).
Comment 7 Ding-Yi Chen 2014-10-01 00:16:46 UTC
I think it would be best to combine the copy trans, TM merge, and the merge in one page. Otherwise the terms like copy trans, TM merge, and copy merge are confusing. And the UI will probably looks like ( I am not UX expert, NEEDINFO from Luke) Copy translation From: ( ) Specify Project/Version ______________- (o) Same project, Any version ( ) Any project, Any version Fuzzy: Translation from different projects should be at most (fuzzy/translated) Translation from different filename should be at most (fuzzy/translated) Translation from different msgctx should be at most (fuzzy/translated) Copy (overwrite) rules: Newer approved should always overwrite empty, fuzzy, rejected, and translated Newer translated should always overwrite empty, fuzzy, and rejected Newer fuzzy should always overwrite empty, fuzzy, rejected Newer rejected should always overwrite empty, fuzzy, rejected [ ] Newer approved overwrite approved [ ] Newer translated overwrite approved [ ] Newer translated overwrite translated [ ] Newer fuzzy/rejected overwrite approved and translated [ ] Newer fuzzy/rejected overwrite translated [ ] Newer empty overwrite approved and translated [ ] Newer empty overwrite translated
Comment 8 Carlos Munoz 2014-10-29 03:19:19 UTC
Notes from our dev team discussions: The first iteration of this feature will copy translations from one version (source version) on a project to another in the same project (target version). In order for source version translations to be copied, they need to meet the following criteria: - Source content must be the same - Document Id must be the same - Context must be the same - be either in translated of approved state (no fuzzies) - be newer than the current translation (if any) in the target version. Translation history will not be copied over to the target version, and there will be a dry run option that will produce a summary of the actions that the process will do.
Comment 9 Yuko Katabami 2015-02-25 12:26:04 UTC
Hello Zanata team. Could you please update us the progress of this request? Greg originally logged this RFE on 2014-08-26, which allowed sufficient time for your team to work before RHEV 3.6 kickstarts. We had RHEV 3.5 GA on 11 Feb and 3.6 software translation cycles are expected to start soon. All of our projects are located on the external instance (zanata.org). Please make sure to upgrade that server when this is implemented in the new version. Thank you.
Comment 10 Michelle Kim 2015-03-03 23:02:57 UTC
Setting this issue priority high and urgent for upcoming sprints.
Comment 11 David Mason 2015-03-04 04:34:25 UTC
Notes from developer discussion: Estimated adding this feature with the following details. - manual operation - only maintainer can trigger the operation - copy all languages from one project-version to another project-version - can be different projects - option for how to behave when the "to" version is already translated or approved, as shown in table below. - obsolete documents are ignored - "from" project-version selector defaults to the project you are in when you first open it | from | to | copy? | |--------------|------------|-----------| |fuzzy/untr | any | no copy | |--------------|------------|-----------| |different | | | |doc, context, | any | no copy | |source text | | | |--------------|------------|-----------| |trans/appr | untr | copy | |--------------|------------|-----------| |trans/appr | fuzzy | copy | |--------------|------------|-----------| |trans/appr | trans/appr | copy if from is newer and option says to copy
Comment 12 Alex Eng 2015-03-13 05:30:29 UTC
Pull request: https://github.com/zanata/zanata-server/pull/719
Comment 14 Einav Cohen 2015-03-16 16:48:22 UTC
Does anyone know if the fix is already applied to the translate.zanata.org instance and if not - when (roughly) it will be?
Comment 15 Alex Eng 2015-03-16 20:32:22 UTC
Einav, We are currently implementing this feature. It will be ready for Zanata 3.7 release. See https://github.com/zanata/zanata-server/pull/719 for the progress.
Comment 16 Ding-Yi Chen 2015-03-17 06:22:43 UTC
VERIFIED with Zanata 3.7.0-SNAPSHOT (git-jenkins-zanata-server-github-pull-requests-3028)