Bug 1025574 - Status of pre-existed translation string changes from "translated" to "fuzzy" when pushing source+target with CopyTrans disabled
Status of pre-existed translation string changes from "translated" to "fuzzy"...
Status: CLOSED NOTABUG
Product: Zanata
Classification: Community
Component: Component-Maven (Show other bugs)
3.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Isaac Rooskov
Zanata-QA Mailling List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 19:10 EDT by Yuko Katabami
Modified: 2015-08-06 01:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-06 17:33:03 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)
First version to be pushed (666.32 KB, application/zip)
2013-11-05 02:01 EST, Sean Flanigan
no flags Details
Second version to be pushed (696.34 KB, application/zip)
2013-11-05 02:04 EST, Sean Flanigan
no flags Details
Files pushed on 17 Sep (338.31 KB, application/zip)
2013-11-06 00:25 EST, Yuko Katabami
no flags Details

  None (edit)
Description Yuko Katabami 2013-10-31 19:10:25 EDT
Description of problem:

Status of pre-existed translation string changes from "translated" to "fuzzy" when pushing source+target with CopyTrans disabled

Version-Release number of selected component (if applicable): 3.0.3


How reproducible: Not sure


Steps to Reproduce:
1. Select a existing Zanata project which contains both source and target strings

2. On your local machine, prepare updated source + target files for that project

3. Make sure zanata.xml file is configured correctly and placed in the directory where files are placed

4. Push both source and target by running: 
mvn org.zanata:zanata-maven-plugin:push -Dzanata.copyTrans=false -Dzanata.username=<YOUR USERNAME> -Dzanata.key=<YOUR API KEY> -Dzanata.pushType=both

5. Refresh the zanata project page and see the result of push

6. In the editor, find and select a string which is marked as fuzzy

7. Click "History" button

Actual results:
History shows that previous status of this string is "translated".


Expected results:
It should not change the status.

Additional info:
[ykatabam@ykatabam ~]$ rpm -q apache-maven
apache-maven-3.0.3-1.el6.noarch
Comment 2 Sean Flanigan 2013-11-05 00:49:06 EST
Pushing source and targets can easily change the target status from translated to fuzzy:

1. When pushing target files for PO projects, the messages may be marked as fuzzy, in which case they will become fuzzy on the server.  That doesn't apply here, because I think this project uses Properties files.

2. When pushing source files for Properties/XLIFF projects, the English text for a given property key may change.  When that happens, all the target strings will be marked as fuzzy, because they are translations of the old string, not the new one.


But in this case, the target files were pushed too, and assuming the target file actually contained a translation for the affected string (can you double-check that please, Yuko?) it should perhaps have replaced the fuzzy string with an approved one.

However, it looks like the class TranslationMergeAuto is does not overwrite the translation because it found the same content in the history of the HTextFlowTarget.  


Yuko, are you able to provide the old and new version of the files which were uploaded?  If the English source text was changed, I would have expected the translation text to change too in most cases.  If the translation text did not change, the merge=auto algorithm may reject it, because it probably needs to be updated, or at least reviewed.  Importing the old string over the fuzzy string could mask an outdated translation.  (Properties files are a very poor localisation format, because you can't always be sure what a target string was translated from.  All you get is the property key.  This is our attempt to defend against some of the risks.)

By the way, Yuko, I think 3.0.3 is the version of Maven, but it may not be the version of zanata-maven-plugin.  The version of zanata-maven-plugin should have been logged at runtime.
Comment 3 Yuko Katabami 2013-11-05 01:30:50 EST
Hi Sean,

(In reply to Sean Flanigan from comment #2)
> Pushing source and targets can easily change the target status from
> translated to fuzzy:
> 
> 1. When pushing target files for PO projects, the messages may be marked as
> fuzzy, in which case they will become fuzzy on the server.  That doesn't
> apply here, because I think this project uses Properties files.
> 
> 2. When pushing source files for Properties/XLIFF projects, the English text
> for a given property key may change.  When that happens, all the target
> strings will be marked as fuzzy, because they are translations of the old
> string, not the new one.
> 

> 
> But in this case, the target files were pushed too, and assuming the target
> file actually contained a translation for the affected string (can you
> double-check that please, Yuko?) it should perhaps have replaced the fuzzy
> string with an approved one.

I have confirmed that most recently pushed file contains the same translation string as the previous file.

> 
> However, it looks like the class TranslationMergeAuto is does not overwrite
> the translation because it found the same content in the history of the
> HTextFlowTarget.  
> 
> 
> Yuko, are you able to provide the old and new version of the files which
> were uploaded?  If the English source text was changed, I would have
> expected the translation text to change too in most cases.  If the
> translation text did not change, the merge=auto algorithm may reject it,
> because it probably needs to be updated, or at least reviewed.  Importing
> the old string over the fuzzy string could mask an outdated translation. 
> (Properties files are a very poor localisation format, because you can't
> always be sure what a target string was translated from.  All you get is the
> property key.  This is our attempt to defend against some of the risks.)

I will be emailing files.

> 
> By the way, Yuko, I think 3.0.3 is the version of Maven, but it may not be
> the version of zanata-maven-plugin.  The version of zanata-maven-plugin
> should have been logged at runtime.

I see. Please let me know how I can find it.


Kind regards,

Yuko
Comment 4 Sean Flanigan 2013-11-05 02:01:23 EST
Created attachment 819542 [details]
First version to be pushed

Attaching sample files.

Yuko, if you run the maven plugin, it should just tell you the version.

Something like

org.zanata:zanata-maven-plugin:X.Y.Z
Comment 5 Sean Flanigan 2013-11-05 02:04:49 EST
Created attachment 819543 [details]
Second version to be pushed

Two of the affected strings in jasperserver_messages.properties for Japanese are error.not.empty.trigger.hours and SEARCH_TYPE_ADHOC_REPORTS.

These strings haven't changed between the two versions provided by Yuko, which seems to destroy my theory.
Comment 6 Yuko Katabami 2013-11-05 02:24:30 EST
(In reply to Sean Flanigan from comment #4)
> Created attachment 819542 [details]
> First version to be pushed
> 
> Attaching sample files.
> 
> Yuko, if you run the maven plugin, it should just tell you the version.
> 
> Something like
> 
> org.zanata:zanata-maven-plugin:X.Y.Z

Thanks Sean.
I copy the part of output below.
(I did not run the command by selecting n for y/n)

[INFO] --- zanata-maven-plugin:3.0.1:push (default-cli) @ standalone-pom ---
[INFO] Please report Zanata bugs here: https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Zanata
[INFO] Loading project config from /home/ykatabam/Desktop/jasper related/29Oct_original-nonbranded-all-langs/zanata.xml
[INFO] Loading user config from /home/ykatabam/.config/zanata.ini
[INFO] client API version: 3.0.1, server API version: 3.0.2
[WARNING] client API version is 3.0.1, but server API version is 3.0.2
Comment 7 Sean Flanigan 2013-11-05 02:26:25 EST
On the other hand, when I pull the source files down in 'xml' form, this is what I get:

        <ns2:text-flow id="error.not.empty.trigger.hours" xml:lang="en-US" revision="3">
            <content>Specify the hour(s) when the job should run.</content>
            <plural>false</plural>
            <extensions/>
        </ns2:text-flow>

        <ns2:text-flow id="SEARCH_TYPE_ADHOC_REPORTS" xml:lang="en-US" revision="3">
            <content>Deprecated reports</content>
            <plural>false</plural>
            <extensions/>
        </ns2:text-flow>

Note the revision numbers: 3.  (Most of the other text-flows in the file are still revision 1.)

These particular strings must have been changed at some point, probably on or before 16 September [1], which is the date on the original translation.  Those strings had Japanese translations, and they would have been marked fuzzy when the English text changed, apparently on 16 October [1].  These translations need to be revised or re-saved in the editor to ensure that they are still accurate translations of the modified English text.

Once they have been saved again, they should stay Translated unless the source text changes again.  If not, we do have a bug, so please let us know.

[1] According to the Translation History in the Zanata editor.
Comment 8 Yuko Katabami 2013-11-05 02:46:06 EST
Hi Sean,

(In reply to Sean Flanigan from comment #7)
> On the other hand, when I pull the source files down in 'xml' form, this is
> what I get:
> 
>         <ns2:text-flow id="error.not.empty.trigger.hours" xml:lang="en-US"
> revision="3">
>             <content>Specify the hour(s) when the job should run.</content>
>             <plural>false</plural>
>             <extensions/>
>         </ns2:text-flow>
> 
>         <ns2:text-flow id="SEARCH_TYPE_ADHOC_REPORTS" xml:lang="en-US"
> revision="3">
>             <content>Deprecated reports</content>
>             <plural>false</plural>
>             <extensions/>
>         </ns2:text-flow>
> 
> Note the revision numbers: 3.  (Most of the other text-flows in the file are
> still revision 1.)
> 
> These particular strings must have been changed at some point, probably on
> or before 16 September [1], which is the date on the original translation. 
> Those strings had Japanese translations, and they would have been marked
> fuzzy when the English text changed, apparently on 16 October [1].  These
> translations need to be revised or re-saved in the editor to ensure that
> they are still accurate translations of the modified English text.
> 
> Once they have been saved again, they should stay Translated unless the
> source text changes again.  If not, we do have a bug, so please let us know.

I would like to check with you if my interpretation is correct.
Are you suggesting me to manually change the status of those fuzzy strings to "Translated" and see what happens in the next push?
We have 6 supported locales - would you like me to do the same in other locales?
(for some reason, strings marked as fuzzy are different in some other locales)

FYI, this particular project has been set up to provide a translation base for other working project (using Copytrans), therefore we have not manually changed these strings.

Kind regards,

Yuko
> 
> [1] According to the Translation History in the Zanata editor.
Comment 9 Sean Flanigan 2013-11-06 00:00:37 EST
(In reply to Yuko Katabami from comment #8)
> I would like to check with you if my interpretation is correct.
> Are you suggesting me to manually change the status of those fuzzy strings
> to "Translated" and see what happens in the next push?

After checking the fuzzy strings are still valid translations, yes.

> We have 6 supported locales - would you like me to do the same in other
> locales?

Well, you could just try one language first.

> (for some reason, strings marked as fuzzy are different in some other
> locales)

That is odd.

> FYI, this particular project has been set up to provide a translation base
> for other working project (using Copytrans), therefore we have not manually
> changed these strings.

Sorry, I don't follow you.
Comment 10 Yuko Katabami 2013-11-06 00:25:38 EST
Created attachment 820194 [details]
Files pushed on 17 Sep
Comment 11 Yuko Katabami 2013-11-06 17:33:03 EST
Sean and I confirmed that there were three pushes.

In the push #1, the translation was marked as translated, but in the push #2 the source was slightly changed (due to typo fix), which made the translation marked as fuzzy.
This status was applied to my recent push #3, thus it is marked as fuzzy.

I am closing this bug.

Thank you Sean for looking into this issue.

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