I 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 the system they use? That would provide compatibility for existing modules and skin objects that do it the DNN way.

---

Paul Taylor

DotNetNuke, ASP.NET and SQL Server Development

Hi Sebastian,

Yes, fair point, I'm not taking into account the history, and I'm overlooking the advantages that DNN localization offers. Localization per portal is a case in point. Thanks for bringing it to my attention.

On the other hand, ASP.NET does support fall-back - a natural fall-back chain from a specific to a general culture and then to a "neutral" culture (eg. fr-CA, fr, default) which is what you'd normally define manually in DNN anyway. I can't think of any use cases that would lead you to configure it differently.

The reason I'm thinking about this is that I need to make a decision on which set of UI controls to use for a particular project. It turns out that the best candidate from every other point of view has one significant disadvantage: that it is going to mean devising my own localisation system, simply because DNN has blocked ASP.NET localization features.

Thanks for the tip about Brandon Haynes' project, I'll check it out.

---

Paul Taylor

DotNetNuke, ASP.NET and SQL Server Development