Forum OpenACS Development: refusing to register message keys for non-en

1: refusing to register message keys for non-en_US locales

Posted by Torben Brosten on 10/28/05 08:24 AM

Hi,

In porting sql-ledger, there are aproximately 44 locales each with about 100 keys that are unqiue to the locale. Trying to import the keys results in error messages stating "lang::message::register - refusing to register message for non-en_US locale.. The messag key ... must be registered in en_US first"

I understand the reasoning behind requiring translatable keys registered for a specific locale first. However, there are exceptions!

For example, the above keys may have legal meaning specific to the locale. Translating the original phrase could change the meaning and therefore the phrase should not be translated.

Requiring to register all keys in en_US means that approximately 4400 dummy en_US keys will need to be created in this case as placeholders --but then how to handle the encoding differences between en_US's ISO-8859-1 and the other keys encoded differently while trying to keep the same untranslated message?!?

Could we make an exception to the "register a en_US message-key first" requirement?

The locale specific, untranslatable keys for this package are named: 'package-key.AA_message_key' where "AA_" refers to at least the right or left two letters of the locale. For example, es_ES has:

'accounts-ledger.ES_730000000' which refers to a ledger column in a ES specific chart of accounts.

If this use is extended in practice, each package would be able to create message-keys where there will be few worries about collisons between locales, message-keys, and their meanings when extending beyond the standard key register requirements.

Other suggestions welcome.

2: Re: refusing to register message keys for non-en_US locales (response to 1)

Posted by Malte Sussdorff on 10/28/05 08:52 AM

So, in effect, what you suggest are two changes:

a) Support for special message keys that are made up like ${package_key}.${locale}_${message_key_desc}. I don't think this is a good idea. I would say though that it might make sense to drop the 5 letter ISO code dependence and allow two letter ISO codes as well, but *only* if it refers to the first part or if we can enforce case sensitivity when comparing it with the users locale. Though, to be honest, I fear supporting this will have a performance impact (as you need to check if the string for the locale exists, if the string exists for the partial locale, if the string exists for the default locale for the user locale and if the string exists for the default locale of the system).

b) Dropping the constraint on the en_US message (well, I think it says system locale) existing before. I do agree that this is desireable and should not have too much of an impact. Though changing this will require a thorough rewrite of quite some pages and procedures in acs-lang. If you would implement this, write a TIP and you can count on my support (unless I missed something).

As for a different suggestion, well, you could register these additional locales using the TCL code and a callback on acs-lang (enable language), where you set the en_US message to the same value (e.g. lang::message::register_with_default, that will try see if the message_key exists in the default locale and if not register it in the default locale along with your own locale). This will prevent the large cluttering of en_US with unneeded language keys.

3: Re: refusing to register message keys for non-en_US locales (response to 1)

Posted by Torben Brosten on 10/28/05 11:51 AM

Thanks for the quick and detailed reply, Malte.

I'm not suggesting that we make the exception into the rule. --only that we modify the import restriction. A missing "system locale" message-key would just show the "missing message-key" message, right?

The prefix (AA_ or bb_ exception for locale bb_AA) would just be a naming convention not much different than using a consistent abbreviation or acronym as a prefix to package procedures, tables etc.

In context with your message,

a) Requiring both parts of the locale is important for the performance impact and other reasons you state. Also, because, for example, some countries have official translations where the meaning is identical.

For the most part, the AA_ prefix in the message-key would just be part of a unique string identifier, and would behave as message keys do now.

It might be nice to change untranslatable message-key behavior, to return the original message-key message when the key is missing for a users' locale, but then I believe the dragon of mixed encoding issues would appear for some cases.

b) I do not think we should drop the "requires registering system-locale message-key first" constraint if a missing system-locale message-key would break code. As you know, the constraint is important for keeping a coherent translation table while minimzing maintenance.

I like the "different suggestion" idea, but digging into yet another package's internals is too much for me right now. Also, there may be a limitation for package use with different system locales. (see "Creating keys" below)

"Cluttering the en_US locale with unneeded language keys" seemed okay here. There are not too many untranslatable keys really. I could modify a tcl program that imports the translations from sql-ledger, to make a copy of non en_US messages into the en_US with the same message-key... and deal with that mixed encoding dragon again! =) maybe using iconv etc to convert the string to something mostly literally identical. hmm.

Creating keys for registering in en_US means the package would break for cases where the "system locale" is not en_US, right?

Yet removing the import restriction would work, because the untranslatable message_keys for the system locale would be properly registered.

Aha!

Is it possible, during import, to ignore message-keys that do not have a system locale translation? Perhaps just send a warning message to error.log instead of flooding the page?

This way, relevant message-keys will be available, and other keys will be available once they are translated to whatever the system locale is.

4: Re: refusing to register message keys for non-en_US locales (response to 1)

Posted by Torben Brosten on 10/28/05 11:55 AM

I should mention that right now, on cvs head from a few weeks ago, apparently no message-keys are imported if 1 or more do not have a translation in the current system locale. =(

Forum OpenACS Development: refusing to register message keys for non-en_US locales