Internationalization/Globalization and ASP.NET Brainstorming at 1:05am
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).