ローカライズファイル (Strings)

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

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

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

ローカライズファイルの作成

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

ローカライズファイルを作成するには、表示可能なすべてのテキストをコードファイル内の固有のIDに置き換えます。次に、テキストStringsをそのIDと共にローカライズファイルに追加します。

ローカライズファイルの使用

実際のテキストStringsの代わりに、コードにはキーのみが含まれるようになります。ソフトウェアがユーザー向けのビューを生成する際、これらのキーを使用してローカライズファイル内の関連付けられたStringsを検索します。

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

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

文字列管理

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

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

リソースファイル形式

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は、<タグ>の形式でメタ情報を提供するファイル形式です。タグ構造は、Android XMLファイルからここに示されているように、キーとその対応する値がどこにあるかを判断するために使用されます。

 <string name="simple_key">Just a  key with a message.</string>

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
<target xml:lang="en-GB">Just a simple key with a simple message.</target
</trans-unit>

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

単純なキーと値のリスト

Ruby on Rails YAMLのこのスニペットが示すように、キーと値の単純なリストのみを含むリソースファイルがあります。

simple_key: Just a simple key with a simple message.

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

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

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

# This is the amazing description for this key!
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Check it out!"このキーは説明です。（少なくとも一部のファイル形式で）」
msgstr[1] "Check it out!"This key has %s descriptions!（少なくとも一部のファイル形式で）」

同様の機能と、比較的マイナーな点で異なるレイアウトを持つ競合するファイル形式が存在します。

連想配列

他の形式では読み取りにカスタムコード（パーサー）が必要ですが、一部の形式は開発者やローカライザーにとってより扱いやすくなっています。.JSON（JavaScript）や.PHP配列に基づく形式は、読み取りが可能であり、操作が容易な一般的なコード構造（配列）に直接マッピングできます。配列は複雑になる可能性があり、アプリケーションごとにカスタム配列構造が生成されます。

例えば、go-i18n JSONではキーをIDと呼びます：

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

Angularは、配列内のキーとしてキーそのものを使用します：

"simple_key": "I am a simple key with a simple message."

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