Upgrade to Pro — share decks privately, control downloads, hide ads and more …

When in Rome, speak…maybe not Italian?

When in Rome, speak…maybe not Italian?

A talk about i18n that Raquel Moss and I gave at Droidcon London 2019.

With a diverse, global base of users, how do you decide which language to use to present content to your user? Location makes sense, right? Romans speak Italian, Osakans speak Japanese, and Ohians speak English. Simple!

Except that you know it’s not like that. Everyone knows there’s Vietnamese people living in Rome, British people living in Osaka, and Argentinians living in Ohio—such is life in 2019.

So why do so many companies solely use location to determine things like language, currency formats, and other important internationalisation features? It’s a frustrating experience for users, and the tools exist to do much better.

In this session, you will explore some examples where companies are getting it right, some examples where companies are getting it very wrong. You will also discover some suggestions on how you can improve the experience in your own apps.

Kai Koenig

October 25, 2019
Tweet

More Decks by Kai Koenig

Other Decks in Programming

Transcript

  1. • Language • Location • Locales ◦ Number and Currency

    formats ◦ Reading direction ◦ Date and Time formats i18n TERMINOLOGY en_US or en-US ???
  2. • Language • Location • Locales ◦ Number and Currency

    formats ◦ Reading direction ◦ Date and Time formats i18n TERMINOLOGY zh-Hans-SG
  3. • Sent by the browser with every request • Gives

    weighted values for each accepted language • Every browser handles this differently • Browsers usually set this initially from the system language THE ACCEPT-LANGUAGE HEADER
  4. CLIENT DRIVEN CONTENT-NEGOTIATION Client English German Danish Thai /en /de

    /da /th Engli sh Ger man Dani sh Thai /en /de /da /th Client
  5. • Make an initial choice based on the Accept-Language header

    (server driven) • Allow a reliable override with a language selector (client driven) USE BOTH
  6. • Be guided by your framework • But stick closely

    to Content Negotiation if you can DYNAMIC & MULTI-LANGUAGE
  7. • Dynamically set the locale based on ◦ Stored preferences,

    if logged in ◦ TLD or subdomain (example.es) ◦ Path (example.com/es) ◦ Accept-Language header DYNAMIC & MULTI-LANGUAGE
  8. • Don’t roll-your-own algorithm for figuring out which language to

    serve up • ….but if you do, RFC 2616 is what you’re looking for to guide you DYNAMIC & MULTI-LANGUAGE