Manpages-DE
Infodrom Oldenburg
<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.
Die anerkannte Sprache im Internet ist Englisch. Daher verwundert es wohl niemanden, daß ü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 dieses allemal, denn nur so kann sichergestellt werden, daß die Programme auch weltweit benutzt werden können.
Voraussetzung dafür ist jedoch, daß 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 verfaßt 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.
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 Paketes. Dort
häuften sich die Anfragen nach einem Paket mit deutschen Texten. Der
Verwalter es 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 seit dem pflegt. Das Hauptaugenmerk wird auf die im ursprünglichen Manpages Paket enthaltenen Seiten gelegt. Dieses umfaßt 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 sind 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 Verläge 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, daß keine konkreten Anweisungen enthalten sind, wie:
Schriftart SansSerif, 12 Punkt, kursivsondern, daß der Text logisch strukturiert ist:
<Überschrift Anfang>Das ist eine Überschrift<Überschrift Ende>Das Dokument läßt 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.
Im Falle des deutschen Projekts werden alle eingeschickten Übersetzungen darüberhinaus korrekturgelesen. Andreas Braukmann stellt dadurch sicher, daß kein geholpertes Deutsch entsteht und der Sinn nicht versehentlich entstellt wird. Zudem achtet er darauf, daß die Übersetzungen in der richtigen Form eingepflegt werden, so daß 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 Mißstand zu beheben.
Hier muß 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 muß entsprechend
angepaßt werden. Wenn ein neues englisches man-pages-Paket
herauskommt, müssen einige Seiten ggf. angeglichen werden. Für diese
Aufgabe werden noch Mitarbeiter benötigt.
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, daß 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, muß 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, muß 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) muß zudem in der
Lage sein, Umlaute korrekt darzustellen. Wird z.B. das Programm less
verwendet, dann muß 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).
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, daß 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.
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 Mail
subscribe manpages-dezu schreiben.
Neben einer Reihe Systemroutinen, dessen Beschreibungen noch übersetzt werden müssen, werden inzwischen verstärkt auch übersetzte Manpages zu weit verbreiteten Anwendungsprogrammen gesucht.
- 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/maninstalliert. - Info-Dateien
- Diese Dateien sind ebenfalls in einem speziellen Format, Texinfo,
geschrieben. Sie werden mit einem sogenannten info-Browser (
info,pinfo,info-modeoderdwww) betrachtet. - Einkompilierte Texte
- Menüpunkte, Fehlermeldungen und Warnungen, Eingabeaufforderungen, Hilfstexte u.s.w. bestehen aus Texten, die normalerweise fest in das jeweilige Programm einkompiliert sind.
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 befaßt 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 angepaßt und damit lokal eingesetzt werden kann, muß 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 beeinflußt 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()undstrxfrm()zu beeinflussen. Sie werden benutzt, um Zeichenketten gemäß des lokalen Alphabets zu vergleichen. Zum Beispiel wird das deutsche scharfe ß wie "ss" sortiert. LC_CTYPE- Durch diese Variable wird das Verhalten von zeichenorientierten
Funktionen wie
isupper()undtoupper()sowie multi-byte zeichenorientierten Funktionen wiemblen()oderwctomb()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 Funktionstrfmon()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()undscanf()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.
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-Buchstabencode aus ISO 639[4] in Kleinbuchstaben angegeben. Für den zweiten Teil, falls er benötigt wird, hält der Zwei-Buchstabencode 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.
Teilweise mußte man sich beim Compilieren entscheiden, in welcher Sprache man das Programm kompilieren 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 einkompiliert, 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 muß 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, daß sich der Programmierer nicht mehr um Übersetzungen kümmern muß. Er muß 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.
/* Enable NLS */Die Bibliothek gettext ist inzwischen Bestandteil der GNU libc (kurz: glibc). Daher werden keine weitern Optionen für Compiler oder Linker benötigt.
_( markiert und lassen sich daher einfach mit
folgendem Befehl aus den .c-Dateien extrahieren:
xgettext --keyword=_ --force-po -o gerstensaft.pot ../src/*.cIn 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:
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 NAMEDiese Datei wird anschließend in <lang>.po umbenannt, z.B.\n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: ENCODING\n" msgid "Dijkstra probably hates me.\n" msgstr "" ...
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.
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 SchulzeIst das geschehen, muß 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\n" "Language-Team: Deutsch \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=iso8859-1\n" "Content-Transfer-Encoding: ENCODING\n" msgid "Dijkstra probably hates me.\n" msgstr "Dijkstra haßt mich wahrscheinlich.\n"
/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.poIm 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 muß 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.potDie 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 muß 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 muß 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=/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 $@ $< .pot all: pot: xgettext --keyword=_ --force-po -o .pot ../src/*.c install: all for lang in ; do test -d /$$lang/LC_MESSAGES || -d -g root -o root -m 755 /$$lang/LC_MESSAGES; -g root -o root -m 644 $$lang.mo /$$lang/LC_MESSAGES/.mo; done clean: rm -fAnschließend stehen folgende Befehle zur Verfügung:
-
make pot - Erstellt eine neue
.potDatei, 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 muß. -
make foo.mo - Kompiliert eine bestehende Datei
foo.poin die entsprechendefoo.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.
.po-Datei in dem Verzeichnis liegt.
[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