Bug 728821 - Fuzzy strings are not shown on web interface after uploading
Summary: Fuzzy strings are not shown on web interface after uploading
Alias: None
Product: Zanata
Classification: Retired
Component: Usability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: James Ni
QA Contact: David Mason
Depends On:
Blocks: zanata-1.5.0
TreeView+ depends on / blocked
Reported: 2011-08-08 01:52 UTC by Chester Cheng
Modified: 2016-06-23 04:45 UTC (History)
6 users (show)

Fixed In Version: 1.3.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-07 00:06:58 UTC

Attachments (Terms of Use)

Description Chester Cheng 2011-08-08 01:52:38 UTC
Description of problem:
After using "zanata publican push --import-po", the fuzzies are not shown on translation.engineering.redhat.com

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

How reproducible:

Steps to Reproduce:
1. svn co https://svn.devel.redhat.com/repos/ecs/Red_Hat_Enterprise_Linux/Deployment_Guide/6.1-GA-RELEASE Red_Hat_Enterprise_Linux/Deployment_Guide/6.1-GA-RELEASE
2. cd Red_Hat_Enterprise_Linux/Deployment_Guide/6.1-GA-RELEASE
3. publican lang_stats --lang ja-JP.  Check the fuzzy status.
4. Go to translate.engineering.redhat.com
5. Compare the status.
Actual results:
Check Deployment Guide 6.1 on Zanata.
Zanata shows no fuzzy.

Expected results:
(Take one file for example.  From publican.)
ja-JP/Date_and_Time_Configuration.po                 945        335         18
=> There are 335 fuzzy words.

Additional info:

Comment 1 Chester Cheng 2011-08-08 01:56:02 UTC
Since our translator is working on this project, the status may change.  I'll list the whole status here:

ja-JP/Author_Group.po                                 17          8          1
ja-JP/Automatic_Bug_Reporting_Tool_ABRT.po          4242        366          1
ja-JP/Automating_System_Tasks.po                    2738        333        179
ja-JP/BIND.po                                       6174        894         15
ja-JP/Book_Info.po                                    36          0          5
ja-JP/Colophon.po                                    235         10          1
ja-JP/Configuring_Authentication.po                   26        307       2148
ja-JP/DHCP_Servers.po                                 18        175       3217
ja-JP/DNS_Servers.po                                 595        111          1
ja-JP/Date_and_Time_Configuration.po                 945        335         18
ja-JP/Deployment_Guide.po                            122         40          3
ja-JP/Directory_Servers.po                             0          2          1
ja-JP/FTP.po                                         132       2027       2419
ja-JP/Feedback.po                                    101          6          1
ja-JP/File_and_Print_Servers.po                        0          4          1
ja-JP/Keyboard_Configuration.po                      693         84          1
ja-JP/Mail_Servers.po                                557       3879       6046
ja-JP/Managing_Users_and_Groups.po                  2630       1596        459
ja-JP/Manually_Upgrading_the_Kernel.po              2896        361          3
ja-JP/NetworkManager.po                               46         26       1264
ja-JP/Network_Interfaces.po                           44        246       3678
ja-JP/OProfile.po                                   3893        548         10
ja-JP/OpenLDAP.po                                   2734       1080         26
ja-JP/OpenSSH.po                                      21        142       5052
ja-JP/PackageKit.po                                    0       1307       1741
ja-JP/Preface.po                                    1342        165         20
ja-JP/Printer_Configuration.po                      2193        377          7
ja-JP/Product_Subscriptions_and_Entitlements.po      13015        934          6
ja-JP/RPM-Checking_Package_Signatures-Fedora.po        385         63          1
ja-JP/RPM-Checking_Package_Signatures-RH.po          328         96          1
ja-JP/RPM.po                                          21        213       4013
ja-JP/Revision_History.po                              5         31          1
ja-JP/SSSD.po                                       1708       1253       6777
ja-JP/Samba.po                                       612       4108       2862
ja-JP/Services_and_Daemons.po                        103        392       1979
ja-JP/System_Monitoring_Tools.po                    1511        322         11
ja-JP/The_Apache_HTTP_Server.po                     8628       2185        100
ja-JP/The_X_Window_System.po                         215         65       5623
ja-JP/The_kdump_Crash_Recovery_Service.po            365       1217       2501
ja-JP/The_proc_File_System.po                      11827       1312          7
ja-JP/The_sysconfig_Directory.po                    2515       1140         53
ja-JP/Viewing_and_Managing_Log_Files.po             5191        432          8
ja-JP/Web_Servers.po                                  37         12          1
ja-JP/Working_with_Kernel_Modules.po                4475        631         36
ja-JP/Yum.po                                        1141       3326       2544
Total for ja-JP                                    84512      32161      52842
Remaining hours for ja-JP                         338.05      64.32

Comment 2 James Ni 2011-08-15 05:40:36 UTC

*** This bug has been marked as a duplicate of bug 730606 ***

Comment 3 Ding-Yi Chen 2011-08-16 06:27:02 UTC
I am sorry, but it does address different problem.

Reporter of this bug requests fuzzy messages be imported and displayed with NeedReview status;
however, reporter of 730606 states he does not whan fuzzy messages to be imported as Approved.

Comment 4 James Ni 2011-08-16 08:55:59 UTC
I have modified source code of python client to fix this issue, changes in commit 8f87e1. 
The fuzzy messages will be imported and displayed as NeedReview status now. I have test and verify this on my locale machine.

There is one make me confused. I compare the status between zanata instance on my locale machine with 'publican lang_stats', The number is different. I am not sure which one is correct, or both is correct, just because using different count method.

Comment 5 Sean Flanigan 2011-08-18 00:35:48 UTC
Without knowing what content was uploaded, there's not really enough information to know if there's a problem with the stats or not.  But could it be that you're comparing stats based on message counts with stats based on word counts?

Comment 6 Chester Cheng 2011-11-23 02:04:44 UTC
Hi All,

Same issue happens again.  Here are more information that I hope we can address this issue.

The source content are at svn:
$ svn co -r 74885 https://svn.devel.redhat.com/repos/ecs/Red_Hat_Enterprise_Linux/Release_Notes/trunk/6.2 Red_Hat_Enterprise_Linux/Release_Notes/trunk/6.2
$ cd Red_Hat_Enterprise_Linux/Release_Notes/trunk/6.2
$ publican update_pot (Generating the .pot files)
$ publican update_po --lang zh-TW (Merging the .pot files generated into existing translation)

$ vi zh-TW/devicedrivers.po  (there's a fuzzy string in this file)

#. Tag: para
#, fuzzy, no-c-format
msgid "The <systemitem>ipr</systemitem> driver for IBM Power Linux RAID SCSI HBAs has been updated to version 2.5.2."
msgstr "IBM Power Linux RAID SCSI HBA 的 <systemitem>ipr</systemitem> 驅動程式已
更新為版本 2.5.2。"

Now let's upload the .pot files to Zanata, where the translation is 100% done and identical to the .po files on the svn repository (revision 74885, before running the "publican update_po --lang zh-TW" command).


$ zanata publican push

On Zanata -> RHEL Release Notes 6.2 -> zh-TW -> devicedrivers.po, the string mentioned above is "Untranslated".  (should have been "fuzzy" with the content above.)

(I've translated this string, so most probably you'll see it is translated at the moment.)


This also happens to the kernel.po (same revision on SVN).

Further test:

I pushed it-IT .po files from SVN to Zanata:

$ zanata publican push --push-trans --lang it-IT

and the contents on Zanata are correct: (1) the previous translation was kept, and (2) marked as "fuzzy".

To conclude, the command

$ zanata publican push

should have been worked as 

$ publican update_po --lang all

but it removes all contents that should have been marked as "fuzzy".

Hope this helps.


Comment 7 Runa Bhattacharjee 2011-11-23 06:27:56 UTC
This probably needs to go into an FAQ. Zanata deals with strings individually and after an off-line merge the strings that are marked as fuzzy are displayed as UT on the editor, with the fuzzy translation(or translations in case the string has seen multiple fuzzy iterations) as a suggestion from Translation Memory. So essentially, the translators need to click a selected suggestion from the translation memory for that particular string, make any changes that are necessary and save the translation.

Comment 9 Sean Flanigan 2011-11-23 08:11:12 UTC
Just to clarify, Zanata TM never returns any matches from prior translations which were fuzzy in their old context, only Approved translations (for obsolete or current textflows).

Whereas msgmerge tends to copy similar strings into the PO and mark them as Fuzzy, Zanata reuses exact matches only, *but* the editor's TM search does return Approved translations of similar strings. 

So at present, the only way to get Fuzzy strings in Zanata is (a) to explicitly mark them as Fuzzy, or (b) to upload a PO file which contains Fuzzy entries.  But uploading a Fuzzy entry won't add anything to the TM results.

Comment 10 David Mason 2012-02-21 05:39:36 UTC
Currently, both generic and publican push behave in the same way when given either push-trans or import-po option:

 - does not change translations that are empty or not present in the po file
 - pushes fuzzy translations from po files, will overwrite approved translations
 - pushes approved translations from po files

Comment 11 David Mason 2012-02-22 08:08:05 UTC
Current behaviour with merge type auto (default):

pull translation document, change translations on server, push unmodified old document:
 - keeps server version of translation if it is FUZZY or APPROVED
 - uses old version if server version is NEW

pull translation document, modify document, push modified document:*
 - use pushed version if translation is FUZZY or APPROVED
 - use server version if pushed version is NEW

* this behaviour is the same regardless whether translations are changed on the server between pulling and pushing the translations that are modified client-side.

Comment 12 David Mason 2012-02-23 00:30:25 UTC
Current behaviour with --merge=import:

 - translations from the client-side file (including empty translations) are used in all cases, regardless of the translation state on the server.
 - if a msgid is not present in the client-side file, the translation on the server will be NEW regardless of the previous state on the server.

Comment 13 David Mason 2012-02-23 02:11:19 UTC
Verified with server 1.5.0-alpha-2-SNAPSHOT (20120223-1144), python client 7cff8ef6b60bea8981a0f62f35ac3d44f9f9390c

With merge=auto, fuzzy translations will not overwrite fuzzy or approved translations on the server.

See: https://github.com/zanata/zanata/commit/79656a86fa6639caba3569e01cd2291a99b26901

Comment 14 Sean Flanigan 2012-03-07 00:12:14 UTC
James, from its age, I'm assuming this fix has been released.  Could you please fill in the Fixed in Version field? If not, please re-open it, and move it back to VERIFIED.

Comment 15 James Ni 2012-03-07 01:30:51 UTC
Thanks Sean, I have filled the Fixed in Version with 1.3.3

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