There is something in the content strategy and web community known as the “11th hour sh*tstorm”. You know: that moment two weeks before the go-live date of a major website redesign when people are scrambling around like crazed chickens because they have everything ready – except the content.
Well, if you’re experiencing storm problems with your content, or suffering from related ones — lack of governance, no maintenance, rework, too much content, lack of purpose, and so on – you’re going to have them to the nth degree if your content needs to be in 5, 15, or 40 languages.
Localizing websites and web content is hard work. It can be costly, time-consuming, and a logistical pain in the butt. It creates complexities all over the place: for information architecture, SEO, look and feel, your CMS, and your infrastructure. And it’s made that much harder when you’re working without a content strategy.
It’s worth repeating: content strategy plans for creation, delivery, and governance of content – ALL content, not just the source content.
Much like trying to retrofit content into wireframes, starting the localization process after the source content has been created (and often published) can lead to problems that could have been avoided with better upfront planning.
There are a lot of things that content strategists can do to facilitate the whole process:
Ask the right questions as you’re setting your target. External market forces, internal strategic ambitions, cultural and language factors, as well as the site’s objectives: such factors need to be considered and weighed against each other in order to make smart decision about your overall model, the number of languages you’ll support, and the critical mass of localized content you should deliver for different types of locale sites. (I suggest you ‘tier’ your sites: it’s unlikely you’ll be able to handle the web presence of a large subsidiary in the same way you would for a 2-person office in a new market.)
Get a handle on your universe: What are you spending now? Who owns the budgets? How are you organized to support your localization efforts? How do localization and local web operations teams work together – if indeed there are different teams? What tool sets are at your disposal? Do you have a language service provider? Several of them? What are your metrics telling you? Is your CMS flexible? Is it integrated with your language tools? What language tools is your company using?
Get a handle on your content: Start by qualifying your source content. Take out your inventory – and if you don’t have one, now’s the time to get it started – and assess it. Is there a little or a lot? Is it stock or flow? It is relevant for all audiences, or is it susceptible of being localized in some way? Too often, companies make all-or-nothing decisions about the content (yes we translate/localize – no we don’t); the choices don’t have to be so stark.
Compare your desired state to what you actually have. Enlist some help reviewing your existing local sites. That’s one of the biggest added complications of working in global environment: your team rarely has the language skills required to assess what’s there (or maintain it, for that matter). Plus, it’s a lot of work. Unless you have sizeable internal resources to support you here, it’s practically impossible to do this part without external support.
Integrate localization issues into your editorial specifications: Page specs are great for aligning people on objectives, and serve to provide guidance to those who actually write source content. Voice and tone, terminology requirements, what elements will be localized – getting it right from the start can save a lot of frustration down the line.
Make a plan and get it done – but do it in chunks. For many companies, developing a content strategy is daunting; they’re not sure it’s worth the investment to do the upfront work. So taking on such a project and adding the global dimension to it can have people running in the other direction. Part of this is because we try to do it all at once, during the redesign. I’m a fan of Lou Rosenfeld’s ‘redesigns must die’ approach: yes, there will be projects, but managing website changes should be part of an ongoing and daily maintenance plan, kind of like putting one foot in front of the other when you’re climbing a very steep hill.
There’s more, of course – lots more. I spoke about this recently at the Content Strategy Forum in London (Note: I’ve updated this link so that it goes to my Confab Minneapolis presentation instead). Here’s my presentation.