Land und Sprache gehören zu jenen Unterscheidungen, denen in der Theorie alle zustimmen und die im ersten Fixture verletzt werden. Eine Testmatrix wird als eine Zeile je Sprache geschrieben, jedem Eintrag wird ein Land angehängt, damit die Daten realistisch aussehen, und die beiden Achsen werden stillschweigend zu einer.
Dieser Beitrag zieht sie auseinander. Er beschreibt die drei Schichten, die das Wort Lokalisierung üblicherweise verdeckt, warum eine Sprachkennung und ein Regionscode verschiedene Aufgaben erfüllen und wie zwei Achsen beprobt werden, ohne sie für dieselbe Achse auszugeben.
Warum lassen sich Land und Sprache nicht voneinander ableiten?
Eine Sprache kann in vielen Ländern Amtssprache sein, und ein Land kann mehrere Amtssprachen haben. Beide Richtungen der Beziehung sind mehrdeutig, also bestimmt kein Wert den anderen.
Die Folge für das Testen ist unmittelbar. Wird jede Sprache mit genau einem Land gepaart, hat die Matrix eine diagonale Form: Sie enthält die Paare, die jemandem natürlich erschienen, und keine anderen. Die interessanten Fehler liegen abseits dieser Diagonalen – dieselbe Sprache, die ein anderes Format rendert, und dasselbe Format unter einer anderen Sprache.
Eine zweite Folge ist subtiler. Weil die Paare auf der Diagonalen kulturell vertraut sind für die Person, die die Matrix geschrieben hat, sind es zugleich die Paare, bei denen die Annahmen des Teams am ehesten zutreffen. Die Matrix ist genau dort am stärksten, wo sie am wenigsten gebraucht wird.
Lokalisierung besteht in Wahrheit aus drei Schichten
Behandeln Sie Lokalisierung als drei Entscheidungen, die zufällig dasselbe Wort teilen.
| Schicht | Die Frage, die sie beantwortet | Übliche Zuständigkeit |
|---|---|---|
| Oberflächensprache | In welcher Sprache stehen Beschriftungen, Schaltflächen und Meldungen? | Inhalt oder Produkt |
| Inhaltsregion | Welche Regeln, Preise und Angebote eines Marktes gelten? | Geschäft |
| Datenformat | Welche Konventionen bestimmen Datumsangaben, Zahlen, Namen und Adressen? | Daten oder Technik |
Jede Schicht lässt sich unabhängig setzen, und in realen Systemen geschieht genau das häufig. Eine Person kann in einer Sprache stöbern, die Regeln eines Marktes sehen, in dem sie gerade unterwegs ist, und eine Adresse eingeben, die den Konventionen eines dritten Ortes folgt.
Sobald die drei Schichten getrennt sind, werden die meisten Lokalisierungsfehler beschreibbar. Ein Fehler ist ein Fall, in dem zwei Schichten sich gemeinsam bewegen sollten und es nicht taten.
Sprachkennung und Regionscode leisten Verschiedenes
Eine Sprachkennung beschreibt Text. Sie sagt, in welcher Sprache eine Zeichenkette geschrieben ist, und manchmal auch, in welcher Schrift oder Variante. Ein Regionscode beschreibt die Konventionen, denen ein Wert folgt: wie ein Datum geordnet, wie eine Zahl gesetzt, wie ein Name aufgebaut wird.
Sie sind nicht austauschbar, und der eine ist keine genauere Fassung des anderen. Ein System, das nur eine Sprachkennung speichert, hat die Information weggeworfen, die zum Deuten eines Datums nötig ist; ein System, das nur einen Regionscode speichert, hat die Information weggeworfen, die zur Wahl eines Meldungskatalogs nötig ist.
Beides zu führen ist keine Redundanz, sondern das Minimum, um eine gerenderte Seite zu beschreiben. Der Fehler, auf den Sie achten sollten, ist die Abkürzung in die andere Richtung: die Sprachkennung als Schalter für die Datenformatierung zu verwenden. Das funktioniert genau so lange, bis das erste Land auftaucht, das sich eine Sprache mit einem anderen teilt.
Was bricht, wenn ein Format der Sprache folgt?
Der klassische Ausfall ist ein Wert, der gegen die Konventionen des falschen Landes geprüft wird, weil sich beide eine Sprache teilen. Die Sprache der Person ist korrekt gesetzt, die Formatregel wird aus dieser Sprache gewählt, und der Wert wird abgelehnt, obwohl er für das Land, in dem die Person tatsächlich lebt, wohlgeformt ist.
Es gibt leisere Varianten. Ein Namensfeld, das Bestandteile umsortiert, weil die Oberfläche in einer bestimmten Sprache ist, und nicht, weil der Datensatz zu einer Region mit dieser Reihenfolge gehört. Ein numerisches Feld, das ein Dezimaltrennzeichen aus der falschen Konvention annimmt und einen Wert speichert, der um Größenordnungen daneben liegt. Ein Datum, das an einer Stelle tagweise und an einer anderen monatsweise gedeutet wird und als plausibler, aber falscher Zeitpunkt in einem Bericht landet.
Nichts davon ist ein Sprachproblem. Es sind Fälle, in denen eine Regionsentscheidung von einer Spracheingabe getroffen wurde, und die Behebung ist strukturell und nicht eine bessere Nachschlagetabelle.
Wie sollte die Testmatrix zwei Achsen beproben?
Beproben Sie jede Achse zu ihren eigenen Bedingungen und kreuzen Sie dann eine kleine Zahl bewusst gewählter Kombinationen statt jeder Zelle.
Beginnen Sie mit der Sprachachse und wählen Sie Einträge, die sich darin unterscheiden, was die Oberfläche braucht: eine Sprache, die Text deutlich verlängert, eine, die eine andere Schrift erfordert, eine, deren Sortierregeln von der lateinischen Vorgabe abweichen. Nehmen Sie dann die Regionsachse getrennt und wählen Sie Einträge, die sich darin unterscheiden, was die Daten brauchen: eine Region, in der ein Feld nicht existiert, eine, in der ein Wert ungewöhnlich lang ist, eine, deren Konventionen einem Nachbarn widersprechen, der dieselbe Sprache spricht.
Die wichtigsten Kreuzungen sind die abseits der Diagonalen – dieselbe Sprache in zwei Regionen und zwei Sprachen in einer Region. Diese vier Zellen fangen die Fehlerklasse ab, die sich mit einem Paar aus Sprache und Land gar nicht ausdrücken lässt, und sie sind billig hinzuzufügen, sobald die Achsen getrennt gespeichert sind.
Für die sprachliche Seite, also wie sich Namen und Text je Locale verhalten, gibt es einen eigenen Leitfaden zu den Namensdaten je Locale, der bei der Sprachachse bleibt; dieser Beitrag hier handelt von der Regionsachse.
Für Entwickler: die Region bestimmt das Format
Speichern Sie beide Werte und seien Sie ausdrücklich dabei, welcher Wert welche Entscheidung steuert. Formatregeln sollten aus der Region gewählt werden, Meldungskataloge und Textlayout aus der Sprache, und keines von beiden sollte zur Renderzeit aus dem anderen abgeleitet werden.
Halten Sie die beiden Einstellungen an verschiedenen Stellen Ihrer Konfiguration, mit Namen, die sagen, was sie sind. Ein Feld namens locale, das eine Sprachkennung trägt, ist eine dauerhafte Einladung an die nächste Entwicklerin, es als Region zu verwenden. Ein Feld, das einen Regionscode trägt, sollte niemals als die Sprache beschrieben werden, die jemand spricht.
Sichern Sie die Trennung anschließend in Tests ab. Ein Test, der eine Sprache über mehrere Regionen rendert und eine Region über mehrere Sprachen, schlägt laut fehl, sobald jemand die Abkürzung wieder einführt. Das Länder- und Regionenverzeichnis und eine Länderseite wie der Eintrag zu Japan zeigen, wie die Konventionen eines einzelnen Landes beschrieben werden, wenn sie nebeneinander stehen – eine verlässlichere Referenz als ein Sprachname.
Nichts hier sollte als Beschreibung realen Verkehrs gelesen werden. Die als Beispiele verwendeten Kombinationen aus Sprache und Region sind konstruierte Stichproben und keine Beobachtungen einer realen Nutzerschaft; sie sagen nichts darüber aus, wo jemand lebt oder was jemand spricht.
Nächste Schritte
Schreiben Sie die drei Schichten für eine Bildschirmseite auf, die Ihr Team verantwortet, und benennen Sie den Wert, der jede von ihnen speist. Werden zwei Schichten von demselben Wert gespeist, haben Sie die Abkürzung gefunden. Der Leitfaden zum Testen von Länder-Auswahlfeldern führt die Regionsachse bis zu dem Bedienelement hinunter, das die Nutzerin tatsächlich anfasst, und der Leitfaden zu Ländergruppen und Marktstufen behandelt, wie Regionen selbst definiert werden.