Open Source im professionellen Einsatz

Internationalisierung von XML-Dateien

Internationale, die zweite Thorsten Fischer

XML ist - man kann es schon nicht mehr hören - in aller Munde. Auch Gnome macht heftigen Gebrauch davon, und irgendwann stellt sich dann die Frage nach der Internationalisierung und Lokalisierung von XML-Dateien.

Die Extensible Markup Langu-age (XML) breitet sich inzwischen fast epidemisch aus und die meisten Hersteller und Programmierer scheinen sich damit anfreunden zu können. Auch in Gnome hat XML Einzug gehalten, sei es nun im Dateiformat von Gnumeric oder beim Speichern beziehungsweise dynamischen Erstellen von GUIs durch Glade und PonG.

Wenn man sich aber auf die Fahnen geschrieben hat, eine Umgebung zu schaffen, die leicht internationalisiert und anschließend lokalisiert werden kann - zu den Unterschieden siehe Kasten "i18n und l10n" -, dann ist die Frage zu stellen, wie man XML-Dateien übersetzbar macht, ohne dass mit einer schönen Neuerung die Konsistenz der Umgebung gleich in Unordnung gerät.

Erfindungsreichtum ist also angesagt und dieser Reichtum hat die XML-i18n-Tools hervorgebracht, einen Satz von Werkzeugen, mit denen sich XML-Dateien, unter anderem für Gnome, internationalisieren und lokalisieren lassen.

i18n und I10n

Internationalisierung und Lokalisierung werden häufig in einen Topf geworfen - und die Unterschiede sind auch wahrlich fein.

Um ein Programm in einer bestimmten Sprache nutzen zu können, muss es für diese Sprache lokalisiert sein. Im Grunde ist jedes Programm, das eine Ausgabe verursacht, bereits in der Sprache lokalisiert. Schreibt man also ein Skript, das seine Fehlermeldungen auf Deutsch ausgibt, ist es deutschsprachig lokalisiert.

Ein Linux-System ist schon darauf ausgerichtet, bei Bedarf in verschiedenen Sprachen agieren zu können, je nach Präferenz der Benutzer. Dazu müssen im Wesentlichen Umgebungsvariablen gesetzt werden, anhand derer zu erkennen ist, welche Sprache benutzt werden soll. Damit ein Programm in einer solchen Umgebung mitspielen kann, muss es darauf vorbereitet werden. Den Vorgang, ein Programm so aufzubauen, dass es später lokalisiert werden kann, nennt man Internationalisierung.

Und die beiden Kürzel i18n und l10n? Nun, Programmierer, Informatiker und die Leute, die darüber schreiben (müssen), sind generell faul und versuchen sich möglichst viel Arbeit zu sparen: "Internationalization" und "Localization" sind nicht nur umständlich auszusprechen. Daher begnügt man sich mit dem ersten und dem letzten Buchstaben der Wörter und setzt dazwischen die Anzahl der Buchstaben, die man weggelassen hat.

Perlen mit Perl

XML-Dateien sind reine Textdateien, und was bietet sich da mehr an, als das Problem mit der Practical Extraction and Report Language anzugehen: die XML-i18n-Tools sind ein Satz von Perl-Skripten. Günstigerweise müssen die XML-i18n-Tools nicht auf dem System der Person installiert sein, die sich den Quellcode letztlich kompilieren beziehungsweise installieren will. Lediglich wir als Programmierer müssen uns mit den Details auseinandersetzen.

Doch zunächst mal generell zur i18n und l10n von Gnome-Programmen. Die Möglichkeit, in verschiedenen Sprachen zu agieren, lässt sich am einfachsten nutzen, wenn man sich einen Autoconf/Automake-Baum für den Quellcode baut. Einen solchen Baum kann man sich beispielsweise durch den GUI-Builder Glade erstellen lassen oder kopiert sich Gnome-Hello von einem FTP-Spiegel.

Neben der Notwendigkeit, Gettext auf seinem System installiert zu haben, und diversen anderen Vorbereitungen [1], geht man als Programmierer bei einer normalen - soll heißen XML-losen - i18n wie folgt vor: Die Strings, die zu übersetzen sind, werden mit einem Makro markiert, meist ist das _(). Statt einer Zeile im Programm wie

printf ("Please print me now");

erscheint nun:

printf (_("Please print me now"));

Im Zusammenspiel mit normalen Quelltextdateien, in denen Zeilen wie diese stehen, sammeln die XML-i18n-Tools Strings aus XML-Dateien wie .glade, .xml.in, .oaf.in und so weiter zusammen und fügen sie in die Listen der zu lokalisierenden Zeichenketten in po/$(PACKAGE).pot ein, wobei PACKAGE nach der jeweiligen Sprache benannt ist; de.pot enthält beispielsweise die deutschen Übersetzungen.

Parallel dazu werden dem Quelltextpaket automatisch die Skripte XML-i18n-Merge, XML-i18n-Extract und XML-i18n-Update noch hinzugefügt, so dass die übersetzten Dateien korrekt bei der Installation der Software eingespielt werden. Der Benutzer, der das Programm kompiliert, muss also lediglich Perl installiert haben, die erforderlichen Werkzeuge zur Übersetzung bekommt er bereits mitgeliefert. Bei eben dieser Installation werden die Übersetzungen aus den po/*.po-Dateien dann im System installiert.

Für XML-Dateien stellt sich natürlich die Frage, wie die zu übersetzenden Zeichenketten zu markieren sind. Das erwähnte Makro ist für diesen Zweck leider nicht einsetzbar, da würde sofort jeder XML-Parser anfangen zu husten. Das Problem lässt sich dadurch lösen, dass alle Tags, die übersetzt werden, mit einem Unterstrich beginnen. In einem Tag wie beispielsweise

<toolitem name="New" pixtype="stock" pixname="New" _label="New"/>

erscheint das Attribut label in der Reihe der Übersetzungen.

Schritt für Schritt

Zuerst sind natürlich die XML-i18n-Tools selber zu installieren. Dieser Vorgang erledigt sich mit einem einfachen ./configure && make && make install. Danach sind einige Änderungen an den eigenen Quelltexten fällig. Die Datei configure.in muss die Zeile

AM_PROG_XML_I18N_TOOLS

erhalten. Die Datei autogen.sh benötigt außerdem einen Aufruf der Tools; daher muss dort, nach dem Aufruf von gettextize, diese Zeile stehen:

xml-i18n-toolize --copy --force  --automake

Damit entstehen die drei Dateien xml-i18n-extract.in, xml-i18n-update.in und xml-i18n-merge.in. Diese Dateien sollten natürlich mit dem Quelltextpaket vertrieben und daher in die Sektion EXTRA_DIST im obersten Makefile.am aufgenommen werden:

EXTRA_DIST=xml-i18n-extract.in xml-i18n-update.in xml-i18n-merge.in

Schließlich und endlich sind noch die Dateien, die in die Lokalisierung übernommen werden sollen, in die Datei po/POTFILES.in einzutragen.

Übersetzbare .desktop-Datei

[Desktop Entry]
_Name=Super program
_Comment=My super program that does everything
TryExec=superprog
Exec=superprg
Icon=superproc.png
Terminal=0
Type=Application

Diesen Artikel als PDF kaufen

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook