Lokalisierungsdateien (Strings)

Lokalisierungsdateien sind Textdateien, die in einem Text Editor wie Notepad oder TextEdit oder einem der zahlreichen erweiterten Tools für die Textbearbeitung geöffnet und bearbeitet werden können. Diese Dateien folgen im Allgemeinen dem Key-Value-Prinzip. Das bedeutet, dass sie eine Liste von Text-Snippets (Strings) enthalten, die eindeutigen IDs (Keys) zugeordnet sind. Jede Zeichenfolge ist somit ein Wert eines Keys (Dieses einfache Beispiel ist das Format von Lokalisierungsdateien, die in der Java-Programmierung verwendet werden):

Erstellung von Lokalisierungsdateien

Lokalisierungsdateien sind Klartextdateien mit einer einfachen Struktur. Sie können manuell erstellt werden, werden aber in der Regel automatisch von Internationalisierungsprogrammen oder Skripten generiert, die für verschiedene Entwicklungsumgebungen verfügbar sind. Die automatische Erstellung von Lokalisierungsdateien stellt die Gültigkeit von Dateistrukturen sicher.

Um eine Lokalisierungsdatei zu erstellen, werden alle darstellbaren Texte durch eindeutige IDs in den Codedateien ersetzt. Die Text Strings werden dann mit ihren IDs zur Lokalisierungsdatei hinzugefügt.

Lokalisierungsdateien verwenden

Anstelle der eigentlichen Text Strings enthält der Code jetzt nur Keys. Wenn die Software eine Ansicht für den User erstellt, werden diese Schlüssel verwendet, um die zugehörigen Strings in der Lokalisierungsdatei nachzuschlagen.

Wenn eine Anwendung für die Verwendung in Englisch und Spanisch festgelegt ist, kann jeder englische Text in einer Datei namens English.txt gespeichert werden und ist der Standardtextspeicherort. Wenn ein User keine Sprache auswählt, wird der gesamte Text aus dieser Datei extrahiert, um eine beliebige Anzeige zu erzeugen. Wenn der User Spanisch wählt, wird die Software auf spanisch.txt umgeleitet. Mit einem solchen System können viele Sprachen verwendet werden.

Der Vorteil ist, dass die Wahl der Sprache für die Anzeige den Code nicht beeinflusst. Wenn die Software eine Anmelde-Schaltfläche anzeigen muss, benötigt sie möglicherweise die Zeichenfolge, die der Key login_Schaltfläche zugeordnet ist, und muss nur wissen, in welcher Datei sie suchen soll, um die entsprechende Zeichenfolge für die bestimmte Sprache abzurufen.

Zeichenfolge

Als Key-basierte Übersetzungsplattform unterstützt phrase viele verschiedene Ressourcendateitypen. Nach dem werden die Keys und deren zugehörige Zeichenfolge extrahiert. Die Keys und Strings werden dann dem Übersetzer in einem standardisierten Format präsentiert. Übersetzer konzentrieren sich auf ihre Aufgabe, ohne sich Gedanken über das genaue Format der Lokalisierungsdatei machen zu müssen. Sie können die Keys inspizieren, da der Key selbst den entscheidenden Kontext liefern und sie zur richtigen Wortwahl führen kann.

Wenn alle Strings übersetzt sind, werden Dateien heruntergeladen. Dabei werden die erforderlichen Formate für die Lokalisierungsdatei erstellt, die mit dem Match der ursprünglichen Ausgangssprache übereinstimmen.

Dateiformate für Ressourcen

Es werden vier verschiedene Arten von Ressourcen unterstützt, die alle im Wesentlichen textbasiert sind und in einem Text Editor geöffnet und geprüft werden können.

Tabellen

.XLSX- und .CSV-Dateien werden unterstützt. Diese Formate sind für Lokalisierungszwecke gleichwertig und enthalten Zeilen von Key-Value-Paaren. Die Keys befinden sich in einer Zeile, während die entsprechenden Werte in einer benachbarten Zeile liegen. Welche Spalte genau für welchen Zweck verwendet wird, hängt von der Anwendung ab. Ein Lokalisierungsspezialist muss phrase konfigurieren, um die Spalten korrekt zu interpretieren. Zendesk .CSV-Dateien haben eine feste Struktur, so dass für diesen Dateityp keine weiteren Anpassungen erforderlich sind:

"Titel","Standardsprache","Standardtext","englischer Text","Status Variante"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

XML ist ein Format, das Metainformationen in Form von <tags> anbietet. Die Struktur des Tags wird verwendet, um zu bestimmen, wo sich die Keys und ihre entsprechenden Werte befinden, wie hier aus einer Android-XML-Datei hervorgeht:

 <Zeichenfolge="simple_Key">Nur ein Key mit einer Nachricht.</Zeichenfolge>

Zwei Standard-XML-Übersetzungsformate sind .TMX und .XLIFF. Diese enthalten nicht nur Keys und Werte in einer Sprache, sondern ordnen auch Wertepaaren aus einer Ausgangssprache entsprechende Werte aus einer Zielsprache zu. Solche Dateien sind in der Regel zweisprachig, wie diese Übersetzungseinheit in einer Symfony Xliff-Datei zeigt:

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source
<Zielsprache xml:lang="en-GB">Nur ein einfacher Key mit einer einfachen Nachricht.</Zielsprache>
</trans-unit>

QT-Programme verwenden Ressourcendateien mit einer Struktur, die diesen standardisierten Formaten sehr ähnlich ist, aber aus historischen Gründen ein anderes Layout hat.

Plain Key-Value-Listen

Es gibt Ressourcendateien, die nur einfache Auflistungen von Keys und Werten enthalten, wie dieses Snippet aus einem Ruby on Rails YAML zeigt:

simple_key: Nur ein einfacher Key mit einer einfachen Nachricht.

Viele verschiedene Programmiersprachen oder Plattformen verwenden solche Formate mit Niedrigen Layoutunterschieden.

Da es sich um einsprachige Dateien handelt, muss ein Lokalisierungsprogramm parallele Versionen dieser Dateien pflegen – eine für die Ausgangssprache und andere für die Zielsprache.

Gettext erstellt Key-Value-Dateien mit zusätzlichen Informationen wie beschreibenden Kommentaren oder Pluralvarianten:

# Dies ist die erstaunliche Beschreibung für diesen Key!
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Schaut euch das an! This key has a description! (At least in some formats)"
msgstr[1] "Schaut euch das an! Dieser Key hat %s Beschreibungen! (At least in some formats)"

Es gibt konkurrierende Formate mit ähnlichen Funktionen und Layouts, die sich relativ Niedrig unterscheiden.

Assoziative Arrays

Während andere Formate angepassten Code (Parser) erfordern, um sie zu lesen, sind einige Formate für Entwickler und Lokalisierungsspezialisten einfacher. Formate, die auf .JSON- (JavaScript) und PHP-Arrays basieren, können gelesen und direkt in gängige Codestrukturen (Arrays) zugeordnet werden, die einfach zu manipulieren sind. Arrays können komplex sein und verschiedene Anwendungen generieren benutzerdefinierte Arraystrukturen.

Beispiel: go-i18n JSON bezeichnet Keys als ID:

{
    "id": "simple_key",
    "translation": "simple key, simple message, so simple."
},

Angular verwendet die Keys selbst als Keys in seinen Arrays:

"simple_key": "Ich bin ein einfacher Key mit einer einfachen Nachricht."

Da es diese Niedrig, aber entscheidenden Unterschiede gibt, werden weit verbreitete .JSON- und PHP-Array-Strukturen unterstützt.