Bugzilla – Bug 153583
[zypp] UI should intform backend about possible locales to choose from
Last modified: 2006-03-30 09:20:44 UTC
The language dependant packages are now handled by the solver. In order to perform its task, it must know which languages are available. This should be in sync with the language list the user can choose from in the UI. ZYpp::setPossibleLocales (LocaleSet) should be called by UI for this purpose. Assign to sh, cc to mvidner
It does not work that way. The UI takes the language list from Y2PM::languageManager(), which probably gets the list by scanning what the selections and packages provide. That way the UI can offer exactly the relevant languages - excluding ones that have no packages and not forgetting ones that do have them.
Ok, ZYpp can provide a "LocaleSet supportedLocales()" (or availableLocales() ?). But this is just a set of Locales, without translation or any other UI relevant information. Does the UI filter the list of all languages (from yast2-language data) with this set ?
ZYpp now has "LocaleSet getAvailableLocales() const;" but after talking to Stefan, is looks as he prefers a List/Set of Selectables. To be implemented in zypp/ui
The 'Language' kind resolvables also provide a summary with a user-readable language name now. Now we need selectables for the UI
setPossibleLocales is IMO the wrong approach. It's not a library task to restrict the languages offered. - Sources provide packages, and as they scan a package offering support for a certain language, they provide a corresponding language resolvable. - When Sources are fed into the Pool, the language resolvables go there too. So a language resolvable is available, as long as there are Sources providing packages offering support, Thus the Selectables built from the Pools language resolvables are what formerly the Y2PM::languageManager() provided. So I'd like to drop setPossibleLocales, as it's not a zypp task. And getAvailableLocales as it would not be more than a Pool query.
Well, all the means are implemented. Just rearrange them as appropriate ;-)
But there should be only a single resolvable per language IMO. Otherwise it will get very confusing after a while - which languages are the same and which are not? Which resolvable should be marked for installation and which not? ...
Open point: Fallback locales. If the user at the UI selects 'de_DE', we won't get the pure 'de' packages, in case 'de_DE' packages are not available. Maybe 'de_DE' could recommend 'de', so the solver adds this automatically? But then of course, one get's both packages 'de_DE' and 'de' if both are available.
Fallback locales currently solved by injecting a recommends. [schubi] Please close this, if the solver testcases are Ok. Otherwise we have to look for a different solution.
Looks good. In testcases AND UI