1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
---
title: Lokalisierbaren Code schreiben
slug: Lokalisierbaren_Code_schreiben
tags:
- Lokalisierung
translation_of: Mozilla/Localization/Writing_localizable_code
---
<p>Diese Seite beschreibt Richtlinien im Umgang mit dem Code der Benutzeroberfläche unter Berücksichtigung der Lokalisierung. Diese Seite ist für Entwickler von Mozilla und Erweiterungen gedacht.</p>
<p>Für weitere technische Details finden sich im <a href="/de/XUL_Tutorial/Lokalisierung" title="de/XUL_Tutorial/Lokalisierung">XUL Tutorial</a> weitere Informationen.</p>
<h3 id="Über_Lokalisierer">Über Lokalisierer</h3>
<p>Einige Anmerkungen für Entwickler, die nur selten mit Übersetzer zu tun haben:</p>
<ul> <li>Übersetzer mögen Tools, nicht aber Editoren.</li> <li>Übersetzungstools sind basieren oft auf Schlüssel (<em>keys</em>) mit ihren zugehörigen Übersetzungen (<em>values</em>),</li> <li>Zumindest haben sich einige Übersetzer auf ihre Sprachfähigkeiten fokussiert und verfügen meist nicht über Programmierkenntnisse oder gar Kenntnisse über das Kompilieren von Anwendungen.</li>
</ul>
<h3 id="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 <em>„key names</em>“ 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 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><em>Keine „preprocessor macros“</em> 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 <a href="/User:AxelHecht" title="en/user:AxelHecht">l10n@</a>. In den meisten Fällen kann der zu kompilierende Code einfach in den Code des Inhalts eingesetzt und unterschiedliche Übersetzungsschlüssel (<em>key-value-pairs</em>) referenziert werden.</dd> <dt>Eine gute <em>„source directory</em>“ 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> <dt>Eine gute „chrome directory“ Struktur verwenden</dt> <dd>Für ein bestimmtes Modul <code>mod</code>, wurde der Zielpfad <code>jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd</code> getestet und hat sich als ein guter Ort für Dateien, die in <code><a class=" external" rel="freelink">chrome://mod/locale/foo.dtd</a></code> verlinkt werden, herausgestellt. Wird diese Verzeichnisstruktur verwendet, wird der Lokalisierungsprozess ohne den Quellcode vereinfacht und wird vor allem Autoren von Erweiterungen empfohlen. Ein <a href="/en/JAR_Manifests" title="en/JAR_Manifests">JAR Manifest</a> kann das noch vereinfachen.</dd>
</dl>
<h3 id="l10n_impact">l10n impact</h3>
<p>Bei geschlossenen Trees, gibt es die Regel keine <em>l10n-impact</em> Veränderungen einzureichen. Was bedeutet das? <em>l10n-impact</em> ist</p>
<ul> <li>jede Veränderung an <code>mozilla/@mod@/locales</code>; Lokalisierer finden Änderungen über Bonsai-Abfragen heraus, genau wie es jeder andere auch macht. Keine Änderung bedeutet, dass das Ergebnis der Abfrage leer ist.</li> <li>jede veränderte oder neue Verwendung von existierenden, lokalisierten Strings; Alles was einen QA-Ablauf auf einen der 40+ Lokalisierungen verursacht, ist <em>l10n-impact</em>.</li>
</ul>
<p>{{ languages( { "en": "en/Writing_localizable_code", "es": "es/Escribir_código_localizable" ,"fr": "fr/\u00c9criture_de_code_localisable" } ) }}</p>
|
