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 :)
