18ways blog

i18n は壊れている: 翻訳キーを書くのはやめよう

Next.jsで、SEOを損なわずにi18nを実現するAIネイティブな方法。

国際化（しばしば i18n と略される）、ローカライゼーション（l10n）、そして 多言語対応 は、いずれも同じ考え方を指します。つまり、ユーザーが自分の言語で使えるように製品を適応させることです。

i18n は、いまだに2005年の作りのままだ

どの企業も、いずれ多言語対応が必要だと気づきます。その時点でプロダクトチームは整備士のように背もたれに寄りかかり、歯の間から息を吸いながらこう言うのです。「何ページあるんですか？ 少なくとも4スプリントは必要ですね。」

従来の i18n 作業にかかるコストと手間への、整備士風の反応

i18n の実装方法の根本は、20年間ほとんど変わっていません。i18n の「ベストプラクティス」の多くは、現代的なWebアーキテクチャが生まれるずっと前に形作られ、その後のあらゆるものはただその上に積み重ねられてきただけです。

i18n は、現代のWeb開発の中でいまだにファイルを書き出して誰かに送る、という作業が残っている唯一の分野です。メールで送る代わりに API 経由でアップロードするなら、それはもう現代的な構成だと見なされます。

CI パイプラインと、数日ではなく数分単位でデプロイが測られる世界では、もう何かをファクスしなくて済むだけでもありがたいと思うべきでしょう。

i18n が壊れていると感じる理由

現代のWeb開発は、驚くほど速く進化してきました。

私たちには次があります。

それでも、国際化のワークフローは今もなお別の時代のもののように感じられる。

比較的小さなアプリケーションでさえ、すぐに次のような要素を扱うことになる:

開発者が、こういうシステムを作ろうとして始めるわけではありません。言語ごとに文の構造がまったく違うことを知らない開発者が、よくある i18n の落とし穴に足を取られて、そこへよろめきながら入り込み、20年前に定められた現状をしぶしぶ受け入れるのです……。

時が経つにつれ、国際化はスタックの中でも最も複雑な部分の一つになっていく。

現代のUIは翻訳文字列の中に収まらない

シンプルな UI を考えてみましょう:

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

これは理解しやすいです。シンプルです。

ある時点で、私たちはそれを国際化することにします。そこで、テキストを翻訳ファイルへ抽出します:

json
{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

そして、その参照をコード内で行います:

jsx
<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

でも待ってください。今ではコードにも翻訳ファイルにも英語のテキストがある、ということですよね？ ええ。i18n ライブラリごとに見た目は少し違いますが、人間が読める JSON ファイルに切り出して、部分的に整形されたテキストを翻訳しようとするのは、負け戦です。

現代のUIは構造化されていますが、翻訳システムは平坦な文字列を土台として作られています。

マークアップ、変数、動的コンテンツが入ってくると、その抽象化はほころび始める。

動的コンテンツとユーザー生成コンテンツは従来のi18nを壊す

コンテンツが静的でないと、事態はさらに難しくなります。

もう一度、この例を見てみましょう:

jsx
<b>{serverResponse.productDescription}</b>

その文字列はAPIから来ている。これをどうやって翻訳キーに変えるのか？

結論: そんなわけがない。つまり今度は、バックエンドにも国際化対応が必要になる。

バックエンドで管理すべきものは次のとおりです：

翻訳者にも、突然バックエンドシステムへのアクセスが必要になります。

そして、ユーザー生成コンテンツが入ってくると、問題はさらに大きくなります。

レビュー。コメント。マーケットプレイスの掲載情報。フォーラム。

従来の i18n パイプラインは、開発者があらゆるテキストを管理していることを前提にしています。ですが今や、それはもはや真実ではありません。

Amazonのような企業が2026年になって翻訳済みのユーザーレビューを試し始めたという事実は、i18nエコシステムの進化がどれほど遅かったかを物語っている。

ロケール検出はいまだに混乱のままだ

ユーザーがどの言語を望んでいるのかを判断するだけでも、驚くほど複雑です。

ブラウザーは Accept-Language ヘッダーを通じて言語の優先順位を送信します。

text
Accept-Language: en-GB,en;q=0.9,fr;q=0.8

これはサーバーにこう伝えます。

  1. イギリス英語を優先
  2. それから、あらゆる種類の英語
  3. それから、あらゆる種類のフランス語

実際にこれを正しく実装するには、次のようなものが必要です。

多くのフレームワークでは、このロジックの大半が開発者任せになっています。

基本的なロケール検出ですら、独自のアプリケーションコードになりがちです。

言語切り替えは後回し

翻訳インフラは問題の半分にすぎません。

ユーザーには、やはり言語を切り替える手段が必要です。

多くの i18n ライブラリは翻訳レイヤーは提供しますが、残りの問題は開発者に丸投げします:

こうした細部は小さく見えても、すぐにアプリケーションの面倒な土台仕事として大きな負担になります。特に i18n の入り組んだ点をすべて把握していないならなおさらです。そうでない会社や開発者のほうが、むしろ普通です。

近道：ウェブサイトの自動翻訳

これだけ複雑だと、サイト全体の自動翻訳ツールに頼るチームも出てきます。こうしたプラットフォームは、最小限の手間でサイトを自動的に翻訳できると約束します。

この発想を、より高度な形で実装している企業は複数あります。残念ながら、そこには別の問題が生まれます:

その結果、技術的には複数言語に対応していても、体験は明らかに悪くなり、開発者にとっては扱いにくいブラックボックスのようなサイトになりがちです。

ここに至るまで

私たちは、見事なほどシンプルなものから始めました:

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

そして、翻訳キー、JSON 辞書、分断されたパイプライン、分かれたバックエンド／フロントエンドのローカライズ層、外部の翻訳ツールへと行き着きました。

現代のWebアプリは、驚くほど高度なシステムです。にもかかわらず、i18n ツールは、まるでエンジン始動に手回しクランクが必要なフェラーリのように、別の時代向けに設計されたワークフローを前提にしています。

モデルを見直す

もし国際化がこんなふうだったら？

jsx
<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

翻訳キーは不要。

JSON 辞書はありません。

手作業のパイプラインは不要です。

ただのテキスト。

別のアプローチ

この考え方こそが、18waysの土台です。

18ways は翻訳を最適化されたランタイム上の関心事として扱います。翻訳キーの抽出や翻訳ファイルの管理は、人間ではなく機械の仕事です。

開発者は、翻訳したいテキストに印を付けるだけだ。

裏側では、18ways は次のことを行います:

すべてが SSR に適したままで、SEO にも安全です。

文脈を考慮した翻訳

従来のi18nシステムは文脈を失う。

翻訳者の目には、こんなふうに映るかもしれません:

text
home

でも、それはどういう意味でしょうか。

ドイツ語では、これらの意味にはまったく別の単語が必要になる:

「home」をドイツ語に訳すとしたら、どちらを見たいですか？ 単独の文字列ですか、それとも実際に表示されるページですか？

孤立した JSON 文字列を翻訳する場合と、サイト全体の文脈の中で翻訳する場合の比較

孤立した文字列しか見えない翻訳システムでは、こうした違いを扱いきれません。

18ways は、実際の UI の文脈で翻訳を分析します。

私たちのバックエンドエージェントは、実際のページ上で表示される翻訳を確認し、次の点を最適化します：

ドイツ語の複合名詞に慣れている人ならご心配なく、オーバーフロー検出もちゃんと入っています。

人間の翻訳者を支える

AIがより良い翻訳を生成するために役立つものは、すべて人間の翻訳者にも役立ちます。

18waysは、翻訳者に私たちのAIエージェントと同じ、文脈を理解できる環境を提供します。

JSONファイルを編集する代わりに、翻訳者はUI上で実際に表示されているテキストを直接確認しながらレビューする。

これにより、翻訳の精度とワークフロー効率が大幅に向上する。

より良いi18nとは

国際化に、翻訳キー、文字列ファイル、パイプライン用の接着剤のような層を、もう1つ増やす必要はありません。

現代のアプリケーションには、これをより良く行うために必要な構造、文脈、実行時情報がすでにあります。

次世代の i18n は、サーバー描画アプリ、動的コンテンツ、AIネイティブなワークフロー、そして人間の翻訳者が並んで作業できることを前提に作られるべきです。

18ways はその方向へ進んでいます。

言語を変更中