The web aims to be an inclusive platform, and when it comes to making our websites and apps more comfortable for a wide variety of people, we love to sweat the details: responsive design, accessibility, browser support. But what about the 6,000,000,000 people who don’t speak English? How can we make our online experiences accessible to everyone who speaks a language different to our own?
Let’s explore how the web standards in our toolkit can help build better experiences for people who don’t speak the same language as us. How do you translate videos or SVGs? Which HTML elements and CSS properties are likely to trip us up? How do Flexbox and CSS Grid help us build interfaces that support writing systems that flow in different directions to ours?
This talk will focus on practical front-end advice for localisation on the web – things I’ve learned while making our company’s platform available in 46 different languages – and show how our localisation efforts are a key part of building an inclusive web.
— Diana MacDonald (@didoesdigital) June 21, 2019
The other 6 billion refers to the billions of people who don’t speak English (80% of humans!). Since not everyone is connected to the internet, 25% of internet users are non-English-speakers. In Australia, 27.3% of households are multilingual. This impacts a lot of people and will impact more as more get online.
Jason is monolingual, but he had a project to add support for Arabic in Culture Amp’s product. Initially he imagined the biggest amount of time would be getting the translations done…
Classic string-replacement localisation is a little hard to work with, as you have no real content in the code context. They are looking at a text transformation approach which uses a readable English key and handles translations elsewhere
Who does the translation? There are specialists who do this for you at surprisingly cheap prices (20c/word) and that’s pretty good for UI where the text doesn’t change too much. But if you have lots of content, the price gets much higher. What about in-house or crowdsourced translations? You can use Pontoon by Mozilla to translate in-place which makes things much easier.
— Anton (@antonjb) June 21, 2019
Beware of code in your translation strings! CA hit a problem where the translation also updated a variable name, which broke things. Don’t expect translators to code!
Don’t forget to translate
alt text – it’s a common mistake.
So now you have a great big file full of translations and you want to add some UI and you think “ahh we’ll use a flag!”. But you will almost certainly offend someone. Languages are not nations. There is no flag for Arabic, just as one example. So just use the name of the language.
Next you need to handle writing direction:
dir="rtl" …and browsers are surprisingly clever at applying this, but you will still need to manually update anything not build in flexbox and grid. If you ARE you using flex and grid you’re in luck, as they support rtl out of the box, it’s why we have names like flex start and end.
For older code (which CA had to deal with at the time) you can use SCSS mixins; but now rtlcss.com provides a plugin which is well worth investigating as it does a lot of it for you.
Then… you still have to sort out things like buttons with directional icons.
Localisation maturity model follows the classic scale of reactive, repeatable, managed, optimised and transparent. You should keep in mind that it’s a process to improve from wherever you are.
Let’s try to reach the other six billion!