多くの経営者が初めて多言語ウェブサイトを作るとき、考え方はとてもシンプルです。中国語のコンテンツを翻訳して、言語切り替えボタンを付けて、公開すれば完了だと思っています。
しかし公開から3ヶ月、海外からの問い合わせはほとんどなく、管理画面にはトラブルばかりが増えていきます。英語ページがインデックスされない、価格の単位が間違っている、ドイツ語版のレイアウトが完全に崩れている。
多言語ウェブサイト開発の難しさは、決して翻訳にあるのではなく、構造設計と長期的な保守にあります。以下に挙げる点は、着手前にしっかり考えておくことをお勧めします。
一、まず言語と地域を決める。国だけで分けない
言語と地域は別物です。同じ英語でも、アメリカ、イギリス、東南アジアのユーザーでは語彙の習慣も価格設定の方法も異なります。同じ中国語でも、簡体字と繁体字では対象市場が違います。
進め方としては、まず表を1つ作ります。対象市場、使用言語、通貨単位、連絡先、コンプライアンス要件。この表が、その後のすべてのページ構造を決定します。
注意点：最初から十数言語を展開しないこと。企業サイトの多言語版は、まず2～3の主要市場で始め、軌道に乗ってから拡大しましょう。言語が増えるほどコンテンツ同期のコストが高くなり、最終的には大半の言語版が半年間更新されないという状況になりがちです。
二、URLとディレクトリ構造は一度で決める
多言語サイトの一般的な方法は3つあります。サブディレクトリ、サブドメイン、独立ドメインです。
ほとんどの企業にとって、サブディレクトリが最も手軽です。例えば `/en/`、`/ja/` などで、評価が集中し、運用も簡単です。サブドメインは各市場を独立運営するチームに向いています。独立ドメインはコストが最も高く、現地に独立した法人がない限りお勧めしません。
ここで見落とされがちな点があります。言語を切り替えた後、ユーザーは現在のページの対応言語版に留まるべきで、トップページに戻されるべきではありません。この体験の細部は、ウェブサイト開発段階で要件に盛り込む必要があり、後から追加するのは非常に面倒です。
また、各言語版には独立したタイトル、ディスクリプション、hreflang の注記が必要です。そうでないと、検索エンジンが複数バージョンを重複コンテンツと見なす可能性があります。
三、コンテンツ保守は開発より時間がかかる
多言語サイトの公開はあくまで始まりです。本当に試されるのは、中国語版で製品パラメータを変更したとき、英語版はいつ追従するのかという点です。
管理画面の段階でコンテンツモデルを設計しておくことをお勧めします。製品名、パラメータ、セールスポイント、事例をフィールド単位で管理し、翻訳もフィールド単位で対応させ、ページ全体をコピーしないようにします。こうすれば、1つのパラメータを変更したとき、各言語版に更新待ちの通知を同期できます。
具体的な例を挙げます。産業機器の会社がコーポレートサイトをリニューアルする場合、製品ページには40以上の型番があり、各型番に6つのパラメータがあります。ページ全体を翻訳する方式だと、パラメータを1回変更するたびに5言語を人手で照合する必要があります。フィールド単位で管理すれば、管理画面で1箇所変更すれば、他の言語は赤くマークされて翻訳待ちになり、作業量が数倍変わります。
こうした要件は、しばしばミニプログラム開発やバックエンド管理システムと一緒に発生します。フロントの表示は表層に過ぎず、その下にはコンテンツ管理のロジックがあります。
四、組版、日付、通貨といった細部が最も体験を損なう
中国語の2文字の情報が、ドイツ語では20文字になることがあります。ボタン、ナビゲーション、表の列幅は、最も長い言語に合わせて余裕を持たせる必要があります。
日付形式、数字の区切り文字、通貨記号、住所の順序も、地域に合わせて適応させる必要があります。これらは翻訳では解決できず、フロントエンドとデータ構造の問題です。
注意点：画像に文字を載せないこと。多言語版が増えると、画像内の文字の修正は非常に苦痛になります。テキストで表現できるものはテキストを使い、フォントと行の高さは言語ごとに個別に調整しましょう。
五、パフォーマンスとセキュリティはメインサイトだけを見ない
多言語サイトで起こりがちな問題があります。メインサイトは速いのに、ある言語版は非常に遅い。原因は通常、静的リソースの多地域配信が行われていないか、翻訳APIの同期呼び出しがファーストビューを遅くしていることです。
方法としては、言語パックと静的リソースを分けてデプロイし、ファーストビューでは現在の言語のみを読み込みます。セキュリティ面では、多言語サイトのフォーム、検索、言語切り替えパラメータはすべて入口となります。公開前にウェブサイトセキュリティテストを一巡行うのが稳妥です。特に問い合わせやアカウント体系が関わる場合には重要です。
会員、注文、多通貨決済を伴うシステムの場合、テスト範囲は権限と決済フローもカバーする必要があります。こうしたシステムの複雑さは軽量な App開発に近く、展示型コーポレートサイトの基準で受け入れ検査はできません。
MIC Studio に依頼すべきケース
3～5ページの展示サイトに1～2言語を追加するだけであれば、既存のサイトビルダーツールでも対応できます。
しかし、以下のようなケースでは専門チームと一緒に整理することをお勧めします。多言語コンテンツを長期的に同期する必要がある、社内の ERP や CRM と連携する必要がある、多通貨・多地域の権限を扱う必要がある、あるいは既存の企業サイト構造がすでに乱れていて再構築が必要な場合です。
MIC Studio はウェブサイト開発やバックエンドシステムを多く手がけており、まずコンテンツモデルと言語構造を定めてからページについて話す習慣があります。また、ミニプログラム開発、App開発、スクリプト開発、リバースエンジニアリングテストも行っており、多言語サイトがAPI連携やセキュリティ検証を伴う場合も、1つのチーム内でクローズできます。
実行可能な3つの提案
1. 着手前に市場と言語の対照表を書き、まずどの2～3言語を進めるかを明確にし、残りはスケジュールを組む。
2. URL構造、言語切り替えロジック、hreflang の注記を要件定義書に盛り込み、公開後に追加しない。
3. コンテンツはフィールド単位で管理し、翻訳ステータスのマークを用意する。公開前にパフォーマンスとウェブサイトセキュリティテストを一巡行い、フォームとAPIをすべて確認する。