A localisation project runs smoothly when the source content is final and prepared before translation begins, the terminology is agreed up front, files move in a format tools can handle, and review is planned as a stage rather than a surprise. Most delays come from changing the source late, unclear review responsibilities and text embedded in images or code. Plan the work in stages and protect the source.
Stage 1: scope and prepare
Decide what is being localised, for which markets and in which languages. Be precise: “Simplified Chinese for mainland China” is more useful than “Chinese”. The distinction between translating and adapting is explained in localisation versus translation.
Then prepare the source. The W3C’s internationalisation guidance gives useful rules that apply to preparation:
- Keep user-interface text out of code so localised versions can be swapped in.
- Avoid building sentences by joining strings, because word order varies between languages.
- Support Unicode and mark up language and text direction.
- Support local formats for dates, times, numbers, names and forms of address.
- Separate localisable elements from source code or content.
The same page notes that preparing early is easier than retrofitting. See the W3C internationalisation questions.
Source freeze
Agree a date after which the source does not change without going through change control. Every late edit multiplies work across every language.
Stage 2: assemble the kit
| Item | Purpose |
|---|---|
| Glossary | Approved terms and terms to leave untranslated |
| Style guide | Tone, formality, punctuation and formatting rules per language |
| Reference material | Screenshots, previous approved translations, product context |
| Contact list | Who answers translator queries, within what time |
| Review plan | Reviewers, scope and deadlines |
Without context, translators guess, and guesses produce rework. Screenshots and short notes on ambiguous strings are cheap and effective.
Stage 3: file handling
Choose formats that preserve structure and let tools protect code and placeholders. XLIFF, the XML Localisation Interchange File Format, is an OASIS standard for exchanging localisable content and related metadata between tools, and the committee page notes the standard is approved by OASIS and ISO. See the OASIS XLIFF Technical Committee page. Your localisation provider will usually tell you what they prefer.
File practices that prevent trouble:
- Do not send text only as screenshots or flattened images. Supply editable source files.
- Keep one master copy and name versions clearly.
- Leave room in layouts, because translated text can be longer or shorter.
- Check fonts cover the character set of each language.
- Do not translate code, placeholders or URLs by accident. Use a check that compares them to the source.
Stage 4: translate and review
Translation is followed by review. The structure of a review process, including in-country review and checks that do not require reading the language, is covered in reviewing translations. Build review time into the schedule and name reviewers early, since availability is the most common bottleneck.
Stage 5: integrate and test in context
Place translated text into the real page, app, video or document and look at it. Check:
- Truncated or overflowing text.
- Broken characters.
- Dates, numbers and currencies in local format.
- Links to the correct local pages.
- Subtitles timed correctly against audio, for video content.
For campaign video this stage includes on-screen text, captions and voice, as discussed in adapting video campaigns for different markets.
Stage 6: sign-off and afterwards
Record the approved version, update the glossary with decisions made in review and note lessons for next time. If content will change, decide how updates will be handled so only changed text is retranslated.
Planning a timeline
Avoid copying timelines from other projects. Instead, estimate by working backwards:
- Fix the launch date.
- Reserve time for integration and testing.
- Reserve time for review and corrections.
- Estimate translation time with your provider, based on volume and complexity.
- Add time for source preparation and glossary.
- Add contingency for approvals.
If the result is earlier than today, reduce scope or launch in phases, starting with the most important market.
Common failure points
- Source changes after translation has started.
- No glossary, causing inconsistent terms.
- Reviewers who rewrite for taste, not accuracy.
- Text hard-coded into graphics.
- No owner for answering translator questions.
Where Radiance Impact fits
Radiance Impact’s Global division handles localisation and adaptation of content, working in English and Chinese. See /global/localisation or contact us.
