simonech wrote
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
|
This would result in quite an increase of tables in the DB since every object gets its shadow localization table.
simonech wrote
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
|
Not an option. We need to gracefully descend down the locale chain and offer content that way, not having multiple sites. The latter is not really a dynamic localization.
simonech wrote
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.
|
I can't see exactly how you'd do this in DNN. There would be an optional shadow module for every page/module this way. Next to this it doesn't offer me as module programmer a good API to include dynamic localization, I can only refer to a shadow module instance. I'll give an example: I have a doc mgt module that has folders and documents. Now the names of folders would ideally be localizable. Having a shadow copy, however, would mean I would lose the contents of the folder (or I would really need to do some fancy programming). I also need to be able to localize categories for instance. This is disjunct from the main functionality. It becomes quite elaborate to work with shadow copies this way.
Peter