It's similar to bug 826840 but for the Custom and Control Firefox menu. On Windows, the setting button is named Preferences and opens Options (window or tab for in-content). It should be Options or Settings everywhere for any OSes. I see it's named Settings in http://people.mozilla.com/~shorlander/files/australis-design-specs/australis-design-specs-osx.html and Options in http://people.mozilla.com/~shorlander/files/customization-tab-i01/customizationTab-quickDisplay.html

Considering that about:home is using "Settings", I think that would be a good compromise. http://hg.mozilla.org/mozilla-central/file/4ffb23062b3b/browser/locales/en-US/chrome/browser/aboutHome.dtd#l29

Matej, do you have any thoughts on this? To summarize: Australis has a button (widget) to open Firefox settings window, currently using "Preferences" as a label, so it doesn't match the corresponding menu command on Windows. Would it be ok to use "Settings" for this label, as in about:home?

Are we only solving for Windows here? I'm just wondering why "Settings" is preferable since then it doesn't match either Windows or Mac.

My assumption is that the button label should be the same as the old OS-specific menuitem. about:home is an interesting example, but I wouldn't be surprised if many users simply didn't use that as an entry-point. Perhaps we should fix that one too (not sure if that was an explicit decision or not).

> I'm just wondering why "Settings" is preferable since then > it doesn't match either Windows or Mac. I guess that's the point. Having Preferences would confuse Windows users, having Options would sound wrong for Mac and Linux users, Settings is kind of os-agnostic. (In reply to Justin Dolske [:Dolske] from comment #4) > My assumption is that the button label should be the same as the old > OS-specific menuitem. So changing based on the OS? Sounds definitely good to me. I checked bug 711157 but I couldn't find anything about this choice.

If we can change based on OS, that would get my vote. Otherwise "Settings" sounds good to me. Thanks.

Stealing this, I hope you don't mind... Let me know what you think of this appapproach. :-)

Comment on attachment 807163 [details] [diff] [review] Make 'Preferences' be 'Options' on Windows, Why does the tooltip end with an ellipsis?

(In reply to Dão Gottwald [:dao] from comment #8) > Comment on attachment 807163 [details] [diff] [review] > Make 'Preferences' be 'Options' on Windows, > > Why does the tooltip end with an ellipsis? Because the Preferences one does too? I was just going for consistency with what we have.

I don't think it makes sense, and we shouldn't strive for consistency with something broken. It's particularly bad for strings where changing them again later on requires extra work for all locales.

(In reply to Dão Gottwald [:dao] from comment #10) > I don't think it makes sense, and we shouldn't strive for consistency with > something broken. It's particularly bad for strings where changing them > again later on requires extra work for all locales. Well, can you describe what would make sense? Traditionally, in my understanding, anything that opens a dialog has ellipses. In the designs, none of the menupanel's buttons have ellipses in their labels. So instead there are ellipses in the tooltips. I'm not entirely sure why this is "broken".

Ellipsis are added when a command will have an extra confirmation or configuration step rather than being executed directly. So for instance, you know that "Print..." won't immediately start the printer and "Clear Recent History..." won't immediately delete data. There's no such intermediate step for Options/Preferences, and therefore this menu item traditionally doesn't get an ellipsis. You can still see it in the menu bar. The same is true for various other menu items that open windows, dialogs or tabs. I don't think moving ellipses from labels to tooltips makes sense either, as it defeats their purpose of clearly informing the user of the intermediate step.

(In reply to Dão Gottwald [:dao] from comment #12) > There's no such intermediate step > for Options/Preferences, and therefore this menu item traditionally doesn't > get an ellipsis. Actually, Preferences has an ellipsis on OS X. On all apps.

(In reply to Dão Gottwald [:dao] from comment #12) > I don't think moving ellipses from labels to tooltips makes sense either, as > it defeats their purpose of clearly informing the user of the intermediate > step. Can we have this discussion in another landing-blocking (M9) bug, please? Needinfo madhava and/or matej and/or shorlander, as I don't think this is clear-cut. While this hasn't landed on m-c, nobody should be localizing anything just yet, and we don't need to scopecreep this bug into "fix all the ellipses".

(In reply to :Gijs Kruitbosch from comment #13) > (In reply to Dão Gottwald [:dao] from comment #12) > > There's no such intermediate step > > for Options/Preferences, and therefore this menu item traditionally doesn't > > get an ellipsis. > > Actually, Preferences has an ellipsis on OS X. On all apps. That must be a special OS X thing then. We follow no rule that says to add ellipses to all items that open dialogs, though, for the reason I stated. Not even on OS X. And is bug is about Windows anyway. (In reply to :Gijs Kruitbosch from comment #14) > Can we have this discussion in another landing-blocking (M9) bug, please? I don't think there's a need for further discussion here. > Needinfo madhava and/or matej and/or shorlander, as I don't think this is > clear-cut. While this hasn't landed on m-c, nobody should be localizing > anything just yet, and we don't need to scopecreep this bug into "fix all > the ellipses". I don't say fix all the ellipses in this bug, you just shouldn't have it in the string you're adding here.

(In reply to Dão Gottwald [:dao] from comment #15) > (In reply to :Gijs Kruitbosch from comment #14) > > Can we have this discussion in another landing-blocking (M9) bug, please? > > I don't think there's a need for further discussion here. > > > Needinfo madhava and/or matej and/or shorlander, as I don't think this is > > clear-cut. While this hasn't landed on m-c, nobody should be localizing > > anything just yet, and we don't need to scopecreep this bug into "fix all > > the ellipses". > > I don't say fix all the ellipses in this bug, you just shouldn't have it in > the string you're adding here. I'm confused. I *think* you're saying: 1) you want me to change one of the strings I'm adding 2) you disagree with all (or some) of the existing tooltip ellipses, and the lack of ellipses on labels. 3) you don't want those to get changed here. 4) you don't think we should have a bug to discuss your suggestion, or to update the ellipses/labels per your suggestion (whatever that would entail) before landing on m-c. Is this summary correct? I'm sure I'm misunderstanding some part of it, but I'm not sure which part.

(In reply to :Gijs Kruitbosch from comment #16) > 4) you don't think we should have a bug to discuss your suggestion, or to > update the ellipses/labels per your suggestion (whatever that would entail) > before landing on m-c. > > Is this summary correct? I'm sure I'm misunderstanding some part of it, but > I'm not sure which part. What I wrote was a rehash of our rule for when to add ellipses, since you seemed to have asked for that in comment 11. It wasn't my personal suggestion of a rule we should adopt but rather a description of what we already had adopted. It's in line with our menu bar on Windows, Linux and for the most part on OS X, I believe. So I do think we should have a bug correcting the existing strings. At the same time, we shouldn't land more strings doing it wrong.

Comment on attachment 807163 [details] [diff] [review] Make 'Preferences' be 'Options' on Windows, I agree with comment #17.

Same patch, sans ellipsis this time.