React i18n：2024年版 React国際化の完全ガイド

世界中のユーザーに対応したReactアプリを構築することは、もはや「あれば望ましい」機能ではなく、競争上の必須要件です。ヨーロッパ、ラテンアメリカ、アジアなど新しい市場に参入する場合でも、React国際化（一般に React i18n と略されます）はそれを可能にする基盤となります。

このガイドでは、React i18n が実際に何を意味するのか、従来の方法でのセットアップ方法、代表的な React ローカライゼーションライブラリの比較、そして better-i18n のようなモダンなプラットフォームが開発者のボトルネックを完全に解消する方法まで、すべてを網羅しています。

React i18n とは？
React ローカライゼーションが重要な理由
基本概念：i18n vs l10n vs g11n
従来の方法で React i18n をセットアップする
主要な React i18n ライブラリの比較
react-i18next：詳細解説
react-intl：詳細解説
従来の React ローカライゼーションの隠れたコスト
better-i18n が React 国際化を簡素化する方法
コード例：従来の方法 vs better-i18n
React i18n ベストプラクティス
よくある質問

React i18n とは？ {#what-is-react-i18n}

React i18n とは、複数の言語や地域設定をサポートする形で React アプリケーションを設計・構築するプロセスを指します。「i18n」という略語は「internationalization（国際化）」の短縮形で、単語の「i」と「n」の間に18文字あることに由来します。

国際化は単なる翻訳ではありません。以下の要素を包括します：

テキスト翻訳 — ユーザーの言語で UI 文字列を表示する
日付と時刻のフォーマット — 地域によって日付の形式が異なる（MM/DD/YYYY vs DD/MM/YYYY）
数値と通貨のフォーマット — 小数点記号としてのカンマとピリオド、通貨記号
複数形のルール — ロシア語やアラビア語などは複雑な複数形を持つ
右から左への（RTL）サポート — アラビア語、ヘブライ語などは右から左に読む
ロケール対応のソート — アルファベット順はロケールによって異なる

React エコシステムでは、i18n は react-i18next や react-intl などの専用ライブラリ、カスタム実装、あるいはコードに触れることなくワークフロー全体を処理する better-i18n のようなコンテンツプラットフォームによって実現されています。

React ローカライゼーションが重要な理由 {#why-react-localization-matters}

React ローカライゼーションのビジネス的な根拠は明快です：

72.4% の消費者が、自分の言語のウェブサイトで多くの時間または全ての時間を費やしている（CSA Research）
56.2% の消費者が、自分の言語で情報を入手できることは価格よりも重要だと述べている
5言語以上にローカライズされたアプリは、英語のみのアプリと比べ最大3倍の収益を生み出す
Google などの検索エンジンは、英語以外のクエリに対してローカライズされたコンテンツを上位にランク付けする — つまり React JS ローカライゼーションは SEO に直接影響する

React 上に構築された SaaS 製品、EC サイト、コンテンツプラットフォームにとって、ローカライゼーションを省略することは大きな収益機会を逃すことを意味します。React JS ローカライゼーションは時間とともに複利で効いてくる投資です。

基本概念：i18n vs l10n vs g11n {#core-concepts}

実装に入る前に、関連する3つの用語を理解しておきましょう：

用語	正式名称	意味
i18n	Internationalization（国際化）	複数のロケールをサポートするようにソフトウェアを設計すること
l10n	Localization（ローカライゼーション）	特定のロケール向けにソフトウェアを適応させること（翻訳＋文化的適応）
g11n	Globalization（グローバライゼーション）	i18n と l10n を組み合わせた全体プロセス

React 開発では：

i18n はコード側の作業 — インフラのセットアップ
l10n は翻訳者の作業 — 実際の翻訳コンテンツの作成
目標は、これら2つの関心事をできる限り分離しておくこと

ほとんどの React i18n の問題は、これらを混同することに起因しています。開発者が翻訳ファイルを管理し、JSON ファイルを通じて翻訳者と調整し、UI が変わるたびに新しいキーを手動で抽出することになります。better-i18n のようなモダンなプラットフォームは、こうした摩擦を完全に解消するために存在します。

従来の方法で React i18n をセットアップする {#traditional-setup}

なぜより良いアプローチが必要なのかを理解するために、従来の React JS i18n セットアップを見ていきましょう。ほとんどの従来のアプローチは同じパターンに従います：

ステップ 1：ライブラリのインストール

npm install react-i18next i18next i18next-browser-languagedetector

ステップ 2：翻訳 JSON ファイルの作成

以下のようなフォルダ構造を作成します：

src/
  locales/
    en/
      translation.json
    fr/
      translation.json
    de/
      translation.json

各 JSON ファイルにはキーと値のペアが含まれます：

// src/locales/en/translation.json
{
  "welcome": "Welcome to our app",
  "nav": {
    "home": "Home",
    "about": "About",
    "pricing": "Pricing"
  },
  "cta": {
    "signup": "Sign up for free",
    "login": "Log in"
  }
}

// src/locales/fr/translation.json
{
  "welcome": "Bienvenue dans notre application",
  "nav": {
    "home": "Accueil",
    "about": "À propos",
    "pricing": "Tarifs"
  },
  "cta": {
    "signup": "S'inscrire gratuitement",
    "login": "Se connecter"
  }
}

ステップ 3：i18next の設定

// src/i18n.js
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import LanguageDetector from 'i18next-browser-languagedetector';

import enTranslation from './locales/en/translation.json';
import frTranslation from './locales/fr/translation.json';
import deTranslation from './locales/de/translation.json';

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources: {
      en: { translation: enTranslation },
      fr: { translation: frTranslation },
      de: { translation: deTranslation },
    },
    fallbackLng: 'en',
    debug: process.env.NODE_ENV === 'development',
    interpolation: {
      escapeValue: false,
    },
  });

export default i18n;

ステップ 4：アプリをラップする

// src/index.js
import React from 'react';
import ReactDOM from 'react-dom/client';
import './i18n';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App />);

ステップ 5：コンポーネントで翻訳を使用する

// src/components/HeroSection.jsx
import { useTranslation } from 'react-i18next';

function HeroSection() {
  const { t } = useTranslation();

  return (
    <section>
      <h1>{t('welcome')}</h1>
      <a href="/signup">{t('cta.signup')}</a>
    </section>
  );
}

export default HeroSection;

このセットアップは機能しますが、アプリが成長するにつれて大きな運用コストが伴います。

主要な React i18n ライブラリの比較 {#libraries-compared}

React ローカライゼーションには、いくつかの成熟したライブラリがあります。最もよく使われるオプションの概要を紹介します。

react-i18next

GitHub スター数： 9,000以上 | 週間ダウンロード数： 400万以上

最も人気のある React i18n ライブラリです。i18next の上に構築され、フック（useTranslation）、高階コンポーネント、複雑な翻訳のための Trans コンポーネントを提供します。

長所：

巨大なエコシステムとコミュニティ
柔軟なバックエンドプラグイン（ファイル、API、CDN から翻訳を読み込む）
機能別に翻訳を分割するネームスペースのサポート
優れた TypeScript サポート
翻訳ネームスペースのレイジーロード

短所：

初期設定が冗長
JSON 翻訳ファイルを手動で管理する必要がある
キーの抽出は別途行う必要がある（i18next-parser などのツールを使用）
翻訳者が JSON ファイルを扱う必要があり、翻訳者に優しくない
翻訳管理 UI が組み込まれていない

react-intl (FormatJS)

GitHub スター数： 14,000以上 | 週間ダウンロード数： 250万以上

FormatJS スイートの一部で、react-intl は Yahoo/Formatjs が保守し、ICU メッセージフォーマット標準に準拠しています。

長所：

業界標準の ICU メッセージフォーマット
優れた複数形と性別の処理
日付、時刻、数値フォーマットが組み込み済み
大規模エンタープライズアプリケーションに適している
堅牢な TypeScript 型定義

短所：

react-i18next より学習曲線が急
<FormattedMessage> でラップするため API が冗長
翻訳者にとって ICU 構文が複雑
翻訳ファイルの手動管理が依然として必要
翻訳管理が組み込まれていない

Lingui

GitHub スター数： 4,000以上 | 週間ダウンロード数： 30万以上

マクロを使ってメッセージを自動抽出し、開発者体験を重視した新しいライブラリです。

長所：

マクロによるメッセージの自動抽出
クリーンなコンポーネント構文
ICU メッセージフォーマットのサポート
TypeScript ファースト

短所：

コミュニティが小さい
Babel または SWC のマクロが必要
外部の翻訳管理が依然として必要

next-intl

GitHub スター数： 8,000以上 | 週間ダウンロード数： 120万以上

App Router サポート、サーバーコンポーネント、型安全性を備えた Next.js 専用ライブラリです。

長所：

Next.js App Router のファーストクラスサポート
サーバーサイドレンダリング対応
優れた TypeScript 体験
型安全な翻訳キー

短所：

Next.js 専用
JSON 翻訳ファイルが依然として必要
翻訳者への変更に開発者の関与が必要

比較表

機能	react-i18next	react-intl	Lingui	next-intl	better-i18n
JSON ファイル不要	—	—	—	—	Yes
キー抽出不要	—	—	一部	—	Yes
翻訳者向け UI	—	—	—	—	Yes
AI 自動翻訳	—	—	—	—	Yes
新規コンテンツにコード変更不要	—	—	—	—	Yes
CMS 駆動	—	—	—	—	Yes
React 対応	Yes	Yes	Yes	Yes	Yes
Next.js 対応	Yes	Yes	Yes	Yes	Yes

react-i18next：詳細解説 {#react-i18next}

react-i18next は React JS i18n の主流ライブラリであるため、実際の使用例を詳しく見ていく価値があります。

ネームスペース

大規模なアプリでは、翻訳をネームスペースに分割することでファイルを管理しやすくします：

// ネームスペースを指定して使用
const { t } = useTranslation('checkout');

// 翻訳ファイル: locales/en/checkout.json
{
  "summary": "Order Summary",
  "total": "Total: {{amount}}",
  "confirm": "Confirm Order"
}

補間

翻訳文字列に動的な値を挿入する：

// 翻訳キー: "greeting": "Hello, {{name}}!"
t('greeting', { name: 'Alice' });
// 出力: "Hello, Alice!"

複数形

// 翻訳キー:
// "item_one": "{{count}} item"
// "item_other": "{{count}} items"
t('item', { count: 5 });
// 出力: "5 items"

Trans コンポーネント

React 要素（リンク、太字テキストなど）を含む文字列に使用：

import { Trans } from 'react-i18next';

// 翻訳キー: "termsText": "I agree to the <1>Terms of Service</1>"
<Trans i18nKey="termsText">
  I agree to the <a href="/terms">Terms of Service</a>
</Trans>

キー抽出の問題

開発者が新しい UI テキストを追加するたびに、以下の作業が必要です：

ソース JSON ファイルにキーを追加する
キー抽出ツールを実行する：npx i18next-parser
更新された JSON を翻訳者に送る
翻訳が完成するまで待つ
翻訳を JSON ファイルにインポートし直す
コミットしてデプロイする

このワークフローは開発者のボトルネックを生み出し、すべてのコンテンツ更新を遅らせ、開発者をプロダクトマネージャーと翻訳者の仲介役にしてしまいます。

react-intl：詳細解説 {#react-intl}

react-intl は哲学的に異なるアプローチを採用しています。メッセージは別の JSON ファイルではなく、コンポーネント内にインラインで定義します。defineMessages ヘルパーを使って抽出可能なメッセージを宣言します。

import { useIntl, defineMessages } from 'react-intl';

const messages = defineMessages({
  greeting: {
    id: 'app.greeting',
    defaultMessage: 'Hello, {name}!',
    description: 'Greeting shown on the home page',
  },
});

function Greeting({ name }) {
  const intl = useIntl();
  return <p>{intl.formatMessage(messages.greeting, { name })}</p>;
}

ICU メッセージフォーマット

react-intl は複雑な複数形と性別処理に ICU メッセージフォーマットを使用します：

// ICU を使った複雑な複数形
const message = `{count, plural,
  =0 {No items in cart}
  one {# item in cart}
  other {# items in cart}
}`;

これは強力ですが、翻訳者が正しく翻訳するために ICU 構文を理解する必要があるため、複雑さが増します。

プロバイダーのセットアップ

import { IntlProvider } from 'react-intl';
import enMessages from './locales/en.json';
import frMessages from './locales/fr.json';

function App() {
  const locale = navigator.language.split('-')[0];
  const messages = locale === 'fr' ? frMessages : enMessages;

  return (
    <IntlProvider locale={locale} messages={messages}>
      <MainApp />
    </IntlProvider>
  );
}

従来の React ローカライゼーションの隠れたコスト {#hidden-costs}

従来の React i18n ライブラリはよく設計されていますが、導入する運用オーバーヘッドはしばしば過小評価されます。

1. 開発者のボトルネック

すべてのコンテンツ変更に開発者が必要です。マーケターが CTA を「Start free trial」から「Try for free」に変更したい場合、チケットを起票し、開発者が JSON キーを更新して PR を出し、デプロイするのを待たなければなりません。このボトルネックが組織全体のスピードを落とします。

2. 大規模な JSON ファイル管理

成熟した React アプリは、数十のネームスペースにわたって数千の翻訳キーを持つことがあります。5言語のサポートは5倍のファイル管理を意味します。JSON 翻訳ファイルのマージコンフリクトは手間がかかり、エラーが生じやすいです。

3. キーのずれと孤立したキー

時間の経過とともに、キーが追加・変更・削除されます。厳格なツールなしでは、使われていない孤立キー（JSON にあるが UI で使われていないキー）や欠落キー（UI にあるが JSON に追加されていない文字列）が発生します。i18next-parser などのツールは助けになりますが、CI/CD パイプラインへの統合が必要です。

4. 翻訳者の摩擦

翻訳者はプロの言語専門家であり、開発者ではありません。JSON ファイルで作業するよう求めることは、間違ったツールを使わせることです。ほとんどのプロの翻訳者は Phrase、Lokalise、Crowdin のような CAT（Computer-Assisted Translation）ツールを使用します。これはコードと翻訳者の間にさらなる統合レイヤーが必要になることを意味します。

5. コンテキストのない翻訳

翻訳者が JSON キーと文字列だけを見る場合、その文字列が UI のどこに表示されるかのコンテキストがありません。「キャンセル」という言葉は、サブスクリプション解約ページとファイルアップロードダイアログでは意味が異なります。コンテキストのない翻訳は品質の低下につながります。

6. デプロイとの結合

従来の設定では、翻訳はアプリにバンドルされています。翻訳の更新のたびに新しいデプロイが必要です。これは遅く、リスクも伴います。フランス語翻訳の誤字を修正するだけでも、完全なリリースサイクルが必要になります。

better-i18n が React 国際化を簡素化する方法 {#better-i18n-section}

better-i18n は、上記で述べたすべての問題を解決するために構築されました。React と Next.js アプリケーション向けに特化した、AI を活用したコンテンツローカライゼーションプラットフォームです。

コアコンセプト：コンテンツをサービスとして

翻訳文字列をコードベースで管理する代わりに、better-i18n はコンテンツをマネージドサービスとして扱います。React アプリが better-i18n CMS に接続し、翻訳はダイナミックに配信されます。リポジトリに JSON ファイルなし、キー抽出なし、コンテンツ更新のためのデプロイも不要です。

仕組み

React アプリを接続 — シングル SDK 統合で better-i18n CMS に接続
コンテンツを作成・管理 — better-i18n UI でコンテンツを管理。JSON 不要、コンテンツ更新に開発者不要
AI が自動的に翻訳 — 新しいコンテンツを公開したり既存のコンテンツを変更すると自動翻訳
React アプリがリアルタイムで翻訳を受信 — リビルドなし、リデプロイなし

開発者のボトルネックなし

better-i18n を使えば、マーケティングマネージャーが金曜日の午後3時にヘッドラインを更新すると、チケットを起票することなく、開発者なしで、デプロイなしで、数分以内にサポートする12言語すべてに反映されます。

コンテキスト対応の AI 翻訳

better-i18n はコンテンツをその完全なコンテキスト（ページ、セクション、コンテンツタイプ、著者メモ）とともに保存するため、AI 翻訳エンジンは孤立した文字列しか見えないツールよりも高品質な翻訳を生成します。翻訳ノートや校閲ワークフローをプラットフォーム内で直接追加することもできます。

CMS 駆動のワークフロー

better-i18n CMS は、開発者、マーケター、コピーライター、翻訳者といったチーム全体が共有できるワークスペースを提供します。翻訳者は JSON ファイルではなく、専用の翻訳 UI を使用します。マーケターは公開前に翻訳されたコンテンツをプレビューできます。開発者はコードに集中できます。

既存の React スタックと連携

better-i18n は React フレームワークの代替ではなく、既存のものと並行して統合されます。Create React App、Next.js、Remix、Vite のいずれを使用していても、コンポーネントアーキテクチャを変更することなく動作します。

コード例：従来の方法 vs better-i18n {#code-examples}

具体的な例として、ヒーローセクション、機能リスト、価格 CTA を持つプロダクトランディングページを見てみましょう。

従来の react-i18next アプローチ

コードで管理するもの：

// public/locales/en/landing.json（各言語ごとに1ファイル）
{
  "hero": {
    "headline": "Ship your product to the world",
    "subheadline": "The fastest way to go global without slowing down your team",
    "cta_primary": "Start for free",
    "cta_secondary": "See how it works"
  },
  "features": {
    "title": "Everything you need to go global",
    "item1_title": "Instant AI Translation",
    "item1_desc": "Translate your entire product in minutes, not weeks",
    "item2_title": "No developer bottleneck",
    "item2_desc": "Marketers update content directly — no tickets, no PRs",
    "item3_title": "Real-time updates",
    "item3_desc": "Content updates go live instantly, no redeployment needed"
  }
}

コンポーネント：

// src/components/LandingHero.jsx
import { useTranslation } from 'react-i18next';

function LandingHero() {
  const { t } = useTranslation('landing');

  return (
    <section className="hero">
      <h1>{t('hero.headline')}</h1>
      <p>{t('hero.subheadline')}</p>
      <div className="cta-group">
        <a href="/signup" className="btn-primary">
          {t('hero.cta_primary')}
        </a>
        <a href="/demo" className="btn-secondary">
          {t('hero.cta_secondary')}
        </a>
      </div>
    </section>
  );
}

新しい言語を追加するには、以下が必要です：

新しい JSON ファイルを作成（fr/landing.json）
すべての翻訳を手動で追加するか、TMS 経由でエクスポート/インポート
i18next の resources 設定に fr を追加
アプリをリビルドしてリデプロイ

better-i18n アプローチ

コンポーネント（どの言語でも変更なし）：

// src/components/LandingHero.jsx
// このコンポーネントは i18n のためにまったく変更する必要がない
// コンテンツは CMS から来る；better-i18n がロケールルーティングを処理

function LandingHero({ content }) {
  return (
    <section className="hero">
      <h1>{content.headline}</h1>
      <p>{content.subheadline}</p>
      <div className="cta-group">
        <a href="/signup" className="btn-primary">
          {content.ctaPrimary}
        </a>
        <a href="/demo" className="btn-secondary">
          {content.ctaSecondary}
        </a>
      </div>
    </section>
  );
}

新しい言語を追加するには：

better-i18n ダッシュボードで「言語を追加」をクリック
AI が既存のコンテンツをすべて自動翻訳
完了 — 新しい言語が即座に公開される

JSON ファイルなし。キー抽出なし。リビルドなし。リデプロイなし。

動的コンテンツの処理

ユーザー生成コンテンツやデータベース駆動のコンテンツに対する従来のアプローチでは、通常すべての文字列を t() でラップし、すべての動的文字列のキーを管理する必要があります。これはしばしば不可能です。better-i18n では、CMS で管理されたコンテンツは、静的な UI テキストであれ、ブログ投稿や商品説明のような長文コンテンツであれ、設定されたすべての言語で自動的に利用可能になります。

React i18n ベストプラクティス {#best-practices}

従来のライブラリを使う場合でも better-i18n を使う場合でも、これらの原則はすべての React ローカライゼーション作業に適用されます。

1. 最初からすべての文字列を外部化する

ユーザーに表示される文字列を JSX に直接ハードコードしないでください。1言語だけから始める場合でも、最初から文字列を外部化しておくことで、将来の i18n が大幅に楽になります。

2. テキスト拡張を考慮してデザインする

ドイツ語のテキストは同等の英語テキストより通常30〜40%長くなります。ロシア語は50%長くなることがあります。レイアウトが崩れないようにテキスト拡張に対応できる柔軟性を持ってUIをデザインしてください。固定幅の代わりに overflow: hidden、text-overflow: ellipsis、または柔軟なコンテナなどの CSS プロパティを使用してください。

3. 文字列の連結を避ける

翻訳文字列を連結で構築しないでください：

// NG — 語順が異なる言語では壊れる
const message = t('hello') + ', ' + userName + '!';

// OK — 補間を使用する
const message = t('hello_user', { name: userName });
// 翻訳: "hello_user": "Hello, {{name}}!"

4. 複数形を正しく処理する

英語には2つの複数形（単数/複数）があります。多くの言語にはもっと多くあります。アラビア語には6つの複数形があります。常にライブラリの複数形処理を使用してください。独自のものを書かないでください：

// NG
const label = count === 1 ? t('item_singular') : t('item_plural');

// OK
const label = t('item', { count });
// 適切な複数形キー: item_one, item_other, item_few, など

5. ロケール設定を保存する

ユーザーの言語選択を永続化する：

// 言語変更時
localStorage.setItem('preferred-locale', newLocale);

// アプリ初期化時
const savedLocale = localStorage.getItem('preferred-locale');
const browserLocale = navigator.language.split('-')[0];
const locale = savedLocale || browserLocale || 'en';

6. ロケール対応のフォーマットを使用する

日付、数値、通貨には常に Intl API またはi18nライブラリのフォーマット機能を使用する：

// NG
const formatted = '$' + price.toFixed(2);

// OK
const formatted = new Intl.NumberFormat(locale, {
  style: 'currency',
  currency: 'USD',
}).format(price);
// ドイツ語ロケール: "1.234,56 $"
// US ロケール: "$1,234.56"

7. RTL を早めに計画する

アラビア語、ヘブライ語、ファルシ語、ウルドゥー語のサポートを予定している場合は、最初から RTL を計画してください。物理的なプロパティの代わりに CSS 論理プロパティを使用してください：

/* 物理的プロパティ（RTL で壊れる） */
.container { margin-left: 16px; padding-right: 24px; }

/* 論理プロパティ（LTR と RTL の両方で機能する） */
.container { margin-inline-start: 16px; padding-inline-end: 24px; }

8. 疑似ローカライゼーションでテストする

実際の翻訳者に文字列を送る前に、疑似ローカライゼーションを使って UI がテキスト拡張と特殊文字を処理できるか確認してください：

// 疑似ロケールは "Hello, World!" を "[Ĥéĺĺô, Ŵôŕĺď!]" に変換する
// これにより実際の翻訳が届く前にレイアウトのバグを検出できる

9. CI でキー抽出を自動化する

キー抽出が必要なライブラリを使用する場合は、CI パイプラインの一部にしてください。本番環境でキーが見つからない場合、ユーザーには空の文字列が表示されます。これは英語のテキストをそのまま表示するよりも悪い状況です。

10. 翻訳の更新とコードのデプロイを分離する

最良のアーキテクチャは、コンテンツ更新とコードリリースを切り離します。翻訳をアプリケーションのデプロイとは独立して更新・公開できるため、better-i18n のような CMS 駆動のアプローチが好まれるのはこの理由からです。

よくある質問 {#faq}

React i18n と React ローカライゼーションの違いは何ですか？

React i18n（国際化） とは、複数の言語をサポートできるようにアプリを構築するエンジニアリング作業を指します。インフラのセットアップ、ライブラリの選択、コードをロケール対応の構造にすることが含まれます。React ローカライゼーション（l10n） とは、特定のロケール向けにアプリを実際に適応させること、つまり翻訳されたテキスト、日付フォーマット、特定の言語・地域の文化的慣習です。i18n は前提条件で、l10n は継続的な作業です。

どの React i18n ライブラリを使うべきですか？

ほとんどの新規プロジェクトでは、エコシステムの大きさと柔軟性から react-i18next が最も安全な選択です。Next.js プロジェクトには next-intl が App Router との統合と型安全性で優れています。JSON ファイルの管理を完全になくしてコンテンツチームに自律性を与えたい場合は、better-i18n が従来のライブラリ層全体を不要にし、CMS 駆動のワークフローを提供します。

既存の React アプリに i18n を追加するにはどうすればいいですか？

既存の React アプリに i18n を追加するには3つのフェーズがあります：(1) コンポーネント内のすべてのハードコードされた文字列を監査する、(2) i18n ライブラリを選択して設定する、(3) 文字列を翻訳ファイルに抽出し、ハードコードされたテキストを翻訳関数の呼び出しに置き換える。better-i18n ではプロセスがよりシンプルで、コンポーネントロジックを変更することなく SDK を接続してコンテンツを CMS に移行します。

React i18n はパフォーマンスに影響しますか？

従来のライブラリでは、翻訳 JSON ファイルは通常アプリにバンドルされるか、ロケールごとに遅延ロードされます。大きな翻訳バンドルは初期ロード時間に影響を与える可能性があります。ネームスペース分割と遅延ロード（react-i18next でサポート）はこれを軽減します。better-i18n はエッジ CDN を通じてコンテンツを配信し、ユーザーの場所に関わらず最小限のレイテンシで翻訳が届きます。

React i18n で動的コンテンツ（ユーザー生成コンテンツ）はどう処理しますか？

ユーザー名、投稿タイトル、商品説明などの動的コンテンツは静的に翻訳することができません。選択肢には：(1) API を通じたランタイムでの機械翻訳、(2) データベースに事前翻訳済みバージョンを保存する、(3) 静的な UI 文字列と長文の動的コンテンツの両方を単一ワークフローで管理する better-i18n のようなコンテンツプラットフォームの使用 — が含まれます。

react-i18next を Next.js で使えますか？

はい。react-i18next は Next.js Pages Router と App Router の両方で動作しますが、App Router の統合はサーバーコンポーネントの慎重な処理が必要です。Next.js プロジェクトには、ネイティブのサーバーコンポーネントサポートを持つ Next.js 専用の next-intl がより適していることが多いです。

React アプリは何言語をサポートすべきですか？

ターゲット市場が話す言語から始めましょう。US 中心の SaaS 製品の場合、スペイン語、フランス語、ポルトガル語、ドイツ語を追加することで、リーチできる非英語圏の市場の80%以上をカバーします。言語の優先度を決める前に、既存のユーザーがどこから来ているかをアナリティクスで確認してください。

React アプリを国際化しないコストは何ですか？

そのコストは市場からの排除です。世界のインターネットユーザーの75%は英語を母国語としない人々です。ローカライゼーションのないアプリは英語以外のクエリで Google にランク付けされず、英語以外のビジターを効果的にコンバージョンできず、国際ユーザーに「自分たちのために作られていない」という印象を与えます。ほとんどのソフトウェア製品では、初年度に3〜5言語を追加した場合の ROI はプラスになります。

better-i18n は翻訳品質をどのように管理していますか？

better-i18n はコンテキスト認識型の AI 翻訳を使用しています。AI は翻訳する文字列だけでなく、コンテンツタイプ、ページの場所、追加した翻訳者メモも確認します。プラットフォームは人間のレビューワークフローもサポートしており、AI 生成の翻訳が公開される前にプロの翻訳者がレビューして承認できます。これにより AI のスピードと人間による品質保証の両方が得られます。

better-i18n は大規模な React アプリケーションに適していますか？

はい。better-i18n は、単一製品を持つスタートアップから複数製品と数十言語を管理するエンタープライズまで、スケールするように構築されています。CMS はチームコラボレーション向けに設計されており、ロールベースのアクセス制御、承認ワークフロー、時間とともに AI 品質を向上させる翻訳メモリを備えています。

まとめ

React i18n は大きく進化しています。従来のアプローチ（react-i18next をインストールし、各言語用の JSON ファイルを作成し、翻訳キーを手動で管理する）は今でも機能しますが、製品がスケールするにつれてチームのスピードを落とす継続的な運用負担が生じます。

better-i18n のようなモダンな代替手段は根本的に異なる哲学を体現しています：コンテンツをサービスとして、コードから切り離し、コンテンツに最も近い人々（マーケター、ライター、翻訳者）が管理し、AI で動くため新しい言語の追加は開発プロジェクトではなく製品決定になります。

新しい React アプリを始める場合でも、既存のアプリに i18n を追加する場合でも、目標は同じです：ローカライゼーションが永続的な開発者の苦労の源になることなく、ユーザーが自分の言語で、自分の文化的コンテキストで製品を使えるようにすることです。

複雑さなしで React i18n をアプリに追加する準備はできていますか？ better-i18n を始める — 数分で React アプリを接続して、残りはコンテンツチームに任せましょう。

最終更新：2024年3月。キーワード：react internationalization, react i18n, react localization, react js i18n, react js localization, reactjs localization.

React i18n：2024年版 React国際化の完全ガイド