While working on the implementation of a CMS-based web site, I had to deal with a problem that obstructed the expected navigation flow. To make sure the site was search-engine-friendly, aliased URLs capability was enabled in the content management application. The site also needed to be localized in at least 6 languages. The combination of these two features didn’t go quite as expected to say the least.

Here’s a detailed description of the problem:

For all content entries of the type Product, we use a product.aspx page that is in charge of rendering all of them by sending the product, and language, ids as query string parameters,it looked like this: product.aspx?id=[productid]&LangType=[languageid] . Aliasing allowed content managers to assign a unique URL for each product in each language, this way search engines would make a distinction between them. Aliases used the following syntax, /[lang-prefix]/[product-alias].aspx, which produced something like this:

So, one would say no problem, we are not shooting for the stars here, right?

Right, we weren’t shooting for the stars, however we did bumped into a problem: CMS system had an unexpected limitation; aliases would not be recognized unless user had selected the right language first.

Say you were in /us/home.aspx, if you typed /fr/home.aspx in the browser and hit enter you would get a 404 File Not Found error. Apparently, the aliasing engine didn’t look in all alias records; it only searched within default and current language selection’s sub-sets. There were many scenarios where this was a problem:

This was a major issue and put the very launch of the site at risk. We needed a solution, and we needed it fast. Writing our own aliasing engine was out of the question, there wasn’t any budget to build such functionality, nor was there any time left to do it. Solution would have to be as least intrusive as possible and had to be built in a day or two at most.