We have a lot of places, where we store a pretty name within OpenACS (core packages). On the one hand these are in -create.sql files (where you can somewhat easily internationalize them with the standard procedure), but on the other hand we have procedures that take "-pretty_name" as an argument.
Though this is (usually) of no concern for "single language sites", it makes live hell for everyone else.
I'm therefore on the brink of enforcing I18N of pretty names wherever I stumble upon them, and here is how I plan to do this:
- Enhance lang::message::register with a "-no_catalog_p" switch, that will prevent the message from being written to the catalog file as well. This will allow Translations that have been registered by the creation e.g. of new attributes to be stored in the database but not in a catalog file, as there is no need (if you loose your database you will loose all dynamically generated pretty_names along with it).
- There is still one question though: Where to store the message_key. Three options:
- Along with each package. If I enter an attribute through AMS, it will be stored with a key like MESSAGE KEY MISSING: 'ams.role_test', and MESSAGE KEY MISSING: 'acs-subsite.role_test' if I register a role in acs-subsite.
- Centrally in acs-lang. This way all dynamically generated language keys will be in one place that already exists.
- Centrally in a new package that is only created for storing the catalog files. In this case we could still keep the catalog files which might have the advantage that even though you will loose the message_keys and attributes together if you drop your database, you won't loose the translations. As acs-lang requires you to have an en_US message key before it inserts the translation, you could store the translations of the dynamic attributes in this special package (e.g. /acs-translations/catalog/acs-translations.de_DE.....). If you register a new attribute which existed in your old database the message_key will be reused. I agree, it leaves you cluttered with old message keys that might not be even be used in your setting anymore, but you do not have to copy the /acs-translations/catalog directory to your new site (or you can delete it if you "lost" your database). Obviously this would also drop the need for a modification of acs-lang.
- Once the backend is in place, add the following code (this one taken form acs-subsite creation of roles):
db_transaction {
# Force internationalisation of Roles
# Internationalising of Attributes. This is done by storing the
# attribute with it's acs-lang key
set message_key "role_${role}"
# Register the language keys
lang::message::register en_US acs-subsite $message_key $pretty_name
lang::message::register en_US acs-subsite "${message_key}_plural" $pretty_plural
# Register the language key in the current user locale as well Usually
# you would only register the key in the locale that the user is using
# But we can't do this as the system depends on english language keys
# first.
set user_locale [lang::user::locale]
if {[exists_and_not_null user_locale]} {
if {$user_locale != "en_US"} {
lang::message::register $user_locale acs-subsite $message_key $pretty_name
lang::message::register $user_locale acs-subsite "${message_key}_plural" $pretty_plural
}
}
# Replace the pretty_name and pretty_plural with the message key, so
# it is inserted correctly in the database
set pretty_name "#acs-subsite.${message_key}#"
set pretty_plural "#acs-subsite.${message_key}_plural#"
db_exec_plsql create_role {}
} on_error {
I prefer the third way of storing the translations in a new package, but what do others think? I know this will require a TIP, but I'd like to get some feeling beforehand. Obviously I'd do the job on 5.3.
