4

私は ASP.NET を使い始めたばかりで、健全だと思ういくつかのコーディング標準を取り入れようとしています。そのような標準の中には、多言語サポートと、将来の変更を容易に処理するためのリソースの使用があります。

デスクトップ アプリケーションのコーディングを行っていた頃は、すべてのテキストを翻訳する必要があったため、顧客に提供する言語ごとに言語ファイルを用意するのが一般的でした。これらのファイルでは、ボタン ラベルからエラー メッセージまで、すべてのテキストをマッピングします。ASP.NET では、Visual Studio の助けを借りて、IDE を使用してそのようなリソース ファイルを生成する手段があります ([ツール] -> [ローカル リソースの生成] から)。記事やチュートリアルから学んだことです。しかし、そのようなアプローチは少し奇妙に見えます。今質問に：

  1. ウェブサイトのすべてのテキストをラベルとして保持し、そのコンテンツをリソース ファイルで管理する必要がありますか? 特にいくつかの段落を含むテキストを考えると、奇妙に見えます/感じます。

  2. ボタンなどの何かを aspx ファイルに追加/削除するたびに、それをリソース ファイルにも追加する必要があります。それは私にとって再利用可能なコードのようにはまったく感じられません。

おそらく、標準化された問題のようには見えないため、チュートリアルからすべて間違っている可能性があります-特に、変更を行う必要があるたびにアプリケーション全体を再コンパイルする必要がある場合.

4

1 に答える 1

8

ASP.NET Web フォームのローカリゼーションのベスト プラクティスは、長年にわたってあまり変わっていません。動的コンテンツがあまりない場合は、暗黙的なローカリゼーションを回避し、Web フォーム コントロール (フォーム要素、さらにはラベル) をリソース ファイルにバインドできます。明示的なローカリゼーションは、ローカライズされたテキストが複数のキャプションを持つコントロールまたは自分で作成したコントロールでレンダリングされる場所をもう少し制御したい場合に便利です。これらのいずれかを行う方法について、MS からの指示手順を遠くまで探す必要はありません。

チュートリアル: ASP.NET でのローカリゼーションにリソースを使用する

ローカリゼーションの要件がより動的である場合、たとえば、新しい言語を簡単にプロビジョニングしたり、リソースを集中化したり、新しい次元で新しい文字列キャプションをプロビジョニングする必要がある場合 (クライアントごとなど)は、もう少しクリエイティブになる必要があります。.NET を使用すると、リソース プロバイダーを拡張でき、ローカライズされたリソースを簡単に管理できるデータベース バックエンドを実装できます。

ASP.NET 2.0 リソース プロバイダー モデルの拡張、データベース リソース プロバイダーの構築

データベースにリソースを格納するための Resource-Provider の拡張* より最近の実装

または、自分でロールすることもできます。

重複した SO 投稿も掘り下げました。数年前のものですが、経験から言えば、参照されているコード プロジェクト ページにあるアドバイスは (Web フォームの場合) 今でも正しいと思います: Globalization and localization demystified in ASP.NET 2.0

それが役立つことを願っています！ローカリゼーションに関してさらに具体的な質問がある場合は、質問またはコメントに追加してください。

于 2012-06-30T15:12:28.333 に答える