Localisation, Microsoft

MS Word for Mac Localisation Updates

fg

MS Word for Mac is now available in the following languages:

  • Arabic
  • Czech
  • Danish
  • German
  • Greek
  • English (UK)
  • English (US)
  • Spanish (Latin America)
  • Spanish (Spain)
  • Finnish
  • French
  • Hebrew
  • Hungarian
  • Italian
  • Indonesian
  • Japanese
  • Korean
  • Dutch
  • Norwegian
  • Polish
  • Portuguese (Portugal)
  • Portuguese (Brazil)
  • Russian
  • Slovakian
  • Swedish
  • Thai
  • Turkish
  • Chinese (Simplified)
  • Chinese (Traditional)

The language options aren’t quite as extensive as those on MacOS itself — Catalan, Romanian and Hindi are options on MacOS, but not Office for Mac — but there are more options than there were before, including multiple English, Chinese, Portuguese, Spanish and French variants. The additional English, French and Spanish options appear to be new. UIs are available in right-to-left languages like Arabic and Hebrew, though I can’t speak to the quality of the localisation or the way it handles those scripts.

Accessibility, Android, Apple, Google, Internationalisation, Localisation, Microsoft

Link Round-up, 28 April 2019

fg
Accessibility, Adobe, Apple, Microsoft, Typography and fonts

Accessible Typography: Over 20 Hints to Make Your Site More Readable

fg

I covered this topic more cursorily in an article for NOS Magazine, but I wanted to cover the topic in more depth to help provide web and app designers and developers create interfaces that are accessible to wider groups of readers. While there is no absolute consensus on what makes typefaces accessible, there are some principles worth noting. All the typefaces I’ve listed support Western European languages at the very least, and quite a few also include Greek, Vietnamese and Cyrillic.

Principles of typeface accessibility

  • Low stroke contrast can promote readability. Some typefaces that have low stroke contrast include Myriad Pro, Gotham, Helvetica, Arial, and Verdana. Some fonts have comparatively high stroke contrast, like Bodoni and Didot. Times New Roman has a moderate stroke contrast. Proxima Nova, commonly used on the web, a has relatively low stroke contrast except for specific letters, like “a,” in which it’s relatively high.
  • Disambiguating between easily confused letters can be helpful for some people. For example, in some fonts, capital I and lowercase l can be easily confused, along with the numeral 1.
  • Fonts with open counters (the whitespace between the strokes in letters) can sometimes be easier to read.
  • Sans-serif typefaces, like Helvetica, Arial, and Trebuchet MS, are thought to be more readable on screen than seriffed typefaces like Times (New) Roman or Palatino. Seriffed typefaces have little “feet” on the edges of the letters.

Continue reading “Accessible Typography: Over 20 Hints to Make Your Site More Readable” →

AAC (Assistive and Augmentative Communication), Accessibility, Android, Apple, Internationalisation, Linux, Localisation, Microsoft

Link round-up, 27 August 2018

fg
  • 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.) 
Apple, Internationalisation, Localisation

UK English spellchecking issues in the MacOS Mojave beta

fg

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. 

Apple, Internationalisation, Localisation

New Localisations in MacOS

fg

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. 

Apple, Internationalisation, Localisation, Microsoft

Respect users’ spellchecker settings in MS Word exports

fg

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.

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

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

fg

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

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

Doing things right: an inclusive tech showcase

fg

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

fg

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.

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.