|
|
Jun
28
Posted by:
Joe Brinkman
6/28/2010 5:29 PM
 Ever since the localization framework was first introduced in DotNetNuke 3.0, it has always been our intention to go back and complete the localization story for DotNetNuke. When localization was first introduced in DotNetNuke, we only tackled the localization of static strings. This support for the localization of static strings was sufficient to address the needs of many international users, however it was not adequate for addressing multi-lingual sites.
We realized from the beginning that content localization was a tough issue to address, and one which could be solved in numerous ways. Every time we looked at tackling content localization, the effort always seemed to be a bigger than we had the resources to be able to tackle. We wanted to make sure that whatever solution we put in place would meet the needs for a large portion of our community.
After many meetings with members of our Internationalization team, international community members and customers, and after many months of development, we are finally ready to release a DotNetNuke version which supports content localization. I will leave it to others on our development team to go into the details of the implementation as we approach the final release of 5.5. You can see an earlier version of code in the two videos that Scott previously posted.
Today, I am pleased to announce that an Alpha version of DotNetNuke 5.5 is available for download. We are still in the middle of addressing some outstanding bugs from previous releases along with any bugs we are finding in the new 5.5 specific code. We anticipate being able to release a beta version next week, but need your help in identifying any major outstanding issues with the current alpha release.
Because this is an Alpha release, we will not be supporting a seamless upgrade to the final 5.5 release. This code should not be deployed in a production environment since we haven’t completed performance testing and tuning and we know that significant bugs still exist in this version of the code.
You can download the code from the Beta Release page on DotNetNuke.com. Please post any questions or comments on the release to the Open Core Testing forum.
16 comment(s) so far...
Re: DotNetNuke 5.5 with Content Localization
Glad to hear this area is getting some TLC Joe - does this update include a way of showing the localised strings - ie. a MLHTML module, or do we still have to use one of the 3rd party ones?
By Rodney Joyce on
6/29/2010 8:22 AM
|
Re: DotNetNuke 5.5 with Content Localization
@Rodney - I am not sure what you mean by localized strings. In the current content localization implementation, you continue to use existing modules and have localized versions of whole pages. Each page is associated with a specific language and when that language is selected, then the pages for that language are displayed. This allows you to account for differences in layout necessitated by differences between LTR and RTL languages. This also means that all of your existing modules will continue to work and the module does not need to be ML aware. This also satisfies the scenario where a particular language may have additional pages.
By Joe Brinkman on
6/29/2010 8:28 AM
|
Re: DotNetNuke 5.5 with Content Localization
@Carlos - Feel free to make corrections to the translation at translate.google.com/?hl=en#en|es|hello%0A ;)
By Joe Brinkman on
6/29/2010 2:34 PM
|
Re: DotNetNuke 5.5 with Content Localization
Joe:
Not to be overly picky, but for the sake of correctness, just wanted to let you know that the punctuation marks for “Hola” in Spanish is incorrect in the logo pic with all the languages. If you want to use exclamation marks it should be ¡Hola!
Espero no meterme en muchos problemas por esta corrección.
Sinceramente,
Carlos
By Carlos Rodriguez on
6/29/2010 2:27 PM
|
Re: DotNetNuke 5.5 with Content Localization
How does translation work? I'm a complete newbie on Localization. Do I need to have the content manually translated for every language I support, or is there some built-in module that handles the translation?
If I handle it manually, then I guess this means that all the content for all languages needs to be translated and entered into the system, prior to publishing live. Is this how it generally works in the real world?
Then too, if this is how it works, then I cannot build a CMS application for a client where they can expect to enter in English language content and then publish it, without also entering in ALL the other content in their languages. Is this also correct?
Thanks.
By King Wilder on
6/29/2010 2:27 PM
|
Re: DotNetNuke 5.5 with Content Localization
Hmm - I was unaware it worked like this (I have not downloaded the Alpha) - I assumed it worked like Apollo - modules show different content based on the UI Culture - so you just have one page and one module and it is capable of generating the localised content depending on the culture.
I would have thought that the multiple page approach would be tricky to manage with large sites and modules that use dynamic pages based on querystring params (e.g. a UserGroup that takes in a GroupID) - do you have to have a page and module instance for each language now? I have over 100 pages on PokerDIY.com and don't want to have to make 100 more for each language?
I'll need to look at it in more detail before I comment further - I need to understand the solution before I waste more of your time ;)
By Rodney Joyce on
6/29/2010 2:28 PM
|
Re: DotNetNuke 5.5 with Content Localization
@King - Translation is required for each individual page. Automated translation is a very poor substitute for manual translation. If you have any doubts about this us Google Chrome to navigate to any web page in a foreign language and let it automatically translate the page for you. What you will see borders on unintelligible gibberish. Since DotNetNuke has a robust permission structure, it is possible to have a set of pages that are only visible to the page editors and translators. Once those pages are fully translated, then change the permissions to show the pages to the public.
By Joe Brinkman on
6/29/2010 2:34 PM
|
Re: DotNetNuke 5.5 with Content Localization
@Rodney - The downside to the module based approach is that it requires all of the module developers to support the new feature. We have learned from past experience that it take a long time for a new feature to be implemented in any significant number of modules. Module developers target their products using a lowest common denominator approach to try and serve the broadest customer market. If we implemented this using an approach similar to that used by Apollo modules, then we would be limiting the usefullness of the feature for many months. The approach we implemented allows everyone to take full advantage of content-localization on the day 5.5 is launched.
By Joe Brinkman on
6/29/2010 2:38 PM
|
Re: DotNetNuke 5.5 with Content Localization
@Rodney - Existing large sites will have issues no matter which method of localization is used. One use case that is not covered by the module approach is that with a page based approach it is possible to limit language translators edit permissions just to the pages for their language. When you are only creating a bi-lingual site, this might not seem to be a big deal. When you have a site that supports half a dozen languages, it becomes more important.
The problem with the module method as I previously mentioned is that it doesn't scale in terms of actual implementation. What is the point of having a robust platform with 1000s of extensions if only a dozen or so support content localization?
Finally, if you prefer the approach taken by Appollo and other modules, then you are free to continue using them and keep DotNetNuke operating as it currently does.
By Joe Brinkman on
6/30/2010 6:16 AM
|
Re: DotNetNuke 5.5 with Content Localization
@James - There is no magic bullet for content localization. It is a lot of work. I recommend you look at the videos on the subject that I link to in my blog. They will do more to show you the basic process than what I can describe in comments.
By Joe Brinkman on
7/1/2010 6:39 AM
|
Re: DotNetNuke 5.5 with Content Localization
@Jeff - The whole point of this approach is that module developers don't have to "support" it. Every module that currently exists already supports it. They don't have to do anything special.
By Joe Brinkman on
7/2/2010 10:16 AM
|
Re: DotNetNuke 5.5 with Content Localization
Ok - I'll have a look at it - thanks. I have always thought that this approach favors small (and new sites) - existing, large sites will have a lot of work ahead of them top copy all content/pages. I guess we have to go with the majority and the easiest to use... (although maintenance becomes a nightmare - if you have 10 languages and change one language string you have to physically update each HTML module on each language page version (ie. content and localisation is blurred), whereas with the module method you just update the language strings and all 10 languages automatically update with no work).
Just to play devil's advocate - I assume you have considered the performance impact of having Number of Languages * Tabs more content on your portal.
Also - I assume there is nothing stopping us using it the other way - i.e. one set of pages with language-aware modules? I would really like to read more about the design/architecture of this solution - are there any documents available please? (I checked the forums but there are no discussions on it?)
By Rodney Joyce on
6/30/2010 6:08 AM
|
Re: DotNetNuke 5.5 with Content Localization
First, a big WOW! for this finally coming back around. It's been a long time coming. This will save a lot of time and headaches in multi-lingual sites. Although I see issues with this until module developers ramp up to support it fully, thanks for providing the framework.
By Jeff Cochran on
7/2/2010 10:15 AM
|
Re: DotNetNuke 5.5 with Content Localization
Thanks for all the hard work! The screenshot above looks slightly similar to the translation tool we use for our software product.
Unfortunately, the described implementation is a little hard for me to grasp. Can you provide a little more information on the work flow for creating a new page or to edit a page?
For example, would it require that I leave the English page, switch to the German site, locate or create the German page, then add/edit the German module? Or are there shortcuts adding or editing the German version of the page after you have created/added the English version? Would DNN provide a list of German pages that have yet to be translated/updated?
Like Rodney, I also use currently use Apollo modules along with dslocalizator, which is great but rather cumbersome. However, a solution with a more simplified workflow and less performance impact might make it worth copying over all our content pages.
By James LaBranche on
7/1/2010 6:36 AM
|
Re: DotNetNuke 5.5 with Content Localization
@StephenW - You can check the Roadmap at support.dotnetnuke.com/project/Project.aspx?Tab=Roadmap&PROJID=2 to see if that issue is included. Just looking at your description though have you considered you might be editing the wrong resource file?
By Joe Brinkman on
7/13/2010 10:29 AM
|
Re: DotNetNuke 5.5 with Content Localization
Im on 5.2 I've added fields to the registration page and have edited Profile.ascx.portal-0.resx
Profile.ascx.host.resx
but from what I can see the resx files are never used. Is this now fixed in 5.4 or 5.5 ?
By StephenW on
7/13/2010 10:03 AM
|
|
|