First a short resume for all the people don't want read the whole article.
Even with DotNetNuke 6.0 it is not possible to create fully functional multi language portals.
My hope was, never must write an article like this, but the team around DotNetNuke did not make it in the past 9 years to implement multi language support, so that it is really possible to build multi language portals.
I had the hope, that with the big change from VB to C# the DNN team will finally take care of that problem.
Unfortunately, my hopes were not fulfilled.
Not now, not with DNN 6.0 and not with that concept of multilanguage implementation.
Let me explain in a very short manner the multi language concept of DotNetNuke .
- Concept Start
- All pages with all included modules and content will duplicated for all installed and activated languages.
- Concept End
OK, this is really the very short version, but as I said, I will only describe the simple principle, and that's the base idea.
A major advantage of this basic concept has at least:
Existing modules (most of them) could be used without changes for portals with multi language support.
The implementation and operation are so confusing as I have not seen any other code in DotNetNuke. Starting with the activation of content localization, which is a one way.
If you have clicked one time the link button "Enable Content Localization" there is no way back, without a backup or with a lot of difficult changes and corrections in the database. I guess only a few people (me included) are able to make these changes. (A little advertising is allowed)
In addition, the handling of these features is not intuitive so that the training effort would be longer as the training effort for all other feature including the portal administration.
To make matters worse, the following points are still unresolved with this concept:
- Host Lists
- Permission Settings (Roles)
As you can hear Shaun Walker and Co. are convinced of their concept. Even when people who know a lot more about the needs of a multi language implementation like him and his team, exposed the weaknesses and told Shaun Walker and his team what is wrong.
But it's not really a surprise, I know that already since 2003/2004 again and again different people talk to Shaun and his team about the urgent need of multi language feature. In some cases those people were also involved in the core development, but as far as we can see, those people did not have the necessary influence.
I remember that already 2003/2004 a first (German) multi language version was available. Some International people have done a lot of work to adopt the work of Shaun Walker and his team to give some additional feature to DotNetNuke. But as far as I remember, this work and the people who have done this work did not find the grace of Shaun and his team.
And ... that was the first chapter and the first chance to get more international with DNN in an very early stadium.
It has been around for years, developers who works on multi language support for DotNetNuke.
But why, these people and their concepts, are not highly involved with the necessary multilingualism in DotNetNuke.
If the localization of static elements in ASP.NET application are not so simple and not already defined by the .NET framework, then we would, I believe, at least, today still waiting for using DotNetNuke for a not English website.
At least, not without creating a unique piece of code that no longer would be upgradable.
Of course there are third party solutions for multilingual portals with DNN, but I find none of these solutions work 100%.
And a theme like multi language support should be a theme of the core product and not of third party products.
If I must build today a multilanguage portal for a customer, then I do not use DNN, or if DNN is a must be (due to use existing modules), then I take a child portal solution (for each language a separate child portal), which is incidentally very close to the "new" concept of version 6.0.
But with this solution, at least the taxonomy and search problems are solved