ファイルをプロジェクトにアップロードすると、すべての新しいリソースがそのファイルから抽出され、プロジェクトに保存されます。アップロードするファイルのファイル形式は、プロジェクト用に設定された初期のファイル形式である必要はありません。リソースをグループ化するためにタグが提供されている場合、新しいキーにはそれらのタグが適用されます。
Gettextなどの一部のファイル形式では、コメント、説明、複数形に関する情報など、価値のある追加のメタ情報が提供されます。この情報は可能な限り抽出され、割り当てられたリソースと一緒に保存されるため、ローカライゼーションファイルで提供されるすべての価値ある情報を保存して、後で使用することができます。
ファイルをアップロードする方法はいくつかあります:
APIまたはCLI経由でアップロードする場合、1つのファイルに複数のロケールが含まれるファイル形式(例:Phrase Strings .JSON、.YAML、多言語 .XLSX/.CSV、.XLIFF、.TMX、Genesys JSON)では、ファイル内の各翻訳のロケール識別子が、プロジェクトのタブで設定された通りに、言語名によってプロジェクトのロケールと一致されます。ロケールコード(例:「en-US」)は、その正確な文字列がロケールの設定名と一致しない限り、この一致には使用されません。翻訳のロケール識別子がプロジェクト内のどのロケール名とも一致しない場合、その翻訳のインポートは通知なく失敗します。
-
デフォルトでは、新しいコンテンツのみが抽出され、ローカライゼーションプロジェクト内の既存のキーは削除または更新されません。ファイルをアップロードしてもデータが失われることはありません。既存のデータを上書きする必要がある場合は、オプションを選択して、プロジェクトのコンテンツをローカライゼーションファイルのコンテンツで置換してください。既存の翻訳は、アップロードされたローカライゼーションファイルのコンテンツで上書きされます。
このオプションはAPIでも利用可能です。
備考
データ損失を防ぐため、ファイルを変更してオプションで再度アップロードする前に、Phraseから最新の変更をローカライゼーションファイルにダウンロードしてください。
-
アップロードされた翻訳キー名の先頭に付加する一意の識別子(ファイルパスなど)を入力してください。キー名を整理しておくために、プロジェクトやファイルに関連する意味のあるプレフィックスを使用してください。
例えば、プレフィックス
project_を付けたインポートされたキーhello_worldは、キーproject_hello_worldになります。翻訳キーのプレフィックスにより、キーが既存のキーと照合され、異なるプロジェクトやファイル間での衝突を回避できます。
このオプションは、APIおよびCLIインターフェースでも使用できます。
-
アップロードされたファイルのコンテンツで、新しいキーを追加し、既存のキーを上書きします。
-
プロジェクトのデフォルト言語の既存の原文が、アップロードされた多言語ファイルの原文と一致する場合にのみ、訳文を更新します。
-
アップロードされたファイルからキーのすべての記述を更新する必要がある場合は、このオプションを選択してください。空欄の記述は既存の記述を上書きします。記述には翻訳者向けの追加情報を含めることができ、エディタで個々のキーを識別するのに役立ちます。
-
翻訳を整理しておくために、意味のあるラベルを付けてキーに複数のタグを追加してください。新しいキーがアップロードタグで自動的にタグ付けされるのを防ぐには、このオプションを選択してください。
-
アップロード時に新しいキーや更新された翻訳を持つキーを自動的にタグ付けするには、このオプションを選択してください。これは、新規、更新済み、および古いStringsを区別するのに役立ち、関連するキーのみがさらに処理されるようにします。
このオプションはAPIでも利用可能です。
-
ファイルのエンコーディング(UTF-8など)を指定するか、自動選択させてください(自動選択されたエンコーディングは誤ったエンコーディングになる可能性があり、アップロードを取り消すことで元に戻すことができます)。
-
-
は、翻訳を更新する際にメイン言語以外の翻訳を再度検証する必要を防ぎます。
-
は、アップロードされたすべての翻訳をレビュー済として扱います。このオプションは、高度なレビューワークフローが有効になっている場合に使用できます。キーが本番環境へ送信される準備が整ったことを示します。
-
は、アップロードされたすべての翻訳を検証済みとして扱います。
-
Stringsでファイルをアップロードするには、以下の手順に従います。
-
アップロードの前に、タイプに基づいてファイルが正しくフォーマットされていることを確認してください。
-
プロジェクトから、メニューのアップロードを選択します。
ページが開きます。
-
ファイルを選択をクリックし、ディレクトリからファイルを選択します。
選択したファイルがフィールドに追加されます。
-
ファイルのを選択します。
ファイルタイプに基づいて、推奨されるファイル形式が最初に表示されます。
-
ドロップダウン一覧から、ファイルコンテンツの言語を選択します。
この情報がファイル自体に含まれていない場合は、コンテンツ用の新しい言語を作成するか、既存の言語を使用します。
-
必要に応じて、新しいキーに割り当てるタグやその他のオプションを指定します。
-
保存をクリックします。
コンテンツがインポートされ、キーに変換されます。
-
アップロード失敗
ファイルが正常に処理されなかった場合、エラーの軽減に役立つエラー詳細が提供されます。
-
アップロード成功
翻訳ファイルの処理が成功すると、アップロードの概要を示すサマリーページが表示され、次のステップへのリンクボタンが提供されます。アップロードタグをクリックして、エディタでファイルを開きます。
-
キーを削除中
ローカリゼーションファイルからキーを削除して再度アップロードする際に、誤ってキーが削除されるのを防ぐため、それらのキーは自動的には削除されません。
それらのキーを削除するには、次の手順に従います。
未言及キーとは、現在のアップロードには含まれていないが、プロジェクトにはまだ存在するキーのことです。それらを削除することで、アップロードされたファイルに含まれていなかったすべてのキーと関連する翻訳がプロジェクトから削除されます。
未言及キーを削除する上限は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> プレースホルダーを使用する代わりに、プッシュセクションでパラメータタグを使用することもできます。
この設定により、プッシュを実行したりリポジトリから同期をトリガーしたりする際に、キーの由来となったファイルに基づいてタグ付きのキーが作成されます。プルを実行したりリポジトリへのエクスポートをトリガーしたりすると、タグに基づいてキーがファイルにグループ化されます。
製品、ウェブサイト、またはアプリは複数の異なる言語に翻訳されますが、場合によっては、ローカライズは選択された言語だけでなく、同一言語内の異なるバージョンを指すこともあります。
以下の場合には、さらなる区別が必要となります。
-
同じ言語が話されている地域で、製品のブランディングが異なる場合。
-
ホワイトラベルソリューションの使用を希望する異なるクライアントによって製品が使用される場合。
-
シンプル、フォーマル、またはインフォーマルといった言語バリエーションが必要な場合。
静的製品のローカライズ
製品が完全に開発されており、更新がほとんど行われない場合は、プロジェクト内に製品の別バージョンを存在させることができます。
-
単一の出力または短期プロジェクトの場合:
ブランチを作成し、プロジェクト期間中は専らそのブランチで仕事をし、完了したらブランチを削除します。
-
長期プロジェクトの場合:
既存のプロジェクトの複製を維持します。これにより、組織内のクライアントにプロジェクトへのアクセス権のみを提供し、他のプロジェクトを非表示にすることで、クライアントを招待して一緒に仕事ができるようになります。
継続的な更新を伴うプロジェクトのローカライズ
製品が新しいコンテンツ(キー)で絶えず更新される場合、それらの更新を複数のプロジェクトに適用し、同期を維持することは困難です。プロジェクト内で専用の言語を使用して、それらを維持します。
ISO標準(例:en-US)に従う言語コードは一意である必要はないため、同じ言語の多くのバージョンをプロジェクト内で作成できます。地域、クライアント、または対象読者ごとに、固有の言語名を使用して区別します。
セットアップを行うと、デフォルトのロケールで新しく導入されたキーはすべて、他の言語では未翻訳として表示され、それに応じてローカライズされます。クライアントおよびそのクライアントの翻訳者と作業する場合、ユーザープロファイルまたはプロジェクトのユーザー管理で言語アクセスを更新することで、彼らが担当する言語バージョンのみを編集できるように具体的に割り当てます。
同じプロジェクト内で、ジョブとレビューワークフローを使用して並行ローカライズプロセスを設定します。この柔軟性は、言語ファイルのアップロードやダウンロード、またはAPIを介した自動化プロセスにも適用されます。