Red Hat Bugzilla – Bug 217153
Please use ngettext for handling plurals
Last modified: 2007-11-30 17:11:49 EST
Currently, pirut uses a broken approach to handle plurals for user visible
strings. Sometimes it is omitted entirely.
if num != 1:
text = "%d updates available" % num
text = "%d update available" % num
may work for English (German would be fine too). But quite some other locales
aren't working that way.
Good summaries of the situation:
Unfortunately it's not easy to fix this. Pirut uses rhpl.translate instead of
gettext itself, and rhpl.translate doesn't support ngettext.
So we have two options:
* Make rhpl.translate aware of ngettext messages, or
* Use plain gettext as any other python app outside Fedora/RH
I would prefer option 2, as I don't see the value of having textdomain
transparency for those apps. OTOH every other application using rhpl.translate
would profit from option 1.
I'll attach an unfinished patch to show you where the problems are.
Wherever possible avoid surrounding markup of translatable strings. This is
If you want me to work on this just leave a note here.
Created attachment 142061 [details]
Unfinished ngettext patch
(In reply to comment #0)
> Unfortunately it's not easy to fix this. Pirut uses rhpl.translate instead of
> gettext itself, and rhpl.translate doesn't support ngettext.
> So we have two options:
> * Make rhpl.translate aware of ngettext messages, or
> * Use plain gettext as any other python app outside Fedora/RH
The plain python gettext used to have problems with translations from different
modules (ie, you have a module foo.py which should be using the translations
from foo.mo and an app bar which uses the translations from bar.mo; things then
went downhill from there). This might be fixed now as I haven't tried in a
little while -- but that's the main reason why rhpl.translation is still used
now with the existence of the gettext python module.
> I would prefer option 2, as I don't see the value of having textdomain
> transparency for those apps. OTOH every other application using rhpl.translate
> would profit from option 1.
Ultimately, I'd like for rhpl.translate to be able to die :-) And at that
point, I'm open to moving things to use ngettext, but I don't know that I want
to a) enhance rhpl.translate or b) lose the things that are provided by it
(which are needed) :-/
> Wherever possible avoid surrounding markup of translatable strings. This is
> error prone:
Yeah, unfortunately, the toolchain for doing things like this is absolutely
awful. Realistically, the markup should be stripped when the strings are
extracted into the pot file. While it's relatively easy to do the split-up in
python since strings are easily concatenable, it does make things significantly
harder to read and to ensure that you actually have matching markup :/
ngettext used now in CVS for the cases I could find after switching to using the
gettext module directly.