Red Hat Bugzilla – Bug 1133989
RFE: Merge changed translations from one version to another
Last modified: 2015-07-23 00:07:09 EDT
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'.
Sounds like a useful feature.
It may be difficult to find the definition of "changed".
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
Einav and Yuko are the experts who can answer these questions.
(In reply to Ding-Yi Chen from comment #3)
> 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)
(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).
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)
( ) Specify Project/Version ______________-
(o) Same project, Any version
( ) Any project, Any version
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
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.
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.
Setting this issue priority high and urgent for upcoming sprints.
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
Does anyone know if the fix is already applied to the translate.zanata.org instance and if not - when (roughly) it will be?
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.
VERIFIED with Zanata 3.7.0-SNAPSHOT (git-jenkins-zanata-server-github-pull-requests-3028)
*** Bug 901521 has been marked as a duplicate of this bug. ***