Universe is translatable in Launchpad
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
- Status:
- Complete
- Approver:
- Jono Bacon
- Priority:
- Undefined
- Drafter:
- David Planella
- Direction:
- Needs approval
- Assignee:
- David Planella
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- David Planella
Whiteboard
[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
