Help:Extension:Translate/File format support/de

FFS steht für Dateiformatunterstützung (englisch file format support). Dies ist der allgemeine Name für eine Gruppe von Klassen für das Lesen und Bearbeiten übersetzter Nachrichten in verschiedenen Dateiformaten in der Übersetzungserweiterung.

Softwareentwickler haben mit Lokalisierungstechnologien das Rad viele Male neu erfunden, sodass es viele unterschiedliche Formate zum Speichern übersetzbarer Softwarenachrichten gibt. Es gibt zwei Hauptgruppen dieser Formate.


 * Schlüsselbasierte Formate: jede Nachricht hat einen Schlüssel, bei dem es sich um eine mehr oder weniger bedeutungsvolle Zeichenkette handelt. Die Übersetzung in jede Sprache ist ein Plan von Schlüsseln, die auf Werte verweisen. Die meisten Formate fallen in diese Gruppe, darunter DTD, JSON und das bis 2014 verwendete alte MediaWiki-Format (im Wesentlichen ein PHP-Array).
 * Gettextähnlich: Die Nachricht in der Originalsprache des Programms, normalerweise Englisch, wird selbst als Schlüssel genutzt, der auf Übersetzungen in andere Sprachen verweist. Dies erfordert die Erstellung inhärenter nicht-stabiler Pseudoschlüssel für das Speichern der Nachrichten in einem anderen Format.

Einführung in die FFS-Klassen
Bis auf einige Ausnahmen leiten sich die meisten FFS-Klassen von der FFS-Oberfläche ab, die die grundlegenden Methoden definiert, die jede Klasse implementieren muss:


 * : Setter für den Dateinamen.
 * : Getter für den Dateinamen.
 * : Liest die Nachrichten aus der Datei und analysiert sie.
 * : Liest die Nachrichten aus einer Zeichenketten-Variable, die das gleiche Format wie die Datei hat und sie als Array aus AUTHORS (Autoren) und MESSAGES (Nachrichten) ausgibt.
 * : Schreibt die Nachrichten in die Datei.
 * : Schreibt die Nachrichten in eine Zeichenketten-Variable, die das gleiche Format wie die Datei hat. Hier wird die ausgegebene Nachrichtendatei erstellt.

MediaWiki-Übersetzungen
Klassen zum Speichern von MediaWiki-Übersetzungen werden derzeit nicht von Varianten der FFS-Oberfläche verwaltet, sondern über unabhängige Klassen: es gibt Konfigurationsanweisungen. Neue FFS-ähnliche Klassen werden entwickelt.

SimpleFFS-Klasse
Die Klasse SimpleFFS ist der Ursprung aller FFS-Klassen und ein einfaches Beispiel dafür, wie eine FFS-Klasse geschrieben werden sollte. Sie implementiert ein vereinfachtes schlüsselbasiertes Format:


 * jede Datei besteht aus zwei Abschnitten, getrennt durch "\0\0\0\0";
 * ein Abschnitt enthält die Namen der Übersetzer, getrennt durch "\0";
 * der andere enthält die Übersetzungen im Format "key=value", ebenfalls getrennt durch "\0".

Da SimpleFFS bewusst einfach gehalten ist, ist es für Fehler und Komplikationen anfällig. So wird das Zeichen "=" nicht maskiert, sodass der Schlüssel und der Wert es nicht enthalten dürfen. Das eignet sich für Programme der realen Welt offensichtlich nicht. SimpleFFS implementiert auch einige nützliche Werkzeuge:


 * : Überprüft, ob die Datei existiert.
 * : Implementiert abgesehen von der generischen writeIntoVariable Einsetzelemente für das Schreiben in dem Dateiformat.
 * : Filtert nach einer benutzerdefinierten Blacklist bestimmte Autoren aus der Datei. Dies ist nützlich, um beispielsweise die Benutzernamen von Bots, Entwicklern und Übersetzungsadministratoren herauszufiltern.
 * : Repariert alle Zeilenenden im Unix-Stil.

Schreiben neuer FFS-Klassen
Alle oben angegebenen SimpleFFS-Methoden können überschrieben werden. Die meisten Implementierungen müssen jedoch nur  und   implementieren.

Allgemeine Hinweise zum Schreiben neuer Klassen:


 * Vermeide es, ausführbare Dateiformate auszuführen. Parse sie.
 * Remember to mangle and unmangle message keys.
 * Do not assume message keys don't include problematic characters. They will.
 * The output is usually expected to be pretty and readable. Some people like to poke in them manually.
 * Most formats don't support fuzzy markers, some add them as comments on export only and ignore them on import.

Supported file formats
The existing FFS classes are:


 * AndroidXml – for use in Android apps
 * AppleFFS – for iOS/Mac OS X Localizable.strings
 * Dtd – for DTD-based projects, like Okawix and Mozilla.
 * FlatPhpFFS – for future use in MediaWiki
 * Gettext – for Gettext-based projects
 * Ini – for INI-based projects
 * JavaScript – for all JavaScript formatted files
 * Java properties – for *.properties files, used in some Java and JavaScript projects, often along with Dtd
 * Json – used in jquery.i18n based projects, such as the portable Universal Language Selector library
 * Yaml – used in Waymarked Trails
 * Ruby (Yaml) – used in OpenStreetMap and Shapado
 * AMD i18n bundle

Examples of Translate exports in those formats are available at translatewiki.net.



Mangling the message keys to ensure correct title handling
The Translate extension is MediaWiki-based and every message is stored as a MediaWiki page, so the key must be a valid MediaWiki page title. Mangling takes care of this by escaping the key names a manner similar to the quoted-printable encoding, but with some modifications before storing the message as a wiki page. Before the message is written back to the file, the message is unmangled.

When an FFS class overrides the functions that call the mangling routines, it must make sure the roundtrip is done correctly – that is, that the key is mangled before writing to MediaWiki and unmangled before writing the translation back to the file.

Mangling is done in the  class.

Testing FFS classes
If you create a new FFS class, create a corresponding testing file in the tests directory. The important things to test are:


 * Parsing of the format: Essentially testing that the  function returns the right keys and values for AUTHORS and MESSAGES.
 * Roundtrip: Test that the keys and the messages are written and read correctly.

You can use existing test routines, such as JavaFFSTest, as examples.