[karmic] Regression from 9.04 in getting fully translated Ubuntu installation

[Timo Jyrinki]

Because of moving a lot of translations and spell-checking functionality from language-support-xxx packages to language-selector, users currently installing Ubuntu 9.10 are getting inferior experience compared with 9.04. The installer does not anymore install many translations, help files or in some cases spell-checkers. Launching language-selector manually after installation works as it should, but I assume only a minority of ordinary users will manually open the utility before getting a bad experience.

I also argue that any notification that would be displayed (currently it seems not, tested on daily 20090921 image in virtualbox) will not get the wanted "click me" effect for enough users, so only a truly automatic way would be needed to match Ubuntu 9.04. It should also be error-proof, so it's not just a one-time tryout after installation which would fail in case of no Internet connectivity etc.

Specifically in case of Finnish, because of how bug #409764 was handled (dependency removed from language-support-writing-fi, moved to manual checking in language-selector), Finnish users of 9.10 are currently missing out the most important part of spell-checking - the one in OpenOffice.org. Also missing is Firefox spell-checking, in addition to the documentation etc. common to all languages.

My completely-idea-level proposal (without full knowledge of possible discussions/plans behind this move in 9.10) would be:
a) Installer would co-operate with language-selector to install everything during installation time, if Internet connection happens to be enabled (something like language-selector --fix-missing)
b) After installation, update-manager (?) would make certain the whole language support is downloaded together with first updates succesfully (one time, but so that it ends in non-error)

In theory I like how language-selector is used to keep sure of proper language support, but IMHO proper co-operation between installer and update-manager (just one candidate) plus language-selector is needed.

So the question also is - against which packages this bug should be filed. Language-selector could need some new functionality, but maybe it's all there already ready to be used by other applications. Ubiquity? Update-manager?

[Arne Goetje (arnegoetje)]

I'm currently working on a command line tool to be run by other applications, which returns the list of missing packages based on a given language code or all languages which are already installed as language-packs on the system.

The original plan was to change the packages, like openoffice.org-core and others to run this script during postinst and display the notification message when something is returned. The user will still need to launch language-selector to install the missing packages.

I hope, that for 10.04 we can integrate this functionality into the installer and update-manager (at least) directly, so that they can dynamically adjust the dependencies during evaluation what to install.
As you know already, this only works if an Internet connection is available. That would need to be solved, too...
I guess this is something for UDS Lucid.

[Arne Goetje (arnegoetje)]

in my branch: lp:~arnegoetje/language-selector/language-selector-karmic

[Colin Watson (cjwatson)]

Let's just integrate this into the installer for 9.10 - it's a regression fix. I don't know about update-manager - it would be a good idea to grab Michael Vogt and ask him about this if you haven't already.

I'm a little concerned about displaying a notification in postinsts as it seems that it would require some care to avoid continually spamming people with notifications in the event that they've explicitly decided not to install some particular piece of language support.

[Martin Pitt (pitti)]

Note that there is a related bug for upgrades: bug 439296

[Jimhu (huyiwei)]

"Installer would co-operate with language-selector to install everything during installation time, if Internet connection happens to be enabled (something like language-selector --fix-missing)"

I think it will be better if we can select which software source the installer will use.

You see, there are many Chinese user complain that their installations freeze at approximate 70% unless they unplug their internet wires. These users have working internet connections, but the download speed is too slow that the whole download job will not finish in hours since they can't decide where to download.

So, i think if you guys are working on this stuff, why not let users decide which software source they want to use.

[Colin Watson (cjwatson)]

Note that fixing this will affect bug 437368.

Jimhu: please don't jump into entirely unrelated bug reports with problems. This really has nothing to do with this bug, which is strictly about which packages are selected for installation, not where those packages are acquired from.

[Olivier Hervieu (ohe)]

Hi, in ubuntu 9.10 beta1, installation in french, i have some translation problems.
See attachement (english messages does not have to appear).

[Launchpad Janitor (janitor)]

This bug was fixed in the package pkgsel - 0.25ubuntu3

---------------
pkgsel (0.25ubuntu3) karmic; urgency=low

  * Use check-language-support if available to select language support
    packages (LP: #434173).

 -- Colin Watson <email address hidden> Wed, 14 Oct 2009 22:38:12 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.0.0

---------------
ubiquity (2.0.0) karmic; urgency=low

  [ Colin Watson ]
  * Bump to a stable version number series for Ubuntu 9.10.

    The main reason for the version bump was because we incorporated
    oem-config and needed to jump past its version numbers, but really
    Ubiquity 2.0.0 is quite different from Ubiquity 1.0.0 despite most of
    the changes being gradual and incremental. 3.5 years and nearly 5000
    lines of changelog entries later, we have several active developers,
    lots more translations, apport integration, a new partitioner,
    migration-assistant, automation, Mythbuntu and noninteractive frontends,
    Wubi, reinstallation without reformatting, a new timezone map,
    accessibility, many UI improvements, a slideshow, plugin support, and
    much more. Here's to version 3!

  * Install kernel headers to match the kernel (LP: #413135).
  * Recommend dmraid to ensure consistent behaviour across Ubuntu flavours
    (it was already present on the Ubuntu desktop CD, but e.g. not on
    Kubuntu).
  * If dmraid devices are active, then create
    /var/lib/disk-detect/activate_dmraid so that partman will exclude slave
    devices, and ensure that dmraid is installed in the target (LP: #90235).
  * Use check-language-support if available to select language support
    packages (LP: #434173).
  * Update translations from Launchpad.
  * Automatic update of included source packages: base-installer
    1.102ubuntu2, hw-detect 1.72ubuntu5.

  [ Jonathan Riddell ]
  * ubi-intro.py: detect kubuntu-netbook-intro.txt if it exists and use
    that as warning for Kubuntu Netbook Edition

 -- Colin Watson <email address hidden> Wed, 14 Oct 2009 23:57:40 +0100

[Colin Watson (cjwatson)]

Michael, is there anything we can do about the update-manager element of this for 9.10, or possibly in an SRU?

[Michael Vogt (mvo)]

I'm not entirely sure what the best course of action is here for update-manager in the release-upgrade context.

When update-manager runs on jaunty it will not have check-language-support available. So it either needs to embed a copy of it or run it after the upgrade has finished. This would add additional step (something I dislike) or make it part of the cleanup process (where it does not belong).

Additionally in the context of upgrades we do not want to add stuff during the upgrade that the user may have refused explicitely (e.g. because the download size for some of the help files is too big or because he does not need it). That means that u-m needs to run a "check-language-support" before the upgrade to see what is missing now and after the upgrade to see whats missing then and just install the new dependencies. If the list of the new/changed dependencies is small, we could ship that instead of a a full copy of the check-language-support code.

[Michael Vogt (mvo)]

I just looked at the code and it seems like the release-upgrader needs to know what the "pkg_depends" file would look like on jaunty (there it does not exist and its done via metapackages). With that it could do the compare relatively easily.

[Michael Vogt (mvo)]

Hm, and the code in l-s that deal with zh_* via code. But if that is no change compared to the jaunty state it could stay.

[Michael Vogt (mvo)]

I just talked to Arne about it and there are a couple of issues here:

1. langauge-support-extra-$lang is gone, so we either need to transition its dependencies form automatic to manual or ignore that and they will be removed as no-longer-used-automatic-dependencies
2. language-support-translations is gone too, but the dependencies are set to manual on upgrade via a quirks handler
3. the previous dependencies of language-support-translations are now managed via pkg_depends and u-m should be deal with them as if it was a meta-package with recommends. i.e.
 a) install them as manual dependencies
 b) only install new ones (and not re-add previously deselected)
 c) do not fail if they can not be installed

[Arne Goetje (arnegoetje)]

Attached are the pkg-depends from Jaunty for the language-support-translation metapackages.

The zh- metapackages have been split into zh-hans (Simplified Chinese) and zh-hant (Traditional Chinese). The zh metapackages now depend on the zh-hans and zh-hant metapackages and are only needed for upgrading.

[Michael Vogt (mvo)]

A alternative solution is to just make update-manager check the situation on upgrade and drop a upgrade note that will appear on first boot if some language-support is incomplete. This has the advantage that the user will have fine control via language-selector and that check-language-support is available and there is no need to embed it. It also means that its generic enough to work for hardy->lucid next cycle too.

[David Planella (dpm)]

Hi Timo,

I believe this bug has now been fixed.

I understand that the expected behaviour you are mentioning in a), where the installer and language-selector cooperate to install all language-dependant packages has been implemented. As per b), I'm not quite sure I can follow it, so if this is not yet implemented as you were describing it, may I ask you to expand a bit on that?

Other issues mentioned in the report are being handled separately as bug 527623 and bug 441321.

If you believe there are still remaining bits, please feel free to reopen.

Thanks!

[Timo Jyrinki (timo-jyrinki)]

It's indeed fixed as far as the regression is concerned.

The b) part is that full language support should be downloaded automatically after the installation similarly to automatic downloading of language support during installation, if network connection is available. Currently it is suggested by a dialog the user might see, but I do think that the full (selected) translation support should be installed as automatically as possible once in the case of a fresh install, whether it is during the installation or after the installation. Therefore the update-manager was a logical place to consider a hook - if updates are being downloaded, the first batch of updates could also include whatever is missing from the language support that was selected in the installation.

[David Planella (dpm)]

El dc 07 de 04 de 2010 a les 10:06 +0000, en/na Timo Jyrinki va
escriure:
> It's indeed fixed as far as the regression is concerned.
>
> The b) part is that full language support should be downloaded
> automatically after the installation similarly to automatic downloading
> of language support during installation, if network connection is
> available. Currently it is suggested by a dialog the user might see, but
> I do think that the full (selected) translation support should be
> installed as automatically as possible once in the case of a fresh
> install, whether it is during the installation or after the
> installation. Therefore the update-manager was a logical place to
> consider a hook - if updates are being downloaded, the first batch of
> updates could also include whatever is missing from the language support
> that was selected in the installation.
>

Ah, I get you now, thanks for the clarification.

I think these are separate issues, so do you think you could file a
separate bug for your enhancement proposal? I'd suggest filing it
against update-manager and perhaps opening tasks for language-selector
and ubuntu-translations.

[Evan (ev)]

Please do not reopen this bug. If you have an issue with getting a fully translated Ubuntu install, open a new bug.

[Rolf Leggewie (r0lf)]

anything left to be done in this ticket for update-manager? It seems to be specifically aimed at karmic which is EOL.

[Timo Jyrinki (timo-jyrinki)]

Regarding the original description everything and more has been done in language-selector, update-manager and ubiquity. There could be some more ideas for enhancement, but they are worth new bugs.