Getting translation strings right/de

From Free Pascal wiki
Jump to navigationJump to search

│ Deutsch (de) │ English (en) │ español (es) │ français (fr) │ 日本語 (ja) │ русский (ru) │

Diese Seite enthält einige grundlegende Bemerkungen darüber, wie man Übersetzungstrings richtig hinbekommt vom Anfang an und aus der Sichtweise eines Originalautors (d.h. zumeist eines Programmierers).

"Richtig hinbekommen" (To get it right) bedeutet in diesem Zusammenhang, dass die Übersetzungsstrings für eine leichtere nachfolgende Übersetzung richtig vorbereitet wurden, und dass die Originalversion an die grundlegenden Erfordernisse für ihren Einsatz angepasst wurde.

Obwohl hier versucht wurde, so sprachneutral wie möglich zu bleiben, besteht de facto eine leichte Einseitigkeit zugunsten des Englischen. Es liegt in Ihrem Ermessen, Richtlinien zu erweitern oder diejenigen zu verwerfen, die nicht auf Ihre Situation passen. (Oder vielleicht fügen Sie sie auch an diese Seite an?)

Allgemeines

Um Probleme zu vermeiden, stellen Sie einfach sicher, dass zuallererst die Originalstrings in Ordnung sind - dafür gibt es einige Gründe:

  • Die Originalstrings dienen normalerweise als Vorgabeübersetzung, und hinterlassen einen schlechten Eindruck für den Endbenutzer, der ungewollt die unübersetzten Vorgabestrings sieht.
  • Auch erschweren schlechte Originalstrings dem Übersetzer die Arbeit unnötig. Dieser ist ja für die Übertragung der ursprünglichen Informationen in eine andere Sprache verantwortlich. Erinnern Sie sich einfach an das Prinzip "Wo Müll hinein kommt, kommt auch nur Müll heraus", das hier perfekt zutrifft.

Versuchen Sie deshalb, sicher zu stellen, dass die Schreibweise korrekt ist - nehmen Sie ein Wörterbuch zur Hand, wenn Sie sich unsicher sind (z.B. [1]).

Benutzen Sie verständliche und bekannte Phrasen für die Situation, die Sie beschreiben möchten, in einer einheitlichen Weise. Falls Sie unsicher sind, ob etwas geläufig ist, schauen Sie sich ähnliche Programme an und betrachten Sie deren Ausgaben. Auch die Literatur und Hilfedateien sind oft eine gute Quelle für die genauen Fachbegriffe oder -ausdrücke, oder Fragen des Stils. Bleiben Sie auch in der Auswahl der Phrasen einheitlich. Beispielsweise haben die Fragen 

Delete the file? (Datei löschen?)
Erase the file? (Datei beseitigen?)
Remove the file? (Datei entfernen?)
Wipe the file? (Datei säubern?)
Zap the file? (Datei vernichten?)

alle fast die selbe Bedeutung. Wenn man sie aber - ohne ersichtlichen Grund - wahlweise einsetzt, interpretiert manch ein Leser verrückte Dinge hinein. Besonders anfällig für diesen Fehler sind Übersetzer, weil sie oft den genauen Kontext einer bestimmten Nachricht nicht kennen (z.B. Informationen über den Ursprung der Nachricht). Sie könnten einfache Wortvariationen als Hinweis auf bedeutende Unterschiede interpretieren, und geraten in Versuchung, unübliche (schlechte) Übersetzungen zu wählen.

Besonders bei Fehlermeldungen an den Benutzer gilt: Beschreiben Sie das Problem selbst in passenden Worten. Das ist niemals der Zustand des Programms, der zur Fehlermeldung führte. Dieser ist nur für die Person nützlich, die den Fehler im Programm beseitigen soll, nicht für den Benutzer. Benutzer werden entweder einfach mit den Schultern zucken und den Fehler bestenfalls ignorieren. Oder aber sie wechseln im schlechtesten Fall zu einem anderen Programm, weil sie ohne eine genaue Problembeschreibung nicht das Problem lösen und mit ihrer Arbeit fortfahren können. All das nur, weil das Programm keine brauchbare Problembeschreibung lieferte.

Nehmen Sie (leicht) verständliche Beschreibungen. Versuchen Sie nicht, Ihre Kunden mit Fremdwörtern oder technischen Begriffen zu beeindrucken, nur um ihnen zu sagen, dass ihre Arbeit nicht gespeichert werden konnte.

Vermeiden Sie mehrfache Verneinungen innerhalb eines einzelnen Satzes. Diese sind fast immer schwerer zu lesen als ihre nicht-negierten Gegenstücke. Ein Beispiel wäre 

Diese Komponente kann auf Non-TControls nicht abgelegt werden.

Hingegen ist die nicht-negierte Formulierung 

Diese Komponente kann nur auf TControls abgelegt werden.

sicher leichter zu lesen und zu verstehen.

Technische Fragen

In diesem Abschnitt erhalten Sie einen kurzen Überblick über technische Fragen, eigentlich einen Überblick über die grundlegenden Möglichkeiten. Diese umfassen das Konstrukt 'resourcestring', GNU gettext() und die Funktion 'format()'.

Ressourcenstrings und GNU gettext

Free Pascal hat einige eingebaute Sprachkonstrukte für die Behandlung konstanter Zeichenketten. Es gibt einen Abschnitt einer Unit namens "resourcestring", die speziell für diesen Zweck eingeführt wurde. Siehe auch den entsprechenden Abschnitt des FPC-Handbuchs (prog.pdf, S. 89ff oder hier) für die Details.

GNU gettext ist ein spezieller Satz von Werkzeugen, um Übersetzungen für Ihre Programme zu liefern. Siehe ebenfalls im FPC-Handbuch (prog.pdf, S. 91ff oder hier).

Anmerkung: GNU gettext hat eine konzeptuelle Macke, die es nicht erlaubt, einen einzelnen Originalstring an mehrere übersetzte Strings zuzuweisen, also Achtung.

Ressourcenstrings in der IDE

  • Für jeden Ressourcenstring-Abschnitt erzeugt FPC eine .rst-Datei, aber es gibt keinen Editor für diese Dateien. Lazarus kann automatisch .po-Dateien aus den .rst-Dateien erzeugen. Es gibt eine Vielzahl von Werkzeugen zum Bearbeiten von .po-Dateien (z.B. kbabel unter Linux, PoEdit unter Windows).

Um die Erzeugung der .po-Dateien für ein Package zu aktivieren, beachten Sie folgende Schritte: 

 * Erstellen Sie ein Unterverzeichnis namens 'languages' (oder 'locale', oder sonstwie).
 * Öffnen Sie das Package. Stellen Sie unter Einstellungen -> IDE Integration -> Verzeichnis der .po-Dateien das Verzeichnis languages ein.

Wenn Sie das nächste Mal das Package kompilieren, erzeugt die IDE die .po-Dateien. Anmerkung: Die .rst-Dateien müssen zu den Package-Units gehören. Andernfalls ignoriert die IDE die fremden .rst-Dateien.

Das funktioniert auch bei Projekten. Das Verzeichnis wird unter Projekt -> Projekteinstellungen -> IDE Integration -> Verzeichnis der .po-Dateien.

  • Um eine deutsche Übersetzung zu erzeugen: kopieren Sie die Datei 'unit1.po' nach 'unit1.de.po'. Verwenden Sie dann einen Texteditor oder einen .po-Editor, um alle Zeichenketten zu übersetzen.
  • Die IDE lädt automatisch die .po-Dateien für installierte Packages, falls sie existieren. Für Beispiele siehe: lazarus/components/projecttemplates/languages/.
  • ToDo: Implementierung und Dokumentation über das Aktualisieren der übersetzten .po-Dateien, wenn neue Ressourcenstrings angefügt werden.
  • ToDo: Implementierung und Dokumentation über das Einsammeln aller .po-Dateien von statisch gelinkten Packages.


Ressourcenstrings in Ihrer Anwendung

Sie können die .po-Dateien bei der Initialisierung laden, um die Ressourcenstrings zu übersetzen. Fügen Sie dies Ihrer .lpr-Datei hinzu: 

...
uses
  ...
  Translations, LazUTF8;

procedure TranslateLCL;
var
  PODirectory, Lang, FallbackLang: String;
begin
  PODirectory:='/path/to/lazarus/lcl/languages/';
  Lang:='';
  FallbackLang:='';
  LazGetLanguageIDs(Lang,FallbackLang); // in der Unit LazUTF8
  Translations.TranslateUnitResourceStrings('LCLStrConsts',
                      PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
  // ... fügen Sie hier einen Aufruf von TranslateUnitResourceStrings für jede .po-Datei hinzu ...
end;

begin
  TranslateLCL;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Anmerkung für Mac OS X: Die IDs der unterstützten Sprachen sollten in der Eigenschaftenliste des Anwendungspakets zum Schlüssel CFBundleLocalizations hinzugefügt werden, für ein Beispiel siehe lazarus.app/Contents/Info.plist.

Die Funktion format()

Um in Übersetzungen nicht nur völlig statische Zeichenketten einzusetzen, können Sie auch die Methode format() aus der Unit 'sysutils' verwenden. Mit ihr können Sie Platzhalter innerhalb eines vorgegebenen Texts durch deren tatsächlichen Wert ersetzen, der als zweiter Parameter in einer Menge gegeben ist. Beispiel: 

format('Morgen am %0:s wird es %1:s geben.', ['Sonntag', 'Sonnenschein']);

liefert 

Morgen am Sonntag wird es Sonnenschein geben.

In diesem Fall steht %0:s als Platzhalter für das erste Argument (mit dem Index 0) aus der Wertemenge (Sonntag), und entsprechend %1:s für das zweite. Für eine exakte Definition der erlaubten Platzhalter und ihre Syntax siehe das FPC-Referenz-Handbuch.

Einige Richtlinien für den Gebrauch der Funktion format()

  • Verwenden Sie indizierte Platzhalter in den Originalstrings, auch wenn diese optional sind. Dies gestattet dem Übersetzer, die Argumente einfach innerhalb des Satzes zu verschieben und erlaubt somit natürlichere Ausdrücke. Und manchmal ist das Verschieben von Satzteilen auch tatsächlich erforderlich, um in dieser Sprache richtige Sätze bilden zu können.
  • Stellen Sie niemals einen Satz aus mehr als einem String zusammen. Nehmen Sie immer die Methode format() aus der Unit 'sysutils', um während der Laufzeit den richtigen String mittels Platzhaltern zu konstruieren. Ein Übersetzer würde normalerweise den ganzen Satz gar nicht rekonstruieren können, deshalb gäbe es auch keine gute Übersetzung; bedenken Sie nur einmal, dass oft Hunderte von solchen Strings in einer einzelnen Übersetzungsdatenbank vorkommen...
  • Verwenden Sie zum Formatieren keine Leerzeichen. Bewegen Sie als erstes einfach Ihr Label an die passende Position. Es ergeben sich sonst Probleme beim Wechseln der Schriftart, und scheinbar überflüssige Leerzeichen laufen Gefahr, vom Übersetzer weggeputzt zu werden.

Anmerkung: Da format() bestimmte Steuerzeichen (z.B. wie C's "\n", "\t", u.s.w.) nicht versteht und GNU gettext aus bestimmten Gründen das gewählte Übersetzungssystem (und die darauf basierenden Werkzeuge nicht fähig sind, solche Steuerzeichen zu interpretieren), ist es erforderlich, die Zeilenvorschübe programmatisch einzufügen.In der aktuellen Version von Lazarus werden "\n" und "\t" in übersetzten Zeichenketten durch newline und tab ersetzt.

Konvertierung der Übersetzung in den richtigen Zeichensatz

Zum Beispiel: wandeln Sie eine Datei von ISO-8859-1 zu UTF-8 um: 

 iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile.po > newfile.po

Vergessen Sie nicht die Zeile 

 "Content-Type: text/plain; charset=ISO-8859-1\n"

zu ändern in 

 "Content-Type: text/plain; charset=UTF8\n"

Aufs Englische bezogen

Dieser Abschnitt enthält Anmerkungen, die besonders dann Berechtigung haben, wenn Sie Englisch als Ausgangssprache für Übersetzungen benutzen.

  • Reservieren Sie dort, wo der Text ausgegeben wird, genug Platz: Englisch ist eine Sprache in der die Texte fast immer kürzer sind (was die Zeichenanzahl betrifft) als in den jeweiligen Übersetzungen. Planen Sie also voraus und reservieren Sie ausreichend Platz. Die Erfahrung zeigt, dass sehr kurze Strings, die nur wenige Zeichen lang sind, sich im Umfang ungefähr verdoppeln; dieser Unterschied nimmt ab, wenn die Zeichenketten länger sind.
  • Vermeiden Sie im Englischen Abkürzungen; neben der Tatsache, dass dadurch schon recht kurze Strings noch weiter gekürzt werden, entstehen auch ernste Probleme z.B. in Sprachen mit ideographischen Zeichen, wo diese Abkürzungen einfach überhaupt nicht existieren.
  • Weil dies oft ein Problem darstellt: Im Englischen sind Satzzeichen (Punkt, Komma, ...) ein Teil des vorherigen Wortes, oder bilden selbst eine Art Wort falls es kein vorhergehendes Wort gibt (im Fall einer Aufzählung). Besonders nach einem Strichpunkt sollte immer ein Leerzeichen folgen.
There was an error ! Please check file settings , compiler settings,... to fix this issue.

hat eine entsetzliche Interpunktion, sieht deshalb einfach schlecht aus und ist schwerer zu lesen als gewohnt. Bedenken Sie auch, dass übliche Algorithmen zum Zeilenumbruch die Zeilen an den Leerzeichen aufteilen, das würde in einem einzelnen Punkt am Zeilenanfang resultieren. 

There was an error! Please check file settings, compiler settings, ... to fix this issue.

wäre wahrscheinlich in Ordnung aus der Sicht der Interpunktion.

Siehe Auch

Retrieved from "https://wiki.freepascal.org/index.php?title=Getting_translation_strings_right/de&oldid=132225"