Apple removes flags from macOS

The latest version of Apple’s macOS, Monterey, has removed one of the longest and most prominent examples of using flags for languages: on the macOS language selector.

New language selector from macOS Monterey without flag

New language selector from macOS Monterey

The new UI is purely text, whereas previously flags were shown in this selection screen since macOS’s release in 2001.

Previous OSX language selector with flag icon

Previous macOS language selector (Source: BusinessInsider

Given macOS supports hundreds of languages (and regional variations), this change radically simplifies the macOS language selection UI and also removes the requirement for Apple to maintain flags to match each language. It also makes this a simpler option for both users and Apple, and also one that no longer confuses languages with flags.

Revolve and G-Star Raw: country and currency selection and appropriate use of flags

What if a user visiting an e-commerce site wants to change the language of the site? Or the currency? Thinking about currency, the main reason a user would change currency is because they’re viewing the site from another country. So often currency and country selection are very closely tied. Language, however, can be less straightforward. Countries like Belgium, Canada, Singapore and Switzerland may have multiple languages but only one currency.

Revolve approach the scenario of languages and currency in a rather cumbersome way: they have a separate currency selector and language selector.

Revolve language and currency selection

First and foremost, and this is why this example has been used in this particular post, Revolve has bizarrely ended up with the flag of the United Arab Emirates for German. Probably a simple mistake but another reason why using flags to signify languages can lead to embarrassing mistakes like this one. The other choices of flags in this menu imply country selection over language: for example the Brazilian flag for Portuguese and Mexican flag for Spanish.

How many users are likely to browse the site in Chinese and want to see prices in Russian Rubles? Probably very unlikely. How many users browsing the site from Mexico want to view the site in Spanish but see prices in Mexican pesos? Probably a lot more, but while the Mexican flag is used for Spanish, Mexican pesos is not an available currency.

Thinking about the scenario of changing currency it would be most closely linked to the country of the user. And the country of the user would of course also relate to language. This is where the G-Star Raw site provides a far simpler UX solution that uses flags correctly.

It asks the user to specify their shipping destination and their language from a single dropdown option:

download-10

This is a far simpler approach that also uses flags appropriately.

Even if Revolve didn’t want to focus on shipping destination and just give a user the ability to view different currencies and languages, they could do so very easily by following the same approach as G-Star Raw and avoid these issues with flags.

ISO language codes and country codes don't mix

In 2012 I wrote about Deezer mixing up ISO country codes and languages codes — specifically Montserrat for Melayu and as a result using the flag of a small English-speaking Caribbean island for the Malay language. (Deezer has since replaced their flags and languages with a simple list of languages presented in their native name).

I recently spotted a similar set of mix ups on a plug in for accessibility and translation from Recite me used on sites such as London’s Gatwick Airport.

recite-me

There are some curious flag choices made for representing languages: such as Andorra for Catalan. With a population of around 80,000, there are are fewer people in Andorra than the seating capacity of Catalonia’s largest football ground, FC Barcelona’s Nou Camp (almost 100,000 people).

Traditional Chinese is represented with China’s flag while it is far more commonly used in Taiwan (where Simplified Chinese is rarely used).

The Indian flag is also used three times — for Hindi, Tamil and Telugu. However, Gujarati does not have an Indian flag: instead it has the flag of Guam. Galician also has the Greenland flag.

This is where checking your country codes and languages codes is very important: the two-letter ISO language codes for Galician (GL) and Gujarati (GU) are the same as the two-letter ISO country codes for Greenland (GL) and Guam (GU) respectively.

However, by far the strangest combination of flags and languages here is the first one: Afrikaans is shown with a Saudi Arabian flag. Another mix up possible with the “SA” abbreviation of South Africa (where Afrikaans is spoken) and Saudi Arabia?

Confusing language and country codes is one pitfall of using flags to represent languages: another is the added onus of having to ensure you’re actually using the “right” flag (and determining the “right” flag is also full of pitfalls).

Had this language selector used a simpler approach with just language names presented in their native name and script then mixing up and even confusing flags wouldn’t even be an issue.

Bioware's Canadian English

Computer game companies seem to be repeat offenders when it comes to using flags to represent languages: Bethesda and Steam have both been featured on this blog (but to their credit have since removed their use of flags for language selection).

However Canadian-based game maker Bioware has really set the bar high with this almost comical use of flags for languages:

Bi

Perhaps unsurprisingly Bioware are based in Edmonton, Alberta and not French-speaking Québec.

Babbel.com: regional language variations and flags

Babbel

Babbel show the Brazilian flag on their site for their Portuguese language lessons. Obviously they’re teaching Brazilian Portuguese — so what not actually emphasize that without just relying on a flag (and of course having the added confusion of a Brazilian flag with ‘Portuguese’ underneath).

This blog has discussed the confusion and annoyance that using flags to represent languages can cause. If you look at Babbel’s YouTube channel you can find many examples of this — and specifically in regards to their Portuguese being Brazilian Portuguese.

comments

This really shows the importance of specifying what regional variation of language you’re referring too — and are flags enough to do this? And yet again, are they even appropriate?

memegenerator.net and overcomplicating language input

memegenerator.net really does what it says on the box: lets users generate memes with a variety of templates.

But it has a really annoying feature: you must select a language (English, Russian, Spanish or other) first. If you don’t select a language, an alert pops up with a meme demanding “Y U NO SELECT LANGUAGE?” — see what they did there? Meta-meme!

memegenerator.net

This sort of validation is incredibly annoying. And for what point? Does this have to do with special characters? Considering you can paste Spanish and Russian text and select “English” and still get a correctly rendered image, it appears not:

memegenerator.net
The only reason I can think of for this is to save the meme and present it on different language sections of the website. That’s solely for the benefit of the site and not for the user. So it still remains an awful user experience (and not to mention the use of flags for languages).

A far better experience would be simply defaulting the meme language to whatever language the site is currently being viewed in and allow users to switch between English, Russian and Spanish. If a Russian user arrives on the site in English, wouldn’t they prefer the Russian language version? There’s even a language switcher at the bottom.

It’s a great example of a bad way to overcomplicate language selection.

Case study: onefinestay.com and dropdown language selection

ofs-main

Key lessons learned (the TL;DR version):

  • users are easily able to find translation links in footers
  • language names work well at communicating links to translations – but only if the user is familiar with that alphabet (for instance, as English-speaking user won’t recognize Chinese lettering if Chinese is the current language)
  • the use of flags do not aid users more than listing language names and using other iconography for selectors
  • be careful when using online remote testing. Careless participants can skew your outcomes

onefinestay is a holiday/vacation rental service with a difference: it aims to give you the chance to stay in someone’s place while they’re out of town and “live their life”. They consider themselves an unhotel.

Currently they operate in four cities: New York, Los Angeles, London and Paris. While most of their users are US-based, they receive significant traffic from users who speak French, Spanish and Portuguese.

While their site is currently only available in English they are looking at providing localised versions. This is especially important considering their service in Paris which is only available through an English interface. Working with their Product Manager Matt Isherwood (a former colleague of mine), we started to discuss what the best way to present multiple languages on the site would be. User testing these approaches was the obvious way forward.

The first design aimed to integrate language selection as a sub-option within a user management dropdown represented by a user icon (see below for screenshot). This would also contain other site settings such as currency and other account information.

Using UsabilityHub for super-fast remote testing some interesting outcomes and insights were discovered.

The test? Prior to seeing a screen, users were given the following instructions:

While looking for a place to stay in Paris you find this page. Where would you click to view a version in English?

Test users would then see a full-screen mock up of a onefinestay page translated into French in which hopefully they would be able to find a way to navigate to the English-language version of the site.

onefinestay

Partial screenshot of test screen

Iteration one: user icon

onefinestay

Would users associate changing language with this icon? I was concerned the task of changing language was too far removed from the sort of user settings this icon usually represents. In a more application-focused product it might (think Twitter or Facebook: language settings are found in user menus). But on a website which doesn’t require logging in why should a user need to access anything under a user management menu – unless, of course, they are logged in?

The first ten tests confirmed this concern. Only one user out of 10 interacted with the icon. However, the remaining 90% (nine users) scrolled to the bottom and found the supplementary language links there.

First lesson: users appear to have no problem finding translation links in footers.

Iteration two: nounproject translation icon

02ofs

Translation icons come in several varieties but the unofficial convention on these icons tie together an eastern character (often Chinese or Japanese) with a Latin equivalent (usually the letter ‘a’). One such variation found on the nounproject icon library site combines with convention with speech bubbles to create a fairly strong icon for translation.

Would this perform better? I expected it too but wondered if the context of the action wasn’t quite right. This icon feels more suited to the action of translation (think Google Translate or a language dictionary) rather than selection of a site-wide language.

Whether it was context or another factor – and this is where quantitative testing can still leave us in the dark – the icon still failed. It performed better than the icon but only 30% of users interacted with this element (four in total).

However, yet again the remaining 70% users (six total) still found the supplementary links at the bottom of the page. Our first lesson had been reinforced but the menu was still struggling.

Iteration three: globe icon

03ofs

The globe icon can, unfortunately, be extremely vague. On Facebook – which arguably shapes the visual meaning of this icon immensely — it functions as a notifications icon (although as John Yunker points out, it’s probably one of the best choices for a translation/localisation icon).

Would be global/international meaning work well with the context of this task? It worked better, but still not great: 50% (five users) interacted with it to change the language (and yes, yet again the remaining 50% of users found the language links at the bottom of the page).

While 50% is an improvement, it’s still not satisfactory.

Iteration four: language names

04ofs

By this point I was concerned the premise of the dropdown was also being lost. So I integrated a downward triangle to better communicate the presence of hidden options below the icons.

By adding a text label for the current language in French (and in French – Français) would this be obvious to users?

03ofs

Click map showing user clicks from user testing.

The results were promising. To be better sure of these results statistically, I bumped the test numbers up to 20. The success percentage still remained excellent at 95% (19 users). And the one user who didn’t interact with the menu? They also found the English link at the bottom.

This appeared to be a winning option.

Second lesson: perhaps unsurprisingly, language links work very well as language links.

While both the onefinestay design team and I were against using flags for language selection, this seemed an interesting opportunity to test whether flags do indeed signpost language selection any better.

After adding a French flag to the drop down, I repeated the test on an another twenty users. The result? Identical. 95% found the menu link and the other single user still found the footer link.

05ofs

Third lesson: flags don’t appear to add any extra advantages to this approach.

So we appear to have found a winning formula? Not quite.

What if onefinestay adds a Chinese option to their menu and we change the task slightly: you’re in Shanghai trying to find a place to stay. By following the same approach, this is what a user would see:

07ofs

(This is not dissimilar a problem recently faced by Anna Kay on the Mozilla site. On her blog she describes being unable to find a language chooser due to all the text on the site being in Chinese).

Based on what I’d seen on the Mozilla site — and Anna’s own testing — there was not much point testing this.

So time for two more tests: one using icons and the other using a flag – just to test our two best performing variants. The globe icon so far had performed the best so I used this along with making the language label blue to give it some more visual prominence – the flag variant already had this thanks to the red of the Chinese flag.

The test script obviously needed to change for this, so the following scene was set for test users:

While looking for a place to stay in Shanghai you find this page. Where would you click to view a version in English?

06ofs

Click map for the globe icon dropdown

08ofs

Click map for the flag dropdown. The red dot shows a user hitting outside the hit area trying to find a link to English content

The results from these tests were far less black and white. A small percentage of users (5-10%) could not find the links at the bottom or the dropdown at the top in either test variation. The lack of Latin characters seemed to add an extra layer of confusion on the task.

With the success/failure rate between both test variants ebbed and flowed. At 20 tests each, the flag variant performed better by only two successful user tests — but success rates for both were below 60%. Was this statistically proof enough to show the flag variant being more successful? Not really. In fact statistically both designs looked flawed with such a low success rate (caveat: even if the flag was performing better, I’d still be very weary using flags in this situation for numerous reasons).

However raising the test number to 30 gave a more positive outcome for both: yet again both hit a 66.6% success rate. Only one user on the globe variation failed to find the dropdown or footer links, whereas two users failed both on the flag variation — the remainder found the translation links in the footer.

Again, our third lesson was reinforced: flags don’t offer any much more assistance to users.

With users finding language links in the footer, I wondered whether a dropdown was even necessary. So in the final test I tried a variation of the Chinese page with only links to translated content in the footer.

09ofs
Click map showing users expecting to find language selector in the top right area

Only 50% out of ten users tested found the footer links in this test: and the clicks shown above strongly suggest that users expect to see some sort of language switcher in the header.

There was a fourth lesson I learnt from this form of testing: one or two careless users can radically skew these results. Along with blowing averages out with poor response time (always be wary with averages: any decision based on an average should only be taken after analysing the full data range) an errant click can easily cast doubt on certain designs.

Unlike a face-to-face test, you can’t guide a user either: if they don’t understand the question then your hypothesis can suffer from whatever action they then take. Distinguishing genuine failures from clicks from test users who don’t care and just want to get through the test can be very tricky. But these outliers can skew your results and should be discounted where possible (and replaced with supplemental tests).

So in conclusion, if you’re planning on implementing a dropdown language switcher, consider the following: