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?

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 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?