18waysブログ

i18nが壊れています: 翻訳キーの記述をやめてください

SEOを壊さずに、Next.jsでi18nを行うAIネイティブな方法。

Internationalisation (often shortened to i18n), localisation (l10n), and multilingual support all describe the same idea: adapting your product so people can use it in their own language.

i18nは今でも2005年のように構築されています

すべてのビジネスは最終的に複数の言語をサポートする必要があることに気づきます。その時、プロダクトチームは整備士のように背もたれに寄りかかり、歯の隙間から息を吸い込みながら、「何ページの話ですか？それは少なくとも4つのスプリントですね。」と言います。

従来のi18n作業のコストと労力に対するメカニックスタイルの反応

私たちがi18nを実装する基本的な方法は、20年間変わっていません。ほとんどのi18nの「ベストプラクティス」は、現代のウェブアーキテクチャが登場するずっと前に形成されており、それ以降のすべては単にそれらの上に重ねられてきました。

I18nは、現代のウェブ開発の中で、まだファイルをエクスポートして誰かに送信することを含む唯一の部分です。メールで送信する代わりにAPIを通じてアップロードする場合、それは現代的な設定と見なされます。

CIパイプラインとデプロイが日単位ではなく分単位で測定される世界では、私たちはファックスを送る必要がないことを幸運だと考えるべきでしょう。

なぜi18nが壊れているように感じるのか

現代のウェブ開発は驚くほど迅速に進化しています。

私たちには:

それでも、国際化のワークフローは依然として異なる時代に属しているように感じられます。

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

開発者はこのようなシステムを構築するつもりで始めるわけではありません。彼らは、異なる言語が文を全く異なる方法で構成することに不慣れな開発者をつまずかせる一般的な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パイプラインは、開発者がすべてのテキストを制御していると仮定していますが、ますますそれは真実ではなくなっています。

2026年にAmazonのような企業が翻訳されたユーザーレビューの実験を始めたという事実は、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辞書、断片化されたパイプライン、分離されたバックエンドとフロントエンドのローカリゼーションレイヤー、外部翻訳ツールを持つことになりました。

現代のウェブアプリは非常に洗練されたシステムです。しかし、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の姿

国際化には、別の翻訳キー、文字列ファイル、パイプラインの接着剤が必要ありません。

現代のアプリケーションは、これをより良く行うために必要な構造、コンテキスト、実行時情報をすでに持っています。

次世代のi18nは、サーバーレンダリングされたアプリ、動的コンテンツ、AIネイティブのワークフロー、そして人間の翻訳者が並んで作業するために構築されるべきです。

それが18waysが進んでいる方向です。

i18nは壊れています: 翻訳キーの記述をやめましょう | 18waysブログ