DebianInstaller

Revision 7 as of 2009-07-25 15:35:12

Clear message

Introduction

The purpose of this page is to provide a deteiled description of the translation lifecycle of the debian-installer package, in order to document the procedure and best practices for translators to follow.

How are the translations handled

The debian-installer translations need to be updated by hand, since they are used before language packs are installed.

Updating them wholesale from Launchpad would put the maintainer in the position of having to decide which of Debian's translations or Launchpad's translations are better each time updated packages are merged from Debian (i.e. at the start of every release cycle, and often more frequently than that).

It is not feasible to take on this workload for more than 50 languages. Also just one side of the merge cannot just be thrown away because:

  • the translation changes done in Debian often constitute important bug fixes in the installer (analogous to c-format bugs, except that Launchpad can't check the substitution format here), so the Debian changes cannot be thrown away;

  • there is no point in updating translations wholesale from Launchpad if the Launchpad changes are gong to be discarded on merge.

In this scenario, it is assumed that the Launchpad translation team forward their changes (if any) to upstream Debian.

Launchpad translations are only incorporated for Ubuntu-specific strings, and the translations from Debian are used for strings which are common.

Recommendations

Translators are advised to contribute translations of installer strings that exist in Debian directly to Debian.

This isn't the same as the usual Launchpad translations workflow where it is possible to have translations in Ubuntu first, but I don't see any other way to do it that doesn't impose a completely unacceptable amount of work and linguistic knowledge on the installer team.

Issues

None of this applies to those strings which are specific to Ubuntu: at the time of writing, these are a small number of strings in cdrom-detect, partman-auto, partman-crypto, partman-target, pkgsel, and user-setup, and all or almost all of the strings in oem-config and ubiquity.

A starting point would be to get a list of these published automatically but such process has not yet been implemented. They can probably be extracted somehow from patches.ubuntu.com.

Branding

There are strings such as «Ubuntu» which are part of a category referred to as "branding", where the string in Debian includes the text "Debian" itself, and clearly needs to have "Ubuntu" substituted.

This turns out to be a vastly more complicated subject than one might hope; the text surrounding the distribution name often needs to change slightly (e.g. "a Debian mirror" vs. "an Ubuntu mirror", or the current change of "de Debian" to "d'Ubuntu" for Catalan).

At the same time, it is generally preferable to stick to the rest of the Debian text for those strings for all the reasons described above, so what is done is to merge all changes from Debian and "rebrand" all the references to Debian according to a set of rules gathered over the years and recorded at the end of https://wiki.ubuntu.com/DistributionDefaultsAndBranding.

This workflow is, according to the maintainer the most optimal at this point, since anything else would be worse (it would leave him in an untenable position when the strings change on both sides of the merge).

Upstream repository

Other

See also MiloCasagrande/DebianInstaller (we should probably merge both pages).

CategoryTranslations