I also think that DNN has taken a strategic wrong turn in disabling ASP.NET 2.0 localization features in favour of it's home-grown version of the same. Why?

• ASP.NET localization is more powerful (multiple implicitly localizable properties per control, as opposed to DNN's single property)
• ASP.NET localization is more economical to implement (implicit and explicit syntax means you rarely have to write a line of code)
• ASP.NET localization is part of the framework on which DNN is built: why reinvent the wheel and increase the size of the code-base DNN has to maintain?

As it appears that the ASP.NET features are disabled using a switch in web.config, how difficult would it be to only enable the DNN localization system when the ASP.NET system is disabled, thereby giving users the choice of which system the want to use? That would also provide compatibility for existing modules and skin objects that do it the DNN way.

---

Paul Taylor

DotNetNuke, ASP.NET and SQL Server Development