Understanding Content localisation (Part 1)
When your organization decides to have the corporate Website information translated into foreign languages and you are entrusted to spearhead this exercise — you have options. And granted, some of those options are better than others, but there’s really no need to stress about it.
Start at the beginning:
- Have a chat with the web development team managing the content management system (CMS).
- Verify that the system has features for processing and managing non-English text scripts.
- Identify all content of the respective pages that need to be translated and categorise them into Static or Dynamic groups.
- Involve global stakeholders when content contains locale-specific information.
- Plan in advance schedules for updating content on a regular basis.
Although it’s not rocket science, equipping yourself with the basic knowledge and understanding of the process of preparing content for local market use will go far in helping you make the right decisions, to avoid costly mistakes and prolong delays in rolling out the respective derivative language versions.
DIY or Contract Out
Whether you have the resources in-house to create new content for the various target markets you hope to reach, or you run an agency that develops website content for your clients, you need to decide if the project is worthy of outside assistance.
The language service provider (LSP) that you choose to do content localisation, needs to know what content needs to be localised, who the target audiences are, and where respective source text for localisation are located in the website. It would be relevant to also know which portions of the website source content are likely to contain programming codes.
This brings you to the second biggest decision you have to make for your content localisation projects:
- Do you have sufficiently trained staff internally that can liaise and manage changes as well as the entire workflow?
- Is there a computer workstation with necessary content apps program up to the task?
- Will a freelance translator effectively finalise your site for all the languages of the target markets you intend to reach?
- Did the LSP you contracted on the last project meet all your goals? (Did you verify that your intended audiences were able to read it comfortably, to the point of making a purchase?)
- Do you think your project and your audiences could be better served by using a transcreation team that not only translates your pages but creatively edits, for cultural nuances, correct syntax and proper messaging?
Manage the Details
With an abundance of CMS system software on the market that offer a variety of functionality and capacity, you can work with your chosen LSP or your internal web team with the preferred CMS that best suits your operations. The popular ones for mid-size enterprises are Sitecore, Adobe Experience Manager, Microsoft ASP.net, Kentico, and Oracle WebCenter Content.
Consider the details your CMS must offer:
- CMS with Peer-to-Peer Capabilities. If the existing CMS was introduced a few years ago, it should cater to peer-to-peer capabilities by providing stakeholders with access rights to directly interact with the CMS. For example, the regional office of respective target markets may need to be involved in the reviewing and approving processes for the translated content.
- Multi-language, Alternative Text Direction. Ability to input and display multilingual text as well as right-to-left writing direction if Middle Eastern languages are involved.
- CMS Plugins. CMS that supports compatible plugins provides the ideal advantage of performing automated extraction of source text as well as automated integration of their respective translated target content versions.
The issues that your LSP must master include:
- Overcoming Text Truncation/Erroneous Word Breaks. Being attentive to words or sentences that may become truncated or wrongly aligned, resulting in them becoming grammatically wrong or meaningless. Understandably, it's usually a design team that compounds display issues in other languages as they prefer to maximise content displays to tailor-fit the original (source) content in a given page layout.
- Consider some languages have much longer words, for example Indonesian, German, etc. Or languages written with diacritics, such as Arabic, Thai and Vietnamese, which have their marks or accents added at the top or bottom of certain letters. Blocking out these marks or accents could be viewed as typographical errors or obvious mistakes in the target language content. This will not be an issue if the page design elements cater to field size flexibility.
- Text in Programming Codes. Handling text script styling such as bold, italic, etc., or interconnected with programming codes for system-generated error messages and prompt messages that must remain in place. Potentially, translators may inadvertently delete or alter programming codes (understandably they are linguists, not software people). As these codes must be added back to ensure proper display for the translated content, the recommended solution is to externalize all codes from texts that are required for translation.
- Text Embedded in Graphics. Embedding text in graphics should be avoided as these text become non-extractable. Should it be necessary for text to appear in images, these images are to be provided in layers to allow their source text to be extracted and then prepped back into their translated equivalent.
- Data Sort Order. Sorting data in alphabetical order may not work the same with non-Romanised text or languages that are written from right to left.
- Setting Viewing Time & Date. Set the time and date according to the region of each viewership. Some communities may prefer to follow their Monarchy system.
- Static or Dynamic Content. Static content is information that's updated less frequently, such as corporate information. Dynamic content is information that's expected to be periodically changed or updated, such as seasonal offers, loyalty marketing campaigns, calendars of events, etc.
Test Before You Go Live
With a general understanding on the dos and don’ts of content localisation, you can arrange for the web team to perform some basic tests by replacing sample text of an existing content page with dummy translated language text.
The purpose of testing is to verify that the respective translated copy is displayed appropriately when viewed. Such tests are required for all the target language versions as well as for any potential languages that are likely to be included in the future.
A proper way to do that is to have a sample page of existing content translated and then incorporate the derivative language text into the page. Send it to native stakeholders to review on correctness and verify on the look and feel of the page.
Why Run the Tests?
As the prototype and pilot sites run through such tests, you ensure that design formats and page elements are flexible enough to handle content in various language writings. Such tests are relevant to be sure that the formatted content for respective language translations can be accessible to the LSP and their translators who are usually working remotely.
The benefits of such pre-localisation testing are that processes can be repeated to narrow it all down to the best option. The same tests can also be performed at different stages to uncover potential workflow problems, thereby resolving internationalization issues and identifying snags well ahead of the actual workflow activities. The consequences for failing to pre-identify how each target’s language content is displayed are the additional cost for retranslation efforts, as well as prolonged time to rectify inherent anomalies.
Create Your Master localisation Kit
With the pre-localisation testing and inputs from the web team, you should be able to create a simple document as your localisation Kit. This Kit can be provided to the various parties involved (copywriter, proofreader, system administrator, designer, translator, reviewer, etc.) as guideline instructions. In essence, the localisation kit should indicate the following:
- The scope of work. This refers to the number of words to be translated (pricing by word count is the LSP industry standard). The word count helps the appointed LSP identify the expected lead-time for their required workflows encompassing a first-level translation, second-level checking and editing, and a final proofreading before each set of translated content copies are ready for delivery.
- Master project timelines. After identifying and taking into consideration the LSP’s and the web team’s internal workflow schedules, including some buffer period to resolve any issues, you can draw a realistic project timeline for the entire development process that includes populating the site with localised language content.
- Stocktaking of content files. Prepare a spread sheet to list all the filenames of source content for translation, including their respective URLs, a list of images and another for images with text. The URLs provide the translation team with the necessary visual references and saves time on searching during the integration of respective translated content.
- Approved glossaries. If this is not the first time that a target language is to be created, you should have a set of bilingual glossaries of specific words, brands and product names that were previously approved by the regional stakeholder. Glossaries are listings of the source and target text in an alphabetical and sequential order. The approved glossaries of dedicated terms are an important reference to maintain consistency, especially for a newly appointed LSP.
- Translation Memory (TM). TM is a data file system of pre-translated content that’s stored as bilingual versions with their respective source and corresponding target text as a corresponding language pair. For content previously translated, the LSP should maintain a copy of the TM. The objective is to leverage the new source text with the TM (if available), and to generate pre-translated segments to identify repeat and matching words.
For pre-translated segments, the LSP only needs to perform post-TM editing instead of having to undertake entirely fresh translation procedures. Thus, the higher the amount of repeat pre-translated segments generated by the TM, the greater reduction in translation costs.
Finalising the localisation Strategy
When these areas have been correctly examined and defined, as well as relevant pilot test for various languages and other peculiarities have been sorted out, it’s much easier to further refine your instructions for the respective parties involved.
In the same way that web teams are trained to create the architecture of websites (generally three clicks to view), the other language versions should also be presented to their respective viewers in the shortest and most convenient ways. Now you are ready to approach your source content writers (whether internally or externally contracted) with your requirement and parameters. It’s imperative that the writing team is made aware that the source content created will be used as source text for translation.
For guidelines on preparation of the source content for translation, please refer to Understanding Content localisation (Part 2).
- Open Source CMS vs Licensed CMS: https://cypressnorth.com/web-programming-and-development/open-source-cms-vs-proprietary-cms/
- Importance of Web Tier: http://smallbusiness.chron.com/importance-tier-57502.html
- Texts/Word Truncation:
- Flattening Images: https://helpx.adobe.com/indesign/using/flattening-transparent-artwork.html
- Translation Memory: http://content.lionbridge.com/translation-memory-vendor-use-one/
- 3-Tier Enterprise Content Strategy: http://searchsoftwarequality.techtarget.com/definition/3-tier-application
- World’s Top Tourism Spenders: https://www.linkedin.com/feed/update/urn:li:activity:6260346723441438720/?actorCompanyId=133118