See https://bugzilla.mozilla.org/show_bug.cgi?id=367596#c108 and next comments. HIGs references: http://blogs.msdn.com/oldnewthing/archive/2004/05/17/133181.aspx http://library.gnome.org/devel/hig-book/stable/menus-design.html.en http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGText/XHIGText.html Since in this case it opens a dialog where the user does not have to add further input the ellipsis are not needed.

Is it ok to just get rid of the ellipsis in this case or do you want a new entity name?

I bet locales copied the ellipsis, so we'll need a new entity name. We could just use helpTroubleshootingInfo, i.e. append Info, I guess.

Comment on attachment 406664 [details] [diff] [review] patch v1.0 IMHO, this can just go without change. Sorry for the lag. Announce in .l10n, and do a follow-up mxr query, and file bugs per locale still affected.

http://mxr.mozilla.org/l10n-central/search?string=helpTroubleshooting.label&find=baseMenuOverlay.dtd&findi=&filter=^[^\0]*%24&hitlimit=&tree=l10n-central suggests that all but one locales copied the ellipsis, so in the end this might just be more work: (In reply to comment #3) > Announce in .l10n, and do a follow-up mxr query, and file bugs per locale still > affected.

Maybe. I'm pretty sure this won't land for 3.6 anymore if we require this change, though.

so, it's not clear to me if you urgently want this on 1.9.2 or not. Seeing the annouce request i think so, but seeing "this won't land if we require this change" i think the opposite. Please clarify, sorry if i didn't get it.

http://hg.mozilla.org/mozilla-central/rev/25696e11dfe8 Pike, please clarify plan for 1.9.2.

So, you did land it without key change, at which point, you've decided to go the soft path. This could land on 1.9.2 if desired by the product drivers. In any case, you should reach out in .l10n and ask localizers to catch up on this.

(In reply to comment #8) > So, you did land it without key change, at which point, you've decided to go > the soft path. hm, well, really i asked you before! Sure, i will create a thread in l10n. asking beltzner about the fact we want it or not.

I don't think we need it in 1.9.2, not worth the cost. We'll fix it in 1.9.3/Firefox 3.7

after a brief talk we are going to take a soft change on 1.9.2 and an entity change on central.

Indeed, this is a bit of a mess. The change should indeed change the identity on mozilla-central. I don't think we should have it fixed in some locales and not others (that inconsistency will be bothersome for screenshots, etc) so I think we should leave it as wontfix for 1.9.2. It's not a big deal.

ok let's go for the entity change on central. no further action needed for 1.9.2

Comment on attachment 408874 [details] [diff] [review] additional patch I'm not a friend of .label2, but this seems to be the least-bad compromise here. You probably still need review from a browser peer to land.

What's wrong with helpTroubleshootingInfo?

Comment on attachment 408874 [details] [diff] [review] additional patch see bug 421609 comment 6

(In reply to comment #15) > What's wrong with helpTroubleshootingInfo? is this a suggestion to use helpTroubleshootingInfo in please of helpTroubleshooting.label? (In reply to comment #16) > (From update of attachment 408874 [details] [diff] [review]) > see bug 421609 comment 6 so this should be helpTroubleshooting2.label? then we would have helpTroubleshooting2.label helpTroubleshooting.accesskey is this expected or should i change both?

Both entities need to be adjusted. My suggestion would be helpTroubleshootingInfo.label and helpTroubleshootingInfo.accesskey.

it's fine for me, will provide an updated patch soon, unless Axel has anything against that.

If you're fine with the bigger patch size, helpTroubleshootingInfo.* would probably be nicest.

first patch posted through a Mac