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.

[UPDATE, 12 August 2019 – This should no longer be an issue, since both Pages and Microsoft Word for Mac both have UK English UIs. The Zombie American Spellchecker may finally have had a stake driven into it.]

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.