Lokalisierungsdateien (Strings)

Lokalisierungsdateien sind Textdateien, die in einem Texteditor wie Notepad oder TextEdit oder in einem der zahlreichen erweiterten Textbearbeitungswerkzeuge, die von Programmierern verwendet werden, geöffnet und bearbeitet werden können. Diese Dateien folgen im Allgemeinen dem Schlüssel-Wert-Prinzip. Das bedeutet, dass sie eine Liste von Textausschnitten (Strings) enthalten, die mit eindeutigen IDs (Schlüsseln) verknüpft sind. Jede Zeichenfolge ist somit ein Wert eines Schlüssels (Dieses einfache Beispiel ist das Format von Lokalisierungsdateien, das in der Java-Programmierung verwendet wird.):

Erstellung von Lokalisierungsdateien

Lokalisierungsdateien sind Textdateien mit einer einfachen Struktur. Sie können manuell erstellt werden, werden jedoch normalerweise automatisch von Internationalisierungswerkzeugen oder Skripten generiert, die für verschiedene Entwicklungsumgebungen verfügbar sind. Die automatische Erstellung von Lokalisierungsdateien stellt sicher, dass die Dateistrukturen gültig sind.

Um eine Lokalisierungsdatei zu erstellen, werden alle anzeigbaren Texte im Code durch eindeutige IDs ersetzt. Die Textzeichenfolgen werden dann mit ihren IDs in die Lokalisierungsdatei eingefügt.

Verwendung von Lokalisierungsdateien

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

Wenn eine Anwendung so eingerichtet ist, dass sie in Englisch und Spanisch verwendet wird, können alle englischen Texte in einer Datei namens English.txt gespeichert werden, die der Standardtextstandort ist. Wenn ein Benutzer keine Sprache auswählt, wird sämtlicher Text aus dieser Datei abgerufen, um eine Anzeige zu generieren. Wenn der Benutzer Spanisch auswählt, wird die Software auf Spanish.txt umgeleitet. Viele Sprachen können mit einem solchen System verwendet werden.

Der Vorteil ist, dass die Wahl der Sprache für die Anzeige den Code nicht beeinflusst. Wenn die Software einen Login-Button anzeigen muss, benötigt sie möglicherweise die Zeichenfolge, die mit dem Schlüssel login_button verknüpft ist, und muss nur wissen, in welcher Datei sie nach der entsprechenden Zeichenfolge für die gegebene Sprache suchen muss.

Zeichenfolgenverwaltung

Als schlüsselbasierte Übersetzungsplattform unterstützt Phrase viele verschiedene Ressourcendateitypen. Nachdem Dateien hochgeladen wurden, werden die Schlüssel und ihre zugehörigen Zeichenfolgenwerte extrahiert. Die Schlüssel und Zeichenfolgen werden dann dem Übersetzer in einem standardisierten Format präsentiert. Übersetzer konzentrieren sich auf ihre Aufgabe, ohne sich um das genaue Format der Lokalisierungsdatei kümmern zu müssen. Sie können die Schlüssel überprüfen, da der Schlüssel selbst entscheidenden Kontext bieten und sie zu den richtigen Wortwahl führen kann.

Wenn alle Zeichenfolgen übersetzt sind, werden die Dateien heruntergeladen. Im Prozess werden die benötigten Lokalisierungsdateiformate erstellt, die mit der ursprünglichen Quelldatei übereinstimmen.

Ressourcen Dateiformate

Vier breite Typen von Ressourcen werden unterstützt und sind alle im Wesentlichen textbasiert und können in einem Texteditor geöffnet und inspiziert werden.

Tabellenkalkulationen

.XLSX und .CSV-Dateien werden unterstützt. Diese Formate sind für Lokalisierungszwecke gleichwertig und enthalten Zeilen von Schlüssel-Wert-Paaren. Die Schlüssel befinden sich in einer Zeile, während die entsprechenden Werte in einer benachbarten Zeile stehen. Welche genaue Spalte 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, sodass dieser Dateityp keine weiteren Anpassungen erfordert:

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

XML

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

 <string name="einfacher_schlüssel">Einfacher Schlüssel mit einer Nachricht.</string>

Zwei Standard-XML-Übersetzungsformate sind .TMX und .XLIFF. Diese enthalten nicht nur Schlüssel und Werte in einer Sprache, sondern assoziieren auch Wertpaare 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="de-DE">Einfacher Schlüssel mit einer einfachen Nachricht.</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 haben.

Einfache Schlüssel-Wert-Listen

Es gibt Ressourcendateien, die nur einfache Auflistungen von Schlüsseln und Werten enthalten, wie dieser Ausschnitt aus einer Ruby on Rails YAML zeigt:

einfacher_schlüssel: Einfacher Schlüssel mit einer einfachen Nachricht.

Viele verschiedene Programmiersprachen oder Plattformen verwenden solche Formate mit geringfügigen Layoutunterschieden.

Da dies einsprachige Dateien sind, muss ein Lokalisierungsprogramm parallele Versionen solcher Dateien pflegen - eine für die Ausgangssprache und andere für die Zielsprache.

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

# Dies ist die erstaunliche Beschreibung für diesen Schlüssel!
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Schau es dir an!" Dieser Schlüssel hat eine Beschreibung! (Mindestens in einigen Formaten)"
msgstr[1] "Schau es dir an! Dieser Schlüssel hat %s Beschreibungen! (Mindestens in einigen Formaten)"

Es gibt konkurrierende Formate mit ähnlicher Funktionalität und Layouts, die sich in relativ geringfügigen Aspekten unterscheiden.

Assoziative Arrays

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

Zum Beispiel bezieht sich go-i18n JSON auf Schlüssel als id:

{
    "id": "simple_key",
    "translation": "einfacher Schlüssel, einfache Nachricht, so einfach."
},

Angular verwendet die Schlüssel selbst als Schlüssel in seinen Arrays:

"simple_key": "Ich bin ein einfacher Schlüssel mit einer einfachen Nachricht.".

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