I wouldn't say it was "poorly researched", but rather "I got fed up of
not finding anyone able to give me an answer". I asked several times
on #i18n, on desktop-devel-list and on gnome-i18n, and didn't get a
real answer apart from something like "it works on newer gettext both
on linux and solaris, and _maybe_ you can rely on it being available".
Nobody told me that ngettext shouldn't be used, and I'm subscribed to
gnome-i18n, and didn't get that impression either. The only answer I
had regarding the use of ngettext was "other gnome modules are already
using it".

Adding a configure check for it, and stuff like that in gnome-vfs is
total nonsense. Having #ifdef all over the place in gnome modules when
there are portability problems is stupid. Something should force
people to install a new enough gettext (gnu gettext 0.12 is probably
not that big to build), so that any gnome module can assume ngettext,
bind_textdomain_codeset and stuff are available.

If that is that bad, feel free to revert this patch, but that will
probably break once again string freeze. 

It seems less critical than the ipv6 issue since it has been applied
for longer and no compilation problem was reported, while the ipv6
compile problem has already been reported twice. But people will
probably complain about it sooner or later, I agree.

The patch has been reverted for now (or will be soon, alex is taking
care of that).

Christophe: I apologise if my choice of words came across too
strongly. It was not my intention to offend.

In your defense, even some of the i18n comments appear misinformed.
For example, in bug #116236, it mentions that ngettext is on Solaris
and Linux. This is not true: it's on Solaris 9 and patched versions of
Solaris 8 (information provided by Sun on desktop-devel and
gnome-i18n-list a while back). I agree that the solution would be to
require GNU gettext, however that does not seem to be a consensus view
at the moment (a price we pay for agreeing to work nicely with
proprietary systems).

Anyway, no offence intended and hopefully we can find a way around
this that somehow works.

I'm not really offenced by this bug, but rather by the fact that I
never managed to get anyone to answer properly to all my questions :)
Anyway after talking with alex on irc, we decided to revert the patch
for now since there are a whole lot of issues with using ngettext. I
thought people could just install some new "libgettext" to get things
to work, but I learnt today that gettext wasn't working this way. 
Moreover, if we use  #ifdef in the code, plural messages will probably
end up nevertheless in the .po files, which will have unexpected
effects on platforms not having ngettext when they try to compile
those files.
So it's better to revert it for now, and take time to think about it
for gnome 2.6 :) My feeling is that it's "some gnome lib"'s job to
make sure ngettext and friends are available, we don't want every
app/library to duplicate the same ngettext check, and forgetting the 
#ifdef from time to time, thus breaking older platforms when it could
easily be avoided.

The fix was reverted, so I'll close this now. It's not like we're
going to forget to have the gettext flamewar in a few weeks. :-(

For my part, I won't reapply this ngettext patch until someone can
answer to all my gettext questions, or until some gnome module checks
for the availability of ngettext, so I guess this won't generate many
flames on gnome-vfs side at least :)

"Just for the record" :-)

The problem with this is that it means incorrect translations in a
couple of languages.

It's equivalent of having strings "1 cars" or "45 car" in English --
it sounds silly and gives a bad image to translation. I'm sure you
would really dislike having strings like these in English messages --
actually, that's why developers insist on using at least *two* strings
for plural forms ("one car" and "%d cars").

The problem is not that it would "work better" with ngettext, the
problem is that it wouldn't work at all without it (unless you
consider "17 car" to be a 'working' string).

So, while you keep one thing "correct" (in a dubious sense, I must
admit), the other is broken, while there is a chance to fix it.

Some desktop apps (modules which are part of the 'desktop', not the
'developer-libs') already include ngettext support in 2.4, and there
haven't been much (if any) complaints about it so far.

And yes, a 5MB gettext source code (and only a part of which is
needed) is far less than the 100+MB (again, source code) required for
basic Gnome 2.4 D&DP install -- not counting all the other
prerequisites not found on ftp.gnome.org.

I hope I clarified this issue a bit more in here, where we don't
expect (too much) flames (just those coming from me ;-)

What's the status of this? Is this resolved or still reverted?

This is still reverted, the bug tracking ngettext usage in gnome-vfs
is #118049

*** This bug has been marked as a duplicate of 118049 ***

Ah, sorry.