I don't remember all the questions we pondered when first tasked with translating dW content. I do know there were some questions we answered along the way that had we recognized them earlier, things would have gone more smoothly. I offer them here as discussion points for your management, human factors, and development teams, as well as the home and local geo marketing teams. All of these teams will actively contribute to the success, or failure, of the project.
What is the audience proficiency in English?
If your target audience is relatively comfortable with English, and the translation is more a nice to have addition to your site, rather than a need, you might simply provide translated content as a separate link off the original English content. If you decide to do this, consider adding the link to translated content in native language. It will be easier for native language users scanning the page to find the link to their language content. If your page encoding is not utf-8, you can use gifs of the language text to link to the content. (more about encoding later)
Let's assume for further discussion your audience has little skill in or comfort with English. You will probably want to build a site or area of the worldwide site that provides localized navigation, content, and function. A user should be able to access content and function without struggling through English. How long would you stay on a site where you had to drill through Russian navigation cues to find the English content? Or imagine submitting an article for publication consideration using this submission form.
Understanding your audience's English proficiency can also give clues as to how to spend translation money. On dW, as our primary audience becomes more experienced, their proficiency in English increases. We interpret this to mean a greater need for translated introductory material. Those users looking for more advanced material are better able to access the English.
How versed is your development team in the concepts and practices of i18n and L10n coding?
It is much easier to build internationalized software than to retrofit existing software for translation. Often this is not possible, such as when you are relying on legacy worldwide code. At the very least, educate the development team on best practices of building i18n'ed code and ensure any new code is built with the core requirement of language neutrality.
I will add an entry to this blog in the near future about the coding practices that have worked best for us. Suffice it to say for now, all language data is pulled in as variables. If developers insist on hardcoding text for test purposes, require it be in Latin. Nobody's language gets preferential treatment.
Are you targeting a geo or a language?
For example, are you trying to reach the worldwide audience of French speakers, or specifically European French ? If you are targeting a geo, you will want to localize the treatment of such data as time, date, currency, phone numbers, addresses etc. If your primary audience is worldwide, you should probably adhere to ISO standards. And, just as there are various dialects of English, like UK, US, and what they speak down under, other languages are have evolved local dialects. Determine which dialect best meets your translation goals.
Our dW local sites target specific geos. Only our worldwide site targets a global audience of English speakers. dW SSA (Spanish South America) targets Spanish speakers residing in South America and Mexico. While this can be counted as a single geo or region, we have run into unique problems in trying to address 11 different countries with one site. More about that later, I'm sure.
Are there any hidden audiences ?
You aren't going to meet the needs of all users, but there may be hidden secondary audiences who are key to your goals and have unique translation needs.
We discovered a need for translated overview or executive summary material. Turns out our developers need material in native language to share with their management who actually make software buy decisions. While developers tended to become more proficient in English with increased experience and education, this was not necessarily true of the business owners or executives.
What level of user communication are you able to support ?
If you link to a feedback form or include email links on translated content, expect to receive user feedback and comments/questions in native language. Do you have someone available to respond to that communication ? One of our initial requirements in setting up a developerWorks local site is that we have someone on staff who resides in the country, is proficient in the language, understands the local audience, and can be the IBM voice for any communication in that native language.
One final caveat that may or may not fit in here, but it's given me trouble, so I'll include it. Beware of publishing content provider emails. We are dealing with an issue in which English speaking authors are receiving native language communication from local site users. Our articles include author emails. Our authors are often fluent in English only. When local teams translate content, they also publish the author email information. If we were talking about a few hundred articles, I would suggest we overhaul them manually. But we have over 40,000 articles that automatically link to tens of thousands of author contact records. In hindsight, we should have replaced all emails in translated content with a general local site editor email, or removed them altogether. So do as I say, not as i did!
These are just a few points of thought to help you start thinking through your plan. I'm sure as soon as I post this, another one or two will come to mind. But, that's the beauty of blogging, I always get another chance.