LanguagePacksForUniverse

Revision 3 as of 2006-06-22 15:38:29

Clear message

Summary

Universe lacks any kind of Rosetta integration feature so it's difficult to get translations update for it. We need to provide a solution like the one for main or an improved one.

Rationale

Although we don't support Universe, people are interested on applications from Universe and thus, there are people interested on translate them and also in see them fully translated.

This would allow a full distribution translation.

Use cases

  • Peter wants to translate VLC for dapper. He knows it's not supported by Canonical but he really likes that application so he translates it and with next language packs, he gets his translation deployed.
  • Jordi found a bug in the Catalan translation of Galeon, he fixes it and waits for next language pack update to see it fixed for all Catalan users of that application. Galeon is in universe.

Scope

This spec requieres updates in:

  • Rosetta.
  • Depending on the solution choosed, we would need to update apt-get, update-manager, langpackomatic, libc, etc...

Design

We need a system that allows us to distribute translations for any application in Universe. It should fit the following requirements:

  • You would install only translations that you are interested on. No extra languages that are not related to your prefered ones or translations for applications that you don't have installed.
  • You should be notified when a new translation is available so you can get updates, even after release time.
  • The updates must not overwrite any file stored in our system that is handled by dpkg that are not related with language packs.
  • The metadata information to handle translation updates should be as small as possible.
  • The system must not be .po/.mo specific, it should update other files like documentation, .desktop files, firefox/openoffice language packs, and any other translatable resource we could have in our system.
  • We should be able to expand its usage to support our installer. This will allow us to use this solution with our 'main' repository so even if we choose a different approach from what we have in main, we could migrate main for that new solution.
  • The solution should be able to use mirrors to distribute the files so we don't overload launchpad or a single server.
  • The translations should be installed and available just after the application is installed. The user should not be aware that the translations are not part of the binary application, they don't care about it, they just want their application full translated just after its installation.
  • When an application is removed, its translations should be removed too so we don't waste resources.

Implementation

While thinking on this, we found several solutions. All them with their pros and their contras and we are going to document them here to be sure that we have those present if the requirements change:

  • Use exactly the same solution we are using in main. All translations for a group of languages are stored inside a single .deb package with a -base package for the initial distribution release and a -updates package for the monthly updates after release. Also, all translations from the binary packages are stripped so we only ship translations as part of the language packs.
    • Pros:
      • Simple to manage, we have already all the infrastructure there to create/maintain/deploy.
      Contras:
      • The amount of packages in universe is higher than in main and thus the hard drive space needed for this would be higher.
      • You would need to install a lot of translations even if you are interested in just one package from Universe.
      • We would need around 200 new packages (100 for base, 100 for the updates)
  • Same solution as before, but without using -base packages and without striping translations from binary packages.
    • Pros over previous option:
      • The initial language pack will be much more small because will only contain changes done in Ubuntu/Rosetta and the others will be part of the binary packages, so the users will have installed only the translations that they need + all updates for universe translations.
      • We will need “only” around 100 new packages for the -updates packages.
      Contras over previous option:
      • If translators do a good job, the size of the language pack would be directly high and thus we don't get a big win.
      • We would have two different language pack behaviours, main must do the strip to save some disk space for the installation/Live CD.

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

CategorySpec