チームが実際に必要としている単一エントリー翻訳のショートカット

多くの翻訳ワークフローには、明らかに2つのモードがあります。1つのフィールドを手動で翻訳するか、大きなバッチをシステムに送るかです。気まずい中間ケースは、チームが認める以上によくあります。

単一のページが変更される。ローンチに重要なヘルプ記事の準備が整う。製品発表をサポート対象のすべてのロケールで公開する必要があるが、CMS内の他のものは一緒に動かすべきではない。

そのために、完全なバッチを手作業で組み立てる必要があってはなりません。

すべてのエントリーをバッチにすることの問題

バッチは、対象範囲が自然に広いときに役立ちます。関連するエントリーをまとめて保持でき、進捗を可視化し、レビュー、反映、公開アクションを管理するための場所をチームに1つ提供します。

しかし、実際の作業が1つのエントリーだけなら、ユーザーに通常のバッチ作成を強いることは摩擦を増やします。

• バッチ名を付けなければならない
• 同じエントリーをもう一度探さなければならない
• 対象ロケールを選ばなければならない
• その後に自動化を実行すべきかどうかを覚えておかなければならない
• いずれにせよ別の場所で進捗を確認しなければならない

これらのどれも戦略的な作業ではありません。単なるワークフロー上の税金です。

よりよい形: 1つのエントリー、複数ロケール

正しいショートカットはシンプルです。エントリーから対象ロケールを選び、そのエントリーだけを含む小さなバッチを作成します。

そうすることで、ユーザーに手作業でバッチを組み立てさせることなく、チームはバッチ基盤の利点を得られます。

また、メンタルモデルも明快に保てます。ユーザーが言っているのは「キャンペーン翻訳プログラムを始めたい」ではありません。「このエントリーを必要なすべての場所へ翻訳したい」です。

それでもバッチになるべき理由

バッチ層を完全に隠したくなるかもしれませんが、通常それは後になってより大きな混乱を生みます。複数のロケールが関わる時点で、その作業はバッチのような振る舞いをします。

• 各ロケールは異なるタイミングで完了する可能性がある
• あるロケールは成功し、別のロケールは失敗する可能性がある
• 反映と公開の自動化には共有された制御が必要になる
• ダイアログを閉じた後も進捗が見える状態である必要がある

作成後にユーザーをバッチ詳細ページへ送るのは、誠実なUIです。これにより、今まさに実行中の作業が示され、チームはあらゆる複数ロケール翻訳実行に期待するのと同じ制御を得られます。

これがローンチチームにもたらすもの

単一エントリー・複数ロケール翻訳は、きれいなリリースバッチの外側にあるコンテンツに対して特に有用です。

• 新たに承認された法的通知
• 緊急のサポート記事
• 価格ページの修正
• レビュー後に変更されたオンボーディングページ
• キャンペーンの残りより先に準備が整った、価値の高い1つのランディングページ

これらはエッジケースではありません。リリース週には普通に起こる瞬間です。

重要なガードレール

このショートカットは、2つ目のワークフローを作るべきではありません。同じ種類のリクエストレコードを作成し、同じモデル設定を使い、同じ権限を尊重し、同じバッチ詳細体験に着地するべきです。

そうすることで、レポート、再試行、自動化、レビューの挙動に一貫性が保たれます。

まとめ

優れたローカライゼーションツールは、よくある経路を短くしつつ、小さな違いごとに別のシステムを発明しないようにするべきです。

ユーザーが翻訳したいそのもののエントリーを見ているなら、ワークフローはそのエントリーを選択したロケールへ直接翻訳できるようにすべきです。裏側では、依然としてバッチであってかまいません。ユーザーにとっては、それが次に取るべき当然のアクションだと感じられるべきです。