本文へスキップ
  1. TOP
  2. Web制作
  3. 実務知識
  4. 多言語サイトで、翻訳原稿・共通部品・段階公開をどう同期するか

03 / BUILD

つくるフェーズの実務知識

多言語サイトで、翻訳原稿・共通部品・段階公開をどう同期するか

ページと言語の対応、原稿状態、公開可否を一つの制作工程として管理する

原稿から複数言語のページと公開状態へ展開する編集工程

PRACTICAL KNOWLEDGE 実務知識

WRITTEN BY

FHW制作チーム

反省会と日々の制作記録をもとに、担当スタッフが実際に迷い、確認し、判断した過程を整理しています。

多言語制作は、翻訳原稿がすべて届いてから始める仕事とは限りません。日本語ページが順番に確定し、翻訳はページごとに届き、言語によって確認者や公開日が異なることがあります。

私たちが多言語制作で避けたいのは、全翻訳を待って公開全体が遅れることと、未確認の原稿を先に出してしまうことです。ページと言語の組み合わせを制作単位として扱い、完成したページを待たせず、未確定の翻訳を誤って公開しない流れを作ります。URL構成など前段の考え方は、多言語サイトの設計ページで整理しています。

最初に「対になるページ」を決める

URLだけを並べるのではなく、各ページの役割と公開状態まで対応表にします。

  • 両言語で同じ役割を持つページ
  • 一方の言語だけに存在するページ
  • 内容は共通だが承認や公開時期が異なるページ
  • 言語ごとに法的表記や問い合わせ先が異なるページ

この対応表を、翻訳順、言語切替、内部リンク、サイトマップ、公開確認の基準にします。URLがあるかではなく、移動先として使える状態かを記録します。

翻訳原稿は、ファイル名ではなく状態で追う

「最新版」「最終版」というファイル名だけでは、翻訳中なのか、内容確認が済んだのか、公開画面まで確認したのかを区別できません。

未着、翻訳中、内容確認中、確定、反映済み、公開確認済みなど、工程に沿った状態で管理します。原文側が変わったのか、翻訳側だけを直したのかも分け、原文更新の翻訳漏れを追えるようにします。

共通化するのは構造であり、文字数ではない

見出し、カード、ナビゲーション、フォーム項目などの構造は共通化できます。ただし、改行位置、固定の高さ、ボタン幅まで同じにすると、言語ごとの文字量差で崩れます。

長い見出しや説明でも伸びる構造にし、固定座標へ文字を置かず、PCとスマートフォンの両方で長い内容を確認します。共通部品は同じ文字数を求めるのではなく、異なる文字量を受け止められるようにします。

段階公開では、移動先が確認済みかを基準にする

言語切替は装飾ではなく、別ページへのナビゲーションです。移動先が未公開なら切替を隠す、確認済みの案内ページへ向ける、言語版が揃うまで切替自体を出さない、といった扱いを決めます。

対応ページ、内部リンク、フォーム、サイトマップ、計測を言語ごとに確認します。一部言語だけ先に公開するときも、公開中のページから未完成ページへ到達しないことを確かめます。

原文を更新した後の流れまで決めておく

基準言語、翻訳が必要な変更、翻訳の期限、翻訳待ちの表示を事前に決めます。数値や日付、重要なお知らせ、商品・採用情報など、差異の影響が大きい内容は優先して同期します。

言語ごとに承認者が違う場合は、ページ構造を共通にしても公開状態は分けます。更新方法まで決めておくことで、公開時に揃っていた言語が運用開始後にずれていくことを防ぎます。

この方法が向いているケース

  • 複数言語を並行して制作する
  • 翻訳原稿がページごとに届く
  • 言語ごとに確認者や公開日が異なる
  • 一部の言語だけ先に公開する
  • 共通テンプレートで文字量差を吸収したい

別の方法を選ぶべきケース

対象者、掲載内容、法的責任、問い合わせ先が言語ごとに大きく異なる場合は、翻訳版ではなく別サイトとして設計した方が安全です。自動翻訳を使う場合も、固有名詞、制度名、重要なお知らせを誰が確認するかは残ります。

多言語公開チェック

  • ページと言語の対応表があるか
  • 確定、反映済み、公開確認済みを区別しているか
  • 原文変更から翻訳対象をたどれるか
  • 長い文章で共通部品の表示を確認したか
  • 未公開ページへ言語切替が向いていないか
  • 内部リンク、フォーム、サイトマップを言語ごとに確認したか
  • 公開後の更新と差異の扱いを決めたか