[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Plurals in translations was Re: [STRAW POLL] Help on i18n translations?

From: Nicolás Lichtmaier <nick_at_reloco.com.ar>
Date: 2004-04-01 21:21:09 CEST

>> The changes are harmless anyway. Have you read my comment about #include
>> <config.h> needing to be *before* the other includes?
>
>
> I disagree with the FSF on their rationale here. Our working
> procedure has been that header files should be self-contained. By
> adding in the <config.h> at the top, we would mask header files that
> really have a dependency on things defined in config.h.

System headers react to some macros by changing what is defined (e.g.
_GNU_SOURCE), and some autoconf macros depend on this. Besides, config.h
might suply for missing features in the current compiler (bool, const,
inline, etc.) and those things should also be defined when parsing the
headers. This is how autoconf is supposed to work and I don't see why
subversion should be different than all the other projects...

>> char *gettext(char *);
>>
>> There's a ngettext function, defined as:
>>
>> char *ngettext(char *msgid1, char *msgid2, int n);
>
> Normal gettext is:
>
> Newer versions of Solaris supports ngettext as well. However, older
> versions don't as they precede GNU gettext's introduction of ngettext
> (circa 2001, AFAICT). So, it's a question of how far back we should
> support.
>
> At this moment, I don't see a reason why we need to handle plurals.
> If we find out later that we really ought to do plurals, we can adjust
> our targets accordingly. *shrug*

There are already many places where the code thecks if a number is !=1
and decides weather to use a plural form or not.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 21:24:38 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.