Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

It's a Canadian Thing

February 22, 2005

A funny standard has shown up on larger Canadian retail sites that doesn’t appear in other sectors.

Question: the site you’re building requires support for multiple languages. Each needs equal prominence. How do you handle this?

Due to the bilingual nature of the marketplace in my home and native land, an interesting standard has emerged amongst larger e-commerce sites in Canada. Splash pages are making a comeback, or more accurately, they never really died. What’s common on the sites of large retail stores is a mostly useless intro page that forces you to choose your language. Observe:

These are all retail outlets. If you take a look at other industries which must abide by the same language laws, you see something remarkably different:

There are exceptions; HBC is a retail chain that merely includes a ‘français’ link in the top corner. And it may be that the latter sites are serving up customized content based on IP address, though I’ll never be able to test that from here.

Still, it’s interesting to observe the single-mindedness in approaching this problem. In previously working with retailers that have chosen the splash page approach, I’ve come to learn that the choice is driven by politics. If you provide an English page with a link to the French equivalent, or vice-versa, you risk alienating a potentially large percentage of your customer base. So by presenting both on equal ground and forcing the consumer to choose, you side-step the issue and add a half-second delay to their visit to your site. Presumably the adverse reaction to a splash page that might cause some to leave the site completely is far less of a concern than the adverse reaction to not playing the language game well enough.

Incidentally, this also used to be a popular trick for retailers to force a choice between US and Canadian currency. By only providing one method of switching between currencies at the very beginning of the visit to the site, the customer would be far less liable to switch to another currency and compare. Thus, the markup built in to US prices (on top of the exchange rate benefits, when there were any) would less likely be spotted. Sometimes it was justified (extra shipping expense), sometimes it was just a cash grab. Either way, there’s no reliable method of enforcing one currency or the other, and if an American ordered in Canadian dollars they would generally have had to honour the price. By taking away an easy method for the customer to compare, the problem was usually alleviated.

Update: Many have suggested use of the Accept-Language HTTP header to redirect automatically based on which language the user’s browser is configured for. While it’s not foolproof (what happens when someone is using a computer/OS in the wrong language? What if their own is set up properly, but they find themselves at an internet café that isn’t?) it seems to be an elegant solution with just one caveat: make sure to provide the user with a way to change their language after the fact.

AkaXakA says:
February 22, 01h

It’s an “Two or more official languages in the same country” thing.

Except holland, where the 2nd offical language, Fries, is only spoken by people in the province Friesland who don’t care if anyone else speaks it.

Belgium has a possibly an even bigger problem than Canada though, as there you’d even have people tape over the dutch or french names of cities, depending if your respectively in Wallonia or in Flanders.

Aldi has quite an interesting approach though: When you enter a local sitename ( or or you’re redirected to the site, where you get to choose your country & language.

Duncan Wilcox says:
February 22, 01h

Is assuming that a browser localized for a specific language will also send an Accept-Language HTTP header with the same language a flawed assumption? It is true here in Italy, I think it is generally true.

My suggestion would be a common redirection page, a “silent splash screen” if you will, that redirects you to the right language subsite, like /en/ and /fr/.

This can be done either server side, based on the Accept-Language header or HTTP_LANGUAGE CGI variable, or client-side with Javascript:

A default redirection would take place when the browser language is not detected or not available.

Note that serving different languages without changing the URL (like apache can do with what they call ‘multiviews’) might seem more elegant but in fact prevents search engines from indexing all the different flavours of the site you put hard work into.

Language-switch links on all the pages make sure visitors can obviate to badly configured browsers (shouldn’t be too frequent) and search engines can scour all subsites.

You also don’t need to set cookies, bookmarks already include the right language in the path.

The only drawback I can think of is that sending a link to a friend who is more comfortable with a different language won’t automatically select the best language for her.

February 22, 01h

This was a very interesting piece, Dave. I get extremely frustrated visiting the site and having to choose every time.

Your point about retailers was very true: I ordered a book for a Christmas gift, and the exchange rate at the time was such that it was actually CHEAPER to pay shipping from than have it shipped for free from

If it could be demonstrated that a combination of HTTP-header detection and I.P. global-location was reasonably reliable, than there’s really no reason why that shouldn’t do it. Just have a cookie as the ‘switch’ mechanism for those who want the non-default.

J Lane says:
February 22, 01h

Yeah, when I used to work for the Government of Canada doing “web stuff”, I used to use the browser language setting (this was back in ‘97). Of course, I always provided a link for the “Francais” or “English” version, just in case my code didn’t work… did in 99% of my tests though.

The big problem is in the translation. It’s really pricey to have your site translated into multiple languages. I’ve often argued that at the University where I know work, that our recruitment pages, at least, should be offered in a few different languages. We have a heck of a lot of students from China, various European countries and a handful of other English-as-a-secondary-or-not-at-all language places.

February 22, 02h

Point taken Adam, I guess I mistakedly omitted the un[official].

On my most recent site, it comes in both Spanish and English. I never thought to give it a splash page for language choice, but after this discussion I am thinking it would be bad *not* to have the language choice up front.

Placing a link in the menu bar to switch languages is agreeably not enough. If your site comes in various languages, all should bear the same weight.

February 22, 02h

Content Negotiation based on the Accept-Language header is the way to go. Add a language chooser with cookies, or possibly Geo-IP-services. has completely implemented such a system, and it is Open Source.

February 22, 02h

As Jonathan (#16) points out, in Canada at least, there are plenty of places where detecting IP’s or o/s is a dangerous business. These methods are simply bad ways to determine your user’s language preference. The only one who knows this is the user herself, and even she may changes her mind from day to day, or within the day.

Tackling this problem for the CBC, I thought that had an interesting way of handling it, similar to Andrew’s: give them your top-level navigation in both languages and let them choose. The splash page becomes a bilingual home page.

I don’t think the solution rests with technology, I think it rests with design: if you’re building a website for 2 languages, you should design your home (not splash) page accordingly.

February 22, 02h Hmmmm. That’s a new one.

What I’m thinking is build a spalsh page to choose a language, then write a cookie based on the language choice. Consecutive visits by the same visitor need not view the splash page for language choice, just carry them into the site based on the cookied language.

Solves the problem as stated by Mike Purvis in regards to the site.

February 22, 03h

Regarding the cookies being tossed around, they’re an interesting devil all unto themselves, and ultimately, an approach such as proposed by Jim (#12) may be the way to go.

It would sure be nice to have a common URL for the English and French version, but what about when you receive a link in your email to a page deep in the navigation tree and you haven’t got the language cookie set? Should it be in the URL-bar also?

What about users who haven’t got cookies enabled? I learned the hard way with my view-once Christmas splash screen that it’s extremely frustrating to try to set-cookie->detect->if-not-there-pass-parameter. (Unless there’s some silver-bullet approach that I totally missed)

And that doesn’t even touch the semantics issue. Someone in the know: Is it more correct to have a single location that sniffs for language? Or separate locations for separate lanuages?

Sarah says:
February 22, 05h

Talk of browser settings, and especially IP and geo data, assumes users are always on their own computers. I can’t be the only one who has accessed multi-lingual content while visiting relatives, at a cybercafe or library, on a shared work computer, in a multi-lingual household, or on a borrowed laptop.

I much prefer online resources to be mostly independent from local settings, so that pages are equally accessible from any computer.

So far the most appealing solution to me is to offer a useful, multi-lingual homepage, different URLs for different languages (for the sake of bookmarks and search engines), and switch options on every page.

February 22, 05h

What’s the percentage of users with cookies disabled? Is it worth the headache of trying to work around their oddities? If people are talking about not supporting IE5, who still has a very small market share (1-2% maybe) why do we still bend over backwards to support browsers with cookies turned off (1-2%).

What about user sessions? Store the user’s language in a server-side sessions variable, back it up with a cookie. Most user sessions require cookies enabled to work properly, but requires testing to verify. I’m pretty sure ASP.NET can track user sessions when cookies are disabled. And *I know* that if .NET can do it, PHP probably already does it too.

Adrian D, says:
February 22, 05h

>> Checking for the browser’s Accept-Language HTTP header is likely to give some people (like me) the “wrong” language - my OS and and applications are all US English versions, but I prefer content in Swedish where available. Yes, I could change the browser settings, but I doubt many people do that.

Hmm, but when you install your OS, don’t you get the chance to choose your preferred language? If you chose English, then I don’t think it is unreasonable for websites to serve you English language content (with a link to switch languages of course)

February 22, 05h

I think Sarah makes an extremely valid point. Not only are we multi-lingual these days (well, okay, I had Spanish in high-school and that was it), but we are also “multi-locational”. It doesn’t matter how well we save someone’s settings for one computer in this day and age of cyber-cafes, work/home, etc. We need to ust make the switch as painless as possible.

And the one thing I love most about teh intarweb is that we get so many viewpoints that we have no excuse to not know what everyone feels.

TonyE says:
February 22, 05h

I guess you’ve never designed for the federal Government. Treasury Board guidelines
( )
state that all Government of Canada intranet / extranet Web sites must have a “Welcome Page” at the main entry point to a site. So those guidelines have probably been carried over by designers into the private sector.

These common look and feel (CLF) guidelines do give a consistency for all Canadians accessing the GoC web sites. Once a user decides to bookmark a site, it will be to either the English or the French home pages (rather than the splash page).

Nate says:
February 22, 06h

when i visit “foreign” sites i don’t mind clicking on “English” to get it in my language, i just accept the fact that english isn’t the only language. having links on every page helps make it easy.

but it sure would be great if the browser could just send what language its in to the site and the site could decide automatically. or better yet when translation services are native in OS’s it will translate a page on the fly! that would be cool!

Jim says:
February 22, 06h

> but it sure would be great if the browser could just send what language its in to the site and the site could decide automatically.

That’s exactly what browsers do. Websites that give splash screens to pick a language are ignoring this information.

If you read above, you’ll see that quite a few people use the Accept-Language HTTP header, which is how the browser tells the server which language it wants the resource to be in.

The issue is whether or not this is reliable enough, whether the state should be saved in the URL or by cookies, and so on.

February 22, 09h

I work for the company that just relaunched the Volvo Canada Website last week (be gentile we’re still optimizing). We usually just go for a link to french at the top of the page… Very similar to switching stylesheets on all these CSS guru’s web pages. ;)

The biggest problem in creating multi-language websites is balancing the fact that french text almost always takes up more space than english, which causes huge blank spots in the design.

Oh and before you comment about the site validating, a) I lost that argument, and b) the site does get crunched through an XHTML parser before getting displayed and has to validate on that first- it just doesn’t quite match with what the w3c says. :[

February 22, 09h

Something else ot consider are computers in public spaces, or computers with multiple users. In all these cases use of cookies can lead to errors.

What it really just boils down to is there is no *guaranteed* way (headers/IP/cookies/voodoo) to make sure you can present the language of the user to them in a bilingual(heck multilingual) country.

Given that the splash/selection page or not question depends largely on the comfort level of the client, which is usually zero.

This still ranks lower on my list of annoyances being a Canadian e-shopper than U.S. sites that won’t ship products to Canada.

If you think E/F is fun Too Scared, try E/F/Spanish/German : note the Canadian site is on v2 while the other non-asian sites are still on the first redesign which is now 3 years or so old but designed with all those languages in mind.

February 22, 09h

Justin: PHP does have a session-management scheme that tries cookies and resorts to url-passing. And on a large site where other settings are being saved, that’s definitely an option.

For less interactive and more content-driven sites, I’d be hesitant to cause every single page-link to have a big ugly hash passed through. Why? Because the most important non-cookie-enabled surfer is the Googlebot. How frustrating it would be to have the search engine caching pages with links containing broken session tokens!

Kevin says:
February 22, 10h

Novalogic is a game publisher with an international market. Landing on an interior page without a cookie sends the user to this page (
After making a selection, the user can navigate the site and optionally change the language. The UI is in the upper left and displays a flag and “Change Language”. IIRC The language app destroys the usefulness of bookmarking and sending links.

Nate: “better yet when translation services are native in OS’s it will translate a page on the fly!”

I’m not so sure about this. Auto translation using Google or Babelfish is very garbled.

eijikel says:
February 22, 11h

It’s an interesting comment. I live in Switzerland. This small country has 4 different languages and you can count english as the fifth element. Pretty scary huh? Going deep into the details of dealing with it is beyond the scope of my modest comment, but one would be hardly pressed not to choose a default language. Then it’s all a matter of sending a cookie to remember the user preferences. You also have to take into account that people living in countries with various languages (not that there are many) are used to this way of surfing. It might seem strange to a person living in the UK or in in the US though. Due to the various languages available in Switzerland, splash pages are not widely used, for obvious reasons (how ugly that solution would be).

Paul D says:
February 22, 11h

I suspect that if HBC does serve different start pages, it does so based on the browser’s accepted languages string. It should be easy enough to test, just rank French above English in your language settings, clear your cookies, and try the sites in question.

Good website interface design should present the language-selection screen (or currency-selection screen) the first time someone visits, and cookies to automatically redirect the visitor on subsequent visits. Of course, a prominent link to change languages should also be visible, with each supported language written natively.

Multilingual sites are also a good impetus to use proper encoding methods like Unicode. No one should be serving English/French welcome pages in DOS-era English Windows encoding.

February 22, 11h

Well, Air Canada truly has a different approach:

“We can’t provide full features or properly formatted pages because your browser is not compatible with our site. See our Browser Requirements to download a compatible browser or to adjust your settings.”

(this was with Safari). The requirements say:

“Supported Browsers:
Internet Explorer 5.5, 6.0 and above
Netscape 7.2”

What can I say? They really seem to be obeying the airlines website standards.

JCRogers says:
February 22, 11h

The AirCanada site tells me my browser needs to be upgraded. Horrible practice to even have such a page. Worse when considering that I’m using the most recent firefox version.

February 22, 11h

I wonder why these sites don’t try to select a correct language site based on HTTP Content-Language negotiation:

This is an easy technique to support if the server has any scripting (or Apache config) capability.

But of course, not everybody has the correct browser language preference set, so the language page where they end up must include option for switching to the other alternatives.

This is what we do automatically on for example our corporate site,

I’ve published a HOWTO on this for Midgard CMS, and I guess the same instructions would pretty much apply to any PHP-powered site:

Dave S. says:
February 22, 11h

Paul, that would be a simple, elegant solution - but none of them are doing it. I checked those without a splash screen in as French a configuration as my Mac can muster, and all of them served me English by default.

(Yeah, and Air Canada’s browser requirements are stupid, I know. The standards message hasn’t reached everybody yet.)

Remi P. says:
February 22, 11h

As a french Canadian (a Quebecois, like we say here), I appreciate when there’s a splash screen asking me for my language.

But please, don’t make english page the “first” one and provide a “In French” link at the top. It sounds like “You probably speak english. In case you speak french, well, click here”.

Dave P says:
February 22, 11h

Nice topic Dave,

It should be worth noting that all of those sites set cookies after the first visit, so I didn’t see most of the splash screens you were trying to point out.

It may be political as you said, but I’ve always preferred subtle language switcher links such as the one on my company’s site, or Manulife.

The insurance industry seems to prefer this way in general.

Interesting that most of the gov’t sites also use the splash screen method.

February 22, 11h

One test I did was to bookmark one of the pages in English. Then wipe my cookies and see if it asks me again to choose a language. It did not. In fact, the assumption was because my link was to the English version, then I wanted to see it in English. If I then choose to see it in French, I had to scroll to the bottom of the page to switch it.

It would seem more useful the language choice any time someone visits who does not have that cookie value set. However, I’m also not saying this is the best way to handle it anyway. I think the language choice should be available near the top of the page instead of the bottom.

February 22, 11h

Very interesting, while this topic doesn’t have the same bearing in the US, I believe that given another 10 or 20 years and Spanish could be the official second language. The Blockbuster site is pathetic, it blows my mind that something so stupid could make it into production for a corporate website! I would be embarassed if one of my sites had such an error and I’m lucky if I get 20 visitors a day.

While we’re ranting on Air Canada, I’d like to join in. Last summer I was trying to book tickets to Vancouver, I went through their entire site (using Firefox on Windows), selecting dates and all that good stuff. I was deep into the checkout process (if you’re a first time customer, there is a lot of info to create) when I suddenly am presented with a Submit button which did NOT submit. It was the last form I had to fill out and I was pissed.

I called and complained to customer service and I wrote them a nasty email. Obviously they’ve received enough complaints by now that they’ve put a lot of time into correcting the matter (not really).

February 22, 11h

I find it hard to make a “best” choice here. Using a splash page makes the site feel dated and is an inconvenience for visitors. Assuming that one language is going to be more common risks scaring off those who prefer another language. Checking for the browser’s Accept-Language HTTP header is likely to give some people (like me) the “wrong” language - my OS and and applications are all US English versions, but I prefer content in Swedish where available. Yes, I could change the browser settings, but I doubt many people do that.

Whatever you do, some will feel you made the wrong choice, just like with font sizing or fixed vs fluid width ;-)

Interesting discussion though. I will face this dilemma in an upcoming project, so I’ll follow this closely.

Jim says:
February 22, 11h

The way I’ve handled this in the past is:

Check to see if the URL explicitly requests a particular language. For example, you could have:

If no language is explicitly requested, check the client’s Accept-Language HTTP header, and serve on that basis *without changing the URL*.

Offer alternative language links in the head element of each page (so they show up in link toolbars) and also as content (in a sidebar, usually). These links should be present in all cases.

The links to change languages should *not* be flags! Too many people screw that up. Jukka Korpela has a good page on that subject.

This, to me, provides the correct behaviour by default in the most amount of cases, and reduces the effort to switch in the other cases as low as is feasible. It’s appropriate for things like deep-linking, social surfing (e.g. sending links to friends), and all sorts of other cases that don’t spring to mind immediately.

Andrew says:
February 22, 11h

We have the same issue at the Museum ( I work at and I think we came up with a solution that seems to work. We wanted to try and give equal access to both English and French speakers without having the user to click an extra time just to get to the page they want. I always found those pages annoying and they just slow me down, so why not get rid of them? It seems to work just fine, as long as you trim your navigation down so it all fits nicely. This of course means finding a place for everything, and it was a long struggle for us to figure out where everything went. In the end I think we did a good enough job that most can find what they are looking for with a minimum of fuss in either language.

February 22, 11h

Andrew… looks great… I do like that idea. Of course, some will still read too much into just the layout. After all, the French translations are lower than the English ones or to the right as the English is to the left. It can still be assumed that English is the primary audience even if that’s not your intent.

Unfortunately this all stems from those small groups of people who take offense at their language of birth being given less prominence. Hello, we’re all on the same globe… At the very least, another language translation is more accessible on the web than sitting down in a restaurant in a foreign country. It only takes a few whiners to make our work doubly complex.

Andrew says:
February 22, 12h

Thanks Charles…

The reason the English is higher is because we are in Ontario. Working in government you soon start to realize that if you are in Ontario the English usually comes first (but not always). If you are based in Quebec the French usually comes first. Takes some of the headache out of deciding what goes where and so far no complaints about the layout.

Jonathan says:
February 22, 12h

As a Québécois based in Montreal, I’m always facing this kind of issues, since we have clients on both sides of the Français/English fence. We will return to a “Choose your language” splashscreen after over a year without it, because we have many complaints from our English visitors (our page defaults to French). Even with the best interface, visitors will be disoriented when facing a page in another language, especially, I’d say, English-speaking people who are - no offense - not used to it (as opposed to us French). Of course, a cookie that remembers the chosen language will be mandatory.

As a French-speaking person, I prefer to have the choice before entering the site. It is simpler, I don’t have to hunt down the Français link somewhere in the page.

And, believe me, you can’t assume that French people will be using a French browser and serve a page on that basis - you’ll be wrong more often than not. A lot of us, especially in Québec, use English OSes or software, which dosen’t mean we don’t care about the French version of your site ;)

Adam Rice says:
February 22, 12h

Just as a slight derail, I wanted to comment on Justin’s comment and point out that for Spanish to become the official 2nd language in the USA, something would need to be the official 1st language.

It might seem surprising, but the USA has no official language whatsoever, and those whose native language isn’t English sometimes fight attempts to create any kind of legal preference for English. No business in the USA can be compelled to have signage in English (or any other language).

Content-language sniffing does seem like the smart thing to do, to the extent it can be relied on. Perhaps the nice Firefox people could make “my preferred language” part of the setup process.

Sarah says:
February 23, 01h

Yes yes, naming multilingual URLs is an interesting problem!

Internationalized word choices are intriguing— any traveller in Europe quickly picks up “pardon” instead of “excuse me”, “photo” instead of “picture”, “moment” instead of “wait a minute”. There are lots— I wonder if there are enough to make a website out of? Just for fun. It would probably have to be about hostels.

Roland says:
February 23, 01h

It’s not a Canadian thing, same problem here in Belgium between french and flemish/dutch.

If you want to see a nice language splash page please go to

20 languages to choose from.
And once you have chosen your language you can switch to other language using a combobox.

February 23, 01h

We had a similar problem to tackle with the Rocky Mountain Bicycles website. We went for the splash page and language selection, but with a twist.

Not only did we build it in 3 languages (English, French, German) but there were “Domestic” and “International” versions of each. That is, French speakers in France (French International) get a different selection of products than do French Canadians (Domestic French).

We still have a “Francais/English” toggle at the bottom that allows for you to switch back and forth between the versions (and a Francais/English/Deutsch for the int’l version).

Some clever language context stuff, .NET, and XML saved the day for the build. And a good clean design (watch for those long German words in your fixed length navigation!). We went with one URL (no de or en in the URL) and yes, the URL’s are all in English.

February 23, 02h

To Charles Belov
The idea of writing a cookie to store the user language choice is for customer experience enhancement, not and end-all to access the site. I’d like to clarify:

1) User navigates to site for first time.
2) Presented with splash to choose a language.
3) Once a language is chosen, a cookie is written.
4) Recurring visits by the above visitor need not choose a language because it is stored in a cookie.

If cookies are not supported (paranoid user or web crawler), then the user must choose a language each time they navigate to the site on recurring visits. This model does not hurt web crawlers in any way whatsoever.

If you are a cookieless visitor, you get the same experience as shown by the Future Shop site ( ).

Maybe I’m being stubborn, but it sounds like a good model to me.

Mike, I agree that URL-based session tracking is probably not a good solution to user’s with cookies turned off. My arguement is why are we even worried about these visitors in the first place, not how to deal with them.

Jim says:
February 23, 03h

> For one, the word “shop” is always in english, even if you’re on a non-english page.

That’s unfortunate practicality. It’s much easier to simply pull out the language from the URL and keep the same URL structure for all languages, rather than build a URL mapping for every language.

Also, it doesn’t work when you initially serve a language negotiated page and offer links to explicit URLs. For example, both English and French visitors might read /shop in their own language, it’s only when they explicitly switch languages that you’d get the opportunity to provide language-specific URLs. I feel it’s better to maintain consistency (and URL hackability) than translate URLs in just some cases.

> Secondly, if you’re on an english page, you get english/shop which is redundant.

I’m not sure I follow.

Are you saying that because it’s /shop, you know that it’s English? Not necessarily - consider /cafe or some other word that is the same in two separate languages.

Are you saying that the link to the English version is redundant? I agree, and I don’t place links to the English versions on the English pages.

joshua says:
February 23, 04h

Strange you should publish this today. I’m thinking of some of the same things right now as I am designing a bilingual site in Japanese/English. Here though (Japan), Japanese will of course be the default, but as it’s for an outdoor sports company, many of its patrons are foreigners. So luckily I don’t have to wrestle with the splash page/menu links choice.

On a secondary note though, are there any CMS’s or blogging packages out there that allow one to publish the same content in multiple languages and give each language equal footing in the administrative area? I’ve only been able to find hacks where you have to keep two posts up-to-date (one in each language), and this isn’t very user-friendly.


joshua says:
February 23, 04h

Sorry, that last post of mine was horribly short on info. Anyway, regarding the CMS, I need something lightweight, preferably PHP/MySQL (similar to WP et al), and simple.

I know Plone does this, and I checked out the Midgard CMS mentioned above, but these are way overkill.

If I had the time, I’d build my own custom job, because it just doesn’t seem like any of the mainstream options were designed with this thought in mind…

heath says:
February 23, 08h

Avoid making language decisions for your user like the plague!

In Belgium this issue is very, very old (like other European countries) and the splash page is pretty ubiquitous. Also, the political aspect of language is very important here (much more-so than in Canada I suspect). If you want to see some good examples just type in any of your favorite global company .be.

Some important tips:

1- Don’t trap your visitor into a language ( does this, but my wife speaks French natively and I English, argh, think people) make it easy to change after.

2- Do set up your site url in a smart way like commented above:

3- Don’t use any default language unless you really don’t want the other languages visiting the site (but then why would you translate).

4- Do, at the very least, provide links using Bablefish or Google language services to translate your site.

5- Do remember when designing pages to ask your clients to provide translations for all content or charge them for the translation (and only use native speakers with translation training).

6- Do tell your mother that you love her, you ungrateful louse!

February 23, 08h

I’m a french Canadian and i think the best solution is to have a splash screen and after the web site remember that you chose a specific language with a cookie. I really dislike website like who we force you to have english page in default.

February 23, 09h

While we’re on the topic, does anyone else think this is a bad idea? For one, the word “shop” is always in english, even if you’re on a non-english page. Secondly, if you’re on an english page, you get english/shop which is redundant.

Much better, in my opinion, to use english and romanized file/directory names:


Thomas says:
February 23, 09h

I find this a very interesting debate, while I might note that I grew up in New Brunswick (the only official bilingual province in Canada) and considering that are province has been bilingual for years before they started to change road signs and enforce signage in both official languages, but as you travel through out the province you notice that the english dominate areas have the english first and the french second while vice versa when travelling through the french areas. My point is although it is a standard or something that may be enforced there are numerous ways of doing things. I am a web developer for the government of canada, so I know plenty about developing (in both languages) and the english/french splash page, but which language comes first ? one thing we always do is keep the file names the same but add a sample.htm or sample_f.htm and this files will be called upon by the users preference in the initial decision to choose english or french and the links are always the english version regardless. Well this topic can be debated for every and I’m not sure if my point was very clear but hopefully you’ll get something out of my ramblings.

Thomas says:
February 23, 10h

Sorry for the typos and not proofreading I wish I could type as fast as I think.

February 23, 11h

Why support browsers with no cookies? Because some of them are called search engines.

I am dealing with a similar issue, in that we have two agencies merging into a single agency. The functions of the two agencies are related (transportation) but different (bus vs. driving/parking/biking/walking). I have (successfully) pushed for a (future) combined home page as opposed to splash screen. That way, visitors can feel they are making a productive choice when they reach our new home page rather than wasting a click.

From that aspect, I feel that the Canada Aviation Museum and the Bell Canada Home are closest to what I want to accomplish.

Air Canada unfortunately doesn’t recognize that Mozilla 1.7 is functionally equivalent to Netscape 7.

One problem with the TravelCanada site is that I might not be conversant in the language of the country I am traveling from. That is, I might be an expatriate. It might be better to ask what my language preference is. And it is bad to automatically jump to the new page upon selection, as I occasionally mis-select the first time. I believe that is a violation of W3C accessibility guidelines.

February 23, 12h

Check Ukrainian sites. There are three languages at most comercial sites: Ukrainian (state), Russian (international) and English (for selfrespect). Nobody uses language detection, because all these languages aren’t location specific (like Quebeq).

Only buttons or combo boxes.

Martin says:
February 23, 12h

Guys, I’m going to contribute some pretty useless technical information:

In South Africa we have 11 (yes eleven) *official* languages - take that!

Maybe that’s why developers here tend to stick just to English, if only to not stir up a hornet’s nest :-)

len says:
February 24, 02h

I live in Belgium and we have 3 communities that speak a different language: French, Dutch and German. And because of the fact that Brussels serves as a European center, English can be considered as the 4th language.

A good example is the, which shows a splash page with 3 categories in the 2 main languages. German an English don’t get that much space, but they are present. You get to choose between 4 languages on this page!

The good thing is that you choose a language by clicking on a category that is displayed in your language and not some button that says “your language”. This option shows the visitor already something of the content inside. (In this case it is used to identify the purpose of your visit depending on what type the visitor considers himself.)

The problem is clearly a political one, and mostly tied to the geographical reach of the company, industry or organization.

If the company or industry goes beyond country boundaries (like big insurance companies), English is still the standard language. And they will use a language switcher for each page. Local industries however, will identify the visitor with their language, possibly modifying the pages to cultural differences. A splash screen looks a good solution to me, if some categories are shown on this splash page.

John Fairley says:
February 24, 07h

re: Cookies

Again the problem with cookies is that for shared computing situations (public spaces, people who use the same login, computers in board rooms, the list goes on) this is functionally equivelent to not having a splash page and forcing users of the other language to switch it.

Now for sites with login you could have a user preference, but really only safely in this case.

praetorian says:
February 24, 09h

my favorite part of the air canada site is “We can’t provide full features or properly formatted pages because your browser is not compatible with our site.”

so basically, they’re admitting THEY’re own failure, yet it’s because MY browser (firefox 1.0/mac) is not compatible. hysterical. no, actually, it’s quite pathetic.

February 24, 10h


> It’s much easier to simply pull out the language from the URL and keep the same URL structure for all languages, rather than build a URL mapping for every language.

I agree 100%. This is great for programmers, but rotten for users. My point is that if you’re going to support multiple languages, you should do so with the visitor foremost in your mind, and your URLs should reflect this.

Presuming you were an english-speaking visitor looking at english content on a Korean website, which link makes the most sense to you?


itchi says:
February 24, 11h

Wow, great discussion on this topic. I too am currently in the midst of developing a bi-lingual Canadian Federal web application. However, for various reasons the CLF does not apply to me but it is in our business’ best interest to provide a french version.

My comment is mostly in regards to the URL format. For the application programmer having two versions of a dynamic page ie and can cause some issues with maintaining two seperate code bases. This really increases your chances that a juniour programming (or someone unfamiliar with the site) coming in and making a change to one page only.

I’m currently using and utilizing .resx files for all of my localization requirements. I will also be using URL rewriting to handle bookmarkable pages so I can have the same page and code behind for and

But I can’t think of any other way to get around a splash screen for first time users without irratating either a french or english user due to many of the previous posters comments.

pid says:
February 25, 04h

The BBC News website shows a splash page if it can’t find a cookie with your regional preference in it.

February 28, 02h

I also live in Belgium (hi, len!), multi-language sites are a given here. I usually do a splashscreen but add the posibility to change the language on every page. A good example is the site I did for the Antwerp Ballet School
I recently tried using a stylesheetswitcher to do the same (on a site for a designer friend of mine so you don’t hace to reload the page, just a div with the text.
Oh yeah, the AIR Canada is just pathetic; I thought we were past that cr@@@p.

tom says:
March 01, 10h

This may have been mentioned before in the comments (I did not read them all), but the Canada Post site is also a good one to look at -

March 03, 07h

We use a very simple english/french link at the top of this website that remembers the preference as you navigate around. I feel it’s easy to use and understand, avoiding a lot of unneccasry code in the process.

Not an e-commerce site, but this link system is going to find its way into a online store project we’re working on at the moment.

And good luck to all those sending emails off to Air Canada - a colleague of mine phoned them directly (he’s non-technical) to complain about the browser “requirements” and was told by Customer Service that it was Apple’s problem, not theirs. He was made to feel both stupid and un-valued. Hmmm.

Go WestJet!


Simon says:
March 03, 12h

Just one more gripe about the shocking arrogance and lack of awareness shown by aircanada’s browser requirements!

Unfortunately for them, their laughable attempt at getting me to downgrade my browser is likely to be the last visit I’ll make there!

I was so gobsmacked, I sent them off an email, not soemthing I’d normally bother doing.

Rant over. Thanks for the interesting topic!

Mike Ward says:
March 04, 07h

I have done a splash screen with a choice between English and French a few years ago for a site for an American artist now living in France. I am about to do a redesign so this is a very timely article.

Admitly, I have only browsed the comments as of now but I was thinking about having both the English and French sections on the page and having cookie based scripting decide what section to show via CSS.

That wasn’t a very eloquent explanation but I hope my idea is clear enough to get this groups opinion on an option like that. I am currently maintaining 2 copies of everything and was wondering if my idea would help.

Your thoughts would be appreciated.

Ciao, Bye, etc…

March 09, 01h

I have noticed this too actually becoming more popular lately when looking at canadian websites, namely retail.

S says:
March 14, 09h

I can talk a little bit more about Air Canada’s website, having been part of the redesign team.

First, the Splash page: If I remember correctly, it was a client request even if we talk to them about HTTP header. The main reason is to separate the US and Canadian version of the site since they don’t have the same flights or specials.

Browser compatibility: Well… Let me just say that Air Canada still use Netscape 4 at all their offices.

Web standard: It goes without saying that their pretty much inexistent considering we HAD to support Netscape4 :-(

And I’m not even talking about the two different group inside Air Canada who were fighting over the direction or the fact that it cost too much to really redo the whole website but I’m going off subject.

Having a splash page show only once (like Air Canada does) is not that bad considering some site you have to hunt to change language or always show the splash. A simpler solution in my mind is an HTTP header AND the use of a language button.

March 21, 09h actually does use the accept-language to determine which language to present to the user upon initial visit to the site as well as includes a very obvious link to the other official language if the user wants to view the site in another language.

Patrick B. says:
December 07, 07h

Just a quick note here to add to what has been said thus far. Some splash screens make you choose different flags, as if flags were somhow associated to languages. Perhaps that was the case in 1685, but not anymore.

An excellent paper has been written on this subject by Jukka Korpela (

The best approach to me is to have the name of the language in small characters written in English, just under (or beside) the name of the language in its native language, with its own characters the case being: french FRANÇAIS, English ENGLISH, Spanish ESPAÑOL, etc.

One thing is clear, you cannot associate a language to a specific area of our little planet. There are many arabic speakers right here in Toronto, and some of them, even though they are fluent in English, must sometimes prefer to read in arabic. If this language is available to them, let them choose.


Anastasi says:
December 14, 18h

The best variant is write like said Patrick, to write laguage on the native language. A for each site better to have as many languages as site can afford to support, it will attract more readers