Ich setze die Diskussion über die Vorteile von Fluent gegenüber dem üblichen gettext fort und veröffentliche die offizielle Position der Schöpfer von Fluent in der Übersetzung.
Gettext ist ein Lokalisierungssystem, das tief im GNU-Projekt und den damit verbundenen Architekturlösungen verwurzelt ist.
Das Fluent Project sieht in gettext ein gutes Beispiel für ein vollständiges plattformunabhängiges Ökosystem von Bibliotheken und Tools auf niedriger Ebene zur Verwaltung des gesamten Produktfreigabezyklus mit Lokalisierungsdateien in einem lesbaren Format. Gleichzeitig führt uns das Fluent-Paradigma zu anderen Architekturlösungen in wichtigen Lokalisierungsaspekten, die wiederum zu völlig unterschiedlichen APIs und Lebenszyklen führen.
Mit anderen Worten, gettext ist ein großartiges Projekt, aber wir teilen nicht seine Ansichten über den Ansatz der Lokalisierung.
Hier sind die Hauptunterschiede zwischen gettext und Fluent:
Anordnung
Der wichtigste Unterschied zwischen gettext und Fluent ist die Nachrichtenkennung. Gettext entschied sich, die Quellzeichenfolge (normalerweise in Englisch) als Kennung zu verwenden. Diese Wahl scheint einfach zu sein, bringt aber später viele Einschränkungen mit sich.
Erstens macht bei diesem Ansatz jede Änderung in der ursprünglichen Zeile alle damit verbundenen Übersetzungen ungültig. Dies erhöht die Belastung der Entwickler erheblich und zwingt sie, die ursprünglichen Nachrichten niemals zu ändern, da hierfür alle Übersetzungen aktualisiert werden müssen.
Zweitens erschwert es die Einführung mehrerer Nachrichten mit demselben Text in der Ausgangssprache, die auf unterschiedliche Weise übersetzt werden müssen. Beispielsweise kann der Text für die Schaltfläche „Öffnen“ und für die Markierung „Öffnen“ auf verschiedene Arten übersetzt werden, da der erste Text ein Befehl und der zweite eine Beschreibung ist. Gettext verfügt über eine optionale
msgctxt- Kontextzeile zur Unterscheidung zwischen Zeilen mit demselben Quellensegment. Dieser Ansatz überträgt die Verantwortung für das Erkennen solcher Situationen auf die Entwickler, was dem Prinzip der Interessentrennung widerspricht.
Fluent empfiehlt aus genau diesem Grund nicht, Texte wiederzuverwenden. Das Trennen des Quelltextes von anderen Übersetzungen ist auch wichtig für unsere Fähigkeit, zusammengesetzte Nachrichten einzugeben (die mehrere Zeilen für eine Übersetzungseinheit enthalten, die an ein Benutzeroberflächen-Widget angehängt sind) und für identifikatorbasierte Links zu Nachrichten.
Fluent stellt eine „Vereinbarung“ zwischen Entwicklern und Lokalisierern her. Der Entwickler gibt einen eindeutigen Bezeichner und eine Reihe von Variablen ein (Anzahl der ungelesenen Nachrichten, Benutzername usw.), und der Lokalisierer entscheidet mithilfe der Fluent-Syntax, wie der Nachrichtentext für diesen Bezeichner erstellt wird.
Der Entwickler sollte sich nicht um die detaillierte Implementierung von Übersetzungen solcher Nachrichten kümmern. Ein Entwickler muss lediglich eine einzelne Textzeile abrufen, die für eine bestimmte Stelle in der Benutzeroberfläche geeignet ist, um eine Zeichenfolge mit einer bestimmten Kennung anzufordern.
Nachrichtenoptionen
Gettext unterstützt eine kleine Reihe von Funktionen für die Internationalisierung, insbesondere für Pluralformen. Eine solche Plural-Syntax ist jedoch zusätzlich zur Standard-Gettext-Syntax ein Sonderfall, und es ist schwierig, sie für andere Fälle zu skalieren, die Variabilität erfordern.
Fluent unterstützt das Grundkonzept der Stringvariation, das mit Selektoren verwendet werden kann. Normalerweise ist die Pluralregel ein solcher Selektor, aber abhängig von den grammatikalischen Merkmalen der Sprache kann es andere geben, wie z. B. Geschlecht, Deklination oder sogar die Umgebung - zum Beispiel die Tageszeit oder das Betriebssystem. Mit der Fluent-Syntax können Locators alle diese Funktionen berücksichtigen und Text erstellen, der genau der Situation entspricht.
Externe Argumente
Gettext unterstützt keine externen Argumente. Mit anderen Worten, Sie können die Formatierung von Parametern - Zahlen, Datumsangaben - nicht angeben. Um Parameter in gettext zu formatieren, wird empfohlen, eine Zeichenfolge zurückzugeben, die an
printf übergeben wird, oder
String.prototype.replace für die resultierende Zeichenfolge
auszuführen .
In Fluent steht die Unterstützung externer Argumente im Mittelpunkt der Syntax. Externe Argumente werden nicht nur interpoliert, sondern auch als Parameter für den Selektor verwendet und können auch in integrierte Funktionen übertragen werden. Auf diese Weise können Lokalisierer für bestimmte Fälle viel genauere Texte erstellen. Darüber hinaus platziert Fluent
FSI / PDI- Markierungen um Objekte, um die Direktivitätsisolation in bidirektionalem Text zu schützen, und verhindert jegliche Manipulation von Blattzeichenfolgen, wodurch die Belastung für Entwickler verringert wird.
Isolation der Verantwortung
Darüber hinaus muss der Systemdesigner für die Art und Weise, wie gettext mit mehreren Regeln umgeht, auswählen, ob die Nachricht eine multivariate Nachricht oder eine einzelne Zeile sein soll. Aus Sicht von Fluent sollte sich der Entwickler nicht mit solchen Problemen befassen. In vielen Fällen, wenn eine Option auf Englisch ausreicht, müssen Sie in anderen Sprachen Varianten mit Pluralformen hinzufügen.
Fluent geht davon aus, dass der Entwickler bei der Entwicklung von Software mit vielen Gebietsschemas nicht über ähnliche Sprachkenntnisse verfügen sollte und dass jede Sprache während der Lokalisierung eine gewisse Handlungsfreiheit haben sollte.
Infolgedessen speichert Fluent jede Übersetzung separat, ohne die Anforderungen einer Sprache an andere weiterzugeben, und hält alle Übersetzungen für einen Entwickler „undurchsichtig“, der sich keine Gedanken darüber machen muss, welche Funktionen die Lokalisierer für eine bestimmte Zeile benötigen.
Stornierung einer Übertragung
Im Entwicklungszyklus gibt es drei Situationen, in denen die Übersetzung in Bezug auf das Original „abgebrochen“ wird (ungültig wird):
- Kleinere Änderung: Beeinflusst die Übersetzung nicht (korrekte Interpunktion, Tippfehler).
- Mittlere Änderung: Beeinflusst das Design der Nachricht, hebt jedoch nicht die Richtigkeit der zugehörigen Übersetzung auf (z. B. Alle Lesezeichen anzeigen -> Lesezeichen-Manager anzeigen ).
- Wesentliche Änderung: die neue Bedeutung des Satzes ( Klicken zum Speichern -> Klicken zum Öffnen ).
Aus architektonischen Gründen kombiniert gettext alle drei Ebenen in einem einzigen Zustand namens
Fuzzy . Jede Änderung der Quellzeile (zumindest vollständig, zumindest unbedeutend) führt zur Stornierung von Übersetzungen.
In Fluent können Sie durch die Verwendung eindeutiger Bezeichner zwei dieser Ebenen von der dritten trennen: Wenn Sie
kleine Änderungen am Quelltext einer Zeile vornehmen und den Bezeichner speichern, bleiben die Übersetzungen gültig. Wenn der Entwickler hingegen die Kennung ändert, werden alle Übersetzungen abgebrochen und müssen aktualisiert werden.
Wir glauben, dass eine solche Architekturlösung für die meisten Release-Zyklen vorteilhafter ist, obwohl wir anerkennen, dass der Entwickler bei Änderungen auf
mittlerer Ebene zwischen dem Speichern oder Ändern der Kennung (d. H. Zwischen einer
geringfügigen und einer
signifikanten Änderung) wählen muss.
Wir erwägen auch die Idee der Nachrichtenversionierung, damit der Entwickler die Nachricht als
aktualisiert markieren kann, ohne ihren Inhalt vollständig ungültig zu machen. In diesem Status können Sie die Übersetzung gültig halten, da die alte Version der Übersetzung immer noch besser ist als die nicht übersetzte Zeichenfolge. Gleichzeitig können die Tools den Localizer über die Notwendigkeit einer Aktualisierung der Übersetzung informieren.
Datenformat
Gettext verwendet drei Dateiformate - * .po, * .pot und * .mo. Dies wirkt sich auf die Implementierung von gettext im Produktionszyklus aus, indem Schritte wie das Extrahieren und Kompilieren von Nachrichten hinzugefügt werden.
Fluent verwendet ein einzelnes * .ftl-Dateiformat, das die Implementierung vereinfacht und keine zusätzlichen Schritte erfordert, die zu Datenabweichungen führen können.
Unicode-Unterstützung
Gettext kann in UTF-8 codiert werden. Im Allgemeinen endet hier die Unicode-Unterstützung. Es verwendet einen eigenen Datensatz für Pluralformen, weiß nicht, wie Datums- und Zahlenangaben formatiert werden, und hilft nicht bei der Arbeit mit bidirektionalen Texten.
Fluent nutzt in großem Umfang standardisierte Bibliotheken sowie CLDR-, ICU- und ECMA402-Algorithmen und kombiniert Lokalisierung und Internationalisierung.
Fazit
Wir glauben, dass die Fluent-API und -Syntax eine signifikante Verbesserung gegenüber gettext darstellen, und wir empfehlen, dass Sie sie für internationale Software verwenden.
Mehr über fließend