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:

<Delphi>... uses

 ...
 Translations, LCLProc;

procedure TranslateLCL; var

 PODirectory, Lang, FallbackLang: String;

begin

 PODirectory:='/path/to/lazarus/lcl/languages/';
 Lang:=;
 FallbackLang:=;
 LCLGetLanguageIDs(Lang,FallbackLang); // in der Unit LCLProc
 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.</Delphi>

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()

To not only allow completely static strings in translations, you can use the format() method of the sysutils unit. It is able to replace placeholders within a given text by their actual value given as secondary parameter in a set. Example:

format('Tomorrow on %0:s there will be %1:s.', ['Sunday', 'sunshine']);

returns

Tomorrow on Sunday there will be sunshine.

In this case the %0:s is a placeholder for the first (index 0) argument in the set of actual values (Sunshine), and likewise %1:s. For an exact definition of the allowed placeholders and their syntax see the FPC reference manual.

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

  • Try to use indexed placeholders in the original strings, even if they are optional. When used, they allow the translator to move the arguments easily within the sentence allowing him more natural expressions (and actually sometimes moving sentence parts is required to create proper sentences in that language).
  • Never compose a sentence out of more than one string. Always use the format() method from the sysutils unit to construct the correct string using placeholders during runtime. Translators will usually not be able to reconstruct the whole sentence, therefore not able to give a good translation; only consider that there are often hundreds of such strings within a single translation database...
  • Do not format using whitespaces. Simply move your label to the appropriate position in the first place. There may be problems with font changes, and seemingly superfluous spaces will be in danger of being trimmed by the translator.

Note: Since format() does not interpret escaped control characters (e.g. like C's "\n", "\t", etc) and GNU gettext for any reason being the translation system of choice (and the tools based on it not being able to interpret non-escaped control characters), it is required to programmatically insert linebreaks.In the current lazarus version, "\n" and "\t" in translated strings are replaced by newline and tab.

Konvertierung der Übersetzung in den richtigen Zeichensatz

For example: converting a file from ISO-8859-1 to UTF-8:

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

Do not forget to change the line

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

to

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

Aufs Englische bezogen

This section contains notes which particularly apply when using English as the base language for translations.

  • Make sure to reserve enough space where the text is output: English is a language in which texts are almost always shorter (in characters) than their respective translations, so plan ahead by reserving enough space. Experience shows that very short strings of a few characters length often almost double in size; this difference decreases as the strings get longer.
  • Avoid abbreviations in English; in addition to the fact that this shortens the already short strings even more, there are severe problems with e.g. languages that use ideographic characters where these abbreviations simply do not exist at all.
  • Since this is often an issue: In English punctuation marks (full stop, comma, ...) are part of the previous words, or form some sort of words themselves if there is no previous word (in case of an enumeration). Especially after a semicolon there should always be a trailing space.
There was an error ! Please check file settings , compiler settings,... to fix this issue.

has horrible punctuation and therefore simply looks bad and is harder to read than usual. Consider that common line break algorithms break the line on whitespaces, possibly resulting in a single stop at the beginning of a line...

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

would probably be okay only considering punctuation.