Lokalisierbaren Code schreiben

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.

Für weitere technische Details finden sich im XUL Tutorial weitere Informationen.

Über Lokalisierer

Einige Anmerkungen für Entwickler, die nur selten mit Übersetzer zu tun haben:

• Übersetzer mögen Tools, nicht aber Editoren.
• Übersetzungstools sind basieren oft auf Schlüssel (keys) mit ihren zugehörigen Übersetzungen (values),
• 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.

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 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.

Keine „preprocessor macros“ 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 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.

Eine gute „chrome directory“ Struktur verwenden

Für ein bestimmtes Modul mod, wurde der Zielpfad jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd getestet und hat sich als ein guter Ort für Dateien, die in chrome://mod/locale/foo.dtd verlinkt werden, herausgestellt. Wird diese Verzeichnisstruktur verwendet, wird der Lokalisierungsprozess ohne den Quellcode vereinfacht und wird vor allem  Autoren von Erweiterungen empfohlen. Ein JAR Manifest kann das noch vereinfachen.

l10n impact

Bei geschlossenen Trees, gibt es die Regel keine l10n-impact Veränderungen einzureichen. Was bedeutet das? l10n-impact ist

• jede Veränderung an mozilla/@mod@/locales; Lokalisierer finden Änderungen über Bonsai-Abfragen heraus, genau wie es jeder andere auch macht. Keine Änderung bedeutet, dass das Ergebnis der Abfrage leer ist.
• jede veränderte oder neue Verwendung von existierenden, lokalisierten Strings; Alles was einen QA-Ablauf auf einen der 40+ Lokalisierungen verursacht, ist l10n-impact.