Forum .LRN Q&A: what happened with the translated messages??!?!

hi:

I know that was a server upgrade, and so some of the messages got lost. I assume that this happened with pt_PT and pt_BR, which had almost all the messages translated and now there are about 100-200 less.. but with gl_ES I had also 1600+ translated messages and now only appear 600+!!

what happened? is there any way to retrieve the "lost" messages?

Collapse
Posted by Peter Marklund on
Loss of 100-200 messages is because I removed messages that are no longer used, it happened to all locales.

The loss of gl_ES messages is kind of a mystery why it happened. I haven't been able to track it down. However, the gl_ES messages are back on the server now. Since I commit to CVS files fairly often mistakes can be reverted and there is no risk that all work will be lost.

Collapse
Posted by Tilmann Singer on
It seems in acs-datetime en_US there are some missing as well. There used to be about 20 in it, now there are only 3 left, and a freshly installed calender shows a bunch of messages like this:

MESSAGE KEY MISSING: 'acs-datetime.Today'

Did you check wether the messages were used by another non-core package before removing them?

ok Peter, thaks a lot ;)
Collapse
Posted by Peter Marklund on
Tilmann,
good catch about the acs-datetime keys. Actually the test servers also caught it for me, but you posting her made me fix it sooner. Sometimes when I fix one bug I introduce another, see this commit: http://xarg.net/tools/cvs/change-set-details?key=EE8D222D64FA3B78E0F53A77DAD282AFFBDC417C

Notice the acs-datetime.en_US file that is there and has nothing to do with what the commit was supposed to do. When the test servers are recreated tonight calendar should be back in business again.

The original problem with missing keys arose because the keys were not present in any scripts as package_key.message_key and therefore my consistency check script thought they were no longer used. It is very important that you *never* do dynamic message lookups like this:

set message_key [generate_message_key_dynamically]

set text [_ $message_key]

Instead you can do something like this:

set message_key_array {
  lookup1 package_key.message_key1
  lookup2 package_key.message_key2
}

set text [_ $message_key_array([generate_lookup_dynamically])]

Ok, that was maybe not so readable. The point I wanted to make is that package developers need to have their keys represented as package_key.message_key somewhere in their scripts or else the message keys risk being removed.

Collapse
Posted by Tilmann Singer on
<blockquote>but you posting here made me fix it sooner
</blockquote>

Fixed or will fix it sooner? I can't see an update to acs-datetime/catalog/acs-datetime.en_US.ISO-8859-1.xml, it's still at 1.14 - or what am I missing here?