When KDE or gnome apps get installed, the corresponding language-packs should be pulled automatically

I guess this is by design - if you install Ubuntu you won't need KDE language support. You will get that when you install Kubuntu. Or when you install it manually.

No the problem appears if the user installs a kde app, lets kturtle. There is no way of installing the language support for this app.

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.

Since you are not talking about the default setup , It is not a papercut.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

Don't worry though, This bug has been marked as "invalid" ONLY in the papercuts project.

Moving to gnome-app-install for lack of a better place. This is definitely not a bug in ubiquity. Given size constraints, this should not be done at install time.

Uh... tricky problem.

Maybe language-selector should have an option for installing only KDE, only GNOME or both language packs.

Adi Roiban wrote:
> Uh... tricky problem.
>
> Maybe language-selector should have an option for installing only KDE,
> only GNOME or both language packs.

No, it's handled automatically. KDe language packs are installed when
kdelibs5-data is installed on the system. As all KDE apps should depend
on this library, running language-selector manually after you installed
the KDE app should pull the correct language-packs.
Similar is true for Gnome apps, which depend on libgnome2-common.

The missing functionality here is automatic dependency handling in
apt/synaptic/software-center. This is planned for Lucid as this issue is
a bit complex.

The current shortcomings have been mentioned in the release notes.

language-selector includes a tool and a python class CheckLanguageSupport, which when called with the to-be-installed packages as 'packages' argument returns a list of corresponding, but not yet installed translation and writing aids packages.
Now it's up to the package managing software to include this function call. However, this has been postponed for now.

Setting priority to Wishlist, since this is a feature request.

Arne, do I understand it correctly that the functionality already exists in language-selector and any applications which want to use it simply have to implement it?

If so, would it not be better to mark the language-selector task as Fix Released and write separate bugs for Synaptic and Software Center to use this functionality, perhaps in Maverick?

I'm raising the Ubuntu Translations task importance to Medium, as this basically means that if I install a KDE application from the main repository in my GNOME desktop (or the other way round), the application will not be translated unless the corresponding KDE language pack is installed, which most users won't know how to do. Or know it exists at all, in fact.

@David Planella: I agree with your assessment of the usability of the current situation: I had this exact experience and had to tinker & google a bit to find the solution (opening up Landuage Selector)...

Following the discussion with ArneGoetje and mvo on IRC, the idea is to make the CheckLanguageSupport call part of aptdaemon, but not apt-get itself to avoid major slowdown, and not on the client side to avoid code duplication.
A plugin mechanism would be ideal, or a re-thinking of the way we do the langpacks.
I'm adding a aptdaemon task.

Currently aptdaemon is not the correct place, since it doens't allow any dependency handling. The user should be informered before if translations will be installed additional, since this could be a quite large download.

I currently working in a separate branch to add dependency handling/confirmation to aptdaemon (taking the already queued changes/transactions into account). Before this isn't merged I would recommend to add this to software-center.

I don't see a problem to add this Ubuntu specific feature to aptdaemon.

I added a plugin system to aptdaemon which allows to e.g. install additional software. Keep in mind that those hooks wil be called on every install/upgrade/remove operation. So they should be quiet fast. See README.plugins for more details.

What's the current status of this discussion?

From the last comment I understand that aptdaemon would be the right place to do this, but I could not find any README.plugins file in the code at http://bazaar.launchpad.net/~aptdaemon-developers/aptdaemon/main/files

I moved the documentation to sphinx:

http://packages.python.org/aptdaemon/plugins.html

If you provide the code to detect the required language packages I could turn it into an aptdaemon plugin.

Sebastian already pointed out that integrating this feature as an aptdaemon plugin would be the best architecture. This now came up as part of https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-clean-up-language-support, so I'll assign this as an oneiric task to me for now. I'll discuss this in further detail with Sebastian soon.

I'll reopen the software-center task if it turns out that we'll actually need a s-c change for this. Preferably we could do all this in aptdaemon so that translations will also work correctly when packages are installed through other applications using aptdaemon.

Unfortunately I didn't find time to get to this for oneiric, moving to P series. This is a nice "fit&finish" bug for the LTS.

So we could only check for newly installed packages. This operation takes an half second on my system (reusing the opened apt cache from aptdaemon)

installs = transaction.packages[PKGS_INSTALL] + transaction.depends[PKGS_INSTALL]
cls = CheckLanguageSupport()
cls.getMissingPackages(packages=installs)

I also like your suggestion to additionally integrate this into update-manager.

Some time ago I wrote a small guide on how to write aptdaemon plugins:

http://packages.python.org/aptdaemon/plugins.html

Status changed to 'Confirmed' because the bug affects multiple users.

I discussed that with Michael again, and writing this as an aptdaemon plugin is a lot more elegant than modifying the core aptdaemon code, so moving this to language-selector.

As for performance, I now rewrote the check-language-support logic from scratch, as the l-s code was really horrible, slow, and hard to maintain. The replacement is much smaller, (IMHO) easy to read and understand, has full test coverage, and is fast.

I added a performance test to the test suite which does a full check of all missing lang support packs for all installed packages for all installed locales, and it takes a mere 8 ms on my system (under the condition that we have an initialized apt.Cache() object, which is given in an aptdaemon plugin). I think this is a negligible overhead and well worth spending.

I'm dropping the other unrelated tasks here to avoid further bug spam.

This bug was fixed in the package language-selector - 0.62

---------------
language-selector (0.62) precise; urgency=low

  [ Colin Watson ]
  * data/pkg_depends:
    - Replace ttf-arphic-uming with fonts-arphic-uming.

  [ Martin Pitt ]
  * data/pkg_depends: Drop usage of '|'. It unnecessarily complicates the
    logic, does not add any expressiveness, and was only used once anyway.
  * data/pkg_depends: Add generic language-pack- pattern (without a trigger
    package), so that we do not need to special-case it in the code.
  * Add language_support_pkgs.py and tests/test_language_support_pkgs.py:
    Complete rewrite of the check-language-support and
    LanguageSelector/CheckLanguageSupport.py functionality. The old code was
    terrible and hard to maintain, the new one now makes it very easy to
    integrate into installers or an aptdaemon plugin and does not have any
    dependencies to any of the old language-selector code (which will
    eventually be dropped).
  * check-language-support: Rewrite using language_support_pkgs. CLI API stays
    the same.
  * setup.py, debian/language-selector-common.install: Install
    language_support_pkgs.py.
  * language_support_pkgs.py: Add apt_cache_add_language_packs() function
    which uses LanguageSupport to mark all corresponding language support
    packages for installation for an apt.Cache() object with to-be-installed
    packages. This is a suitable function to use as an aptdaemon plugin.
  * setup.py, debian/rules: Move to python-setuptools, as we are going to need
    it for registering an aptdaemon plugin through "entry_points". Add
    python-setuptools build dependency.
  * setup.py, debian/language-selector-common.install: Register
    apt_cache_add_language_packs as aptdaemon "modify_cache_after" plugin and
    install this package's egg-info. With this, installing a new package
    through aptdaemon (i. e. software-center or any other desktop
    integration) will automatically install the corresponding language packs
    and support packages as well. (LP: #396414)
 -- Martin Pitt <email address hidden> Thu, 26 Jan 2012 16:20:53 +0100