Fluentとgettextの違い

通常のgettextに対するFluentの利点についての議論を続けて、翻訳におけるFluent の作成者の公式な立場を公​​開します。

Gettextは、GNUプロジェクトとその関連アーキテクチャソリューションに深く根ざしたローカリゼーションシステムです。 Fluent Projectは、gettextを、読みやすい形式のローカライズファイルを使用して製品リリースサイクル全体を管理するための、ライブラリおよびツールの完全な低レベルのプラットフォームに依存しないエコシステムの良い例と考えています。 同時に、Fluentパラダイムは、重要なローカライズの側面で他のアーキテクチャソリューションにつながり、その結果、完全に異なるAPIとライフサイクルにつながります。



言い換えれば、gettextは素晴らしいプロジェクトですが、ローカライズへのアプローチに関する見解を共有していません。



gettextとFluentの主な違いは次のとおりです。

手配

gettextとFluentの最も重要な違いは、メッセージ識別子です。 Gettextは、ソース文字列（通常は英語）を識別子として使用することにしました。 この選択は簡単に思えますが、さらに多くの制限が課されます。



まず、このアプローチでは、元の行を変更すると、それに関連付けられているすべての翻訳が無効になります。 これは、すべての翻訳を更新する必要があるため、開発者の負荷を大幅に増加させ、元のメッセージを変更しないようにします。



第二に、ソース言語で同じテキストを持つ複数のメッセージの導入が複雑になり、異なる方法で翻訳する必要があります。 たとえば、「開く」ボタンと「開く」マークのテキストは、最初のテキストがコマンドで、2番目が説明であるため、さまざまな方法で翻訳できます。 Gettextには、同じソースセグメントを持つ行を区別するためのオプションのmsgctxtコンテキスト行があります。 このアプローチは、開発者にそのような状況を認識する責任を負います。これは、利益の分離の原則と矛盾します。



Fluentは、まさにこの理由でテキストを再利用することを推奨していません。 ソーステキストを他の翻訳から分離することも、複合メッセージ（1つの翻訳単位の複数の行を含み、1つのユーザーインターフェイスウィジェットにアタッチされている）を入力する機能およびメッセージへの識別子ベースのリンクにとって重要です。



Fluentは、開発者とローカライザーの間に「合意」を確立します。 開発者は一意の識別子と一連の変数（未読メッセージの数、ユーザー名など）を入力し、Fluent構文を使用してローカライザーがこの識別子のメッセージテキストの作成方法を決定します。



開発者は、そのようなメッセージの翻訳の詳細な実装について心配するべきではありません。 開発者に必要なのは、UIの特定の場所に適した1行のテキストを取得して、特定の識別子で行を要求することです。

メッセージオプション

Gettextは、特に複数形の国際化のために、小さな関数セットをサポートしています。 ただし、このような複数の構文は、標準のgettext構文に加えて特殊なケースであり、可変性を必要とする他のケースに合わせて拡張することは困難です。



Fluentは、セレクターで使用できる文字列バリエーションの基本概念をサポートしています。 通常、複数規則はそのようなセレクターになりますが、言語の文法的な特徴によっては、性別、偏角、または環境（例：時刻やオペレーティングシステムなど）が存在する場合もあります。 Fluent構文を使用すると、ローカライザーはこれらすべての機能を検討し、状況に完全に一致するテキストを作成できます。

外部引数

Gettextは外部引数をサポートしていません。 言い換えると、パラメーターの形式（数値、日付）を設定することはできません。 gettextのパラメーターをフォーマットするには、 printfに渡す文字列を返すか、結果の文字列でString.prototype.replaceを実行することをお勧めします。



Fluentでは、外部引数のサポートが構文の中心にあります。 外部引数は補間されるだけでなく、セレクターのパラメーターとしても使用され、組み込み関数に転送することもできます。 これにより、ローカライザーは特定のケースに対してより正確なテキストを作成できます。 さらに、Fluentはオブジェクトの周囲にFSI / PDIマーカーを配置して、双方向テキストの指向性分離を保護し、リーフ文字列の操作を禁止して、開発者の負担を軽減します。

責任の分離

さらに、gettextが複数のルールを処理する方法では、システム設計者がメッセージを多変量メッセージにするか単一行にするかを選択する必要があります。 Fluentの観点からすると、開発者はそのような問題に対処すべきではありません。 多くの場合、英語で1つのオプションで十分な場合、他の言語では複数形のバリアントを追加する必要があります。



Fluentは、多くのロケールでソフトウェアを開発する場合、開発者が同様の言語知識を持っていてはならず、各言語にはローカライズ中に特定のアクションの自由があるべきだと想定しています。



その結果、Fluentは、ある言語の要件を別の言語に「漏らす」ことなく各翻訳を個別に保存し、ローカライザーが特定の行に必要とする機能を心配する必要のない開発者のためにすべての翻訳を「不透明」に保ちます。

振込のキャンセル

開発サイクルでは、翻訳がオリジナルに対して「キャンセル」（無効になる）状態が3つあります。

• わずかな変更：翻訳に影響しません（正しい句読点、タイプミス）。
• 中程度の変更：メッセージのデザインに影響しますが、関連する翻訳の正確性はキャンセルされません（たとえば、 すべてのブックマークを 表示 -> ブックマークマネージャーを表示 ）。
• 重要な変更：文の新しい意味（ クリックして保存 -> クリックして開きます ）。

アーキテクチャ上の理由により、gettextは3つのレベルすべてをfuzzyと呼ばれる1つの状態に結合します。 ソース行の変更（少なくとも完全、少なくとも重要でない）は、翻訳の取り消しにつながります。



Fluentでは、一意の識別子を使用することで、これらのレベルのうち2つを3つ目のレベルとは別に保つことができます。行のソーステキストに小さな変更を加え、識別子を保存すると、翻訳は有効なままです。 一方、開発者が識別子を変更すると、すべての翻訳がキャンセルされ、更新が必要になります。



このようなアーキテクチャソリューションは、ほとんどのリリースサイクルでより有益であると考えていますが、 中間レベルの変更の場合、開発者は識別子を保存するか変更するかを選択する必要があります（つまり、 マイナー な変更と重要な変更のどちらか）。



また、開発者がメッセージをその内容を完全に無効にすることなく更新済みとしてマークできるように、メッセージのバージョン管理のアイデアも検討しています。 この状態では、古いバージョンの翻訳が未翻訳の文字列よりも優れているという観点に基づいて、翻訳を有効に保つことができ、同時にツールは翻訳を更新する必要性についてローカライザーに通知できます。

データ形式

Gettextは、* .po、* .pot、および* .moの3つのファイル形式を使用します。 これは、生産サイクルでのgettextの実装に影響を与え、メッセージの抽出やコンパイルなどの手順を追加します。



Fluentは、単一の* .ftlファイル形式を使用します。これにより、実装が簡素化され、データの不一致を招く可能性がある追加の手順が不要になります。

Unicodeサポート

GettextはUTF-8でエンコードできます。 一般的に、ここでUnicodeサポートが終了します。 複数形に独自のデータセットを使用し、日付と数値の書式設定方法がわからず、双方向テキストの操作に役立ちません。



Fluentは、標準化されたライブラリとCLDR、ICU、およびECMA402アルゴリズムを広範囲に使用し、ローカリゼーションと国際化をうまく組み合わせています。

おわりに

Fluent APIと構文はgettextよりも大幅に改善されていると思われるため、国際的なソフトウェアに使用することをお勧めします。

Fluentの詳細

• Project Fluentの公式サイト
• Fluentの紹介
• 構文ガイド
• Fluentはどこで役立ちますか？