このページとあなたの好きなAIアシスタントを使ってドキュメントを要約します
バージョン履歴
- "代替案に対するIntlayerの利点セクションを追加"v8.11.22026/5/31
- "コンパイラのリリース"v7.3.12025/11/27
- "比較表の更新"v5.8.02025/8/19
- "履歴の初期化"v5.5.102025/6/29
このページのコンテンツはAIを使用して翻訳されました。
英語の元のコンテンツの最新バージョンを見るIf you have an idea for improving this documentation, please feel free to contribute by submitting a pull request on GitHub.
GitHub link to the documentationCopy doc Markdown to clipboard
なぜIntlayerを検討すべきなのか?
Intlayerとは?
Intlayerは、JavaScript開発者向けに特別に設計された国際化(i18n)ライブラリです。コード内のあらゆる場所でコンテンツを宣言することができます。多言語コンテンツの宣言を構造化された辞書に変換し、コードに簡単に統合できるようにします。TypeScriptを使用することで、Intlayerは開発をより強力かつ効率的にします。
なぜ他の選択肢ではなくIntlayerなのか?
next-intlやi18nextなどの主要なソリューションと比較して、Intlayerは以下のような統合された最適化を備えたソリューションです:
バンドルサイズ
ページに巨大なJSONファイルを読み込む代わりに、必要なコンテンツのみを読み込みます。Intlayerはバンドルサイズとページサイズを最大50%削減するのに役立ちます。
メンテナンス性
アプリケーションのコンテンツのスコープを限定することで、大規模アプリケーションのメンテナンスが容易になります。全体のコンテンツコードベースを見直す精神的負担なしに、単一の機能フォルダを複製または削除できます。さらに、Intlayerは完全に型定義されているため、コンテンツの正確性が保証されます。
AIエージェント
コンテンツを同じ場所に配置(コローケーション)することで、大規模言語モデル(LLM)に必要なコンテキストが削減されます。Intlayerには、翻訳漏れをテストするためのCLI、LSP、MCP、エージェントスキルなどのツールスイートも付属しており、AIエージェントの開発体験(DX)をさらにスムーズにします。
機能性
Intlayerは、他のi18nソリューションにはない、Markdownサポート、外部コンテンツの取得、ファイルコンテンツの読み込み、ライブコンテンツ更新、ビジュアルエディタなど、多くの追加機能を提供します。
自動化
CI/CDパイプラインでお好みのLLMを使用し、AIプロバイダーの実費で自動翻訳を行います。Intlayerはコンテンツ抽出を自動化するコンパイラや、バックグラウンドで翻訳をサポートするウェブプラットフォームも提供しています。
パフォーマンス
巨大なJSONファイルをコンポーネントに接続すると、パフォーマンスやリアクティビティの問題が発生する可能性があります。Intlayerはビルド時にコンテンツの読み込みを最適化します。
非開発者とのスケーリング
単なるi18nソリューションにとどまらず、Intlayerはセルフホスト可能なビジュアルエディタとフル機能のCMSを提供し、多言語コンテンツをリアルタイムで管理できるようにします。これにより、翻訳者、コピーライター、その他のチームメンバーとのコラボレーションがシームレスになります。コンテンツはローカルおよび/またはリモートに保存できます。
クロスフレームワーク設計
アプリケーションの異なる部分で異なるフレームワークを使用している場合(例:React、React-Native、Vue、Angular、Svelteなど)、Intlayerはすべての主要なフロントエンドフレームワークで共通の構文と実装を使用する方法を提供します。また、デザインシステム、アプリ、バックエンドなどでコンテンツ宣言を共有することもできます。
なぜIntlayerが作られたのか?
Intlayerは、next-intl、react-i18next、react-intl、next-i18next、vue-i18nなど、すべての一般的なi18nライブラリに影響を与える共通の課題を解決するために作成されました。
これらのソリューションはすべて、コンテンツをリスト化して管理するために中央集権的なアプローチを採用しています。例えば:
コードをクリップボードにコピー
.├── locales│ ├── en.json│ ├── es.json│ └── fr.json├── i18n.ts└── src └── components └── MyComponent └── index.tsxまたは、名前空間(namespaces)を使用する場合:
コードをクリップボードにコピー
.├── locales│ ├── en│ │ ├── footer.json│ │ └── navbar.json│ ├── fr│ │ ├── footer.json│ │ └── navbar.json│ └── es│ ├── footer.json│ └── navbar.json├── i18n.ts└── src └── components └── MyComponent └── index.tsxこのタイプのアーキテクチャは、いくつかの理由から開発プロセスを遅らせ、コードベースのメンテナンスを複雑にします:
新しいコンポーネントを作成するたびに以下を行う必要があります:
localesフォルダに新しいリソース/名前空間を作成する- ページに新しい名前空間をインポートすることを忘れないようにする
- コンテンツを翻訳する(AIプロバイダーから手動でコピー&ペーストすることが多い)
コンポーネントに変更を加えるたびに以下を行う必要があります:
- 関連するリソース/名前空間を探す(コンポーネントから離れている)
- コンテンツを翻訳する
- すべてのロケールでコンテンツが最新であることを確認する
- 名前空間に未使用のキー/値が含まれていないか検証する
- JSONファイルの構造がすべてのロケールで同一であることを確認する
これらのソリューションを使用するプロフェッショナルなプロジェクトでは、コンテンツの翻訳管理を支援するためにローカリゼーションプラットフォームがよく使用されます。しかし、これは大規模なプロジェクトでは急速にコストがかさむ可能性があります。
この問題を解決するため、IntlayerはCSS(styled-components)、型定義、ドキュメント(storybook)、ユニットテスト(jest)でよく行うように、コンテンツのスコープをコンポーネントごとに限定し、コンテンツをコンポーネントの近くに維持するアプローチを採用しています。
コードをクリップボードにコピー
.└── components └── MyComponent ├── index.content.ts ├── index.test.tsx ├── index.stories.tsx └── index.tsxコードをクリップボードにコピー
import { t, type Dictionary } from "intlayer";
const componentExampleContent = {
key: "component-example",
content: {
myTranslatedContent: t({
en: "Hello World",
es: "Hola Mundo",
fr: "Bonjour le monde",
}),
},
} satisfies Dictionary;
export default componentExampleContent;コードをクリップボードにコピー
import { useIntlayer } from "react-intlayer";
export const ComponentExample = () => {
const { myTranslatedContent } = useIntlayer("component-example");
return <span>{myTranslatedContent}</span>;
};このアプローチにより、以下のことが可能になります:
開発スピードの向上
.content.{{ts|mjs|cjs|json}}ファイルはVSCode拡張機能を使用して作成できます- IDEのAI補完ツール(GitHub Copilotなど)がコンテンツの宣言を支援し、コピー&ペーストを削減します
コードベースのクリーンアップ
- 複雑さを軽減
- メンテナンス性を向上
コンポーネントとそれに関連するコンテンツの複製がより容易に(例:ログイン/登録コンポーネントなど)
- 他のコンポーネントのコンテンツに影響を与えるリスクを限定
- 外部依存関係なしに、あるアプリケーションから別のアプリケーションへコンテンツをコピー&ペースト可能
未使用のコンポーネント用コードベースに未使用のキー/値が残るのを防止
- コンポーネントを使用しない場合、Intlayerは関連するコンテンツをインポートしません
- コンポーネントを削除する場合、関連するコンテンツも同じフォルダに存在するため、削除し忘れが防げます
多言語コンテンツを宣言するAIエージェントの推論コストを削減
- AIエージェントはコンテンツをどこに実装すべきか知るためにコードベース全体をスキャンする必要がありません
- IDEのAI補完ツール(GitHub Copilotなど)で簡単に翻訳を行えます
読み込みパフォーマンスの最適化
- コンポーネントが遅延読み込み(lazy-loaded)される場合、関連するコンテンツも同時に読み込まれます
Intlayerの追加機能
テーブルをモーダルで開き、すべてのデータを明確に表示
| 機能 | 説明 |
|---|---|
| クロスフレームワークサポート Intlayerは、Next.js、React、Vite、Vue.js、Nuxt、Preact、Expressなど、すべての主要なフレームワークやライブラリと互換性があります。 |
| JavaScriptによるコンテンツ管理 JavaScriptの柔軟性を活かして、コンテンツを効率的に定義および管理します。 - コンテンツ宣言 |
| コンパイラ Intlayerコンパイラは、コンポーネントからコンテンツを自動的に抽出し、辞書ファイルを生成します。 - コンパイラ |
| ロケールごとのコンテンツ宣言ファイル 自動生成の前にコンテンツを一度宣言するだけで、開発速度を向上させます。 - ロケールごとのコンテンツ宣言ファイル |
| 型安全な環境 TypeScriptを活用して、コンテンツ定義とコードにエラーがないことを保証し、IDEの自動補完も享受できます。 - TypeScript設定 |
| シンプルなセットアップ 最小限の設定で迅速に稼働させることができます。国際化、ルーティング、AI、ビルド、コンテンツ処理の設定を簡単に調整できます。 - Next.js統合の探索 |
| シンプルなコンテンツ取得 コンテンツの各部分で t関数を呼び出す必要はありません。単一のフックを使用して、すべてのコンテンツを直接取得できます。- React統合 |
| 一貫したサーバーコンポーネントの実装 Next.jsサーバーコンポーネントに最適で、クライアントコンポーネントとサーバーコンポーネントの両方で同じ実装を使用でき、各サーバーコンポーネントで t関数を渡す必要はありません。- サーバーコンポーネント |
| 整理されたコードベース コードベースを整理された状態に保ちます:同じフォルダ内に1コンポーネント=1辞書。それぞれのコンポーネントの近くに翻訳を配置することで、メンテナンス性と明瞭性が向上します。 - Intlayerの仕組み |
| 強化されたルーティング アプリルーティングの完全なサポート。Next.js、React、Vite、Vue.jsなどの複雑なアプリケーション構造にシームレスに適応します。 - Next.js統合の探索 |
| Markdownサポート プライバシーポリシーやドキュメントなどの多言語コンテンツのために、ローカルファイルやリモートのMarkdownをインポートして解釈します。コード内でMarkdownメタデータを解釈し、アクセス可能にします。 - コンテンツファイル |
| 無料のビジュアルエディタとCMS コンテンツライター向けに無料のビジュアルエディタとCMSが利用可能で、ローカリゼーションプラットフォームの必要性を排除します。Gitを使用してコンテンツを同期させるか、CMSで部分的または完全に外部管理します。 - Intlayerエディタ - Intlayer CMS |
| Tree-shakableコンテンツ 最終バンドルのサイズを削減するTree-shakableコンテンツ。コンポーネントごとにコンテンツを読み込み、未使用のコンテンツをバンドルから除外します。アプリの読み込み効率を高めるための遅延読み込み(lazy loading)をサポートします。 - アプリビルドの最適化 |
| 静的レンダリング 静的レンダリングをブロックしません。 - Next.js統合 |
| AI支援の翻訳 独自のAIプロバイダー/APIキーを使用し、Intlayerの高度なAI翻訳ツールを使用してワンクリックでウェブサイトを231言語に翻訳します。 - CI/CD統合 - Intlayer CLI - 自動入力 |
| MCPサーバー統合 IDE自動化のためのMCP(Model Context Protocol)サーバーを提供し、開発環境内で直接シームレスなコンテンツ管理とi18nワークフローを可能にします。 - MCPサーバー |
| VSCode拡張機能 Intlayerは、コンテンツや翻訳の管理、辞書の作成、コンテンツの翻訳などを支援するVSCode拡張機能を提供します。 - VSCode拡張機能 |
| 相互運用性 react-i18next、next-i18next、next-intl、およびreact-intlとの相互運用を可能にします。 - Intlayerとreact-intl - Intlayerとnext-intl - Intlayerとnext-i18next |
| 翻訳漏れのテスト(CLI/CI) | ✅ CLI: npx intlayer content test(CIフレンドリーな監査) |
Intlayerと他のソリューションの比較
テーブルをモーダルで開き、すべてのデータを明確に表示
| 機能 | intlayer | react-i18next | react-intl (FormatJS) | lingui | next-intl | next-i18next | vue-i18n |
|---|---|---|---|---|---|---|---|
| コンポーネント近くの翻訳 | ✅ あり、コンテンツは各コンポーネントと同じ場所 | ❌ なし | ❌ なし | ❌ なし | ❌ なし | ❌ なし | ✅ あり - Single File Components (SFC) を使用する場合 |
| TypeScript統合 | ✅ 高度、自動生成された厳格な型定義 | ⚠️ 基本的;安全性のために追加設定が必要 | ✅ 良好だが厳格さは劣る | ⚠️ 型定義あり、設定が必要 | ✅ 良好 | ⚠️ 基本的 | ✅ 良好(型定義あり;キーの安全性には設定が必要) |
| 翻訳漏れの検出 | ✅ TypeScriptエラー強調およびビルド時のエラー/警告 | ⚠️ 主に実行時のフォールバック文字列 | ⚠️ フォールバック文字列 | ⚠️ 追加の設定が必要 | ⚠️ 実行時フォールバック | ⚠️ 実行時フォールバック | ⚠️ 実行時フォールバック/警告(設定可能) |
| リッチコンテンツ(JSX/Markdown/コンポーネント) | ✅ 直接サポート | ⚠️ 制限あり / 補間のみ | ⚠️ ICU構文、本物のJSXではない | ⚠️ 制限あり | ❌ リッチノード向けに設計されていない | ⚠️ 制限あり | ⚠️ 制限あり(<i18n-t>経由のコンポーネント、プラグイン経由のMarkdown) |
| AI支援の翻訳 | ✅ あり、複数のAIプロバイダーをサポート。独自のAPIキーで使用可能。アプリケーションのコンテキストとコンテンツ範囲を考慮 | ❌ なし | ❌ なし | ❌ なし | ❌ なし | ❌ なし | ❌ なし |
| ビジュアルエディタ | ✅ あり、ローカルビジュアルエディタ + オプションのCMS;コードベースコンテンツの外部化が可能;埋め込み可能 | ❌ なし / 外部ローカリゼーションプラットフォーム経由で利用可能 | ❌ なし / 外部ローカリゼーションプラットフォーム経由で利用可能 | ❌ なし / 外部ローカリゼーションプラットフォーム経由で利用可能 | ❌ なし / 外部ローカリゼーションプラットフォーム経由で利用可能 | ❌ なし / 外部ローカリゼーションプラットフォーム経由で利用可能 | ❌ なし / 外部ローカリゼーションプラットフォーム経由で利用可能 |
| ローカライズされたルーティング | ✅ あり、ロケール付きパスを標準サポート(Next.jsおよびViteで動作) | ⚠️ 標準機能なし、プラグイン(例:next-i18next)またはカスタムルーター設定が必要 | ❌ なし、メッセージ形式のみ、ルーティングは手動 | ⚠️ 標準機能なし、プラグインまたは手動設定が必要 | ✅ 標準搭載、App Routerは[locale]セグメントをサポート | ✅ 標準搭載 | ✅ 標準搭載 |
| 動的ルート生成 | ✅ あり | ⚠️ プラグイン/エコシステムまたは手動設定 | ❌ 提供なし | ⚠️ プラグイン/手動 | ✅ あり | ✅ あり | ❌ 提供なし(Nuxt i18nが提供) |
| 複数形化 | ✅ 列挙(Enum)ベースのパターン | ✅ 設定可能(i18next-icuなどのプラグイン) | ✅ (ICU) | ✅ (ICU/messageformat) | ✅ 良好 | ✅ 良好 | ✅ 標準の複数形ルール |
| 書式設定(日付、数値、通貨) | ✅ 最適化されたフォーマッタ(内部でIntlを使用) | ⚠️ プラグインまたはカスタムIntl使用経由 | ✅ ICUフォーマッタ | ✅ ICU/CLIヘルパー | ✅ 良好(Intlヘルパー) | ✅ 良好(Intlヘルパー) | ✅ 標準の日付/数値フォーマッタ(Intl) |
| コンテンツ形式 | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml 開発中) | ⚠️ .json | ✅ .json, .js | ⚠️ .po, .json | ✅ .json, .js, .ts | ⚠️ .json | ✅ .json, .js |
| ICUサポート | ⚠️ 開発中 | ⚠️ プラグイン経由(i18next-icu) | ✅ あり | ✅ あり | ✅ あり | ⚠️ プラグイン経由(i18next-icu) | ⚠️ カスタムフォーマッタ/コンパイラ経由 |
| SEOヘルパー(hreflang, sitemap) | ✅ 標準ツール:サイトマップ、robots.txt、メタデータのヘルパー | ⚠️ コミュニティプラグイン/手動 | ❌ コア機能にない | ❌ コア機能にない | ✅ 良好 | ✅ 良好 | ❌ コア機能にない(Nuxt i18nがヘルパーを提供) |
| エコシステム / コミュニティ | ⚠️ 小規模だが急速に成長中かつ高反応 | ✅ 最大かつ成熟 | ✅ 大規模 | ⚠️ 小規模 | ✅ 中規模、Next.js重視 | ✅ 中規模、Next.js重視 | ✅ Vueエコシステムで大規模 |
| サーバーサイドレンダリング & サーバーコンポーネント | ✅ あり、SSR / React Server Components向けに最適化 | ⚠️ ページレベルでサポートされているが、子サーバーコンポーネントにt関数を渡す必要あり | ⚠️ 追加設定ありのページレベルでサポートされているが、子サーバーコンポーネントにt関数を渡す必要あり | ✅ サポートあり、設定が必要 | ⚠️ ページレベルでサポートされているが、子サーバーコンポーネントにt関数を渡す必要あり | ⚠️ ページレベルでサポートされているが、子サーバーコンポーネントにt関数を渡す必要あり | ✅ Nuxt/Vue SSR経由のSSR(RSCなし) |
| Tree-shaking(使用コンテンツのみ読み込み) | ✅ あり、Babel/SWCプラグイン経由でビルド時にコンポーネントごとに実施 | ⚠️ 通常はすべて読み込み(名前空間/コード分割で改善可能) | ⚠️ 通常はすべて読み込み | ❌ デフォルトではない | ⚠️ 部分的 | ⚠️ 部分的 | ⚠️ 部分的(コード分割/手動設定あり) |
| 遅延読み込み(Lazy loading) | ✅ あり、ロケールごと / 辞書ごと | ✅ あり(例:オンデマンドのバックエンド/名前空間) | ✅ あり(ロケールバンドルの分割) | ✅ あり(動的カタログインポート) | ✅ あり(ルートごと / ロケールごと)、名前空間の管理が必要 | ✅ あり(ルートごと / ロケールごと)、名前空間の管理が必要 | ✅ あり(非同期ロケールメッセージ) |
| 未使用コンテンツの削除 | ✅ あり、ビルド時に辞書ごとに実施 | ❌ なし、手動の名前空間分割経由のみ | ❌ なし、宣言されたすべてのメッセージが同梱される | ✅ あり、ビルド時に未使用のキーを検出してドロップ | ❌ なし、名前空間管理で手動管理可能 | ❌ なし、名前空間管理で手動管理可能 | ❌ なし、手動の遅延読み込み経由のみ可能 |
| 大規模プロジェクトの管理 | ✅ モジュール化を促進、デザインシステムに最適 | ⚠️ 優れたファイル規律が必要 | ⚠️ 中央カタログが肥大化する可能性あり | ⚠️ 複雑になる可能性あり | ✅ 設定ありのモジュール式 | ✅ 設定ありのモジュール式 | ✅ Vue Router/Nuxt i18n設定ありのモジュール式 |
GitHubスター数
GitHubスター数は、プロジェクトの知名度、コミュニティからの信頼、長期的な関連性を示す強い指標です。技術的な品質を直接測定するものではありませんが、プロジェクトが有用であると感じ、その進捗を追いかけ、採用する可能性が高い開発者がどれだけいるかを反映しています。プロジェクトの価値を評価する際、スター数は選択肢間の勢いを比較し、エコシステムの成長に関する洞察を得るのに役立ちます。
相互運用性
intlayerは、react-intl、react-i18next、next-intl、next-i18next、vue-i18nの名前空間の管理にも役立ちます。
intlayerを使用すると、お気に入りのi18nライブラリの形式でコンテンツを宣言でき、intlayerは任意の場所に名前空間を生成します(例:/messages/{{locale}}/{{namespace}}.json)。