Hello Vincenc, hello all i18n developers,
I've been redirect from this thread on the main forum (http://forums.asp.net/1032550/ShowPost.aspx) while I was searching for a solution on how to make a ML portal with DNN... and I found out that the only possibile way is to use some 3rd party developed modules. But dynamic localization is not built in into the core yet.

I've a long experience in developing ML CMS for portals (the latest I developed is now driving www.goal.com, www.acmilan.com and many other websites in Italy) so this forum is to offer my help in the design of this feature inside the core of DNN.

I'm on holiday at the moment, and I'm accessing this forum from an Internet cafè with 10 people on queue behind me, so I've better be quick (or I'll be dead ): anyway, in my experience I used many appraches for the development of this feature:

1. an object is created absolutely in NO locale, and then it's translated in many languages. DB speaking, there is an "object" table with the obj_id, and then there is an "object_local" table with the couple obj_id, locale_id and the translated attributes
   
2. the object is created in one language, so DB speaking, each object has only one locale, and is like as there are many portals, each with its set of tabs, modules and so on
3. the third is an extension of the 2nd: object are created in one language, but can be linked also to other locales (DB speaking, there is an "object" table with the main object, and then there is an "object_locale" table that links each object to one or more locales): this way if I've a main language on the site, and I don't want to translate all tabs in all locales, I can link, for example, the contacts page in english also to the italian version of the site.

Well, in my experience, the solution n° 3 is the best because:

the 1st forces all version of the portal to have the same structure (and forces the admin or content editor to make a translation for all contents), and this is not always true
the second could have been the best solution, but it forced the content editor to write 2 identical contents for not localized contents (like tables, links) if he wanted them to appear in 2 version of the site
so the 3rd is the best because solves also the little problem arose with the solution 2.

I've seen that the modules from tiendaboliviana.com and from apollo both uses the approach n° 1, becuase the same tab_id has different contents for different locales.

What are u thinking to adopt for the core module?

Hope to help more when I come back home.
Simone

---

Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"

---

Erik van Ballegoij, Former DNN Corp. Employee and DNN Expert

DNN Blog | Twitter: @erikvb | LinkedIn:

Erik,
that's why I think that option 3 is the best.
It's like your way of doing things, but let the content editor (or site admin) decide wheather to display a locale different for current one, or not to show a content at all.

Imagine a JP portal with an english translation... maybe you don't want to translate a local shop page:

• in your module english people will see the page in the menu, will click on it and see a JP page
• with my implementation, it's up to the editor decide if the english guy will see the JP page or not

Of course this way of doing things is much more complex because the objects inside the menu will dipends on the locale (and not just their translation), but I think that, if implemented in the core instead of inside a 3rd party  module, will be easier and will provide a higher value to DNN.

Simone

---

Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"