Red Hat Bugzilla – Bug 728821
Fuzzy strings are not shown on web interface after uploading
Last modified: 2016-06-23 00:45:30 EDT
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):
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.
Check Deployment Guide 6.1 on Zanata.
Zanata shows no fuzzy.
(Take one file for example. From publican.)
ja-JP/Date_and_Time_Configuration.po 945 335 18
=> There are 335 fuzzy words.
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
*** This bug has been marked as a duplicate of bug 730606 ***
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.
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.
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?
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> 驅動程式已
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).
DO NOT REALLY RUN THIS COMMAND OR WE MAY LOSE CONTENTS ON ZANATA AND MISS THE RHEL 6.2 DUE DATE.
$ 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).
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.
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.
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.
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
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.
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.
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.
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.
Thanks Sean, I have filled the Fixed in Version with 1.3.3