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

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

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

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

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

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

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

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

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

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

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

文字列管理

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

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

リソースのファイル形式

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

Spreadsheets

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

"タイトル","デフォルト言語","デフォルトテキスト","英語テキスト","バリアントステータス"
"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">
 <原文 xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</原文
<訳文 xml:lang="en-GB">シンプルなキーとシンプルなメッセージ</訳文>
</trans-unit>

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

プレーンキー値リスト

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

simple_key:シンプルなキーとシンプルなメッセージ。

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

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

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

# これがこのキーの素晴らしい説明です！
msgid "key_with_description"
msgid_plural ""
msgstr[0] 「チェックアウト！このキーには説明があります！（少なくともいくつかの形式で）」
msgstr[1] "Check it out!このキーには%sの説明があります！（少なくともいくつかの形式で）」

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

連想配列

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

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

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

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

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

これらのマイナーながら重要な違いがあるため、広く使用されている.JSONと.PHPアレイ構造がサポートされています。