KubuntuTranslationsLifecycle

Revision 8 as of 2009-08-05 11:48:33

Clear message

THIS IS CURRENTLY A DRAFT

Introduction

The purpose of this page is to document the lifecycle of translations in Kubuntu since the import from upstream until they are shown to users.

Some quick facts

  • All KDE translations imported from upstream are contained in the kde-l10n-xx packages (one per language)
    • These packages contain:
      • Translations for the applications (PO files)

      • Translations for the applications' .desktop files (as PO files) - in KDE those translations are created separately from the application. For each KDE module, there is a desktop_<modulename>.po file containing all .desktop translations for all applications in the module.

      • The templates (POT files) for all of the above, created on build
      • entry.desktop files - note: what are these?
      • Translations for the documentation
      • Translations for man pages

      • Other translated media (audio, video, transcript scripts, etc.)

    • From the above, only the following will be stripped from the binary packages and imported into Launchpad:
      • Translations for the applications (PO files) and their templates (POT files)
      • Translations for the applications' .desktop files (PO files) and their templates (POT files)
  • On the distro, KDE translations will be installed in the following way:
    • In the KDE language packs: language-pack-kde-xx, one per language

      • Translations for the applications (MO files) at /usr/share/locale-langpack/<langcode>/LC_MESSAGES

      • Translations for the applications' .desktop files (MO files) at /usr/share/locale-langpack/<langcode>/LC_MESSAGES

      • entry.desktop files at at `/usr/share/locale-langpack/<langcode>, copied verbatim from the kde-l10n-xx packages

    • In the kde-l10n-xx packages, one per language

      • These contain the documentation and additional translated media which cannot be imported into Launchpad, and will be 1:1 with upstream. They will be installed at locations such as /usr/share/doc/kde/HTML/<langcode> or /usr/share/locale/<langcode>/LC_SCRIPTS

      • Those languages without upstream translations for these media will have empty packages, but nonetheless they will be installed

How are translations fetched from upstream

Applications, documentation

Desktop files

  • Directly from upstream's SVN, from the stable branch

entries.desktop

  • langpack-o-matic has a script update-kde-tars which grabs the entries.desktop files from all the kde-l10n-xx packages, and generates entries.desktop files for any language-pack-kde-xx which does not have a corresponding kde-l10n-xx
  • These should them be included in language-pack-kde-xx but currently (2009-08-01) is broken

Import workflow for KDE core

  • Upstream:
    • The upstream sources are internationalised with KDE functions for gettext, PO files are kept separate from the source code in SVN
    • All translations (PO files) are shipped in a separate tarball for each language (kde-l10n-xx)
  • Packaging:
    • Those sources are packaged as .deb packages:
    • The source packages generate POT files on build (using extract-message.sh and the Message.sh included in each package.)
    • The kde-l10n-xx sources, containing exclusively translations, are packaged

    • kde-l10n-xx packaging includes downloading the desktop_<package>.pot files for KDE's modules from SVN. It also downloads other desktop files as listed in /usr/lib/kubuntu-desktop-i18n/desktop-template-list

  • Build:
    • The kde-l10n-xx binary packages, do _not_ generate POT files on build
  • Import:
    • The application's POT files are put in the import queue upon upload of the application package to the archive
    • The PO files are put in the import queue upon upload of the kde-l10n-xx package to the archive

The main difference between GNOME/extragear/other and KDE4 core (as far as the import into Launchpad goes) is that the first ones generally have a single template (domain) per source package, whereas the latter have got many templates (domains) per source packages.

  • Issues:
    • In the past some upstream sources (e.g. KTorrent) did not ship with Messages.sh files which had to be added manually, new packagers should watch out for this
    • The kde-l10n packages contain more translated content other than PO files (audio files, pictures, etc.). It should be investigated whether it is worth installing them by default.
    • Quassel and Arora are in main and use Qt's translation system and produce .qm files. As a result, these don't get in language packs at all. Qt translation import is not trivial, since Qt use their own XML-based format, which is supported by gettext (but reportedly always one step behind, which prevents both Kubuntu and upstream from using gettex).
    • kde-l10n-xx do generate desktop_kde-l10n-xx.pot files, these should be ignored (fixes to kubuntu.mk to stop them being generated welcome).

    • The generated .desktop templates are in the form desktop_<sourcepackage>.pot. The source package does not always match the template name used upstream so it needs to be overridden in the debian/rules file.

The kde-l10n packages and language packs

Language variants

  • In Kubuntu, language variants are shipped in the same language pack as the main language code. That is, taking sr and sr@latin as an example, both the sr and the sr@latin translations will be shipped in the language-pack-kde-sr package.

  • In Launchpad variants are not shown in the UI, but are imported and exported transparently.
  • In KDE upstream, the variants can be found in two different places:

The following language variants can be currently found in the KDE stable branch:

  • be@latin
  • ca@valencia
  • sr@latin
  • uz@cyrillic

In order to fetch the variant translations for Kubuntu:

  • Application PO files: the translations in the language@variant subfolder in the upstream tarball should also be imported into Launchpad Translations.

  • Desktop files: the scripts fetching the files for the main language code package (kde-l10n-xx) should look at the SVN location for the variant as well.

  • batl10n is a script that assists Kubuntu packagers with KDE updates. It mostly just walks through all kde-l10n tarballs, merges the packaging in and create ready-to-upload source packages (in the process it can also apply batch changes of course).

  • KDE l10n orphans parser

CategoryTranslations