From 4b1a9203c547c019fc5398082ae19a3f3d4c3efe Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:41:15 -0500 Subject: initial commit --- files/de/lokalisierbaren_code_schreiben/index.html | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 files/de/lokalisierbaren_code_schreiben/index.html (limited to 'files/de/lokalisierbaren_code_schreiben/index.html') diff --git a/files/de/lokalisierbaren_code_schreiben/index.html b/files/de/lokalisierbaren_code_schreiben/index.html new file mode 100644 index 0000000000..9d8f8172aa --- /dev/null +++ b/files/de/lokalisierbaren_code_schreiben/index.html @@ -0,0 +1,22 @@ +--- +title: Lokalisierbaren Code schreiben +slug: Lokalisierbaren_Code_schreiben +tags: + - Lokalisierung +translation_of: Mozilla/Localization/Writing_localizable_code +--- +

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:

+ +

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

+ +

{{ languages( { "en": "en/Writing_localizable_code", "es": "es/Escribir_código_localizable" ,"fr": "fr/\u00c9criture_de_code_localisable" } ) }}

-- cgit v1.2.3-54-g00ecf