1.    One of the reasons we initially chose DNN is because it aims for modularity. Adding a separate welcome page for Dutch and another one for French just to translate “hallo” to “bonjour” doesn’t seem very modular. Whenever non-content related work (e.g.: page order) has to be done to this page it has to be done x times the number of languages used. The solution to add pages for each language doesn’t seem thought through. We can see a few limited examples where it could be useful, but nothing that couldn’t be handled in an equal amount of time “the old way”.

1.1  The one-time automatic copy of all pages when the localization function is enabled doesn’t seem very useful and could prove extremely unwanted, as there is no way you control when you want it to happen.

2.    We have built websites who are very complex structures with shopping carts, product lists, entry forms with each having pages of configuration to set up. This has to be the same for every language. As we understand we would have to rebuild this for every language? This requires nearly impossible administration.

3.    If we chose not to use the new localization button, and ignore the functionality, a few other problems arise:

·          Firstly, we want to follow whatever road DNN takes, even it means extra work transitioning

·          If this choice is made by DNN then eventually it will be the only choice, which is logical but scary for us

·          Our customers are all administrators (because they need to be able to add root-pages to their portal), which means they will have a “break this website” button. Since “enable localized content” can only be done once, and there is no turning back or fixing. Again, very, very scary for us.

4.    There isn’t any solution offered to all the modules that already deal with content localization, I’m sure the developers there are confused and not sure what road they should take.



Thank you for taking the time to read this.
Dieter Vieren
duotix Belgium

Hello Cathal,

thank you for your answer. We're looking forward to the changes in 5.6, as always.

1 and 2. We agree the page-approach makes it easier for module builders. Still, for a medium size multilangual website, it is much more powerful to have a multilanguage module. We're glad to hear both techniques are going to exist next to eachother, so we can continue to use multilanguage modules. Like we said, some of our webshops and other more complex websites would be unmanagable without multilanguage modules.

1.1 We're glad you also agree and this is also taken under consideration. It would indeed be nice to select this page-approach for a selected number of pages, and we also need to be able to undo things.

3. We're running 50+ multilangual websites, so we know what we're talking about :) We see this page approach would fit a number of *pages* in a small number of our websites, for all other websites we need to stick to the multilanguage module approach. Those *pages* would contain 'great-but-not-yet-multilangual-modules', so we'd be able to translate those pages also. It's also very complex to teach our customers (who manage the content of there website) the difference between these two approaches.

4. About the percentage counter: That sounds like an interesting idea, we hope all multilangual module builders will understand they need to continue the same way and just show the "translated 100% or x %". This seems like a detail though, I don't think we'd look at these percentages, we look at our websites to see what's translated and what's not.

We didn't think this was "code thrown over the wall" :), but we were wondering what part we were missing. The key thing you have answered for us is:

 - the two technologies will continue to exist together
 - the page-approach will be a lot more manageble (and undoable) in the future

As a side note, wouldn't it be interesting to have a core "store-my-data-multilingual" interface for module builders? Like an interface/function that would make it easy for them to store their data in x languages in the DNN database?

Thank you very much for your time and effort to answer our questions and keep up the good work,
Dieter Vieren
duotix Belgium