There's usually a time in the life of a software product when it needs to be tailored and translated for overseas markets. At this point in time, companies tend to go through the same steps under the pretext of saving cost and getting product out into a different territory quickly. These are:
1. Get the text to be translated into a set of files that can be sent to the translators.
2. Find a cheap translator (usually somebody's relative who happens to have studied the language at school in the dim and distant).
3. Get the files back and stitch them into the product flow.
4. Release to the world and give yourself a pat on the back.
5. Wonder why users are conplaining.
This is an expensive and qualify-free way to get the job done.
In this and subsequent blogs I'll cover a better, formal approach in the shape of a simple project lifecycle. This covers:
1. Get your act together. Things to consider before you even start.
2. Sourcing the right provider for translation services.
3. Getting your team's knowledge up to speed so that the know why you are doing what you are doing.
4. Pre-processing the content to be translated and creating a bill of materials for it.
5. Getting the translation done and monitoring progress / quality along the way.
6. Post-processing the content back into its proper form.
7. Testing and correction.
8. Release.
9. Happy customers.
Getting your act together
Before you even start, consider the following:
Graphical User Interface (GUI)
This is usually made up of a number of different file formats. Make sure you know what they are (.res, html, xml, dhtml.... etc). Once you have the list make sure you know who is responsible for which part and find out the following:
- Is the text easily extractable? A process will need to be developed to make sure this is a simple and repeatable process, under source control.
- Are any icons / graphics used acceptable in other countries? You will need to ask your colleagues in-territory to help you answer this question. Alternatively your chosen translator / agency (when you get to that step) will advise. Avoid using text elements in graphics wherever possible - graphics work for localisation is expensive.
- Are field display lengths variable? There has to be enough room for longer text, particularly German and French to name but two languages that translate a lot longer than English.
- Is there any hard-coded text in the product that doesn't get extracted? If there is, this needs to be reengineered so that it follows the same process.
- Are there any variables in the product (values that call from a list of options such as months or days, depending on the message) and can these be transposed in the text string during translation without causing an error? Each language will have a different grammatical context and it's important that this is respected. Again, reengineering may be required by the developer.
- Can languages be built in independently, rather than everything being required for a single language release? it's better for you if you can release language modules as add-ons with their own release lifecycle. Well run localisation projects usually have a home language release followed by one or more language releases.
- Has the interface been subject to a full English review by a Technical Author or other individual skilled in use of English? (As opposed to a developer - sorry if I insult any techies out there).
- Is there a way to give translators access to the source language version of the product, and identifying which files sent for translation relate to which screens? This will make sure they get the context right most of the time.
- Do you have the language versions of your operating system available so that you can load and test the behaviour of the localised version once it has been completed? Even if you don't speak/read the language this helps you pick up anomolies where stray source language strings appear or field lengths crop the translated version.
Why bother?
Addressing these issues before you start will stop a number of problems, including:
- Keeping track of multiple files - knowing what stage in the process each is at and who to see if there are problems.
- Not seeing source language words and phrases pop-up in a translated version due to hard-coding,
- Avoiding variable details appearing at the wrong point in a sentence due to immutable positioning.
- Developers lack of understanding about the requirements for localisation (the pain will be so great during reengineering that the knowledge will be permanently etched on their memory).
- Having to hold up release of the source language product, pending resolution of language issues.
- Dealing with lots of queries from nn x translators who just don't understand the context or meaning of text supplied.
- making sure the end result doesn't look cobbled together.
- Receiving higher than necessary charges for the translation work - this is charged by the word. If you can keep text down to a minimum through the use of standard key phrases, field names etc. you will reduce your costs significantly.
Once you have a level playing field to launch your venture into localisation projects, write the steps down and train all concerned in what their role is in the process. It's good to build in some KPIs along the way to keep everyone informed.
Until you act on these key elements DON'T DO IT!
The next post (after 19th April 2010 when I get back from France) will cover dealing with supporting documents, help and training materials.
in the meantime these sites might help you:
http://www.simultrans.com/slpm.cfm
http://whitepapers.techrepublic.com.com/abstract.aspx?docid=169756
http://www.idrc.ca/panasia/ev-61420-201-1-DO_TOPIC.html
http://www.translationdirectory.com/article623.htm
http://www.japaninc.com/cpj/magazine/issues/1996/jun96/localize.html
No comments:
Post a Comment