翻訳の管理

Using Localization Files (Strings)

本コンテンツはPhrase Language AIの機械翻訳により、英語から翻訳されています。

ローカライゼーションファイルのアップロード

プロジェクトにファイルをアップロードする場合、新しいリソースはすべてそのファイルから抽出され、プロジェクト内に保存されます。アップロードされるファイルのファイル形式は、プロジェクトの初期設定のファイル形式である必要はありません。リソースのグループ化に tags  が設定されている場合、新しいキーにはそれらの tags が適用されます。

Gettext のように、コメント、説明、複数形に関する情報などの追加の貴重なメタ情報を提供する形式もあります。この情報は必要に応じて抽出され、割り当てられたリソースとともに保存されるため、ローカリゼーション ファイルで提供されたすべての貴重な情報は、後で使用するために保存できます。

ファイルのアップロードにはいくつかの方法があります。

  • アプリケーションでは、新規プロジェクトを作成するとき、またはプロジェクトページでファイルアップロードを選択するとき

  • API経由

  • CLI経由

アップロード オプション

  • 翻訳を更新する

    デフォルトでは、新しいコンテンツのみが抽出されます。ローカライゼーションプロジェクトの既存のキーは削除または更新されません。ファイルのアップロードによってデータが失われることはありません 。既存のデータの上書きが必要な場合は、翻訳更新 オプションを選択して、プロジェクトリソースをローカライゼーションファイルのコンテンツで置換。既存の翻訳はアップロードされたローカライゼーションファイルのコンテンツで上書きされます。

    このオプションは API でも使用できます。

    備考

    データの損失を防ぐため、ローカライゼーションファイルの変更および 翻訳更新 オプションでの再度のアップロードを行う前に、そのファイルに対する最新の変更をPhraseからダウンロードしてください。

  • 翻訳キーのプレフィックスを使用

    アップロードされた翻訳キー名の先頭に付ける一意の識別子(ファイルパスなど)を入力します。プロジェクトまたはファイルに関連する意味のあるプレフィックスを使用して、キー名を整理します。

    たとえば、プレフィクス project_hello_world キーがインポートされると、キー project_hello_world になります。

    翻訳キーのプレフィックスを使用すると、キーが既存のキーと確実に一致し、異なるプロジェクトやファイル間の衝突を回避できます。

    このオプションは API および CLI インターフェイスでも使用できます。

  • 概要を更新する

    アップロードされたファイルからすべてのキーの説明を更新する必要がある場合にこのオプションを選択します。empty descriptions will overwrite existing descriptions.(空の説明文は既存の説明文を上書きします。)説明には、翻訳者向けの追加情報、およびエディタでの個々のキーの識別ヘルプを含めることができます。

  • アップロード tagsをスキップ

    翻訳を整理し続けるには、意味のあるラベルを持つキーに multiple tags を追加します。このオプションを選択すると、新しいキーが自動的にアップロードタグでタグ付けされなくなります。

  • 新規翻訳及び更新された翻訳のためのタグキー

    このオプションを選択すると、アップロード時に自動で新しいキーと更新された翻訳キーにタグを付けます。これにより、新規、更新、および古い翻訳 Strings を区別するのにヘルプが表示され、関連するキーだけがさらに処理されることが保証されます。

    このオプションは API でも使用できます。

  • エンコード

    ファイルのエンコード(UTF-8など)を指定するか、自動的に選択させます(自動的に選択されたエンコードは、不正なエンコードになる可能性があるため、アップロードを元に戻すことでロールバックできます)。

  • 校正

    未検証をスキップ することによって、翻訳を更新する際に、メインではない言語の翻訳を再度検証する必要がなくなります。

    翻訳をレビュー済にすると、アップロードされたすべての翻訳がレビュー済として扱われます。このオプションは、先進レビュー ワークフローがアクティブ化されているときに使用できます。これにより、キーをプロダクションへのプッシュ準備完了としてマークすることができます。

ユーザー インターフェイス経由のファイルアップロード

Strings でファイルをアップロードする手順は、次のとおりです。

  1. アップロード前に、ファイルのタイプに基づいて正しいフォーマットになっていることを確認してください。

  2. プロジェクトから、[その他] メニューの [ファイルをアップロード] を選択します。

    ファイルのアップロードページが開きます。

  3. [ファイルの選択]をクリックし、ディレクトリからファイルを選択します。

    選択したファイルが「ファイル」フィールドに追加されます。

  4. ファイルのファイル形式を選択します。

    推奨されるファイル形式は、ファイルの種類に基づいて最初に表示されます。

  5. ドロップダウン一覧からファイルコンテンツの言語を選択します。

    この情報がファイル内にない場合は、コンテンツの新しい言語を作成するか、既存の言語を使用します。

  6. オプションで、新しいキーに割り当てる tags およびその他のオプションを指定します。

  7. 保存をクリックします。

    コンテンツがインポートされ、キーに変換されます。

アップロード概要

  • アップロード失敗

    ファイルを正しく処理できなかった場合は、Errorの詳細がErrorの軽減に役立ちます。

  • アップロード成功

    翻訳ファイルの処理が完了すると、アップロードの概要を示す概要ページと、次へのステップにリンクするボタンが表示されます。アップロードタグをクリックしてエディタでファイルを開きます。

  • キーを削除中

    ローカライゼーションファイルからキーを削除して再度アップロードする際、誤ってキーが削除されないように、これらのキーは自動的に削除されません。

    これらのキーを削除する手順は、次のとおりです。

    1. ファイルをアップロードします。

    2. 削除をクリックし、メンションされていないキー削除を選択。

    3. 選択を確定します。

    アップロードされたファイルに含まれなかったすべてのキーと関連する翻訳は、プロジェクトから削除されます。

  • アップロードを元に戻す

    アップロードのたびに複数のアクションが実行され、プロジェクト内の多くのデータが変更される可能性があるため、アップロードを取り消すことはできません。

    アップロードされたファイルによって(誤って)導入されたキー を削除するには、次の手順に従います。

    1. 該当するアップロードのアップロード概要から、削除をクリックし、作成キー削除を選択。

    2. 選択を確定します。

    そのアップロードロードによって作成されたすべてのキーと関連する翻訳は削除されます。アップロード前に存在していたキーの翻訳は削除されません。個々の翻訳を削除するには、各翻訳のバージョン履歴を使用します。

アーカイブアップロード

任意のプロジェクト ページで、[More]メニューから uploads を選択してアップロード アーカイブにアクセスします。

アップロードアーカイブには、すべての過去の uploads がすべての可能なステータスで一覧表示されます。[All statuss]ドロップダウンをクリックして、uploadsのステータス(成功失敗進捗)でフィルタします。特定のアップロードを検索するには、上部にある検索Boxを使用して名前で検索します。

一覧表示されたアップロードをクリックすることで、影響を受けたリソースの詳細なアップロード概要にアクセスできます。成功した uploads はすべてプロジェクトのアクティビティストリームにも表示されます。

ローカライゼーションファイルのダウンロード

言語ファイルは、任意の時点でプロジェクトから任意のサポートされているファイル形式にダウンロードできます。

ファイルは、アプリケーションから API または CLI 経由でダウンロードできます。

ファイルは、任意のプロジェクトの [言語] タブから選択し、ダウンロード (複数のファイル) または言語の [その他オプションmore.jpeg/ダウンロード] ボタンをクリックしてダウンロードできます。

ダウンロードオプション

ファイルのダウンロード時に、ダウンロード オプションが [Download] ウィンドウに表示されます。このウィンドウには、[General][Advanced]、および [Encoding] のタブがあります。

異なるファイル形式を選択すると、異なるオプションが表示されます。詳細については、ファイル形式に関する記事を参照してください。

  • 翻訳キープレフィックス削除

    ファイルアップロード時に翻訳キーのプレフィックスが追加されている場合は、[詳細設定]タブでこのオプションを選択すると、エクスポートされる翻訳キーの名前からプレフィックスを削除できます。

    1. すべてのキーをダウンロードするプレフィックスを入力し、可能な場合は指定のプレフィックスを削除

      注意

      プレフィックスが削除された後に他のキーが同じ名前を共有している場合、複製キー名が作成される可能性があります。

    2. 必要に応じて、翻訳キープレフィックスをフィルタとして使用を選択して、指定されたプレフィックスを含む翻訳キーのみをダウンロードし、ダウンロードしたファイルからプレフィックスを削除します。

    このオプションは API と CLI インターフェイスでも使用できます。

使用例

ファイル構造のメンテナンス

デフォルトでは、翻訳可能リソースは、元のファイル構造を保持せずに、キーと値として保存されます。これにより、1つのファイル形式にロック済で交換可能なファイル形式や、tagsを使用した柔軟なグループ化が可能になります。

フレームワークや設定によっては、複数の原文ファイルが必要な場合もあります。

別々のファイルを保持

通常、各言語の翻訳はすべて 1 つのファイル内に保存します。これにより、リソースダウンロードがより速く、より堅牢になります。翻訳はプロジェクト内で整理されるため、個別の小さなファイルは必要ありません。

ローカライゼーション ファイルを別々のファイルに維持する必要がある場合は、アップロード時に keys にタグを付け、翻訳されたキーを元のファイルをダウンロードする際に tags を参考資料として使用することで、ファイルベースのワークフローを使用できます。キーは複数の tags を使用でき、複数のファイルに含めることで再利用と一貫性を確保できます。タグベースのワークフローは柔軟で、プロジェクトにアップロードすることなく翻訳リソースを再編成できます。

スムーズなワークフローを実現するため、すべてのファイルに一意のキー名をつけましょう。キー値ベースのアプローチでは、すべてのコンテキストでキーに同じ値を割り当てる必要があります。一部のフレームワークでは、複数のファイルに対して一意でないキーを使用できます。Symfonyなど一部のファイル形式はメッセージドメインに対応しています。これらのドメインはファイル名によって検出されます。キーはファイル名ベースのドメインでは自動的にスコープ指定されませんが、ファイル内のキーに一意のドメインプレフィックスを使用することで解決できます。

CLI 設定例

CLIを使用する場合や、プロジェクトをリポジトリ( GitHub、 GitLab、 Bitbucketなど)に接続する場合は、 設定ファイル を設定して uploadsとdownloadsを管理します。

たとえば、原文ロケール用にセマンティックに名前が付けられた翻訳ファイルが 1 つのプロジェクトに複数あります。例:accounts.en.ymlemails.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

注意

サポートされていますが、セキュリティ上の理由から、ファイル内にアクセスを格納することは推奨されません。

PHRASE_ACCESS_TOKEN環境変数を設定すると、より安全です。

Parameter tags  は push セクションで <タグ> プレースホルダーの代わりに使用することもできます。

この設定では、リポジトリから push または sync をトリガーするときに、そのキーのファイルに基づいて tags 付きのキーを作成します。リポジトリへのエクスポートの実行時 pull またはトリガー時に、 tags に基づいてキーをファイルにグループ化します。

地域、クライアント、オーディエンスごとにプロジェクトをローカライズする

製品、ウェブサイト、アプリは多数の異なる言語に翻訳されますが、ローカライゼーションは単に選択された言語ではなく、1つの言語内の異なるバージョンで行われる場合もあります。

次のような場合は、さらに区別する必要があります。

  • 同じ言語が話されている地域では、製品のブランディングも異なります。

  • 製品は、ホワイトラベルソリューションの使用を希望するさまざまなクライアントによって使用されています。

  • シンプル、フォーマル、インフォーマルなどの言語バリエーションが必要です。

静的な製品のローカライズ

製品が完全に開発されていて、ほとんどアップデートされない場合、プロジェクト内に別のバージョンの製品が存在する可能性があります。

  • 単一出力または短期プロジェクトの場合:

    ブランチの作成、プロジェクトの期間中そのブランチだけでの仕事、完了後ブランチの削除。

  • 長期用語プロジェクトの場合:

    既存プロジェクトの複製を維持。これによって、同じ組織内のクライアントにはそのプロジェクトへのアクセスのみ許可し、他のプロジェクトは非表示にして招待および作業を行うことができます。

継続的な更新によるプロジェクトのローカライズ

製品が常に新しいコンテンツ(キー)で更新されている場合、それらの更新を複数のプロジェクトに適用して同期を維持することは困難です。プロジェクト内で専用の言語を使用して管理できます。

ISO 標準に従う言語コード (en-US など) は一意である必要はないため、プロジェクト内で同じ言語の多くのバージョンを作成できます。一意の言語名を使用して、地域、クライアント、オーディエンスを区別します。

セットアップ時、デフォルトロケールで新しく導入されたキーは他の言語では未翻訳として表示され、それに応じてローカライズされます。クライアントとその翻訳者を使用する場合は、ユーザー プロファイルまたはプロジェクト ユーザー管理で言語アクセスを更新することによってのみ、その翻訳者の言語バージョンを編集できるように割り当てます。

同じプロジェクト内でジョブワークフローのレビューを同時に行うローカライゼーションプロセス設定この柔軟性は、言語ファイルのアップロードとダウンロードやAPI経由の自動化プロセスにも及びます。

この記事は役に立ちましたか?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.