host posted on October 07, 2010 14:03
This following is from dnn forum which summarizes the new dnn multiligual feature:
---------------------------------------------------------------------------------------------------------------------------
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 3rd 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.
by Sebastian Leupold More here
---------------------------------------------------------------------------------------------------------------------------
1. Thanks to Sebastian for outlining some of the detail. One of the most powerful reasons behind going for a page rather than module model was that a model module requires all modules to work in that fashion. Considering the number of modules that are in use but do not have source, or are not being actively developed or who's developers would not ever upgrade them to work in a module localization fashion (i.e. the original module was free or did not have enough sales to justify more work), going a module localization route was dangerous. Ironically it's easier to code, but we choose to take the approach that did not contain that risk, and take on the more challenging code of a page approach.
2. Sacha was asking about the difference from "clone" modules. The changes we made for localization add support to track the translation status of content e.g. if i add some en-us content, add a language (e.g. de-de) and localize the site the existing modules are effectively cloned (using the existing tabmodules support). However some additional values are written so that the relationship with the original content is maintained. This is important, as it allows us to see that the new content (de-de) is not translated. To translate the content the user detaches the module, this means that the 2 instances no longer share the same piece of content, instead it's copied to the new one. The user can the translate it and mark it as translated. Despite the fact that the tabmodules relationship is gone (due to the detach) the values allow us to track the relatioship and translation status. Finally, creating the module instances in this fashion allows us to add additional fuctionality e.g. we create language specific translator roles and apply those permissions as part of the process.
As to the other points, we're currently debating a couple of key pieces, the Language Selector Skin Object Behavior and Human Friendly Urls behaviours, both within the corp and with the internationalization team. Depending on the decision made we may alter the functionality, or even revert back to previous functionality (though the call to revert some back has met with as much reluctance as leaving it in place, so we may enhace areas to support multple use-cases i.e. adding a setting to control. Adding new settings is never ideal, as it complicates things and has more learning involved, but for this area it may be the right/only (delete as approriate :) ) choice)
by Cathal more here
[Read the rest of this article...]