多言語対応しなくても i18n を入れる理由は、表記揺れをなくすため

多言語対応を予定していない場合でも、i18n ライブラリを導入し、文言をメッセージファイルで管理しておく方法があります。
この方法を取ると、表記揺れに気づきやすくなるという利点があります。

この記事では主にフロントエンドの文脈で話を進めますが、考え方自体は特定の領域に限定されるものではありません。その点を踏まえて読んでいただければと思います。

表記揺れという課題

私は個人開発で Web アプリを作っており、次のようなサービスを公開しています。

• Fequest
  • https://fequest.vercel.app
• Fequest 管理画面
  • https://fequest-admin.vercel.app

このサービスは、プロダクトに対する改善要望や新機能のリクエストを投稿でき、開発者はそれを参考に開発を進めていくものです。ユーザーと開発者の双方でプロダクトを育てていくことを目的としています。

Fequest 自体へのリクエストを集めるページも用意しています。

Fequest | Fequest

ほしいとつくるを共有するプラットフォーム。 ユーザーがほしい機能をリクエストし、開発者がそれをつくるにつなげる、みんなでプロダクトを育てる場所です。

fequest.vercel.app

実際に開発を進めていくと、表示する文言が気になる場面が増えてきます。

たとえば、次のようなケースです。

• 「プロダクト」と書くか、「サービス」と書くか
  • ドメイン用語が定まっていないことによる違い
• 「申し込み」と書くか、「申込み」と書くか
  • 日本語特有の表記の違い

このような表記揺れがページごとに存在すると、複数ページを横断して読むユーザーに、違和感や混乱を与える可能性があります。

AI 利用による影響

近年は、AI を使ってコード生成を行う、いわゆるバイブコーディングの流れが広がっています。私自身も、その方法を取り入れています。

一方で、十分にコンテキストを共有しないまま AI に実装を任せると、文言の表現が少しずつ異なるコードが生成されることがあります。開発を進めるほど、その差分が蓄積されていく傾向があります。

メッセージファイルでの管理

こうした状況への対応策の一つとして、メッセージファイルを用意する方法があります。
多言語対応を行わない場合でも、next-intl などの i18n ライブラリを利用して文言を集約する選択肢があります。自作の仕組みでも問題ありません。

日本語の文言を一つのファイルにまとめておくと、全体を俯瞰しやすくなり、表記揺れに気づきやすくなります。

以下は、メッセージファイルの例です。

{
  "top": {
    "tagline": "ほしいとつくるを共有するプラットフォーム",
    "description": "ユーザーがほしい機能をリクエストし、開発者がそれをつくるにつなげる、みんなでプロダクトを育てる場所です。"
  },
 
  "request": {
    "empty": "リクエストはまだありません。",
    "loginToPost": "ログインするとリクエストを投稿できます。",
    "newAriaLabel": "新しいリクエスト"
  },
 
  "requestEdit": {
    "title": "リクエストの編集",
    "description": "{productName} へのリクエスト「{requestTitle}」を更新します。",
    "form": {
      "titleLabel": "タイトル",
      "contentLabel": "内容",
      "contentPlaceholder": "改善内容や背景を入力してください"
    },
    "buttons": {
      "save": "保存する",
      "cancel": "キャンセル",
      "delete": "削除する"
    }
  },
 
  "toast": {
    "save": {
      "loading": "保存中...",
      "success": "保存しました",
      "error": "保存に失敗しました"
    },
    "delete": {
      "loading": "削除中...",
      "success": "削除しました",
      "error": "削除に失敗しました"
    }
  },
 
  "error": {
    "required": "必須項目です",
    "unexpected": "予期しないエラーが発生しました"
  }
}

この例では一つのファイルにまとめていますが、単語帳と文章を役割ごとに分ける設計も考えられます。

直接記述を避ける工夫

さらに、静的解析を利用し、コード中に直接文字列を書くことを検知するルールを設ける方法もあります。 この仕組みを用いると、AI が生成したコードであっても、文言の直接記述に気づきやすくなります。

結果として、文言は自然とメッセージファイルへ集約されていきます。

導入の進め方

メッセージファイルの構造は、最初から厳密に設計する必要はありません。 初期段階では、ページ単位で愚直に定義していく方法も考えられます。

構造化されたデータであれば、後から機械的に整理することが可能です。 必要に応じて、少しずつ整えていく進め方も選択肢の一つです。

その他

別の方法として、textlint のような、テキストに対して静的解析を行うツールを利用し、問題を検知するという選択肢もあります。