Reviewer feedback (MattZimmerman):

• Rosetta interaction with kde-i18n needs to be more completely specified, and possibly split into a separate spec. Kiko and I discussed this with Carlos
• The scheme for merging the PO files into application tarballs doesn't seem necessary; we should be able to import the POT and PO files separately (according to Carlos)

Language Pack Roadmap

Status

• Created: Date(2005-04-23T10:02:01Z) by MattZimmermanBR

• Priority: HighPriorityBR

• People: MartinPittLead, CarlosPerelloMarinSecondBR

• Contributors: MattZimmermanBR

• Interested: JonathanRiddell, DafyddHarries, SebastienBacherBR

• Status: MattZimmermanQueue, BrainDump, DistroSpecificationBR

• Branch: BR

• Malone Bug: BR

• Packages: BR

• Depends: BR

• UduSessions: 3(0)BR

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 and support packages into -other, -kde, -gnome.

• language-support-kde-lang should depend on kde-i18n-lang.

• Since POT files are shipped in the application debs, but PO files are shipped in kde-i18n, we need to manually merge the PO files into the application tarballs before importing them into Rosetta. This needs to be done in a script on rookery where all the tarballs are hosted. The script would be called in a daily cron job right before the Rosetta import. This is a rather nasty hack, though; maybe Rosetta can be extended to support such situations in a clean way in the future.

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.

MartinPitt: eventually desktop/server files should just use gettext() to translate entries since application's *.mo files already ship the translations. The above solution does not really fit into the original idea of language packs, but is a solution we can implement for Breezy.

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 [http://translate.sourceforge.net/ 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

UDU BOF Agenda

UDU Pre-Work

Things to think about in the future

• gok also ships translatable stuff in XML files (special case)