Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Content Localization Walkthrough

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 
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:[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 instead of Or use a fully qualified domain name: or
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: 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 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.


2sic Daniel Mettler
Thanks Erik! finally a new guideline for the new guys. Great post!
2sic Daniel Mettler Tuesday, August 26, 2014 12:05 PM (link)
Franco Prati
Thanks Erik, very good description of the steps involved. We have all done it "by discovery", i.e., with trial and error and this is the first time I see it outlined in a comprehensive document.
If I may add, one should remember to delete the first html module added on the content pane by the default page creation, and for all languages 'cause that's not 'copiable', either direction.

By the way, I think the community agrees that the native localization, although powerful and improved over the years, is quite heavy to manage and may not apply to all cases. For the simpler case, though, what we need is a lean solution, such as your former Apollo PL (and associated modules/objects). A few initiatives are still alive, such as Sacha's, and it'd be nice if they could be better supported. What's your opinion on that?

Franco Prati Wednesday, August 27, 2014 9:02 AM (link)
Sebastian Leupold
It is nice to know, that DNN content localization is finally working without major issues, but it is still way too complex to handle for most of the sites - it would be nice to get a simple alternative like Apollo PageLocalization and ModuleLocalization, but with the option to use monolingual modules as well and just hide per language.
Sebastian Leupold Wednesday, August 27, 2014 10:40 AM (link)
Erik van Ballegoij
@Franco: I think the issue with the default HTML module on pages has been resolved. If not, please create a JIRA ticket for that.

@Sebastian: Hiding a module based on language (or other properties) would be a nice addition I think. Not too difficult to create.

I see options to create a tighter integration between PageLocalization and DNN.. so who knows what the future brings in that respect. I am not sure it will be useful to have multiple localization features available inside the product... that will not help make things easier
Erik van Ballegoij Wednesday, August 27, 2014 10:53 AM (link)
Sebastian Leupold
Erik, maybe you are right and DNN is not the proper platform for my ideas.
Sebastian Leupold Wednesday, August 27, 2014 5:28 PM (link)
Mike Ryckman
Hi Erik. Thanks for this... As a quick question, is there a way I can change just a specific page from Neutral to some language? I don't seem to be able to do it, and so if I localize a neutral page, then DNN makes two new copies for each language. It'd be nice if I could take a neutral page, change it to english (in my case), and then localize it to create versions in other languages.
Mike Ryckman Thursday, March 19, 2015 1:55 PM (link)
M Bouwman
The solutions looks ok, it works, but in the ideal situation I would like more freedom.
So for example I would like to make a contact page in english and in dutch, which are linked to each other.
Right now, I have to either do something like: and

or and

However ideally I would like something like: and

So then I will not have to worry about multiple domains or subdomains, or an extra parameter in my url that my customers are not happy with.

So I think the solutions is ok, but it can be improved....
M Bouwman Thursday, October 06, 2016 4:26 AM (link)

Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?