Forum OpenACS Development: Changes in the acs-lang data model: Splitting message keys

In connection with the internationalisation work on acs-lang, we are considering splitting message keys.

The table holding the message catalog looks like this:

create table lang_messages (    
    key varchar2(200),
    locale varchar2(30) 
        constraint lang_messages_locale_fk
            references ad_locales(locale)
        constraint lang_messages_locale_nn
            not null,
    message clob,
    registered_p char(1)
        constraint lm_tranlated_p_ck check(registered_p in ('t','f'))
);

By convention the messages are keyed by package name and local key name separated by a dot.

One option is to split the key so messages gets keyed by (package_key, key, locale) instead of just (key, locale). The new table would be:

create table lang_messages (    
    package_key varchar2(100)
                references apm_package_types (package_key)
    key varchar2(200),
    locale varchar2(30) 
        constraint lang_messages_locale_fk
            references ad_locales(locale)
        constraint lang_messages_locale_nn
            not null,
    message clob,
    registered_p char(1)
        constraint lm_tranlated_p_ck check(registered_p in ('t','f'))
);

There are two advantages:

  1. The modelling is better because rather than relying on some text coding convention the relationship between messages and packages is actually reflected in the model and the model can become more robust and maintainable by introducing constraints.
  2. Modules (acs-lang administration) that search the message catalog by package will become faster and simplier written.

The advantages should be weighted against the cost of implementing upgrade scripts and possible breaking existing code that rely on the current acs-lang data model.

Any comments on this?

Splitting the key in the db is certainly a good thing. I wonder though if the first part should be referencing apm_package_types - this way you would loose the ability to have generic groupings, as for example used already in the greenpeace project. E.g. for generally used error messages, text on the homepage etc. etc. I'd vote for a simple varchar not null (and can't think of a better name right now, but it would have to be called other than package_key).
Tillman, I see your point.

On the other hand, you can always assign those keys to acs-subsite or acs-kernel. Or you could create a new package, e.g. "gp-message-catalog", where you'd actually store the catalog file as well.

Is it worth loosing the power of the foreign key over this flexibility?

/Lars

Also I think it should be defined wether more than one dot should be allowed in the message key and what happens in that case. There are some keys like this in the greenpeace catalog file: acs-lang.test.French but they may be just unused leftovers.

It is propably ok to define that everything right of the first dot belongs to the key, even if it contains more dots.

Assigning project specific messages to acs-kernel or acs-subsite seems a bit like a kludge to me. I'd rather create my own project-message-catalog package in that case. But then I'd loose the ability to distinguish between e.g. error.xxx and generic.xxx (don't know if that would be necessary though). Hmm.

Also we might want to enable content editors of a site to create their own groups, without having to create their own package. Not sure about this either. Some advice from somebody who used that in practice would be good ... Bruno, do you read this?

Just so people know, the reason why the key was not split in the
first place was that the datamodel predated the APM.  I think splitting the key is a good idea.

You could preserve the ability to have generic catalog by having
such generic data belong to the acs-lang package.