Created attachment 331352 [details] [diff] [review] v1 Label for "Check for Updates" menu-item has several variations (see http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/browser.properties#65). Currently there is only one accesskey, which is used for all of them. This makes localizer's life even harder. For some locales it can be impossible to choose char that is available in every of these strings. Let's use separate accesskeys, just like SeaMonkey does. BTW: with this we can (and this patch does it) fix wontfixed Bug 296016 Note to reviewer: Patch adds a localization note - if you have a better wording, let me know (I'm not native en speaker). Thx.
Attachment #331352 - Flags: review?(gavin.sharp)
Comment on attachment 331352 [details] [diff] [review] v1 >diff -r fd8f55f1e10f browser/base/content/baseMenuOverlay.xul > <menuitem id="checkForUpdates" >- accesskey="&updateCmd.accesskey;" This means the menu item won't have an accesskey if updates are disabled (i.e. if we return early from buildHelpMenu()), but that's not that big of a deal since it will be disabled in that case, and it's better for localizers to only have to set the accesskey in one place anyways. Sorry for the delay here...
Attachment #331352 - Flags: review?(gavin.sharp) → review+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090422 Minefield/3.6a1pre Is there a plan to get it into 1.9.1 after b4?
Status: RESOLVED → VERIFIED
No, I don't think it's worth breaking 1.9.1 string freeze. The less new strings after b4, the better for L10n teams.
(In reply to comment #4) > No, I don't think it's worth breaking 1.9.1 string freeze. The less new strings > after b4, the better for L10n teams. Please review that decision. I realise its too late now but if it had been done for b4 the Afrikaans team would have made the needed change as its simply broken and ugly in our language. I for one don't like new translations in a string freeze, but these are simply broken translations and we as a team do want to fix those. Other languages have this problem, bug 437581 (Hebrew) and bug 488484 (Afrikaans team). Bug 315226 seems to indicate that this issue has been a problem since late 2005. Will this be fixed for post 3.5 bug fix releases e.g. 184.108.40.206?
(In reply to comment #7) > Will this be fixed for post 3.5 bug fix releases e.g. 220.127.116.11? Question for Axel, but I don't think so.
I don't think the reward here is big enough to warrant the trouble. If we have a real fish to fry, this could be a ride-along, though.
@Axel is there a process in place to keep track of these bugs. I'd like to know that they do get reviewed when bigger fishes come along?
@Dwayne, talked to Sam and we agreed that wanted1.9.1.x is the right flag to set. I'm setting the late-l10n keyword as well, so that we know that this has l10n impact.
Axel: is this still wanted to land in 1.9.1.x? This should have gone into 18.104.22.168, but now that it hasn't is it worth bothering with? I think "blocking" is the only way to make sure this gets landed, or an approval request on the patch, if you still want it.
blocking1.9.1: --- → ?
status1.9.1: --- → wanted
This never really wanted to be in 1.9.1.x, it was more of a "let's see if we need to break string freeze, then we'd take it". Trying to set the flags to indicate "nah, not 1.9.1.x".
blocking1.9.1: ? → -
status1.9.1: wanted → wontfix
status1.9.1: "wontfix" is exactly how you do that -- thanks.
You need to log in before you can comment on or make changes to this bug.