ロケール (locale) は、言語・地域・書式設定の組み合わせを表す識別子です。ja-JP (日本語・日本)、en-US (英語・米国)、zh-CN (中国語・中国) のように、言語コードと地域コードを繋げた形が代表的で、言語コードは ISO 639、地域コードは ISO 3166-1 に由来します。同じ言語でも地域によって表記規則が異なるため (例: en-US と en-GB では日付形式やスペルが異なる)、言語コードだけでなく地域コードも重要です。

ただし識別子の構造は「言語 + 地域」の 2 要素に限られません。BCP 47 として標準化された言語タグは、言語・書字系 (script)・地域・変種 (variant) のサブタグをこの順に並べ、さらに暦や時刻表記といった細かい指定を加える拡張を後ろに付けられる構造になっています。書字系のサブタグが欠かせない代表例が中国語で、簡体字は zh-Hans、繁体字は zh-Hant と書き分けます (書字系のコードは ISO 15924 に由来します)。簡体字を使うシンガポール、繁体字を使う香港のように地域と書字系は一対一に対応しないため、zh-CN と zh-TW の 2 択だけで組むと取りこぼしが生じます。日本語にも ja-Jpan-JP のような書字系込みの形がありますが、書字系が事実上 1 つに定まる言語では省略するのが通例です。

ロケールは日付形式 (2025/01/15 vs 01/15/2025 vs 15.01.2025)、数値形式 (1,000.50 vs 1.000,50)、通貨記号 (¥ vs $ vs €)、ソート順序、テキストの方向 (LTR/RTL) など、テキスト表示のあらゆる側面に影響します。たとえば、ドイツ語ロケール (de-DE) では小数点にカンマを使い、桁区切りにピリオドを使うため、「1.000」は千を意味します。この違いを無視すると、金額や数量の表示で深刻なバグが発生します。

JavaScript では Intl オブジェクトがロケール対応の書式設定を提供します。Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' }) で「￥1,000」のような日本式の通貨書式が得られます。ここで付く円記号は全角の ￥ (U+FFE5) で、同じ JPY を en-US で整形したときに使われる半角の ¥ (U+00A5) とは別の文字です。見た目が近いため気付きにくいものの、表示幅の計算や、全角を 2 文字として数える方式のカウンタでは差になって現れます。上限をバイト数で管理している場合は、UTF-8 で全角の円記号が 3 バイト、半角が 2 バイトという違いも効いてきます。Intl.DateTimeFormat、Intl.Collator、Intl.PluralRules なども用意されており、ロケールに応じた日付表示、文字列ソート、複数形の処理が可能です。

Web サイトの多言語対応では、ユーザーのブラウザロケール (navigator.language) を検出して適切な言語版を表示する仕組みが一般的です。ただし、ブラウザのロケール設定がユーザーの希望言語と一致しないケースもあるため、言語切替の UI を必ず提供すべきです。HTML の lang 属性、hreflang タグ、Accept-Language ヘッダーなど、ロケールに関連する Web 標準は多岐にわたります。

よくある誤解として、ロケールと文字エンコーディングを混同するケースがあります。ロケールは表示形式の規則を定義するものであり、文字の符号化方式 (UTF-8、Shift_JIS など) とは別の概念です。また、ロケールを切り替えても、保存されているテキストデータそのものが書き換わることはありません。変わるのはそのデータの表示方法です。ただし文字列を加工する処理まで含めると例外があります。大文字・小文字の変換はロケールに依存し、JavaScript の toLocaleUpperCase に「istanbul」を渡すと、既定のロケールでは「ISTANBUL」になるのに対し、トルコ語 (tr) を指定するとドット付きの大文字 İ (U+0130) が使われて「İSTANBUL」になります。トルコ語やアゼルバイジャン語では i と I の対応が他の言語と異なるためで、変換後の文字列を比較したり検索キーに使ったりするコードでは実害のあるバグ源になります。大文字・小文字を無視した比較では、ロケール依存の変換を避けてロケール非依存の toLowerCase を使うか、Intl.Collator の sensitivity 指定で比較するのが安全です。

文字数カウントの観点では、ロケールによって同じ情報を表現するのに必要な文字数が大きく異なります。たとえば 2025 年 1 月 15 日という同じ日付を Intl.DateTimeFormat の長い形式で整形すると、日本語 (ja-JP) は 2025年1月15日 の 10 文字、英語 (en-US) は January 15, 2025 の 16 文字、ドイツ語 (de-DE) は 15. Januar 2025 の 15 文字になります。日本語が最も短いのは、年・月・日をそれぞれ 1 文字の漢字が担い、区切りの空白も入らないためです。ただし短いのは文字数の話で、全角の分だけ表示幅は文字数の比ほど縮みません。なお日本語の文中では読みやすさのために数字の前後へ半角の空白を入れる表記もあり、その場合は同じ日付が 15 文字になります。数える対象がプログラムの出力なのか人が書いた文面なのかで結果が変わる好例です。多言語サイトで文字数制限のある UI 要素 (ボタン、ラベルなど) を設計する際は、ロケールごとの文字数の違いを考慮する必要があります。