Accessibility, Gender, Internationalisation, Localisation

Link roundup: 12 April 2015

Most of these links are OS X-related for now – I think the next roundup will have a Windows or Linux focus to make up for it.


Be gender-inclusive

Avoid sexism when marketing your tech product or writing documentation. Despite stereotypes, men are not the only people who use computers.

You can avoid the ‘all competent computer users are male’ assumption by:

  • Using gender-neutral language in your documentation. Don’t use ‘he’ as a generic pronoun to refer to your users – instead of saying something like ‘a user should go to the Preferences menu to choose his settings’, rewrite the sentence to be gender-neutral. In some languages, using ‘he’ as a generic pronoun is typical, but in English, many people consider this offensive or sexist. A good way of doing this is making the subject of the sentence plural, so it reads ‘users should go to the Preferences menu to choose their settings’. You can also use the second person: ‘you should go to the Preferences menu to choose your settings’, or use the singular ‘they’ as a gender-neutral pronoun: ‘a user should go to the Preferences menu to change their settings’. NB: some traditionalists object to the singular-they construction, but there’s nothing wrong with it.
  • Showing different kinds of people using your product if you use images to advertise your application or game. Show people of all genders, not just men. Try to make sure there’s a mixed group of people, so it doesn’t look like tokenisation where you’ve got a single woman in a sea of men.
  • Don’t use women as your image of a novice or non-technical computer user, like guides that write about ‘Linux that your mother can use’. The Geek Feminism wiki has a good article about avoiding making women the stereotype of novice or non-technical computer users, which is worth a read if you’re trying to make your website, game, operating system or application more inclusive. There are men who don’t have a clue what FTP, PHP and Angular are, and there are women who are experts at all those things. Don’t be sexist and pander to tired, hurtful assumptions about the gender of your users.
Internationalisation, Localisation

If you’re going to translate, translate thoroughly

If you’re going to translate a site into another language, make sure the translation is thorough. This is related to one of the first entries here, ‘Provide accurate translations’, but it relates to a specific problem that results in half-translated text, as opposed to translations where all the text is changed to a new language, but the words are simply wrong or the sentence structure is weird.

I’ve noticed this with websites and apps that were originally written in English and later translated to a different language. If you’ve noticed this with other languages too, you can mention them in the comments.

What not to do

If you try to use the FedEx US website in Spanish, half the text is still in English. That wouldn’t be as much of a comprehension problem for somebody who’s fully bilingual in both languages, but it’s still jarring to see text in two languages:

Screenshot of the FedEx US website, set to Spanish. Most of the text is translated into Spanish but there are still several information panels written in English.

Tumblr’s French translation has a lot of untranslated English text interspersed, including some huge date and time format failures.

Screen Shot 2015-01-27 at 17.47.14

There are three mistakes here:

  • the (numerical!) date is written in the American ‘month/day’ order, which is always wrong in French – if you want to say 17 October, it would be 17/10
  • there is a 12-hour time stamp of 6:55am – French uses the 24-hour time format and the time should be written as 6h55
  • ‘ven’ (short for ‘vendredi’ or ‘Friday’) is capitalised. Days of the week are not capitalised in French. I’m surprised Friday was even translated to vendredi!

I’m not sure how many people actually use the French translation of Tumblr, but even so, if you’re going to translate your website, make sure your text is translated. The ‘archive’ page on Tumblr has a similar problem, with completely untranslated month names – it should be ‘janvier’, not ‘January’, and the date format is again wrong for French. (I’m starting to lean towards recommending against using the US date format at all if you plan on translating a website, instead using the unambiguous ISO date standard, since it seems to be a revealing error in translations.)

Their newest UI change, where recent activity is shown by clicking on a thunderbolt icon in the top bar, has a similar problem with mostly untranslated text. Dates are shown in English (using the Month Day, Year format), as are phrases like ‘one week ago’. Again, the date format is wrong for French.

Mozilla’s Firefox add-ons page seems to have the same problem as Tumblr:

Screenshot of a user profile on the Mozilla website. All the text is in German except for the date.

Most of the text is in German, except for the date, which says ‘Benutzer seit [translation: User since]: July 9, 2010′. The date should be translated into ‘9. Juli 2010’. The bottom bar, where the copyright section is located, has more untranslated text:

Botton navigation bar on the German Mozilla add-ons site. Copyright notice and 'Report Trademark Abuse' are in English. Text isn't aligned well.

‘Report Trademark Abuse’ and the copyright notice have not been translated into German. Not to mention, the assumed word length for some of those words is too short for German.

This is frustrating, because Firefox gets top marks for the sheer amount of localisations available for it; it’s too bad that Mozilla’s centralised websites aren’t up to scratch.

Something similar occurs on Behance, Adobe’s online portfolio website. If you set your language to French, there’s still a lot of English text throughout.

If your translation to another language or language variant is incomplete, then add a warning letting the user know that they may come across text that’s in a different language. That seems more thoughtful than trying to use a website or application in Chinese, only to have lots of text interspersed throughout in another language. When you change to a language that isn’t available in OS X, the operating system will warn you that menus and applications won’t be available in that language. Etsy did something similar with their Russian translation – if you chose Russian, it told users that it was a beta and that some English text would still be there.


Apple, Internationalisation, Localisation

Apple’s inconsistent internationalisation

Apple’s work towards internationalising their products has been incredibly inconsistent. There are some glowing examples (primarily in iOS and on regional Apple websites), but there are some places where their efforts could be improved, particularly on the desktop and on iCloud.

(most recent update: 8 August 2018—many of the complaints in previous versions of this article have been rectified, though there is still room for improvement.)

iOS: Mostly good   iOS comes in a wide variety of languages and dialects – in fact, its language selection is more comprehensive than that of OS X. The user interface and Apple-made apps are designed to reflect different languages, cultures and regions and it’s clear there’s some effort at making sure their apps are culturally sensitive. Even English-language applications change based on what iOS language and region format you’ve chosen. On Pages for iOS, if your OS is set to UK English and Region Format UK, you can create envelopes whose addresses list cities, counties and postcodes instead of cities, states and ZIP codes and CVs instead of résumés.

Regional websites The same attention paid to iOS itself applies to the iOS 8 marketing websites on regional versions of – at least for selected languages. In the iOS screenshots, many regional pages show app screenshots in the same language the copy is in, so the German screenshots show German text, featuring people with typically German names. The same applies to France, Thailand, the UK, Australia, Italy and Brazil. There are even subtle differences between language variants for some countries – Mexico and Spain have different copy and screenshots. The UK and Australia have slightly different names and time formats (UK with 24-hour time and Australia with 12-hour time). The Japanese, Korean and Chinese pages go even further, changing both the people in the photos and the text. (And they don’t use the same East Asian people for China, Japan and Korea either.) Every page is written in the appropriate language or dialect though – there’s no English on the Spanish or Thai page. Even the Canadian page uses Canadian spelling.

This is all really impressive work and Apple deserves credit for paying so much attention to their international iOS user base.

Apple starts losing their touch after a while, though. The English-language Indian page uses the same time format as the Australian screenshots, but the same text and people as the British one. The Swedish, Dutch, Romanian, Portuguese, Polish and Russian pages use the same images as the North American pages. New Zealand uses a mixture of the British and American screenshots – and ‘Favourites’ is written incorrectly (for New Zealand, anyway) in the penultimate screenshot (though it’s written with a ‘U’ everywhere else), but Control Centre is written properly for NZ. A similar issue appears with Taiwan, which uses a combination of the Chinese and North American screenshots. Canada’s is identical to the US page, except for the spelling in the copy (‘favourite’ has a U).

I can give Canada a pass, since there isn’t a specific Canadian English user interface in iOS. But that doesn’t apply to the non-English-speaking countries like Taiwan, Poland, Portugal, Romania, Sweden and the Netherlands. All those languages are available in iOS. For India, they could have included photos of Indian people at the very least. Some of these mistakes were easily avoidable, though – no American spellings or Month/Day/Year date formats should have appeared on the New Zealand screenshots, and English of any variety should not be on the Taiwanese page at all.

Verdict for iOS: There has been some painstaking work put into these internationalisations and I’ve got to give them credit. But there are a few blunders here and there that keep it from being perfect – at this point, though, they’re second only to Google. But their efforts are far and away ahead of Microsoft – and Apple’s own OS X division.

OS X: You tried? Let’s compare this with OS X, which is more like Microsoft in the 90s, making the minimum effort.

Simplified Chinese is the only language for which OS X sample screenshots have been localised. That’s right, the screenshots for other languages and scripts like French, Dutch, Russian, Greek, Japanese, Portuguese, Spanish, Thai, German, Traditional Chinese and Korean are still in English. Even if they use non-Roman letters like Thai and Russian. The copy is written in the right language (or dialect, in the case of English-to-English ‘translations’), but that’s what everybody expects. Nobody expects to go to a website designated for the Italian market to find English copy written there. Even with the inconsistencies on the iOS pages, they’re much better than OS X. I do give Apple credit for careful localisation of each page though – you won’t find American spellings and vocabulary littered across the UK or Australian pages (unlike Microsoft) or strings of untranslated English text on the French page.


(As of MacOS High Sierra, Hindi is available as a UI option.)

The situation isn’t much better in the OS itself for some languages. OS X is not available in Hindi. Yes, Hindi. One of the largest world languages out there. Hindi is available under Windows and iOS as of version 8. Windows has a wider variety of world languages available, including African languages (Swahili, Xhosa, Zulu and many more) which are completely unrepresented in OS X, with the exception of Arabic.

For a point of comparison: Windows’ language list (as of Windows 8.1) is here.


(Please note that the following section on language variants will soon be outdated; MacOS is finally starting to rectify this problem and will be including British English, Canadian French and Australian English in the next major release. —FG, 8 August 2018.) 

The only English dialect available for the UI is American. No British, no Australian, no Canadian, no Indian. They can’t even be bothered to change the spelling (how hard is it to add a ‘U’ to the Favourites sidebar? it took me a few minutes), much less modify the vocabulary – no ‘Bin’ for Trash for a hypothetical English (UK) version, for example. The same applies to apps (with the sole exception of iTunes, which is localised for UK English) – sample documents in Pages for iOS change based on the English dialect you’ve chosen as your default. Addresses can be composed of city, county and postcode for the UK, and cities, states and zip codes for the US. You’ll only see cities, states and ZIP codes on Pages for OS X. That cultural sensitivity doesn’t exist on OS X – apparently the US is the sum total of the English-speaking world.

This is a backward and parochial stance. Windows, once notable for steadfastly ignoring English dialects other than American, has had an installable British English version for the past two years. English is spoken outside the United States, where it didn’t even originate. How can you be so thoughtful on your websites and in iOS, but not at all in OS X? They do the bare minimum: spellcheckers and date format options, but not the actual user interface. This is like Microsoft in the 90s and early 2000s.

French suffers from the same problem as English, though unlike English only the European variant is available. Canadian French is available on iOS, but it’s not on OS X. In Apple’s defence, though, they’ve introduced Mexican Spanish to Yosemite (before, the only Spanish available was Peninsular Spanish – this is recognisable by the use of ordenador to refer to a computer, rather than the Latin American computadora). This is the first time a subset of a Latin-script language (there are multiple Traditional Chinese versions available) has been added to the OS where most of the differences concern vocabulary and sentence structure, rather than larger differences like Brazilian and European Portuguese.

It’s becoming more common to offer multiple subsets of languages, especially in mobile operating systems. The idea that there is One Dialect To Rule Them All (and in the darkness bind them!) is quickly becoming passé. Unfortunately, Apple isn’t the leader here, despite their forward-looking reputation – they’re well behind Google, Microsoft, Facebook, Twitter, Pinterest, Etsy and other US-based tech companies. As I said before, they’re the 1990s Microsoft in this regard.

Verdict for OS X:  What are you doing, Apple? OS X needs to gain parity with iOS. If you’re going to try to bring the platforms closer together, you should add more languages and dialects, including Hindi, Canadian French/Québécois, UK English, Australian English and Indian English, since these languages and dialects are already available for iOS.

Update, 16 May 2015: Apple’s inconsistency in internationalisation persists. According to Multilingual Mac, the Apple Watch will be coming in much fewer languages than iOS. This may present a problem for people whose iPhones sync with the Apple Watch, but don’t have the iPhone set to a language available on the Apple Watch. Languages like Portuguese, Russian and Hindi are notably absent from this release – it seems to be mostly a handful of Western European languages, Chinese and Japanese.

Update, 25 May 2015: Brazilian Portuguese, Thai, Turkish, Danish, Dutch, Swedish and Russian have been added to the Apple Watch, according to Multilingual Mac. Most of these are European languages (or a South American dialect of a European language), but it’s good to see Thai added.

Update, 23 October 2015: iWork for iCloud, despite having been out for two years, still does not support British English spellcheckers. If you don’t write US English, you’re a second-class citizen. If you’re part of the rest of the English-speaking world, stick with Google Docs. European Portuguese speakers are similarly left out for now. 

Update, 8 August 2018: Apple is becoming more consistent. In the upcoming MacOS Mojave, the operating system will include British English, Canadian French, Australian English and a second Traditional Chinese localisation geared towards users in Hong Kong. While this is less extensive than the English options available on iOS, it’s a major improvement. 

Internationalisation, Localisation

Remember that languages have multiple variants

(updated 20 October 2018 to remove outdated information)

Regional differences can include vocabulary, spelling, accent or script. I’ve noticed this primarily with English, Chinese and Portuguese – developers think, probably unconsciously, that US English, Brazilian Portuguese and Simplified Chinese are the only versions of those languages that exist. Admittedly these are broad user bases, but there are still people in other Portuguese-, Chinese- and English-speaking countries who may very well appreciate having their dialect represented. In the case of English, between one-third and half the native speakers use ‘Commonwealth’ (for lack of a better word) English forms (that is, colour is written with a u, centre is written with the r before the e and the ‘l’ is doubled in some verbs like cancelled, labelled and travelled). Apart from the US, Philippines and Liberia, every other English-speaking country, including high-population ones that use English as an administrative language like India and Nigeria, uses a form of Commonwealth English. Large companies’ ignoring Commonwealth dialects may come across as arrogant or wilfully ignorant, especially if that ignoring extends to spellcheckers and displayed dates.

If your team has the time, money and people available to handle this, including multiple variants of a language is a good idea. Microsoft and Apple learned this lesson with Windows 8 and MacOS Mojave. If you are a large company and want to use the word Favourites for a bookmarking system, you’ll want to create versions that reflect both common spellings of this word. Smaller companies have fewer resources and may not be able to maintain multiple translations, but that’s not an excuse for Microsoft or Adobe to do the same thing.

If you’re a developer from an English-speaking country outside the US, for instance, you don’t necessarily have to cater only to the American audience by spelling words differently from your normal style without offering a version that reflects both your dialect and the dialect of many of your users. There are customers outside the USA who may appreciate their local dialect being included. If you take the entire Commonwealth plus Ireland into account that’s over a billion people. Many of these countries, like India and Nigeria, have other dominant languages, but administrative and academic English usually follows a British-based standard.

The same applies to Chinese if you’re familiar with both Traditional and Simplified Chinese scripts. There are Chinese-speakers outside the People’s Republic of China and Singapore.

And in the case of Portuguese, there are enough differences between European/African Portuguese and Brazilian Portuguese that it helps to offer both if you can. Users of Blizzard Software have complained about a ‘Portuguese’ version for Portugal that is written in Brazilian Portuguese, making it difficult for Portuguese users to understand. Offer both if you can – don’t claim to offer something only to have it not meet the criteria.

It’s especially annoying when you encounter only US English, Brazilian Portuguese and Simplified Chinese as options in an application, but the same application offers Canadian French and Swiss German along with French and standard Hochdeutsch. English has a much larger user base than Swiss German, and the spelling differences between Swiss German and Standard German are similar to British, Canadian and American spellings.

And if you claim to offer a localisation in a specific dialect, be sure it’s actually in that dialect. You don’t want to have an app that claims to be in Serbian Cyrillic only to have portions of it written in Latin letters, or something supposedly in Swiss German that uses the spelling standards of Germany and Austria. If I choose English (UK), I shouldn’t see a Favorites panel or a Help Center . For example, in the British English version of Windows 8, most spellings and terms are changed (so I have a Favourites panel in Windows Explorer), but they left some words like Accessibility Center (sic) unchanged. Luckily, Microsoft corrected this to Centre in Windows 10.

If free and open-source software products can offer different language variants, so can paid-for software projects. Microsoft and Apple have billions of dollars each. Surely they could afford a localisation team. The Gimp, for example, has at least two English versions available, as does LibreOffice. If you’re an open-source project, explicitly allow multiple language variants if people are willing to work on them. Even some commercial software projects allow users to contribute languages via platforms like Transifex.

If you do not have the resources to make multiple variants of a language, avoid using contentious words as much as possible. If you want to use a bookmarking system, use words whose spelling does not change, like Bookmarks, Liked or Starred rather than Favourites. On a more casual site you could abbreviate ‘Favourite’ to ‘Fave’, thus avoiding the problem of variant spellings. There are some technically ‘British’ spellings that are secondary variants in the US (but American spellings tend to be acceptable only within its borders, at least for native speakers). For example, you might want to spell cancelled and cancelling with two Ls, theatre with the -re ending, and grey with an e as a compromise.’


Write language labels in their own language

(Edit, 24 Oct 2017: included Dropbox as a good example of what to do)

When creating language selectors, make sure the language labels are written in that language, not the language the page is currently on if it differs. For example, on an English-language web page, German should be written as Deutsch, not German. This makes it easier for people to find their own language. Someone browsing a website that defaults to Japanese and wants to find German may not know that ドイツ語 means Deutsch. But if the link says Deutsch they will be able to recognise it. Wikipedia uses this strategy when labelling languages in the sidebar – if you want to find Czech, you just need to find Čeština. Also, make sure the languages are alphabetised by their own name, not by their names in English or another language.

Example of what to do:

Screenshot of Dropbox language selector

Dropbox writes language labels using their own names, so German is Deutsch and Indonesian is Bahasa Indonesia. (They also get a few other things right too – they label all dialects for English, Chinese and Spanish and include indicators for Norwegian and Portuguese as well. Flags are not used to represent languages. The languages are alphabetised according to their own names, not their English names. The Ukrainian translation is a beta and is marked as such.)

Example of what not to do:

A drop-down menu with a language selector. The UI language is set to French, but all the language names are in English.

This is a screenshot from SquirrelMail, a popular webmail web app that comes installed with many hosting packages. The language chooser has all the languages listed in English (except for Malay and Indonesian, for some reason), regardless of whether the UI language is set to English or not. If I speak Arabic and want to find it in a list, I don’t want to search for the English name.


(language drop-down or unordered list)

Internationalisation, Localisation

Label all dialects of a given language

(significantly updated 20 Oct 2018)

If you are an American developer, don’t label your dialect as simply English when referring to the British, Australian and Canadian localisations as British English, Canadian English and Australian English. I specifically mention American developers – and English settings – because a) this is an English-language document and b) I’ve noticed this tendency from US developers more often than I have others. It’s not just English though; I’ve come across it with Portuguese and Chinese too. Label them all; you’re less likely to cause offence or annoyance to people who don’t speak or write the dialect you consider archetypical. Major software companies like Apple, Google and Microsoft typically do this right. For example, on most Google products and current versions of MacOS and Windows, you can’t just pick ‘English’; you’d have to pick a specific kind.

The unmarked-dialect problem can happen inadvertently when a company starts with their local dialect and later adds others. For example, Twitter has a generic ‘English’ (American) and ‘British English’ (added a few years ago). It would make more sense to add a label to the default English afterwards and call it English (US). Pinterest, Dropbox, Facebook and Apple retroactively added United States labels to their products after adding other English localisations.

Again, this isn’t just about English. If your software is available in both Brazilian and European/African Portuguese, don’t label the Brazilian version Português when you’ve labelled the European version Português europeu. Label them both, or only label Brazilian Portuguese. I’ve noticed the ‘local dialect as default’ with North and South American variants more than I’ve seen with with European ones, however, with the exception of French.

If you are going to leave a language unmarked, make it the originating country’s dialect (British English, European Portuguese, the French spoken in France, Simplified Chinese – but call them English, Portuguese, French and Chinese) and mark the local variants (US English, Brazilian Portuguese, Traditional Chinese, Canadian French, Swiss German). Better yet, label them all if you offer multiple versions of a language.

It’s not necessary to label a language if only one version of it is available unless

  • It’s likely to cause confusion, especially when the language is written in multiple scripts or there are mutual intelligibility problems between two subtypes of a language. This can arise with languages like Portuguese, Chinese and Serbian. If date formatting varies within a language, only offering one date format can also be confusing.
  • The lack of options reduces the usability of your site or application for writers and speakers of other subtypes of a given language. An example might be a website that only offers an English spellchecker that works in the United States, but nowhere else.
  • The ideal choice would be to add the missing options, but that’s not always practical; development teams have limited time, money and other resources. The next best thing is to recognise the fault and make it clear that you’re not just pretending that these other populations don’t exist.

    The OS X spellchecking language selector: four versions of English, French, German, Spanish, Italian, Dutch, two versions of Portuguese, Danish, Swedish, Russian and Polish all labelled in their own languages.

    Fig. 1: Marking all dialects
    A good example from Apple’s spellchecking options in OS X. Every language is listed in its own language, despite the computer’s interface language being set to English (Dansk, Deutsch, Español, Italiano, Nederlands, Svenska, Français, Polski, Português, Русский) and all the regional variants for English and Portuguese are marked.

    Language selector, listing German, Spanish, French, Hebrew, Italian, Brazilian Portuguese, Russian and US English (with no other variant available).

    Fig. 2: Unnecessary dialect label for English

    Above is an example of what not to do with English. Since there are no other dialects of English included here, there’s no need to label it. Just label it as ‘English’ unless you have more than one version available or if there’s some feature of the application that would make it difficult for users of other English variants to use, like spellchecking. If I see English (US), I would expect to find, when clicking the list, other English variants, only to be disappointed. The Portuguese label is OK.


Dealing with gender on websites

The best solution is actually the simplest: just avoid requiring your users to pick a gender, either by omitting gender as a field or making it optional rather than required. But if you want to include a user’s gender as an option, the most inclusive way of handling it would be to allow genders other than the binary ‘male’ and ‘female’ options, even if it’s just ‘other’. Sarah Dopp has written a very helpful guide for developers that can help them create more inclusive gender selectors. You can also use the SGOSelect menu as a model for creating gender-inclusive dropdown menus.

Some popular websites like Tumblr don’t even ask for a gender, which hasn’t had a negative impact on the popularity of the site. Older websites, however, like Yahoo and AIM, still demand that you should choose from two binary options, with no ‘decline to state’, ‘other’ or write-in options to choose from. Forcing people to choose a binary gender can be alienating or offensive, especially to people who don’t identify with the gender binary or see themselves as being gender-fluid. It can also be a violation of privacy; many women prefer not to identify themselves as women online because of the potential for sexist bullying and sexual harassment. (And if you’re forcing people to choose a gender because of advertising, you may just be displaying things based on gender stereotypes, a problem Sarah Dopp has also mentioned in her article – ‘not every woman likes baking, and not every man likes cars’. There are men who collect dolls and women who restore classic cars. Single fathers who wouldn’t mind having diapers/nappies advertised to them, but childfree butch women who would. People are complicated.)

If you do include a gender selector, there is no need to restrict it to ‘male’ and ‘female’. It’s becoming increasingly common for web services – even advertising- and data-driven ones like Google – that require a gender to be selected to choose a neutral option. Google services offer the ‘other’ gender option, which isn’t perfect, but it’s still better than having to choose from the binary options. Facebook introduced a variety of non-binary gender options in 2014 on their English-language sites (both US and UK). Livejournal and Dreamwidth offer ‘other’ or ‘unspecified’ options. Flickr has offered ‘decline to say’ and ‘other’ options for years, though their parent company, Yahoo, has never included an ‘other’ gender option.

And whatever you do, don’t call your gender selector a ‘sex’ selector.

Internationalisation, Localisation

Make the relationship between location and language flexible

While you’ll find most people in a location may prefer the most commonly spoken local language (or languages) or dialect of a particular language, there may be exceptions: members of a minority language group, immigrants, expats, members of the armed forces, civil servants, language-learners or people who may simply prefer another language.

A lot of non-native English-speakers have grown used to setting sites to English-language options because of poor or confusing translations. Of course, your priority should be to improve your translations, but if your users want to see your English page despite them visiting from a country with a different primary language, let them see your English-language pages.

Some websites are not very flexible, but offer one or two common regional languages. Some only offer one. There are even websites that ostensibly sell to countries with multiple languages, but offer only one language (like websites that sell to Switzerland and have only a Swiss German option with no French or Italian available). Switzerland has four official languages – but according to Apple, Ebay and Paypal there’s just one, German. Something similar happens to sites that target Belgian customers and only offer French, even though a slight majority of the population speak Flemish and there is a German-speaking minority.

In order to access eBay in a different language (or dialect) other than the one (or ones) associated with your country, you need to use a different country’s eBay site. You can’t visit a Spanish-language eBay site and have prices default to US Dollars or Pound Sterling.

There are lots of reasons why someone might want to have modular language and currency settings:

  • An Australian working in China: English (Australia), Chinese Yuan, China
  • A Chinese person working in Spain, paid in Euros: Chinese (Simplified), Euro, Spain
  • An American Japanese-learner in the Netherlands, who has a US bank account: Japanese, US Dollar, Netherlands
  • A Romanian working in Italy, being paid in Euros: Romanian (Romania), Euro, Italy
  • A German working in Singapore, being paid in Singapore Dollars: German (Germany), Singapore Dollar, Singapore
  • A British expat working temporarily in the US, being paid in pounds to a British bank
    account: English (UK), Pound Sterling, United States

An example of a site that allows for flexibility is Etsy. You can choose any country listed on the site, which is a separate setting from your language and currency. It also shows you which settings it’s derived from your IP address and your computer’s language settings, and asks to confirm them.

A screenshot of the language, location and currency selector on Etsy. It says English UK, US Dollar, United States.

In this screenshot, Etsy has cleverly detected my preferred settings: English (UK), US Dollar as a currency, and US as a location. As you can see, I’m not bound to choose English (US) or Spanish (if I’m lucky) or French or Chinese (if I’m really lucky). I can choose Dutch or Russian if I like. If I happened to have an overseas bank account I could change the currency from ‘US Dollar’ to ‘Euro’ (to give an example).

Websites and operating systems that don’t offer this facility, despite the existence of other language translations for the website, make lots of assumptions about the users and their habits. They may fit for some people but there will always be exceptions and allowing for that possibility may make your customers or readers happier because of your thoughtfulness. A way (for web apps) to base language preferences on what the user prefers, rather than what you think they might prefer, is to use the language their browser is set to in order to determine the display language.

Internationalisation, Localisation

We’re not all living in America

Despite what some developers seem to think, the entire world does not constitute the USA. This section is specifically targeted towards American software companies and online businesses (though the nature of other sections can apply to them as well, and I’ve seen some non-American companies that make the same mistakes) who market their services outside the US, but the lack of attention given to internationalisation makes their products less useful for non-American users.

  • Do not require a US ‘zip code’ (postcode) as a condition of signing up to your site. Say ‘postcode/zip code’ – and don’t make it mandatory for all countries, as some countries don’t use postcodes.
  • Do not require a ‘state’ if your site is meant for people in various countries. Not every country is divided into states (or provinces).  Japan has prefectures. France has departments. Some countries just don’t have any administrative divisions that would be used in an address. Requiring states may put people in a state of frustration.
  • Do not put ‘United States’ at the top of the list of a country selector if you plan on having users from outside the US. If you plan on targeting users from English-speaking countries in general, you could put a group of English-speaking countries on top – like a list that has the US, UK, Canada, Australia, India, New Zealand and Nigeria at the top. A Spanish-language website could list countries like Spain, Mexico, Argentina, Guatemala and Colombia first.
  • Do not force the ‘Month/Day/Year’ date format on English-language users, especially if it’s written numerically. Most people in the UK, Australia, India, South Africa, New Zealand, Ireland, Nigeria and every other English-speaking country that is not the US, Canada, the Philippines or Belize will not want their dates to be formatted that way. All these countries use the Day/Month/Year format. Either make the date format flexible or detect the user’s date format based on their language settings, like Github.
  • If your website offers an English-language spellchecker and you plan to have users outside the US, you must, at the very least, offer British and Canadian English spellcheckers. Otherwise you will have very frustrated users who have words like ‘colour’ and ‘centre’ treated as mistakes when they’re not. There are open-source spellcheckers for all major English dialects. Include them or just get rid of your spellchecker. If you can only be bothered to offer an American spellchecker, you are being thoughtless. There is absolutely no excuse. The same applies to Portuguese and German – a German-language site may get users from Switzerland, and there are significant differences between Portuguese and Brazilian Portuguese. An example of this thoughtlessness is the Prezi site, which only offers an English (US) spellchecker. iWork for iCloud also has this problem.
  • Don’t make English (US) a hidden default. Base spellcheckers and other settings on what the user has chosen. Word processors should open documents in the user’s default language if there isn’t already a proofing language associated with the document already. This is particularly obnoxious when the user has set their operating system to another language entirely.
  • If you need bank account information, don’t ask for a ‘routing number’ if you plan on selling outside the US (or Canada, for that matter). The ‘routing number’ has other names in other English-speaking countries, like ‘sort code’. The name for a transactional bank account can vary too – it can be a ‘current account’ (UK), ‘checking account’ (US), ‘chequing account’ (Canada – note the spelling) or ‘cheque account’ (UK and Australia).

What not to do:

System Preferences

In OS X Yosemite, I can’t search for the option to ‘customise’, but I can search for ‘customize’. The common spelling in the UK, Australia, New Zealand and Ireland (and amongst many speakers in India, Nigeria and other countries where a variant of Commonwealth English is an administrative language) is ‘customise’. OS X should allow for both spellings. At least OS X is better than Prezi, though, who can’t even be bothered to include spellcheckers for English dialects other than American.

(Update, 20 October 2018: This particular Apple problem has been eliminated with the release of MacOS Mojave.)

Further reading:
American Computing Assumption