What is Internationalization?
The word “Internationalization” is often abbreviated to “i18n”, which is a numerym. “i18n” is used because there are 18 letters between the ‘i’ and the ‘n’. Accessibility, by the way, uses the numerym “a11y”.
Following some research and webinars on this subject (thanks @elibelly and the Smashing Magazine crew), this is really a fascinating topic. It’s not new – there are web standards to help regulate it, and infact a whole section devoted to it on W3C here. But in terms of Accessibility, making your website available to all users is a pretty big deal. And that includes more than *just* language choices.
Access to the Web for all has been a fundamental concern and goal of the World Wide Web Consortium since the beginning. Unfortunately, it is easy to overlook the needs of people from cultures different to your own, or who use different languages or writing systems. If you do overlook those needs, you will inadvertently present barriers to the use of your technology or content for many people around the world – and even in your own area.
Did you know that when your website is served to a visitor, your website is adapted to local language and culture in the target market? This is a whole lot more than just translating the language – although that can have pretty significant impacts as well (see my article here about Accessibility). So whether your visitor is in the same province, state or country, localizers will deliver the site based on their location – not yours.
Localization can occur based on your IP address, your server location, and sometimes even your computer’s OS. You know all those cookie notifications that you get on some websites? Localization is part of the service offered by those cookies. Among other things, it can help ensure that if you’re selling a product that’s available only in Europe, you won’t necessarily find it when doing a search from Canada.
Among the many technical elements which can be localized are: date and time formats, currency formats, number formats, address and telephone number formats, units of measure and connection speed.
Localizer Date Elements: 19/01/19 vs 01/19/19
Let’s take just one of those technical elements. Date alone can be enough to make you toss your desk contents in frustration. I published this article on January 19, 2019. So which date format above looks right to you?
If you’re in the US, congratulations. You’re one of the very few countries who use MM/DD/YYYY (month/day/year) as a standard format. Side note: please tell me you’re not using the MM/DD/YY format as I did in my header above for 19/01/19, which is even more confusing. So, you might say I published this article on 01/19/2019.
In most of the rest of the world, the day is written first and the year last (DD/MM/YYYY) – ie., this article published on 19/01/2019 – although in some places like China, Korea and Iran, this order is flipped (YYYY/MM/DD) – or 2019/01/19.
Another side note: Americans themselves can’t decide which format to use, and have waffled back and forth throughout the last 250 years.
First and Last Name Requests
Another example is name fields in contact forms. A pretty standard form in North America asks for first name and last name, and makes those field “required”. We don’t even really think about it. But in some countries, for example Indonesia, the Western naming practice of a given first name and a family last name isn’t used. So, faced with a contact form that requires them to enter something in the “last name” field is confusing and even rude.
And colour of those field entries should be another concern too. Maybe you thought having the font in your contact form show as red because you think it matches your colour palette. But in some countries such as China, Japan and Korea, you should never write the name of a living person in red ink. And don’t be tempted to write this advice off just because your website may not be serving visitors who live in those countries. What about the Chinese, Japanese or Korean (or more!) folks living or visiting in your target area who will see your website?
Left-to-right and Right-to-left
As the W3C guide states: Content developers and content management systems must also be prepared to deal with linguistic and cultural issues. For example, a sentence that is constructed by combining several phrases together in one language may be impossible to translate sensibly in a language with a different sentence structure.
For example, in the Japanese translation of “Page 1 of 34” all elements in the phrase would be in reverse order. Your application must not restrict the order in which these elements can be combined. Specifications for technologies such as widgets and voice browsers should also avoid locking developers into an English-biased syntax for such things as composing messages or firing events associated with text.
Now, some of this is beyond what you might get into if you’re working as a designer using pre-made platforms like WordPress or Shopify. But maybe you need to check and make sure those platforms are doing as much as they can to ensure these accessibility practices are being followed.
But symbols are okay, right?
Goodness, no! Symbolism (just like emojis – have you ever been confused by what an emoji means? They even render differently on different devices!) can be culture-specific. For example, the check mark means “correct” or “OK” in many countries. In some countries, however, such as Japan, it can be used to mean that something is incorrect. Japanese localizers may need to convert check marks to circles (their symbol for “correct”) as part of the localization process.
The point of all this is that design – whether we’re talking about a website, a widget on a website, a web application, or a whole content management system – needs to be flexible enough to accommodate local needs. And to have an accessible website that complies with true #a11y, then #i18n is a critical component.