プロジェクトにファイルをアップロードすると、そのファイルから新しいリソースがすべて抽出され、プロジェクトに格納されます。アップロードされるファイルのファイル形式は、プロジェクトの初期設定ファイル形式である必要はありません。リソースのグループ化のためにタグ が提供されている場合、新しいキーにはそれらのタグが適用されます。
Gettext などの一部の形式は、コメント、説明、複数形に関する情報などの追加の貴重なメタ情報を提供します。この情報は必要に応じて抽出され、割り当てられたリソースとともに保存されるため、ローカライゼーションファイルで提供されるすべての貴重な情報を保存して、さらに使用することができます。
ファイルをアップロードするには、いくつかの方法があります。
-
デフォルトでは、新しいコンテンツのみが抽出され、ローカライゼーションプロジェクトの既存のキーは削除または更新されません。ファイルのアップロードによってデータが失われることはありません 。既存のデータを上書きする必要がある場合は、 オプションを選択して、プロジェクトリソースをローカライゼーションファイルのコンテンツで置換します。既存の翻訳は、アップロードされたローカライゼーションファイルのコンテンツで上書きされます。
このオプションは APIでも利用できます。
備考
データの損失を防ぐため、ローカライゼーションファイルを変更してから オプションで再度アップロードする前に、Phraseから最新の変更をダウンロードしてください。
-
アップロードされたファイルのキーの説明をすべて更新する必要がある場合は、このオプションを選択します。空欄の説明は既存の説明を上書きします。説明には、翻訳者の追加情報を含めることができ、エディタで個々のキーを識別するヘルプになります。
-
翻訳を整理するには、意味のあるラベルを持つキーに複数のタグを追加します。このオプションを選択すると、新しいキーがアップロードタグで自動的にタグ付けされなくなります。
-
このオプションを選択すると、アップロード時に新しいキーと更新された翻訳に自動的にタグを付けます。これにより、新しい翻訳文字列、更新された翻訳文字列、古い翻訳文字Stringsを区別し、関連するキーのみがさらに処理されるようにすることがヘルプます。
このオプションは APIでも利用できます。
-
ファイルのエンコード（UTF-8など）を指定するか、自動的に選択してください（自動的に選択されたエンコードは不正なエンコードになる可能性があり、アップロードを元に戻すことでロールバックできます）。
-
することで、翻訳の更新時に非メイン言語翻訳を再度検証する必要がなくなります。
翻訳をレビュー済にすると、アップロードされたすべての翻訳がレビュー済として扱われます。このオプションは、 詳細レビューワークフローがアクティブになっている場合に使用できます。これにより、キーをプロダクションにプッシュする準備ができたことを示すことができます。
Strings でファイルをアップロードする手順は、次のとおりです。
-
アップロード前に、ファイルがタイプに基づいて正しくフォーマットされていることを確認してください。
-
プロジェクトから、]メニューからファイルアップロードを選択します。
ページが開きます。
-
[ファイルの選択]をクリックし、ディレクトリからファイルを選択します。
選択したファイルがフィールドに追加されます。
-
ファイルのを選択します。
ファイル形式に基づいて、提案されたフォーマットが最初に表示されます。
-
ドロップ一覧からファイルコンテンツの言語を選択します。
この情報がファイル自体にない場合は、コンテンツの新しい言語を作成するか、既存の言語を使用します。
-
オプションで、新しいキーに割り当てるタグやその他のオプションを指定します。
-
保存をクリックします。
コンテンツがインポートされ、キーに変換されます。
-
アップロード失敗
ファイルを適切に処理できなかった場合は、エラーの詳細が表示され、エラーの軽減にヘルプます。
-
アップロード成功
翻訳ファイルの処理が完了すると、アップロードの概要を示す概要ページが表示され、次へのステップにリンクするボタンが表示されます。
-
キーを削除中
ローカライゼーションファイルからキーを削除して再度アップロードする際に、キーが誤って削除されるのを防ぐため、これらのキーは自動的に削除されません。
これらのキーを削除する手順は、次のとおりです。
アップロードされたファイルに含まれなかったすべてのキーと関連する翻訳がプロジェクトから削除されます。
-
アップロードを元に戻す
アップロードのたびに複数のアクションが実行され、プロジェクト内の多くのデータが変更される可能性があり、アップロードを取り消すことはできません。
アップロードされたファイルによって（誤って）導入されたキーを削除する手順は、次のとおりです。
そのアップロードロードによって作成されたすべてのキーと関連する翻訳は削除されます。アップロード前に存在していたキーの翻訳は削除されません。個々の翻訳を削除するには、各翻訳のバージョン履歴を使用します。
言語ファイルは、プロジェクトから任意の時点で、サポートされている任意のファイル形式にダウンロードできます。
ファイルは、アプリケーションから 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：
出典：
- file: ./path/to/locales/<tag>.en.yml
params：
locale_id: "abcd1234cdef1234abcd1234cdef1234"
プル：
訳文：
#個のアカウント
- ファイル: ./path/to/locales/accounts.<ロケール名>.yml
params：
タグ：アカウント
#個のメール
- file: ./path/to/locales/emails.<locale_name>.yml
params：
タグ：メール
パラメータ tags は、 <タグ> プレースホルダーの代わりにプッシュセクションでも使用できます。
この設定では、プッシュを実行する とき、またはリポジトリから同期をトリガーするときのファイルに基づいて、タグ付きのキーが作成されます。リポジトリへのエクスポートを実行する pull またはトリガーすると、キーはタグに基づいてファイルにグループ化されます。
製品、ウェブサイト、アプリは多数の異なる言語に翻訳されますが、場合によっては、ローカライゼーションは選択した言語だけでなく、1つの言語内で異なるバージョンを使用することもあります。
以下の場合は、さらに区別する必要があります。
-
同じ言語を話す地域でも、製品のブランディングは異なります。
-
製品は、ホワイトラベルソリューションの使用を希望するさまざまなクライアントによって使用されます。
-
シンプル、公式、非公式などの言語バリエーションが必要です。
静的製品のローカライズ
製品が完全に開発され、ほとんど更新されない場合、プロジェクト内に製品の別バージョンが存在することがあります。
-
単一の出力または短期プロジェクトの場合：
-
長期用語プロジェクトの場合：
既存プロジェクトの複製を維持する。これによって、同じ組織内のクライアントを招待し作業することができます。クライアントにはプロジェクトへのアクセスのみが許可され、他のプロジェクトは非表示になります。
継続的な更新を伴うプロジェクトのローカライズ
製品が常に新しいコンテンツ（キー）で更新されている場合、それらの更新を複数のプロジェクトに適用して同期を維持することは困難です。プロジェクト内で専用の言語を使用してメンテナンスします。
言語コード （例：en-US）は一意である必要はないため、同じ言語の多くのバージョンが プロジェクト内でできます。一意の言語名を使用して、地域、クライアント、オーディエンスを区別します。
セットアップ時、デフォルトロケールで新しく導入されたキーは他の言語では未翻訳として表示され、それに応じてローカライズされます。クライアントとその翻訳者を使用する場合は、ユーザープロファイルまたはプロジェクトユーザー管理で言語アクセスを更新して、その翻訳者の言語バージョンのみ編集できるように割り当ててください。
ジョブ と レビューワーク フローを使用して、同じプロジェクト内で並列ローカライゼーションプロセスを設定します。この柔軟性は、API経由での言語ファイルのアップロードやダウンロード、プロセスの自動化にも及びます。