Bug 748157 - Documenting the interaction between --copy-trans and --push-trans
Documenting the interaction between --copy-trans and --push-trans
Product: Zanata
Classification: Community
Component: Component-Docs (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Joshua Wulf
Ding-Yi Chen
Depends On: 748154
  Show dependency treegraph
Reported: 2011-10-22 12:08 EDT by Joshua Wulf
Modified: 2014-10-19 18:59 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-19 21:32:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Joshua Wulf 2011-10-22 12:08:12 EDT
I understand that --copy-trans only takes acts during the initial import of a project, and is ignored on subsequent pushes.

My question is two-fold, and is related to how --copy-trans and --push-trans interact.

Q1. If I push version 2 of my translation project, with --push-trans and --copy-trans, is it correct to state the following four points?

i. Any string with no translation in the import, but with a matching source string and translation in version 1 of the project will have the translation from version 1 applied in version 2.

ii. Any string with no translation in the import, and no matching source string, or a matching source string with no translation will have no translation in version 2.

iii. Any string with a translation in the import, and no matching source string, or a matching source string with no translation will have the imported translation in version 2.

iv. Any string with a translation in the import, and a matching source string with a translation on the server will have the import translation in version 2.

Q2. Does specifying "--merge import" or "--merge default" make any difference to the interaction of copy-trans and push-trans?

To test this out:

1. Push version 1.0 to the server.
2. Perform 2 translations on the server, for source strings A and B
3. Update the zanata.xml to version 2.0
4. Perform a translation for B on the client-side
5. push version 2 with --push-trans
6. Observe: translation for source string A should be copied from version 1.0 by copy trans. What happens with source string B? Does it inherit the copy-trans translation or the import translation?
7. Update the zanata.xml to version 3.0
8. push version 2 with --push-trans --merge import
9. Reobserve the behaviour of source string A and B with respect to translation prefill in version 3.
Comment 1 David Mason 2012-11-13 02:38:53 EST
This behaviour has recently changed. Requesting information on the above for Zanata 2.0.
Comment 2 Carlos Munoz 2012-11-13 17:56:59 EST
I recently worked on some changes for the maven client in regards to this workflow. Below the answers:

i. Correct. The maven client will first do a push (source and / or target) and then will run a copy trans on the document. Only untranslated entries are written by copy trans. (See the answer below for more details on this behavior)

ii. It depends. Copy trans can now accept arguments. You can take a look at what they are when running copy trans manually form the web UI. In the case of the maven client (and python client for that matter), the arguments used will be the default for the project (again, these can be set from the web UI), or if those haven't been set, it will use a very conservative set of arguments. These arguments basically determine how lenient or strict the 'matching' procedure is. So for example, if the settings determine that only translations for the same project are to be copied, your initial statement should hold true, otherwise, copy trans might copy translations from other projects.

iii. I think there are two scenarios here: "Any string with a translation in the import, and no matching source string"; in this case, since there is no source, there will be warning and the translation will simply not get used. "a matching source string with no translation"; here, since there is no translation, the entry becomes a candidate for copy trans. If the source is in the previous version then it will get reused (provided the copy trans arguments allow it).

iv. Yes. Since the translation is already there (provided it is not fuzzy), copy trans will disregard the entry.

Q2. This is specific to the python client, and is an option specific to the translation push. It does have an impact, but I will explain with an example:

When doing an "import" push, translations that are removed from the local documents will be removed from Zanata. This means that they now become available for copy trans to try and find a matching translation for them. When doing a "default" merge, these translations will not be removed, and if they are approved they will not be targeted by copy trans. So the results MIGHT be different.

I would also like to point out a few differences in the behavior of the python client vs the new maven client. The python client will only run copy trans on the first document import, and I THINK it cannot do so along with a target push. The maven client can run copy trans on demand when pushing sources, targets, or both as described above.
Comment 3 Sean Flanigan 2012-11-13 22:05:45 EST
Q1.i: The Maven client does not invoke CopyTrans when pushing translations only.  CopyTrans is only run if there might be a new source string which needs translating.

ii: The CopyTrans parameters can only be configured via the web UI, not from the client.

Q2: The Python client currently invokes CopyTrans the old way: straight after the source is uploaded, before the translations.  

This means that CopyTrans won't get a chance to fill in an empty "imported" translation.  Essentially, in the case of the Python client, using the options CopyTrans=true and merge=import will cause Zanata to perform CopyTrans, and then completely overwrite anything it may have done.  (Except that any files which don't have local files for a given locale will not be overwritten by merge=import.)

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