Unterstützte Dateiformate¶

Weblate unterstützt eine Vielzahl von Übersetzungsformaten. Jedes Format unterscheidet sich geringfügig und bietet eine Reihe unterschiedlicher Funktionen.

Hinweis

Wenn Sie ein Dateiformat für Ihre Anwendung wählen, ist es besser, ein gut bewährtes Format in dem/der von Ihnen verwendeten Toolkit/Plattform zu verwenden. Auf diese Weise können Ihre Übersetzer zusätzlich die Tools verwenden, an die sie gewöhnt sind und werden eher zu Ihrem Projekt beitragen.

Siehe auch

Translation Related File Formats

Automatische Erkennung¶

Weblate versucht, das Dateiformat während Übersetzungsprojekte und Komponenten hinzufügen zu erkennen. Die Erkennung kann für verschiedene Varianten desselben Serialisierungsformats (JSON, YAML, properties) oder derselben Dateikodierung falsch sein. Bitte überprüfen Sie daher, ob das Dateiformat korrekt ist, bevor Sie die Komponente erstellen.

Fähigkeiten der Übersetzungstypen¶

Fähigkeiten aller unterstützten Formate¶
Format	Lingualität [1]	Pluralformen [2]	Beschreibungen [3]	Kontext [4]	Ort [5]	Markierungen [8]	Zusätzliche Status [6]
GNU gettext PO (Portable Object)	zweisprachig	ja	ja	ja	ja	ja [9]	bearbeitungsbedürftig
Gettext einsprachig	einsprachig	ja	ja	ja	ja	ja [9]	bearbeitungsbedürftig
XLIFF	beides	ja	ja	ja	ja	ja	bearbeitungsbedürftig, genehmigt
Java-Properties	beides	nein	ja	nein	nein	nein
draggable/i18n-lang-Datei	einsprachig	nein	ja	nein	nein	nein
GWT-Properties	einsprachig	ja	ja	nein	nein	nein
Joomla-Übersetzungen	einsprachig	nein	ja	nein	ja	nein
Qt Linguist .ts	beides	ja	ja	nein	ja	ja	bearbeitungsbedürftig
Android-Zeichenketten-Ressourcen	einsprachig	ja	ja [7]	nein	nein	ja
Apple-iOS-Zeichenketten	beides	nein	ja	nein	nein	nein
PHP-Zeichenketten	einsprachig	nein [10]	ja	nein	nein	nein
JSON-Dateien	einsprachig	nein	nein	nein	nein	nein
JSON-Dateien i18next	einsprachig	ja	nein	nein	nein	nein
JSON-Dateien go-i18n	einsprachig	ja	ja	nein	nein	nein
JSON-Dateien gotext	einsprachig	ja	ja	nein	ja	nein
ARB-Datei	einsprachig	ja	ja	nein	nein	nein
JSON-Datei WebExtension	einsprachig	ja	ja	nein	nein	nein
.NET-Ressourcendateien (RESX, RESW)	einsprachig	nein	ja	nein	nein	ja
ResourceDictionary-Dateien	einsprachig	nein	nein	nein	nein	ja
CSV-Dateien	beides	nein	ja	ja	ja	nein	bearbeitungsbedürftig
YAML-Dateien	einsprachig	nein	nein	nein	nein	nein
Ruby-YAML-Dateien	einsprachig	ja	nein	nein	nein	nein
DTD-Dateien	einsprachig	nein	nein	nein	nein	nein
Flache XML-Dateien	einsprachig	nein	nein	nein	nein	ja
Windows-RC-Dateien	einsprachig	nein	ja	nein	nein	nein
Excel Open XML	einsprachig	nein	ja	ja	ja	nein	bearbeitungsbedürftig
App-Store-Metadatendateien	einsprachig	nein	nein	nein	nein	nein
Untertiteldateien	einsprachig	nein	nein	nein	ja	nein
HTML-Dateien	einsprachig	nein	nein	nein	nein	nein
Markdown-Dateien	einsprachig	nein	nein	nein	nein	nein
OpenDocument-Format	einsprachig	nein	nein	nein	nein	nein
IDML-Format	einsprachig	nein	nein	nein	nein	nein
INI-Übersetzungen	einsprachig	nein	nein	nein	nein	nein
Inno-Setup-INI-Übersetzungen	einsprachig	nein	nein	nein	nein	nein
TermBase-eXchange-Format	zweisprachig	nein	ja	nein	nein	ja
Textdateien	einsprachig	nein	nein	nein	nein	nein
Stringsdict-Format	einsprachig	ja	nein	nein	nein	nein
Fluent-Format	einsprachig	no [11]	ja	nein	nein	nein

Zweisprachige und einsprachige Formate¶

Es werden sowohl einsprachige als auch zweisprachige Formate unterstützt. Zweisprachige Formate speichern zwei Sprachen in einer einzigen Datei – Quelle und Übersetzung (typische Beispiele sind GNU gettext PO (Portable Object), XLIFF oder Apple-iOS-Zeichenketten). Auf der anderen Seite identifizieren einsprachige Formate die Zeichenkette durch eine ID und jede Sprachdatei enthält nur die Zuordnung dieser zu einer bestimmten Sprache (typischerweise Android-Zeichenketten-Ressourcen). Einige Dateiformate werden in beiden Varianten verwendet, siehe die detaillierte Beschreibung unten.

Für die korrekte Verwendung einsprachiger Dateien benötigt Weblate Zugriff auf eine Datei, die eine vollständige Liste der zu übersetzenden Zeichenketten mit ihrem Quelltext enthält – diese Datei heißt in Weblate Einsprachige Basissprachdatei, obwohl die Benennung in Ihrem Paradigma abweichen kann.

Zusätzlich kann dieser Arbeitsablauf durch die Verwendung von einer Zwischensprachedatei erweitert werden, um von Entwicklern bereitgestellte Zeichenketten einzuschließen, die jedoch nicht in den endgültigen Zeichenketten verwendet werden sollen.

Zeichenkettenstatus¶

Viele Dateiformate unterscheiden nur zwischen den Zeichenketten „nicht übersetzt“ und „übersetzt“. Bei einigen Formaten ist es möglich, detailliertere Statusinformationen zu speichern, wie z. B. „bearbeitungsbedürftig“ oder „genehmigt“.

Beschreibung der Ausgangszeichenkette¶

Ausgangszeichenkettenbeschreibungen können verwendet werden, um zusätzliche Informationen über den zu übersetzenden Text zu übergeben.

Mehrere Formate bieten native Unterstützung für das Bereitstellen zusätzlicher Informationen für Übersetzer (zum Beispiel XLIFF, GNU gettext PO (Portable Object), JSON-Datei WebExtension, CSV-Dateien, Excel Open XML, Qt Linguist .ts, JSON-Dateien go-i18n, JSON-Dateien gotext, ARB-Datei, .NET-Ressourcendateien (RESX, RESW)). Viele andere Formate extrahieren den nächsten Kommentar als Ausgangszeichenkettenbeschreibung.

Erklärung¶

Die Erklärung für Zeichenketten kann aus einigen Dateiformaten gespeichert und analysiert werden.

Wird derzeit nur in TermBase-eXchange-Format unterstützt.

Ort der Ausgangszeichenkette¶

Der Ort einer Zeichenkette im Quellcode kann geübten Übersetzern helfen, herauszufinden, wie die Zeichenkette verwendet wird.

Diese Information ist in der Regel in zweisprachigen Formaten verfügbar, bei denen Zeichenketten mit Hilfe von Tools aus dem Quellcode extrahiert werden. Zum Beispiel GNU gettext PO (Portable Object) und Qt Linguist .ts.

Übersetzungsmarkierungen¶

Übersetzungsmarkierungen ermöglichen das Verhalten von Weblate anzupassen. Einige Formate unterstützen die Definition dieser in der Übersetzungsdatei (Sie können jederzeit in der Weblate-Oberfläche definiert werden, siehe Anpassen des Verhaltens mit Markierungen).

Diese Funktion ist den Markierungen in GNU gettext PO (Portable Object) nachempfunden.

Zusätzlich werden die Markierungen für alle XML-basierten Formate aus dem nicht standardisierten Attribut weblate-flags extrahiert. Zusätzlich wird max-length:N durch das maxwidth-Attribut unterstützt, wie im XLIFF-Standard definiert, siehe Angabe von Übersetzungsmarkierungen.

Siehe auch

Anpassen des Verhaltens mit Markierungen, PO-Dateien-Dokumentation

Kontext¶

Der Kontext wird verwendet, um identische Zeichenketten in einem zweisprachigen Format zu unterscheiden, die in verschiedenen Bereichen verwendet werden (z. B. kann Sun als abgekürzter Name des Tages „Sonntag“ oder als Name unseres nächstgelegenen Sterns verwendet werden).

Bei einsprachigen Formaten kann die Zeichenkettenkennung (oft als Schlüssel bezeichnet) denselben Zweck erfüllen und ein zusätzlicher Kontext ist nicht erforderlich.

Zeichenketten mit Pluralformen¶

Pluralformen sind notwendig, um Zeichenketten mit variabler Anzahl richtig zu lokalisieren. Die Regeln hängen von der Zielsprache ab und viele Formate folgen der CLDR-Spezifikation für diese Sprache.

Hinweis

Die Pluralbildung von Zeichenketten muss auch vom Anwendungsframework ordnungsgemäß unterstützt werden. Wählen Sie das native Format Ihrer Plattform wie GNU gettext PO (Portable Object), Android-Zeichenketten-Ressourcen oder Stringsdict-Format.

Schreibgeschützte Zeichenketten¶

Schreibgeschützte Zeichenketten aus Übersetzungsdateien werden einbezogen, können aber in Weblate nicht bearbeitet werden. Diese Funktion wird nur von wenigen Formaten (XLIFF und Android-Zeichenketten-Ressourcen) nativ unterstützt, kann aber in anderen Formaten durch Hinzufügen einer read-only-Markierung emuliert werden, siehe Anpassen des Verhaltens mit Markierungen.

Unterstützung anderer Formate¶

Die meisten von translate-toolkit unterstützten Formate, die Serialisierung unterstützen, können leicht unterstützt werden, aber sie wurden (noch) nicht getestet. In den meisten Fällen wird eine dünne Schicht in Weblate benötigt, um Unterschiede im Verhalten der verschiedenen translate-toolkit Speicher zu verbergen.

Um die Unterstützung für ein neues Format hinzuzufügen, ist der bevorzugte Ansatz, zuerst die Unterstützung für dieses Format in das translate-toolkit zu implementieren.

Siehe auch

Translation Related File Formats