Bug 153583

Summary:	[zypp] UI should intform backend about possible locales to choose from
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Klaus Kämpf <kkaempf>
Component:	libzypp	Assignee:	Stefan Schubert <schubi>
Status:	RESOLVED FIXED	QA Contact:	Klaus Kämpf <kkaempf>
Severity:	Major
Priority:	P5 - None	CC:	mvidner
Version:	Beta 5
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Klaus Kämpf 2006-02-26 17:01:28 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

Comment 1 Martin Vidner 2006-02-27 07:40:34 UTC

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.

Comment 2 Klaus Kämpf 2006-02-27 08:42:21 UTC

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 ?

Comment 3 Klaus Kämpf 2006-02-27 17:11:25 UTC

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

Comment 4 Klaus Kämpf 2006-03-03 13:17:00 UTC

The 'Language' kind resolvables also provide a summary with a user-readable language name now.

Now we need selectables for the UI

Comment 5 Michael Andres 2006-03-04 00:01:40 UTC

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.

Comment 6 Klaus Kämpf 2006-03-04 07:15:06 UTC

Well, all the means are implemented. Just rearrange them as appropriate ;-)

Comment 7 Stanislav Visnovsky 2006-03-06 08:04:07 UTC

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? ...

Comment 8 Michael Andres 2006-03-28 11:56:50 UTC

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.

Comment 9 Michael Andres 2006-03-29 21:17:35 UTC

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.

Comment 10 Stefan Schubert 2006-03-30 09:20:44 UTC

Looks good. In testcases AND UI