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.
