Re: Plurals and ngettext

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-02-23 at 10:30, Christian Rose wrote:
> lör 2003-02-22 klockan 23.00 skrev Havoc Pennington:
> > > I just wrote a short piece of text on the problems of plurals:
> > > http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#plurals
> > > As mentioned there, GNU gettext since version 0.10.38 includes a
> > > function called ngettext for solving these problems with plurals. It
> > > would be nice to be able to use that in future versions of GNOME, so
> > > that we can get plurals right.
> > > 
> > > However, as this is a GNU extension, I'm unsure what the level of
> > > support there is in other gettext implementations, so it looks like a
> > > portability problem. Opinions?
> > 
> > Whoa, lots of bugs filed and people are making ngettext() changes, yet
> > as far as I see the portability problem has not been addressed at all.
> > We need a plan there before people start adding ngettext() calls. 
> 
> Noone has given any objections yet -- rather the opposite, as people
> have confirmed that this is supported by the OpenI18N standard and
> compliant platforms. That still leaves the issue of older systems, but
> then people that are worried about portability problems should come
> forward. That's basically the reason I asked this on desktop-devel to
> begin with, to get possible objections on the portability issue. So far
> there has been none.

Well, it makes a significant gettext version -- note that as well as not
being in the traditional implementations of gettext() found on
currently-common versions of Solaris and so forth,
it also is only found in reasonably recent versions of GNU gettext and
glibc.

(It looks like it was added as of glibc-2.2, don't know the gettext
version off hand. So, Linux distributions released in the last two
years or so will have it.)

But then again, some GNOME software above GTK+ uses 
bind_textdomain_codeset() without checking, and that is of similar
vintage...

The OpenI18N thing is pretty much a red-herring; OpenI18N follows
Linux practice and is being adapted by Sun, so it isn't _completely_
irrelevant here, but it certainly isn't a widely adopted standard
at the moment.

Regards,
                                         Owen