Closed Bug 761566 Opened 8 years ago Closed 6 years ago
Settings on about:home does not match string Firefox uses
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.
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.
Component: Preferences → General
QA Contact: preferences → general
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.
Whiteboard: [about-home] → [about-home] p=0
Whiteboard: [about-home] p=0 → [about-home] p=0 [mentor=mak]
Whiteboard: [about-home] p=0 [mentor=mak] → [about-home] [mentor=mak] p=0
Whiteboard: [about-home] [mentor=mak] p=0 → [about-home] [mentor=mak] p=1
No longer blocks: fxdesktopbacklog
Flagging as a diamond bug, and I _think_ that the description is good enough to warrant Good Next status.
Whiteboard: [about-home] [mentor=mak] p=1 → [about-home] [mentor=mak] p=1 [diamond] [good-next-bug]
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.
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.
Whiteboard: [about-home] [mentor=mak] p=1 [diamond] [good-next-bug] → [about-home] [mentor=mak] [diamond] [good-next-bug] p=1 [qa?]
Stealing this as it's on the backlog, with no interest for a month, and we should just fix this.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Whiteboard: [about-home] [mentor=mak] [diamond] [good-next-bug] p=1 [qa?] → p=1 [qa+]
Added to Iteration 32.3
Whiteboard: p=1 [qa+] → p=1 s=it-32c-31a-30b.3 [qa+]
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.
Attachment #8434258 - Flags: review?(mak77)
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
Attachment #8434258 - Flags: review?(mak77) → review+
(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 :-)
w/ changed entities + l10n note remote: https://hg.mozilla.org/integration/fx-team/rev/09d3ce10e110
Whiteboard: p=1 s=it-32c-31a-30b.3 [qa+] → [fixed-in-fx-team] p=1 s=it-32c-31a-30b.3 [qa+]
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team] p=1 s=it-32c-31a-30b.3 [qa+] → p=1 s=it-32c-31a-30b.3 [qa+]
Target Milestone: --- → Firefox 32
Hi Florin, can a QA contact be assigned to this bug for verification.
Whiteboard: p=1 s=it-32c-31a-30b.3 [qa+] → p=1 s=33.1 [qa+]
QA Contact: catalin.varga
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
Status: RESOLVED → VERIFIED
Whiteboard: p=1 s=33.1 [qa+] → p=1 s=33.1 [qa!]
You need to log in before you can comment on or make changes to this bug.