This post is a follow-up to a recent tweet in which I said:
“The biggest enemy of CS in Europe is the budgetary bloat caused by localization requirements. Right tech ends up being too expensive.”
I’m a lucky guy. In the past few weeks I’ve been pitching and/or working on projects that involve serious content creation. Just the kind of thing I love.
But I keep running up against the same wall: languages. There’s nothing more frustrating than coming up with great content ideas, only to have them dashed on the hard rocks of multilingual reality.
To avoid future headaches, I’ve scraped together a checklist of issues that I make sure to cover during the initial (pre-strategy, pre-creative) stages of the project. It never ceases to amaze me how often they are overlooked/underestimated by clients, strategists and project managers.
I’m not going do down the slippery slope of discussing the finer points of translation vs. adaptation vs. transcreation. I’ll leave that for another post. A much more mundane point is cost. The more languages you have, the more expensive it is – and quality translation even more so. However, another often-ignored angle is speed. Good translation takes time, making it tough to keep content fresh, relevant and responsive – which is what fast moving brand demand of web content.
2. Hidden content
Legends. Images. Video subtitles. Voiceovers. Motion graphics. Rollover captions. Forms. Prompts. Charts. Graphs. All these elements can contain textual content that will need inventorying and translating.
When estimating translation costs, metadata are often forgotten. And what if there are metadata that need to exist for one language/location but not for others? How do you track it?
4. Accents & subtitles
When recording people speaking in a language other than their mother tongue, listen to their accent before sending the crew to film them. Also, remember that if you decide to subtitle your videos, the text will be impossible to read if the screen size is too small.
5. Location & language
Who gets to see what, in what language, and where are they located? Clients need to understand (even if they don’t want to) that translation and localization are not the same thing. Content in French may turn out to be useful in France, Belgium and Switzerland. But a French phone number for Belgian users is rude. Browser language and IP localization can help, but can also be a hassle when the site visitor is browsing when traveling.
6. Geolocalization & mobile devices
The problems are related to those in the previous paragraph, and are exacerbated by social media. Imagine, you’re a registered user of a brand’s local website. You’ve picked your country and language. But you’re traveling abroad and accessing the web via your iPhone with geolocalization turned on. You want to find the brand’s nearest store in the country where you are, but when you go to the Store Directory page all you can see are the stores at home. You get the picture. And this is just one of the problems I’ve encountered.
7. Approval process
This is the dirty underbelly of multilingual content creation. You need to figure out early on who approves what in which language. But this is rarely the case. In the giddy, heady days at the start of a project, no one wants to think about something as mundane as sign-offs.
Obviously, it’s easiest to work and approve all content in one language, but it’s not always practical. If you’ve interviewed someone in French, but written the article in English, in what language do you think they’ll be most comfortable approving the article? And the costs and delays generated by having to redo content (especially audio-video) because someone didn’t like it when they finally read/heard it in their mother tongue are enough to turn a great project into a giant fiasco.
8. Social media
“Oh, let’s set up a Twitter account for our brand.” And in what language will you tweet? I ask. Who tweets? Agency or client? What’s the workflow and approval process?
Does the existing one support localization? Which one to pick if they don’t have one? Have they budgeted for it? If you’re obligated to work with the existing CMS and it won’t support your ideas, it’s a recipe for disappointment. Oh, and don’t get me started on IT departments that won’t authorize certain kinds of content or that impose a crappy CMS.
10. Budget & Time
I’ve seen too many projects get the axe because the budget was just plain unrealistic. The client may have loved the creative, loved the concept, loved the UX, but it was too costly to be feasible. Get an idea of the budget as soon as you can. Ensure that there is no disconnect between ambition, technology and dinero.
Speaking of disconnect, one of the best ways to keep costs under control is to assemble a multi-lingual CS team that includes members from all the localities served by the site. But since many brand CS projects are managed centrally by head office, this is rarely the case. There is usually a strong disconnect between what HQ wants from the website what the countries want. If HQ doesn’t know or care about what the countries want, you’ve got yourself a red flag.
In my experience, US companies operating in Europe are notorious for underestimating what a content project will cost in terms of money and time, because they think in terms of one market and one language (two if you’re lucky). This is especially true when you venture out of consumer brands into B2B and internal communications projects.
So, the next time you feel like ripping you hair out on a monolingual project, spare a thought for your CS brethren in Europe.
PS: Like all lists, this one is incomplete and superficial, but it’s start. Feel free to add any other issues that you think might be missing in the comments. I’d look forward to hearing from you.