761566 - Settings on about:home does not match string Firefox uses

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Brian King [:kinger]]

about:home now has a Settings button:

http://jboriss.wordpress.com/2012/05/18/update-on-firefox-13s-home-and-new-tab-redesign/

The string 'Settings' does not match what it is called elsewhere, e.g. 'Options' on Windows.

This might be a cause of some confusion for users.

Comment 1

[Marco Bonardo [:mak]]

hm, it's a bit late to change it, we may evaluate fixing it for future... I wonder if other localizations have been paying more attention so that we should just fix en-US.  But probably safer to change the key and force everyone to re-check.

Comment 2

[Axel Hecht [:Pike]]

Well, localizations can't fix this, as the name itself is platform dependent, so we need multiple strings, and pick the right one at runtime per platform.

Comment 3

[Marco Bonardo [:mak]]

I see
http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#314

Comment 5

[Mike Hoye [:mhoye]]

Flagging as a diamond bug, and I _think_ that the description is good enough to warrant Good Next status.

Comment 6

[:Paolo Amadini]

We are moving the concept of "Preferences" to something that is implemented natively inside the browser window, and we are now using the "instant apply" mode across all platforms with no more differences. This is known as the "in-content preferences" project, see for example bug 738797.

Given this new concept, can we just settle on using the term "Preferences" for this new type of browser customization, that is not platform-dependent anymore? This goes in the general direction of unifying the in-content and browser menu experience, and will simplify our code and localization by removing all the special cases we have put in place for Windows.

Jared, I see you are working on in-content preferences. Do you know if there is someone from UX that can make a decision on this? We can then file bugs to have the terminology unified.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

The term "in-content preferences" is a technical term that people working on the browser have been using, but it doesn't mean that we are changing user-facing terminology. "Options" is still the Windows-specific terminology, and we should respect that (see Windows 8.1 Explorer, http://screencast.com/t/R3nrOurF ).

I don't see this difference causing many issues between cross-platform experience.

Comment 8

[:Gijs (he/him)]

Stealing this as it's on the backlog, with no interest for a month, and we should just fix this.

Comment 9

[Marco Mucci [:MarcoM]]

Added to Iteration 32.3

Comment 10

[:Gijs (he/him)]

Attachment: add per-OS settings/options/preferences string,

I've added a separate string to the about:home strings because of potentially different space constraints / l10n considerations. Alternatively, we could reuse the ones from browser.dtd, but I suspect this is the better option.

Comment 11

[Marco Bonardo [:mak]]

Comment on attachment 8434258 [details] [diff] [review]
add per-OS settings/options/preferences string,

Review of attachment 8434258 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/locales/en-US/chrome/browser/aboutHome.dtd
@@ +26,5 @@
>  
>  <!ENTITY abouthome.bookmarksButton.label "Bookmarks">
>  <!ENTITY abouthome.historyButton.label   "History">
> +<!ENTITY abouthome.optionsButton.label  "Options">
> +<!ENTITY abouthome.preferencesButton.label  "Preferences">

off-hand, I think it's confusing for localizers to have here both optionsButton and preferencesButton, they may argue why we did such thing when they can only see one button.

I'd retain the classical way to handle this, by having preferencesButtonWin.label and preferencesButtonUnix.label

Comment 12

[:Paolo Amadini]

(In reply to Marco Bonardo [:mak] from comment #11)
> I'd retain the classical way to handle this, by having
> preferencesButtonWin.label and preferencesButtonUnix.label

And a small <!-- LOCALIZATION NOTE (preferencesButtonWin.label, preferencesButtonUnix.label): ... --> won't hurt, localizers appreciate those :-)

Comment 13

[:Gijs (he/him)]

w/ changed entities + l10n note

remote:   https://hg.mozilla.org/integration/fx-team/rev/09d3ce10e110

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/09d3ce10e110

Comment 15

[Marco Mucci [:MarcoM]]

Hi Florin, can a QA contact be assigned to this bug for verification.

Comment 16

[Catalin Varga [QA][:VarCat]]

Verified as fixed using the following environment:

FF 32
Build Id: 20140609030202
OS: Win 7 x64, Mac Os X 10.8.5, Ubuntu 12.10 x32