touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

Hmmm... I can (mostly) recall the discussion we had with Michal around
that time (months ago). Back then, we decided that all the scope does is
set a LocationDataNeeded item to true in the scope.ini file. That
setting becomes available to the shell via the scope's metadata. The
shell is now responsible for adding a way for the user to
allow/fuzz/disallow the location data in the scope's settings menu.

We decided to do this because

- we didn't think it was reasonable for a scope to have to create a
settings.ini file just so the scope can get location data. (That's messy
because some scopes will have location data as their *only* setting.)

-  If each scope is responsible for creating its own settings.ini entry
for location data, what is essentially the same setting for all scopes
needs to be translated separately for each scope. That's a sure-fire way
to end up with inconsistent strings for this setting for different
scopes. It's a tri-state setting, with values "on, off, approximate".
(At least, that's what we were expecting at the time.) Besides, each and
every scope would have to make sure that it uses the exact same
definition for the name, type, and values of the enum.

- If the meaning of the location data setting ever changes in the future
(e.g., we change it to "off, precise to 100 km, precise to 10 km, full
precision"), the setting metadata definition is baked into each and ever
scopes settings.ini file, where we can't change it. For this reason, we
also decided that the user-select value of the setting should *not* be
stored in the scope's normal settings database, but somewhere else.

- Even if each scope were to create it's own settings.ini file, the
shell would *still* have to interpose itself in some way. Otherwise, the
scope could ship a settings.ini file that adds location data, sets the
default value to "true" (or "precise"), and the scope would get location
data without the user ever having given permission.

I just had a look through the code. The string was added with commit
448. Pete, I suspect that you were unaware of what we had decided
earlier when you made that change and, my apologies, I somehow missed
this during review. The intent all along was for the shell to notice the
LocationDataNeeded value in the metadata and to construct the additional
settings menu item in response to that.

So, just fixing the translation in the scopes-api won't really fix the
problem. Conceptually, the location data needed thing is much like the
rendering preferences that a scope indicates to the shell: the scope
just says "I want this", and the shell takes care of cooking this up in
the UI and making the state persistent. We have to make sure that:

- If we ever change the location data meaning, we can do so in the
future without breaking every installed scope.

- That a scope can't trick the machinery into providing location data
without explicit user permission.

- That the user-selected value is not stored in the normal scope
settings DB.

I'm reluctant to add translations to the scopes api, not because it's
more work, but because I think the string shouldn't be there in the
first place (and it's the only one). If we end up with UI concepts in
the scopes api that require translation, I strongly suspect we are doing
it wrong architecturally.

-- 
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 “unity-scopes-api” package in Ubuntu:
  New
Status in “unity8” package in Ubuntu:
  Invalid

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/unity-scopes-api/+bug/1393438/+subscriptions