ASP.NET 2.0 Internationalization : Web Browser URLs and File System Strategies

One aspect of internationalizing your dynamic websites that is often overlooked is the web browser URL strategy for representing the current language and the file system strategy for managing your content. What URLs do you use if your website needs to be localized to support Canada English and French? And how are they stored on your file system? I hope that I help to shed light on some options that you have.

Some of your browser URL options are as follows:

URL Parameters:
http://mywebapp.com/?l=en-CA/
http://mywebapp.com/?l=fr-CA/

Directories:
http://mywebapp.com/en-CA/
http://mywebapp.com/en-FR/

Sub-domains:
http://en-ca.mywebapp.com/
http://fr-ca.mywebapp.com/

Language Drop Down List Boxes, Cookies, Session State:
http://mywebapp.com/

Choose a URL strategy based on your design needs
Your design should help to guide you to an appropriate browser URL solution. One major consideration should be if you require your pages' content to be indexed and crawled. Following are some strategies available.

Language Drop Down List Boxes
Language drop down lists can impact what is needed in your browser URLs. Since you'll typically indicate to your users what their current selected language is, it can be said that your browser's URL need not have a language element encoded in it since a language drop down list box can serve 2 purposes: to indicate to the user their current selected language, and to be queried server side to determine the UI culture to process an HTTP request with.

I don't recommend doing this though as your only solution for your multi-language website. I do recommend using this in tandem with the language encoded into your browser URL.

Tangent - Language Drop Down Usability Guidelines
A good example of language drop down list boxes can be found at http://www.google.com/analytics/. There is an important usability note worth mentioning, which is that you should always present available languages in the native script of the language. I've seen too many implementations of websites that don't follow this general usability guideline.
A big usability faux pas can be found at http://www.ebay.com/. At the footer of the website you'll find Ebay offered in many other countries. The problem is that they're all displayed in English:


If a user navigates to the Chinese version of the website, they'll see all of the other EBay countries still listed in the page footer, but would you be able to find the US or Canada EBay if you were looking at the footer below?


Also always make sure your language selectors are at the top right of your web pages (or close to) so that your website users don't have to search for this. This has grown into the most widely accepted practice today.

Cookies
My comments are the same as for the language drop down list. Cookies can be useful at times but they should be used in tandem with a browser URL strategy.

Session State
Same thing applies here as for cookies and drop down lists.

URL Parameters
URL Parameters are easy to incorporate - and you get instant re-use of your file system resources such as default.aspx's. The major downside is that you have to ensure that all of your in-site redirects and HTML anchor tags need to encode the language as well.

URL parameters might not optimize your content as well with search engines. It's worth noting this from the Google Webmaster Help Center:

"If you decide to use dynamic pages (i.e., the URL contains a "?" character), be aware that not every search engine spider crawls dynamic pages as well as static pages. It helps to keep the parameters short and the number of them few."

If you plan to have a very dynamic website that uses URL parameters for other purposes, and requires indexing and crawling, then you might want to avoid adding another parameter to each and every page for this reason and instead use another browser URL strategy.

For these reasons, I tend to shy away from this option.

Directories and Sub-Domains
Directories can be more effective from a search engine optimization perspective because there are no dynamic query parameters in your URLs. Directories as compared to sub-domains are useful if you cannot create sub-domains. Directory solutions can be completely decoupled from IIS, but IIS can make some things easier.

Comparing Directories to Sub-Domains
Either solution can be designed to maximize your application's file system resources and be more effective with search engine optimizing. The biggest difference that I've found is in your URL branding needs. If you plan to create a website with a very catchy or memorable top-level domain name, then you might want to pass on sub-domains for languages because then you wind up with these types of URLs:

en-us.mycoolsite.com
fr-ca.mycoolsite.com

The drawback of this is that "mycoolsite" is not the first part of the browser URL. In a lot of cases that won't be a big deal but in others it could be a deal breaker.

It can be easier to partition your websites with the use of sub-domains but that goes beyond the scope of this blog. I'm mainly considering websites that have fairly simplistic translation needs, and don't require deployment of sub-domains across different servers or geographies.

Maximize re-use of files system resources
If you use URL parameters then obviously you will be re-using your file system resources. But if you're encoding your website language as directories or sub-domains then you need to consider how your website's file system will be structured. Your structure should NOT require you to have directories for each language like this:

d:/web/mywebapp/en/default.aspx
d:/web/mywebapp/fr/default.aspx

Rather, your file system strategy should allow all cultures to use the same path. So ideally http://mywebapp.com/fr-CA/ and http://mywebapp.com/en-CA/ both point to the same physical file system resources such as:

d:/web/mywebapp/default.aspx

Fortunately IIS allows you to easily configure this type of strategy with either the directory or sub-domain approach. If you're using the directory approach, you can simply create virtual directories under your web application's root for each language that you want to support. Here's a simple virtual directory example:


This example shows a website with 2 languages that it supports - Canada French and Canada English - and that the languages are configured as virtual directories. The interesting thing to note is that the virtual directories are simply pointing to the web app root.

So if MyCoolWebsite points to:
d:/web/mywebapp/

Then the fr-CA and en-CA virtual directories point to the same directory.

Thus you can then dynamically process the URL to set the UI culture. Typically this is done with an HTTP Module, or possibly an HTTP handler. I'll provide an example of this in the next few weeks.

If you're planning to use sub-domains for your languages, you can leverage IIS host headers to map your languages to the same web app process space:



In this case, I'm specifying different sub-domains for each language as host headers. This is all within the definition of one IIS website. On the server side, the same type of URL parsing can occur.

Both the directory and domain approaches work well with user sessions.

I realize that there are a lot of missing pieces in this, especially the server side technical options to determine, validate and set your UI cultures. But there are already a ton of resources that you find on doing that. I do plan to post a sample component that you can drop into your web applications and start using it based on what I've written about, sometime in the next few weeks.

Happy localizing!