多言語サポートシステム構築中

ウェブサイトに多言語（i18n）を入れてる。

uranai-musumeが日本ターゲットだし、今後グローバルも考えると最初から多言語構造を作っておくべきだと思って始めた。

🛠️ 進捗状況

1. next-intl設定完了

2. 翻訳作業

3. ハマったこと

🌏 なぜ3言語なのか？

多言語を後から追加しようとしてたら本当に苦労したと思う。最初から入れておいてよかった。

なぜ最初から3言語にしたのか

最初は「日本向けのサービスがあるから日本語だけでもいいのでは」とも思った。でもPark Labs自体は、一つのサービスだけを紹介する場所ではない。複数の実験を積み上げて、何を作り、何に失敗し、どこに可能性があるかを公開する場所だ。そう考えると、最初から言語の入口を分けておくことには意味があった。

韓国語は自分の思考に近い言語で、英語は将来的に海外の開発者や小さなチームにも届く可能性がある。日本語は生活圏とサービス展開の中心に近い。3言語を同時に持つのは重いけど、Park Labsの「実験を公開する」という性格には合っていると思った。

翻訳ではなく、運用設計の問題だった

やってみて分かったのは、多言語対応は翻訳の問題ではなく運用設計の問題だということ。ボタンの文言を置き換えるだけなら簡単だけど、URL、SEOメタデータ、OG画像、sitemap、記事、実験説明、ナビゲーション、フッターまで全部つながっている。

たとえば日本語ページだけ内容が濃くて、英語や韓国語が短いままだと、サイト全体の印象がずれる。ユーザーにとっても検索エンジンにとっても、「このページは本当に管理されているのか」という不安につながる。だから翻訳の量を増やすより、どの言語を主軸にして、どの言語を後から育てるかを決めることが大事だと感じた。

実装して見えた負荷

実装面では、localeをすべての内部リンクに通す必要があるのが一番地味に効いた。トップページ、実験一覧、ノート詳細、フッター、モバイルメニュー。どこか一つ抜けると404になる。最初は「リンクのprefixだけでしょ」と軽く見ていたけど、ページが増えるほど漏れやすくなる。

SSGとの相性も注意が必要だった。静的に出力するなら、各localeと各ページIDの組み合わせをビルド時に作る必要がある。ノートが増えるほど生成対象も増える。これはパフォーマンスにも関係するし、Cloudflare Pagesでの配信にも影響する。

AdSense目線での学び

AdSenseの目線で見ると、多言語サイトは強みにも弱みにもなる。各言語に十分な内容があれば、同じテーマを複数の読者に届けられる。でも言語ごとに薄いページが大量にあると、低価値コンテンツに見える可能性がある。

だから今後は「全部の言語を同じ速度で完璧にする」より、「主軸の日本語をしっかり育て、他の言語は無理にindexさせない」という判断も必要になる。多言語対応は見た目のグローバル感ではなく、信頼できる情報構造として運用しなければ意味がない。

次に直すこと

次は、言語ごとの内容差をちゃんと見える化したい。どのノートが十分な長さで、どのノートがまだ短いのか。どのページをsitemapに出し、どのページをnoindexにするのか。これを感覚ではなく基準で管理できるようにしたい。

多言語対応は一度作って終わりではない。新しい実験、新しいノート、新しいページを追加するたびに運用負荷が増える。だからこそ、最初から構造を作っておいたことは間違っていなかったと思う。あとは、その構造に見合うだけの中身を少しずつ育てること。