ファイルをプロジェクトにアップロードすると、そのファイルからすべての新しいリソースが抽出され、プロジェクトに保存されます。アップロードするファイルのファイル形式は、プロジェクトに対して最初に設定されたファイル形式である必要はありません。リソースをグループ化するためにタグが提供されている場合、新しいキーにはそれらのタグが適用されます。
Gettextなどの一部のファイル形式では、コメント、説明、複数形に関する情報など、貴重なメタ情報が追加で提供されます。この情報は可能な限り抽出され、割り当てられたリソースとともに保存されるため、ローカリゼーションファイルで提供されるすべての貴重な情報を後の使用のために保存できます。
ファイルをアップロードするにはいくつかの方法があります。
-
デフォルトでは、新しいコンテンツのみが抽出され、プロジェクト内の既存のキーは削除または更新されません。ファイルをアップロードしてもデータが失われることはありません。既存のデータを上書きする必要がある場合は、オプションを選択して、プロジェクトのリソースをローカリゼーションファイルのコンテンツで置換してください。既存の翻訳は、アップロードされたローカリゼーションファイルのコンテンツで上書きされます。
このオプションはAPIでも利用可能です。
備考
データ損失を防ぐため、ファイルを変更してオプションで再度アップロードする前に、Phraseから最新の変更をローカリゼーションファイルにダウンロードしてください。
-
アップロードする翻訳キー名の先頭に付加する一意の識別子（ファイルパスなど）を入力します。キー名を整理するために、プロジェクトやファイルに関連する意味のあるプレフィックスを使用してください。
例えば、インポートされたキー
hello_worldにプレフィックスproject_を付けると、キーproject_hello_worldになります。翻訳キーのプレフィックスにより、キーが既存のものと照合され、異なるプロジェクトやファイル間での衝突が回避されます。
このオプションは、API および CLI インターフェースでも利用できます。
-
新しいキーを追加し、アップロードされたファイルのコンテンツで既存のキーを上書きします。
-
プロジェクトのデフォルト言語の既存の原文が、アップロードされた多言語ファイルの原文と一致する場合にのみ、訳文を更新します。
-
アップロードされたファイルからキーのすべての説明を更新する必要がある場合は、このオプションを選択します。空欄の説明は、既存の説明を上書きします。説明には、翻訳者向けの追加情報を含めることができ、エディタ 内で個々のキーを識別するのに役立ちます。
-
翻訳を整理しておくために、意味のあるラベルを付けてキーに複数のタグを追加します。新しいキーがアップロードタグで自動的にタグ付けされるのを防ぐには、このオプションを選択します。
-
新しいキーや翻訳が更新されたキーをアップロード時に自動的にタグ付けするには、このオプションを選択します。これは、新規、更新済み、および古い翻訳 Strings を区別するのに役立ち、関連するキーのみが後続の処理対象となるようにします。
このオプションはAPIでも利用可能です。
-
ファイルのエンコーディング（例：UTF-8）を指定するか、自動選択させます（自動選択されたエンコーディングは誤ったエンコーディングになる可能性があり、アップロードを取り消すことで元に戻すことができます）。
-
-
は、翻訳を更新する際にメイン言語以外の翻訳を再度検証する必要を防ぎます。
-
は、アップロードされたすべての翻訳をレビュー済として扱います。このオプションは、高度なレビューワークフロー が有効になっている場合に使用できます。これは、キーが本番環境へ送信される準備が整っていることを示します。
-
-
Stringsでファイルをアップロード<1>するには、以下の手順に従います。
-
アップロード<3>失敗<2>
ファイルが正常に処理されなかった場合、エラーを軽減するためのヘルプ<1>としてエラーの詳細が提供されます。
-
アップロード<3>成功<2>
翻訳ファイルの処理が成功した後、アップロード<1>の概要を示すサマリーページが表示され、次へ<2>のステップへのリンクボタンが提供されます。アップロードタグをクリックして、エディタでファイルを開きます。
-
キーを削除
ローカライズファイルからキーを削除して再度アップロードする際に、誤ってキーが削除されるのを防ぐため、それらのキーは自動的には削除されません。
それらのキーを削除するには、次の手順に従います。
未言及のキーとは、今回のアップロードには含まれていないものの、プロジェクトにはまだ存在するキーのことです。それらを削除することで、アップロードされたファイルに含まれていなかったすべてのキーと関連する翻訳がプロジェクトから削除されます。
未言及のキーを削除する上限は100,000キーです。この上限を超えるプロジェクトでは、オプションは使用できません。
-
アップロードの取り消し
すべてのアップロードは複数のアクションをトリガーし、プロジェクト内の多くのデータを変更する可能性があるため、アップロードを取り消すことはできません。
アップロードされたファイルによって（誤って）導入されたキーを削除するには、次の手順に従います。
そのアップロードによって作成されたすべてのキーと関連する翻訳が削除されます。アップロード前に存在していたキーの翻訳は削除されません。個々の翻訳を削除するには、各翻訳のバージョン履歴を使用します。
言語ファイルは、いつでも、またサポートされている任意のファイル形式でプロジェクトからエクスポートできます。
ファイルは、APIまたはCLIを介してアプリケーションからエクスポートできます。
ファイルは、任意のプロジェクトのタブから、それらを選択してダウンロード（複数のファイル）をクリックするか、言語のその他のオプション /ダウンロードボタンをクリックしてダウンロードできます。
ダウンロードオプションは、ウィンドウでファイルをダウンロードする際に表示され、、、のタブがあります。
異なるを選択すると、異なるオプションが表示されます。詳細については、特定のファイル形式に関する関連する記事を参照してください。
オプションとして、タブのフィールドを使用してカスタムエクスポートファイル名を指定するか、空白のままにしてシステム定義の名前を生成します。
-
ファイルのアップロード時に翻訳キーのプレフィックスが追加されている場合は、タブでこのオプションを選択し、エクスポートされた翻訳キーの名前からプレフィックスを削除します。
-
プレフィックスを入力してすべてのキーをダウンロードし、可能な場合は指定されたプレフィックスを削除します。
注意
プレフィックスが削除された後に他のキーが同じ名前を共有している場合、これにより重複するキー名が作成される可能性があります。
-
必要に応じて、を選択して、指定されたプレフィックスを含む翻訳キーのみをダウンロードし、ダウンロードしたファイルからプレフィックスを削除します。
このオプションは、APIおよびCLIインターフェースでも使用できます。
-
デフォルトでは、翻訳可能なリソースは、元のファイル構造を維持するのではなく、キーと値として保存されます。これにより、1つのファイル形式にロック済の状態になることなく、交換可能なファイル形式が可能になり、タグを使用した柔軟なグループ化も可能になります。
一部のフレームワークや設定では複数の原文ファイルが必要となり、追加の設定も必要になります。
個別のファイルの維持
一般的に、各言語のすべての翻訳は1つのファイルにまとめてください。これにより、リソースのダウンロードが高速化され、堅牢性が向上します。翻訳はプロジェクト内で整理されて保持されるため、小さなファイルを個別に用意する必要はありません。
ローカリゼーションファイルを個別のファイルで維持する必要がある場合は、アップロード時にキーにタグを付け、翻訳されたキーを元のファイルにダウンロードする際にそのタグを参考資料として使用することで、ファイルベースのワークフローを使用できます。キーは複数のタグを持つことができ、複数のファイルに含めることで、再利用と一貫性を確保できます。タグベースのワークフローは柔軟であり、プロジェクトにアップロードすることなく翻訳リソースを再構成できます。
スムーズなワークフローを確保するために、すべてのファイルでキーに一意の名前を付けてください。キーと値に基づくアプローチでは、キーにはすべてのコンテキストで同じ値が割り当てられている必要があります。一部のフレームワークでは、複数のファイルにわたって一意ではないキーの使用が許可されています。Symfonyなどの一部のファイル形式は、メッセージドメインをサポートしています。これらのドメインはファイル名によって検出されます。キーはファイル名ベースのドメインによって自動的にスコープ設定されるわけではありませんが、ファイル内のキーに一意のドメインプレフィックスを使用することで解決できます。
CLI設定の例
CLIを使用する場合や、プロジェクトをリポジトリ（GitHub、GitLab、Bitbucketなど）に接続する場合は、アップロードとダウンロードを管理するための設定ファイルを設定してください。
この例では、プロジェクトには原文ロケール用に意味のある名前が付けられた翻訳ファイルがいくつかあります。例: accounts.en.yml、emails.en.yml など。これらのセマンティック名はタグを通じて管理されます。
.phrase.yml を設定して、ローカライズプロジェクト内のファイルの組織を反映させ、ファイルパスにタグのプレースホルダーを含めることで、それらをStringsプロジェクトのタグにリンクします。
phrase:
access_token: "3d7e6598d955bfcab104c45c40af1b9459df5692ac4c28a17793"
project_id: "23485c9c5dfb15d85b32d9c5f3d2hl54"
file_format: yml
push:
sources:
- file: ./path/to/locales/<tag>.en.yml
params:
locale_id: "abcd1234cdef1234abcd1234cdef1234"
pull:
targets:
# accounts
- file: ./path/to/locales/accounts.<locale_name>.yml
params:
tags: accounts
# emails
- file: ./path/to/locales/emails.<locale_name>.yml
params:
tags: emails
パラメータタグは、<tag> プレースホルダーを使用する代わりに、pushセクションで使用することもできます。
この設定により、リポジトリからpushを実行したり同期をトリガーしたりする際に、ファイルに基づいたタグを持つキーが作成されます。pullを実行したりリポジトリへのエクスポートをトリガーしたりすると、タグに基づいてキーがファイルにグループ化されます。
製品、ウェブサイト、またはアプリはさまざまな言語に翻訳されますが、場合によっては、ローカライズは選択された言語だけでなく、同一言語内の異なるバージョンを指すこともあります。
以下の場合、さらなる区別が必要になります。
-
同じ言語が話されている地域で、製品のブランディングが異なる場合。
-
ホワイトラベルソリューションを使用したい異なるクライアントによって製品が使用される場合。
-
シンプル、フォーマル、インフォーマルなどの言語バリエーションが必要な場合。
静的製品のローカライズ
製品が完全に開発されており、めったに更新されない場合は、プロジェクト内に製品の個別のバージョンを存在させることができます。
-
単一の出力または短期的なプロジェクトの場合:
ブランチを作成し、プロジェクトの期間中は専らそのブランチで仕事をし、完了したらブランチを削除します。
-
長期的なプロジェクトの場合:
既存のプロジェクトの複製を維持します。これにより、クライアントのプロジェクトへのアクセスのみを提供することで、同じ組織内のクライアントを招待して仕事をし、他のプロジェクトを非表示にすることができます。
継続的な更新を伴うプロジェクトのローカライズ
製品が新しいコンテンツ（キー）で絶えず更新される場合、それらの更新を複数のプロジェクトに適用し、同期を維持することは困難です。プロジェクト内で専用の言語を使用して、それらを維持します。
ISO標準（例: en-US）に従う言語コードは一意である必要はないため、同じ言語の多くのバージョンをプロジェクト内で作成できます。固有の言語名を使用して、地域、クライアント、または対象読者を区別します。
セットアップすると、デフォルトのロケールで新しく導入されたキーはすべて、他の言語では未翻訳として表示され、それに応じてローカライズされます。クライアントおよびそのクライアントの翻訳者と仕事をする場合は、ユーザープロファイルまたはプロジェクトのユーザー管理で言語アクセスを更新することにより、そのクライアントの言語バージョンのみを編集できるように具体的に割り当てます。
同じプロジェクト内で、ジョブとレビューワークフローを使用して並行ローカライズプロセスを設定します。この柔軟性は、言語ファイルのアップロードとダウンロード、またはAPIを介した自動化プロセスにも拡張されます。