Bug 217153 - Please use ngettext for handling plurals
Please use ngettext for handling plurals
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-24 08:26 EST by Frank Arnold
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-10 15:05:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Unfinished ngettext patch (6.12 KB, patch)
2006-11-24 08:26 EST, Frank Arnold
no flags Details | Diff

  None (edit)
Description Frank Arnold 2006-11-24 08:26:36 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
else:
  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:
http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#plurals
http://www.gnu.org/software/gettext/manual/html_chapter/gettext_10.html#SEC150

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.

---
Another issue:

Wherever possible avoid surrounding markup of translatable strings. This is
error prone:
http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#avoid-markup
If you want me to work on this just leave a note here.
Comment 1 Frank Arnold 2006-11-24 08:26:38 EST
Created attachment 142061 [details]
Unfinished ngettext patch
Comment 2 Jeremy Katz 2006-11-27 17:45:07 EST
(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 :/
Comment 3 Jeremy Katz 2007-08-10 15:05:48 EDT
ngettext used now in CVS for the cases I could find after switching to using the
gettext module directly.  

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