Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Proposal of code changes for l10n in FF3

1 view
Skip to first unread message

Jean-Marc Desperrier

unread,
Aug 3, 2006, 5:17:00 AM8/3/06
to
Marek Stepien wrote:
> It should not be a problem at all with only one numeric variable; we'd
> just need to make sure that the "plural chooser" uses only the %d vars.
> [...]
> (the numbers represent: 0 - singular form, 1 - first plural form, 2 -
> second plural form, and so on)

And where do you envision coding the plural chooser ?

Is it some js, that must be added in the localisation, or an XPCOM
component ? Maybe the nicest is an XPCOM component, that you can choose
to code in js, or in low level language when that is more adapted.

Or, well maybe we should include in the i18n code a table driven plural
chooser, and the l10n provides the tables so that we solve the
performance problem. If it's *really* complex, there could be a way by
which the localisation provide it's own XPCOM implementation to call.

Copying i18n.

Marek Stepien

unread,
Aug 6, 2006, 12:48:23 PM8/6/06
to
Jean-Marc Desperrier napisał(a):

> Is it some js, that must be added in the localisation, or an XPCOM
> component ?

The localization would only need to provide the plural forms expression
that decides which plural form is correct for a specific number.

> Maybe the nicest is an XPCOM component, that you can choose
> to code in js, or in low level language when that is more adapted.

Probably, yes.

But I suppose a getFormattedPluralString method next to
getString and getFormattedString would be the most natural place for
this.

> Or, well maybe we should include in the i18n code a table driven plural
> chooser, and the l10n provides the tables so that we solve the
> performance problem.

What do you mean by "table driven plural chooser"?

> If it's *really* complex, there could be a way by
> which the localisation provide it's own XPCOM implementation to call.

XPCOM component is not something that a localization team (often
consisting of non-techies) should provide. They should only provide the
plural forms expression, like for gettext, and preferably it should be
the same expression as in gettext, like these:

http://www.wordforge.org/static/l10n-pluralforms.html

(note: I don't know how accurate this page is, however it seems OK for
English, Germand and Polish)

--
Marek Stępień <mar...@aviary.pl>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/

Robert Kaiser

unread,
Aug 7, 2006, 3:31:38 PM8/7/06
to
Marek Stepien schrieb:

> But I suppose a getFormattedPluralString method next to
> getString and getFormattedString would be the most natural place for
> this.

I think that getFormattedString itself should support that
automatically. That way, the code doesn't need to be rewritten for that,
and I don't see it conflicting anyways.

Robert Kaiser

0 new messages