I think that it is out of question that 5.2 should have a full set of message keys for all major languages (whatever these are)....
However, i would like to bring attention to another issue: how to maintain message catalogs in case where per-installation modification are needed? For example, in the a 5.2 version from cvs "Club" is transated to German as "Kunde", which means "customer". See e.g. dotlrn/catalog/dotlrn.de_DE.ISO-8859-1.xml
<msg key="clubs_pretty_name">Community</msg>
<msg key="clubs_pretty_plural">Kunden</msg>
<msg key="Communities">Communities</msg>
<msg key="Community">Community</msg>
I don't think this was intentional (Malte?)
There are certainly more complicated issues involved. A few weeks ago, we made a presentation of learn@wu to people from our ministry. One of the first reactions was that the terms in the language catalog were not gender neutral. This was a complete show-stopper, since more or less on every page, this person noticed such formulations (e.g. are only male students adressed here; in German "Student" is the male form, while "Studentin" is the female form). There is some regulatory framework from various organizations. As a consequence, we have produced for the packages we are using gender neutral message catalogs.
But what now? Should we feed this back into the main CVS? Maybe other organizations don't like this gender neutral formulations.
It would be nice to be able to subclass a message catalog
to allow a per-instance catalog, where the instance can override the general definitions and where we have some easy ways to see the differences and allow an easy merge....
Are we the only ones with such problems?
Some of the concepts of e.g. dotlrn are very general and could be used for various purposes. e.g. a Community or Club could be "customers" as the message catalog indicates, or a "project" or some working group. It would be great to be able to subclass the general "community" for various purposes, and provided tailored configurations (e.g. portals) and message catalogs for these... but this is certainly beyond message catalogs alone.