In a world that gets smaller every day, it becomes more important every day to be able to serve the content of your website in a language that people actually understand. If you look at the demographics of the US, a little more than 20% of the people speak another language than English at home. That is a little more than 60 million people. About 40% of those are not speaking English “very well” (see
http://1.usa.gov/1qsOtVl).
The DNN Platform can help: there are a number of features that make it easy to create a multilingual site. Localization is very complex though, so, let’s go over a few tips and tricks!
Choose your localization wisely
Localization in DNN can be done in two different ways. Which way to choose depends on the content of your site, and how you want to localize this content for different languages and countries. The simplest way to start offering your site in multiple languages is to add a portal per language. This will create a completely separate environment for the new language, which is great if content is not really related, and you have independent editors taking care of the content for the site.
In a lot of cases, this approach will not work very well. Quite often, content in the different languages needs to be in sync. For this situation, DNN has a built-in feature called “Content Localization”. This feature allows a site owner to duplicate a site for each desired language, give translators access to the language content they need, and permit a seamless switch between the different languages.
Turn it on: tread carefully!
The DNN Content Localization feature is definitely one of the most complex features of the platform. That’s why we made it a little hard to turn the feature on. We hid the setting in Host Settings > Other Settings:
Once this setting is enabled, the feature is available in the Admin > Languages page:
It is important to note that once you enable Content Localization, the default site language can no longer be changed. So before going ahead, make sure you’ve selected the correct default language. You can do this on the “Settings” tab.
Depending on how many languages you enable before clicking the “Enable Localized Content” button, DNN will either just prepare the pages in the default language or also create localized versions of pages for the enabled languages. When you click “Enable Localized Content”, the following popup will appear:
Normally, you will want to check the “Make all pages translatable” checkbox. This will make all existing pages culture specific (i.e. available in only one language). If you leave the option unchecked, all pages will be language neutral. Pages that are language neutral will be displayed in all languages.
After clicking the “Enable Localized Content” button in this popup screen, it is off to the races as DNN will traverse all pages, create a copy of each page for all the enabled languages, and create copies of all modules on each page to all the newly created copies of that page. As you can imagine, this can be a long running process depending on the number of pages, modules, and enabled languages. Making a database backup before starting this progress is a smart idea!
Working on translations
The idea behind how content localization works in DNN is that there is some sort of workflow when translating your site. Although there is no automated workflow, there are some steps that need to be taken in a specific order to make everything work:
1. Create translatable page(s)
2. For each language, go to each translatable page, and translate contents
3. In Content Localization settings, mark individual pages as translated
4. In Languages, activate a language
5. In Languages, publish a language
Let’s go over that in more detail.
After a page is translated, a translator can go to the Localization tab in the Page Settings for that page and mark the page translated.
As long as a language is not activated and not published, only administrators and translators can see pages in that language. This makes it very easy to work on a translation on a live site. Once you are ready to put the translation into production, make sure the language is activated. After that, click on the Publish Pages button for that language on the Languages page. Doing this will give all pages that are marked as translated the same permissions as the default language version of those pages, which means that anyone who could see those pages in the original language will now also see them in the translated version.
Manage your URLs
When working with multilingual sites, URLs are very important. The way DNN handles these is a bit tricky. When we added Advanced URL Management to DNN in v7.1, we also needed a new way to handle multilingual URLs. It turned out that the easiest way to implement that was to work with language specific site aliases. Simply put, this means that the URL rewriter will first try to get a language, and then will try to get a site alias that is tied to that language. If a match is found, a redirect is performed to that portal alias. The other way around also works; when browsing to a language specific site alias, DNN will set the proper language based on the alias.
When multiple languages are defined, the site alias list in Site Settings should look similar to this:
The way this works is that whenever you enable a new language in the Languages page, DNN will also automatically create a site alias for that language. It will do that in this format: domain.com/[culture code]. When you remove a language specific alias, but keep the language active, DNN will no longer be able to serve pages properly for that language.
One benefit of this approach is that it is very easy to change the site aliases to something that better fits your site. You could use domain.com/nederlands instead of domain.com/nl-Nl. Or use a fully qualified domain name: nl.domain.com or domain.nl.
The latter two are preferable because they solve a rather annoying issue when you work with translated text. Let’s say you have a site that has “translations” for en-US, en-CA and en-GB. The reason to have 3 versions of English could be that some of your pages should only be available in one country, but most pages would be available in most countries. In this case, you could choose to create neutral pages that would show up in each language, and language specific pages for the few pages that need to be different.
The issue then arises that if you put internal links to other pages on any of the neutral pages, these links will normally include the language parameter. For instance, if you edited text while en-US was selected, a link would look like this: www.domain.com/en-us/some-page. Since the page is neutral, the contents will show up in all languages, and in all languages that link will be the same. This means that if you switch to Canadian, the link will still be www.domain.com/en-us/some-page and if you click that link, the site will be switched back to American English because of the en-us parameter in the URL.
The solution is very simple: use site aliases that are fully qualified domain names, and then use relative URLs as internal links. The link /some-page will then automatically point to the correct language no matter which language is selected.
The way language specific site aliases work is a break from DNN versions prior to 7.1. Since DNN does not automatically upgrade from human friendly URLs to advanced URLs, it is also not able to automatically add language specific aliases. That means that after an upgrade from a pre-DNN 7.1 version, and a switch to advanced URLs, you will also need to add the language specific URLs.
Powerful, yet complex
The DNN Content Localization feature is a very useful though tricky feature to use. When pages and modules are copied to a new language, the IPortable implementation of modules is used to also copy content from the default language to the new one. This means that all modules used should implement this feature correctly in order for it to work as expected.
This complexity also means that as an admin you need to plan ahead. Create a backup of your site before you begin and select the correct default language. Most of the localization processes are reversible, so if you make a mistake or errors occur, you can backtrack to a previous state.
Finally, I am interested in your experiences. Feel free to add a comment and link to your site.