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.