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

03 / BUILD

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

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

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

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

PRACTICAL KNOWLEDGE 実務知識

WRITTEN BY

FHW制作チーム

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多言語公開チェック

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

PRACTICAL KNOWLEDGE 同じフェーズの実務知識

私たちが別の制作で得た判断や確認方法を、同じ制作フェーズからご覧いただけます。

複数社でWeb制作の引き継ぎ内容を確認する作業デスク

自社で公開できないWeb制作で、入稿・納品・確認の責任範囲をどう決めるか

外部CMSや別会社の環境へ入稿・納品する制作で、利用できる技術、確認段階、修正の戻し先、完了条件をどう決めるか整理します。

支給デザインを共通ルールと例外へ分けて確認する制作チーム

支給デザインを、共通ルール・例外・動作仕様へどう変換するか

Figma、画像、印刷物、参考サイトなどの支給物から、共通部品、例外、可変条件、レスポンシブ、動作仕様を整理し、複数人で再現できる実装ルールへ変換する方法をご紹介します。

急増したAPI利用料金の請求明細とグラフを確認する制作チーム

55万円請求を生んだ、公開ページと従量課金APIを直結する落とし穴

公開ページへの機械的な大量アクセスが従量課金APIの大量実行へ増幅され、約55万円の請求に至った経験から、外部APIの費用上限、クォータ、キャッシュ、監視の設計を整理します。

公開日時と素材の進行状況を確認するWeb制作の作業デスク

公開日を動かせないWeb制作で、未確定素材・版管理・日時公開をどう管理するか

公開日時が固定された制作で、後から届く素材、複数の版、日時指定公開、公開直前の変更を安全に管理する方法をご紹介します。

Web制作中に増えた要望と工程への影響を整理する制作チーム

その追加要望、今入れますか? Web制作中の変更をどう判断するか

Web制作中に増えた要望を、目的、合意範囲、影響する工程、費用、日程、公開時期から確認し、修正・追加対応・公開後対応へ整理する方法をご紹介します。

短納期の制作で公開条件と後工程をカードに分ける制作チーム

短納期のWeb制作で、削ってよい工程・削ってはいけない確認は何か

短い制作期間で、共通ルール、未確定素材、確認範囲、公開後へ送る改善を整理し、速さのために品質判断まで省略しない進め方をまとめます。

受付窓口で申込書と処理の流れを確認する担当者と利用者

紙・PDFで続けてきた申込・注文業務を、どうWebへ移すか

紙やPDFで行ってきた申込・注文業務をWeb化するとき、利用者の操作、受付側の確認、例外処理、計算、保存、外部連携までを一続きで設計する方法を整理します。

公共空間でスマートフォン、タブレット、ノートPCを使う人々

対応端末・ブラウザは、利用場面からどう決めるか

Web制作の対応端末とブラウザを、利用者、場所、主な操作、重要度から優先・代表・簡易確認へ分け、境界の内容と再現情報を確認する方法を整理します。

Webフォームの入力から通知までを検証する作業デスク

フォームの送信確認で、通知・自動返信・保存データ・担当振り分けまでどう検証するか

Webフォームについて、入力・確認・送信だけでなく、管理者通知、自動返信、保存データ、担当振り分け、本番環境でのメール到達までを一続きで検証する方法を整理します。

CSVの一括更新結果と既存データへの影響を確認する資料

CSVで一括登録・更新するとき、既存データをどう守るか

CSVの一括登録・更新で、識別キー、空欄、部分失敗、事前確認、再実行、復旧を安全に扱う確認方法を整理します。

更新担当者と制作会社がページテンプレートの編集範囲を確認する作業台

お客さまもHTML・CSSを更新するサイトで、編集範囲をどう設計するか

お客さまがHTML・CSSを直接更新するWebサイトで、編集できる範囲、共通部品、CSSの影響範囲、変更履歴、制作会社へ相談する条件をどう決めるか整理します。

会員の登録状態と役割ごとの権限、外部連携を整理した立体模型

会員サイトで、登録状態・役割・権限・外部連携をどう設計するか

会員サイトの登録途中を含む状態、役割ごとの操作権限、外部サービスとの状態差、機能を段階公開する場合の判断方法を整理します。

少量のサンプルから本番規模の多様なコンテンツへ広げて検証する模型

少量のサンプルで動くWebサイトを、本番規模でも崩さないために何を試すか

数件のきれいなデータだけでは見つからない、最大件数、長文、画像量、空欄、ページ送り、一括処理の問題を公開前に確かめる方法を整理します。

共通基盤でつながりながら役割を分けた複数サイトの建築模型

複数サイト・複数部署で、共通部分と運用範囲をどう分けるか

複数サイトや複数部署で運用するとき、共通化する見た目・情報・仕組み、権限、公開日、正となる情報源をどう分けるかを整理します。

光と布の動きが段階的に変化する展示空間

動きのあるデザインを、雰囲気ではなく実装仕様へどう変えるか

参考サイトやデザインの動きを、開始条件、時間、順番、終了状態、読み込み、端末ごとの代替表現へ分解し、安全に実装する方法を整理します。