ローカリゼーションファイル（文字列）

本コンテンツはPhrase Language AIの機械翻訳により、英語から翻訳されています。

ローカリゼーションファイルは、NotepadやTextEditなどのテキストエディタや、プログラマーが使用するさまざまな高度なテキスト編集ツールで開いて編集できるテキストファイルです。これらのファイルは一般的にキーと値の原則に従います。これは、ユニークなID（キー）に関連付けられたテキストスニペット（文字列）の一覧を含むことを意味します。したがって、各文字列はキーの値です（この単純な例は、Javaプログラミングで使用されるローカリゼーションファイルの形式です）。

key1 = value1
key2 = value2
...
keyN = valueN

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

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

ローカリゼーションファイルを作成するには、表示可能なテキストのすべての部分がコードファイル内のユニークなIDに置き換えられます。その後、テキスト文字列はそのIDと共にローカリゼーションファイルに追加されます。

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

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

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

利点は、表示のための言語の選択がコードに影響を与えないことです。ソフトウェアがログインボタンを表示する必要がある場合、キー login_button に関連付けられた文字列が必要になることがあり、指定された言語の適切な文字列を取得するためにどのファイルを探すべきかを知る必要があります。

文字列管理

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

すべての文字列が翻訳されると、ファイルがダウンロードされます。その過程で、元のソースファイルに一致する必要なローカリゼーションファイル形式が作成されます。

リソースファイル形式

4つの広範なリソースタイプがサポートされており、すべて本質的にテキストベースで、テキストエディタで開いて検査できます。

スプレッドシート

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

"タイトル","デフォルト言語","デフォルトテキスト","英語テキスト","バリアントステータス"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

XMLは、<tags>の形式でメタ情報を提供するファイル形式です。タグ構造は、キーとそれに対応する値がどこにあるかを決定するために使用されます。これは、Android XMLファイルからの例です：

 <string name="simple_key">メッセージを持つ単純なキーです。</string>

標準的なXML翻訳形式には、.TMXと.XLIFFがあります。これらは、1つの言語のキーと値を保持するだけでなく、ソース言語の値ペアをターゲット言語の対応する値と関連付けます。このようなファイルは通常バイリンガルであり、これはSymfony Xliffファイルの翻訳ユニットが示しています：

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">単純なキーと単純なメッセージです。</source
<target xml:lang="en-GB">単純なキーと単純なメッセージです。</target>
</trans-unit>

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

プレーンなキー-値リスト

キーと値の単純なリストだけを含むリソースファイルがあります。これは、Ruby on Rails YAMLからのスニペットです：

simple_key: 単純なキーと単純なメッセージです。

多くの異なるプログラミング言語やプラットフォームは、わずかなレイアウトの違いを持つこのような形式を使用します。

これらはモノリンガルファイルであるため、ローカリゼーションプログラムは、ソース言語用の1つのファイルとターゲット言語用の他のファイルの並行バージョンを維持する必要があります。

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配列構造がサポートされています。