Deutsche Manpages und Internationalisierung
von Martin Schulze (joey@infodrom.north.de)

Deutsche Dokumentation erleichtert die Verständlichkeit des Systems. Durch Aufhebung der Sprachbarriere steigt die Verbreitung von Linux und Freier Software. Erreicht wird dieses durch zunehmende Internationalisierung von Programmen. Hier kann die Freie-Software-Gemeinschaft ihre Stärken zeigen.

Inhalt

Historie Deutscher Manpages
Organisation im Projekt Deutsche Manpages
Probleme
Installation
Wie sieht so etwas aus?
Mitmachen kann jeder
Verschiedene Kategorien von Texten
Internationalisierung von Programmen
Eincompilierte Texte
Texte übersetzen
Ressourcen

Die anerkannte Sprache im Internet ist Englisch. Daher verwundert es wohl niemanden, dass über das Internet verteilte oder im Internet entwickelte Software prinzipiell auf Englisch gehalten ist. Menüs, Fehlermeldungen, Hilfstexte und Dokumentation sind international formuliert. Sinnvoll ist dies allemal, denn nur so kann sichergestellt werden, dass die Programme auch weltweit benutzt werden können.

Voraussetzung dafür ist jedoch, dass die Anwender Englisch ausreichend gut verstehen. Auf diese Weise werden die Programme zwar verbreitet und vielen Menschen zugänglich gemacht, doch was ist mit denen, die kein oder kaum Englisch sprechen?

Wer vor 20-30 Jahren Englisch gelernt hat, die Sprache seit dem jedoch nie wieder benutzt hat, wird englische Menüs und Hilfstexte kaum verstehen, geschweige denn eine englische Beschreibung. Ähnliches gilt für Kinder und Leute, die vom Schulenglisch nicht viel behalten haben. Viele Menschen empfinden einen Text zudem leichter verständlich, wenn er in ihrer Muttersprache verfasst ist und sie nicht lange über die Bedeutung nachdenken müssen.

Natürlich betrifft dieses Problem nicht nur Deutsche. Ganz im Gegenteil: Länder, in denen Kinder nicht bereits in der Schule gezwungen werden, Englisch zu lernen, sind viel stärker von dieser Problematik betroffen. In Korea und Japan leben zum Beispiel viele Linux-Anwender, die Englisch nur rudimentär verstehen.

Wer sich das Problem nur schlecht vorstellen kann, der möge sich die Dokumentation zum lha-Paket[1] ansehen und versuchen zu verstehen. Sie ist auf Japanisch geschrieben.

Historie Deutscher Manpages

Seit 1993 haben sich mehrere Gruppen unabhängig voneinander zusammengesetzt und angefangen Texte für das Man-System zu übersetzen. Die wohl bekannteste Gruppe ist LunetiX. Im Zuge der Erstellung des erfolgreichen Linux-Anwenderhandbuchs haben die Autoren Man-Texte vieler Anwendungsprogramme ins Deutsche übertragen. Diese Texte sind anschließend nicht nur im Anwenderhandbuch erschienen, sondern wurden ebenfalls frei im Internet zur Verfügung gestellt.

Eine zweite Gruppe befand sich unter den Entwicklern und interessierten Anwendern des Man-Betrachters man-db. Sie haben dessen Dokumentation in mehrere Sprachen übersetzt. Das dritte Team entstand aus den Mitarbeitern des regulären Manpages-Pakets. Dort häuften sich die Anfragen nach einem Paket mit deutschen Texten. Der Verwalter des ursprünglichen Pakets, Andries Brouwer aus Eindhoven, hat schließlich mit man-pages-de begonnen.

Vor drei Jahren wurde das Paket an Martin Schulze übergeben, der es seitdem pflegt. Das Hauptaugenmerk wird auf die im ursprünglichen Manpages-Paket enthaltenen Seiten gelegt. Dieses umfasst hauptsächlich Systemfunktionen und teilweise Funktionen des Linux-Kernels. Seit einiger Zeit werden jedoch auch verstärkt Texte aus Abschnitt 1, also Beschreibungen von Benutzerprogrammen, übersetzt.

Nachgezogen haben auch Teams weiterer Länder. Inzwischen gibt es Manpages ebenfalls auf Spanisch, Französisch, Ungarisch, Italienisch, Finnisch, Japanisch und Koreanisch. Wie die übrige Dokumentation von Linux werden nationale Übersetzungen ebenfalls zentral auf dem wichtigsten Server für Linux-Software[2] gesammelt: metalab.unc.edu (ehemals sunsite.unc.edu). Die Manpages sind inzwischen zu einem Bestandteil des Linux Documentation Project (kurz: LDP) geworden.

Das LDP wurde vor Jahren ins Leben gerufen und enthielt primär die ersten Linux-Bücher: Installation and Getting Started, Network Administration Guide, System Administration Guide etc. In der Linux-Gemeinde fanden diese Bücher großen Anklang. Dadurch wurden Verlage auf sie aufmerksam, und inzwischen sind sie ebenfalls in gedruckter Form zu erwerben.

Diese Bücher sind in einem besonderen Format geschrieben: SGML. Standard Generalized Markup Language (kurz: SGML) ist eine Metasprache zum Erstellen von Dokumentation. Metasprache bedeutet, dass keine konkreten Anweisungen enthalten sind, wie:

   Schriftart SansSerif, 12 Punkt, kursiv

sondern, dass der Text logisch strukturiert ist:

   <Überschrift Anfang>Das ist eine Überschrift<Überschrift Ende>

Das Dokument lässt sich daher aus SGML mit Hilfe verschiedener Programme (sgml2html, sgml2latex, sgml2txt, sgml2lyx, sgml2xml, sgml2rtf) relativ einfach in andere Formate konvertieren. Dadurch ist diese Metasprache besonders gut geeignet für Dokumentation, die in mehreren Formaten angeboten werden soll: z.B. gedruckt als auch auf Webseiten.

Organisation im Projekt Deutsche Manpages

Wie bei vielen Projekten im Internet wird auch bei den Deutschen Manpages verteilt im Netz gearbeitet. Die Mitarbeiter sind gleichberechtigt und können sich ihre Arbeit selbst einteilen. Sofern zusätzliche Koordination notwendig wird, findet diese auf der eigens für dieses Projekte eingerichteten Mailing-Liste statt, auf der sich die Teilnehmer austauschen.

Im Falle des deutschen Projekts werden alle eingeschickten Übersetzungen darüber hinaus Korrektur gelesen. Andreas Braukmann stellt dadurch sicher, dass kein holpriges Deutsch entsteht, und der Sinn nicht versehentlich entstellt wird. Zudem achtet er darauf, dass die Übersetzungen in der richtigen Form eingepflegt{?} werden, so dass die Seiten einheitlich aussehen.

Mitarbeiten kann jeder! Wenn beim Lesen der Seiten Unstimmigkeiten auffallen, sollten sie dem Projekt mitgeteilt werden, damit sie korrigiert werden. Wer ein wenig Freizeit für Linux verwenden möchte und eine nicht übersetzte Seite findet, ist herzlich eingeladen, diesen Missstand zu beheben.

Probleme

Natürlich tauchen auch in diesem Projekt Probleme auf. Wer sich bereits mit computertechnischen Texten befasst hat, kennt das Problem. Einige Begriffe lassen sich nur schlecht oder gar nicht ins Deutsche übersetzen - und falls doch, dann versteht sie niemand mehr. Wenn alle Begriffe komplett eingedeutscht würden, dann hätten diejenigen, die sich bereits seit Jahren mit Computern beschäftigen, starke Verständnisprobleme. Zudem hätten Neueinsteiger dadurch eventuell zusätzliche hausgemachte Schwierigkeiten, Fachliteratur zu verstehen.

Hier muss ein vernünftiger Mittelweg gefunden werden. Englische Wörter, die in diesem Bereich zu Schlüsselbegriffen geworden sind und quasi in die deutsche Sprache aufgenommen wurden, werden daher nicht übersetzt. Gleiches gilt natürlich für Bezeichner.

Ein weiteres Problem betrifft die Aktualität der Texte. Sowohl das Verhalten als auch die Seiteneffekte von Programmen und Funktionen können sich mit der Zeit ändern. Die Dokumentation muss entsprechend angepasst werden. Wenn ein neues englisches man-pages-Paket herauskommt, müssen einige Seiten gegebenenfalls angeglichen werden. Für diese Aufgabe werden noch Mitarbeiter benötigt.

Installation

Die deutschen Linux-Distributionen SuSE-Linux und DLD sowie Debian GNU/Linux haben die Deutschen Manpages bereits ins System integriert. Wenn sie nicht in der von Ihnen verwendeten Distribution enthalten sind, besorgen Sie sich am besten das aktuelle Paket vom Infodrom-Server[3]. Es wird jeden Morgen neu zusammengepackt und befindet sich daher immer auf dem aktuellen Stand.

Nach dem Auspacken installiert das obligatorische make install die Dateien in Ihrem System. Wenn Ihr Man-Betrachter auch Dateien anzeigen kann, die mit gzip komprimiert wurden (z.B. man-db), dann rufen Sie vorher make gz auf.

Die Man-Betrachter suchen die anzuzeigenden Seiten normalerweise in den Unterverzeichnissen man1 bis man9 von /usr/man. Um übersetzte Seiten zu installieren, könnten bestehende Dateien einfach überschrieben werden. Dann stünde man jedoch vor dem Problem, dass bei einem automatischen Update des ursprünglichen englischen man-pages-Pakets die Seiten wieder durch die Originale ersetzt würden. Abgesehen davon stünden teilweise nur noch die übersetzten Seiten zur Verfügung.

Auf einem System mit mehreren Benutzern, die nicht nur die übersetzten Seiten sehen möchten, ist das nicht wünschenswert. Daher wurde für lokale Übersetzungen unterhalb von /usr/man eine weitere Verzeichnisebene für jede Sprache eingerichtet. Dabei wird das Sprachenkürzel aus zwei Buchstaben verwendet. Deutsche Manpages werden daher unterhalb von /usr/man/de und spanische unterhalb von /usr/man/es installiert.

Um die Seiten anschließend zu betrachten, muss der Man-Betrachter angewiesen werden, die zusätzliche Verzeichnisstruktur anstelle der regulären zu benutzen, sofern dort die passende Manpage gefunden wird. Ist keine übersetzte Seite zu finden, muss wie bisher im regulären Verzeichnis gesucht werden.

Um dem Programm diesen Wunsch mitzuteilen, wird die Variable LANG verwendet. Für die deutschen Seiten wird sie auf "de" gesetzt. Wenn man sich anschließend eine Manpage ansieht, wird zuerst nach der deutschen Seite gesucht. Die englische wird nur angezeigt, wenn die deutsche Seite nicht vorhanden ist. Alternativ kann beim Man-Betrachter man-db das Argument -L de angegeben werden, um auf deutsche Sprache umzustellen.

Der verwendete Pager (siehe Umgebungsvariable PAGER) muss zudem in der Lage sein, Umlaute korrekt darzustellen. Wird z.B. das Programm less verwendet, dann muss zusätzlich LESSCHARSET=latin1 gesetzt werden. Dieser Befehl sollte in einer der Startup-Dateien (.profile, .bash_profile, .bashrc etc.) eingetragen werden. Weitere Informationen dazu stehen in man(1).

Wie sieht so etwas aus?

Viele Leute lassen sich von der Technik abschrecken: "Manpages sind in roff geschrieben. Ich kann doch nicht programmieren". Solche und ähnliche Argumente hört man nicht selten. Ihnen kann jedoch ganz einfach begegnet werden, denn im Prinzip sind Manpages nichts anderes als Textdateien mit ein paar Steuerbefehlen.

Das folgende Beispiel zeigt eine der einfachsten Manpages. Der größte Teil besteht aus dem Copyright-Vermerk. Es folgt ein Titel (.TH = Top Heading) und zwei Überschriften (.SH = Section Heading) gefolgt von regulärem Text.

   .\" Copyright (c) 1993 Michael Haardt
   .\" (u31b3hs@pool.informatik.rwth-aachen.de), Fri Apr 2 11:32:09 MET DST 1993
   .\"
   .\" This is free documentation; you can redistribute it and/or
   .\" modify it under the terms of the GNU General Public License as
   .\" published by the Free Software Foundation; either version 2 of
   .\" the License, or (at your option) any later version.
   .\"
   .\" The GNU General Public License's references to "object code"
   .\" and "executables" are to be interpreted as the output of any
   .\" document formatting or typesetting system, including
   .\" intermediate and printed output.
   .\"
   .\" This manual is distributed in the hope that it will be useful,
   .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
   .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   .\" GNU General Public License for more details.
   .\"
   .\" You should have received a copy of the GNU General Public
   .\" License along with this manual; if not, write to the Free
   .\" Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
   .\" USA.
   .\" 
   .\" Modified by Thomas König (ig25@rz.uni-karlsruhe.de) 24 Apr 1993
   .\" Modified Sat Jul 24 17:28:08 1993 by Rik Faith (faith@cs.unc.edu)
   .\" German translation  Rene Tschirley (gremlin@cs.tu-berlin.de) 
   .\" Modified Mon Jun 10 00:20:20 1996 by Martin Schulze (joey@linux.de)
   .\" 
   .TH INTRO 7  "23. April 1993" "Linux" "Verschiedenes"
   .SH BEZEICHNUNG
   intro \- Einleitung in den Abschnitt 'Verschiedenes'
   .SH "BESCHREIBUNG"
   Dieses Kapitel beschreibt verschiedene Dinge, die von anderen Kapiteln
   nicht abgedeckt werden, so wie nroff Makro Pakete, Tabellen, C
   Headerstrukturen, die Dateihierarchie oder allgemeine Konzepte.
   .SH "AUTOREN"
   Informationen zu Autoren und Urheberrechten befinden sich in den Köpfen
   der jeweiligen Seiten.  Beachten Sie, dass diese Daten von Seite zu Seite
   unterschiedlich sein können!

In der Manualseite zu man(7) wird beschrieben, welche Formatierungsarten zur Verfügung stehen. Einfache Seiten lassen sich mit ca. einem Dutzend Befehle erstellen. Bezeichner, Makros und Dateinamen werden üblicherweise nicht in normaler Schrift sondern halbfett bzw. kursiv dargestellt. Gesteuert wird dieses durch Handvoll Befehle: .B, .I, .BR, .BI, .IR etc.

Allgemein ist es bei der Übersetzung eine gute Idee, die ursprüngliche Datei als Grundlage zu verwenden und dort die Texte zu übersetzen, während die Formatierungen übernommen werden.

Mitmachen kann jeder

An muttersprachlicher Dokumentation mitzuarbeiten, ist die einfachste Art und Weise, der "Gemeinde" etwas zurückzugeben und selbst etwas für die Qualität der Software zu tun. In seiner eigenen Muttersprache kann sich jeder ausdrücken, benötigt werden also nur noch eine E-Mail-Adresse, ein Editor und ein klein wenig Mut.

Damit Texte nicht mehrfach übersetzt werden, sollten sie vorher für andere gesperrt werden. Dieses geschieht durch Benachrichtung der Mailing-Liste oder des Projektleiters. Eine Liste der bereits übersetzten Manualseiten kann über das Web abgerufen werden, genauso eine Auflistung, wer an welchen Seiten arbeitet.

Bei wem jetzt das Interesse geweckt wurde, der sollte sich die Webseiten zu den Deutschen Manpages ansehen:

Leiter: Martin Schulze
Mailing-Liste: manpages-de@Infodrom.North.DE
Web: http://www.Infodrom.North.DE/Linux/manpages-de/

Um der Mailingliste beizutreten, reicht es, eine Mail an Majordomo@Infodrom.North.DE zu schicken und in der Mitteilung

   subscribe manpages-de

zu schreiben.

Neben einer Reihe Systemroutinen, deren Beschreibungen noch übersetzt werden müssen, werden inzwischen verstärkt auch übersetzte Manpages zu weit verbreiteten Anwendungsprogrammen gesucht.

Verschiedene Kategorien von Texten

Durch das Übersetzen der Manpages wird nur ein Teil der Texte abgedeckt, die in einem Progammpaket enthalten sind. Es gibt verschiedene Kategorien von Texten, die an unterschiedlichen Stellen bzw. auf unterschiedliche Arten in einem Paket verwendet werden. Man unterscheidet dabei:

Herkömmliche Texte
Erklärungen (README-Dateien und ähnliche Dateien) werden als normale ASCII-Texte im Paket mitgliefert. Wird das Paket installiert, dann werden diese Texte nach /usr/doc/Paket, /usr/lib/Paket oder /usr/share/Paket kopiert.
Manpages
Manpages sind in einem speziellen Format (roff mit man-Makros) geschrieben. Um sie zu betrachten, werden spezielle Programme benötigt. Die Dateien werden in Verzeichnissen man1 bis man9 unterhalb von /usr/man installiert.
Info-Dateien
Diese Dateien sind ebenfalls in einem speziellen Format, Texinfo, geschrieben. Sie werden mit einem sogenannten Info-Browser (info, pinfo, info-mode oder dwww) betrachtet.
Eincompilierte Texte
Menüpunkte, Fehlermeldungen und Warnungen, Eingabeaufforderungen, Hilfstexte u.s.w. bestehen aus Texten, die normalerweise fest in das jeweilige Programm eincompiliert sind.

Beim Aufrufen einer deutschen Manpage wie oben beschrieben, wird man feststellen, dass nicht nur der eigentliche Text auf Deutsch erscheint, sondern ebenfalls die regulären Ausgaben des Man-Betrachters. Diese Texte gehören zur vierten Kategorie und liegen ebenfalls übersetzt vor.

Internationalisierung von Programmen

Um eine allgemeine Lösung zu schaffen und um die Entwickler nicht übermäßig mit zusätzlicher Arbeit zu belasten, haben sich einige Leute zusammengesetzt und generelle Lösungen entwickelt. Die Internationalisierung befasst sich mit Techniken, Programme im laufenden Betrieb auf lokale Gegebenheiten anzupassen.

Abgekürzt wird sie mit i18n (internationalisation), denn vielen Entwicklern war das Wort schlichtweg zu lang. Sie haben den ersten und letzten Buchstaben behalten und die Zeichen in der Mitte durch deren Anzahl ersetzt. Analog dazu steht l10n für Lokalisierung (localisation), womit die Durchführung von i18n bezeichnet wird.

Das Ziel der Internationalisierung besteht nicht ausschließlich darin, Programmen zu ermöglichen, Texte in unterschiedlichen Sprachen zu verwenden. Das ist jedoch das auffälligste Merkmal. I18n befasst sich genauso mit Währungen, Zahlen und Zeitangaben. Nicht in allen Ländern werden Nachkommastellen durch ein Komma und Tausender durch einen Punkt getrennt. Im Englischen wird es bei Zahlen zum Beispiel genau umgekehrt gehandhabt.

Um diesem zu begegnen, wurde das System der sogenannten Locale entwickelt. Eine Locale ist ein Satz von Sprach- und kulturellen Regeln. Sie behandeln neben der Sprache für Meldungen auch Aspekte wie unterschiedliche Zeichensätze, lexikografische Konventionen und so weiter.

Damit ein Programm international angepasst und damit lokal eingesetzt werden kann, muss es beim Programmstart in der Lage sein, die gewünschte Sprache zu ermitteln und entsprechend zu reagieren. Es wurden daher eine Reihe von Umgebungsvariablen und C-Funktionen eingeführt, mit denen dieses Verhalten beeinflusst wird. Es wurde Wert darauf gelegt, einzelne Bereiche unabhängig von anderen ändern zu können.

LC_COLLATE
Diese Variable wird benutzt, um das Verhalten der Funktionen strcoll() und strxfrm() zu beeinflussen. Sie werden benutzt, um Zeichenketten gemäß des lokalen Alphabets zu vergleichen. Zum Beispiel wird das deutsche ß wie "ss" sortiert.
LC_CTYPE
Durch diese Variable wird das Verhalten von zeichenorientierten Funktionen wie isupper() und toupper() sowie multi-byte zeichenorientierten Funktionen wie mblen() oder wctomb() gesteuert.
LC_MONETARY
Diese Variable ändert die Informationen, die von localeconv() zurückgegeben werden. Sie beschreiben das Format, in dem Zahlen normalerweise ausgegeben werden, inklusive Details wie Dezimalpunkt bzw. Dezimalkomma. Diese Information wird intern von der Funktion strfmon() benutzt.
LC_MESSAGES
Mit dieser Variable wird die Sprache geändert, in der Meldungen angezeigt werden, und wie eine positive oder negative Antwort aussieht. Die GNU C-Bibliothek beinhaltet die Funktion rpmatch(), um diese Informationen anzuwenden.
LC_NUMERIC
Diese Variable ändert die Informationen, die von den Funktionsfamilien printf() und scanf() benutzt werden, wenn sie angewiesen werden, Lokale-Einstellungen zu benutzen.
LC_TIME
Über diese Variable wird das Verhalten der Funktion strftime() geändert, um die aktuelle Uhrzeit in einem lokal passenden Format anzuzeigen. In Europa wird zum Beispiel meistens eine 24-Stunden-Uhr benutzt, im Gegensatz zur 12-Stunden-Uhr in Amerika.

Soll das Verhalten in allen Bereichen umgestellt werden, dann wird die Variable LC_ALL benutzt. Teilweise werden überdies die Variablen LANG (wie bei man-db) oder LANGUAGE akzeptiert. Eine Lokale hat üblicherweise die Form

  language[_territory][.character-set][,version]

Die beiden letzten Teile werden hier außer Acht gelassen. Die Sprache wird als Zwei-Buchstaben-Code aus ISO 639[4] in Kleinbuchstaben angegeben. Für den zweiten Teil, falls er benötigt wird, hält der Zwei-Buchstaben-Code für das Land aus ISO 3166[5] her. Dieser wird in Großbuchstaben angegeben.

Für die deutsche Sprache wird somit LANG=de gesetzt. Genauer wäre de_DE, was jedoch nicht nötig ist, da es hier zwischen Sprache und Land keine Unterschiede gibt. Für Länder, in denen zwar eine Grundsprache gesprochen wird, in denen sich die Sprache jedoch weiterentwickelt hat, ist der zweite Teil vorgesehen, so z.B. fr bzw. fr_FR für Französisch in Frankreich und fr_CA für Französisch in Canada.

Eincompilierte Texte

Programme mehrsprachig zu halten, war schon lange ein Wunsch vieler Programmierer. Herausgekommen sind oft zweisprachige Programme (Englisch und die eigene Muttersprache). Dabei hat fast jeder Programmierer einen neuen Weg gefunden, die Texte in mehreren Sprachen zu verwenden.

Teilweise musste man sich beim Compilieren entscheiden, in welcher Sprache man das Programm compilieren möchte. Dann gibt es zwei unterschiedliche Programme, die sich nur in den Texten unterscheiden. Der Anwender - oder ein potentieller Übersetzer - hat dabei keine Chance Verbesserungen oder neue Übersetzungen einzubringen oder auf eine andere Sprache umzuschalten.

Werden die Texte nicht direkt eincompiliert, dann entstehen viele verschiedene Möglichkeiten, mehrere Sprachen zu unterstützen. Da die meisten Programmierer dabei ihr eigenes Süppchen brauen, sind diese Methoden nicht zueinander kompatibel.

Aus diesem Grund hat sich Ulrich Drepper von Cygnus Solutions vor Jahren hingesetzt und die Bibliothek gettext[6] entwickelt. Der Programmierer einer Anwendung muss sein Programm dazu nur minimal ändern, damit es auf gettext zurückgreift.

Anschließend steht eine standardisierte Schnittstelle zur Verfügung, um weitere Sprachen hinzuzufügen. Die Texte selbst werden in zusätzlichen Dateien gespeichert. Diese können vom Administrator selbst hinzugfügt werden, wenn der Autor eine Sprache noch nicht unterstützt.

Das Wichtigste ist jedoch, dass sich der Programmierer nicht mehr um Übersetzungen kümmern muss. Er muss lediglich die Dateien aufnehmen, die ihm von Übersetzern geschickt werden.

Die auffälligste Änderung im Programmcode ist:

Bisher:

   printf("Dijkstra probably hates me.\n");

Mit gettext:

   printf(_("Dijkstra probably hates me.\n"));

Hinter dem merkwürdigen Namen "_" verbirgt sich (über ein Makro definiert) ein Aufruf der Funktion gettext(). Alternativ kann man auch

   printf(gettext ("Dijkstra probably hates me.\n"));

im Programm schreiben. Wenn die Funktion gettext() keine Übersetzung findet, wird auf den normalen Text zurückgegriffen. Damit der Compiler weiß, welche neuen Funktionen zur Verfügung stehen, müssen folgende Deklarationen eingebunden werden, die man sinnvollerweise in eine Datei nls.h schreibt und mit #include "nls.h" einbindet.

   #ifndef __NLS_H__
   #define __NLS_H__

   
   #include 
   #define _(String) gettext(String)
   #define N_(String) (String)

   #endif 

In der main()-Routine muss gettext beim Progammstart schließlich aktiviert werden. Dazu wird der Pfad benötigt, unterhalb dessen die Sprachdateien in den Verzeichnissen sprachkürzel/LC_MESSAGES als basename.mo abgelegt sind. sprachkürzel entspricht der Locale (s.o.), basename wird vom Programmierer gewählt und sollte wie das Projekt benannt werden (z.B. »e2fsprogs« für die im Paket e2fsprogs enthaltenen Programme, wie mke2fs, e2fsck, etc.).

Als Sprachverzeichnis wird üblicherweise /usr/share/locale für Bestandteile des Systems und /usr/local/share/locale für eigene Erweiterungen verwendet. Zur Aktivierung werden folgende Zeilen in die main()-Routine eingefügt.

/P>

   bindtextdomain ("e2fsprogs", "/usr/share/locale");
   textdomain ("e2fsprogs");

Die Bibliothek gettext ist inzwischen Bestandteil der GNU libc (kurz: glibc). Daher werden keine weitern Optionen für Compiler oder Linker benötigt.

Texte übersetzen

Wenn das Programm so gut wie fertig entwickelt ist, werden alle zu übersetzenden Zeichenketten in eine Übersetzungsdatei kopiert. Die Texte sind im Programmcode mit _( markiert und lassen sich daher einfach mit folgendem Befehl aus den .c-Dateien extrahieren:

   xgettext --keyword=_ --force-po -o gerstensaft.pot ../src/*.c

In der Datei gerstensaft.pot stehen alle zu übersetzenden Texte. Es ist eine reine Textdatei mit Anweisungen, daher einfach zu modifizieren. Zu Anfang sieht sie wie folgt aus:

   # SOME DESCRIPTIVE TITLE.
   # Copyright (C) YEAR Free Software Foundation, Inc.
   # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
   #
   #, fuzzy
   msgid ""
   msgstr ""
   "Project-Id-Version: PACKAGE VERSION\n"
   "POT-Creation-Date: 1999-02-12 02:38+0100\n"
   "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
   "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
   "Language-Team: LANGUAGE <LL@li.org>\n"
   "MIME-Version: 1.0\n"
   "Content-Type: text/plain; charset=CHARSET\n"
   "Content-Transfer-Encoding: ENCODING\n"

   #: ../src/main.c:438
   msgid "Dijkstra probably hates me.\n"
   msgstr ""
   ...

Diese Datei wird anschließend in lang.po umbenannt, z.B. de.po. In der neuen Datei werden zunächst die Angaben im Kopf ausgefüllt. Anschließend werden die Texte übersetzt, die als msgid angegeben sind und in die leeren Felder von msgstr geschrieben.

   # Gerstensaft
   # Copyright (C) 1999 Free Software Foundation, Inc.
   # Martin Schulze <joey@infodrom.north.de>, 1999.
   #
   #, fuzzy
   msgid ""
   msgstr ""
   "Project-Id-Version: Gerstensaft 0.1\n"
   "POT-Creation-Date: 1999-02-12 02:38+0100\n"
   "PO-Revision-Date: 1999-04-26 09:10+0200\n"
   "Last-Translator: Martin Schulze <joey@infodrom.north.de>\n"
   "Language-Team: Deutsch <DE@li.org>\n"
   "MIME-Version: 1.0\n"
   "Content-Type: text/plain; charset=iso8859-1\n"
   "Content-Transfer-Encoding: ENCODING\n"

   #: ../src/main.c:438
   msgid "Dijkstra probably hates me.\n"
   msgstr "Dijkstra haßt mich wahrscheinlich.\n"

Ist das geschehen, muss die Datei lediglich noch "compiliert" und ins passende Verzeichnis kopiert werden. Sie wird in ein Binärformat übersetzt, um die Zugriffsgeschwindigkeit im Programm zu erhöhen. Die so entstandenen .mo-Dateien werden normalerweise nach /usr/share/locale/lang/LC_MESSAGES/programm.mo kopiert. Dort wird eine Sprachdatei beim Programmstart gelesen.

Der Befehl zum Compilieren von de.po in de.mo lautet:

   msgfmt --statistics -o de.mo de.po

Im Quellcode-Archiv (.tar.gz) einer Applikation befinden sich üblicherweise nur die .po-Dateien, die compilierten .mo-Dateien werden erst im Installations-Schritt erzeugt.

Werden weitere Texte in der späteren Entwicklung des Programms hinzugefügt, dann muss die Übersetzung natürlich nicht von vorne losgehen. In dem Fall wird die .pot-Datei nicht umbenannt, sondern vom Programm msgmerge mit der bestehenden Übersetzungsdatei gemischt. Das geschieht mit folgendem Befehl:

   msgmerge -o de.pox de.po gerstensaft.pot

Die daraus resultierende Datei de.pox enthält die Übersetzungen der Texte, die weiterhin vorhanden sind. Sind Textstellen rausgefallen oder anders formuliert, dann ist die entsprechende Passage in der neuen Datei nicht mehr vorhanden. Neu hinzugekommene Texte sind mit einer leeren Übersetzung aufgeführt.

Die Datei muss daher anschließend manuell bearbeitet und entsprechend ergänzt werden, bevor sie in lang.po umbenannt wird. Die so entstandene neue .po-Datei wird wie bisher weiterbearbeitet und dem Programmautor geschickt bzw. compiliert und im System installiert.

Bei dieser Methode muss sich der Autor der Applikation nicht um die Übersetzungen kümmern, sondern die Übersetzungsdateien nur ins Paket aufnehmen. Die Übersetzungsarbeit wird von den Leuten übernommen, die darin ihre Aufgabe sehen und darauf spezialisiert sind, während die Programmierer weiter programmieren können.

Üblicherweise werden die Übersetzungsdateien im Quellarchiv in einem eigenen Verzeichnis po gesammelt. In diesem sorgt ein Makefile für entsprechende Behandlung. Ein solches könnte wie folgt aussehen:

   prefix = /usr/local

   LOCALE_DIR=$(prefix)/share/locale

   basename=gerstensaft
   POFILES=$(shell echo *.po)
   MOFILES=$(POFILES:%.po=%.mo)
   POXFILES=$(POFILES:%.po=%.pox)
   LANGUAGES=$(POFILES:%.po=%)

   ifeq ($(shell whoami),root)
   install=install -o root -g root
   else
   install=install
   endif

   .SUFFIXES:	.po .mo .pox

   .po.mo:
	   msgfmt --statistics -o $@ $<

   .po.pox:
	   msgmerge -o $@ $< $(basename).pot

   all: $(MOFILES)

   pot:
	   xgettext --keyword=_ --force-po -o $(basename).pot ../src/*.c

   install: all
	   for lang in $(LANGUAGES); do \
	     test -d $(LOCALE_DIR)/$$lang/LC_MESSAGES || $(install) -d -g root -o root \
	   -m 755 $(LOCALE_DIR)/$$lang/LC_MESSAGES; \
	   $(install) -g root -o root -m 644 $$lang.mo \
	   $(LOCALE_DIR)/$$lang/LC_MESSAGES/\$(basename).mo; \
	     done

   clean:
	   rm -f $(MOFILES) $(POXFILES)

Anschließend stehen folgende Befehle zur Verfügung:

make pot
Erstellt eine neue .pot Datei, die alle im Programmtext vorhandenen Texte enthält, die übersetzt werden sollen.
make foo.pox
Erstellt aus der .pot-Datei und einer bestehenden .po-Datei eine neue .pox-Datei, die die neuen Texte berücksichtigt und manuell kontrolliert werden muss.
make foo.mo
Compiliert eine bestehende Datei foo.po in die entsprechende foo.mo-Datei, die anschließend ins Dateisystem installiert wird.
make
Erstellt aus allen .po-Dateien die entsprechenden .mo-Dateien.
make install
Installiert alle .mo-Dateien in das passende Verzeichnis.
make clean
Löscht alle .mo- und .pox-Dateien.
Einige dieser Befehle funktionieren nur dann, wenn mindestens eine .po-Datei in dem Verzeichnis liegt.

Ressourcen

  1. ftp://ftp.Infodrom.North.DE/pub/unix/archive/lha-1.00.tar.Z
  2. ftp://metalab.unc.edu/pub/Linux/docs/LDP/man-pages/
  3. ftp://ftp.infodrom.north.de/pub/Linux/Devel/manpages-de/manpages-de.tgz
  4. http://www.iro.umontreal.ca/contrib/po/iso-639
  5. ftp://ftp.Infodrom.North.DE/pub/doc/tech/tcpip/iso-3166.gz
  6. ftp://ftp.gnu.org/pub/gnu/gettext/