Do You Know What Countries are in Western Europe?

Different people and organizations define geographical regions in almost the same way, but there are differences. Consider the different regions of Europe for example.

What countries do YOU think are in Western Europe? Are you sure one or two of those aren’t in Southern Europe? How do you decide?

According to the United Nations, nine (9) countries define “Western Europe”. Can you name them? I’ve included an image below to help.

Western Europe No Names

You can learn more about how the UN defines world macro regions with their M.49 document.

Just another suggestion for language selection lists

Recently I was asked to fill in an online questionnaire. As I began the form, an entire window was shown to me, and it had a single UI item on it, a language selection list. Of course, I had to click on the list, wondering what wonderful choices I might have for a user interface. Surprisingly, the list revealed a single entry: English.


If you sometimes read my blog, you’ll know that I’m particularly interested in language lists at the moment. However, if you are interested in providing a list, I do have one additional suggestion…if you don’t have any choices, you probably shouldn’t use a selection list. It’s just too much of a bummer when nothing else is available and just doesn’t make much sense. Maybe disable it until your UI does provide additional languages.

That’s it for today. 

Language Signals on the Web


Presenting a user interface in the customer’s language should be a high priority from your product management team. If not, they’re not doing their job in my opinion. Assuming you have the feature in your product roadmap, how do you choose the UI language of your customer on the web. After all, web applications have multiple, sometimes conflicting language signals.

A language signal is an indicator that gives your application a hint of your customer’s preferred language. In a web application, these signals are numerous. To help you in choosing from all these signals, I believe you should honor the preferences in the following priority. That is, check each signal for its existence in this order, and use the first signal that is available:

  1. query parameters, for example
  2. domain name or path parameters, i.e. or
  3. persistent application preferences
    • cookies
    • customer profile or settings
  4. browser accept-language headers
  5. geolocation hints
  6. default application language

Query Parameters

Query parameters are often used to override every other language or application signal. If parameters are used, your customer (QE engineers or even end users) are intentionally trying to coerce the application into ignoring all other language signals. Query parameters beat out any other language signal when they are provided in the same request.

Domain name or Path Parameters

Sometimes you will partition your localized sites by domain name or by language tag paths. A domain name partition means that you select different or even localized domain names for specific markets. For example, your French site could be You can also distinguish language preference on the path like this: or When query parameters don’t exist, this is the next choice in our prioritization.

Persistent Settings

Of course, if your application has allowed the user to select a language preference, the application should honor that preference. The preference may be stored in a cookie or even in a user profile attribute on the server.

Accept-Language Header

Most browsers provide a list of user language preferences in each request. These languages are provided in request headers as values of the accept-language attribute. This attribute can have 1 or more language codes, and they indicate the priority of the user when requesting content. In the absence of other signals, your application should respond to the accept-language header.

Geolocation Hints

The last signal that actually provides information about the user is the geographic location from which the user is accessing your content. Although imperfect and imprecise, geography can provide a hint to your customer’s language preference. It’s definitely not the best indicator because multiple languages can be spoken in any geographic location. In a pinch, though, you may be able to provide a language selection tool that provides a list of the most prominent languages spoken in a specific area of the world.

Default Application Language

Finally, when all else fails and there have been no other indicators, you can provide the UI in the default language of the application. If your company is in Germany, maybe the default is German. If it’s the U.S., your default language is most likely English…or maybe even Spanish. You have to display the application in some language, and the default at this point is your last option.

In Summary

To summarize, a web application can serve a global audience. In doing so, it may accommodate customers in a variety of languages. Your application’s user interface may be selected from numerous possibilities, numerous signals from the user. Those signals are important data points to consider when making the language choice to present to the user. Using the signals described in this article, you’ll be able to consider some of the more important language preference indicators. Follow the prioritization I’ve outlined here, and you’ll make the right language choice most of the time…until you don’t. And there will be times when you don’t make the right choice from all these signals. When that happens, and it will happen, you have to give your users some way to indicate that problem. Take a look at my previous blog entry about language selection widgets for help with that.



Even Apple Messes Up Sometimes

You have to respect Apple. They have excellent products that are known worldwide for their quality and ease-of-use. Part of that ease-of-use comes from their commitment to producing internationalized, world-ready products. However, even the best companies and employees make mistakes.

Recently I purchased a new iMac 27″ computer for my family. Of course, they don’t believe it is for them since I spend the most time using it. But I’m going to stick with my story…it’s the new family computer. Anyway, I immediately noticed that Apple is pushing their iCloud service. During setup and first run of things like iPhoto, I was prompted to choose whether I wanted to use iCloud for backups, etc.

Of course, I had to try out the iCloud service, so I entered all my personal details — name, account id, etc. The service works as expected, and I have nothing interesting to report on that.

To make iCloud clearly available and visible, Apple puts the iCloud service settings into the System Preferences application.

icloud settings

Clicking on the iCloud icon brings up the iCloud settings of course. Again, not much to say there. You have all the typical iCloud-able apps to choose from: Mail, Contacts, Calendars, Photo Stream, etc. However, I did quickly notice that iCloud had a little trouble with my name. Instead of showing my full name as John O’Conner, the iCloud app prominently displayed it as John O'Conner. Oops.

Icloud name

I admit that this is not the first time I have seen my name displayed in this way. Web forms sometimes mistakenly store my name using character entity references. Apparently the apostrophe sends bank and medical systems into fits of confused stupor. However, I’m surprised that it trips up Apple in this way.

It just goes to show you that even some of the best companies can make mistakes with how they handle and display text data. It’s common to normalize text when putting it into a database. However, I don’t think a character entity reference is the right thing to put into your db. If you do, you certainly should remember to decode it when you display it to your user.


Providing a Language Selection List

Lang listThe questions pop up often enough in internationalization circles so I’ll address them here:

1. how should I localize a language selection list?
2. how should I sort it?

Localized Language Lists

Customers use a language selection list to change languages. You must assume that the currently selected language is inappropriate for some reason. One possible reason is that the user cannot read the page content. This means that a localized language list that displays all target language options in the language of my current page probably won’t be understood. For example, let’s pretend that I speak English but am on a Japanese web site. Presenting me with language options that include ” 英語” will not help me if I don’t read Japanese. I can’t be expected to know that those characters mean “English” to a Japanese person. This option is unhelpful. What is helpful?

The right way to represent any language selection list is to display languages in their own language and script. For example, English should be English, Spanish should be Español, Japanese is 日本語, etc. You don’t need to localize this list into every language. One list using the target language’s own language and script for each language choice is both sufficient and optimal. This guarantees that I’ll be able to read and select my target language regardless of the current page’s language setting. This is the most universal option you have, and I consider this a best practice for creating language selection lists.

Sort Order

I don’t know how better to prepare you for my answer…so here it is. The actual sort order is less important than consistency. Two points make this obvious to me:

1. if your customer wants to choose a different language, they probably don’t speak the current one, and the current language’s sort rules won’t be particularly useful anyway.
2. you can’t accurately guess what language rules you should use because you don’t know which language the user will select.

With these points in mind, I don’t think the sort order matters. Correct linguistic sorts for this list are not critical, and anything you choose will be inconvenient to someone. For this reason, I think you simply have to choose a sort order and be consistent every time you show the language list. My suggestion is that you simply order the list in U.S. English order if you consider U.S. English to be the base language of your product. If you consider your base language to be something else, use that. My point is that it doesn’t matter. Sure, you’ll be tempted to provide this list in the sorted order of the language of the current page or host OS setting. Sure that’s an option, but it’ll be incorrect more often than correct when it’s needed. Save your sanity. Choose an order. Be consistent. Don’t worry about localizing this order.

So this sort issue is bothering you still? You just can’t accept it? Ok, that’s fine, but consider this. The solution I’ve described is already used by some pretty big players. Since I just finished evaluating Facebook, let’s use it as an example. Regardless of which localized site I visit, regardless of my browser language preferences, Facebook shows the same list of languages in the same sort order. They don’t even use a US English sort. Their choice is something different, something almost like a US English sort, but maybe using the Romanized version of the target language? Here’s an example — Japanese is sorted with other languages that start with an “N” sound. The Japanese pronunciation is romanized as “nihongo”. So, “nihongo” starts with an n and sorts with other languages that start with n? I can’t quite figure the sort rules out BUT that’s my point…it doesn’t matter. Its consistent every time I go to the page, and it works. Here’s a shot of that Facebook page:

Fb lang selection


Providing a language selection list for your multilingual product is a great idea. It lets customers conveniently change the UI language of the product. Don’t over-think this problem. You can provide this feature without spending countless hours of debate. Follow my suggestions:

  1. Provide a single language selection list in which each entry is translated into the target language and script.
  2. Choose a sort order, any order. Be consistent in displaying this order.

Have a suggestion or comment? I’d enjoy hearing from you.




Answers to Which Countries Have Multiple Time Zones

Yesterday I asked the question:

Which countries have multiple time zones?

And I promised an answer today. Congratulations to Paul Clapham, who made a great effort listing them!

The W3C document Working with Time Zones is the source of my information. That document lists the following countries as having more than one time zone:

  • Argentina
  • Australia
  • Brazil
  • Canada
  • Chile
  • Democratic Republic of the Congo
  • Ecuador
  • France
  • Greenland
  • Indonesia
  • Kazakhstan
  • Kiribati
  • Mexico
  • Micronesia
  • Mongolia
  • New Zealand
  • Portugal
  • Russia
  • Spain
  • The United States


Countries with Multiple Time Zones

Recently I came across a W3C document about times, dates, and time zones. The document claims that only 20 countries observe more than one time zone. The United States is in that list. Can you name the rest of them?

I’ll post the answers to this question tomorrow! Until then, which countries do you think have more than one time zone?

P.S. Please provide your answers as comments!

Offensive Hand Gestures of the World

Recently I told some colleagues that I wanted to write a book about offensive hand gestures around the world. In my business, it’s common knowledge that icons of hand gestures just don’t localize well. We’re told to avoid using icons of hands and fingers because we might offend someone in a different culture. I’ve always known that anything can be offensive to someone somewhere, so of course I’ve accepted this as truth. Seems reasonable to avoid hand gestures when I can.

However, in all my years working in globalization and localization, I’ve never once been provided a comprehensive list of gestures that should be avoided. And not surprisingly, I’ve always wanted to see that list! In fact, I’ve wanted that list of offensive or rude gestures so much that I promised I’d write a book on the topic.

Oddly enough, it turns out that someone else has already beat me to the task. And I’ve discovered this not a moment too soon — I was already interviewing hand models. :) So, now that I know that someone has already beaten me to the job, I suppose I can now take that book off my todo list and just get a copy of it.

In my extensive research on the subject, I’ve found 3 books. THREE! On one of my late-night runs to Barnes and Noble, I saw the first one on my list — it was in the old discounted book pile. What a pity! Now pull out your credit card and take a look at these gems. I know I’ll order at least one of these:

  1. Rude Hand Gestures of the World
  2. Gestures: The Do’s and Taboos of Body Language Around the World
  3. 70 Japanese Gestures: No Language Communication

It’s really too bad too…I could really feel myself being pulled into this work. Maybe I can hope that the original authors do a 2nd edition and allow me to help? Man that would have been a fun book to research and write! But alas, I’m too late! But finally I’ve found the book I’ve wondered about for so long!


Companies gain productivity from continuous work force

One of the wonderful benefits of any global company is the productivity achieved by having a continuous work force. As one group of employees in the US go home, another set in India begins its day. It’s an oversimplification for sure, but I have no doubt that global companies gain real productivity.

Here’s an example of real productivity. It is now Sunday night on April 17, about 11:35 PM in my local time zone. I’ve just responded to an email that’s been in my INBOX over the weekend. Fortunately, even though it’s late for me, and I’m really, really exhausted, my colleague in India is fresh and perhaps just going for his lunch break on Monday afternoon. He can take my email response and act upon it. The contents of the email provide a helpful tip for fixing a unit test. The end result is that the corporate product — the software in this case — has continuous nurturing, updates, and improvements.

The problem is at the micro level, however. While the larger company product benefits, sometimes individuals that work in that environment burn out. I’m no where near that, but I can see a pattern evolving that could lead to that. You see, for me, the work day never ends. Somewhere in the world, someone is working on a problem that I am also working on. Ideally, the handoff would be a clearly distinguished time. That is, I might get an email in the morning, work on the issue, then respond before my end of day. Then my colleague in India would awake (and I’d be asleep), and then he would continue working.

In reality, however, the actual work day never really ends for some of these people. For example, I stay up late to get a real-time response back. Or I might use an instant messenger tool to get an immediate response from a colleague around the world. This continues for several weeks until finally someone gets ill and has to take a few days extra rest. At the micro level — at the real person level — around-the-clock work is not a good thing. It takes its toll on energy level, family interactions, and even health.

In the end, I still think a company can benefit from a global workforce. However, individuals must be disciplined to let one shift end and another begin without feeling the need to constantly communicate in real time. In a global workforce, asynchronous email is a great thing. I have to remind myself of that regularly. Like now. Time for bed. No more work for me. Good night India.