The term "mouse cursor" is rather antiquated, and we should use "mouse pointer" or even just "pointer" instead. (trackpads, trackballs, etc)

Yes, "pointer". The pointer is a cursor only on text.

Google and Bing both show "mouse pointer" and "mouse cursor" as evenly matched. But Windows UI seems to strongly prefer "pointer" (the control panel has a "pointer options" page which uses the word 6 more times). Curiously, OS X manages to avoid both terms for the most part, although I did find one mention of "mouse pointer". I guess "cursor" may leak in more from the technical side... There's the .CUR file format, both the Windows and Cocoa system APIs call them cursors (eg WM_SETCURSOR and NSCursor), and then there's the CSS |cursor| property which can take the value of |pointer|! Of course none of this is relevant to UI. :)

Went with just "pointer". Fortunately the string IDs seem to not mention "cursor" anywhere...

Comment on attachment 732390 [details] [diff] [review] Patch A native English speaker should review this stuff, and technically if we're changing localization, property/entity name should be changed too, I think

So we could also change the property IDs. Note that I needed to change that of the "Hide pointer" accesskey as well because that string is accessed dynamically based on the ID of the label, which means that changing only one breaks the entire dialog (figured that out when doing a sanity test...).

Comment on attachment 732451 [details] [diff] [review] Patch v2, Change string IDs as well I discussed this with Gavin on IRC, and we thought that we may want to take the first patch on aurora (because of the "Don't change strings please" rule) and the second on m-c. Axel, does that sound right to you?

Comment on attachment 732451 [details] [diff] [review] Patch v2, Change string IDs as well Review of attachment 732451 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/locales/en-US/chrome/browser/pageInfo.dtd @@ +65,5 @@ > <!ENTITY permInstall "Install Extensions or Themes"> > <!ENTITY permGeo "Share Location"> > <!ENTITY permPlugins "Activate Plugins"> > <!ENTITY permFullscreen "Enter Fullscreen"> > +<!ENTITY permPointerLock2 "Hide the Pointer"> I'm thinking this one should probably keep the reference to 'mouse' -- "Hide the Mouse Pointer". The other ones have a more obvious context (and the notification icon is a ginormous pointer :), where as this one is is buried in Page Info amongst a hodgepodge of random things. Seems more likely to be confusing.

Comment on attachment 732390 [details] [diff] [review] Patch (Same comment about permPointerLock as in last comment) Otherwise this WFM if we want to avoid the churn on Aurora, although I wouldn't expect it to be a big deal just a few days after uplift.

(In reply to Justin Dolske [:Dolske] from comment #7) > Comment on attachment 732451 [details] [diff] [review] > Patch v2, Change string IDs as well > > Review of attachment 732451 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: browser/locales/en-US/chrome/browser/pageInfo.dtd > @@ +65,5 @@ > > <!ENTITY permInstall "Install Extensions or Themes"> > > <!ENTITY permGeo "Share Location"> > > <!ENTITY permPlugins "Activate Plugins"> > > <!ENTITY permFullscreen "Enter Fullscreen"> > > +<!ENTITY permPointerLock2 "Hide the Pointer"> > > I'm thinking this one should probably keep the reference to 'mouse' -- "Hide > the Mouse Pointer". The other ones have a more obvious context (and the > notification icon is a ginormous pointer :), where as this one is is buried > in Page Info amongst a hodgepodge of random things. Seems more likely to be > confusing. Landed on inbound with that corrected: https://hg.mozilla.org/integration/mozilla-inbound/rev/4d1787e7e3cf

I'm not sure I agree with the "pointer" argument to begin with. We're not using that phrase at all anywhere in our UI yet. If UX wants to change that, we should do it consistently throughout, and not start at one little corner of our product.

(In reply to Axel Hecht (pto - April 2) [:Pike] from comment #10) > If UX wants to change that, we should do it consistently throughout, and not > start at one little corner of our product. We're not using "cursor" anywhere else in our UI either AFAICT, so I'm not sure what missing consistency you're looking for.

cursor is rare, but shows up in the same meaning a few times, http://transvision.mozfr.org/?sourcelocale=en-US&locale=de&repo=aurora&search_type=strings&recherche=cursor. Many other meanings are actually about the cursor keys, granted.

The only two other references I see that aren't touched by this patch are for caret browsing (one in SeaMonkey, one in the Firefox prompt on enabling), where it wouldn't make sense to switch to "pointer".

What's the best path for getting to Aurora? Uplift the patch that landed on m-c, or just change the strings without updating the entity/properties?

Let's just land attachment 732390 [details] [diff] [review] on Aurora.

Comment on attachment 732390 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): 737100 User impact if declined: Strange description of pointer lock; change in description between 22 and 23 when there's an update. Testing completed (on m-c, etc.): Been on m-c for 5 days, no problems. Risk to taking this patch (and alternatives if risky): 0, except localizers may theoretically notice we switched from saying "cursor" to "pointer". String or IDL/UUID changes made by this patch: Changed all "cursor" stuff to "pointer"

For the record, I think if the original bug shouldn't ship as is, it should be backed out of aurora. Busting string freeze isn't worth it for this feature, IMHO.

(In reply to Axel Hecht (pto - April 2) [:Pike] from comment #18) > For the record, I think if the original bug shouldn't ship as is, it should > be backed out of aurora. From my perspective, this an en-US-only enhancement to the terminology. It's not a blocker and if other locales don't notice the "silent" change on Aurora it's not a big deal.

I disagree. Fixing a bug for 40% of our users isn't worth it.

Isn't worth what? What is the cost to landing attachment 732390 [details] [diff] [review] on Aurora?

Quite a few localizers (*) are working on infrastructures that untranslates that string without further action on behalf of the localizer. It's rather simple: The rapid release cycle was designed to "ship it or back it out", and that's what l10n is built on top of. This bug is one of the ones that makes this cycle breaking string freeze yet again. We suck, big time, and the desktop product is getting harder and harder to keep alive. (*) ... being the folks working off of translate-toolkit, which marks those strings as fuzzy, and reverts then to en-US, if you're trying to fix something else without paying attention to that one.

(In reply to Axel Hecht (pto - April 2) [:Pike] from comment #22) > Quite a few localizers (*) are working on infrastructures that untranslates > that string without further action on behalf of the localizer. It does this based on the value (rather than the name) of the string? > It's rather simple: The rapid release cycle was designed to "ship it or back > it out", and that's what l10n is built on top of. This bug is one of the > ones that makes this cycle breaking string freeze yet again. We suck, big > time, and the desktop product is getting harder and harder to keep alive. We're not "breaking string freeze" if we make no requirements on localizers to handle new/modified strings. If you're saying there's no mechanism for us to make en-US-only string changes on Aurora without triggering l10n system complications, that seems like a failing we need to solve.

What you're saying is that it's OK to ship strings in localizations that you're not willing to ship in en-US. That's failing that needs to be resolved, I think.

(In reply to Axel Hecht [:Pike] from comment #24) > What you're saying is that it's OK to ship strings in localizations that > you're not willing to ship in en-US. No, that's not what I'm saying. I would be willing to ship Aurora en-US as-is, but given that we've decided to change the string on trunk, it's better for us to avoid shipping the string and then immediately changing it again in the next cycle. It seems unlikely to me that other languages would even have the same cursor vs. pointer distinction that en-US has anyways.

Landed on aurora per comment #25.