コンテンツにスキップ

多言語翻訳管理のアプローチを比較する

ローカライズされたコピーの保存、更新、プレビュー、送信の方法を評価し、QAワークフロー、チャネル構成、更新頻度に合ったローカライゼーションアプローチを選択できます。

この例について

架空のキッチン用品小売業者である Kitchenerie は、英語、フランス語、ドイツ語でメール、プッシュ、アプリ内メッセージを送信しています。マーケティングチームと開発チームには、キャンペーン全体の翻訳を管理するための、再現性と拡張性のある方法が必要です。

Braze は、いくつかのローカライゼーションパターンをサポートしています。

  • 手動の条件付き Liquid: メッセージ本文に言語ごとのコピーを入力します
  • Content Blocks: 再利用可能なブロック (多言語翻訳タグの有無を問いません)
  • カタログ: ロケールをキーとする構造化された翻訳行
  • 多言語メッセージ: 翻訳タグ、CSV アップロード、翻訳 API (早期アクセス)
  • 翻訳パートナー: Smartling、Phrase、Lokalise など
  • Connected Content: 送信時に CMS または API から取得するローカライズされた文字列

この例ではそれぞれのトレードオフを比較し、QA ワークフロー、チャネル構成、更新頻度、チームのリソースに合ったアプローチを選べるようにします。個々の方法の詳しい設定手順に代わるものではありません。機能の詳しい説明については、まずローカライゼーションと多言語メッセージをご覧ください。

考慮事項

  • パターンを選ぶ前に、ダッシュボードでのプレビューと QA、プロのワークフローによる翻訳、高頻度のコンテンツ更新、CMS 主導のリアルタイムなコピーのうち、どれが必要かを判断してください。
  • 多言語メッセージは、メール、プッシュ、バナー、アプリ内メッセージ、Content Blocks をサポートしています。SMS と WhatsApp では別のローカライゼーションパターンを使用することに注意してください。手動の Liquid、Content Blocks、カタログ、パートナー、Connected Content は、それらの機能がサポートされているチャネル全体に適用できます。
  • Braze は翻訳を生成しません。コピーは、ダッシュボード、CSV、API、カタログインポート、パートナーのワークフロー、または外部 CMS を通じて提供します。
  • 条件分岐を埋め込んだ手動の Liquid や Content Blocks では、言語数が増えるにつれて命名規則とレビュープロセスが必要になります。多言語機能やパートナーのワークフローでは更新を一元管理できますが、CSV や API のメンテナンスが必要になる場合があります。
  • Connected Content や一部のパートナーフローは外部システムに依存します。送信時に API や CMS が利用できない場合、ローカライズされたコンテンツを読み込めないことがあります。
  • 複数の方法を併用するのは一般的です。たとえば、同じプログラム内で、メール本文には多言語タグ、共通のフッターには Content Blocks、商品のコピーにはカタログを使用することがあります。

設定

ステップ 1: ローカライゼーションの要件を把握する

要件 確認すべき質問
プレビューと QA マーケターは送信前に Braze のコンポーザーで各ロケールをプレビューする必要がありますか?
規模 対応する言語の数と、コピーの変更頻度はどのくらいですか?
ワークフロー 翻訳者によるレビュー、修正、承認が必要ですか?
データの形式 コピーは自由形式のマーケティングテキストですか、それとも構造化された商品フィールド (名前、価格、URL) ですか?
オートメーション CMS の変更時に翻訳を自動で更新する必要がありますか?
チームのスキル チームで Liquid、CSV アップロード、API、パートナー連携を運用できますか?

ステップ 2: アプローチを比較する

観点 手動の Liquid Content Blocks カタログ 多言語メッセージ 翻訳パートナー Connected Content
ダッシュボードでのプレビュー / QA 可 可 可 可 パートナーにより異なる 限定的 (取得したコンテンツのプレビューが難しい)
デフォルト (連携不要) 可 可 一部 (カタログの設定が必要) 可 不可 (ベンダー側の設定が必要) 不可 (API または CMS が必要)
対応チャネル サポートされているすべてのチャネル サポートされているすべてのチャネル サポートされているすべてのチャネル メール、プッシュ、バナー、アプリ内メッセージ、Content Blocks パートナーにより異なる サポートされているすべてのチャネル
実装の工数 低 低〜中 中 低 高 (パートナーによる) 中
継続的な (BAU) 工数 高 (メッセージごとに編集) 中 (ブロックのメンテナンス) 中 (CSV または API での更新) 中 (CSV アップロード) 中 (プラットフォーム上で管理) 低 (送信時に取得)
高頻度の更新 不可 一部 不可 一部 可 可
プロの翻訳ワークフロー 不可 不可 不可 不可 可 不可
構造化データ / 商品データ 限定的 限定的 可 (キーで管理するコピーに最適) 限定的 パートナーにより異なる 可 (外部ソース経由)
外部依存のリスク なし なし なし なし 中 中 (ソースが停止すると送信に失敗)
最適なケース 言語が少なく、更新頻度が低い 複数のメッセージで共通のコンポーネントを使う 多数のロケールで構造化された文字列を扱う 多数の言語をコピー&ペーストの手間を抑えて扱う 承認フローを伴うエンタープライズ向け翻訳 CMS 主導のダイナミックなローカライゼーション

ステップ 3: Kitchenerie のようなシナリオに合うアプローチを選ぶ

Kitchenerie のシナリオ 推奨される出発点
3 言語、月あたりのキャンペーン数が少なく、マーケティングチームが小規模 手動の条件付き Liquid、または Liquid を使った Content Blocks
メールとアプリ内メッセージで共通のヘッダー、フッター、法的表記ブロックを使う Content Blocks (ロケールが増える場合はブロックに多言語の翻訳を保存)
ロケールをキーにした商品名、プロモーション文、画像 URL カタログ
コンポーザーでのプレビューが必要な、8 つ以上のロケールでのメールとプッシュ 多言語メッセージ
翻訳者のワークフローと承認を伴う一元的な TMS ローカライゼーションパートナー (Smartling や Phrase など)
毎日更新される CMS で管理しているコピー Connected Content

ステップ 4: 選択したアプローチを実装する

  1. 手動の条件付き Liquid: プロファイルの language またはロケール属性を、if / elsif / else の Liquid と組み合わせて使用します。代替アプローチと条件付きロジックを参照してください。
  2. Content Blocks: 再利用可能なブロックを作成します。必要に応じて、条件付き Liquid をブロック内に隠すこともできます。Content Blocksと、翻訳されたメッセージの送信の Content Blocks タブを参照してください。
  3. カタログ: 翻訳の行 (id、context、language、body など) をインポートし、Liquid の catalog_items で参照します。翻訳されたメッセージの送信のカタログタブを参照してください。
  4. 多言語メッセージ: ロケールを追加し、コピーを翻訳タグで囲んでから CSV をアップロードします。翻訳エンドポイントの早期アクセスを利用している場合は、代わりに API で翻訳を更新できます。コンポーザーで 多言語ユーザー を使ってプレビューします。
  5. 翻訳パートナー: ワークスペースのロケールを設定してから、パートナー連携の手順 (Smartling や Phrase など) に従います。
  6. Connected Content: 送信時に CMS または翻訳 API を呼び出します。十分にテストしてください。プレビューにはライブの API レスポンスが反映されない場合があります。Connected Contentを参照してください。

地域をまたいだキャンバスやキャンペーンのオーケストレーション (1 つのジャーニーにするか、国ごとに 1 つのジャーニーにするか) については、ローカライゼーションのページの翻訳管理を参照してください。

New Stuff!