I usually do not post in the US community forums although I would describe myself as an active community member, more in the european part of the world though. But as I was just about to throw my notebook out of the window I thought I better calm down and get my hands dirtty on writing a thread here...

It is very unfortunate that I just didn't have the time to look at the ML capabilties in DNN 5.5. earlier. I would have told you right from the beginning that the way the whole thing is implemented as of today just doesn't work. It took me only 5 minutes to break a new install after enabling content localization. I can't reproduce my steps as they were too many to record but that's exactly the main issue amongst many others:

• Too many buttons that make no sense from their wording to the non-technical user (actually they didn't make sense to me as well)
• Different page Urls for localized pages? Why the hell is that?
• Empty module content after enabling the localization
• Non working locale selector when content localization is not yet enabled

That means to me that I have to tell my clients - e.g. those who use my ML modules -  that they should not under no cicumstances ever upgrade to DNN 5.5, which in fact means the end of their upgrade path.

I remember that back in Paris I was telling Shaun that DotNetNuke's preferred model would break my ML business model and he said, "Oh well, you'll find another niche to build modules in". While one could say that this is a pretty arrogant statement I in fact would be more that happy if could take another route, leaving my clients to an easy to use ML capable DotnetNuke solution - but that's not what DNN provides! It's neither easy to use nor is it anything like rock solid. It's a case study maybe. A trunk in a the SVN. Whatever, it's defintely not a content localization solution.

So what to do next?

The only thing the Corp can honestly do is take back that feature.  Roll back to a trunk without content localization features. Implement all other improvements that make DNN 5.5 a great and stable release. Re-think the content localization concept. Take into account the approaches  the DNN-Europe group had contributed. Each of them were better.

 

---

Cheers, Philipp Becker, Peppertree Solutions

You're right with the urls in a way and I wouldn't mind if it were only the language parameters that change. It's also the tabid in the url that changes though. My idea as i had understood the concept from the beginning was that the tabid would never change. Event if there are different tabs for each locale in the backend that would have to be something that the core handles in the background. So if someone hits a tab with id 100 then the core could actually serve the localized tab with the id 101 in the background but that visitor has to stay on the tabid 100 of course.

What if a module expects a certain other module to be on a certain tab? Let's say you've got a teaser on the homepage that shows items from another module on another tab. Eeach of these items would have a link to the tabid that the feeder is on. But now that feeder is spread across two tabs.

What that one example leads to is a very complicated situation that I doubt anyone can overlook completely.

---

Cheers, Philipp Becker, Peppertree Solutions

Must add that the locale selector does not work if the localization feature is enabled either.

DNN 5.5 break every site that have more than 1 language enabled regarding the human friendly url:s