Bug 217153 - Please use ngettext for handling plurals
Summary: Please use ngettext for handling plurals
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-24 13:26 UTC by Frank Arnold
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-10 19:05:48 UTC
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 13:26 UTC, Frank Arnold
no flags Details | Diff

Description Frank Arnold 2006-11-24 13:26:36 UTC
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 13:26:38 UTC
Created attachment 142061 [details]
Unfinished ngettext patch

Comment 2 Jeremy Katz 2006-11-27 22:45:07 UTC
(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 19:05:48 UTC
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.