Lokalisierungsdateien (Strings)

Lokalisierungsdateien sind Textdateien, die in einem Editor wie Notepad oder TextEdit oder einem der unzähligen erweiterten Tools zur Textbearbeitung, die von Programmierern verwendet werden, geöffnet und bearbeitet werden können. Diese Dateien folgen im Allgemeinen dem Key-Value-Prinzip. Dies bedeutet, dass sie eine Liste von Textausschnitten (Strings) enthalten, die eindeutigen IDs (Keys) zugeordnet sind. Jeder String ist somit ein Value eines Key (Dieses einfache Beispiel ist das Format von Lokalisierungsdateien, die in der Java-Programmierung verwendet werden.):

Erstellen von Lokalisierungsdateien

Lokalisierungsdateien sind reine Textdateien mit einer einfachen Struktur. Sie können manuell erstellt werden, werden aber normalerweise automatisch von Internationalisierungs-Dienstprogrammen oder Skripten generiert, die für verschiedene Entwicklungsumgebungen verfügbar sind. Das automatische Erstellen von Lokalisierungsdateien stellt sicher, dass Dateistrukturen gültig sind.

Um eine Lokalisierungsdatei zu erstellen, werden alle Teile des anzeigbaren Textes in den Codedateien durch eindeutige IDs ersetzt. Die Strings werden dann mit ihren IDs zur Lokalisierungsdatei hinzugefügt.

Verwenden von Lokalisierungsdateien

Anstelle der tatsächlichen Strings enthält der Code jetzt nur noch Keys. Wenn die Software eine Ansicht für den User generiert, werden diese Keys verwendet, um die zugehörigen Strings in der Lokalisierungsdatei nachzuschlagen.

Wenn eine Anwendung so festlegen ist, dass sie auf Englisch und Spanisch verwendet werden kann, kann der gesamte englische Text in einer Datei namens English.txt gespeichert werden und ist der Standard-Textspeicherort. Wenn ein User keine Sprache auswählt, wird der gesamte Text aus dieser Datei abgerufen, um eine Anzeige zu generieren. Wenn der User Spanisch auswählt, wird die Software zu Spanish.txt umgeleitet. Viele Sprachen können mit einem System wie diesem 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 mit dem Key login_button verknüpft ist, und muss nur wissen, in welcher Datei sie nachsehen muss, um die entsprechende Zeichenfolge für die gegebene Sprache abzurufen.

Zeichenfolge-Verwaltung

Als Key-basierte Übersetzungsplattform unterstützt Phrase viele verschiedene Ressourcen-Dateiformate. Nachdem Dateien hochgeladen wurden, werden die Keys und ihre zugehörigen Zeichenfolge-Werte extrahiert. Die Keys und Strings werden dem Übersetzer dann in einem standardisierten Format präsentiert. Übersetzer konzentrieren sich auf ihre Aufgabe, ohne sich um das genaue Format der Lokalisierungsdatei sorgen zu müssen. Sie können die Keys überprüfen, da der Key selbst entscheidenden Kontext liefern und sie bei der Wahl der richtigen Wörter unterstützen kann.

Wenn alle Strings übersetzt sind, werden die Dateien heruntergeladen. Dabei werden die benötigten Lokalisierungs-Dateiformate erstellt, die dem ursprünglichen Ausgangssprache-Dateiformat entsprechen.

Ressourcen-Dateiformate

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

Tabellenkalkulationen

.XLSX- und .CSV-Dateien werden unterstützt. Diese Formate sind für Lokalisierungszwecke gleichwertig und enthalten Zeilen mit Key-Wert-Paaren. Die Keys befinden sich in einer Zeile, während die entsprechenden Werte in einer angrenzenden Zeile stehen. Welche Spalte genau für welchen Zweck verwendet wird, hängt von der Anwendung ab, und ein Lokalisierer muss Phrase so konfigurieren, dass die Spalten korrekt interpretiert werden. Zendesk .CSV-Dateien haben eine feste Struktur, daher erfordert dieser Dateityp keine weiteren Anpassungen:

"Titel","Standardsprache","Standardtext","Englischer Text","Varianten-Status"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

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

 <string name="simple_key">Just a  key with a message.</string>

Zwei Standard-XML-Übersetzungsformate sind .TMX und .XLIFF. Diese enthalten nicht nur Keys und Werte in einer Sprache, sondern verknüpfen auch Wertepaare aus einer Ausgangssprache mit entsprechenden Werten aus einer Zielsprache. Solche Dateien sind typischerweise 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
<target xml:lang="en-GB">Just a simple key with a simple message.</target>
</trans-unit>

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

Einfache Key-Wert-Listen

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

simple_key: Just a simple key with a simple message.

Viele verschiedene Programmiersprachen oder Plattformen verwenden solche Formate mit Niedrigen Layout-Unterschieden.

Da es sich um einsprachige Dateien handelt, muss ein Lokalisierungsprogramm parallele Versionen solcher Dateien verwalten – eine für die Ausgangssprache und andere für die Zielsprachen.

Gettext erzeugt Key-Wert-Dateien, die zusätzliche Informationen enthalten, wie beschreibende Kommentare oder Pluralvarianten:

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

Es gibt konkurrierende Formate mit ähnlicher Funktionalität und Layouts, die sich in relativ Niedrigen Punkten unterscheiden.

Assoziative Arrays

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

Zum Beispiel bezieht sich go-i18n JSON auf 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": "I am a simple key with a simple message.".

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