Forum OpenACS Development: Re: Internationalization efforts

Collapse
Posted by Gustaf Neumann on
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.

Collapse
Posted by Carl Robert Blesius on
As part of the i18n work that we did when I was in Heidelberg we added audit trail and it was one of the first steps toward version control for the translators, which is what we need (in addition to finer grained permissions and roles for the translate server with some kind of notification function so authors and admins of a locale can be notified when changes are made). Regretfully funding ran out before we could proceed.

In the meantime (for work I am doing in Boston) I have been encouraged to make changes to the UI using acs-lang for site specific needs (it is hard to resist) and it is clearly a can of worms waiting to cause problems (I see Malte's innocent commit error as an example of one of those worms, change a single message key and you have forked).

I do like your subclassing suggestion Gustaf. In addition to having a diff ideally the per-instance differences would have a "submit this group of translations to locale admin for inclusion in the superclass (e.g. the gender neutral changes that belong in German proper).

In any case, it's obviously not an easy problem.