Internationalisation of the Debian distribution also involves the internationalisation and translation of the tools developed within the distribution itself. This includes the translation of the installation system (d-i), of the package management system tools (dpkg, dselect, apt, aptitude), of desktop menu management (menu) and of other Debian tools such as debconf.
Without proper internationalisation or translation of these tools, the majority of current and potential users will not be able to use or manage the Debian GNU/Linux operating system effectively.
The following sections describe the efforts in internationalisation and in the translation of different parts of the Debian GNU/Linux distribution within the Debian project itself
Debconf translation covers the translation of all interactions with the system administrator while installing packages (or installing the entire system).
The Developer's reference recommends using the debconf protocol for user interaction. This presents information in a standardised way, easier for the user to follow and understand, and also allows more effective localisation of user interaction. Allowing debconf templates to be translatable is also a recommended practice.
This requirement could even become mandatory in the future. This was mentioned for Etch but unfortunately no-one followed through, by proposing the required changes to the policy for this to take place. Debconf, untranslated, is a bottleneck between the users and your software. Translate it, and it's an access conduit.
Debconf translations involve the po-debconf package which has now become a standard in Debian. Even though not mandated by the policy, all packages using debconf for user interaction should use po-debconf. It automates a number of the repetitive but essential tasks, and ensures that translators receive update notices for your templates. This is best practice in the field, ensuring a much higher translation rate.
The details of po-debconf are well covered in its man page (po-debconf(7)). In short, strings (Description, Choices and Default fields) should be prepended with the underscore character in the debconf templates file. If you do so, they will be included automatically in the list of translatable material.
The debconf-updatepo program gathers all the translatable material in a Portable Object Template (POT) file located under debian/po in the package build tree. This templates file is then used as a reference by translators to create a Portable Object file for their languages, using the language ISO 639 code.
Users will often see a series of several debconf screens in a row. A consistent style in both writing and presentation considerably improves the perception of professionalism in the overall Debian distribution.
Unfortunately, the original English strings very often lack this consistency, and despite some efforts in the Developer's Reference to give maintainers advice about writing style for debconf templates, the manner of addressing users often varies wildly:
use of the first person;
use or not of interrogative form for input-style templates;
repeated interrogative form in long and short description of templates;
varying enumeration styles;
use of specific references to some of the debconf interface-specific widgets or behaviour (talking about "previous" or "next" screens, assuming that boolean templates use Yes/No style questions, etc.).
In general, maintainers should follow translators' advice when they suggest improvements to original templates.
The French team, and more specifically Thomas Huriaux, has setup a dedicated page which automatically tracks down the most common "errors" with regards to this recommendation.
A great deal of user interaction in debconf templates involves similar questions or input, such as web server configuration for packages that provide web services, database interactions for RDBMS-related packages or packages that use databases, basic identification, etc.
To avoid such repetition and the wasted time associated with it, packages aimed at providing common methods, as well as common debconf templates for such use have recently appeared in the Debian distribution. The dbconfig-common package is one of them.
Maintainers are encouraged to use these packages, and to help improve them for better quality and efficiency. The use of the debconf register commands is also encouraged in some cases, when a package needs to use strings or templates provided by another package.
The part of this paper which deals with i18n/l10n of Debian specific programs(see Section 2.2) introduces the concept of "localisation assistants".
As the maintenance of debconf translations is usually very simple, this paper does not enforce the use of localisation assistants, except in the case of packages with a high number of templates and/or packages listed a top priority packages for translators (packages which belong to the Debian Installer "levels" packages, or very popular packages).
However, in any situation where the maintenance of debconf translations becomes a hassle for them, package maintainers are encouraged to cooperate with a localisation assistant. The debian-i18n mailing list is the entry point that should be used to "recruit" localisation assistants.
Although everyone can access debconf translation material by downloading each package source and looking in debian/po, translators are encouraged to use links from the translation statistics pages.
Although debconf templates are fairly small, there are over 695 individual debconf templates, a fairly large and repetitive task for translators. The number of Debian packages with translatable material for debconf is pretty important. As of this writing these 695 packages with translatable debconf material add up to about 10000 strings to translate.
Recent changes to the translation statistics pages now allow sorting packages by their popularity, using data from the popularity-contest package. This was achieved to avoid translators spending their effective time on rarely-used packages, and to ensure commonly-used packages get translated first.
Statistics for debconf translations are gathered on the Debian l10n status pages and are separated from the translation statistics for individual programs. These pages also give access to the translation material collected by the statistics robot operated by the Debian i18n team.
Translation usually involves copying the templates.pot file to <code>.po (where code is the language code it is being translated to), filling in this file's header with appropriate information, then using a Portable object editing tool (or any text editor) to enter the translations for all the strings.
Translators can test the debconf PO files by using the podebconf-display-po tool from the po-debconf package. They will need to install this package on their system.
A locale for the tested language must be built on the system (which can be achieved by "dpkg-reconfigure locales") and the LC_MESSAGES variable should be set to this locale.
It is recommended to test the debconf templates by using the debconf dialog interface in a 80x25 screen.
podebconf-display-po has a few quirks, especially when some strings are shared among several templates, so it should not be relied on blindly. Despite this, it has already proven extremely helpful in detecting formatting issues.
Translations need a consistent writing style, just as the original strings do, to communicate effectively. This information, and the way it is presented, also functions as the public face of that application or document, and of the overall project.
While it is true that, as yet, the original English strings in many packages may lack this professional consistency, translators can greatly help package maintainers a great deal in improving accuracy and style. They can report syntax and style errors as bug reports against the relevant packages. Ultimately, this partnership between package maintainers and translators not only produces an application accessible by many more people, but also a higher overall quality of presentation.
Translators should aim for consistency in their own translation work. Even if the original strings do not follow writing-style recommendations, translators should adapt their translation to be consistent in their language, to create a high-quality translation as an achievement in its own right.
Translation teams, and the QA work they do, have indeed a great role to play in this overall improvement of presentation consistency. They are capable not only of processing information for translation, but also of reviewing it as information. Through this additional review process, the quality of information presentation in debconf templates should continue to improve.
Translators should send debconf translation updates to maintainers via the Bug Tracking System, even when the update is requested by a maintainer using an automated tool to call for updates. Such bug reports should use the "l10n" and "patch" tags, and severity "wishlist"
They should be filed against the source package rather than against a binary package.
The use of the reportbug utility is recommended.
A standardised bug title is recommended: "<package>: [intl:<code>] <Language> debconf templates translation", where <package> is the source package name, <code> the language ISO code and <Language> is the language name in English.
Here's an example of reporting the French translation of the geneweb package. Of course, in the example below, geneweb should be replaced by the appropriate package name:
bubulle@mykerinos:~/tmp> reportbug geneweb *** Welcome to reportbug. Use ? for help at prompts. *** Using 'Christian Perrier <email@example.com>' as your from address. Detected character set: UTF-8 Please change your locale if this is incorrect. Getting status for geneweb... Checking for newer versions at packages.debian.org... Will send report to Debian (per lsb_release). Querying Debian BTS for reports on geneweb (source)... 14 bug reports found: (snip all bug reports for geneweb) (1-14/14) Is the bug you found listed above [y|N|m|r|q|s|f|?]? n Maintainer for geneweb is 'Christian Perrier <firstname.lastname@example.org>'. Looking up dependencies of geneweb... *** The following debconf settings were detected: geneweb/run_mode: Always on geneweb/remainingdir: * geneweb/remove_databases: false geneweb/port: 2317 * geneweb/lang: French Include these settings in your report [Y|n|q|?]? n Please briefly describe your problem (you can elaborate in a moment; an empty response will stop reportbug). This should be a concise summary of what is wrong with the package, for example, "fails to send email" or "does not start with -q option specified." > [INTL:fr] French debconf templates translation Rewriting subject to 'geneweb: [INTL:fr] French debconf templates translation' Enter any additional addresses this report should be sent to; press ENTER after each address. Press ENTER on a blank line to continue. > How would you rate the severity of this problem or report? 1 critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.) 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. 5 does-not-build a bug that stops the package from being built from source. (This is a 'virtual severity'.) 6 normal a bug that does not undermine the usability of the whole package; for example, a problem with a particular option or menu item. 7 minor things like spelling mistakes and other minor cosmetic errors that do not affect the core functionality of the package. 8 wishlist suggestions and requests for new features. Please select a severity level: [normal] 8 Do any of the following apply to this report? 1 l10n This bug reports a localization/internationalization issue. 2 patch You are including a patch to fix this problem. 3 experimental This bug only applies to a package in the experimental branch of Debian. 4 none Please select tags: (one at a time) [none] 1 - selected: l10n Please select tags: (one at a time) [done] 2 - selected: l10n patch Please select tags: (one at a time) [done] (snip editor being spawned) Report will be sent to "Debian Bug Tracking System" <email@example.com> Submit this report on geneweb (e to edit) [Y|n|a|c|e|i|l|m|p|q|?]? a Choose a file to attach: /home/bubulle/tmp/fr.po Report will be sent to "Debian Bug Tracking System" <firstname.lastname@example.org> Attachments: /home/bubulle/tmp/fr.po Submit this report on geneweb (e to edit) [Y|n|a|c|e|i|l|m|p|q|?]? y
Another translation project is the translation of the descriptions of the software packages offerred for the Debian GNU/Linux OS. This project is named the Debian Description Translation Project (DDTP).
Each package shipped in Debian GNU/Linux is provided with two descriptions: a short description (less than 80 characters) and a long one (of variable length). The first one describes briefly what the package does and the second one describes its main functionalities, characteristics, differences with other software, etc. This information is vital for users who are looking for a given functionality within the (huge) quantity of software provided in the Debian distribution. The package management tools include interfaces to do word (or regular expression) searches through these descriptions.
However, the fact that all these descriptions are only available in the English language makes it difficult for users that have already installed the system to look for new software they might want. Users not fluent in English might not be capable to define their needs in a foreign language to look for the specific software they are looking for.
The description translation project started in order to solve this problem for end users. This project was started initially by two different work groups in the year 2002, resulting in two different management systems (one based on e-mail and another based on a web application. The framework was based on Perl scripts that collected descriptions and provided an e-mail interface for translators (translators could request new translation through email and submit them using the same interface). All translations are stored in a simple file with a database holding the status of the translation (new, needs to be reviewed, out of date, etc.). Most notably, the framework did not use PO files for translations which got it many objections from some translation teams.
The translations from the web based interface one of these systems have later been merged on with the other one. The project was used by different translation teams. When Debian systems were compromised in November 2003 the main framework was disconnected pending a review of the source code.
The Brazilian team (Otavio Salvador) later developed patches for apt to support the use of the translated descriptions in it. This patch (apt-ddtp) was ported to the 0.6 code base, with the help of some other developers, including Michael Vogt. Later, in April 2005, an Alioth project was started and the original source code of the translation framework was moved to a SVN repository.
As of this writing the DDTP project does not have an interface to submit translations. The translations already done for descriptions can be downloaded from http://ddtp.debian.org/, but they are not being updated.
This work, however, has been reused in Ubuntu. Currently, the Ubuntu package descriptions are imported into Ubuntu's translation framework: Rosetta using the po/pot extraction/assemble tools developed by Michael Vogt, and available at email@example.com/apt-ddtp-tools--main--0. The tools converted the Packages file to a pot file that is then imported into Rosetta. Rosetta then generates the PO files from the translations that can be downloaded and converted into a Translations-$lang file that apt-ddtp understands.
This web application was developed by members of the Spanish translation team and available at http://www.laespiral.org/