Lokalisierbaren Code schreiben

  • Adressname der Version: Lokalisierbaren_Code_schreiben
  • Titel der Version: Lokalisierbaren Code schreiben
  • ID der Version: 114589
  • Erstellt:
  • Autor: René Schwarz
  • Aktuelle Version? Nein
  • Kommentar Fehler beim Verlinken

Inhalt der Version

Diese Seite beschreibt die besten Praktiken im Umgang mit Code der Benutzeroberflächen hinsichtlich derer Lokalisierung. Gedacht ist diese Seite für Entwickler von Mozilla und Erweiterungen.

Für weitere technische Details schauen Sie bitte auch in das XUL Tutorial (Kapitel Lokalisierung).

Diese Seite ist ein Entwurf, übersetzt von dem {{ mediawiki.interwiki('en', 'Writing_localizable_code', 'englischen Original') }}.


Über Übersetzer

Ein paar kurze Bemerkungen über Übersetzer für Entwickler, die nur selten mit ihnen zu tun haben:

  • Übersetzer mögen Tools, nicht aber Editoren,
  • Übersetzungstools sind basieren oft auf Schlüsseln (keys) mit ihren zugehörigen Übersetzungen (values),
  • zu guter letzt sind einige Übersetzer fokusiert auf ihre Sprachfähigkeiten and meistens nicht firm mit Programmierung oder gar in dem Kompilieren von Anwendungen.

Richtlinien

Es existieren einige Richtlinien, an die sich Entwickler halten sollten, um ihren Code besser lokalisierbar zu machen.

gute Schlüsselnamen (key names) wählen 
Der gewählte Name für einen Schlüssel (egal ob es eine DTD oder eine properties-Datei ist) sollte selbstbeschreibend sein. Wenn Sie die Semantik eines lokalisierten Strings ändern, so ändern Sie auch den zugehörigen Schlüssel. Dies wird den String besser beschreiben und Übersetzungstools helfen zu erkennen, dass die Veränderung nicht lediglich die Korrektur eines Sprachfehlers ist.
zusammengesetzten Strings keine Grammatik untermischen 
Das unachtsame Aufsplitten von Sätzen induziert meistens eine Grammatik und Satzstruktur, die meistens schwierig zu übersetzen ist und eventuell auf andere Sprachen nicht zutrifft. Vermeiden Sie daher wenn möglich das Aufsplitten von Sätzen; wenn es allerdings unvermeidbar sein sollte, dann lassen Sie dem Übersetzer einen Freiraum. Ein Beispiel für einen bedacht zusammengesetzten String ist Firefox's Einstellungsfeld für besuchte Seiten: Der Übersetzer kann ohne weiteres die Position des Textfeldes verändern.
preprocessor macros nicht verwenden 
Wir bitten darum weder #if, #else, #endif noch #expand zu verwenden. Es gibt einige Einwände gegen diese Vorgehensweise, aber hauptsächlich geht es darum, dass die lokalisierte Datei mit Standards harmonieren solte und nicht erst durch Compilierer umgewandelt werden muss. Wenn Ihre lokalisierten Dateien mit kompiliert werden müssen, so kontaktieren Sie vorher bitte {{ mediawiki.interwiki('en', 'user:AxelHecht', 'l10n@') }}. In den meisten Fällen kann der zu kompilierende Code einfach in den Code des Inhalts eingesetzt und unterschiedliche Übersetzungsschlüssel (key-value-pairs) referenziert werden.
eine gute source directory - Struktur verwenden 
Legen Sie die lokalisierbaren Dateien am richtigen Ort ab. Das Hinzufügen neuer Toplevel-Verzeichnisse ist ein Kompromiss zwischen Modulbesitz im cvsroot repository und der Einfachheit der Lokalisierung.

{{ QA_unvollständig("* Übersetzung nicht abgeschlossen") }}

{{ languages( { "en": "en/Writing_localizable_code", "fr": "fr/\u00c9criture_de_code_localisable" } ) }}

Quelltext der Version

<p>Diese Seite beschreibt die besten Praktiken im Umgang mit Code der Benutzeroberflächen hinsichtlich derer Lokalisierung. Gedacht ist diese Seite für Entwickler von Mozilla und Erweiterungen.
</p><p>Für weitere technische Details schauen Sie bitte auch in das <a href="de/XUL_Tutorial/Localization">XUL Tutorial (Kapitel Lokalisierung)</a>.
</p><p><b>Diese Seite ist ein Entwurf</b>, übersetzt von dem {{ mediawiki.interwiki('en', 'Writing_localizable_code', 'englischen Original') }}.
</p><p><br>
</p>
<h3 name=".C3.9Cber_.C3.9Cbersetzer"> Über Übersetzer </h3>
<p>Ein paar kurze Bemerkungen über Übersetzer für Entwickler, die nur selten mit ihnen zu tun haben:
</p>
<ul><li> Übersetzer mögen Tools, nicht aber Editoren,
</li><li> Übersetzungstools sind basieren oft auf Schlüsseln (<i>keys</i>) mit ihren zugehörigen Übersetzungen (<i>values</i>),
</li><li> zu guter letzt sind einige Übersetzer fokusiert auf ihre Sprachfähigkeiten and meistens nicht firm mit Programmierung oder gar in dem Kompilieren von Anwendungen.
</li></ul>
<h3 name="Richtlinien"> Richtlinien </h3>
<p>Es existieren einige Richtlinien, an die sich Entwickler halten sollten, um ihren Code besser lokalisierbar zu machen.
</p>
<dl><dt> gute Schlüsselnamen (<i>key names</i>) wählen </dt><dd> Der gewählte Name für einen Schlüssel (egal ob es eine DTD oder eine properties-Datei ist) sollte selbstbeschreibend sein. Wenn Sie die Semantik eines lokalisierten Strings ändern, so ändern Sie auch den zugehörigen Schlüssel. Dies wird den String besser beschreiben und Übersetzungstools helfen zu erkennen, dass die Veränderung nicht lediglich die Korrektur eines Sprachfehlers ist.
</dd><dt> zusammengesetzten Strings keine Grammatik untermischen </dt><dd> Das unachtsame Aufsplitten von Sätzen induziert meistens eine Grammatik und Satzstruktur, die meistens schwierig zu übersetzen ist und eventuell auf andere Sprachen nicht zutrifft. Vermeiden Sie daher wenn möglich das Aufsplitten von Sätzen; wenn es allerdings unvermeidbar sein sollte, dann lassen Sie dem Übersetzer einen Freiraum. Ein Beispiel für einen bedacht zusammengesetzten String ist Firefox's Einstellungsfeld für besuchte Seiten: Der Übersetzer kann ohne weiteres die Position des Textfeldes verändern.
</dd><dt> <i>preprocessor macros</i> nicht verwenden </dt><dd> Wir bitten darum weder <code>#if</code>, <code>#else</code>, <code>#endif</code> noch <code>#expand</code> zu verwenden. Es gibt einige Einwände gegen diese Vorgehensweise, aber hauptsächlich geht es darum, dass die lokalisierte Datei mit Standards harmonieren solte und nicht erst durch Compilierer umgewandelt werden muss. Wenn Ihre lokalisierten Dateien mit kompiliert werden müssen, so kontaktieren Sie vorher bitte {{ mediawiki.interwiki('en', 'user:AxelHecht', 'l10n@') }}. In den meisten Fällen kann der zu kompilierende Code einfach in den Code des Inhalts eingesetzt und unterschiedliche Übersetzungsschlüssel (<i>key-value-pairs</i>) referenziert werden.
</dd><dt> eine gute <i>source directory</i> - Struktur verwenden </dt><dd> Legen Sie die lokalisierbaren Dateien am richtigen Ort ab. Das Hinzufügen neuer Toplevel-Verzeichnisse ist ein Kompromiss zwischen Modulbesitz im <code>cvsroot</code> repository und der Einfachheit der Lokalisierung.
</dd></dl>
<p>{{ QA_unvollständig("* Übersetzung nicht abgeschlossen") }}
</p>{{ languages( { "en": "en/Writing_localizable_code", "fr": "fr/\u00c9criture_de_code_localisable" } ) }}
Zu dieser Version zurücksetzen