Einleitung

GNOME-Anwendungen werden unter der Vorgabe entwickelt, mit verschiedenen Sprachen und Normen zusammenzuarbeiten. Das bedeutet, dass eine Anwendung so erweitert werden kann, dass sie sich an verschiedenen (geographischen) Orten unterschiedlich verhält. Ausdrucke haben in Amerika eine andere Größe als in Europa, Wettertemperaturen werden an unterschiedlichen Orten in Fahrenheit oder Celsius angegeben und die Sprache, die der Benutzer vom Programm zu sehen bekommt, könnte seine Muttersprache sein.

Übersetzungen sind ein wichtiger Teil dieses Anpassungsprozesses. Ein Großteil der GNOME-Übersetzungen werden auf freiwilliger Basis von Muttersprachlern erstellt. Sie nehmen Zeichenketten in der originalen englischen Fassung, fügen die entsprechende Übersetzung hinzu und legen die Datei, welche diese Informationen enthält, im GNOME SVN Repository ab. Die nächste veröffentlichte Version dieser Anwendung enthält dann auch die neue Sprache bzw. deren Aktualisierungen.

Dieses Dokument versucht Ihnen zu erläutern, wie Sie bei diesen Übersetzungsprozess von GNOME mithelfen können.

Eine Übersetzergruppe finden

Als erstes sollten Sie herausfinden, ob bereits eine Gruppe an Ihrer Sprache arbeitet. Alle bekannten Gruppen sind in der GNOME Translation Project Team-Liste aufgeführt. Kontakt zu ihnen aufzunehmen ist der erste Schritt.

Kontakt zum deutschen GNOME-Übersetzungsprojekt

Die Anlaufstelle für deutschsprachige Übersetzer und solche, die es werden wollen, ist http://www.gnome-de.org/ bzw. die Mailing-Liste gnome-de.

Sollte bereits eine entsprechende Gruppe existieren, aber kein Kontakt zustande kommen, wäre die nächste Anlaufstelle die GNOME I18N Mailing-Liste. Von den Mitgliedern dieser Liste bekommen Sie in jedem Fall weitere Ratschläge dazu, was als nächstes zu tun ist. Anfragen an diese Liste sollten in englischer Sprache gehalten sein.

Falls es keine Gruppe für Ihre Sprache gibt, sollten Sie ebenfalls die GNOME I18N Mailing-Liste kontaktieren. Möglicherweise werden Sie dann dazu eingeladen, der Koordinator dieser Sprache zu werden.

Sollte die Kontaktaufnahme zu einer aktiven Gruppe erfolgreich gewesen sein, kann unter Umständen der nächste Abschnitt übersprungen und gleich zum Abschitt Übersetzen übergegangen werden.

Gründen einer neuen Übersetzergruppe

Es gibt keine Gruppe für Ihre Sprache, aber Sie sind mutig und entschlossen genug, eine neue Gruppe zu gründen und ihr Koordinator zu werden? Wunderbar!

Die Aufgaben eines Koordinators

Der Koordinator einer Gruppe ist der primäre Ansprechpartner für die Gruppe und verantwortlich für die Organisation der anderen Übersetzer dieser Gruppe. Dies beinhaltet die Vermeidung des Umstandes, dass mehrere Übersetzer gleichzeitig versuchen, ein und dieselbe Anwendung zu übersetzen.

Koordinatoren müssen die GNOME I18N Mailing-Liste abonnieren. Das ist übrigens für jeden Übersetzer sehr zu empfehlen, für die Koordinatoren aber unbedingt notwendig.

Der Koordinator hat in der Regel Zugang zum GNOME SVN. Sollte dieser keinen Zugang haben, werden alle Mitglieder die Übersetzungen zu ihm schicken und er wird diese an eine Person mit einem SVN-Zugang weiterleiten. Das stellt sicher, dass alle Übersetzungen korrekt sind und zur richtigen Zeit an die richtigen Leute kommen.

Anfangs sicher weniger, aber es werden auch Fehler im Zusammenhang mit Ihren Übersetzungen auftreten. Jede Sprache wird als eigene Komponente im GNOME Bugzilla Fehlerverfolgungssystem aufgeführt.

Der Koordinator wird sich häufig mit den technischeren Aspekten der Übersetzungsarbeit beschäftigen müssen, wie z.B. Pluralformen, Aktualisierung von configure.in Dateien oder Erstellung von Übersetzungsvorlagen (.pot Dateien). All das wird später ausführlich erläutert.

Möglicherweise werden Sie sich auch mit der Anwerbung von neuen Mitgliedern beschäftigen müssen. Viele Hände lassen die Übersetzung schneller vorankommen, auch wenn es mehr organisatorische Arbeit für Sie als Koordinator bedeuten könnte.

Es liegt ebenfalls in der Verantwortung des Koordinators, diese Position rechtzeitig abzugeben. Sobald sich herausstellt, dass nicht mehr genug Zeit für dieses Amt vorhanden ist, sollten Sie einen geeigneten Nachfolger suchen.

Sprachkennung

Um mit einer neuen Sprache zu beginnen, muss zuerst die Sprachkennung bekannt sein. Diese besteht aus zwei bis drei Buchstaben. Gebräuchliche Sprachen haben häufig nur zwei, exotischere Sprachen eher drei Buchstaben. Bei Sprachen, die in mehr als einem Land gesprochen werden, folgt der Sprachkennung ein Unterstrich und eine zweistellige, groß geschriebene Landeskennung. Dieser wiederum kann ein @-Zeichen und weiterführende Informationen angehängt sein.

GNOME benutzt Standardkennungen, die im ISO Standard 639 (für Sprachen) und im ISO Standard 3166 (für Länder) definiert sind.

Falls die Kennung der Sprache nicht herauszufinden ist, hilft möglicherweise die Suche nach Übersetzungsbeiträgen in anderen Projekten, wie z.B. KDE, Mozilla oder OpenOffice weiter — diese sollten die gleichen Kennungen benutzen. Wenn auch das nichts bringt, sollte die GNOME I18N Mailing-Liste um Hilfe gebeten werden.

Die Sprachkennung wird zur Indentifikation der Übersetzungen und Normen benötigt, z.B. für die Namen der Locales und für Dateien. Sobald diese Kennung bekannt ist, kann mit dem Übersetzen begonnen werden.

Was für den Anfang benötigt wird

Es gibt eine Reihe von Dingen, die die Übersetzungsarbeit wesentlich erleichtern.

Eine Mailing-Liste

Sie wird als Forum benötigt, über das die Gruppe — vorzugsweise in der eigenen Sprache — kommunizieren kann. Sie kann zur Vermeidung von doppelten Übersetzungen und zu Diskussionen über schwer zu übersetzende Worte bzw. Ausdrücke genutzt werden und auch zu einem allgemein gültigen Wörterverzeichnis führen. Möglicherweise ist es angebracht, diese Liste mit einem Übersetzungsteam eines anderen Projekts (z.B. KDE) zu teilen. Hier können auch Ankündingen zu Übersetzungen bekannt gegeben werden.

Diese Mailing-Liste könnte auch von Nutzern der erstellten Übersetzungen für Rückmeldungen und allgemeine Diskussionen verwendet werden.

Eine Website

Eine Website ist bietet sich an, um damit neue Mitglieder anzuwerben und dadurch die Arbeit weiter zu verteilen. Dort kann auch aufgeführt sein, wer sich um welches Paket kümmert. Andere Sachen, wie zum Beispiel das Wörterverzeichnis könnten Sie ebenfalls hier abgelegen.

Ein Wörterverzeichnis

Es ist wichtig, dass alle Übersetzungen konsistent sind und die gleichen Ausdrücke benutzen. Das vermeidet Verwirrung bei den Anwendern. Ein allgemeines Wörterverzeichnis wird Ihnen dabei helfen, dass nicht mehrere Varianten einer Übersetzung für ein und dieselbe Sache entstehen. Es sollte nicht versucht werden, eine Übersetzung neu zu erfinden. Stattdessen sollten vorhandene Übersetzungen wiederverwendet werden. Deshalb sollten Sie nach einem allgemein genutzten Grundstock an Wörtern dieser Sprache oder nach bereits vorhandenen Übersetzungen suchen. Eine Anlehnung an die Ausdrucksweise von Microsoft Windows oder Apple OS X wäre eine Möglichkeit. Im Zweifel ist es aber vorzuziehen, sich an anderen freien Benutzeroberflächen zu orientieren. Falls ein neuer Ausdruck erstellt oder eine Wahl zwischen zwei Ausdrücken getroffen werden muss, sollte die Entscheidung und der Hintergrund dazu dokumentiert werden. Das vermeidet später Verwirrungen. Anfangs getroffene Entscheidungen werden mit Sicherheit nach einigen erstellten Übersetzungen wieder revidiert. Aber es passiert nur einmal, dass Sie eine Übersetzung beginnen und dabei Probleme feststellen.

In einigen Gruppen übersetzen die gleichen Personen auch KDE, Mozilla oder OpenOffice in die gleiche Sprache. Es gibt aber auch Gruppen, die sich nur um die Übersetzung von GNOME-Anwendungen kümmern. Im zweiten Fall ist es eine sehr gute Idee, Kontakt zu den anderen Gruppen aufzunehmen und herauszufinden, was sie für ihre Übersetzungen benutzen, worauf sie sich stützen usw.

Eine gute Grundlage, um ein Wörterverzeichnis aufzubauen, ist eine Kombination der Stilanleitung des GNOME Dokumentationsprojekts und dem Glossar des gnome-i18n Moduls. Das letztere benötigt allerdings eine Aktualisierung.

Ein IRC Channel

Die Vorteile sind hier sehr ähnlich zu denen einer Mailing-Liste, außer dass er für bestimmte Arten von Diskussionen zweckdienlicher ist. Speziell, wenn es sich um eilige Anfragen handelt. Er kann natürlich auch zur Hilfestellung für Anwender der Übersetzung genutzt werden. Das Freenode Netzwerk ist ein IRC-Netzwerk, dass Diskussionen um freie Software gewidmet ist. Es wäre ein geeigneter Platz für einen Channel dieser Art.

Die gettext-Werkzeuge

gettext ist ein Paket, dass Werkzeuge zur Erstellung von übersetzbaren Zeichenketten, zur Umsetzung dieser Zeichenketten in Listen, zur Aktualisierung dieser Listen und zum Umwandeln der Listen in ein für den Rechner nutzbares Format enthält. Mindestens einer in der Übersetzergruppe, am besten aber so viele wie möglich, sollten die Grundlagen zur Benutzung der gettext-Werkzeuge beherrschen.

Dieses Paket wird bei vielen Linux-Distributionen installiert. Falls es nicht installiert wurde, sollte es zumindest verfügbar sein.

Ein Blick auf intltool lohnt sich ebenfalls. Es ist eine Art Frontend für gettext und übernimmt einige Arbeiten, die von einem Übersetzer gemacht werden müssen. Es ist für viele Distributionen verfügbar, aber meist ein oder zwei Versionen weiter, als die offiziellen Pakete. Die aktuellste Version kann aus dem GNOME SVN heruntergeladen werden: svn checkout intltool.

Übersetzen

Hier kommen wir endlich zum wichtigsten Teil. Eine einfache Distribution von GNOME in der Version 2.4 enthält mehr als 17000 einzelne Zeichenketten. Diese Zahl beinhaltet nicht Evolution, Galeon, eine Messaging-Anwendung oder andere Dinge, die möglicherweise als notwendig angesehen werden. Es gibt eine Vielzahl von Taktiken und Methoden, die hier angewendet werden können. Letztlich laufen aber alle auf die Übersetzung dieser Zeichenketten hinaus.

Verschiedene Ansätze

Es gibt mehrere Möglichkeiten zur Übersetzung. Einige Gruppen arbeiten direkt an den .po-Dateien, entweder mit einem einfachen Texteditor oder mit speziellen, GUI-basierenden Werkzeugen. Die fertigen Dateien werden dann in das GNOME SVN eingepflegt. Andere Gruppen arbeiten mit web-basierenden Systemen. Alle diese Möglichkeiten habe Vor- und Nachteile.

Eine ausführliche Beschreibung der .po Dateien befindet sich am Ende dieses Abschnitts und ist der längste Teil. Sollten Sie nicht beabsichtigen, etwas anderes zu nutzen, können Sie auch direkt zum Abschnitt .po-Dateien springen.

Web-Schnittstellen

Eine Web-Schnittstelle stellt eine Liste von Zeichenketten zur Verfügung und ermöglicht dadurch die Übersetzung. In bestimmten Zeitabständen werden die gesammelten Übersetzungen zurück in das SVN geschrieben. Der Vorteil hierbei ist, dass nur der Koordinator und der Verantwortliche für die Web-Schnittstelle wissen müssen, wie .po-Dateien erstellt werden. Außerdem lässt diese Lösung auch Hilfe von Leuten zu, die weder GNOME noch einen passenden Editor zur Verfügung haben. Ein Nachteil ist, dass die Beitragenden nicht den Rest der Dateien zu sehen bekommen. Das könnte zu Inkonsistenzen zwischen den einzelnen Übersetzungen führen. Ein weiteres Problem sind Kommentare zu einzelnen Zeichenketten, die der Entwickler an den Übersetzer richtet, da sie nicht immer angezeigt werden.

Zu bereits vorhandenen Web-Schnittstellen zählen folgende:

• Prevod

• Kyfieithu

• Das System der chinesischen Gruppe. Login: „i18n“, kein Passwort

po Dateien

Es gibt eine exzellente Anleitung, die beschreibt wie man Verzeichnisse aus dem SVN auscheckt, .pot-Dateien erstellt, diese in .po-Dateien umwandelt und wieder in das SVN eincheckt: Using GNOME CVS as a Translator. Diese Anleitung ist leider etwas veraltet, da sie die Nutzung von CVS (das System, welches vor der Einführung von SVN genutzt wurde) beschreibt, nahezu alles ist aber einfach übertragbar. Die Anleitung erklärt alle Einzelheiten zur Benutzung der gettext-Werkzeuge. Weil sie ca. 90% der Arbeiten mit .po-Dateien beschreibt, sollte sie auf jeden Fall gelesen werden. Die Beschreibungen werden an dieser Stelle nicht wiederholt. Stattdessen folgen hier einige zusätzliche Kommentare, die diese Anleitung keinesfalls ersetzen.

.po-Dateien sind auch über die Statusseite des GNOME Übersetzungsprojekts für die jeweilige Sprache erhältlich. Manchmal werden dabei allerdings spezielle Zeichen, die nicht im ASCII-Zeichensatz enthalten sind, entstellt. Es ist aber eine nützliche Alternative zum SVN.

Eine .po-Datei ist eine Liste von ursprünglichen Zeichenketten der Anwendung und Freiraum für die übersetzte Version. Zusätzlich dazu enthält sie noch einen Kopf mit folgenden Daten:

Project-Id-Version

• Hier steht der Name des Pakets und gegebenenfalls die Version, für die die Übersetzung gültig ist.

POT-Creation-Date, PO-Revision-Date

• Das „POT-Creation-Date“ ist das Datum, an dem die Vorlage erstellt wurde. Dieses Feld wird automatisch ausgefüllt. Das „PO-Revision-Date“ ist das Datum der letzten Änderung und muss von Hand geändert werden.

Language-Team

• Dieses Feld sollte die Sprache und am besten auch eine Kontaktadresse der Übersetzergruppe enthalten.

Content-Type

• Dieses Feld beschreibt den Zeichensatz und muss auf UTF-8 gesetzt werden. Es ist auch zwingend notwendig, dass die fertige Datei im UTF-8 Format vorliegt. Auf Rechnern mit UNIX oder UNIX-verwandten Betriebssystemen gibt file Auskunft darüber, welches Format eine Datei hat. Sollte die vollständige gettext-Umgebung auf Ihrem System installiert sein, können Sie auch msgfmt -cv -o /dev/null dateiname.po zum überprüfen verwenden. Sollte die Datei nicht im UTF-8 Format vorliegen, wird msgfmt -cv eine entsprechende Fehlermeldung ausgeben.

Auch Kommentare sind in der Datei enthalten. Diese sind durch das Zeichen # am Zeilenanfang gekennzeichnet. Ein Kommentar wie z.B. #,c-format weist darauf hin, dass die Zeichenkette Teile enthält, die von der Anwendung selbst ausgefüllt werden. Ein Beispiel dafür ist das Uhr-Applet aus gnome-panel. Dort gibt es eine Zeichenkette „%H:%M“. Diese kann einfach durch kopieren „übersetzt“ werden. Sie wird zur Darstellung der Systemzeit benötigt, wobei %H für die Stunde und %M für die Minuten steht.

In diesem Artikel gibt es einen separaten Anhang zu allgemeinen C-Format Zeichen.

Möglicherweise sind auch Kommentare des Programmieres für die Übersetzer enthalten. In gnome-panel zum Beispiel steht folgender Kommentar kurz nach der oben erwähnten Zeichenkette:

• #. translators: reverse the order of these arguments #. * if the time should come before the #. * date on a clock in your locale.

Ebenso sind Kennzeichnungen für Zugriffstasten, im folgenden Hotkeys genannt, zu ersetzen. Durch diese Hotkeys können Menüs und andere Elemente über die Tastatur bedient werden, ohne die Maus zu benutzen. Sie sind mit einem Unterstrich vor dem Buchstaben markiert, der zusammen mit der Alt-Taste den Hotkey bildet. Das wird anfangs zu Widersprüchen und Kollisionen führen, weshalb es möglicherweise sehr wichtig ist, die Hotkeys für gtk+ als erstes zu übersetzen. Diese wirken sich auf jede einzelne GNOME-Anwendung aus. Danach können Sie die übrig gebliebenen Zeichen benutzen und die beste Kombination für den jeweiligen Fall suchen. Sollten trotzdem einmal zwei oder mehrere Menüeinträge den gleichen Hotkey besitzen, ist das nicht weiter tragisch. Ab Version 2.4 lässt es GNOME zu, zwischen diesen Einträgen durch mehrmaliges Betätigen des Hotkeys zu springen.

Beschreibungen von GConf-Schlüsseln können auch enthalten sein. Normalerweise hat jeder Schlüssel eine kurze und eine detailliertere Beschreibung. Zeichenketten dieser Art erkennen Sie an ihrer Herkunft. Sie sind üblicherweise in Dateien mit der Endung .schemas.in.h enthalten.

Bei der Übersetzung von Schlüsselbeschreibungen sollten Sie Beispielausdrücke für den Schlüssel, eingeschlossen in doppelten Anführungszeichen, nicht mit übersetzen. Ein Beispiel:

• #: src/gnome-terminal.schemas.in.h:70 msgid "" "Default color of terminal background, as a color specification (can be HTML-" "style hex digits, or a color name such as \"red\")." msgstr "" "Die voreingestellte Hintergrundfarbe des Terminals als Farbangabe (kann als " "HTML-artige Hex-Zahl oder einer Schriftfarbe wie »red« angegeben werden)."

Hier ist red der Beispielausdruck und muss unverändert in die Übersetzung übernommen werden. Da doppelte Anführungszeichen in .po-Dateien eine besondere Bedeutung haben, werden diese mit einem Backslash maskiert. Bei deutschen Übersetzungen hat man sich dazu entschieden, statt der doppelten Anführungszeichen die umgekehrten französischen Anführungszeichen (AltGr-x bzw. AltGr-y) zu verwenden.

Falls einmal englische Beschreibungen auftauchen, die unverständlich sind, sollte ein Fehlerbericht für die entsprechende Anwendung erstellt werden. Auch wenn eine Beschreibung nicht sinnvoll übersetzt werden kann sollte das getan werden. Übersetzer im Ganzen erstellen viele solcher Meldungen, da sie in der Regel die Ersten sind, denen so etwas auffällt. Je eher solche Probleme angezeigt werden, desto besser. Falls Sie den Sinn der Beschreibung doch noch erkennen, werden Sie es möglicherweise vergessen. Solche Fehler zu melden, bewahrt andere Übersetzer davor, die gleichen Probleme zu haben.

Auf keinen Fall die msgid-Zeilen verändern

Die englischen Zeichenketten in der Datei dürfen Sie nicht verändern. Geänderte msgid-Zeichenketten werden durch die Programme, die die Übersetzung in die Anwendung integrieren, nicht abgefangen. Die Änderungen an der ursprünglichen Zeichenkette gehen verloren und die Übersetzung wird möglicherweise nicht eingefügt.

Mit Änderungen umgehen

Unglücklicherweise ändert sich Software hin und wieder. Dies betrifft auch übersetzbare Teile der Anwendungen. Zeichenketten kommen hinzu, ändern sich und manchmal werden diese auch entfernt. Glücklicherweise gibt es Werkzeuge und Prozeduren, die es Ihnen ermöglichen, mit den Änderungen der Anwendungen Schritt zu halten.

Die Statustabellen

Claude Paroz wartet die Statustabellen der Übersetzungen aller Sprachen, die in GNOME verfügbar sind. Sie sind auch über die Seite des GNOME Übersetzungsprojekts zu erreichen. Diese Tabellen enthalten verschiedene Ansichten und werden unmittelbar nach Änderungen im Git-Softwarebestand aktualisiert.

• Startseite

• GNOME-Grundpakete der stabilen Version: Alle Sprachen

• GNOME-Grundpakete der Entwicklungsversion: Alle Sprachen

• Alle Pakete: Deutsch

• Übersicht der einzelnen Module

Für jede Sprache gibt es Tabellen, die den Gesamtstatus und eine Aufspaltung in einzelne Pakete anzeigen. Diese Tabellen enthalten außerdem Links zu den aktuellsten .pot-Dateien (falls eine lokal vorliegende *.po-Datei aktualisiert werden soll) bzw. zur aktuellsten .po-Datei, die immer verfügbar ist, selbst wenn im Git noch keine solche Datei existieren sollte. Sie können direkt von dort heruntergeladen werden, ohne das Git zu benutzen.

Alle diese Funktionen stehen zumindest für die letzte stabile Version und die aktuelle Entwicklungsversion von GNOME sowie für Anwendungen, die nicht dem Veröffentlichungszyklus von GNOME unterliegen ("master" genannt), bereit.

Sobald Übersetzungen der jeweiligen Sprache in das Git eingepflegt wurden, erhält diese eine eigene Abteilung in den Statustabellen. Es lohnt sich, persönliche Lesezeichen auf die für die jeweilige Sprache relevanten Tabellen anzulegen. Sie sind sehr, sehr nützlich.

Jede Sprache ist über eine URL in der Form http://l10n.gnome.org/languages/XX/gnome-3-0 ereichbar, wobei XX durch die jeweilige Sprachkennung (klein geschrieben) ersetzt werden sollte. Soll eine andere Version angezeigt werden, ist eine entsprechende Anpassung der URL durch Angabe der Version in der Form „gnome-X-XX“ notwendig.

Geänderte Pakete aktualisieren

Wenn Sie Ihre Kopie eines Pakets über Git aktualisieren oder die Statusseiten im Browser aufrufen, werden Sie früher oder später auf Änderungen stoßen. Auch an dieser Stelle sei die Anleitung How to use Git for GNOME translators für die notwendigen Git-Befehle wärmstens empfohlen. Sollten mehrere Zeichenketten zu aktualisieren sein, gibt es verschiedene Wege, um an neue Vorlagen zu kommen. Die einfachste Möglichkeit ist das Herunterladen der fertigen Vorlage bzw. der aktualisierten .po-Datei von den Statusseiten. Die zweite Möglichkeit über das Git mit Hilfe von intltool ist in der oben angesprochenen Anleitung zu finden.

An dieser Stelle ist ein kleiner Abstecher zu den Hintergründen notwendig. Im Prinzip wird zur Aktualisierung eine neue Vorlage (.pot) erstellt und die vorhandenen Übersetzungen mittels msgmerge in diese Vorlage eingefügt. Das Ergebnis ist dann die aktualisierte .po-Datei.

msgmerge fügt aber nicht nur wirklich passende Übersetzungen ein, sondern erzeugt auch sogenannte „fuzzy“ (ungenaue) Übersetzungen. Hierbei werden die originalen Zeichenketten auf Ähnlichkeiten überprüft und bei ausreichender Übereinstimmung eine eventuell schon vorhandene Übersetzung eingefügt.

Ungenaue Übersetzungen sind auch als solche zu verstehen

Die Übersetzungen durch msgmerge treffen oft nicht den eigentlichen Sinn der originalen Zeichenkette. Jeder Übersetzer hat hier seinen eigenen Lieblingsvorschlag, den msgmerge liefert. Mein (Telsa's) persönlicher Favorit ist der Vorschlag, dass die Übersetzung von „Open window“ genutzt werden sollte, um „Close window“ zu übersetzen…

Ungenaue Übersetzungen sind in .po-Dateien durch einen Kommentar oberhalb der Zeichenketten markiert, der das Wort fuzzy enthält. Sollte die Übersetzung gut genug sein, können Sie die Markierung fuzzy entfernen. Wenn dieses Wort als einziges in der Kommentarzeile steht, kann die ganze Zeile gelöscht werden. Sollten Sie dieses Wort nicht entfernen, wird die Übersetzung von der Anwendung nicht genutzt. Ein paar Beispiele dazu:

• #, fuzzy msgid "Blah blah blah." msgfmt "Gelabere."

Falls die Übersetzung für diesem Fall zufriedenstellend ist, können Sie die Zeile mit dem Wort fuzzy komplett entfernen:

• msgid "Blah blah blah." msgfmt "Gelabere."

Gelegentlich werden Sie aber auch auf so etwas stoßen:

• #, c-format, fuzzy msgid "Very important: %s" msgstr "Sehr wichtig: %s"

Soll in diesem Fall die Ungenauigkeit entfernt werden, muss die c-format-Markierung intakt bleiben:

• #, c-format msgid "Very important: %s" msgstr "Sehr wichtig: %s"

Es wird auch einmal vorkommen, dass eine Reihe von Zeichenketten in ein anderes Modul verschoben wird. Das kann teilweise entmutigend sein, wenn die Übersetzungen dafür bereits erledigt sind und man denkt, dass die ganze Arbeit umsonst war. Diese Arbeit können Sie sich aber ersparen, indem Sie die vorhandene .po-Datei mittels msgmerge -o neu.po vorhanden.po vorlage.pot in das neue Modul einfügen.

Sie können sich auch eine persönliche Sammlung von Übersetzungen anlegen, die Sie als Quelle für Übersetzungsvorschläge nutzen können. Dies wird mit dem Befehl msgcat a.po b.po c.po > sammlung bewerkstelligt. Bevor die Sammlung benutzt wird, sollte sie speziell auf Zeichenketten in der Form „#-#-#-#-#“ untersucht werden. Diese zeigen Konflikte zwischen den einzelnen .po-Dateien. Diese Eigenschaft von msgcat kann ebenfalls zur Überprüfung von verschiedenen .po-Dateien auf Inkonsistenzen genutzt werden. Ist einmal eine Sammlung mit msgcat erstellt, kann sie mit msgmerge benutzt werden, um die Vorschläge in eine .po-Datei zu übernehmen. Ein Beispiel dafür: msgmerge -C sammlung -o neu.po alt.po vorlage.pot

Möglicherweise finden Sie auch eine Reihe von Übersetzungen in der .po-Datei, die nicht länger genutzt werden. Sie werden an das Ende der Datei geschoben und auskommentiert. Für die Anwendung haben sie dadurch keine Auswirkungen mehr und werden ignoriert. Diese Zeilen sollten Sie nur löschen, wenn es zu viele geworden und sie wirklich im Weg sind. Vielleicht werden sie zu einem späteren Zeitpunkt wieder in die Anwendung integriert. Sie werden auch durch den Befehl msgmerge für Übersetzungsvorschläge genutzt. Deshalb sollten sie stehen bleiben, wo sie sind.

Die erste Übersetzung

Dieser Abschnitt gibt Ihnen einige Hinweise zur Entscheidung, was Sie als erstes übersetzen sollten.

Suchen Sie sich zum Anfang etwas sehr kleines heraus, um mit den Übersetzungswerkzeugen vertraut zu werden. Es sollte auch möglichst eine Anwendung sein, damit Sie die Übersetzung sofort testen können. Eine kleine, alleinstehende Anwendung ist also die beste Wahl.

In den seltensten Fällen wird die aktuellste Version von GNOME aus dem Git auf Ihrem Rechner installiert sein. Meist ist es die letzte stabile Version. Deshalb ist es angebracht, genau die Version einer Anwendung zu übersetzen, die auch auf Ihrem Rechner vorhanden ist. Sollte zum Beispiel bug-buddy-2.8 installiert sein, sollte die Version aus GNOME 2.8 verwendet werden. Wird eine andere Version übersetzt, haben sich unter Umständen einige Änderungen an den Zeichenketten ergeben. Beim Ausprobieren würden dann nicht alle Übersetzungen angezeigt.

Sobald Sie die Anwendung mit der neuen Sprache testen, gibt es sicher einige allgemeine Knöpfe und Dialoge, die noch in englischer Sprache beschriftet sind. Sie werden durch Bibliotheken bereit gestellt, die in fast jeder GNOME-Anwendung zum Einsatz kommen. Um diese Teile in eine neue Sprache zu übersetzen, werden Sie einen Blick auf gtk+, libgnome und teilweise libgnomeui werfen müssen. Diese Pakete enthalten einige sehr schwierige Zeichenketten, die zu diesem Zeitpunkt nicht unbedingt übersetzt werden müssen. Suchen sie vorerst nur nach den Zeichenketten, die ständig in verschiedenen Dialogen auftauchen. Das wird Sie schon ein großes Stück weiter bringen.

Das gtk-Paket ist Teil einer Gruppe, die „developer-libs“ genannt werden. Es enthält in etwa die Hälfte aller Zeichenketten dieser Gruppe. Sobald Sie gtk übersetzt haben, werden Sie einen großen Sprung in Ihren Statistiken bemerken.

Einige Zeichenketten im Epiphany-Browser stammen von Mozilla. Sollten Sie Epiphany vollständig übersetzt haben, könnten trotzdem einige Zeichenketten, die durch Mozilla bereitgestellt werden, unübersetzt erscheinen. Sollte ein Mozilla-Sprachpaket in Ihrer Sprache existieren, werden Sie diese Tatsache unter Umständen überhaupt nicht wahrnehmen. Falls kein entsprechendes Sprachpaket verfügbar ist, können Sie nicht viel tun. Sie könnten natürlich einen Freund dazu bewegen, die Übersetzung von Mozilla zu übernehmen…

Installieren

Es ist sehr zu empfehlen, die Übersetzungen in direktem Zusammenhang mit der Anwendung zu testen. Das ist möglich, wenn Sie Root-Rechte auf einem Rechner mit einer halbwegs aktuellen GNOME-Installation haben. Die Anwendung braucht dazu eine sogenannte „Message-Object“ Datei (.mo), die Sie über msgfmt -cv erzeugen können. Die damit erzeugte Datei muss in das Verzeichnis /usr/share/locale/XX/LC_MESSAGES/ (wobei XX für die Sprachkennung steht) verschoben werden und den Namen des Programms tragen. Beispiele dafür sind metacity.mo oder nautilus.mo. Gelegentlich wird auch die Programmversion im Namen benötigt. Leider gibt es keine einfache Möglichkeit, den richtigen Namen für die .mo-Datei herauszufinden. Hier hilft nur die Suche in Unterverzeichnissen von /usr/share/locale/ nach bereits existierenden .mo-Dateien für andere Sprachen.

Jetzt können Sie die Anwendung starten. Änderungen an .mo-Dateien können die Anwendung zum Absturz bringen. Sollten Sie zum Beispiel gnome-terminal.mo aktualisieren während dieser noch läuft, bereiten Sie sich schon mal auf einen Crash vor …:) Sobald die Datei an ihrem Platz ist, wird alles wie gewohnt funktionieren. Es ist nur die Aktualisierung, die diese Probleme verursachen kann.

Die Locale muss existieren

Das Installieren der .mo-Datei wird nur funktionieren, wenn die Locale auf dem Rechner verfügbar ist. Am einfachsten ist es bei Debian: Hier gibt es einen Befehl dafür. Die Prozedur unterscheidet sich aber bei den verschiedenen Distributionen.

Sobald Sie herausgefunden haben, wie Sie Ihre Übersetzungen auf einem Rechner installieren können, teilen Sie es anderen Interessenten mit, damit diese Ihre Übersetzungen testen können. Andere Leute werden mehr Fehler als Sie selbst entdecken. Nebenbei könnten sie dadurch inspiriert werden, bei den Übersetzungen zu helfen.

Testen

Das Testen gewinnt an Bedeutung, wenn große Teile der Oberfläche übersetzt sind. Sie werden dabei feststellen, dass identische Begriffe unterschiedlich übersetzt sind oder der Sinn eines Begriffs durch eine Übersetzung nicht getroffen wurde.

Je mehr Sie testen oder testen lassen, umso besser.

Editoren

Eine Reihe von Editoren haben einen speziellen Modus zum Bearbeiten von .po-Dateien und werden automatisch in diesen fallen.

Stellen Sie sicher, dass der Editor im UTF-8 Format schreibt. Sollte die Datei nicht in diesem Format vorliegen, wird es Probleme im GNOME SVN geben.

Editoren, die gut mit UTF-8 zurecht kommen:

• Emacs
• Vim
• GEdit

Falls Sie vim verwenden, sollten Sie einige Dinge in Ihre .vimrc übernehmen:

• set fileencodings=utf-8 " Ein vim-Makro zum Kopieren von msgid in msgstr über Ctrl-E:

  map <C-E> :s/msgid "\(.*\)"\nmsgstr ""/msgid "\1"<C-V><CR>msgstr "\1"/<CR>

Es gibt ein Plugin zum Bearbeiten von .po-Dateien, das vim weitere nützliche Funktionen hinzufügt. Es ist auf der Vim-Website als po.vim verfügbar.

GNU-Emacs besitzt einen Editier-Modus eigens für .po-Dateien.

Es gibt auch Anwendungen mit grafischer Benutzeroberfläche zum Editieren von .po-Dateien. Das GNOME-Pendant nennt sich gtranslator.

Weitere Hinweise

Einige Dinge haben wir aus bitteren Erfahrungen gelernt. Sie werden hier aufgeführt, damit niemand die gleichen Fehler begeht.

• Warten Sie nicht Ewigkeiten damit, Aktualisierungen in einen Branch einzupflegen. Wie lange es auch dauert und wie mühsam es auch ist, den Branch auszuchecken und die Übersetzungen zu aktualisieren. Falls Sie beabsichtigen, den Branch und trunk zu übersetzen, tun Sie beides gleichzeitig. Wenn Sie dies nicht tun, wird der Tag kommen, an dem Sie Stunde um Stunde damit verbringen, die Aktualisierungen in den Branch zu übertragen.
• Sollten Sie eine langsame oder volumenbegrenzte Verbindung zum Netz haben, legen Sie die Branches in einem separaten Verzeichnis ab, statt zwischen HEAD und Branch zu wechseln. Zuerst wird es etwas länger dauern, auf lange Sicht spart es aber eine Menge Zeit.

• Automatisieren Sie soviel wie möglich, solange es sicher ist. Beim Einfügen einer neuen Übersetzung zum Beispiel, werden immer die gleichen drei Zeilen zur Änderung von configure.in in das Haupt-Changelog geschrieben. Erstellen Sie sich eine passende Datei, die alle notwendigen Angaben enthält und aktualisieren Sie das Datum täglich. Diese Datei kann dann über ein Editor-Makro eingefügt werden. Es ist in jedem Fall besser, als fünfzig Mal dasselbe einzugeben. Benutzen Sie auch Kurznamen für häufig genutzte Befehle, z.B. alias de-commit='svn commit -m "Updated German translation." de.po ChangeLog'

• Finden Sie einen Sprach-Enthusiasten. Sie werden auf eine Reihe von schwer zu übersetzenden Zeichenketten stoßen. Angefangen von Ausdrücken für Tabellenkalkulationen in Gnumeric bis zu dem Satz „The quick brown fox..“, der in der Schriftartauswahl verwendet wird, da er alle englischen Buchstaben enthält. Hier werden Sie ein passendes Gegenstück suchen oder erfinden müssen, was sich für Japanisch und Chinesisch schwierig gestalten könnte…
• Wenn es in Ihrer Sprache einen akzeptierten Satz an neuen Ausdrucksweisen gibt, sollten Sie sich dessen bewusst sein. Auch wenn Sie sie nicht gut finden. Möglicherweise müssen Sie sich irgendwann rechtfertigen, warum Sie nicht die „offizielle“ Terminologie verwenden…
• Sie werden des Öfteren auf versteckte Späßchen der GNOME-Hacker stoßen. Ein Beispiel: GEGL kann der Name einer Bibliothek sein (Generic Graphical Library), ist aber auch die Abkürzung von „Genetically Engineered Goat, Large“ (gentechnisch veränderte Ziege, groß). Das ist einfach nur ein kleiner Witz, der an verschieden Orten in GNOME vorkommt. Ein Bild dieser Ziege müsste unter /usr/share/pixmaps/gnome-gegl2.png zu finden sein…;) Solche Dinge müssen nicht unbedingt übersetzt werden. Es gibt auch eine Reihe von skurrilen „Hinweisen“ in einer der Aisleriot-Dateien.
• Akzeptieren und übernehmen Sie diese Dinge. Sie sind Teil von dem, was an GNOME Spaß macht. Auch wenn es manchmal nicht einfach ist, den Sinn zu verstehen und man vier Wörterbücher dafür wälzen muss…
• Auf der gnome-i18n Mailing-Liste und im #i18n IRC-Channel ist meist nicht viel los. Dort gibt es aber in jedem Fall erfahrene Leute, die Antworten auf die meisten Fragen haben und Wege zur Lösung von Problemen anbieten können. Benutzen Sie deshalb beides.

• Es kommt schnell mal vor, dass man die Unterstriche, die ein Tastenkürzel in Menüs markieren, in der Übersetzung vergisst. Der Unterschied in der Anzahl der Unterstriche zwischen den msgid- und msgstr-Zeichenketten kann mit dem Befehl msgfmt --check-accelerators=_ festgestellt werden. Sollte es aber die Zeichenkette „translator_credits“ geben und hier Ihr Name eingetragen sein, wird es immer einen Unterstrich geben, der zu fehlen scheint.

• Testen, testen, testen. Es ist schwer, alles dem Rechner Ihrer Sprache anzupassen. Aber es ist vergleichsweise einfach, Ihre eigene Übersetzung zu installieren — zumindest bei einigen Anwendungen. Tun Sie das. Es wird Ihnen wirklich helfen.
• Erstellen Sie ein Tarball der fertigen Übersetzungen — ein weiterer Kandidat zur Automatisierung. Stellen Sie es zusammen mit einer einfachen Anleitung ins Netz, so dass es andere Leute installieren können. Das bringt Ihnen früher Rückmeldungen und Hilfe, als wenn Sie darauf warten, dass Ihre Übersetzungen in einer Distribution mitgeliefert werden. Die Anleitung zur Installation wird unglücklicherweise von Distribution zu Distribution unterschiedlich ausfallen. Das Ergebnis ist es aber wert.

Glossar

• I18N : Die Abkürzung von „Internationalisation“: Der erste und letzte Buchstabe des Wortes und achtzehn weitere Buchstaben dazwischen. Internationalisierung ist der Prozess zur Sicherstellung der Lokalisierbarkeit eines Programms.
• L10N : Die Abkürzung von „Localisation“: Der erste und letzte Buchstabe des Wortes und zehn weitere Buchstaben dazwischen. Lokalisierung ist der Prozess zur landesspezifischen Anpassung von Programmen. Er beinhaltet außer der Übersetzung von Zeichenketten auch die Anpassung von Messgrößen, Währungen, Zahlendarstellungen und anderen landesspezifischen Regeln auf die jeweiligen Normen.

• Locale : Eine Locale ist ein Sammlung aus Sprache und kulturellen Regeln. Sie betrifft Mitteilungen in der Ausgabe von Programmen, verschiedene Zeichensätze, Messgrößen, Zahlenformate und ähnliches. Ein Programm muss seine Locale ermitteln können, um mit verschiedenen Sprachen und Regeln umzugehen. Die Zusammensetzung des Namens einer Locale ist im Abschnitt Sprachkennung beschrieben. Dieser Name wird üblicherweise Umgebungsvariablen wie LANG, LC_CTYPE, LC_COLLATE, LC_TIME, LC_NUMERIC, LC_MONETARY und LC_MESSAGES zugeordnet. Nähere Informationen finden Sie auch unter man 1 locale und man 7 locale.

• SVN / CVS : Die Abkürzung von „Subversion“. SVN ist ein System zur Versionskontrolle von hierarchischen Quellensammlungen mit Stärken im Bereich von Textformaten. Es verwaltet Quellverzeichnisse, die die Hauptkopien der versionskontrollierten Dateien enthalten, durch Kopieren einzelner Revisionen in ein privates Verzeichnis des Entwicklers und Speicherung der daran erfolgten Änderungen. Dieses System wird zur Sammlung und Verwaltung der GNOME-Quellen an einem zentralen Ort eingesetzt. Der Name des zuvor benutzten Systems hierfür lautet CVS („Concurrent Versions System“).

A. Spezielle Zeichen und eine spezielle Zeichenkette in po-Dateien

Hier folgt eine Liste von Zeichen und anderen Dingen, die Probleme verursachen können. C-Format Zeichen werden in einem eigenständigen Anhang erklärt.

• Zu maskierende Zeichen : Einige Zeichen werden durch Programme benötigt, die an den .po-Dateien arbeiten. Sollen diese nicht interpretiert werden, sondern ein Teil der Zeichenkette sein, müssen sie durch einen vorangestellten Backslash maskiert werden.
• Das am häufigsten auftretende Zeichen ist das doppelte Anführungszeichen (").
• Formatierungsmarken : Ihnen werden die Kombinationen \n oder \t über den Weg laufen. Sie stehen für Zeilenumbruch bzw. Tabulator. Sie müssen nicht unbedingt die gleiche Anzahl dieser Zeichen in Ihre Übersetzung einbinden. Falls aber eine dieser Marken am Anfang oder Ende der Zeichenkette steht, müssen sie in der Übersetzung ebenfalls an diesen Positionen stehen.

• Größer-/Kleiner-Zeichen sowie kaufmännisches Und in GConf-Dateien : Es gibt ein oder zwei Pakete, in denen XML sehr stark genutzt wird. GConf ist das bedeutenste davon. In XML haben die Zeichen <, > und & eine besondere Bedeutung. Sie müssen als Entitäten angegeben werden. Das gleiche gilt für Beschriftungen in Benutzeroberflächen, die Pango-Formatierungen enthalten. Der Syntax von Pango ist ähnlich dem von HTML. Solche Zeichenketten sind häufig in .glade.h-Dateien enthalten.

• &lt; wird ersetzt durch <

• &gt; wird ersetzt durch >

• &amp; wird ersetzt durch &

• Ersetzen Sie aber nicht die Zeichen, die Teil der Formatierung sind! Im Regelfall werden diese Zeichen so übernommen, wie sie in der ursprünglichen Zeichenkette enthalten sind. Ein Beispiel:

• msgid "<b>This and That</b>"

• msgstr "<b>Dies & Das</b>"

• Hier ist nur das im Original nicht enthaltene kaufmännische Und als Entität anzugeben. Die Formatierungsmarken bleiben bestehen.
• TRUE und FALSE : „TRUE“ und „FALSE“ kommen vor in gtk+, in Gconf und in vielen Dateien, die mit Glade generiert wurden (Dateiendung .glade.h). Übersetzen Sie diese Ausdrücke nicht. Programme erwarten sie an entsprechenden Stellen und werden Probleme verursachen, wenn diese Ausdrücke nicht vorhanden sind.

• Desweiteren gibt es eine sehr spezielle Zeichenkette in den .po-Dateien: Die msgid translator_credits. Der Inhalt der Übersetzung wird ausgegeben, wenn man eine Anwendung in der entsprechenden Sprache startet und sich die Liste der Mitwirkenden über Hilfe->Info anzeigen lässt. Hier sollte also Ihr Name bzw. die Namen aller Mitwirkenden eingetragen werden, so dass es jeder auf der Welt sehen kann. Das typische Format ist eine Liste der Namen und Email-Adressen auf separaten Zeilen. Achten Sie dabei auf die Zeilenumbruch-Markierung. Ein Beispiel: msgid "translator_credits" msgstr

  "Telsa Gwynne <hobbit@aloss.ukuug.org.uk>\n" "Dafydd Harries <daf@muse.19inch.net>"

Vergessen Sie also nicht, sich hier einzutragen

B. C-Format Zeichen

Hier folgt eine kurze Liste und einige Erläuterungen zu C-Format Zeichen. Alle Formatierungszeichen werden durch ein „%“ eingeleitet und stellen einen Platzhalter für einen variablen Inhalt dar. Ein Beispiel aus Nautilus:

• #: components/emblem/nautilus-emblem-view.c:834 #, c-format msgid "The file '%s' does not appear to be a valid image." msgstr ""

Zeichenketten, die solche Formatierungszeichen enthalten, sind wie im Beispiel mit einer „c-format“-Markierung versehen. Es gibt auch Formatierungen anderer Sprachen, wie z.B. „python-format“ (ähnlich wie C) oder „csharp-format“ (geschweifte Klammern), auf die hier aber nicht näher eingegangen wird.

Die gebräuchlichsten C-Formatierungszeichen

• %s:Eine Zeichenkette.
• %d, %i:Eine vorzeichenbehaftete Ganzzahl.
• %o:Eine Oktalzahl.
• %x, %X:Eine hexadezimale Zahl.
• %u:Eine vorzeichenlose Ganzzahl.
• %c:Ein einzelnes Zeichen.
• %p:Ein Zeiger.
• %f, %F:Eine Fließkommazahl im Dezimaldarstellung.
• %e, %E, %g, %G:Eine Fließkommazahl in Exponentialdarstellung.

Sollten mehrere dieser Formatierungszeichen in einer Zeichenkette stehen, bedeuten Sie meist nicht dasselbe. Ein weiteres Beispiel aus Nautilus:

• #: components/hardware/nautilus-hardware-view.c:483 #, c-format msgid "Uptime is %d days, %d hours, %d minutes" msgstr ""

Die Reihenfolge dieser Formatierungszeichen können Sie auch ändern, damit die Übersetzung einen Sinn ergibt oder besser formuliert ist. Es könnte zum Beispiel folgende Zeichenkette zu übersetzen sein:

• #, c-format msgid "String `%s' contains %d characters"

Eine deutsche Übersetzung mit umgekehrter Reihenfolge der Formatierungszeichen könnte so aussehen:

• #, c-format msgid "String `%s' contains %d characters"

msgstr "%2$d Zeichen sind in der Zeichenkette `%1$s' enthalten"

Wollen Sie in einer Zeichenkette mit „c-format“-Markierung des Zeichen „%“ verwenden, muss es zwei mal hintereinander stehen:

• #, c-format msgid "%d percent done." msgstr "%d %% fertiggestellt."

Lizenz

Telsa Gwynne

Dafydd Harries

Deutsche Übersetzung: Frank Arnold

Copyright © 2003 Telsa Gwynne, Dafydd Harries

Copyright © 2004 Dafydd Harries

Copyright © 2004 Frank Arnold (Deutsche Übersetzung)

Dieses Dokument können Sie unter den Bedingungen der GNU General Public License, wie von der Free Software Foundation veröffentlicht, weitergeben und/oder modifizieren, entweder gemäß Version 2 der Lizenz oder (nach Ihrer Option) jeder späteren Version. Der vollständige Wortlaut dieser Lizenz kann unter http://www.gnu.org/copyleft/gpl.html abgerufen werden.

CategoryGnomeI18n