This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

Contents

  1. Einleitung
  2. Eine Übersetzergruppe finden
  3. Kontakt zum deutschen GNOME-Übersetzungsprojekt
  4. Gründen einer neuen Übersetzergruppe
  5. Die Aufgaben eines Koordinators
  6. Sprachkennung
  7. Was für den Anfang benötigt wird
    1. Eine Mailing-Liste
    2. Eine Website
    3. Ein Wörterverzeichnis
    4. Ein IRC Channel
    5. Die gettext-Werkzeuge
  8. Übersetzen
    1. Verschiedene Ansätze
    2. Web-Schnittstellen
  9. po Dateien
      1. Auf keinen Fall die msgid-Zeilen verändern
      2. Mit Änderungen umgehen
      3. Die Statustabellen
  10. Geänderte Pakete aktualisieren
  11. Ungenaue Übersetzungen sind auch als solche zu verstehen
  12. Die erste Übersetzung
    1. Installieren
    2. Die Locale muss existieren
    3. Testen
  13. Editoren
  14. Weitere Hinweise
  15. Glossar
  16. A. Spezielle Zeichen und eine spezielle Zeichenkette in po-Dateien
  17. B. C-Format Zeichen
    1. Die gebräuchlichsten C-Formatierungszeichen
  18. Lizenz

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.

„fr“

Französisch

„en_GB“

Englisch, wie es in Großbritannien verwendet wird

„de_DE@euro“

Deutsch, wie es in Deutschland verwendet wird. Zusätzliche Anpassungen rund um die Euro-Währung

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:

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

POT-Creation-Date, PO-Revision-Date

Language-Team

Content-Type

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:

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:

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.

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:

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

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

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

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:

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

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.

Glossar

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.

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:

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

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

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:

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

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:

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

2024-10-23 11:55