Universe is translatable in Launchpad

Registered by David Planella on 2010-04-01

Assess if it's desirable to make all localized applications from universe also translatable in Launchpad, not only those from the main repository. If so, drive the implementation.

Blueprint information

Jono Bacon
David Planella
Needs approval
David Planella
Series goal:
Not started
Milestone target:
Completed by
David Planella on 2011-05-17

Related branches



[dpm] Assesment: First of all, assess if this is desirable/doable:
[dpm] Organize session at UDS. Discuss how language packs would be created for this.
[dpm] Consult Ubuntu Translators on their thoughts about this.
[dpm] Provide a list of how many packages this would affect, to have an idea if there is enough capacity to do this
[dpm] Create a resource for the coordination of this effort. This should be on the Ubuntu wiki

arnegoetje 2010-04-27: My thoughts on this:
 1. we don't want universe 'language-packs' for the following reasons:
  * we have already 700+ language-packs just for 'main' in the archive. Adding another 700+ packages is not something we want to do.
  * we would also need to split them up into categories, like gnome, kde and probably others. Where to draw the line?
  * we don't want to force users to install the translations for all applications (by category) in universe, just because they install one or two applications from universe.
 2. we could use bzr-import and -export and ship the translations in the packages directly, like we do now.
  * who triggers the export of the translations and when?
  * who makes sure the packages get rebuilt and the version number gets increased when translations are exported?
 3. we could establish a separate set of repositories with a stripped down dpkg, just for translations:
  * Pros:
   * we don't pollute the package archive with translation packages
   * we would have multiple repositories, one for each language(code) where users could subscribe to
   * if an application has multiple translation domains, the translation package for the given language would include the .mo files for all those translation domains
  * Cons:
   * someone would need to write a stripped down version of dpkg for managing the translation packages (packages could be simple tarballs, but they need to be managed by a registry on the user's machine). We basically need the same function, that dpkg provides, but without all the overhead necessary for application packages.
   * the package registry would need to be separate from the usual dpkg registry in order to not blow up the package cache


Work Items