多言語Webサイトで最も起こりやすい問題は、初回翻訳ではなく、コンテンツが継続的な更新段階に入った後に発生します。中国語版の製品パラメータが変更されても英語ページは旧バージョンのまま、ランディングページにフォーム項目が追加されても日本語ページには反映されない、記事のタイトル・説明・画像を差し替えても一部の言語では古いSEO情報が残っている、といった状況です。ページ自体は正常に閲覧できても、コンテンツの整合性、コンバージョン導線、検索エンジンが認識できる情報はすでに分断され始めています。
CMS翻訳で自動同期を実現する核心は、「変更後に直ちに機械翻訳する」ことではなく、コンテンツの分割、変更の識別、翻訳タスク、レビュー・公開、バージョンの書き戻しを追跡可能なプロセスとしてつなげることです。ソースコンテンツ、言語バージョン、ページコンポーネントの間に安定した関連付けが維持されて初めて、システムはどの項目を更新すべきか、どのコンテンツを上書きすべきでないか、どの翻訳文がまだ承認されていないかを判断できます。
多くのサイトでは cms 翻訳を設定する際、「ソース言語ページの更新」を「すべてのターゲット言語ページへの自動上書き」に直接設定しています。この方法は初期段階では手間を省けますが、その後に人手で調整した翻訳文を破壊しやすくなります。たとえば、英語市場向けページでローカルの検索習慣に合わせてタイトルを修正済みであり、ソースページでは製品サイズの項目だけを更新した場合、ページ全体を上書きすると、人手で最適化したタイトルと説明まですべて置き換えられてしまいます。
より確実な方法は、コンテンツの種類に応じて同期の粒度を定義することです。通常、項目は次の3種類に分けられます。
設定前にこの分類を完了しておくことで、自動同期が「差異を自動的に生み出す」ことを防げます。特に、ページが複数の再利用可能なモジュールで構成されている場合は、各モジュールがグローバル共有、言語別独立、または部分的な上書きを許可するもののどれに属するかを明確にする必要があります。
自動同期は、タイトル、URL、ページ上の位置による照合ではなく、安定したコンテンツIDに依存します。各ソース記事、各製品、各コンポーネントには一意の識別子を付与し、その翻訳バージョンには対応するソースコンテンツID、ターゲット言語コード、翻訳文のバージョン番号、公開ステータスを保存する必要があります。ページにモジュールを追加した際、システムはこれに基づいて、それが既存モジュールの変更ではなく「新規の翻訳待ちコンテンツ」であることを識別できます。
実際の設定では、CMSに少なくとも次の情報を記録させることを推奨します。
ここでいう「項目レベルの更新日時」は特に重要です。ソースページで画像のALTテキストを更新しても、本文全体を翻訳待ちにするべきではありません。製品パラメータだけを修正した場合も、翻訳者はページ全体の内容を再比較するのではなく、具体的な変更項目を直接確認できるべきです。

比較的信頼性の高いプロセスは、通常、公開イベントによって開始されます。ソース言語のコンテンツが下書きから公開済みに変わると、CMSはコンテンツのスナップショットを生成します。システムは現在のスナップショットと直前の公開バージョンを比較し、追加・変更・削除された項目の一覧を出力し、さらに項目ルールに従って各言語の翻訳タスクを作成します。翻訳サービスの完了後、翻訳文はまず「レビュー待ち」ステータスとなり、レビュー承認後にターゲット言語の公開済みバージョンが更新されます。
トリガールールは、「公開したら翻訳する」という単一のスイッチだけにすべきではありません。業務の進行に応じて異なる優先度を設定できます。
削除の同期は見落とされがちです。多言語サイトにおいて、ソースページが非公開になったにもかかわらず翻訳ページが200ステータスを返し続けると、訪問者に古いコンテンツを見せるだけでなく、言語切り替え後に無効なページへ遷移する原因にもなります。ワークフローでは、削除を同期削除とするのか、下書きに戻すのか、または保持してリダイレクトページに変更するのかを明確にすべきです。
翻訳タスクの完了後は、タスクのステータスが成功していることだけを確認してはなりません。翻訳文の基となったソースバージョンが、現在も最新バージョンであるかを照合する必要があります。よくあるケースとして、翻訳文の生成中にソースページが再度変更されることがあります。この場合、最初に返された翻訳文は言語的に問題がなくても、すでに現在のソースコンテンツより古いものです。
「ソースバージョンのロック」メカニズムを採用できます。タスク作成時にソースバージョン番号を書き込み、翻訳文の返却時にCMSがその番号と現在のソースバージョン番号を比較します。両者が一致する場合、翻訳文はレビューに進めます。一致しない場合は、タスクを期限切れとしてマークし、結果は参照用に保持しますが、直接公開することは許可しません。頻繁に更新される商品ページでは、この手順により、編集者が古い翻訳文を誤って公開することを防げます。
レビュー画面では、差分を目立つように表示するのが望ましいです。追加項目、削除された文、変更前後の内容、機械翻訳文と公開済み翻訳文を表示します。編集者は変更箇所を画面ごとに探すことなく、部分的に統合するか全文を再レビューするかを判断できます。リッチテキスト、表、ダウンロードリンク、埋め込みコンポーネントを含むページでは、タグ、プレースホルダー、変数が完全に保持されているかも確認する必要があります。
本文の同期が完了しても、ページ全体の更新が完了したとは限りません。タイトル、Meta Description、画像ALTテキスト、構造化データ内の名称と説明、パンくずリスト、Open Graph項目は、多くの場合、CMSの異なる設定階層で管理されています。これらの項目が翻訳関係に紐付けられていなければ、ページ本文は新しい内容である一方、検索スニペットは依然として旧バージョンのままという状況が発生します。
SEO項目は、独立した翻訳可能項目として扱い、長さおよび文字数制限の通知を設定することを推奨します。URLは通常、機械的に同期することは推奨されません。言語ディレクトリ構造の一貫性は保ちつつ、ターゲット言語で現地の検索習慣に合った短いリンクを使用できるようにするべきです。hreflangの関連付けについては、言語バージョンの公開、非公開、またはURL調整時に自動更新し、削除済みの言語ページが相互リンク関係に残らないようにします。
ログイン、注文、会員情報、API転送に関わるページでは、コンテンツ同期後にすべての言語ルートでHTTPSが利用可能であることも確認する必要があります。特に、新しい言語のサブドメインやECサイトのパスを追加する際、証明書の導入漏れはリダイレクト、フォームの読み込み、リソースリクエストの異常を引き起こします。自動導入、HTTPからHTTPSへのリダイレクト、混在コンテンツの修正をサポートするSSL証明書を活用し、新しい言語パスの通信セキュリティ確認を、ブラウザがリスクを警告してから調査するのではなく、公開前の検証に組み込むことができます。
一括同期のたびに、ページを1つずつ閲覧するよりも、まずステータス異常を確認します。重点項目には、ソースバージョンが翻訳文バージョンより新しいページ、翻訳に失敗した項目、公開済みであるにもかかわらず言語関連付けがないページ、ソースページで削除されたのに依然としてアクセス可能な翻訳ページ、未置換の変数または空のリンクを含むコンテンツブロックなどがあります。製品詳細ページでは、パラメータ表の単位、添付ファイルへのリンク、問い合わせフォームの項目、在庫表示がソースページのロジックと一致しているかも確認する必要があります。
最後に、明確な公開基準を設定できます。強制同期項目が完了していない場合はターゲット言語ページの公開を許可せず、ローカライズ項目が不足している場合は公開を許可しつつ編集者に通知し、SEO項目のみがレビュー待ちの場合はページの種類に応じて公開を保留するかを決定します。これにより、自動化は識別と配信を担い、編集者は市場向けの表現と最終バージョンに対する管理権を維持できます。
関連記事
関連製品