Since DotNetNuke 5.5 was released, and the Url Master module version 2.0 was released, I’ve received an increasing number of questions with regards to setting up sites to take advantage of Friendly Urls. While DotNetNuke 5.5 allows you to create a true multi-language site, it does so at the cost of Friendly Urls, as the introduction of the /language/xx-XX path in the Url causes the core Friendly Url Provider to start putting the /tabid/yy back into the Url.
Assuming you only have one domain name registered for your site, and you want to run both Multi-Language and Human Friendly Urls, how do you do it? That’s what this post is going to cover.
Standard DotNetNuke Multi-Language Urls
If you switch on Multi-Language features for a DotNetNuke 5.5 site, you’ll get Urls that look like this (note, all Urls for the ‘Blog’ page in a site):
| Url | Language |
| example.com/Blog.aspx | en-US (default) |
| example.com/Blog/tabid/61/language/en-US/Default.aspx | en-US |
| example.com/BlognlNL/tabid/62/language/nl-NL/Default.aspx | nl-NL |
| example.com/BlogfrFR/tabid/63/language/fr-FR/Default.aspx | fr-FR |
These are the default Urls generated for that page. The BlognlNL / BlogfrFR can be renamed back to ‘Blog’, or to a localised version.
The problems with these are several :
- They’re not ‘Human Friendly’
- Duplicate content is possible
- It’s difficult for search engines to detect which language the pages actually are.
On the last point, Google’s webmaster help has several important pointers for helping search engines differentiate between different languages. Some of the points mentioned are:
“Google uses only the visible content of your page to determine its language. We don’t use any code-level language information such as lang attributes. You can help Google determine the language correctly by using a single language for content and navigation on each page, and by avoiding side-by-side translations.”
and
“Google uses the content of the page to determine its language, but the URL itself provides human users with useful clues about the page’s content. For example, the following .ca URLs use fr as a subdomain or subdirectory to clearly indicate French content:
http://example.ca/fr/vélo-de-montagne.html http://fr.example.ca/vélo-de-montagne.html “
Basically what this says is that it’s a good idea to 1) separate out your language clearly in the Url, and 2) having the language parameter in the Url makes no difference for SEO, and doesn’t help readability for the user.
Simplifying One-Domain Multi-Language Urls with Url Master
To improve the Urls shown above, what we really want is an understandable, Human-Friendly version that works the same way. The Url Master module has built-in functionality to handle this and produce friendly urls as a result. I’ll show you in the example below how to get the above Urls to turn into these Urls:
| Existing Url |
New Url |
Language |
| example.com/Blog/tabid/61/language/en-US/Default.aspx |
example.com/Blog.aspx |
en-US |
| example.com/BlognlNL/tabid/62/language/nl-NL/Default.aspx |
example.com/nl/Blog.aspx |
nl-NL |
| example.com/BlogfrFR/tabid/63/language/fr-FR/Default.aspx |
example.com/fr/Blog.aspx |
fr-FR |
In this case I’m going to assume that you want to keep the Url ‘Blog’ in all languages – I’m happy to be corrected by Dutch/French speakers!
Procedure to create Friendly Urls
Pre-requisite : DotNetNuke 5.5 (or later) Installation with two or more languages installed and configured, and localized versions of existing pages created.
Step 1 : Install Url Master version 2.2 (or later)
If you haven’t already installed the module, download the install package from the Url Master Product page.
Step 2 : Create subfolders in your website root
In a nutshell, we’re going to get the portal we’re working on to pretend it has a portal alias like a child portal. We’re not turning it into a child portal, just making the behaviour for the alias similar.
If you are unfamiliar with the term ‘portal alias’ – it’s simply the unique part of the Url that DotNetNuke recognises your site with. In most cases, it’s the same as the domain name (example.com). In the case of child portals, it’s the domain name + the child portal name (example.com/childportal).
To create the subfolders, just go to where your website is hosted, and create a new folder in the root path. You might do this by logging onto the server, or you might do it via FTP. In our example, we’re going to create two new folders, one called ‘nl’ and one called ‘fr’.
The above image shows the two subfolders created in the root directory of the DotNetNuke installation. As noted, you can do this directly on the server, or via FTP. If you’re unsure, whoever looks after your hosting should be able to do this for you.
Step 3 : Upload a dummy default.aspx file.
The next part of the process is to load a ‘default.aspx’ file into the /fr and /nl folders. This is so that the home page of each of the languages can work as expected : example.com/nl and example.com/fr will be the home pages for each language respectively. This works because any request for a subfolder in a website will append the ‘default document’ as specified in your IIS configuration. Because DotNetNuke uses ‘default.aspx’ as the default document, we’re just using this convenient fact to work with our language-specific subfolders.
You can create an empty default.aspx file yourself, or you can download (and unzip) one from here : Dummy Default.aspx File
The dummy default.aspx file doesn’t do anything, it just allows ASP.NET to recognise the /nl and /fr folders as a valid path to process.
To use the linked download, just extract the default.aspx file from the dummy-default.zip package, and upload one copy of the default.aspx file per language subfolder. This should be the only file in each language subfolder.
Step 4 : Create the portal alias entries
Now we’re going to create a portal alias for each separate language we want to use. To do this, go to the Admin->Site Settings page, and scroll down until you’re at the ‘Advanced Settings’ section. Expand this, and scroll down again until you’re at the ‘Portal Aliases’ section. Expand that section to see a list of the existing portal alias entries for your portal.
Click on ‘Add New Alias’ and add a new entry for both example.com/nl and example.com/fr. You should already have an entry for example.com, which is going to be used for the default language.
Step 5 : Associate the portal alias entries with specific languages
Now, go to the Admin->Portal Urls page created by the Url Master module. Click on the ‘Portal Settings’ tab, and find the section called ‘Portal Alias (domain name) selection type’. Choose ‘The selected portal alias values will be used for the specified language/culture’, and then check each of the aliases you wish to use, and select the language/culture to associate with that alias:
The above example shows how the finished result should look. Click on ‘Apply Changes’ once this is complete. Note that if you haven’t activated the Url Master module yet, follow the ‘Friendly Url Settings’ link to go to the Host->Friendly Url Settings page, and click on ‘Apply Changes’ there.
Step 6 : Rename the DotNetNuke Pages
The BlognlNL and BlogfrFR are names automatically created by the localization software in DotNetNuke. You don’t have to (and shouldn’t) use these auto-generated defaults. You’ve got the choice of either renaming to a localized translated name of the page (but stay away from non-standard characters outside of the basic ASCII set) or, as I’ve shown in this example, just use the same name for all versions of the page, or any combination of both. By changing the page name, you’ll change the Url generated by the Url Master module.
If you want to use a page Url that is different to the page name (and by all means, do so to optimize for specific search terms) then you can create a customised page Url per-language in the Admin->Portal Urls page.
Step 7 : Test and Enjoy!
That’s all there is to it. Once this has been setup, the correct portal alias will be used with the correct language/culture for each page. This means that the French pages will all have the example.com/fr entry, and each language will repeat this behaviour. The default language (in this case, en-US) will show no language path so as to avoid creating duplicate content in the search engine listings.
Special Note for those with ‘wildcard’ extensions
If you’re using ‘wildcard extensions’ or have switched off the extensions in the Url Master settings (so your site Urls would be example.com/blog instead of example.com/blog.aspx) then you don’t have to do steps 2 & 3, which are creating dummy folders and default.aspx files. This is because, when routing all requests through the ASP.NET runtime, the Url Master module gets to inspect all Urls to decide if it needs to do some rewriting with them. When running with a regular, .aspx configured site, ASP.NET (and hence DotNetNuke, and hence Url Master) only gets to process those Urls which end in .aspx. That’s why you need to create the dummy folders and dummy default.aspx when you’re using .aspx extensions.
Redirecting Old Urls
An important part of any Url modification work is making sure that any existing Urls either indexed by search engines or bookmarked by customers are correctly redirect to either the new Url, or at the very least a close-enough version of one. In the case of the ML Urls, the Url Master module should successfully redirect to the new version, because the old Urls contain the ‘tabid/xx’ path in them, and this is enough to identify the tab and lookup the correct, friendly Url and redirect if necessary. Just check through some of your indexed/common Urls and make sure they are all redirecting OK. If any aren’t you have the option of creating custom redirects in the Url Master module to handle these.
Share your Success
If you’ve tried this out and succeeded, please let me know via the comments. Or just let me know if something hasn’t worked or isn’t right somehow. I don’t yet have a reference site with this type of ML setup, so let me know if you have an example and I’ll link your site as a reference.