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