So wird’s gemacht: Vorbereiten für die Lokalisierung (HTML)

Artikel
01/29/2016

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation ]

Mit den folgenden Schritten und bewährten Methoden können Sie Ihre App für die Lokalisierung vorbereiten. Lesen Sie jedoch zuerst die Prüfliste für die Globalisierung, um sicherzustellen, dass Ihre App für andere Märkte, Regionen oder Sprachen bereit ist.

Anweisungen

Verwenden von Ressourcendateien und Qualifizierern

Geben Sie Zeichenfolgenressourcen in Ressourcendateien an. Weitere Informationen finden Sie unter Schnellstart: Übersetzen von UI-Ressourcen.

Geben Sie Bilddateien oder andere Dateiressourcen in deren Datei oder Ordner mit dem entsprechenden Sprachtag an. Berücksichtigen Sie, dass die Lokalisierung von Bildern, Audio und Video erhebliche Systemressourcen beansprucht. Verwenden Sie deshalb soweit möglich neutrale Medienobjekte. Weitere Informationen finden Sie unter So wird's gemacht: Benennen von Ressourcen mit Qualifizierern.

Hinzufügen von Kontextkommentaren

Fügen Sie den Ressourcendateien Ihrer App Lokalisierungskommentare hinzu. Die Kommentare können vom Lokalisierer gelesen werden und sollten Informationen zum Kontext enthalten, die als Hilfestellung für eine präzise Übersetzung der Ressourcen dienen. Die Kommentare sollten auch ausreichend auf Beschränkungen hinweisen, sodass die Übersetzung die Funktionalität der Software nicht beeinträchtigt. Optional können die Kommentare auch mit dem Tool Makepri.exe protokolliert werden.

Mit ResJSON können Metadaten in Felder aufgenommen werden, die mit einem Unterstrich beginnen, wie z. B. Kommentare:

{
    "String"  : "Hello World",
    "_String1.comment" : "This is a comment to the localizer"
}

Lokalisieren von Sätzen anstelle von Wörtern

Beispiel: "The {0} could not be synchronized."

Der Platzhalter "{0}" kann durch zahlreiche Wörter ersetzt werden, z. B. durch Termin, Aufgabe oder Dokument. Dieses Beispiel funktioniert zwar in der englischen Sprache, aber nicht in jedem Fall im entsprechenden deutschen Satz. Sie sehen, dass in den folgenden deutschen Sätzen einige der Wörter in der Vorlagenzeichenfolge ("Der", "Die", "Das") zum parametrisierten Wort passen müssen:

Englisch	Deutsch
The appointment could not be synchronized.	Der Termin konnte nicht synchronisiert werden.
The task could not be synchronized.	Die Aufgabe konnte nicht synchronisiert werden.
The document could not be synchronized.	Das Dokument konnte nicht synchronisiert werden.

Der folgende Satz ist ein weiteres Beispiel: "Remind me in {0} minute(s)." Zwar funktioniert "minute(s)" in Englisch, in anderen Sprachen sind vielleicht andere Begriffe nötig. Auf Polnisch heißt es je nach Kontext "minuta", "minuty" oder "minut".

Lokalisieren Sie den gesamten Satz, statt nur ein einzelnes Wort, um das Problem zu beheben. Auf den ersten Blick wirkt diese Lösung vielleicht nicht ganz so elegant und sieht nach überflüssiger Arbeit aus, die Gründe sprechen jedoch für sich:

Für alle Sprachen wird eine saubere Fehlermeldung angezeigt.
Lokalisierer müssen nicht nachfragen, womit die Zeichenfolge ersetzt wird.
Sie müssen keine kostspielige Codefehlerbehebung implementieren wenn ein solches Problem in der fertigen App auftaucht.

Sicherstellen der richtigen Parameterreihenfolge

Gehen Sie nicht davon aus, dass Parameter in allen Sprachen in der gleichen Reihenfolge auftreten. Beispiel: "Every %s %s". Dabei wird das erste "%s" durch den Monatsnamen und das zweite "%s" durch den Tag des Monats ersetzt. Dieses Beispiel funktioniert zwar in der englischen Sprache, aber nicht bei einer Lokalisierung ins Deutsche, da hier Tag und Monat eine umgekehrten Reihenfolge einnehmen.

Ändern Sie die Zeichenfolge in "Every %1 %2", um das Problem zu beheben. Die Reihenfolge ist dann je nach Sprache austauschbar.

Vermeiden einer zu starken Lokalisierung

Lokalisieren Sie bestimmte Zeichenfolgen, nicht Tags. Beachten Sie folgende Beispiele:

Zu stark lokalisierte Zeichenfolge	Richtig lokalisierte Zeichenfolge
<link>Nutzungsbedingungen</link>	Nutzungsbedingungen
<link>Datenschutzrichtlinie</link>	Datenschutzrichtlinie

Wenn das Tag "<link>" in die Ressourcen aufgenommen wird, wird es ebenfalls lokalisiert. Dadurch wird das Tag ungültig. Nur die Zeichenfolgen selbst dürfen lokalisiert werden. Betrachten Sie Tags generell als Code, der vom Lokalisierungsinhalt getrennt gehalten werden sollte. Lange Zeichenfolgen sollten jedoch Markup enthalten, um den Kontext zu wahren und eine Sortierung zu ermöglichen.

Keine Verwendung derselben Zeichenfolgen in unterschiedlichem Kontext

Es mag vernünftig erscheinen, eine Zeichenfolge mehrmals zu verwenden. Allerdings können erhebliche Lokalisierungsprobleme auftreten, wenn ein Wort oder Ausdruck mehrere Bedeutungen oder Kontexte besitzt.

Sie können Zeichenfolgen im gleichen Kontext mehrmals verwenden. Sie können z. B. die Zeichenfolge "Volume" sowohl für Soundeffekte als auch für die Lautstärke von Musik verwenden, da sich beides auf die Intensität von Tönen bezieht. Verwenden Sie dieselbe Zeichenfolge jedoch nicht für Festplattenvolumes, da sich hier Kontext und Bedeutung unterscheiden und das Wort anders übersetzt wird.

Ein weiteres Beispiel sind die Zeichenfolgen "on" und "off". Im Englischen können sich "on" und "off" auf das Ein- und Ausschalten von Flugzeugmodus, Bluetooth oder Geräten beziehen. Im Italienischen hängt die Übersetzung jedoch davon ab, was ein- und ausgeschaltet wird. Sie müssten für jeden Kontext ein Zeichenfolgenpaar erstellen.

Zudem können Zeichenfolgen wie "text" oder "fax" in der englischen Sprache als Verb und als Substantiv verwendet werden, was die Übersetzung erschweren kann. Erstellen Sie deshalb jeweils eine getrennte Zeichenfolge für das Verb und das Substantiv. Falls unklar ist, ob es sich um den gleichen Kontext handelt, gehen Sie auf Nummer sicher, und verwenden Sie getrennte Zeichenfolgen.

Identifizieren von Ressourcen mit eindeutigen Attributen

Bei Ressourcenbezeichnern wird zwischen Groß-/Kleinschreibung unterschieden, und die Bezeichner müssen pro Ressourcendatei eindeutig sein. Verwenden Sie beim Zugriff auf eine Ressource den Ressourcenbezeichner und nicht den tatsächlichen Wert der Ressource. Ressourcenbezeichner ändern sich nicht. Die tatsächlichen Werte der Ressource ändern sich hingegen je nach Sprache.

Wählen Sie aussagekräftige Ressourcenbezeichner, um für die Übersetzung einen weiteren Kontext bereitzustellen.

Ändern Sie die Ressourcenbezeichner nicht, nachdem die Zeichenfolgenressourcen zur Übersetzung weitergegeben wurden. Lokalisierungsteams verfolgen Ergänzungen, Löschungen und Updates an den Ressourcen anhand der Ressourcenbezeichner nach. Bei Änderungen an Ressourcenbezeichnern — auch "Resource Identifiers Shift" genannt — müssen die Zeichenfolgen neu übersetzt werden, da der Eindruck entsteht, es seien Zeichenfolgen gelöscht oder hinzugefügt worden.

Auswahl des richtigen Übersetzungsansatzes

Nachdem die Zeichenfolgen in Ressourcendateien untergliedert wurden, können sie übersetzt werden. Der ideale Zeitpunkt für die Übersetzung ist nach Fertigstellung der Zeichenfolgen im Projekt, was in der Regel gegen Projektende der Fall ist. Der Übersetzungsprozess kann auf unterschiedliche Weise gehandhabt werden. Die Vorgehensweise hängt vom Umfang der zu übersetzenden Zeichenfolgen ab, von der Anzahl der zu übersetzenden Sprachen und wie die Übersetzung erfolgt (intern oder über externe Auftragnehmer).

Überlegen Sie folgende Optionen:

Die Ressourcendateien können zur Übersetzung direkt im Projekt geöffnet werden. Dieser Ansatz funktioniert gut für Projekte mit nicht allzu vielen Zeichenfolgen, die in zwei oder drei Sprachen übersetzt werden müssen. Er könnte sich für Szenarien eignen, in denen ein Entwickler mehrere Sprachen spricht und die Übersetzung übernehmen kann. Dieser Ansatz ist schnell, erfordert keine Tools und minimiert das Risiko von falschen Übersetzungen. Er ist aber nicht skalierbar. Insbesondere kann es passieren, das die Ressourcen in verschiedenen Sprachen nicht mehr synchron sind, was eine mangelnde Benutzerfreundlichkeit und Verwaltungsprobleme zur Folge haben kann.
Die Zeichenfolgen-Ressourcendateien im XML- oder ResJSON-Textformat können für eine Übersetzung in einem beliebigen Texteditor weitergegeben werden. Die übersetzten Dateien werden anschließend zurück in das Projekt kopiert. Bei diesem Ansatz besteht das Risiko, dass der Übersetzer versehentlich XML-Tags bearbeitet. Allerdings kann die Übersetzung außerhalb des Microsoft Visual Studio-Projekts erfolgen. Dieser Ansatz funktioniert gut für Projekte, die in wenige Sprachen übersetzt werden müssen. Das XLIFF-Format ist ein XML-Format, das speziell für die Lokalisierung entwickelt wurde und von einer Reihe von Lokalisierungsanbietern und Lokalisierungstools unterstützt wird. Sie können mit dem Multilingual App Toolkit XLIFF-Dateien aus anderen Ressourcendateien (wie RESW oder RESJSON) erzeugen.

Lokalisierern müssen möglicherweise noch andere Dateien übergeben werden, wie Bild- oder Audiodateien. In der Regel wird davon abgeraten, Dateien mit kulturellem Bezug zu erstellen, da diese schwer zu lokalisieren sind.

Berücksichtigen Sie auch die folgenden Vorschläge:

Verwenden Sie ein Lokalisierungstool. Es gibt eine Reihe von Lokalisierungstools, mit denen Ressourcendateien analysiert werden können und die nur die Bearbeitung von übersetzbaren Zeichenfolgen für den Übersetzer zulassen. Das Risiko, dass ein Übersetzer versehentlich XML-Tags bearbeitet, ist somit geringer. Der Nachteil ist aber, dass neue Tools und Prozesse in den Lokalisierungsprozess eingebunden werden müssen. Ein Lokalisierungstool eignet sich für Projekte mit vielen Zeichenfolgen, aber wenigen Sprachen. Weitere Informationen finden Sie unter Multilingual App Toolkit.
Verwenden Sie einen Lokalisierungsanbieter. Wenden Sie sich an einen Lokalisierungsanbieter, wenn des Projekt viele Zeichenfolgen enthält und in viele Sprachen übersetzt werden muss. Ein Lokalisierungsanbieter kann Sie hinsichtlich der Tools und Prozesse beraten sowie die Ressourcendateien übersetzen. Diese Lösung ist ideal, stellt allerdings auch die teuerste Option dar und kann die Bearbeitungszeit für den übersetzten Inhalt verlängern.
Halten Sie die Lokalisierer informiert. Lassen Sie die Lokalisierer wissen, welche Zeichenfolgen Substantive oder Verben sind. Erklären Sie konstruierte Wörter mithilfe von Terminologietools. Halten Sie die Zeichenfolgen grammatikalisch korrekt, eindeutig und allgemein verständlich, um Missverständnisse zu vermeiden.

Zugriffstasten und Bezeichnungen

Die "Synchronisierung" der für die Barrierefreiheit verwendeten Zugriffstasten mit der Anzeige der lokalisierten Zugriffstasten stellt eine besondere Herausforderung dar, da beide Zeichenfolgenressourcen in getrennten Abschnitten kategorisiert sind. Folgen Sie unbedingt der unten dargestellten Implementierung, und kommentieren Sie die Bezeichnungszeichenfolge ausreichend, sodass sie mit der Definition der Zugriffstaste verknüpft werden kann.

<label id="theLabel" data-win-res="{accessKey: 'theLabelAccessKey'}" for="xPrinterRedirection" accessKey="L">The <u>L</u>abel</label>
<input type="checkbox" value="OFF" id="xPrinterRedirection" name="xPrinterRedirection" />

Formulieren Sie Kommentare etwa so: Make sure that <u>L</u> is synchronized with the access key "theLabelAccessKey"

Unterstützung von Furigana für sortierbare japanische Zeichenfolgen

Japanische Kanji-Zeichen weisen die Besonderheit auf, dass sie je nach Wort und Kontext ihrer Verwendung anders ausgesprochen werden. Bei der Sortierung japanisch bezeichneter Objekte (wie Anwendungsnamen, Dateien, Lieder usw.) führt das zu Problemen. In der Vergangenheit wurde japanisches Kanji normalerweise in einer maschinenlesbaren Anordnung, XJIS genannt, sortiert. Da es sich hierbei um keine phonetische Sortierung handelt, ist sie für menschliche Nutzer leider nicht hilfreich.

Furigana umgeht dieses Problem, da der Benutzer oder Ersteller die Phonetik für die verwendeten Zeichen angeben kann. Wenn Sie Furigana dem App-Namen wie folgt hinzufügen, können Sie sicherstellen, dass die App in der Liste an der richtigen Stelle aufgeführt wird. Wenn die UI-Sprache des Benutzers oder die Sortierreihenfolge auf Japanisch festgelegt ist und der App-Name Kanji-Zeichen ohne ergänzendes Furigana enthält, dann generiert Windows nach Möglichkeit die richtige Aussprache. Es ist jedoch möglich, App-Namen mit seltener oder spezieller Schreibweise stattdessen nach einer gebräuchlicheren Schreibweise zu sortieren. Deshalb empfiehlt es sich, bei japanischen Anwendungen (insbesondere wenn sie Kanji-Zeichen im Namen enthalten) eine Furigana-Version des App-Namens im Rahmen der japanischen Lokalisierung bereitzustellen.

Fügen Sie "ms-resource:Appname" als Paketanzeigenamen und den Anwendungsanzeigenamen hinzu.
Erstellen Sie einen Ordner „ja-JP“ unter „strings“, und fügen Sie zwei Ressourcendateien wie folgt hinzu:
```
strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw
```
In Resources.resw für ja-JP allgemein: Fügen Sie eine Zeichenfolgenressource für den App-Namen "希蒼" hinzu.
In Resources.altform-msft-phonetic.resw für japanische Furigana-Ressourcen: Fügen Sie einen Furigana-Wert für den App-Namen "のあ" hinzu.

Der Benutzer kann sowohl mit dem Furigana-Wert "のあ" (noa) als auch mit dem phonetischen Wert (mithilfe der GetPhonetic-Funktion aus dem Eingabemethoden-Editor (Input Method Editor, IME) "まれあお" (mare-ao) nach dem App-Namen "希蒼" suchen.

Die Sortierung folgt dem regionalen Format der Systemsteuerung:

Unter dem japanischen Benutzergebietsschema:
- Wenn Furigana aktiviert ist, wird "希蒼" unter "の" sortiert.
- Wenn Furigana fehlt, wird "希蒼" unter "ま" sortiert.
Unter nicht japanischem Benutzergebietsschema:
- Wenn Furigana aktiviert ist, wird "希蒼" unter "の" sortiert.
- Wenn Furigana fehlt, wird "希蒼" unter "漢字" sortiert.

Share via