| Thread Previous • Date Previous • Date Next • Thread Next |
Right, what you wrote above I totally agree with, but it's not how it's
currently implemented, and we were not aware this is how it was supposed
to work. We just got a new boolean setting and we dealt with it as with
any other.
Now, to rectify this untranslatable string somewhat quickly, I propose
the setting comes of "location" instead of "boolean" type, which we'd
then render as we please, including the currently-untranslatable string.
Long-term, IMO we should make use of the trusted location helper, which
would take care of ensuring the scope in question is allowed to get
location data (and of what accuracy), the dash would either act as a
proxy, as it does today, or the scope will request data from the
location service directly, but we'd then need a way to link the scope
process to a surface on which to open the location trust store dialog.
That would be useful for other use cases as well (payments, accounts
etc.), so might be a nobler goal.
** Changed in: unity-scopes-api (Ubuntu)
Status: New => Confirmed
** Changed in: unity-scopes-api (Ubuntu)
Status: Confirmed => Triaged
** Changed in: unity8 (Ubuntu)
Status: Invalid => Confirmed
** Also affects: location-service (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity8 in Ubuntu.
https://bugs.launchpad.net/bugs/1393438
Title:
"Enable location data" string displays untranslated
Status in “location-service” package in Ubuntu:
New
Status in “unity-scopes-api” package in Ubuntu:
Triaged
Status in “unity8” package in Ubuntu:
Confirmed
Bug description:
Using rtm 162 on krillin, several of the dash screens have a "enable
location data" option, that strings seems to not be translatable
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1393438/+subscriptions
| Thread Previous • Date Previous • Date Next • Thread Next |
