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