Skip to content

MS_ASPNETWebFormsI18N

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

ASP.NET Web Formsの国際化対応

概要

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

リソースファイル

  • ASP.NET Web Formsでは、
    Windows Formsのような
    （レイアウト変更なども含めた）高機能な国際化対応機能は実装されていない。

  • リソースファイルや、globalize.js などの jQuery プラグインを
    使用して、地道に国際化対応を行う。

  • ただし、*.aspx から直接リソースファイルを参照する場合は、
    以下の専用構文を使用し、
    App_GlobalResources に配置したリソースファイルとしか
    バインドできないもよう。

Text="<%$ Resources:リソースファイル名, キー名 %>"

移行メモ（表記）: 原文の「App_GlobalResouces」は
App_GlobalResources の綴りの誤りと判断し修正した。

補足（明示的／暗黙的ローカライズ）: Web Forms には
2 通りの書き方があり、原文が挙げているのは前者である。

① 明示的ローカライズ（App_GlobalResources）

<asp:Label runat="server" Text="<%$ Resources: Messages, Greeting %>" />
  • App_GlobalResources のリソースしか参照できない（原文の指摘通り）
  • 1 項目ずつ書く必要がある

② 暗黙的ローカライズ（App_LocalResources）

<asp:Label runat="server" meta:resourcekey="lblGreeting" />
App_LocalResources\Default.aspx.resx
    lblGreeting.Text = "こんにちは"
    lblGreeting.ToolTip = "あいさつ"
  → プロパティ名を "." で繋いだキーを書くだけで
    複数のプロパティを一括で当てられる

② の方が記述量が少ないが、

  • ページ名と .resx 名が結び付く（ページを改名すると壊れる）
  • キーが文字列で、タイプミスが実行時まで分からない
  • App_LocalResources は実行時に動的コンパイルされる
    （プリコンパイル、ASP.NET の 国際化対応 の補足を参照）

という難点がある。

原文が「地道に」と表現している通り、
Web Forms のローカライズは Windows Forms ほど自動化されていない。
Windows Formsの国際化対応 では
配置・サイズまでデザイナが面倒を見るのに対し、
Web Forms ではCSS で対応することになる。

参考

ブラウザの言語設定で、HTTP リクエスト ヘッダに「Accept-Language: ja」と
カルチャ情報が付与されるためデフォルトでこれを使用してもよいが、
通常システムで制御した方が良い。

アプリケーションによっては、それらを個別に設定することが必要な場合もある。
例えば Web オークション サイトでは Web ブラウザごとに UI カルチャは変わるが、
カルチャ自体は変更されない（価格に適用される通貨と表示形式は常に一定になる）。

補足（この引用は重要）: 引用されている
「Web オークション サイト」の例が、
リソースファイル で述べた
CurrentCulture と CurrentUICulture を分ける必要性を
端的に示している。

UI カルチャ（文言）      … ユーザーの言語に合わせる → en / ja / zh
カルチャ（書式・通貨）    … 商品の通貨に固定する    → 常に ja-JP（円）

  → 英語表示でも金額は「￥1,234」のまま
  → 逆にすると、英語ユーザーには "$1,234" に見えて事故になる

<!-- 文言だけブラウザに合わせ、書式は固定する -->
<globalization culture="ja-JP" uiCulture="auto:ja" />

**「通貨は換算しないなら、書式も変えない」**というのが原則である。

DB などのストアを使用する。

  • ASP.NET Web Formsでは、
    Form 内のコントロールを再帰的に検索して処理することができる。

  • このため、DB などの別ストアにディクショナリを用意し、
    Form 内のコントロールを再帰的に検索して caption・label を切り替える方式も可能である。

参考

補足（DB 方式の利点と代償）: リソースファイル で
述べた**「再ビルドが必要」という制約を回避する**方式である。

.resx 方式 DB 方式
文言の変更 再ビルド・再配置が必要 運用中に変更可能
変更の権限 開発者 運用担当・業務部門に委譲できる
性能 高速（メモリ上） DB アクセス（キャッシュ必須）
型安全性 型付きプロパティ 文字列キー
未翻訳の検出 ビルド時／フォールバック 自前で仕組みを作る
履歴・承認 Git DB 側で用意する必要

業務アプリで文言の微修正が頻繁（「得意先」→「取引先」等）な
場合は DB 方式の価値が高い。
ただし、

  • 必ずキャッシュする（画面表示のたびに DB を引かない）
  • キャッシュの無効化（変更時にクリアする）を設計する
  • フォールバック（キーが無い場合の表示）を決める

といった作り込みが要る。

**原文が言う「再帰的に検索して切り替える」**手法は、
Web Forms の Control.Controls を辿るものだが、

void Localize(Control parent)
{
    foreach (Control c in parent.Controls)
    {
        if (c is Label lbl && !string.IsNullOrEmpty(lbl.ID))
            lbl.Text = Dictionary.Get(PageName, lbl.ID) ?? lbl.Text;
        if (c.HasControls()) Localize(c);   // 再帰
    }
}

ID をキーにするため、
ID の変更が文言の紛失に直結する点に注意が要る。

ASP.NET Core（MVC / Razor Pages）ではこの手法は使えない
（コントロール ツリーが存在しない）。
代わりに IStringLocalizer を自作して DB から引くのが
同等かつ素直な実装になる。

public class DbStringLocalizer : IStringLocalizer
{
    public LocalizedString this[string name]
        => new(name, _cache.Get(CultureInfo.CurrentUICulture.Name, name) ?? name,
               resourceNotFound: false);
    // ...
}

builder.Services.AddSingleton<IStringLocalizerFactory, DbStringLocalizerFactory>();

抽象（IStringLocalizer）が標準で用意されているため、
呼び出し側のコードを変えずに
.resx 方式と DB 方式を差し替えられる——これが
ASP.NET Core における国際化の設計上の利点である
（DI / 依存性反転原則）。

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

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally