Let me elaborate on the Magic Content idea.

When editing a page in many languages, we have to save content (wait), load page (wait), change language, load new page (wait) edit content (wait).

An HTML module that inserts itself in each page for which it is turned on would be a great enhancement. The editor loads the HTML modules in one go and then saves modifications across language pages also in one go. That would probably solve the objections of many a ML site. Other modules may start thinking of similar enhancements...

Just an idea, open for suggestions.

---

____________________________________
The one-eyed in the land of the blind.

Let me start with the statement that content localization (CL) is one of the largest and most challenging projects with DNN core framework. It is even more ambitions, given the fact that all the architects and developers of DotNetNuke Corp. are native English speakers. One of their main goals was providing a solution, which is supporting the both, existing ML modules and the large number of single language modules for multilingual (ML) sites, as well as a solution for localization of site, page and module settings. The Internationalization team did provide some requirements and use cases, e.g. there are sites where each language is managed and edited separately (already covered by portals per language, either as individual domains for national subsidiaries, sub domains per country/language or child portals of a shared landing page), other sites, e.g. from many small and medium sized organizations in Europe, provide only parts of their content in foreign languages, while the bigger part of their content is addressing their national audience in their native language. A third use case covers international organizations and companies, which have to provide (nearly) all their content in multiple languages simultaneously. While the first use case is already covered, the page centric approach of DNN 5.5.0 focuses mainly on the second use case, to provide an option using all existing modules in a ML configuration. The third use case requires a “content” centric approach, using mainly multilingual modules providing localization of each text they include, e.g. each individual article in an announcements module.

Let’s review the current solution in respect to these goals:

• Site settings got ML support by using existing base table and a new localization table, holding overloading translated texts and language specific values. This has been introduced in DNN 5.3, and seems to work now with no significant issues.
• Pages get localized by providing single language copies of each page record with an extra key for language affected. All page settings are part of the page record and are now available per language – an advantage for language specific properties, which are available automatically, but a disadvantage for all other settings, which need to be synchronized (which currently seems not to function properly in all cases). Providing a number of uniquely expected settings redundantly in all language bears a risk of inconsistency.
• Modules takes advantage of the existing concept of TabModules, i.e. modules being indirectly assigned to pages, which can be used for single language modules as well as ML modules, which now need an assigning record per language. The fact, that module title and other language specific properties have been moved from Modules to TabModules table provides full support of property localization.
• Master language for all pages is taken from site settings and cannot be altered (neither for the site nor individual pages/branches of the site). IMHO this is a limiting fact, which needs to be reconsidered.
• The implementation of page localization assigns a TabID per localized version, what makes each version easier to identify, but much more difficult to identify translated pages and switch between pages. The database does not reflect the hierarchy between master page and translated versions, i.e. integrity needs to be maintained in the BCL which bears some risks, e.g. if 3^rd party solution access the data layer directly. I would have preferred using an approach like in site settings with a master page ID exposed and localized properties being overloaded, while an additional language key in TabModules filters the modules to display per page.
• Synchronization of modules and tab settings has been implemented using a dedicated workflow, for authors and translators, which would be more appropriate for the third use case described before. It is requiring each page to be set up in master language first and requiring extra steps for translation support. This contrasts with the freedom of handling, used in other areas of DNN and needs to be redesigned. There are translation statistics, which are of limited use for the current approach and should be removed.
• Any solution will need to deal with content language and UI language, which has not been distinguished in DNN before. As an example take an admin in the US, maintaining a site in English and Chinese (without speaking Chinese himself). When he gets Chinese texts from the translation agency for adding it to the site, he still needs to be able to read field and button captions. According to my ideas, the language selector Skin object should control UI and content language simultaneously for anonymous users and in view mode, while in editing mode the UI language sticks to the preferred language in his profile  - and eventually an additional language selector in the control panel might allow him to switch UI language as well, when needed (also required for authors of language pack to validate their translations).

As a conclusion, I consider CL in DNN 5.5 as a big step into the right direction, but a lot of work needs to be done – and eventually some basic decisions being reconsidered.

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

 I would still suggest that for registered users an option is included to have UI language follow content language (checkbox?) and that this option is set by default. For newly registered users it may be confusing to see two languages on the same page and the profile is often filled out some time after registration. Editors, translators etc. will know how to set the profile settings for their needs.

---

____________________________________
The one-eyed in the land of the blind.