@intlayer/docs 9.4.1 → 9.4.3

package/blog/ja/date_time_number_formatting_locales.md

@@ -0,0 +1,216 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Intl を使ってロケールごとに日付と数値をフォーマットする"
+description: おそらくフォーマット専用ライブラリは不要です。Intl が言語ごとの日付、数値、通貨、リストをどう処理するか、キャッシュのオーバーヘッド、本番限定のタイムゾーンバグを解説します。
+keywords:
+  - ロケール別日付フォーマット
+  - Intl.DateTimeFormat
+  - Intl.NumberFormat
+  - toLocaleDateString
+  - 通貨フォーマット ロケール
+  - 相対時間フォーマット
+slugs:
+  - blog
+  - date-time-number-formatting-locales
+author: aymericzip
+---
+
+# Intl を使ってロケールごとに日付と数値をフォーマットする
+
+文言の翻訳は、国際化（i18n）の目に見える半分にすぎません。バグ報告の大半を生み出すもう半分はフォーマットです。ドイツ人ユーザーに `1.234,56` ではなく `1,234.56` と表示されたり、日本人ユーザーが `08/02/2026` を8月と誤読したり、サーバーとクライアントで日付の文字列が食い違って React のハイドレーションエラーで画面が真っ白になったりします。
+
+これらを解決するために外部ライブラリは必要ありません。ターゲットとするすべてのモダンランタイムに `Intl` が標準搭載されています。
+
+## 目次
+
+<TOC/>
+
+## まず自作の日付ヘルパー関数を削除する
+
+ほぼすべてのコードベースに、多言語対応を意識する前に書かれた `formatDate` が存在します。表示順や区切り文字、英語の月名が決め打ちされています。
+
+```ts
+// 削除すべきコード
+const formatDate = (d: Date) =>
+  `${d.getMonth() + 1}/${d.getDate()}/${d.getFullYear()}`;
+```
+
+`Intl.DateTimeFormat` はこれらを完全に代替し、すべてのロケールで正しく動作します。
+
+```ts
+new Intl.DateTimeFormat("de-DE", { dateStyle: "long" }).format(date);
+// "2. August 2026"
+new Intl.DateTimeFormat("ja-JP", { dateStyle: "long" }).format(date);
+// "2026年8月2日"
+```
+
+数値も同様です。`toFixed(2)` はどこでも `1234.56` を出力しますが、これはヨーロッパの大部分の地域で不適切です。
+
+## `Intl` がカバーする範囲
+
+| API                       | 用途                                                   |
+| :------------------------ | :----------------------------------------------------- |
+| `Intl.DateTimeFormat`     | 日付と時刻（`dateStyle` / `timeStyle` プリセット対応） |
+| `Intl.NumberFormat`       | 小数、通貨、パーセント、単位、コンパクト表記           |
+| `Intl.RelativeTimeFormat` | "3日前"、"2時間後" などの相対時間表現                  |
+| `Intl.ListFormat`         | "A、B、およびC" といった列挙の結合                     |
+| `Intl.PluralRules`        | 数値に応じた複数形ルールの判定                         |
+| `Intl.Collator`           | 言語規則に基づく正確な文字列の並べ替え                 |
+
+特に忘れられがちなのが `Intl.Collator` です。文字列に対する通常の `array.sort()` は Unicode コードポイント順でソートするため、アクセント記号付き文字が `z` の後ろに回ったり、スウェーデン語の `ö` が不自然な位置に来たりします。ユーザーに見せるリストを並べ替える際は、必ずコレーターを使用してください。
+
+```ts
+["zebra", "édouard", "apple"].sort(new Intl.Collator("ja").compare);
+// ["apple", "édouard", "zebra"]
+```
+
+## 個別のオプション指定よりもプリセットを優先する
+
+`dateStyle` と `timeStyle` を使えば、ロケールに応じた正しい順序と区切り文字が自動的に決定されます。`year`、`month`、`day` を個別指定すると不要な制御が発生し、国ごとの慣習の違いを見落として CLDR の正確な定義を誤った推測で上書きしてしまいます。
+
+```ts
+// ロケールに応じた最適なフォーマット
+new Intl.DateTimeFormat(locale, { dateStyle: "medium" }).format(d);
+
+// 手動指定によって他国で不自然になる例
+new Intl.DateTimeFormat(locale, {
+  year: "numeric",
+  month: "2-digit",
+  day: "2-digit",
+}).format(d);
+```
+
+個別指定を行うのは、狭いテーブル列に収めるために固定幅が絶対に必要とされるデザイン要件がある場合だけに留めてください。
+
+## フォーマッターのインスタンス生成コストに注意する
+
+パフォーマンス面で極めて重要な点です。`Intl.NumberFormat` のインスタンス生成時にはロケールデータの読み込みが発生するため、その後の `.format()` 呼び出しよりもはるかに大きな処理コストがかかります。これをレンダリング内や1000行のループの中で毎回実行すると、明確な遅延となって現れます。
+
+```ts
+// 行ごとにフォーマッターを再生成（遅い）
+rows.map((r) => new Intl.NumberFormat(locale).format(r.total));
+
+// 1度だけ生成して再利用（高速）
+const nf = new Intl.NumberFormat(locale);
+rows.map((r) => nf.format(r.total));
+```
+
+`toLocaleDateString()` や `toLocaleString()` も内部で同じ処理を行っています。単一の値の変換には手軽ですが、リストの処理には向きません。
+
+ロケールとオプションの組み合わせをキーにしてキャッシュしましょう。
+
+```ts
+const cache = new Map<string, Intl.NumberFormat>();
+
+const getNumberFormat = (
+  locale: string,
+  options: Intl.NumberFormatOptions = {}
+) => {
+  const key = `${locale}:${JSON.stringify(options)}`;
+  let formatter = cache.get(key);
+  if (!formatter) {
+    formatter = new Intl.NumberFormat(locale, options);
+    cache.set(key, formatter);
+  }
+  return formatter;
+};
+```
+
+## 本番環境だけで発生するタイムゾーンバグ
+
+多くの開発者が頭を抱えてきた問題です。SSR 時にサーバーが日付文字列をレンダリングし、ブラウザでハイドレーションを行う際、出力結果の不一致により React が Hydration Mismatch エラーを出して停止します。
+
+原因は、`Intl.DateTimeFormat` にタイムゾーンを明示しないと実行環境のシステム設定が使われるためです。本番サーバーは通常 UTC で稼働していますが、開発者の PC はローカルタイムゾーン（JST など）です。そのため手元では再現せず、本番環境でのみ障害が発生します。
+
+```ts
+// サーバー（UTC）とブラウザ（JST）で結果が食い違い、ハイドレーション失敗
+new Intl.DateTimeFormat(locale, { dateStyle: "short" }).format(d);
+
+// タイムゾーンを固定すれば完全に一致
+new Intl.DateTimeFormat(locale, { dateStyle: "short", timeZone: "UTC" }).format(
+  d
+);
+```
+
+現実的な3つの解決策：
+
+- **サーバー側でタイムゾーンを固定**し、明示的に渡す。安全かつ確実ですが、全員に UTC が表示されます。
+- **クライアントサイドのみでレンダリング**し、サーバーではプレースホルダーを表示する。ユーザーに正確な時刻を見せられますが、初期表示でチラつきが発生します。
+- **ユーザーのタイムゾーンを保存**し、サーバーとクライアントの双方に渡す。最善のユーザー体験が得られますが、設計の手間が増えます。
+
+どの方法を選ぶにせよ、サーバーとクライアントの両方で描画される日付には必ず `timeZone` を明示してください。タイムゾーンの指定がない日付は、2つの異なる値を持つことになります。
+
+## 通貨に必要なのはロケールではなく通貨コード
+
+ロケールと通貨はまったく別の概念です。`fr-FR` だからといって自動的にユーロになるわけではありません。フランス在住のユーザーが米ドル建ての請求書を見ることもあります。
+
+```ts
+new Intl.NumberFormat("fr-FR", { style: "currency", currency: "USD" }).format(
+  1234.5
+);
+// "1 234,50 $US"
+```
+
+ロケールは区切り文字や記号の位置を制御します。通貨そのものはアプリケーションのデータから指定します。ロケールから通貨を勝手に推測すると、会計上の重大なバグにつながります。
+
+また、`currencyDisplay` も有用です。複数のドル通貨が混在するインターフェースでは、`"code"` を指定することで米ドル、カナダドル、オーストラリアドルの誤認を防ぐことができます。
+
+## 絶対日時よりも相対時間の方が伝わりやすい
+
+最近の出来事であれば、正確なタイムスタンプよりも「2時間前」の方が直感的に伝わります。`Intl.RelativeTimeFormat` はこれを適切に多言語化します。
+
+```ts
+new Intl.RelativeTimeFormat("ja", { numeric: "auto" }).format(-1, "day");
+// "昨日"
+```
+
+`numeric: "auto"` を指定することで、「1日前」ではなく「昨日」と自然に出力されます。
+
+## Intlayer が提供するラッパー
+
+Intlayer はこれらの API をキャッシュ付きヘルパーとして提供しているため、手動でキャッシュ用 Map を管理する必要がなく、アクティブなロケールを自動適用してくれます。
+
+```ts
+import {
+  number,
+  currency,
+  date,
+  relativeTime,
+  units,
+  compact,
+  list,
+} from "intlayer";
+
+number(1234.5); // "1,234.5"
+currency(1234.5, { currency: "EUR" }); // "€1,234.50"
+date(new Date(), "short");
+relativeTime(now, twoHoursAgo, { unit: "hour", numeric: "auto" }); // "2時間前"
+units(5, { unit: "kilometer", unitDisplay: "long" }); // "5キロメートル"
+compact(1200); // "1.2千"
+list(["りんご", "バナナ", "オレンジ"]); // "りんご、バナナ、オレンジ"
+```
+
+`date()` はプリセット（`"short"`, `"long"`, `"dateOnly"`, `"timeOnly"`, `"full"`）も受け付けます。React や Vue 向けのフックやコンポーザブルも用意されており、コンテキストから自動的に言語を解決します。
+
+プラットフォーム標準の `Intl` をベースにしたキャッシュ層とロケール補完機能であるため、内部のフォーマット動作は `Intl` そのものです。詳細は [フォーマッタードキュメント](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/formatters.md) を確認してください。
+
+## よくある失敗
+
+- **ロケール未指定の `toLocaleDateString()`。** 実行環境のデフォルトに依存し、サーバー側ではコンテナ設定に引きずられます。
+- **ループ内での都度フォーマット生成。** インスタンス生成がボトルネックになります。1度生成して再利用してください。
+- **サーバー・クライアント共通日付での `timeZone` 未指定。** ローカルで再現しないハイドレーションエラーの原因になります。
+- **ロケールから通貨を推測する。** `fr-FR` はユーロを意味しません。
+- **画面表示テキストに対する通常の `sort()`。** `Intl.Collator` を使ってください。
+- **月名や曜日名のハードコード。** 全言語のデータがすでに CLDR に揃っています。
+- **相対時間での `numeric: "always"` の放置。** 「昨日」という表現がある言語でも「1日前」と無機質に出力されてしまいます。
+
+## さらに学ぶ
+
+- [フォーマッターとロケールユーティリティ: `number`、`currency`、`date`、`relativeTime`、`list`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/formatters.md)
+- [設定リファレンス](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/configuration.md)
+- [主要フレームワーク間のベンチマークレポート](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/benchmark/index.md)
+- [react-intl互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/react-intl.md)
+- [ICUメッセージフォーマット: 複数形、条件分岐、数値スケルトン](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/icu_message_format.md)
+- [翻訳のテスト戦略（フォーマッターと複数形カバレッジを含む）](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/i18n_testing_strategies.md)
+- [国際化（i18n）がカバーする領域の本質](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/what_is_internationalization.md)

package/blog/ja/detecting_missing_translations.md

@@ -0,0 +1,202 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "ユーザーに見つかる前に翻訳漏れを検出する方法"
+description: 翻訳漏れは静かに発生します。フォールバックがエラーを隠してしまう理由、実際に機能する4つの検出レイヤー、そして未翻訳キーでビルドを失敗させる方法を解説します。
+keywords:
+  - 翻訳漏れを検出
+  - 翻訳キーの不足
+  - i18n 監査
+  - 未翻訳テキスト
+  - 翻訳カバレッジ
+  - i18n lint
+slugs:
+  - blog
+  - detecting-missing-translations
+author: aymericzip
+---
+
+# ユーザーに見つかる前に翻訳漏れを検出する方法
+
+翻訳漏れによってアプリケーションがエラーを投げることはほとんどありません。設定にもよりますが、日本人ユーザーに突然英語が表示されたり、本番環境の画面に `checkout.summary.total` とそのまま出力されたりします。どちらも問題なくデプロイされ、コードレビューをすり抜け、開発者ではなくユーザーからの指摘によって初めて発覚します。
+
+## 目次
+
+<TOC/>
+
+## ライブラリの種類を問わず適用できます
+
+本記事の内容は特定のスタックに限定されません。後述する検出レイヤーは、i18next、react-i18next、next-intl、react-intl、vue-i18n、next-translate、Lingui など、どの環境でも同様に機能します。これらはすべて同じ方法でキーを解決し、同じ理由で不具合を生じるためです。
+
+ツールも同様に移植可能です。翻訳メッセージがJSONカタログとして管理されている場合、[Sync JSON プラグイン](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/plugins/sync-json.md) を使用することで、コンテンツの場所やインポートパスを変更することなくIntlayerの監査、自動補完、テストコマンドを実行できます。
+
+```ts fileName="intlayer.config.ts"
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config = {
+  plugins: [
+    syncJSON({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.json`,
+      format: "i18next", // または next-intl / react-intl 向けに "icu"
+    }),
+  ],
+};
+
+export default config;
+```
+
+ランタイムAPIもそのまま維持したい場合は、[互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/index.md) を使ってバンドラーレベルで `useTranslation` や `$t` などのエイリアスを設定できます。以下のコマンド群は設計思想の一例として捉えてください。
+
+## なぜ翻訳漏れは目に見えないのか
+
+あらゆるi18nライブラリは、同一のルックアップチェーンを採用しています。まずアクティブなロケールを検索し、なければデフォルトロケールにフォールバックし、それでも解決できなければキー名そのものを文字列として返します。この最後のステップこそが問題の本質です。キーの欠落を異常として処理する仕組みがパイプラインにないため、エラーも出ず、本番の警告ログも残らず、テストも通過してしまいます。
+
+フォールバック機能は問題を解決するどころか悪化させます。英語で静かに描画された画面は、英語を話す開発者や自動化テストの目には正常に見えてしまうからです。不具合は、その言語を読めないユーザーにしか見えません。
+
+したがって、「実行時に翻訳漏れをどう扱うか」ではなく、「翻訳漏れがある状態でのマージをどう防ぐか」を考える必要があります。
+
+## 翻訳漏れを捕捉する4つのレイヤー
+
+それぞれのレイヤーで捕捉できる領域が異なります。複数を組み合わせて運用するのが理想的です。
+
+| レイヤー           | 検知できるもの                             | 見落とすもの                         |
+| :----------------- | :----------------------------------------- | :----------------------------------- |
+| 型定義             | そもそも存在しないキー                     | キーは存在するが `ja` の翻訳値が空   |
+| リント (Lint)      | 翻訳対象として抽出されていない直書き文字列 | カタログから不足しているキー         |
+| 監査 (Audit)       | 宣言されたキーに対する全言語のカバレッジ   | そもそも国際化対応されていない文言   |
+| レンダリングテスト | キーは解決されるが表示崩れを起こすケース   | テストで網羅されていないすべての画面 |
+
+多くのチームで盲点となっているのは3行目です。キーの定義自体は正しくても、18言語すべてに翻訳値が存在するかどうかを検証する仕組みが欠落しています。
+
+## レイヤー1: キーを文字列ではなく型にする
+
+`t("checkout.summry.total")` のようなタイポは、文字列のままだと正常にコンパイルされてしまいます。キーが単なる文字列である場合、リネームは本番障害のリスクを孕み、削除のたびに孤立したキーが蓄積されます。
+
+キーを型付けすることで、タイポをビルドエラーとして検知できます。`react-i18next` では宣言のマージ（Declaration Merging）、`next-intl` ではメッセージ構造からの推論、LinguiではソーステキストからのID生成、Intlayerでは宣言ファイルからの型自動生成によって実現されます。
+
+ただし、このレイヤーは必要条件であっても十分条件ではありません。型はデフォルトカタログの構造を保証するだけであり、韓国語にそのキーの値が存在するかどうかは関知しないためです。
+
+## レイヤー2: キーになっていない直書き文字列をリントする
+
+見つからない翻訳の多くは、最初から外部ファイル化されていないテキストです。コンポーネント内にハードコードされた文言は、カタログ監査ツールからは認識できません。ツールにとって、その文字列は存在しないのと同じだからです。
+
+IntlayerのESLintプラグインは、`no-raw-text` によって直書きテキストを検出し、さらに `no-unused-content` によって宣言されているがどこからも使われていない不要なコンテンツを検出します。
+
+```js fileName="eslint.config.mjs"
+import intlayer from "@intlayer/eslint-plugin";
+
+export default [
+  intlayer.configs.recommended,
+  {
+    rules: {
+      "@intlayer/no-raw-text": "error",
+      "@intlayer/no-unused-content": "warn",
+    },
+  },
+];
+```
+
+`no-unused-content` は、カタログが無駄に肥大化するのを防ぎます。使われていないデッドキーは動作エラーにはなりませんが、外部翻訳サービスへの発注費用を無駄に跳ね上げる原因となります。ルールの詳細は [ESLintプラグインドキュメント](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/eslint.md) を参照してください。
+
+## レイヤー3: ロケールカバレッジの監査
+
+これこそが最も本質的な問いに答えるレイヤーです。IntlayerはこれをCLIコマンドとして提供しています。
+
+```bash packageManager="npm"
+npx intlayer content test
+```
+
+設定されたロケールと宣言された辞書を読み込み、どのファイルのどのキーにどの言語が不足しているかを詳細に出力します。
+
+CIに組み込む前に知っておくべき注意点として、**このCLIはレポートを出力しますが終了コード0を返します。** そのため、そのままパイプラインに入れると、ビルドが通ったままログの中に警告が埋もれてしまいます。ビルドを停止させたい場合は、後述のプログラムAPIを使用してください。
+
+## レイヤー4: テストスイート内でアサーションを行う
+
+`listMissingTranslations()` は同じ監査結果をデータ構造として返すため、CIのゲートとして最適です。
+
+```ts fileName="i18n.test.ts"
+/* @vitest-environment node */
+import { listMissingTranslations } from "intlayer/cli";
+import { describe, expect, it } from "vitest";
+
+describe("translations", () => {
+  it("必須ロケールに翻訳漏れがないこと", async () => {
+    const result = await listMissingTranslations();
+
+    if (result.missingRequiredLocales.length > 0) {
+      console.log(result.missingTranslations);
+    }
+
+    expect(result.missingRequiredLocales).toHaveLength(0);
+  });
+});
+```
+
+戻り値には以下の3つの重要なフィールドが含まれます。
+
+- `missingTranslations`: キーごとに、どの言語がどのファイルで不足しているか。テスト失敗時に出力すべき情報です。
+- `missingLocales`: 全キーを通じて不足している言語のユニオン。
+- `missingRequiredLocales`: 設定内の `requiredLocales` に限定された不足言語（未設定の場合は全言語が対象）。
+
+## `requiredLocales` が実用的な運用を可能にする
+
+18言語を提供しているからといって、全言語が100%揃うまでデプロイを止めるべきではありません。多くのチームでは、リリースをブロックする必須言語と、順次補完していく言語を段階的に分けて管理しています。
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [
+      Locales.ENGLISH,
+      Locales.FRENCH,
+      Locales.JAPANESE,
+      Locales.POLISH,
+    ],
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+};
+
+export default config;
+```
+
+`requiredLocales` を指定しない場合、宣言された全言語が必須扱いとなり、翻訳が遅れている言語が1つあるだけでビルドが止まり続けます。その結果、チェック自体が無効化されてしまうケースが後を絶ちません。
+
+## すでに本番に紛れ込んだ漏れを見つけ出す手法
+
+ここまでの方法は新たな翻訳漏れの混入を防ぐためのものです。すでにリリース済みのアプリに対しては、以下の2つの手法が効果的です。
+
+**疑似ローカライゼーション。** 全文字列を `[!!! Ĉĥéçķöũţ !!!]` のように変換するテスト用ロケールでアプリを動かします。英語のまま残っている部分は確実にコードに直書きされています。画面そのものを検証するため、カタログ監査ツールでは不可能な検出をわずか10分で完了できます。
+
+**自社サイトのクローリング。** 言語別URLを使用している場合、ロケールごとのページを取得し、HTML内にデフォルト言語の文言が含まれていないか検索します。`/ja/` のページに "Add to cart" が含まれている場合、それは翻訳漏れか、意図しないフォールバックが発生している証拠です。
+
+```bash
+curl -s https://example.com/ja/checkout | grep -c "Add to cart"
+```
+
+## 不足した翻訳を補完する
+
+不足箇所が判明したら、`intlayer fill` で空のエントリを自動入力できます。また、`autoFill` オプションを使用すれば、コンテンツを宣言した時点で言語別ファイルを自動生成できます。詳細は [autoFill](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/autoFill.md) を参照してください。
+
+ここで重要なのは、機械による自動補完は「目に見える不足」を「目に見えない不足」に変える手段にすぎないという点です。キーが埋まるためテストはパスしますが、その文言はまだ誰もレビューしていません。開発をブロックしないための足場として活用し、重要な文言は必ず人間の手で確認してください。
+
+## よくある失敗
+
+- **フォールバックを安全対策だと錯覚する。** エラーを隠す緊急回避策にすぎません。英語で静かに表示されるのはバグです。
+- **CLIレポートだけでCIを止めようとする。** `intlayer content test` は正常終了するため、テストコード内でアサーションを行ってください。
+- **全言語を必須にしてしまう。** リリースが止まり、最初の障害で監査ごと撤廃される原因になります。
+- **カタログだけを見て画面を見ない。** 直書きされたテキストはカタログ監査には絶対に現れません。
+- **デフォルト言語しかテストしない。** 欠落するはずのない言語を検証しても意味がありません。
+- **機械翻訳だけで作業を完了させてしまう。** 監査はパスしても、品質が保証されていないテキストが残ります。
+
+## さらに学ぶ
+
+- [コンテンツのテスト: CLI監査、プログラムAPI、UIアサーション](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/testing.md)
+- [ESLintプラグインルール (`no-raw-text`、`no-unused-content`)](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/eslint.md)
+- [autoFill: ロケール別宣言ファイルの自動生成](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/autoFill.md)
+- [設定リファレンス: `locales`、`requiredLocales`、`defaultLocale`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/configuration.md)
+- [主要フレームワーク間のベンチマークレポート](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/benchmark/index.md)
+- [i18next互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/i18next.md)
+- [国際化（i18n）がカバーする領域の本質](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/what_is_internationalization.md)
+- [コンポーネント指向 vs 集中管理型i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/per-component_vs_centralized_i18n.md)