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