Forum OpenACS Q&A: Re: Notes from Internationalization Discussion at Heidelberg 2004 .LRN conferenc

Collapse
2: Re: Notes from Internationalization Discussion at Heidelberg 2004 .LRN conferenc (response to 1)
Posted by Joel Aufrecht on 05/18/04 04:24 PM
What about plurals?  In English, all numbers are plurals except for 1 and -1.  So this would suggest to make two keys, plural and singular, and use logic whenever the keys are used  so that 1/-1 gets singular and the rest get plural.  But is this generalizable?

(after a bit of research)

http://www.delorie.com/gnu/docs/glibc/libc_135.html

The rules for

Okay, we are going to need to figure out:
1. A naming convention for pluralizable keys.  If we want to solve this completely, we will need at least four keys each time we have a dynamic countable word in a key.  Singular and Plural aren't enough; even singular, 2-ular, 3-ular, plural may not be enough because the extra ones may be different in different languages.

We could call them widget.num_of_widget and widget.num_of_widgets, which makes the key names make sense in English but gets odd for the cases we don't have in English.

We could use widget.num_of_widget_singular, widget.num_of_widget_plural, etc.

2. How we can piggyback on existing code, such as glibc, to do the mapping of locale/number/form?  We need a function that takes as input a number and a locale and gives as output which case should be used.  I don't think tcl has this.

Collapse
3: Re: Notes from Internationalization Discussion at Heidelberg 2004 .LRN conferenc (response to 2)
Posted by Tom Ayles on 05/18/04 05:47 PM

I think the answer could be in the link you gave, although I may be way off the mark. How about just ripping off the system described there? I _think_ this can be done using the existing localisation infrastructure. The idea is pretty rough, but goes like this:

Each locale needs to define the number of plurals plus the plural expression as described in that doc. It makes sense (to me, at least :) to make these message keys: for argument's sake, I'll pretend that they are messages in acs-lang, i.e. acs-lang.nplurals and acs-lang.plural_expr. For example, English (en_US) would have acs-lang.nplurals = '2' and acs-lang.plural_expr = '$n != 1', Polish (pl_PL) would have acs-lang.nplurals = '3', acs-lang.plural_expr = '$n==1 ? 0 : $n%10>=2 && $n%10<=4 && ($n%100<10 || $n%100>=20) ? 1 : 2'. (I just copied these straight out the doc, I guess they're probably valid Tcl expressions, but maybe not...)

So then you need to define the plural forms of a noun. So for English you'd have message keys noun0 = 'noun', noun1 = 'nouns'. I don't speak Polish, but you'd need to define noun0, noun1, noun2 appropriately.

And then the procedure to get the appropriate localised form. Something like: 

ad_proc localize_plural {
   {-message_key:required}
   {-n:required}
} {
  set plural_expr [_ acs-lang.plural_expr]
  set plural_index [expr $plural_expr]
  return [_ "${message_key}${plural_index}"]
}

Oh, I guess nplurals may be redundant then - s'pose you could use it for validation or something. To be honest,I'm not au fait with localisation in OpenACS to the extent that I could say this definitely will/will not work. For example, I don't know what would happen if translations for a locale weren't present and the system had to fall back on defaults. But, it gives you a naming convention (entirely detached from our Anglicised perception of how language works), and ties in with how glibc does it.

You could maybe even bypass the plural_expr business and make a call to glibc to get the appropriate plural index, assuming the indexing scheme is the same. Not sure whether that's desirable, there's probably something to be said for having it all in OpenACS.

And it might be a horrific security risk allowing translators to specify arbitrary expressions to be evaluated by the server, e.g. by setting acs-lang.plural_expr = '[exec rm -rf /]'. That's a seperate issue that could be worked around though.

Just a thought :)