An American Geek in Paris — Chapter 4

On Language, brand, and content

A fundamental difference between Silicon Valley startups (really all US startups) and European ones is how early they tackle internationalization. The US benefits from an enormous market of 330M consumers, most of whom speak English albeit, judging by twitter posts, poorly. There is rarely talk of internationalization in an MVP product. Many companies can go as far as series D or even an IPO without once having to consider anything but en-US (the language code for US-English) in their code. While most smart developers will start building their apps using unicode, locales, and UTC timestamps because modern frameworks make that easy for them, some will blissfully proceed without considering any of those factors.

In one Palo Alto company-based company I joined, all timestamps were stored in “Palo Alto time,” i.e. Pacific, for “efficiency.” This didn’t even allow us to easily account for daylight-savings time but things got really nasty when we installed our software in Europe. What was originally a non-decision during setup of the database for an MVP product turned into a nightmare later.

In Europe the largest single-language country is Germany, with ~83M people. Add in Austria and a good chunk of Switzerland and you’ve got almost 100M native German speakers, all of which are in a single time zone. English is probably the most spoken language in Europe so even though there are only 65M people in the UK the available market for English-language software in Europe ends up being bigger than German. The Nordic countries have been especially strong in software startups (ex: Rovio, Spotify) but these countries are individually so small that English is usually a better initial choice for an App than Danish, Swedish, or Norwegian. To be fair Rovio bypassed the whole language problem by brilliantly starting with a purely pictorial app — Angry Birds (although the name itself is in English).

While a European startup might start development in a single language, sustaining growth will require internationalizing the product earlier than their American counterparts.

Brand

A related aspect of internationalization is the brand itself. One of the most challenging aspects of starting a company is choosing a name, a logo, and a domain name (all the good ones are taken). Startups have little time and money for this and many make exceedingly poor choices. Short, memorable, and international-friendly is good. Long, hard to remember, and explicitly regional is bad. Evocative is good but if you’re too evocative you may have a hard time branching out into adjacent markets. Apple was evocative at first because of apples and school (American imagery) but Apple was not so evocative as to pigeon-hole the brand into the education market forever.

Brands that are synthetic words (again: Rovio, Spotify, but also of course: Cisco, Pixar, facebook) start off life already internationalized. Many of the world’s biggest brands have short English names because they started in the US and by the time they went global they were already well known, ex: Coca-Cola, Google, Amazon.

When growing by acquisition it’s easy to pickup new regional brands that are relatively well established in a given country. When the acquirer is not well known you can end up with a multi-brand, multi-language, multi-country line of products. Things get really messy.

I’ve been in this situation a few times now. The inexorable arc that successful companies follow is to converge on a single global brand (at least for a given product line). With few exceptions, regional brand names eventually die or wither. Regional managers will argue vociferously about the in-country strength of their brand name, their heritage, and the company culture that is wrapped up in the name — recall the original struggle they went through to come up with it! In reality people tend to overestimate their regional brand equity and are merely fighting a delaying action. There’s a predictable sequence of events:

1. Our brand is well known in our country, we need to keep it as is.
2. OK, we’ll keep our local name and logo but we’ll adopt the parent brand’s color scheme.
3. OK, we’ll keep the local name and logo but we’ll add the parent brand name underneath.
4. Fine, we’ll adopt the parent brand wholesale but we absolutely must be the last regional subsidiary to do so!
5. Capitulation followed by heavy drinking and reminiscense about how wonderful the old brand was before it got subsumed into the global brand.
6. Profits.

At some point the parent brand gets big enough so that it just imposes its brand right away. In its acquisition heyday Cisco was famously efficient at making sure acquired companies had Cisco email addresses, badges, business cards, network access etc… on day one.

What’s Best for the user?

Having recently examined a number of global sites, it seems the Internet industry still hasn’t converged on a “best” way to address international users on the dimensions of brand, language, and content.

When a user in country X whose language preferences are Y and Z arrives at my site:

• What language should my interface be in?
• What brand should I present?
• What content should I present?
• Whose legal framework(s) do I need to respect?

I’m going to steer relatively clear of that last question because (a) I’m not a lawyer, and (b) I don’t have time to write 20,000 words. Didn’t we just go through GDPR?

About 10 years ago I was in Peru on a hotel computer and looking something up in Google. I would type google.com and google would automatically redirect me to google.pe in Spanish. This was quite annoying but, given that it was a hotel computer and they probably had their language set to Spanish, not entirely unexpected.

Americans tend to think that languages and countries are 1:n. Each human language is spoken in multiple countries. The reality is that it’s m:n. Each human language is spoken in multiple countries and in some countries multiple languages are spoken. Belgium and Switzerland are great European examples where Belgium has two official languages: Flemish and French. Switzerland has four: German, French, Italian, and Romansh. Dialects also come into play as Swiss-German (de-CH) and Swiss-French (fr-CH) are quite different than the “native” versions. Don’t even get me started on fr-CA, Quebecois is an ancient fork of French that’s never been merged back into master.

Major websites handle these issues very differently, so differently that it makes me wonder who really respects the standards set by browsers and mobile OSes. These generally allow the user to set:

• An ordered list of language preferences.
• A region. This may drive regional data formatting preferences including:
• How dates are displayed
• What calendar to use
• What day is considered the first day of the week
• Number formatting
• The currency to be used

Content

What is notably missing from browser/mobile OS preferences is “What country/countries am I a citizen of?” as well as “What country am I a resident of?” For the most part you can assume that a browser or mobile application can usually figure out “What country am I in right now?” just based on IP address. However, the content you display could conceivably depend on all three factors (citizenship, residency, and current location). If you’re selling physical goods then logistics, customs regulations, distribution and licensing agreements, local compatibility (electrical, plumbing, metric vs. English units, etc…), laws at both the source and destination, tax regimes all become factors. Even media sites are subject to many of these concerns.

Content also couples with language to constrain the site from respecting the user’s language preferences. An international media organization might offer content in many countries in many languages but only in the dominant combinations. It’s just not worth it to translate everything. Sites with user-generated content have to deal with the frequent mismatch between the site’s presentation language and user content that is in a completely different language. Should you see a review written in German on a site listing properties in France when German is not in your list of preferred languages? Some sites will filter out these “unreadable” pieces of content and others will just let them be. My facebook and twitter feeds each display posts in several languages, some of which I don’t understand. It’s very nice of facebook and twitter to offer translation buttons right in their UI; even if machine translation isn’t always up to snuff, at least I can get the gist.

Best machine translation ever

A Few Examples

Modern web browsers and mobile operating systems nominally give their users great control over their experience. I say nominally because it turns out that most top-tier brands don’t respect the user’s stated preferences. Sometimes it’s just not possible — if the user specifies that Lithuanian and Finnish are their preferred languages and none other and the site has no content in either of those languages then the site has to fallback to something. In many cases that is going to be English. In other cases the choices are just plain arbitrary and disrespect the user’s preferences.

Amazon

• A user who attempts to visit amazon.ch (Switzerland) with language preferences of English and French is redirected to amazon.de (Germany) with the initial language set to German. If you dig way down into the footer you can reset the site language to English, Dutch, Polish, Turkish, and Czech. French, Italian, and Romansh are unavailable.
• A user who attempts to visit amazon.be (Belgium) gets a site for Amazon Insurance — nothing to do with Amazon.com. Amazing that Amazon hasn’t yet managed to get this domain.
• A user who visits Amazon.fr gets content in French. When we moved to France we quickly had to switch from using Amazon.com to using Amazon.fr so that we could get stuff easily delivered to our Paris apartment. Fortunately for my wife, the search index behind amazon.fr has most products categorized in both French and English so an English language search will return a decent list of products. On the other hand, our US prime account didn’t carry over to France so we had to open a new one here. Due to logistics, customs, compatibility with 220V power etc… the Amazon catalog in France is pretty different than the American one. That happens to match with my expectations.

Amazon’s Country Selector — this also controls the language

Even with a major brand like Amazon, little errors get through. Here’s a case from their Chinese site where the copy is all in Chinese but the images are American:

Booking.com

Booking.com was originally a Dutch company so I’d expect their approach to differ somewhat from a US one.

• A user who visits booking.fr gets redirected to www.booking.com/index.fr.html and is presented with content in French, even if French is not their first language preference and the first preference is supported by booking.com. Ditto for Italy with Italian, Sweden with Swedish and so on. Booking.com does not respect the user’s language preference even when they support that language.
• Unlike many other sites the country top-level-domain (TLD, ex: fr, de, uk, com) is removed altogether. The visitor always ends up at booking.com/index.{countryCode}.html

The positive aspect for the user of using a single TLD is that their client state (login, cookies, shopping cart) is retained no matter what TLD they used. Sites that reroute you to a different TLD will require you to login again (and create multiple accounts in your password manager to boot!) The better ones will at least carry your preferences and your shopping cart over to the other TLD.

Booking.com supports 43 languages from one TLD

Apple

Apple, like booking.com also routes any request for apple.{tld} to apple.com/{tld}

• A request to apple.fr gets redirected to apple.com/fr/ with content in French even when my first preference is English. Of course I’m in France when I’m testing this so it may behave differently if I was elsewhere.
• A request to apple.de gets redirected to apple.com/de/ with content in German but Apple adds a little menu at the top that allows me to change to French content. If I select that I end up at apple.com/fr My physical location seems to matter more here than my language preferences.

Language selection dialog on apple.de when visiting from France

• A request to apple.ch brings up a simple page with a two option dialog:

“Pick your language” — apple.ch

• Picking French sends you to apple.com/chfr/ and picking German sends you to apple.com/chde/

While you can’t see it here, the title of this dialog actually fades in and out between French and German so that both types of visitors can understand the choice being proposed. On the other hand the Italian and Romansh-speaking Swiss get bupkus.

• A request to apple.be brings up a similar two option dialog with French and Dutch as options. Picking the Dutch option takes the visitor to www.apple.com/benl/ with Belgian-Dutch content (as opposed to Dutch content for the Netherlands which is at /nl/

Apple’s UX here is good but could still be improved. Once on the Belgian site for example you only have French and Dutch as options. If you’re a visitor or expat that doesn’t speak one of those languages you’re out of luck; Apple doesn’t even give you a way to access content in another language even though they support quite a few. Certainly they are not respecting the language preferences you set in the browser even when they have your first choice available.

If you are an Apple fanboy who thinks that Apple can do no wrong you should go try to install an app that is not available on your home app store. When we got to France I wanted to get the app for my new ISP but it’s only published on the French app store. Apple’s UX here is absolutely horrible. First I couldn’t find the app at all on the US app store. Then I found it on the French app store but couldn’t download it because my app store is set to the US. Switching to the French app store was a non-starter because I would have lost every app I had installed from the US app store, paid or not. That’s basically a complete reinstall and re-login for every app and potentially a fair bit of money for paid apps. If you’re a gamer it’s also potentially a reset to zero of all your progress in all your games. Apple provides no way to transfer an account from one App Store to another.

HuffPost

HuffPo’s Edition Menu

This is a news site that started in the US then grew internationally. It is now part of Oath — the merger of AOL and Yahoo, which by the way, seems to not care about EU cookie warnings on their main site. HuffPost provides local news content in 17 countries, several of which are bilingual (Canada and the Maghreb countries of Morocco, Algeria, and Tunisia). HuffPost has gone with a model of one site — one language. They have content in French for Quebec and in English for the rest of Canada. The Maghreb countries are all served French language content. Browser language settings are ignored altogether.

This set of choices feels like it actually works; Canada is nominally bilingual but dividing into Quebec and “rest of Canada” with French in the former and English in the latter probably gives most people the content they want in a language they speak. HuffPost doesn’t publish in Arabic at all so there’s no point in them respecting an Arabic first choice of language in the Maghreb. News is primarily a regional product.

How Should it Really Work?

This is purely personal opinion, keep in mind, I’m a geek, not a brand guy. If you have a different one, I’d love to see it in the comments.

1. Respect the user’s language preferences, in order, if possible. If not fallback to your most commonly used language. The user has invested in setting their language preferences in their browser and on their mobile phone. This is their opportunity to exercise control. Respect that. The downside is that many users don’t ever set their language preferences, particularly for browsers so their default language tends to be English more often than it should.
2. If you provide content in multiple languages always give the user the option to change the language they want to see your site in. Remember that choice for future visits. On the web it is preferable to present this choice in the header than to bury it in the footer. Also make sure that the choice is intuitive for someone who doesn’t understand the site language at all — this is why flags tend to work well. If you don’t like flags at least display the language’s name in that language (i.e. Francais instead of French).
3. Don’t change TLD when you change language. If the user is logged in you’ll end up forcing them to login again — not very friendly.
4. Respect the brand that the user started with. If a user in some country knows you as brandA and either goes straight to your site or arrives from google then don’t switch the site to brandB when they change languages — at least not without asking them! The gut reaction of most users will be to wonder where they are and why they were taken there. This is a bit easier with an app since you choose it by name in the app store. If you change your language preference the branding in the app shouldn’t change with it!
5. When you kill off an old brand site it’s tempting to just 301 redirect to the new site. This can confuse users who thought they were going somewhere else (my Mom’s reaction is “Someone has hacked my computer!”) At least leave an “{oldsite} has moved to {newsite} as of {someDate}” page to make the transition less jarring. Furthermore, you’ll be able to collect statistics on that page to see how many people are still finding the old site and where they are coming from. After awhile the flow will drop to a trickle and you can finally close down the transition page.

Other chapters of An American Geek in Paris.