Bugzilla – Bug 980329
gettext tools do not support Ruby
Last modified: 2020-06-24 16:15:44 UTC
+++ This bug was initially created as a clone of Bug #979781 +++ The German translation of module yast2-journal contains an error: msgid "Between %{since} and %{until}" msgstr "Zwischen %{seit} und %{bis}" "since" and "until" should not be translated. See this code: ... =================================================================== We see this kind of bugs again and again. In the past, YCC was properly supported in gettext. We need this for Ruby as well. Please, take the time to report appropriate info to the gettext maintainers (or better, provide a patch). In the meantime, which tools can I use as a workaround?
Lada - you work the most with translation, do you have idea?
msgfmt should be able to check this, at least in theory: http://linux.die.net/man/1/msgfmt --check-format check language dependent format strings It should check that the format strings are not changed(=broken by translation), just permuted.
(In reply to Martin Vidner from comment #2) > msgfmt should be able to check this, at least in theory: > > http://linux.die.net/man/1/msgfmt > --check-format > check language dependent format strings > > It should check that the format strings are not changed(=broken by > translation), just permuted. maybe this bug is about missing ruby support in msgfmt?
Yes, it seems format-ruby should be implemented in http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/src There is no upstream bug for that it seems: http://savannah.gnu.org/bugs/?group=gettext
With Ruby it's a bit more complicated, the GNU Gettext does not support Ruby at all. The translatable texts are collected by Ruby rgettext (https://github.com/ruby-gettext/gettext) and at runtime YaST uses fast_gettext gem (https://github.com/grosser/fast_gettext) for actual translation. That means beside adapting the GNU gettext to support the ruby-format, we would need to fix Ruby gettext to write this flag when creating the POT file...
See also https://bugzilla.suse.com/show_bug.cgi?id=954505 "yast ruby msg extractor (xgettext) does not support format marker"
(In reply to Martin Vidner from comment #6) > See also https://bugzilla.suse.com/show_bug.cgi?id=954505 > "yast ruby msg extractor (xgettext) does not support format marker" Thanks for the reminder! I'd vote to report it upstream. I'd have reported it upstream, if I'd be familiar with Rudy. In the past, the gettext maintainers (Bruno) wanted to know the specifics about the format specifiers and then implemented it (ycp). I guess Ruby is rather complex, but why not trying? It's rather important to us ((open)SUSE).
(In reply to Karl Eichwalder from comment #0) > +++ This bug was initially created as a clone of Bug #979781 +++ > > The German translation of module yast2-journal contains an error: > > msgid "Between %{since} and %{until}" > msgstr "Zwischen %{seit} und %{bis}" > > "since" and "until" should not be translated. See this code: > ... This bug is fixed now.
*** Bug 1026156 has been marked as a duplicate of this bug. ***
I'm closing the bug as the original problem has been fixed (see comment #8). Implementing the Ruby support in GNU gettext is out of our scope for the YaST team. Moreover I guess the GNU and Ruby upstreams are probably not interested as there already is a separate pure Ruby gettext implementation.
See also bug #954505. Please read the extensive documentation at the pull request for the proposed fix 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.
Hi, Seams that gettext is gaining Ruby support: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=d079c75c1a1e04b1677a6baaa24b3bc61b17d865 http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=c4da9b03f016dbf1f956e42d4cc3262e9efc11fb and http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=6c39c38b094db79b59ee38b1a0320cb3713f5fc9 maybe is worth a look
Native support for Ruby in the gettext tools would be most welcome. Once that arrives, it will supersede our post-processing solution: This new script does not override an existing format. If a message already has a format marker, that one has priority, and we do not attempt to add another one (which might conflict with the existing one). Thanks for the update!
Oh yes, and of course we also have our YaST-specific format to consider which goes back to YCP and its "sformat()" builtin: _("Can't open file %1 for %2", filename, operation) i.e. another version of positional parameters. And in all the existing YaST code we have a lot of those. So this script will still remain useful for the forseeable future.
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.
Ok, this is really good news! I'm still uncertain whether we still must update or adjust the tools on the weblate server? Maybe, I'd better check twice. I'll ask Standa. Thanks for all your help.
(In reply to Karl Eichwalder from comment #17) > Ok, this is really good news! I'm still uncertain whether we still must > update or adjust the tools on the weblate server? From our side, we are only making use of existing things; those formats have been in gettext for a long time (including ycp-format since the early 2000s). So if they use standard gettext tools from less than 10-15 years ago, it should work out of the box. But it can't hurt to give it a try. > Maybe, I'd better check twice. I'll ask Standa. > > Thanks for all your help. You are welcome!