Language Pack Roadmap
Status
Created: 2005-04-23 by MattZimmerman
Priority: HighPriority
People: MartinPittLead, CarlosPerelloMarinSecond
Contributors: MattZimmerman
Interested: JonathanRiddell, DafyddHarries, SebastienBacher
Status: MattZimmermanQueue, ChristianReisQueue, EditedSpecification, DistroSpecification
Branch:
Malone Bug:
Packages:
Depends:
UduSessions: 3(0)
Introduction
We want to extend the current scope of language packs and Rosetta integration to work with more than just application gettext translations.
Rationale
Currently the language packs contain only translations for desktop applications that use gettext. However, there are many more translatable items in Ubuntu. Our goal is to extract all translatable contents from application packages, import them into Rosetta, and ship them into language packs so that they can be updated after a release.
Scope and Use Cases
- Extract and handle KDE translations for Kubuntu.
Extract and handle translations of OpenOffice.org and Mozilla applications, which do not use gettext, but their own system.
Some translatable files do not use gettext at runtime, but rather contain all translations in a single file, like .desktop and .server files.
Some applications have special file formats involving translations (e. g. gok).
Implementation Plan
Supporting KDE
- Split language packs into -main, -kde, -gnome (not the support packages, though).
Besides language-support-lang, Kubuntu additionally installs kde-i18n-lang.
- Our language selector application automatically determines the set of language packs to install.
Official KDE tarballs don't have the .POT files included and seems like there is no easy way to rebuild them so, after talking with KUbuntu people they will package the translation tarball from CVS instead of the released one so we get also the .pot files. After that it's a matter of adding the KDE special layout as a "needs to be implemented" to the LaunchpadPackagePoAttach spec like we have Python and PHP layouts. This means that all KDE translations will appear as belonging to kde-i18n source package name.
Proposal for .desktop and .server files
pkgstriptranslations will store .desktop and .server files in translation tarballs.
Rosetta will export a file that maps .desktop/.server file names to translation domains.
- langpack-o-matic uses intltool/homebrew script to add new translations to those files.
We create a new package desktop-translations which ships files in parallel directory hierarchies /usr/share/applications-langpack/ and /usr/lib/bonobo/servers-langpack/; those files are preferred over the files in the original directory. It only requires very few changes to lookup files into these additional directories. We just have to make sure that the desktop backend that is responsible for that ignores files whose application is not installed.
desktop-translations can be updated after the release to provide new desktop files.
This solution does not really fit into the original idea of language packs, but is a solution we can implement very quickly and independently from other distributions and upstream. But eventually desktop/server files should just use gettext() to translate entries since application's *.mo files already ship the translations. Therefore we want to propose the extension of the FreeDesktop standard to support an additional field TranslationDomain, so that Gnome, KDE, and other implementations can find the matching .mo file at runtime to get additional translations from it. Note that most upstream packages already use gettext to translate .desktop files at build time.
NOTE: This approach is already being developed: check out AddingGettextSupportToDesktopFiles and LangpacksDesktopfiles
Data Preservation and Migration
No data needs to be preserved when adding to language packs.
Packages Affected
Potentially many affected packages:
- Some packages do not include/produce a POT file (amongst them, most KDE packages).
- Ubuntu-specific strings are usually not contained in POT files.
- We have to fix those packages to produce an up to date POT file at build time.
- We have to find a heuristics to detect packages which need to be fixed:
- We can't compare PO and POT files because it is possible and valid for PO files to be out of date.
- List generation: set of packages whose tarball does not contain a POT file + set of packages whose diff.gz touches translations (this probably catches too much, though).
OpenOffice.org/Firefox:
Package translation tools which converts between gettext, OpenOffice, and Mozilla style translation formats.
Change the packaging of openoffice.org and mozilla-firefox-locale-all to generate POT and PO files at build time, so that those are shipped in the translation tarball and can be imported into Rosetta. There should also be an easy function to pull updated translations from Rosetta (at package development time) so that the next build will contain updated translations.
OpenOffice.org has its own bof about this: OpenOfficeLocalisation
This approach will not allow us to update translations of stable releases, though. They need their own solution and it will be done based on a technical evaluation of current tools. Seems like Firefox translations could be able to be integrated into language packs without too much pain. OpenOffice.org is another history.
- Firefox needs to support per-language startup pages.
mozilla-firefox-locale-all:
- The locale packages need to ship translated default startup pages.
langpack-o-matic:
- In the future, documentation translation will be done with gettext in Rosetta. Thus langpack-o-matic needs to be extended to support disassembling, translating, and reassembling
Needs to generate gnome-doc-lang packages and make them dependencies of language-support-lang.
pkgstriptranslations
- Extract gnome documentation into the translation tarballs.
User Interface Requirements
We need an easy way to configure language support, see LanguageSelector.
Outstanding Issues
Things to think about in the future
gok also ships translatable stuff in XML files (special case)