Apple, Internationalisation, Localisation, Microsoft

Respect users’ spellchecker settings in MS Word exports

This is kind of arcane, fiddly technical stuff, but I’ve run into enough problems with this issue that I thought I’d write about it.

Anyway, people are complicated. So are the ways they use spellchecking, especially if they’re multilingual, expats, travellers or language-learners. Unfortunately, MS Word export functions in a number of MacOS and cross-platform applications don’t get the subtleties of language and dialect. I’ll use myself as an example, since I’ve been experiencing some frustration with how word processors handle language. My system-wide spellchecker is set to British English and always has been. My Mac’s interface has been in English, German and French; currently, it’s in French. My iPhone and iPad are set to English (UK).

All MS Word documents exported from Pages whose language is set to English under Advanced Settings will use the US spellchecker when I open them in MS Word, even if the region format is something else like UK. This is because Apple’s Word exporter parochially sets all English-language documents to US English, specifically using the en_US tag. I looked at the XML file associated with a test document and saw this for myself. I’m guessing it was an oversight rather than an intentional slight, but it’s still annoying because it comes with potentially unwarranted cultural assumptions. Pages should add explicit dialect preferences in the drop-down menu to make sure users get the spellcheckers they want. Oddly enough, all documents that I import into Pages use my system’s British spellchecker – American spellings and foreign words get red underlines. It seems that Pages recognises my system settings when I actually write in the app, but not if I open the exported file in Word.

I’ve also had issues in which MS Word documents that I wrote in English, with an English-language MacOS spellchecker, opening in French on others’ computers because some applications like Ulysses and TextEdit use their own UI’s language when exporting to MS Word format. These applications use the UI language to determine which language should be set in a .docx file’s associated XML settings. Applications that use the MacOS text engine should be able to tell that I write in English because of my spellchecker, even if I operate my computer primarily in French.

Also, when documents are created without a default language, Microsoft Office opens them in the language the user interface is set to, even if your default spellchecker is different. Because my computer is set to French, documents without a specified XML language open in French on MS Word. This is the reason why users of British, Australian and Canadian spellcheckers frequently have issues with documents erroneously opening in US English – Microsoft has never created a British, Australian or Canadian UI localisation for MS Word, meaning that the hidden default is always US English if you use the English-language interface even if your default spellchecker is set to something else. LibreOffice has the same problem.

I know that many companies think of conventional use-cases first, but there is a good case for anticipating less conventional use-cases too. For example, many non-native English speakers will set their UI to English and use spellcheckers in their native language. I’m the opposite; I’m a native English-speaker who sets my UI to either French or German and uses spellcheckers in English. In any case, it’s good practice to recognise a user’s spellchecker or spellcheckers when setting languages for documents or portions of documents, instead of assuming that a user’s UI language is always the same as their working language, or that there is only one valid dialect of a language.

Adobe, Apple, Date and time, Google, Internationalisation, Localisation

Date-formatting problems from Adobe, Apple, PayPal and Google

Some of the most irritating cases I’ve seen with hardcoded date formatting come from large, well-resourced tech companies that should theoretically know better: Adobe, Apple, PayPal and Google come to mind. I wouldn’t be surprised if Microsoft did similar things, though I use more Adobe, Google and Apple products. As a user of non-US UI region formats and languages, I frequently encounter problems with date and time formatting. The Month/Day/Year format is not portable. It should not be the default. Never default to Month/Day/Year, and never hardcode date formatting. As soon as you localise your software to something other than English (US), it’s backwards. Developers should default to the ISO standard Year/Month/Day format and derive settings from users’ set region format or language, prioritising region format.

Adobe products, both on the web and on the desktop, have a long-standing and pervasive problem with hardcoded US date formats regardless of the language the app or website is set to. I’ve mentioned the problems with Behance, but it’s not limited to that site. The document setup screens on Photoshop, Illustrator and other Adobe applications all display dates in the Month/Day/Year order, even if you’re set to a different language. I use Photoshop and Illustrator in French. The names of the months and days change to French, but the dates are in the wrong order and the 12-hour clock appears. France does not use the twelve-hour clock. A Month/Day/Year date should never appear on any applications on this computer; my UI language is set to French and my region format is a customised one with a Day/Month/Year preference. I’ve brought it to the attention of the Adobe team, but I haven’t seen any changes yet.

Screenshot of Adobe Illustrator's welcome page. My language is set to French. Dates and times appear as MDY with 12-hour clocks.

On the App Store, Apple thinks that your shipping address or credit card company takes precedence over your own region settings if they differ. Everything related to the App Store shows US Month/Day/Year dates, even though my region format is set to UK. The Mac App Store is even weirder. The Available Updates section shows the Month/Day/Year date format, even if you’re logged into a UK account. The correct Day/Month/Year format shows under Purchased and Updated, though. Most Apple apps pick up the correct date format, though. Also, some features in the iWork apps prioritise the UI language over the spellchecker’s language. Just because I have the UI set to French doesn’t mean that I necessarily want dates to appear in French in Numbers, since my spellchecker is set to English. I’ll still take French dates over a date format I didn’t choose though. At least I picked French as my UI language.

PayPal’s settings are just as asinine as Apple’s. Because of my account location, I’m still treated to Month/Day/Year dates and the 12-hour clock, despite my phone being set to display Day/Month/Year dates and a 24-hour clock. I tweeted PayPal support about the app overriding my settings. The representative told me that date and time settings are based on your account location, not your phone or computer settings. This is silly. How difficult is it to respect a user’s settings? iOS and Android make it possible for apps to detect date formatting using their own protocols.

Date formatting in Google search is dependent on the region they’ve detected for your search results. Before they changed all the top-level domains (,,, etc) to deliver local results based on your detected IP address, the site you chose determined your date format. I’ve been using for years because it shows dates in the sensible Day/Month/Year format. When I noticed Month/Day/Year formatting on, I wondered what was going on, since it contradicted my language settings. I found out that I had to go into search settings to switch my results to UK in order to bring back my date formatting preferences. This makes it harder for me to get local results. Why can’t I get local results and have my language and date/time format preferences? Other Google products, like Docs, Gmail and YouTube, correctly use language and dialect, not physical location or regional result settings, to determine date formatting.

Accessibility, Android, Google, Internationalisation, Localisation, Typography and fonts

Doing things right: an inclusive tech showcase

I’ve shown you many examples of people doing inclusive tech wrong, from large companies like Apple and Microsoft to smaller outfits like the 2Do team. But some people are doing it right. 

Dropbox labels the English, Spanish and Chinese variants when two versions are available, and marks Norwegian (Bokmål) and Brazilian Portuguese because those disambiguations help. All languages are listed using their own names and are alphabetised according to those names, not their English ones. Ukrainian is marked as a beta, indicating that the translation may be incomplete. No flags are used next to the language names. They’ve improved quite a bit since the days when they had an unchangeable US date format when using the English version. 

Dropbox language selector

DuckDuckGo uses flags for countries, not languages. Also, they realise that languages other than German are used in Switzerland – the portion of my country selector shows Italian and French options for Switzerland. Similarly, the United States has both English and Spanish options. DuckDuckGo’s options also allow users to change the UI font for the search engine, and there are several options available: the default Proxima Nova, Helvetica, Arial, Verdana, a few other system fonts and a free-choice box that allows you to choose something you have installed on your system. Some people benefit from using different kinds of fonts in the UI, so this is good for accessibility. 

Screenshot of DuckDuckGo with a country selector.

The Hoefler & Co type foundry has a section where the designers showcase their typefaces in action, called DiscoverTypography. One of the showcases includes a series of tips about making apps more usable for multiple users. I doubt the sample would work well with a screenreader, but if you can access the page, you’ll find advice about making apps usable for colour-blind people, using visual hierarchy to improve understanding, and avoiding filling apps with unnecessary text to make localisation easier. 

Google’s Noto font family, developed by Monotype, is designed to accommodate 800 languages and 100 writing systems within a single font family. Emma Tucker wrote an exhaustive case study about the work the design team put into ensuring that the fonts would accurately reflect people’s languages, culture and history. 

Apple, Internationalisation, Localisation

Apple parochialism in action – doubly inappropriate naming

Does anybody else see the problem with this? Note that my operating system is set to French. 

Screenshot of an 'iMovie Theatre' icon. Theatre is spelled the American way...and my OS is set to French!

There are two problems with the name of this iMovie feature. First, my system is set to French and this feature should have a French name – or a name similar to a French word – in the first place. But the problem isn’t limited to French. This name is a problem in English too. The place where you watch movies in many dialects of English is called a ‘cinema’ – ‘theatre’ is restricted to the stage and is always spelled theatre. In Canada, it’s called a movie theatre, with the R before the E as in every other primarily English-speaking country outside the US. The -er spelling is especially insensitive – it’s not spelled that way in other English-speaking countries, and even many Americans spell both the cinematic and live variants as theatre.

Calling it a theatre is also inappropriate for most languages. The spelling would work for German, but das Theater refers to live performance; the place where people see films is called das Kino. Most western languages disambiguate between live theatre and film houses. The US and Canada are outliers, and many Americans can’t even spell it the same way as the other English-speakers. 

They could have avoided this self-made localisation problem by calling it iMovie Cinema or something similar. Calling it iTunes Cinema would have avoided English spelling differences and would have made it more appropriate for a wider variety of people. 

What Apple did was probably the worst thing they could have done. 

Android, Apple, Internationalisation, Localisation

What Not 2Do

2Do is a popular project-management and to-do list application for macOS, iOS and Android. Since this app has been widely lauded on various tech blogs, I decided to give it a try after I signed up for Setapp. It’s definitely a well-designed app with a beautiful user interface. It’s clear that the developer obviously put a lot of care into making things work. Unfortunately, there are some localisation and internationalisation problems that should be cleared up in future releases.

This single screenshot from the Mac version shows four examples of practices to avoid when localising and internationalising applications: flags to represent languages, incomplete translations, text boxes that don’t accommodate the text that has already been translated, and forgetting that English has multiple variants.

A screenshot of the preferences window in 2Do.

Flags for languages. 2Do includes a language selector within the app preferences on the Mac. All the language names have flags next to them. The flags are superfluous. The language selector is clearly marked with Langue (language in French) and there is a list of languages ordered by name.  Most gallingly, they use the American flag for English. This is completely inexcusable, as the developers are based in the UK. Not that I particularly want to see a Union Jack either; flags do not represent languages. I tweeted 2Do and they told me that they’re planning on removing the flags from the language selector. They’ve already been removed in the Android version. But this is something that should never have happened in the first place. The developer apparently hadn’t thought of it that way and was surprised I pointed it out. I think this points to a lot of underlying issues around language, culture and other issues in tech, but that’s a topic for another post.

Stray English in the French localisation. There is stray English text in various places in the app (‘delay sub-tasks by 3 weeks’ at the bottom of my screenshot, for example), especially in the preference window. If you’re offering an app in multiple languages, make sure the text is thoroughly translated. Also, the language names in the language selector are alphabetised according to English order even though they’re written in their own languages.

Text boxes don’t accommodate French text. The text boxes are clearly too small to accommodate French text and have been hardcoded to accommodate the word lengths in the English version. If you expect to offer a program in multiple languages, you should anticipate different text lengths. Languages like German, Finnish and French require more space for words than English or Chinese.

Forgetting that English has multiple variants. Again, inexcusable in this case. The US flag for English is usually a red flag that we’ll be dealing with American developers being insular or developers from elsewhere who feel obliged to Americanise themselves.

It’s not all bad, though – there were several things 2Do did right. I believe in giving credit where it’s due. They used the region-neutral ‘Starred’ instead of ‘Favourites’ when the app is set to English, wrote the language labels in their own languages, made the font size adjustable, included European Portuguese along with its Brazilian cousin, labelled both Portuguese dialects and ensured that their service is available on multiple platforms.

I think 2Do is off to a good start with some of these inclusive tech principles, but the issues with translation and localisation show that some work still needs to be done.

Accessibility, Internationalisation

Brief updates, 5 October 2017

  • MacOS now has Hindi available as of the High Sierra release! I’m wondering if they’ll add other Indic languages in the future. I’d still like to see them adding Welsh, Irish, UK English and Canadian French user interfaces down the line, but Hindi is a major step forward for them. I think much of the inconsistency with MacOS localisation compared to iOS and even watchOS comes from the allocation of resources at Apple HQ; as the iPhone is its top-selling device, most of the language work is done over there. 
  • iOS 11 has considerably expanded its accessibility options in comparison to previous versions. 
  • The Glyphs Mini font-editing app has a lot of stray English text in the French localisation, particularly in the preferences window. Most of the text isn’t even in French, which looks kind of careless. I’ve tweeted at the developer to see if he can fix it in a future update. Remember to be thorough when translating your apps into new languages or variants of a given language. 
Accessibility, Apple, Internationalisation, Localisation

Inclusive Tech Links, 5 April 2017

Adobe, Internationalisation, Localisation

Be mindful of regional date and time formatting

This entry is related to ‘Use flexible date and time formats‘. Every region and language has its own standard for formatting dates and times. If you get it wrong, or assume that only one format exists within a language, then you may end up annoying – or worse, confusing – your users.

What not to do:

Behance, an online portfolio site run by Adobe, seems to have its date format hard-coded to the US ‘Month Day Year’ format regardless of what your language is set to. As you can see here, my user interface is temporarily set to French. The date says ‘Membre depuis le mai 11, 2013′ (member since 11 May 2013). This is wrong for French; it should be ’11 mai 2013’. If you’re going to have non-English text on your site, do not hard-code the month/day/year format. In most languages, the month does not precede the day; they use a logical format from smallest to largest (day/month/year) or largest to smallest (year/month/day). This is from Adobe, not a tiny company run by two people with a lot of work and very little time. We’re talking about a multi-million-dollar company with enough time and resources to get this right.


A screenshot from the online portfolio site Behance. The site is set to French. The bottom text says 'Membre depuis Mai 11, 2013'. This is incorrect for French.

Actually, even if your site is only in English, you should still be careful about date formatting, since the English-speaking world doesn’t use one date format. Britain, Australia, New Zealand, India, South Africa and most other English-speaking countries use the day-month-year format; the US, some of English-speaking Canada, the Philippines and Belize use month-day-year.

Even if your site is going to be used only in the US, there may be the likelihood that your site will be written in Spanish, or in some regions, Chinese, Haitian Creole, Brazilian Portuguese, Japanese, Arabic or another language spoken by a large immigrant population. The same rules still apply: make sure your date-formatting system can accommodate these languages.

Just don’t hard-code month/day/year. It’s culturally insensitive. If you’re going to hard-code any date format, hard-code year/month/day.

AAC (Assistive and Augmentative Communication), Accessibility, Android, Apple, Cross-platform support, Internationalisation, Localisation, Microsoft

Brief updates – the good, the bad and the fascinating

Dropbox has been called out here before for date format foolishness, but they seem to be improving their internationalisation ever so slowly. If you look at the language drop-down, there are two English options now – hopefully that means English date formats will no longer default to Month/Day/Year. (They’ve also done it right by retroactively labelling English US for what it is, instead of having ‘English’ and ‘English UK’.) I want to say Latin American Spanish was added recently too, but I could be wrong.

iOS 9 has added some new language features, including a new Chinese system font, dictation support for more languages, Finnish and Korean spellcheckers, French/English and German/English bilingual dictionaries, improved Japanese autocorrect, predictive text for a variety of languages including Korean, Russian and Turkish, Canadian English and Canadian French user interfaces, and the option to switch between Arabic and Hindi number systems (h/t Multilingual Mac).

OS X El Capitan (10.11) has just added some new Eastern language support features as well, including the same Chinese system font that is now in iOS 9. There’s also new dictation for Arabic and Hebrew. No news of any new French, English or Hindi localisations – it’s Apple’s inconsistent internationalisation, yet again (and out of step with their other products and other operating systems).

Windows 10 had some localisation-related fail during the upgrading process, that required people to set their OS to English (US) in order to upgrade it properly. You shouldn’t have to change your system language in order to upgrade your computer, especially if you don’t speak English as a primary language. Good job, Microsoft. (That was sarcasm.)

Proloquo2Go is now available in Spanish! More info. There are bilingual English/Spanish children’s voices included with the new Spanish localisations, which are probably targeted towards the large bilingual Latino/Hispanic community in the US. (Interestingly, the boy’s voice has a recognisable Spanish-speaking accent when speaking English, whereas the girl’s voice has a recognisable American accent when speaking Spanish.) Adult voices come in Castilian Spanish and Latin American Spanish versions.

People on any region format other than US will not be able to see Apple’s News app on iOS 9 until iOS 9.1 – and I think that’s just for the UK and Australian region formats. (I know people are saying ‘people in other countries can’t see it’, but it’s tied to region format, not geographical location; anybody can set their region format to any country or language they want on an iOS device, and it doesn’t even have to match the UI language. You can set your region format to one language and have your phone set to a different language and your keyboard on another. Remember that when you set up an iOS device for the first time, it asks your language and region separately. I’ve seen screenshots of phones set to English but the region format set to Turkish.)

Skype In Your Language is a community-supported project for Windows and Linux that provides Skype localisations for languages and dialects that aren’t officially part of Skype releases. Not for the Mac, unfortunately – there’s no easy way to do unsupported localisations on OS X.

TalkTablet is an AAC (Assistive and Augmentative Communication) app that comes in iOS, Android and Kindle editions. It’s also available in multiple languages, unlike Proloquo2Go which is only available in English and Spanish.