1399502 - [meta] Change remaining "Options" and "Preferences" references to "Settings" (including URL)

Status: NEW

(Firefox :: Menus, enhancement, P3)

Description

[Stephen Horlander [:shorlander]]

Over the years Windows has internally referred to Settings as Options or Settings. This inconsistency has gradually resolved to Settings over Options and in Windows 10 consistently uses Settings.

For consistency we should change Options to Settings and on Windows this should resolve to about:settings

Comment 1

[:Gijs (he/him)]

I was trying to implement this, but it looks super hairy. We use "options" in a *lot* of places ( https://dxr.mozilla.org/mozilla-central/search?q=Options+file%3A.dtd&redirect=true and https://dxr.mozilla.org/mozilla-central/search?q=Options+file%3A.properties&redirect=false (that's 50-60 strings in total, minus comments plus change for access keys)). We would have to update all/most of those strings, and rev their ids, and change their access keys, and then potentially change other items' access keys (e.g. in the Tools menu, we want the "s" access key, so we need to change the 'sync now' access key). ***

I don't know if this is realistically doable for 57, even without the URL change, also because of the mayhem it inflicts on localizers this close to the merge (which is *this week*).

Can we please wontfix for 57? This was filed very late in the cycle, and isn't really all that related to the other structure changes we're making for 57, so I think it can wait a cycle.


*** Yes, I realize we could in theory only update the items that refer to the "actual" full-on Firefox options, but that (a) introduces inconsistency, and (b) would still require auditing all those strings, updating them, getting that reviewed, landed, and then making localizers do the same thing.

Comment 2

[Francesco Lodolo [:flod]]

(In reply to :Gijs from comment #1)
> Can we please wontfix for 57? This was filed very late in the cycle, and
> isn't really all that related to the other structure changes we're making
> for 57, so I think it can wait a cycle.

We *really* need to keep this out of 57. 

Changing strings all over the place means shipping mixed translations until all languages have caught up with the changes (unless we decide to fix only English). Doing it now, it means shipping several beta in poor state, and maybe even 57 release. There is very little to gain from making this change now.

Comment 3

[:Gijs (he/him)]

Stephen replied on slack. Gonna wontfix for 57.

Comment 4

[Francesco Lodolo [:flod]]

Side questions:
* Should we start using "Settings" for new features and strings?
* Does it mean that we're going to have 3 variants: Options (Linux), Settings (Windows), and Preferences (macOS)? That seems extremely hard to manage.

Comment 5

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #4)
> Side questions:
> * Should we start using "Settings" for new features and strings?
> * Does it mean that we're going to have 3 variants: Options (Linux)

I think we use "Preferences" on Linux, certainly for the main prefs... what did I miss?

Comment 6

[Francesco Lodolo [:flod]]

(In reply to :Gijs (no reviews; PTO recovery mode) from comment #5)
> > * Does it mean that we're going to have 3 variants: Options (Linux)
> 
> I think we use "Preferences" on Linux, certainly for the main prefs... what
> did I miss?

Clearly not enough coffee on my side. 
* Linux, macOS: Preferences
* Windows: Options (changing to Settings)

So there would still be 2 variants.

Comment 7

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #6)
> So there would still be 2 variants.

Yep, we're just changing Windows. :-)

Comment 9

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Do you think you can make the change before the next ESR, so we do not have two different localizations in two supported Firefox versions? Also I think the change should include Thunderbird too.

Comment 10

[:Gijs (he/him)]

I can make this change for Firefox for 60. I don't have any influence over what Thunderbird does. I'm not sure they would take a patch even if I had one, and in any case it wouldn't happen in this bug as all the relevant strings are in browser/ .

Comment 11

[Francesco Lodolo [:flod]]

+zibi, since we're migrating strings to Fluent, and I wonder what the best timing for this would be.

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

I don't think it's blocking. I'd be happy to see this landing before the Fluent switch if possible since then we'll be able to migrate to Fluent without ID inflation, but we can also handle it after, so up to Gijs.

Comment 13

[:Gijs (he/him)]

My Q1/Q2 priorities are basically "perf". Having looked at this again, I don't think I have time to work on this. It's significantly more involved than just re-doing the strings for the page and menu itself, because we use the "options" terminology in lots of other strings that then also need updating along with the places where we use them, rev IDs, adjust access keys in a way that doesn't conflict with whatever the context is, etc. etc.

So I'm unassigning. Dão, Stephen, please ensure that *if* this needs prioritizing for 60 (given esr) as photon cleanup, that someone else picks it up. Otherwise, it'll have to wait until folks are more available to work on this.

Comment 14

[Stephen Horlander [:shorlander]]

It's not urgent. Going to leave the reserve whiteboard flag.

Comment 15

[Rokas]

Hello, May I take on this task?
Im new to mozilla development, so any guidance would be highly appreciated.

Comment 16

[:Gijs (he/him)]

(In reply to Rokas from comment #15)

Hello, May I take on this task?
Im new to mozilla development, so any guidance would be highly appreciated.

This isn't really easy enough to be a good bug to start on if you're new to mozilla development. Maybe try looking at https://codetribute.mozilla.org/projects/ff ?

Comment 17

[Rokas]

Thanks, ill have a look.

Comment 18

[Dão Gottwald [:dao]]

Bug 1620536 comment 24 suggests that we should make this change on all platforms.

Comment 19

[Stephen Horlander [:shorlander]]

(In reply to Dão Gottwald [::dao] from comment #18)

Bug 1620536 comment 24 suggests that we should make this change on all platforms.

I don't think we should deliberately create a situation where we use different terminology depending on which surface you happen to use as an entry point. Which in this case would cause a mismatch between Menubar --> Firefox --> Preferences… and Application Menu --> Settings… on macOS.

The point of this bug was to create more internal and external consistency, not less.

Comment 20

[:Gijs (he/him)]

macOS and Windows have all aligned on "Settings" now, and in fact even though we have "Preferences" in our codebase for macOS - https://searchfox.org/mozilla-central/rev/d87ac4f189d6c1ad068bc3d1cdf50d2f871028c2/browser/locales/en-US/browser/menubar.ftl#13 - macOS actually shows "Settings..." these days.

One of the obvious remaining issues is the URL. Thankfully a contributor just provided a patch in bug 1839845 that makes about:settings work. Based on that I think we can start moving other consumers over, and eventually retire about:preferences and rename any straggling references.