Scott Hanselman

I presented at ASPLive! and TechEd 2003 on Internationalizing ($g(i18n)) ASP.NET.  I know that the story changes with Whidbey and changes dramatically post-Whidbey, but until then...what are the best practices for ASP.NET 1.1?   DasBlog is a good example, as is (IMHO) the code I showed at the conferences.  Each takes certain approaches for performance vs. ease of i18n vs. avoiding $g(code smell).

Some random thoughts, some questions, some rethorical, some I could use comments/thoughts on:

• Store a single ResourceMananger in the Application Object and either yank and cast as needed or stick it in some base blass.  [Seems reasonable.  Preferable over instantiating on each page?]
• Create a base class (LocalizedPage, etc) that introduces an "OnLocalize" method and event, and performance most of your i18n there. [Good, but usually only an 80% solution.  Does let you bypass localization for the default language, though, and that's a BIG performance gain.]
• For DataGrids, piggyback on DataBinding and do your i18n here [Not bad, easy, tends to spread i18n code out]
• Localize in the .aspx page with <%#resMan.getString("someresourcename")> [Good, avoid cluttering code behind, also allows for quick changes without recompiles, although forces localization in the default language]

This and other questions burn...time to refactor...Now this looks like an interesting tool that makes ASP.NET localization more like WinForms localization.  I'll check out the trial, but I suspect it will break down when faced with complex ASP.NET DataGrids (definitely non-trivial to localize).

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By