Forum OpenACS Development: Internationalization efforts

Posted by Rafael Calvo on 12/06/05 04:13 AM

Hi
I've seen a number of unrtanslated English keys in my latest install with 5.2 and this brings me back to how are we managing the internationalization efforts.

According to translate.openacs.org people are still using that service to translate to new languages or fix existing ones. We are also using CVS, but I think both things have not been synchronized for a while.
I wrote a couple of calls in the bug tracker for the Hindi and the Australian English translations that are in the translation server to be moved to the code base. These translations have been finished for months but no one has had the time to merge it in the code.

I think that if possible we should have translations fixed for the 5.2 final release.

What is the best way for coordinating this?
If we can only add things to the catalog through CVS we are giving a step back since non-programmers can not contribute.

cheers

rafael

2: Re: Internationalization efforts (response to 1)

Posted by Gustaf Neumann on 12/06/05 12:56 PM

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

  &lt;msg key="clubs_pretty_name"&gt;Community&lt;/msg&gt;
  &lt;msg key="clubs_pretty_plural"&gt;Kunden&lt;/msg&gt;
  &lt;msg key="Communities"&gt;Communities&lt;/msg&gt;
  &lt;msg key="Community"&gt;Community&lt;/msg&gt;

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.

8: Re: Re: Internationalization efforts (response to 2)

Posted by Carl Robert Blesius on 12/07/05 09:33 AM

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.

3: Re: Internationalization efforts (response to 1)

Posted by Malte Sussdorff on 12/06/05 02:07 PM

Autsch... This was indeed not intentional.

Okay, these are the steps to do:

- Create a new locale: de_WU
- Set this as the default locale for de
- Translate according to your needs

If you provide e.g. a gender neutral version or general enhancements, we should make this available somewhere. In Germany gender neutral is also key, so I think you could put this gender neutral into the main trunck.

What is needed in general is a forum where we can discuss these things and efforts.

And sorry again for the translation, I thought I did not commit the .LRN package... Darn...

4: Re: Internationalization efforts (response to 1)

Posted by Malte Sussdorff on 12/06/05 02:09 PM

I also have a lot of ideas on how to improve internationlization with OpenACS, which I will post to a WIKI and where we could continue working together. Once we have come up with a framework on how we want to improve things we might be able to come up with some funding for it as well as developers who are interested in developing this framework.

5: Re: Internationalization efforts (response to 1)

Posted by Gustaf Neumann on 12/06/05 02:39 PM

Malte, this does not improve the situation, it makes it even somewhat worse, since we would be even more decoupled from the main trunc and its language key improvements. If an installation has only one key per package different, they have to maintain the full set. By simply updating the changed keys, cvs could help to merge improvements from the main trunk. At least in theory, since the language keys are somewhat critical to end users, when they change, a documentation/screen shots etc. have to be updated, users are confused, support mails go up etc. From an end users perspective, the situation is not so unrelated with our TIPing rules :)

It would be certainly neat to have some support to make the differences explicit and helps to feed differences back into CVS. It might help to increase the responsiblity of the installations for the language keys in CVS. I do agree with Rafael that it would be great to find a way that non-techies are able to contribute as well.

6: Re: Internationalization efforts (response to 1)

Posted by Malte Sussdorff on 12/06/05 03:11 PM

Okay, sorry. Don't make de_WU your default but keep de_DE the default. This way you can set the de_WU as your system locale and encourage all users to use it. All de_DE keys will be available to you, but you could override them with a de_WU translation. Or am I missing the point ?

7: Re: Internationalization efforts (response to 1)

Posted by Gustaf Neumann on 12/06/05 11:23 PM

Ah i see, this is how it is intended to work. the weak side is the "encourage people" part of the sentence, when you have e.g. 23000 users. It is as well quite strange that the users will have the choice between German and WU-German. It seems to me that you do not suggest this approach to your customers.

9: Re: Internationalization efforts (response to 1)

Posted by Malte Sussdorff on 12/07/05 06:42 AM

For our customers we usually set the system locale to "de_CG", and make it therefore the default for new users. The reason why the previous commit happened was due to the fact that we forgot this on our development server....

As for confusions with your users at WU, you could put a sentence on the "change locale" page, stating that the WU has austrianized the north german translations and this is the recommended version for students to use. This is perfectly normal, taking into account that you can have some Linux programs running in "Plattdeutsch" as well.