RFC: On-demand package installation API in kdelibs

John Layt johnlayt at googlemail.com
Thu Jul 29 01:21:22 BST 2010

On Wednesday 28 July 2010 20:10:12 Lubos Lunak wrote:
> On Wednesday 28 of
July 2010, John Layt wrote:
> > There's a long-standing wish in bko to allow
users to install
> > KDE translations from the locale kcm, i.e. a big button
in the Languages
> > tab saying "Install More Translations".  I'm currently
re-writing the kcm
> > and was just about to ask around on opinions about
> > 
> > The Spell Checker kcm
> > could also do with an "Install More
Dictionaries" button.
> > 
> > For this purpose
> > any such api would need
to be able to queried for a list of language
> > codes for available
translations or dictionaries to show the user, and
> > then take a given
language code and try to install the translation or
> > dictionary.
>  I
haven't thought of adding calls for querying what capabilities are
available, my first idea here would be to simply try to do
> e.g.
'installCapability( "kde-translations-cz" )'. That should take care
> of
"Install More Translations" (if that means "more for this language").
What would you need the querying for? Would it be for "more translations"
== "more languages"? Querying could be added, so that you could
> do
'queryCapability( "kde-translation" )' and it'd
> give "kde-translation-cz",
"kde-translation-de" etc., but I expect you
> might have a small problem
with getting "Czech", "German" out of that. You
> generally cannot get all
info about a package without installing it first,
> so all this would need
to be stuffed into packages' capabilities (e.g.
> rpm's 'provides'). What
would be your requirements here exactly?

Sorry, I'll use "Languages"
rather than "Translations" here.  I've just been messing with the kcm
labelling to see if Translations would make more sense to users, they
apparently don't understand what we mean by Languages.

I specifically mean
the packages named in openSUSE like "kde4-l10n-en_GB" that provide the KDE
.mo translation files, docbooks, etc for each language.  The ISO language
code on the end would be what I would want to use in the API, each distro
should know how to convert that into their own package name format, and we
already know how to convert it into a localised name using
KLocale::languageCodeToName().  Parsing the language code out of the package
name is probably the simplest way, but I guess the package could provide a
'provides' key of some kind, but that's a distro level implementation

In the Locale KCM in the Languages tab the user can select from a
list of the currently installed KDE languages those languages they want to
be searched for translations in the order of priority.  It's probably not a
common scenario, but if a user wanted to install other languages we
1) enable the Install button only if the api says the facility is
2) list the languages that the api says are available to be
3) return if the install was successful so the kcm knows to add
the language to the installed list

Apps that are outside the core KDE
modules, such as KOffice and ExtraGear, are not included in those
kde4-l10n-* packages, so they could provide a button for "Install
Application Language" in the "Switch Application Language" dialog from the
help menu.  Well, we could do that for all apps anyway, we'd just need a way
of knowing which package to install for which app.

The Spelling
Dictionaries would be a far more common scenario, e.g. for multilingual
users.  We could expose this anywhere you spellcheck.  It's certainly more
user friendly than saying "Run Yast and install aspell-fr"

These could be
special cases in the api, rather than generic calls:

    QStringList availableLanguages(appName)
bool installLanguage(languageCode, appName)

    QStringList availableDictionaries()

If it was a generic installCapability(
"kde-language-fr" ) then we would just be doing lots of parsing of the key
at both ends to obtain the language code and decide what to do.


More information about the kde-core-devel mailing list