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.
Created attachment 406664 [details] [diff] [review] patch v1.0 Is it ok to just get rid of the ellipsis in this case or do you want a new entity name?
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Attachment #406664 - Flags: review?(l10n)
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.
Attachment #406664 - Flags: review?(l10n) → review+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
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
status1.9.2: --- → wontfix
after a brief talk we are going to take a soft change on 1.9.2 and an entity change on central.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Created attachment 408874 [details] [diff] [review] additional patch ok let's go for the entity change on central. no further action needed for 1.9.2
Attachment #408874 - Flags: review?(l10n)
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.
Attachment #408874 - Flags: review?(l10n) → review+
Attachment #408874 - Flags: review?(gavin.sharp)
What's wrong with helpTroubleshootingInfo?
Comment on attachment 408874 [details] [diff] [review] additional patch see bug 421609 comment 6
Attachment #408874 - Flags: review?(gavin.sharp) → review-
(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.
Created attachment 411677 [details] [diff] [review] additional patch v1.1 first patch posted through a Mac
Attachment #411677 - Flags: review?(dao) → review+
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.