Inclusive Tech

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:

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

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:

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:

‘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.

(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.’

(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.



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.



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.

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.

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.

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:

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