Best way for multi-language sites virtual Directories

Question

I have a site that will ultimately support 4 languages and 2 countries (US & Canada, English and Spanish)

I'm wondering what's the best way to set up the directory structure?

Right now, I have a root site called site.com:

This will take you to a page where you choose your country and language.

Ideally, I want to have the directory like so:

site.com/ca/en/ (Canada English)
site.com/ca/fr/ (Canada French)
site.com/us/en/ (US English)
site.com/us/es/ (US Spanish)

But that will mean I will be putting a "ca" and a "us" virtual directory and language virtual directories inside that. IS that good practice, or should I do something like:

site.com/ca-en/ (Canada English)
site.com/ca-fr/ (Canada French)
site.com/us-en/ (US English)
site.com/us-es/ (US Spanish)

edit: I have done the following:

There is a dummy directory: /ca/ and /us/ in the application. They both have a default.aspx which is just a redirect. In my case, I redirect them to their English language sites:

For example: site.com/ca/ --> site.com/ca/en/ site.com/us/ --> site.com/us/en/

if site.com is entered, you are pushed to a language selection page. Basically, I use a regular expression in Global.asax on every request to look for the language/culture string.

This has the following benefits. Country separation. So you have control over site.com/ca/ or site.com/us/ and are able to provide a simple URL for each country.

Anyway, the Virtual directories /en/, /fr/ and /es/ are inside their respective country physical folders.

So you have the following (Virtual Dirs are in bold):

site.com/ca/en/ (default) site.com/ca/fr/ site.com/us/en/ (default) site.com/us/es/

What this means is that you need to have five (identical) applications, except you can use the URL to get the current language and country (and point it to the right database).

Answer 1

Why not having one site and check the client setting (request.servervariables / HTTP_ACCEPT_LANGUAGE) for what preferred language to use and using the built in globalization in asp.Net?

If totally different content will be shown depending on country/language then I can understand why separate them like that.

Answer 2

Well, they want the Url to be different for each site.

Essentially it is actually one site (for maintenance reasons) and we're using globalization to determine which connection string to use (different databases, identical structures in each one)

Each time we publish I'll publish to four locations. Identical app.

Globalization using one URL SOUNDS like a good idea, but I don't think it will spider properly, and even if it does, doesn't offer a good bookmarkable link. (French person sends link to another french person using an computer set to English). There are other implications, but there is a reason sites like apple and microsoft use different urls for each language/culture.

On each Session start, I check the url, and set the connection strings accordingly.

IN THE END, i just put a /ca/ and /us/ directory in the main application, add some virtual directories to each language do a reponse redirect to the "choose a language" page.

Perhaps not the best solution, but it seems to be working.

Another benefit of doing it this way is if there is some special page that only applies to one site, it can be added to that site only.

Answer 3

generally accepted nomenclature for localization is ll-CC for language code hyphen country-code. example: en-US, though en-US would probably be the default with en-GB or en-CA as fallbacks... es-MX etc are also worthy. It may be better to use subdomains though, which would allow for the breakup of resources without complex load balancing rules in front. ex: us.en.yoursite.com ... this also allows for an easier breakdown of servers in a webfarm environment. I would suggest having the actual code the same with a settings change per site to match the localization. Then use a localization resource that you pass in a textual key, and the language translation is resolved based on the site's localization pattern. Note: .Net, and other platforms offer resource localization options built in.