On Wed, 2009-01-07 at 03:57 +0100, David Larlet wrote:
> Hi Malcolm,
>
> Thanks for your detailed answer.
>
> Le 7 janv. 09 à 02:54, Malcolm Tredinnick a écrit :
> > Using (u)ngettext as inspiration for a solution might provoke some
> > ideas. That precise API would look a bit ugly in templates, but there
> > might be something that falls out of the sky when you think along
> > those
> > lines.
>
> The sky was really cloudy after reading your link but hopefully, I
> found this one:
> http://scratchpad.cmlenz.net/c8e1af24481df087217bf12a57862949/
The only slightly complex thing have to know to understand the PO file
expressions is the C ternary operator
<test> ? <result-if-true> : <result-if-false>
The final result has to return a number between 0 (sometimes 0 is
omitted and 1 is returned for the singular case) and "n" (for some value
of n corresponding to the number of plural forms in the language). PO
files take a very limited set of things for the <test>. Basically, only
numerical comparisons (n==2, n > 100, etc)
> My proposition is to get a human readable dictionary between locales
> and expressions:
> { 'en': '(n != 1)', 'fr': '(n>1)', and so on }
It would be nicer if we could extract that information directly from the
PO files to save on having to keep it updated in two places at once, if
at all possible. Not sure what the license is on Christian's code, but
writing something similar from scratch wouldn't be too hard, I suspect.
For prototyping, though, you can assume such a dictionary exists however
you want to create it. We can fill in the holes later. I'd certainly
make the values in the dictionary function objects, though, so that you
can pass in the quantity and get back the index or offset of the suffix
to use.
> and then to add a l10n argument to pluralize (naive first iteration
> for the syntax):
> d{% comment_count|pluralize:"u,es,l10n=fr" %} commentaire{%
> comment_count|pluralize:"l10n=fr" %}
Take your hands off the keyboard and back away from the existing
pluralize filter! :-)
Let's not make the existing one more complex, just yet. At least whilst
developing. If you create a new filter -- say pluralize_i18n filter --
you can require that the first argument is always the locale and is
required, for example. Passing arguments to filters is a bit ugly,
trying to work in optional keyword arguments as well starts to get
pretty messy.
> It looks simple and functional but I'm afraid that it will impact
> performances... I can provide a benchmark to verify but let's discuss
> at first :-)
It shouldn't be too slow, relative to everything else that is going on.
You're doing a key lookup, a function call to a pretty simple function,
and an array lookup.
So that all looks reasonable.
There's an elephant in the room that we haven't mentioned yet. Appending
some kind of string suffix to a word works for plural forms (mostly) in
English. But it doesn't internationalise particularly well. For example,
in German, "dream" is "Traum", "dreams" is "Traüme". But I don't think
that's a reason not to work on this. The pluralize filter is an aid for
some cases, not a do-everything filter, even in English. A template
author can also write things like
Ich habe {{ count|as_a_word_in_german }} {{ count|
pluralize_i18n:"de,Traum,Traüme" }}.
I'm only bringing this up partially so that we remember to note it in
any final documentation.
I think you're going in the right direction here. It's a little bit
fiddly and I'll keep thinking about what might go wrong. I'm also hoping
(hint!!) that some of other code contributors on this list (Ramiro, the
Marcs, Jannis, Ludvig, ...) will reply if they have any great ideas or
see any huge problems (again, keeping in mind that we're not trying to
solve every pluralisation problem on the planet -- just provide an aid
for the simple cases).
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django I18N" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Django-I18N?hl=en
-~----------~----~----~----~------~----~------~--~---
