New Global Gateway for Kyero
January 5th, 2012
What is a Global Gateway?
It’s the industry term for the language selector on a website, and now the main Kyero.com site (not this blog) has a new one.
Here’s what it looks like, and why it looks like it does.
Previously, we had the language selector at the bottom of the home page only. It’s still there in a modified form, but actually it’s always been for the benefit of search engines, rather than visitors.
We relied on Google to direct visitors to the appropriate language version of Kyero.com – but as we’re about to support more and more languages, we decided to separate our strategies for visitors and search engines.
So, now we have a search-optimised selector in the footer (for the benefit of search engines) and a new global gateway in the header (for the benefit of human beings).
When we’re done adding languages to Kyero next year, it’ll end up look something like this.
Looks like a pretty simple device doesn’t it? Fortunately, we had the benefit of John Yunker’s excellent 200-page publication, The Art of the Global Gateway, to guide us – otherwise we’d have repeated most if not all of these 8 Global Gateway mistakes:
- 1. Flag waving
Often, flag icons are used to represent a language – but this isn’t always appropriate. The Swiss flag, for example, can’t accurately depict the four official languages spoken in that country: French, German, Italian and Romansh.
- 2. Poor visibility
It’s common for the language selector to be added as an afterthought to a website – because that’s often what it is. Positioning it at the top-right of the page (or top-left with languages like Arabic and Hebrew) means that visitors can find and use it easily.
- 3. No ubiquity
The language selector should be available on every page of the website, because there’s no telling what page visitors will initially land on.
- 4. No Memory
Some kind of ‘remember my selection’ option is important because we don’t want to force visitors to make a language choice every time they visit. It’s also important that they can change or forget that choice.
- 5. Words are not enough
What happens if a visitor lands on a language version they don’t want? If they only speak Spanish and they’re confronted simply with Pyccĸий, we don’t want to rely on them guessing this means that a better language option might be available.
So, we also include a universally-understood, no-words icon – the little globe.
As an aside, a universal icon for language selection does exist – but we judged there isn’t sufficient awareness of it to make it useful.
- 6. No scrolling
If there is a long list of supported languages, a scrolling menu can be tedious to use. Instead, we opted for an overlay, because Kyero will support almost 30 languages next year.
- 7. Bad choice of labels
Languages should be presented in their native tongue – English, Deutsch, Español – instead of – English, German, Spanish.
These shouldn’t be translated, because visitors who only speak German will be looking for the option to select German in the German language, of course.
- 8. Inconsistent sorting
How to present a list of languages written in different scripts? How to avoid any kind of bias creeping in to that list? Fortunately, John came to the rescue.
He recommends adopting the Unicode Collation Algorithm: alpha sorting Latin-script languages first, followed by:
Greek – Cyrillic – Hebrew – Arabic – Devanagari – Bengali – Gujarati – Tamil – Telugu – Kannada – Malayalam – Thai – Hangul (Korean) – Japanese – Chinese (Simplified) and Chinese (Complex). Phew!
Are we done yet?
This is just the first phase of our new Global gateway for Kyero – and we’ll be improving it as we go along. The biggest thing left to do is language negotiation – automatically (and accurately) directing a visitor to the best-choice language version of Kyero.
There are two ways to do this, and we’ll likely use them both in the future. We can use the language settings of the visitor’s browser and we can infer their physical location from their current IP address, although neither method is foolproof.
Physical location does not always equate to language, and browser settings do not always reflect the language preference of the person using the browser.
Consider someone using a borrowed or shared computer, or using one while abroad, or using one they purchased in another country.
In these, and many other scenarios, neither method of language negotiation will accurately describe their ideal language preference – it might, but it will be based on potentially faulty assumptions.
Even when language negotiation is accurate and successful, we’ll still need to have a default or fall-back option.
What if the visitor is identified as preferring Arabic – but we don’t support that language (yet)?
We’ll need a way of logging that preference (useful information for deciding which language to implement next), and redirecting the visitor to the English language version (probably).
Locale to the rescue
The stand-alone localisation application we developed specifically for Kyero has been invaluable in simplifying the process of adding new languages.
There’s no way we’d even be contemplating a Kyero.com in almost 30 languages without an easy way to manage and translate content.
If you’re a Rails developer, why not signup and start using it? It’s free, and you’ll wonder how you ever managed without it.
We’ll use your feedback to continue to improve Locale, and the localisation process for all Rails developers and their i18n-enabled apps.