timwi, you asked once why we don't do translation strings from the beginning of new features, and we replied vaguely that it makes updates hard as the UI takes shape. You were correct that we don't always get to translation strings too quickly (if ever) afterwards, but didn't understand why things were a pain during the "UI is very liquid" stage. Here's the reason why:The thing I hate most about the translation system is that there's no way to update a translation strictly in a patch, short of deleting the string and making a new key.
The reason is: when you run bin/upgrading/texttool load, it doesn't update the live database with what you have in your lang.dat files if any version already exists. Why? Because it thinks the version on the site might be newer, and won't risk destroying it. That paranoia was designed it, and it's saved our asses tons of times. But it makes real updates pain:
When I go to make a simple patch which fixes a relative URL (like from ssldocs/login.bml) to a full URL, so it works in both htdocs and ssldocs, I have to go through a dozen hoops:
Destructive way:
-- kill the translation string, remove from en.dat, and put a new entry in deadphrases.dat
-- make a new translation string.
(but I might've reverted changes in the translation string from the live site)
Annoying way:
-- remember to make the change at http://www.livejournal.com/interface/ when I put the new code live.
(but I always forget, and other people following the code don't want to do that).
So some thoughts:
Potential Solution #1
We already keep track of modtimes for translation strings in the database from the /translate/ interface. So let's make the dumptext/loadtext respect a new parameter:
Instead of:
/create.bml.entry.text = Make a new account!
Could use a time:
/create.bml.entry.text@1073105753 = I changed this recently.
(Where that number is the unix time since the epoch, no timezone. Run "date +%s" to get it.)
Now, dumptext will include that, and loadtext will replace the value on the live site if the time in the dat file is newer.
We'd just have to change the DATETIME column in the database to be an INT UNSIGNED. (currently it has timezone data implictly attached to it, which we don't want). Or, we could just say the DATETIME is GMT, and make mysql date formats in Perl (we do this elsewhere in the code) instead of using MySQL's NOW().
Potential Solution #2
The server also keeps a history of old values for each string. The .dat file to live site replacement policy could be: "If this string has never been used, it's newer. If, however, it was previously used for this key and it's no longer the newest, don't replace it, because that'd essentially be reverting it."
Personally, I prefer #1 because it's more explicit and faster. (I think #2 would take forever when running loadtext)
Thoughts? I'm going to go ahead with #1 sometime this week probably unless I hear either a) alternate solutions, or b) volunteers who want to implement #1/alternate solutions.