We've seen export problems around keys with pootle recently, like Lithuanian. I investigated naively a bit, and here's my list of other possibly affected locales: mr/browser/chrome/browser/aboutDialog.dtd ms/browser/chrome/browser/aboutDialog.dtd ne-NP/browser/chrome/browser/aboutDialog.dtd ta/browser/chrome/browser/aboutDialog.dtd th/browser/chrome/browser/aboutDialog.dtd tn/browser/chrome/browser/aboutDialog.dtd Those have a localization for update.updateButton.label2, but no corresponding .accesskey. Dwayne, can you help here? Stuff like tn doesn't warrant a push to beta, but this seems to have affected a number of locales that are also just sporadically active.
FYI, this is the command I ran on my local clones: grep -L update.updateButton.acc `grep -l update.updateButton.label2 */browser/chrome/browser/aboutDialog.dtd `
Locale: mr / Marathi, ms / Malay, ta / Tamil, th / Thai
Axel, I'm not sure what caused the initial hickup but I now know what caused what we're seeing: 1) Pootle getting a set of empty POT files 2) Language updated against those cause the translations to be made obsolete 3) POT files are fixed in the next round 4) Files are recovered... but accesskeys which are one units are not recovered as mostly they're useless and all others that are recovered are made fuzzy. I've been rebasing the previous languages. But rebasing 2000 commits is a pain. I'm now just looking at a revert of that commit on 39 and 38. It look manageable but I had some issues. I'll deal with any specific ones you highlighted above mr, ms, ta, th. Then follow that with a global fix.
I implemented this revert in 38 so closing this bug.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.