Bug 217153

Summary: Please use ngettext for handling plurals
Product: [Fedora] Fedora Reporter: Frank Arnold <frank>
Component: pirutAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Unfinished ngettext patch none

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.