A portal about multilingual websites
and applications development


Implementation - Virtual urls


Review the analysis that we've made about some multilingual websites. Understand and identify the common problems and learn how to solve them.

Subscribe to our Site

Subscribe to our site and be notified when the site gets updated

Virtual urls

  • Print
  • Decrease font
  • Default font size
  • Enlarge font

We saw that in all multilingual website implementation alternatives we can run into untranslated urls. The solution to this problem is the use of virtual friendly urls. This functionality itself is not an alternative because it needs to be used together with a content management system.

A virtual url doesn't point directly to a file in the webserver, but is treated in a special way.  It gives an impression to a site visitor or to a search engine that it is a real url. Here is an example to better understand how it works. Imagine the site previously shown available in three languages. The company section would be made available through the following urls:

English: /company.aspx
French: /compagnie.aspx
German: /unternehmen.aspx

Contrary to what it seems, there are not so many files in the webserver. Perhaps not one of them exists. But, instead of getting the typical 'Page Not Found' message, the site visitor would see the desired content in the language that the file name indicates.

How does this work?

All virtual urls are mapped to the same physical file in the webserver. For example, when the user tries to get access to /company.aspx, internally the webserver maps the request to /real_company_page.aspx?language=en. In the same way, trying to get access to /unternehmen.aspx makes the webserver map the request to /real_company_page.aspx?language=de.

This technique solves the untranslated urls problem. And it adds a huge advantage. We can map all virtual urls to the same physical file, that has the same layout. So, the site can have 30 sections, and be available in 5 languages, and we would only require one physical file. In the first implementation alternative that we saw we would have 150 files, and in the others we would have 30 files.

There are many other particularities about multilingual websites development. For example, let's say that the website allows the user to subscribe and add his/her birthdate and address. We know that very often, different countries have different date and zip/postal code formats. For example, the date 03/25/2008 is a valid date in english, but it's invalid in french. In the same way the American zip code is made up of 5 numbers, the Canadian is made up of 6 alphanumeric symbols. How can we manage this?

We will see in future articles!


Leave a comment:





Enter the code shown above: