The Other 6 Billion

(upbeat electronic music) (audience clapping) - All right, thank you, everyone.

Yeah, so reaching The Other 6 Billion, the six billion people who don't speak English. Clearly the title of my talk is hyperbole, there are only 4,383,810,342 people connected to the internet, last time I checked.

So, it's a little bit of fake news, but I said it to get attention.

One of the things I love about an event like this and about working in this industry is that the web is inclusive.

And as people who build the web, we obsess about inclusivity and about sweating the details.

We look at things like can I use habitually to check if the features that we want are supported by the browsers that our users use? We realise that not everyone sits at a giant office desk, that a lot of people are checking things on their phones and on laptops, on touch pads and so, we design for different contexts and keep that in mind and we've built entire work flows around this and we realise that not everyone's got the same abilities as us in terms of what we can see, what we can touch, how we can move.

So, we think about accessibility and localization is another one of these ways of thinking about people who might be different to us. In this case, a lot of people,

the other six billion people. So, only 20% of the planet is

able to speak English and even fewer of those it's their first language.

But, well, you might go, well, how much of the world is already speaking this? The stats are 75% of all internet users speak English. Anyway, the web is perhaps more inclusive than we realise already.

More and more people are already using the internet around the world and we should be thinking about them. I'm aware at an event like this, not everyone is building something that's global.

A lot of you might say, but my audience is just Australian, I work for an Australia company, we're focused on an Australian market, it might be worth looking at the languages that are spoken in home according to the 2016 census.

English only is 72.7%.

Is that lower than you might've expected? So, there is, yeah, 27% of households are speaking other languages.

They might be speaking a mix, but that's worth thinking about.

Next on the list is Mandarin at 2.5% and then Arabic. So, they're quite large numbers of people.

So, it makes business sense to actually be thinking about it.

Perhaps Australia is more inclusive than we realise too. For this reason, you start seeing government websites and needing to think about multi-lingual support, at least for certain parts of their content. We see businesses like airports that have to cater for audiences moving through.

You might even be building a website which is explicitly English only.

I think someone from the ABC is here.

Users might go and translate that using built in browser tools.

You don't know what people are doing with your content and if someone wants to do something weird with your website you should let them, make it available to them. So, I work for Culture Amp.

We're a company that is a people and culture platform. So, we do employee engagement surveys and performance review processes in any way people are giving feedback to try and improve the culture of your work.

We have companies all over the world and we have to support our product in 46 different languages.

So, that's quite a bit and I asked our product analytics people to dig up some stats on how many people are actually using it and while most of our users are still English, the majority of our accounts are multi-lingual.

So, the accounts have a requirement that these companies, they're global and if we're going to serve them, we need to serve their employees as well, so it needs to be available in multiple languages.

So, 52% of our accounts, but the thing is, they're the most important ones.

Those 52% of the accounts make up 72% of the revenue. So, almost three quarters of our revenue is coming from people who need support in multiple languages.

It's really important.

So, I'm going to share a story about how I've gotten into this.

But, the big disclaimer is, I'm mono-lingual. Like most Australians, I only speak English which I kind of wish that I had have stuck at Indonesian when I was in high school, but I dropped out. But, I don't have the skills to do any of these translations myself.

When we translate stuff on our website, I don't have the ability to read it and know if it's correct.

I don't even know if the stuff I've got on the screen is correct, so apologies if anything is in your native tongue and it makes no sense at all.

I hope it doesn't, but we'll see.

But, I'm going to share a story because about a year ago I got put on a team or my team got placed with the responsibility to add Arabic support to our platform.

At this point, we already had about 40 languages we were supporting, but two really important ones for our customers which we hadn't been able to do were Arabic and Hebrew.

So, we started with Arabic.

It was a giant ice cream company, an evil multi-national ice cream company.

Anyway, they had an office in the middle east and they wanted to listen to what the people in that office had to say.

So, we started and I was like, surely the slowest thing about adding a new language is ordering the translations.

Now, if you've never done multi-lingual support in an app before, the way it usually works is you have a file which has all of your strings.

So, in this case, we have an English file and it's got all of our global nav menu items in it. So, it's got dashboard surveys, reports, action plans. It's got all of those words in English, and we pull those out of our code, so that's one neat file that we can send off to translators.

And then in our code we reference that file. So, we say, get the value for global_nav.dashboard and pull it up in whatever the user's current local is.

And then once the user views the page, instead of a translate function or instead of it saying global_nav.dashboard, it say dashboard. It pulls the value out of the English file and puts it in. So, if we had an Arabic file that had all of the translations for these words, it would come through and the users would see what they need to in their language.

The disadvantage of that is your user interface begins to look really weird and it's hard when you're looking at code to understand what's there.

What is global_nav.dashboard? You have to change context, go look at a YAML or a JSON file to understand what that text is and it's a little less nice to work with.

So, a different approach which we're hoping to adopt is using automatic extraction. So, there is a webpack plugin.

There's also different ways to do this.

You can do it with babel or other things.

But, in this approach, you have your English text in your thing, but you just wrap it in a function. So, you can call the function whatever you want but we called it T in this case for this example. So, you can find any string and you go, I want to translate that and you just wrap it in a function and it makes it really easy to take an existing English only page and just wrap the necessary bits and all of a sudden you're able to translate it.

That plugin will then go and generate a JSON file which has your text.

The key is the English version and then the value.

In our case this is the English version of the file, so it comes up there.

But, then when we send it off to translators, they leave the key intact and they translate the value. So, that's a different approach which I think has some upsides, also some downsides which I won't go into. So, we have that. We have our files ready to go. Who does the actual translation? No, we don't use Google Translate.

I have relied on Google Translate very heavily when I'm trying to understand what I'm looking at in things that have come back to me.

But for the most part, software companies use services which do the translating for you. There's a bunch of different services to choose from. They all have advantages and disadvantages. Their pricing varies a little bit in the platform costs but for the most part when it comes to actually doing the translations, they have an army of translators out among the world and they do it at about 20 cents a word.

So, if we were to translate the full UI for our platform, that's about 9000 English words. This is in US dollars.

So, the price comes in just under $2000 US dollars to translate that.

Now, what happens if you order a $2000 translation and then you update a button label? Do you have to pay for another $2000 translation? Almost every single one of these providers has a feature called translation memory where you could order $2000, you can order 9000 words worth.

If you change one word, the next translation update you get, they'll just change that one word and it will cost you 20 cents.

So, that's how it usually works.

For us though, we don't just have user interfaces, we also have content.

So, we don't just take surveys of customers and do performance review processes and the go, it looks like your culture's terrible, sorry about that.

We have all these action inspirations that try to show you ways that you can improve what's going on at work and try to inspire the people at your work to change their practises and make the culture improve.

So, if we were to translate all of that, that's 67,000 words and all of a sudden it's getting a whole lot more expensive and you have to start thinking about how we're going to maintain this and which languages we're going to support. So, we're still in the process of figuring some of this out.

What about if you do in house translations or you want to crowd source translations? What if you're a big enough company that you actually have people in the offices you're targeting and they speak those languages and you want to take those? Or if you're an open source project like Mozilla, like how do they organise to translate Firefox into so many languages? Well, Mozilla had that problem, so they built this tool called Pontoon which lets you solve this.

So, if you've got your own translators, you can use this as a translation management platform which lets you translate all of the words in the context on the page and see it demoed.

It's all open source.

It's really cool.

So, if you are crowd sourcing or you're using in house, that's a good way to go.

So, after this, we've got a giant file full of Arabic translations and that's one of the several files we've got translated.

So, at this point, we're good to go, right? We load it in, everything's fine.

Well, just a quick warning.

Some of our things, we've been a bit lazy and we'd started to mix some HTML into our translation strings. So, we've got some paragraphs, there's a link in there with like a Ruby variable and then stuff happens, things happen.

And then when we got it translated, in this case it's not Arabic, this is Hebrew, so different translation. When it got translated, something went wrong. Can anyone pick what it is? That link.

So, there's a variable interpolation going on there which was supposed to point to a variable called link. If we were to run this now, rails would throw an error. So, any time someone chooses the Hebrew translation and gets to the page where this happens, rails would throw an error and say unknown variable that. The lesson here is don't expect translators to code. Let your translators do the translating, let them be good at understanding the right way to phrase a sentence in their language.

Don't mix your code up in there.

There's different approaches for doing that. While on this little aside, I've got another one. Translated images.

This is something you have to think about.

Here's like an example empty state from our design system. The empty state has someone who's looking a bit lost. This is the image, the English version of the image. Now, I want to show you the Arabic version. Can anyone pick what changed? I think I heard someone say that.

The alt text.

That is correct.

A lot of the time, I've heard from one of my friends who's an accessibility auditor, this is one of the things people forget to translate.

So, if someone is using a screen reader or if they're on a slow connection and the image fails to load, but they're using the Mandarin version of your website and you forgot to translate that, that image and that alt text is completely meaningless to them. So, we also need to wrap that, translate that. So, thank you for indulging me on that little aside. We've got our giant file.

Now we want to make it available to users.

We had a local picker that used to look something like this. So, we go, okay, we need to add Arabic to this. We need the flag.

So, we just need to get an image of the Arabic flag.

The only problem is, there's no country for Arabic. The flag of the Arab league is like saying the flag of the G8.

It's meaningless.

It doesn't mean anything to anyone.

About the time we ran into this problem, we also got a customer say, we're about to launch a global engagement survey and have it in seven languages. When we were getting it tested in Vietnamese, some of our employees said they found the Vietnamese flag offensive because they were refugees from Vietnam. Is it possible to replace the flag with another symbol or just say Vietnam? Basically, the lesson here is locals are not nations. Locals are something people speak, nations are a political thing.

You're almost certain to offend somebody if you use flags. So, we got rid of the flags.

And then we added Arabic to our thing.

Users can choose Arabic.

How is it looking? Hey, almost everything there has worked.

There's a few bits of English that have snuck in that we need to make sure we're translating. But, that's looking pretty good, right? Well, there's something that we need to talk about, which is writing direction.

Anton hinted at this before, but not every writing system travels in the same direction as ours.

Some move left to right like we do.

You go left to right and then move down the lines. Some move right to left like Arabic and Hebrew do. Some can go in multiple directions.

I believe Japanese can ... I don't understand how that works but it can move left to right or up and down. I'm not sure.

But, for Arabic and Hebrew, they can't run left to right like we do.

So, they have a HTML attribute called DIR or direction. That lets you change it from left to right, to right to left and reverse things.

How does this actually work? If we've got four paragraphs here, we've got two versions of the sentence in English and two versions of the sentence in Arabic. The numbers`are the same.

Their numbering system is the same as ours. So, here, we've got English, forcing it in left to right and English in right to left and then Arabic. How do you think this is going to display? Is it going to completely reverse every character and end up in gobbledygook? Not quite.

Browsers are pretty smart at ignoring that attribute when they need to and putting text in the way it's supposed to go.

There's a thing called the uni code bi-directional algorithm and one of my co-workers Seb had the unfortunate experience of having to read that document. But, they know that B and A and S and E and D are characters that move from left to right and so, when they find those, they can run the characters one way or another.

But, when they hit an Arabic character, they can go the other way.

Numbers run left to right as well.

But, can anyone see what has actually changed between the English versions? The full stop is right at the start.

That's because full stops aren't necessarily one direction or the other.

Most punctuation could be right to left.

It could be left to right.

So, the algorithm doesn't know and it relies on your hints that you put in your HTML attributes to put it in the right spot.

So, if you were reading the English version and the direction was wrong, it's still legible but it's weird.

This is what happens if you have the Arabic version. It's kind of legible but it's weird.

So, you want to give the hint to the browser of which way it should be going.

So, I've actually like put some arrows here that show the way the text direction changes. So, when it's all English, it just moves straight from left to right, but when you put the direction wrong, it's like it tries to go right to left but it's just finding a big chunk of left to right text. So, it does that first and then it goes, okay, now that I've finished that, and gotten to something neutral like a full stop, i'm going to go back right to left now.

So, then it goes and puts it on the other side. It gets really confusing once you start mixing numbers in there, the directions go all over the place. When you start to try and do this in an editor, this is me just holding down the right button. So, if you go and you're trying to select something or you're trying to move that variable somewhere else, then I hold down shift and left and yeah, you can see what it's doing.

Yeah.

I do enjoy that moment in the Simpsons and it reminds me of our current political discourse. The way this works isn't just for the actual text. The BBC does a great example of this.

This is their Brazilian site.

It runs left to right because that's the way Portuguese runs.

And then their Arabic site flips.

So, it's not just that the writing direction is changing with the text, but you'll notice the side bar has moved.

So, I'll go back, the side bar's on the right. Side bar's on the left.

Also up the top, the logo used to be on the left, now the logo's on the right.

That's something we want to try and achieve. So, before we had ours with everything running this way and to actually change it, we set the direction at the top of our HTML page, we change it.

Sorry.

This is what I was saying.

This is if English was forced to face the wrong way around. So, Arabic facing the wrong way around.

To them, it would look like this English version looks to us.

It's kind of like you can get by but it's weird, the graphs seem to be the wrong way.

It's abnormal to have the navigation there. If you look down the bottom, this kind of notification that's there.

This is where you've got the punctuation beginning to go weird.

So, we set our direction and then see how it looks. Incredibly broken is the answer.

So, we have the left to right version on the left. We have the right to left and like our side bars and everything got completely messed up.

There's icons floating underneath other things. It got all kind of just muddled.

We had someone go through and find all of the things that needed flipping and all of the places where it was changing.

And then other things worked perfectly fine. Like this modal came and everything flipped perfectly. Why? Because of Flexbox and Grid.

Flexbox and Grid have built in right to left support. So, it's called flex-start and flex-end for a reason, because in left to right, the start is on the left and the end is on the right.

And then it flips.

So, you have a modal like this which has like a row reverse because we want the primary button to sit on the right hand side, even though the source sort is different.

And then when we add it in another language and change the direction, everything flips, the direction of the primary button flips, all of that. Pretty good.

Built in support, so make heavy use of Flexbox and Grid. In our case, we had this for accessibility reasons, for keyboard accessibility reasons, we had a fixed margin on the left and then that menu was positioned absolutely.

We've changed our whole layout now, but at the time, this is how we did it and to fix it, we started using sas mixins. So, here, you can see like there's the position absolute and we used a margin left, but the problem is once we flipped everything, that needed to be a margin right, not a margin left.

So, we created a mixin called margin-start and it just does margin-left by default.

But, if it detects the direction is in a right to left environment, it flips everything.

We did similar things for a line start.

So, it flips text align left and text align right. Only two days ago did I see on Twitter that this exists, rtlcess.com, which is a post CSS plugin that does a whole bunch of this stuff for you.

So, I might've done it slightly differently if we did that. But, once we sorted that out, it worked.

One of the only things we've got left now is imagery and icons.

So, before, I kind of joked about the alt text, but there is an icon wrong on this page and it's that little arrow in the button.

It's supposed to be facing forward but, because the writing direction is left, it's actually facing backwards.

So, the button has something like next in it and it's going the wrong way.

The reason is, the icon says, chevronRight when it really should be chevronLeft or right, depending on the direction. You could try and do a chevronForward with some CSSSVG magic to do it.

That doesn't work if you're treating the SVG as an image or you're using like a shadow dom.

So, it didn't work for us, but that is something you can also try and do.

Once you sort that out, you've got it moving and everything's working.

So, where are we at? When we ordered this Arabic translation, we didn't have any repeatable process.

We had a customer say we really need this so we were reactive and we went and we ordered it. But, as I said, two days later, the interface has moved on, buttons and labels have changed, new features are added and we needed to order it again. So, we needed a repeatable process and so we've worked on setting up scripts that work with our translation provider's API and get all of that done.

But, then we're stepping in towards managed where you actually have ways of improving translations based on feedback for customers, ways of ensuring that things are translated within a certain amount of time and optimising it.

So, this is kind of the journey we're on and the people who made this model common sense advisory, they say that no one ever really gets to transparent where you're fully multi-lingual.

Like no organisations really get there.

But, it's a constant journey to optimise and include more and more people.

So, that's where we're at and thank you.

Let's try and reach the other six billion.

(audience clapping) (upbeat electronic music)