ローカライゼーションファイル (Strings)

ローカリゼーション ファイルは、メモ帳や TextEdit などのテキスト エディタ、またはプログラマが使用する多数の拡張テキスト編集ツールのいずれかで開いて編集できるテキスト ファイルです。これらのファイルは、一般的にキー/値の原則に従います。つまり、一意のID(キー)に関連付けられたテキスト スニペット(Strings)の一覧が格納されていることを意味します。したがって、各文字列はキーの値になります（この単純な例は、Java プログラミングで使用されるローカライゼーション ファイル形式です）。

ローカライゼーションファイルの作成

ローカライゼーションファイルは、シンプルな構造を持つプレーンテキストのファイルです。手動で作成することもできますが、通常はさまざまな開発環境で利用できる国際化ユーティリティやスクリプトによって自動的に生成されます。ローカライゼーションファイルの自動作成により、ファイル構造が確実に有効になります。

ローカライゼーションファイルを作成するには、表示可能なテキストはすべて、コードファイル内の一意の ID に置き換えられます。次に、Strings テキストが ID とともにローカリゼーション ファイルに追加されます。

ローカライゼーションファイルの使用

実際のテキスト Strings の代わりに、コードにはキーのみが含まれます。ソフトウェアがユーザーのビューを生成するとき、これらのキーはローカライゼーションファイル内の関連する Strings の検索に使用されます。

英語とスペイン語で使用するようアプリケーションが設定されている場合、すべての英語テキストは English.txt という名前のファイルに保存され、デフォルトのテキスト ロケーションになります。ユーザーが言語を選択しない場合、このファイルからすべてのテキストが抽出されて表示が生成されます。ユーザーがスペイン語を選択した場合、ソフトウェアは Spanish.txtにリダイレクトされます。このようなシステムでは、多くの 言語 を使用することができます。

利点は、表示用の言語の選択がコードに影響を与えないことです。ソフトウェアがログインボタンを表示する必要がある場合、キー login＿ボタンに関連付けられた文字列を必要とすることがあります。この場合、どのファイルを検索するかを知るだけで、特定の言語の適切な文字列を読み出せます。

文字列管理

キーベースの翻訳プラットフォームであるPhraseは、多くの異なるリソースファイルタイプをサポートしています。 ファイルが アップロードされると、 とそれに関連付けられた文字列値が抽出されます。次に、キーとStringsが標準化されたファイル形式で 翻訳者 に提示されます。翻訳者は、ローカライゼーションファイルの正確なファイル形式を気にすることなく、自分のタスクに集中できます。キー自体が重要なコンテキストを提供し、正しい単語の選択に導く可能性があるため、キーを検査できます。

すべてのStringsが翻訳されると、ファイルがダウンロードされます 。このプロセスで、元の原文ファイルと一致するローカライゼーションファイル形式が作成されます。

リソースのファイル形式

4 つの広範なリソースがサポートされ、すべて基本的にテキストベースであり、テキスト エディタで開いて調べることができます。

スプレッドシート

.XLSX および .CSV ファイルがサポートされています。これらの形式はローカライゼーションにおいて同等であり、キーと値のペアの行を含みます。キーは 1 行にあり、対応する値は隣接する行にあります。どの列をどの目的で正確に使用するかはアプリケーションによって異なり、ローカライゼーションでは列を正しく解釈するようにphraseを設定する必要があります。 Zendesk .CSV ファイルは固定構造であるため、このファイル タイプはそれ以上調整する必要はありません。

"Title","Default language","Default text","English text","Variant status"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

XML は、 <tags> 形式のメタデータを提供するファイル形式です。タグ構造を使用して、キーと対応する値を決定できます。これは、 Android XML ファイルから確認できます。

 <String name="simple_キー">単なるメッセージ付きのキーです。</文字列>

2 つの標準的な XML 翻訳形式は .TMX と .XLIFF です。これらは、キーと値を 1 つの言語で保持するだけでなく、原文言語の値ペアと訳文言語の対応する値を関連付けます。このようなファイルは、一般的にバイリンガルです。Symfony Xliff ファイルのこの翻訳ユニットは、次のように表しています。

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source
<訳文 xml:lang="en-GB">シンプルなメッセージが入ったシンプルなキーです。</訳文>
</trans-unit>

QT プログラムは、これらの標準化された形式と非常によく似た構造のリソースファイルを使用しますが、歴史的理由によりレイアウトが異なります。

プレーン キー値リスト

Ruby on Rails の YAML からの抜粋に示すように、キーと値の単純なリストだけを含むリソースファイルもあります。

simple_key:シンプルなメッセージのシンプルなキーです。

多くの異なるプログラミング言語やプラットフォームで、このような形式がマイナーなレイアウト違いで使用されています。

これらはモノリンガルファイルであるため、ローカライゼーションプログラムは、原文言語用と訳文言語用の、これらのファイルの並列バージョンを維持する必要があります。

Gettext は、説明的なコメントや複数形表現などの追加情報を含むキー値ファイルを作成します。

# このキーの説明は最高です！
msgid "key_with_description"
msgid_plural ""
msgstr[0 ] 「 ご覧ください！このキーは説明です。（少なくとも一部のファイル形式で）」
msgstr[1] 「ご覧ください！このキーには%s の説明があります！（少なくとも一部のファイル形式で）」

似たような機能やレイアウトで、比較的マイナーな違いを持つ競合するフォーマットもあります。

連想配列

他のファイル形式では、読み取りにカスタマイズされたコード（パーサー）が必要ですが、開発者やローカライゼーションにとってより簡単なファイル形式もあります。 .JSON （JavaScript）および .PHP 配列 に基づいた形式は、読み取り、操作が簡単な共通のコード構造 （配列） に直接マッピングできます。配列は複雑で、アプリケーションによってカスタム配列構造が生成されます。

たとえば、 go-i18n JSON  はキーを ID として参照します。

{
    "id": "simple_key",
    "translation": "simple key, simple message, so simple."
},

Angular はキー自体を配列のキーとして使用します。

"simple_key":"私はシンプルなメッセージを持つシンプルなキーです。".

これらのマイナーだが重要な相違点があるため、広く使用されている .JSON および .PHP 配列構造がサポートされています。