Skip to content

MS_ASPNETI18N

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

ASP.NET の 国際化対応

概要

ASP.NET の国際化対応方法について説明する。

補足（国際化対応で決めること）: 「リソースをどう持つか」以前に、
カルチャをどう決定するかを設計する必要がある。

【カルチャの決定方法】
  ① ブラウザの Accept-Language ヘッダー   … 自動。ユーザーは変えられない
  ② URL に含める（/ja/... , ?culture=ja） … SEO に有利。共有しやすい
  ③ Cookie に保存                          … ユーザーの明示的な選択を保持
  ④ ユーザー プロファイル（DB）            … ログイン後に適用

実務では ③（切り替え UI）＋ ① （初回の既定）の組み合わせが多い

ASP.NET（.NET Framework）では <globalization> の
culture="auto" / uiCulture="auto" で ① が使える。

<system.web>
  <globalization culture="auto:ja-JP" uiCulture="auto:ja" />
</system.web>

auto:<既定> の形にしておくと、
ブラウザが送ってこない場合の既定値を指定できる。

国際化対応方法

リソースファイル

  • 各カルチャ用のリソースファイルを用意しておきコードで国際化対応する。

  • ASP.NET には、以下のリソースファイルがある。

    • グローバル・リソース（App_GlobalResources）
    • ローカル・リソース（App_LocalResources）

  • 上記が一般的に言われている方法だが、
    必ずしも、以下のフォルダにリソースファイルを配置する必要はない模様。

    • グローバル・リソース（App_GlobalResources）
    • ローカル・リソース（App_LocalResources）
    • 参考

補足（2 つのリソースの違いと、現在の推奨）: ASP.NET 固有の
この 2 フォルダは、ASP.NET Web Forms 向けの仕組みである。

App_GlobalResources App_LocalResources
範囲 アプリ全体 特定のページ専用
命名 Messages.resx Default.aspx.resx（ページ名 + .resx）
参照 Resources.Messages.Key <%$ Resources: Key %>
暗黙のローカライズ － meta:resourcekey で自動適用

原文の「必ずしも配置する必要はない」という指摘は重要で、
この 2 フォルダには次の制約がある。

・実行時に動的コンパイルされる（[プリコンパイル](MS_Precompile) 参照）
    → 起動が遅い、コンパイル エラーが実行時まで分からない
・別アセンブリ（クラス ライブラリ）から参照できない
・[ASP.NET MVC](MS_ASPNETMVC) では暗黙のローカライズが使えず、利点が薄い

**現在の推奨は「通常の .resx をプロジェクトに置く」**方式である
（リソースファイル の標準的な使い方）。
原文が参照している記事も、同じ結論に至っている。

jQuery

JavaScript でメッセージを表示させている場合、
globalize.js などの jQuery プラグインを使う。

補足（クライアント側の国際化／最新化）: jquery-globalize は
現在ほぼ使われていない。標準 API とライブラリが整備されたためである。

用途 現在の手段
日付・数値・通貨の書式 Intl API（ブラウザ標準。ライブラリ不要）
相対時刻（「3 分前」） Intl.RelativeTimeFormat
文言の切り替え i18next、react-i18next、vue-i18n
複数形・性別の変化 Intl.PluralRules、ICU MessageFormat 
// 標準 API だけで書式化できる
new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' })
    .format(1234);                       // → ￥1,234
new Intl.DateTimeFormat('ja-JP', { dateStyle: 'long' })
    .format(new Date());                 // → 2026年8月19日

サーバ側とクライアント側で文言を二重管理しないことが要点で、

  • 画面の文言はクライアント側に寄せる（SPA の場合）
  • サーバは API のエラー メッセージだけを返す
    （またはエラー コードを返し、文言はクライアントが持つ）

という切り分けにすると、管理が単純になる。

補足（ASP.NET Core での国際化／最新化）: 本ページの方式は
System.Web 前提で、ASP.NET Core では
仕組みが刷新されている（リソースファイル の補足も参照）。

// Program.cs
builder.Services.AddLocalization(o => o.ResourcesPath = "Resources");
builder.Services.AddControllersWithViews()
    .AddViewLocalization()
    .AddDataAnnotationsLocalization();

var supported = new[] { "ja", "en" };
app.UseRequestLocalization(new RequestLocalizationOptions()
    .SetDefaultCulture("ja")
    .AddSupportedCultures(supported)
    .AddSupportedUICultures(supported));

カルチャの決定は RequestCultureProvider が担う（既定は次の順）。

# プロバイダー 決定方法
1 QueryStringRequestCultureProvider ?culture=ja&ui-culture=ja
2 CookieRequestCultureProvider Cookie（.AspNetCore.Culture）
3 AcceptLanguageHeaderRequestCultureProvider ブラウザの設定

URL のパスに含めたい（/ja/home）場合は
RouteDataRequestCultureProvider を自作するか、
ルート テンプレートに {culture} を入れる。

言語切り替え UI は、標準で用意されている
SetLanguage アクションの実装例が公式ドキュメントにある。

参考

ASP.NET Web Formsの国際化対応

ASP.NET MVCの国際化対応

Microsoft Learn

Tags: 移行, .NET開発, ASP.NET, 国際化対応

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally