Forum OpenACS Development: I18N AMS & Dynamic Types

Collapse
Posted by Malte Sussdorff on
AMS and Dynamic Types (as well as Assessment in a way) allow us to have additional attributes for object types. Sadly it is assumed that these additional types will be only available in one language (not internationalized).

Not that this would be annoying at the moment, but I wanted to raise the issue anyway.

My idea for a solution (using AMS as an example):

Instead storing the pretty_name and the pretty_plural name directly as a new attribute, I'd store "[_ ams.[acs_lang::util::create_language_key $pretty_name]]" and insert the pretty_name cum language key in the AMS catalog.

I know that this stores internationalization in a package where it does not belong in the first place, but I think it still is a good solution. You'd just have to keep in mind that you should never submit you language catalog files to CVS :).

Other ideas ?

Collapse
Posted by Malte Sussdorff on
Oh, did I mention that this approach has the additional benefit that you can change the Pretty Name of the attribute as often as you want and *additonally* circumwent the unique constraint on pretty name. Not to forget that the client actually could change the word using the translation interface.
Collapse
Posted by Matthew Geddert on
I had thought of programming AMS the same way you described but decided against it because of the catalog files issue as well 😊 but since we should make sure the software is internationalized (now that its at cvs.openacs.org and not just in house), i think the approach you mentioned is a good one for dynamic attributes. But what about attributes created via plsql by the core or other packages. So, for example persons have first_names and last_name attributes inserted by acs-kernel. Would AMS then scan the attribute table and generate a key acs-kernel.first_names or would it create ams.first_names, or would it only do that if somebody went to change the pretty name of that attribute?

If we go with the solution to only change it when the "pretty name" changes, we cannot provide a pre-packaged internationalized version of AMS or Dynamic types with default attributes that work in multiple languages...

Collapse
Posted by Malte Sussdorff on
I went ahead and got it to work beautifully, while also detecting the problem that a couple of strings for attribute pretty names in acs-kernel and acs-subsite are hardcoded. I changed it on my install to use I18N and if I don't detect and negative side effects I will commit next week (the kernel changes).

Two issues though that need to be worked out:

- New attributes in a locale != en_US. As acs-lang requires you to register the string in en_US before any other language you face the issue that it is impossible to add an attribute e.g. only in German. I solved this by adding the language key first in en_US and then into the locale of the user adding this attribute. I also think that it might be fun to try out the babblefish SOAP gateway in the tsoap package to translate the message into english before inserting it, but this is still a little bit off.

- Editing attribute names. Any form that offers you to edit the pretty names of the attributes will display "<span>#</span>ams.message_key#" instead. My approach would be to disallow the changing of the pretty name in the user interface, but maybe this is a little bit too drastic.