- Off World Girl hosts a number of unofficial English translations (Windows and Mac) for Celsys’ Japanese-language Clip Studio apps.
- The American Federation for the Blind has a good outline of accessibility tools for Windows.
- AFB also has an article on Twitter and accessibility.
- Apple’s developer portal has information on making accessible applications for the Mac, iPhone, iPad, Apple Watch, Apple TV and iPod Touch.
- Scaledrone offers a number of tips and tricks to make iPhone and iPad applications more accessible.
- Android Authority has a list of accessibility tools for Android users.
- Slack has published a multi-year accessibility plan. Here’s a blog entry about some of the work they’ve done on increasing accessibility. (I will say that retrofitting accessibility as they did is probably part of the problem; it’s ideal to build in accessibility from the beginning.) They’ve also recently added three new language options to their apps and website: Brazilian Portuguese, Latin American Spanish and British English. It’s a rolling update, so you may or may not see the new options on your account. They appeared about a day after the announcement for me.
Category: Internationalisation
Link round-up, 27 August 2018
- All the language packs available for Windows 10. Microsoft does a good job at representing Asian and African languages, especially compared to some other tech companies, though I can’t speak to the quality of the translations. Note that some of these languages require English (either variant) to be set as a base language for them to install.
- Google’s accessibility overview for Android developers.
- Over the course of 2018, Microsoft will be adding more accessibility features to Windows 10, including eye control navigation improvements, expanded accessibility settings and new input options for users with disabilities.
- Towards the end of 2017, AssistiveWare added localisation for Dutch and Flemish to Proloquo2Go, alongside English, Spanish and French. After adding these Dutch-language localisations, AssistiveWare made the app available in the Dutch and Belgian App Stores. There’s a good overview of the app on Communiceer (site is in Dutch).
- An overview of the accessibility features in Ubuntu Linux.
- Information about how to make Debian Linux more accessible.
- Online Connections sells an Australian English exclude dictionary for MS Word to force it to allow only preferred Australian spellings. For example, if you want to allow only realise and not realize, entering realize into the exclusion dictionary will treat it as an error. MS Word’s British and Australian English dictionaries allow both –ise and –ize spellings, since both are technically allowed in British and Australian spelling. Matthew Goodall of New Horizons Learning Centres gives instructions for users to create their own MS Word exclusion dictionaries for other forms of English. (Incidentally, I disagree with Goodall that towards and grey are uncommon in American usage; towards seems to be the most common spoken form in all English dialects, and grey is pretty common, too. American dictionaries list them as secondary options, just as realise is listed as a secondary option in Oxford University Press dictionaries for British English, despite its being more common in everyday use.)
UK English spellchecking issues in the MacOS Mojave beta
The quality of the British English spellchecker seems to have deteriorated in the MacOS Mojave beta. Certain American spellings, especially the notorious duo of color and center, aren’t being underlined as errors. In previous MacOS releases, they were. I’ve noticed a similar problem in iOS 11, though it’s limited only to center. This has been a problem for a while – canceled has never been marked as an error, for example – but at the very least the spellchecker was able to recognise that archetypical American spellings should be underlined.
If you find the inconsistency as annoying as I do, you’ll want to download an alternative dictionary instead. This StackExchange thread links to LibreOffice’s British English dictionary and provides instructions for installing it. While the LibreOffice dictionary is somewhat smaller than the pre-installed Mac dictionary, it is more accurate at recognising US spellings and marking them as errors. Another perk of the LibreOffice dictionary is that it allows spellings like realize and organize through. While -ize endings are sometimes associated with North American spelling standards, they’re actually the preferred variant of Oxford University Press, and Oxford dictionaries will always list the -ize spelling first. The default Apple dictionary underlines all spellings that end in -ize.
I filed a bug report with Apple, since I think they may have made some mistakes with the dictionary file. As far as I can tell, Apple’s English dictionaries are based on a US English master file, and the British, Australian, Canadian and other localised dictionaries exclude the American spellings and add Commonwealth ones like colour and fibre.
If you use one of the other non-US English dictionaries on the Mojave beta (or even High Sierra and earlier MacOS versions) and see obvious American spellings being let through without underlining, please let me know so I can update this entry. Tell Apple, too, so that they know to look for the issue in forthcoming releases.
New Localisations in MacOS
In the upcoming OS X Mojave, Apple is finally adding British and Australian English localisations to the Mac after twenty years of only offering an Americanised version. They’ve finally caught up to Windows and their own iOS division!
While iOS still has more English localisations, having multiple options is still better than the lack of choice Mac users have had since UK English was discontinued in Mac OS 9. Apple is also adding a Canadian French localisation and a Traditional Chinese localisation for Hong Kong on top of that!
It’s good to see that Apple is improving their efforts when it comes to localisation. Last year they added Hindi, and two years before that they added Latin American Spanish as an alternative to the European Spanish they’d always had available. I hope that Indic languages other than Hindi, African languages, Welsh and Irish are up next.
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.
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.
On the App Store, Apple thinks that the date and time format of your local store 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.
Update, 23 August 2018: Apple has improved the way dates appear in both the Mac and iOS App Stores. On the Mac App Store’s update page on the Mojave beta, the user’s region format now takes precedence over the user’s local store settings. The Updates section of the Mac App Store now shows the Day Month Year date format for me, even though I’m logged into a US account. Before, it forced the Month Day, Year format regardless of what my actual settings were. Since iOS 11, the app update section has respected the user’s region format. Unfortunately, review pages on individual apps still default to the local store’s settings.
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 (google.com, google.co.uk, google.de, etc) to deliver local results based on your detected IP address, the site you chose determined your date format. I’ve been using google.co.uk for years because it shows dates in the sensible Day/Month/Year format. When I noticed Month/Day/Year formatting on google.co.uk, 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.
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.
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.
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 parochialism in action – doubly inappropriate naming
Does anybody else see the problem with this? Note that my operating system 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.
Edit, 28 April 2019:
There’s been some improvement here. As of 2019, it now says ‘Cinema’ in French, though it’s still a problem on systems set to British or Australian English. Unlike MacOS and iWork, iMovie hasn’t been localised into British or Australian English yet, so the offending spelling/terminology is still there. Hopefully this is updated in a future edition of iMovie that adds the Mojave localisations. Though they seem to be working on it, this is a problem that should have never been there to begin with.
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.
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.
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.