Bugzilla – Bug 954505
yast ruby msg extractor (xgettext) does not support format marker
Last modified: 2020-05-06 15:39:58 UTC
+++ This bug was initially created as a clone of Bug #954357 +++ When installing Leap 42.1 (or 13.2) with Ukrainian localization the page of user account setup is skipped with error: Details: malformed format string - %*[0-9] Caller: /usr/lib64/ruby/gems/2.1.0/gems/fast_gettext-0.9.2/lib/fast_gettext/vendor/string.rb:70:in `%' Other tried localizations show user account page correctly. y2logs is attached ============================================================================= Karl Eichwalder 2015-11-10 17:36:40 CET (In reply to Ancor Gonzalez Sosa from comment #5) > Silly me! I was looking at Estonian .po file (et) and checking the effect in > Greek language (el). But turns out el!=et. :-) > > In Estonian it's not broken just because the translation is marked as fuzzy > (so not included in the .mo file)... a missing translation that is not that > obvious when you are staring at a Greek screen and you see no English text. > :-D > > So, in the end, it's a bug in the uk/users.po, as expected from the very > beginning. So reassigning to translations. Ok, thanks for debugging. It would work better, if the ruby xgettext extractor would add formatting markers as it does for other languages such as c or even ycp: #, c-format #, ycp-format I'm not sure whether that's a general issue or whether our yast xgettext extractor just does not know about this. Without such markers we are not (easily) able to validate the translations -- we usually do this with msgfmt.
Added to YaST Team Scrum queue for the issue to be prioritized with the other tasks.
Raising priority. Broken translations are repeatedly a source of crashes in the installer.
A user have reported that when trying to install TW 20180222 with German locale (de_DE.UTF-8) he got this same error in Keyboard Settings (required for vconsole): malformed format string - % ... /usr/lib64/ruby/gems/2.5.0/gems/fast_gettext-1.6.0/lib/fast_gettext/vendor/string.rb:70:in `%'
(In reply to Luciano Santos from comment #4) > A user have reported that when trying to install TW 20180222 with German > locale (de_DE.UTF-8) he got this same error in Keyboard Settings (required > for vconsole): > malformed format string - % ... > /usr/lib64/ruby/gems/2.5.0/gems/fast_gettext-1.6.0/lib/fast_gettext/vendor/ > string.rb:70:in `%' Sorry, I gave a wrong information. The system was installed but failed at startup when vconsole was being set.
(In reply to Luciano Santos from comment #4) > A user have reported that when trying to install TW 20180222 with German > locale (de_DE.UTF-8) he got this same error in Keyboard Settings (required > for vconsole): > malformed format string - % ... > /usr/lib64/ruby/gems/2.5.0/gems/fast_gettext-1.6.0/lib/fast_gettext/vendor/ > string.rb:70:in `%' Which typically means an error in the translated string (German in this case). The translator didn't respect the number and shape of all the placeholders.
(In reply to Ancor Gonzalez Sosa from comment #6) > Which typically means an error in the translated string (German in this > case). The translator didn't respect the number and shape of all the > placeholders. As long as nobody take the time to work with gettext upstream maintainers to add proper ruby support, this will happen again and again. Also see Ludwig's #c2. (In the past I did this for ycp.)
this is a SLE 15 problem now and a pretty nasty one. Typos of translators go unnoticed and take can down the installer :-( given that translations are often late, lack of qa checks here really hurts.
JFYI related source code including ycp one is at http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/src
If translators are introducing typos, then it asks for a better translation process. This is a "side note", but very important. We use code-reviews in YaST. If translators do not use anything like that (and spell-checker), then we ask for bigger problems.
(In reply to Lukas Ocilka from comment #12) > If translators are introducing typos, then it asks for a better translation > process. Of course we ever need better processes for everything. But. Garbage in, garbage out is the old saying. I'm fine with it (but if garbage can be identified aka filtered that should be done as some protecting step), but in this case it is 'garbage in, system die'. This is a clear bug and must not happen.
Yes, we are already looking for some garbage cleaner solution. Of course, this will not fix the problem of broken translations. It will just refuse to be killed by the trash, so it's a hotfix.
Created attachment 766130 [details] List of broken translations My simple script found 167 broken translations
(In reply to Ladislav Slezák from comment #15) > Created attachment 766130 [details] > List of broken translations > > My simple script found 167 broken translations Sounds like good input for the translation team. Also sounds like you already have a filter you could use. Only question is where the filter should run, in YaST or before?
(In reply to Kai Dupke from comment #16) > Also sounds like you already have a filter you could use. Only question is > where the filter should run, in YaST or before? Sounds like a task for the CI, before things end up broken in a package
(In reply to Kai Dupke from comment #16) > (In reply to Ladislav Slezák from comment #15) > > Created attachment 766130 [details] > > List of broken translations > > > > My simple script found 167 broken translations > > Sounds like good input for the translation team. > > Also sounds like you already have a filter you could use. Only question is > where the filter should run, in YaST or before? ideally in weblate. If we can inject own script, then we can avoid modify gettext in C.
See bug 1088113 for the weblate side. But even without new code, tagging the texts as c-format or python-brace-format (even if this leaves out the '%') would get us 90% there.
*** Bug 1088121 has been marked as a duplicate of this bug. ***
Just for the record, the is also a card for the YaST workshop: https://trello.com/c/nx1ktW0a/22-refactor-and-cleanup-the-translation-process
Publishing the bug as we want to have community involved too. It is based of SLE15 if someone later tries on what codestreams need to be updated.
WIP: https://github.com/yast/yast-devtools/pull/152
Please read the extensive documentation at the pull request to get an idea how this works: https://github.com/yast/yast-devtools/pull/152 In a nutshell, we manually add different types of format markers for the different kinds of format that we use; so "msgfmt -c" or "msgmerge -c" should catch any errors in the translations. The script is normally part of our translation process when generating .pot files, but it can also be invoked standalone. Feel free to test and experiment.
The fix will become available with yast2-devtools-4.2.6. But it can already be used independently if downloaded from here: https://github.com/yast/yast-devtools/blob/master/build-tools/scripts/po_add_format_hints It doesn't need any YaST development environment, only Ruby (which all SUSE users should have installed anyway for YaST) and the "gettext" Ruby gem for that Ruby version (see ruby --version) sudo zypper in ruby2.6-rubygem-gettext For more details, see https://github.com/yast/yast-devtools/pull/152 All YaST .pot files that we generate from now on should already contain format flags generated by this script, so they will trickle down to the translators with the normal translation workflow.