GNOME Bugzilla – Bug 726498
Geolocation strings are misleading
Last modified: 2014-04-02 06:59:53 UTC
The Location section in the system status menu has two possible states: "On" or "Off". The submenu also includes a "Turn Off" or "Turn On" item. These strings are misleading: when geolocation is on, it usually actually isn't "on" - it is available to be used, but it isn't actually running. The following strings would provide clearer feedback about what is going on: * "Enabled" * "Disabled" * "In use" With this schema the submenu would have "Enable" and "Disable" actions, rather than "Turn On" and "Turn Off".
(In reply to comment #0) > * "Enabled" > * "Disabled" FWIW, we already have those elsewhere, so not a string freeze break. > * "In use" > "Enable" and "Disable" Those require a string freeze break.
(In reply to comment #1) > (In reply to comment #0) > > * "Enabled" > > * "Disabled" > > FWIW, we already have those elsewhere, so not a string freeze break. > > > > * "In use" > > "Enable" and "Disable" > > Those require a string freeze break. :( That means if we put them in even now, we won't get them translated to enough languages in time for release?
Created attachment 272481 [details] [review] location: Improved language * 'Turn On' -> 'Enable' * 'Turn Off' -> 'Disable' * 'Off' -> 'Disabled' * 'On' -> 'In Use' or 'Enabled' depending on whether or not service is in use.
(In reply to comment #2) > (In reply to comment #1 > > Those require a string freeze break. > > :( That means if we put them in even now, we won't get them translated to > enough languages in time for release? Well, technically it means that there's one more team to ask for permission if we want this addressed for 3.12 (and unlike hard code freeze, the string freeze doesn't go away with 3.12.0).
Review of attachment 272481 [details] [review]: ::: js/ui/status/location.js @@ +165,2 @@ } else { + this._item.status.text = this._indicator.visible ? _("In Use") : _("Enabled"); Are we sure that starting to use location services will always trigger a max-accuracy-level change? From a glance the code looks like we can end up with a visible location indicator while still showing "Enabled" in the menu ...
Review of attachment 272481 [details] [review]: ::: js/ui/status/location.js @@ +165,2 @@ } else { + this._item.status.text = this._indicator.visible ? _("In Use") : _("Enabled"); > Are we sure that starting to use location services will always trigger a max-accuracy-level change? No. I didn't think of changing of label on change of 'service in use' actually. I'll look into that.
Created attachment 272484 [details] [review] v2: React to changes in 'InUse' property.
Review of attachment 272484 [details] [review]: LGTM.
(In reply to comment #8) > Review of attachment 272484 [details] [review]: > > LGTM. Good, could you please test it for me too? :P
Review of attachment 272484 [details] [review]: Hmm, for some reason it shows "In Use" on startup, despite the status icon being hidden ...
Created attachment 272488 [details] [review] location: Improved language v3: This should work better. If not, next time I do my own testing before submission. :)
Review of attachment 272488 [details] [review]: OK. Not a problem of this patch, but: Disabling doesn't really seem to have any effect (apart from updating the labels)? The location icon is shown in the status area when starting maps, regardless of whether it's enabled or not :-(
(In reply to comment #12) > Review of attachment 272488 [details] [review]: > > OK. > > Not a problem of this patch, but: Disabling doesn't really seem to have any > effect (apart from updating the labels)? The location icon is shown in the > status area when starting maps, regardless of whether it's enabled or not :-( That is bug#726497, unless Maps can actually query location.
Ah good, it's already tracked then - so time to ask for freeze exceptions if we want this in 3.12 :-)
(In reply to comment #14) > Ah good, it's already tracked then - so time to ask for freeze exceptions if we > want this in 3.12 :-) Done! Its likely that we can only get it into 3.12.1 and even that if we are lucky. Fingers crossed!
b(In reply to comment #15) > (In reply to comment #14) > > Ah good, it's already tracked then - so time to ask for freeze exceptions if we > > want this in 3.12 :-) > > Done! Its likely that we can only get it into 3.12.1 and even that if we are > lucky. Fingers crossed! Got all ACK for 3.12.1. Can I push now?
Sure!
Attachment 272488 [details] pushed as b0bdf7f - location: Improved language
*** Bug 727476 has been marked as a duplicate of this bug. ***