Global SEM

4 February
2011

Rapid eLearning Localization

By Darron | Best Practices, Development Tools | 2 responses so far

There are a LOT of rapid elearning platforms out there. Many of them are based on MS PowerPoint. My personal development preferences do not include PPT, but that’s irrelevant. There are clearly enough course designers out there who use PowerPoint to justify myriad rapid dev tools to be built around it. Some producers of such tools include small but excellent companies like eLearning Brothers as well as some big players like Adobe.

Read more

30 November
2010

Save Time and Money by Developing for Global

By Darron | Best Practices | No comment yet

You’ve completed all development work on your creative, integrated approved copy and finished text styling and layout. Your project is complete, and the result is a thing of beauty…in English. Now you are tasked with rolling your creative into 15 languages, ranging from German to Arabic. Is your creative prepared to handle typical localization roadblocks such as the following?

Read more

30 November
2010

Save Time and Money by Developing for Global

By Darron | Best Practices | No comment yet

You’ve completed all development work on your creative, integrated approved copy and finished text styling and layout. Your project is complete, and the result is a thing of beauty…in English. Now you are tasked with rolling your creative into 15 languages, ranging from German to Arabic. Is your creative prepared to handle typical localization roadblocks such as the following?

•    Accessibility and easy sharing of content
•    Character corruption due to encoding disparity
•    Text-centric functionality
•    Text expansion up to 35%
•    Style transfer for key terms and other text

Regardless of your development platform, there are some basic items to consider before production commences. Adhering to these internationalization principles will save you time and money (and frustration):

•    Externalize text in a tagged format
•    Create plenty of white space in the source English creative
•    Assign centrally controlled styles

Externalize Text in a Tagged Format

Whether you are developing in a CMS, creating a Flash module or typesetting a print document, getting your text content into a separate tagged file is the first step to success. With Open XML’s increasing ubiquity, XML has become the standard tagged file format to use for everything from InDesign content exports to scratch developed web sites. XML is a great way to store, share and distribute text for a number of reasons. First, XML will typically be encoded as UTF-8, the international encoding standard which pretty much supports every language. This ensures, or at least makes probable, that characters will not corrupt when your creative is localized into disparate language families. Second, it is simple to parse and isolate text for extraction, translation and automated re-insertion. That leads to the third point which is that having your text content isolated from the rest of the creative allows the translators to focus on what they do best without requiring any technical expertise. Similarly, styles and functionality built around the text can be preserved independently, which makes rebuilding the creative much more efficient.

Create More White Space Than You Think

Moving away from actual text and onto text containers, let’s look at why white space should be your first consideration when starting production on your creative. English is known linguistically for its concision. While there are some languages which require fewer characters to express the same idea in English, most of the time you need to prepare for text expansion. Western European languages like French and Italian, Eastern European languages like Russian and even some Asian languages like Japanese will expand up to 35% on average. Consider that paragraphs of text will require additional lines. Be mindful that single words might expand to 300% at times. A good example of that is an OK button. Just build in some extra space to the right and left of a center-aligned OK. Remember that a little extra white space in the English source is better than cramped, crashing text in most of the localized versions.

Utilize Style Sheets Always

Styles can be stored at the document level as in InDesign and HTML, or as an external file as with CSS. In keeping with earlier thoughts about externalizing text, use external styles whenever possible. Styling text properly, and reusing styles appropriately is good development/typesetting practice, but it becomes essential when introducing localization. Styles are intended to preserve look and feel in the source creative, and they are used for the same purpose in localized versions. Adjusting font size, kerning, leading, etc to account for text expansion or contraction is much more easily and quickly accomplished when styles are consistently applied throughout the creative. Think about how tedious and time consuming it would be to find and change text formatting for every paragraph in your creative. Remember too that this work multiplies exponentially with an increasing number of target languages. Now think about how easy and fast it would be to make the same change one time in your style sheet. Get the idea? A very little bit of work up front will save countless hours and dollars on the back end.

A Practical Example

A leading entertainment company needed to distribute online instructional modules on vendor process for moving a product through proposal to final sign-off. The development team spent weeks building the course with hard-coded text on the Flash timeline. When it came time to localize, the text extraction was time-consuming and expensive. Those costs multiplied as the modules were localized into 10 languages. Each text string had to be manually pasted. Text formatting had to be done on a textbox-by-textbox basis. Extra rounds of review were required to ensure that styling was consistent throughout the localized creative; this was necessary to account for human error. The debrief revealed all areas of inefficiency and unnecessary cost.

We made some simple recommendations to the client about how to build an XML-driven Flash module with shared styles and room for text expansion. Text extraction for translation was automated. Re-inserting or flowing the translated text into XML was automated. Style changes applied across the entire module at one time. These changes toward a fully internationalized creative amounted to a 40% reduction in overall time required. Those time savings translated directly into cost savings for our client.

Conclusion

Controlling the storage, accessibility, style and format of text in your creative leads to increased efficiencies and decreased costs. Internationalizing at production start requires thinking and planning, but will ultimately return more manageable localized documents that require less time to reconstruct and clean up.

30 November
2010

Save Time and Money by Developing for Global

By Darron | Best Practices | No comment yet

You’ve completed all development work on your creative, integrated approved copy and finished text styling and layout. Your project is complete, and the result is a thing of beauty…in English. Now you are tasked with rolling your creative into 15 languages, ranging from German to Arabic. Is your creative prepared to handle typical localization roadblocks such as the following?

•    Accessibility and easy sharing of content
•    Character corruption due to encoding disparity
•    Text-centric functionality
•    Text expansion up to 35%
•    Style transfer for key terms and other text

Regardless of your development platform, there are some basic items to consider before production commences. Adhering to these internationalization principles will save you time and money (and frustration):

•    Externalize text in a tagged format
•    Create plenty of white space in the source English creative
•    Assign centrally controlled styles

Externalize Text in a Tagged Format

Whether you are developing in a CMS, creating a Flash module or typesetting a print document, getting your text content into a separate tagged file is the first step to success. With Open XML’s increasing ubiquity, XML has become the standard tagged file format to use for everything from InDesign content exports to scratch developed web sites. XML is a great way to store, share and distribute text for a number of reasons. First, XML will typically be encoded as UTF-8, the international encoding standard which pretty much supports every language. This ensures, or at least makes probable, that characters will not corrupt when your creative is localized into disparate language families. Second, it is simple to parse and isolate text for extraction, translation and automated re-insertion. That leads to the third point which is that having your text content isolated from the rest of the creative allows the translators to focus on what they do best without requiring any technical expertise. Similarly, styles and functionality built around the text can be preserved independently, which makes rebuilding the creative much more efficient.

Create More White Space Than You Think

Moving away from actual text and onto text containers, let’s look at why white space should be your first consideration when starting production on your creative. English is known linguistically for its concision. While there are some languages which require fewer characters to express the same idea in English, most of the time you need to prepare for text expansion. Western European languages like French and Italian, Eastern European languages like Russian and even some Asian languages like Japanese will expand up to 35% on average. Consider that paragraphs of text will require additional lines. Be mindful that single words might expand to 300% at times. A good example of that is an OK button. Just build in some extra space to the right and left of a center-aligned OK. Remember that a little extra white space in the English source is better than cramped, crashing text in most of the localized versions.

Utilize Style Sheets Always

Styles can be stored at the document level as in InDesign and HTML, or as an external file as with CSS. In keeping with earlier thoughts about externalizing text, use external styles whenever possible. Styling text properly, and reusing styles appropriately is good development/typesetting practice, but it becomes essential when introducing localization. Styles are intended to preserve look and feel in the source creative, and they are used for the same purpose in localized versions. Adjusting font size, kerning, leading, etc to account for text expansion or contraction is much more easily and quickly accomplished when styles are consistently applied throughout the creative. Think about how tedious and time consuming it would be to find and change text formatting for every paragraph in your creative. Remember too that this work multiplies exponentially with an increasing number of target languages. Now think about how easy and fast it would be to make the same change one time in your style sheet. Get the idea? A very little bit of work up front will save countless hours and dollars on the back end.

A Practical Example

A leading entertainment company needed to distribute online instructional modules on vendor process for moving a product through proposal to final sign-off. The development team spent weeks building the course with hard-coded text on the Flash timeline. When it came time to localize, the text extraction was time-consuming and expensive. Those costs multiplied as the modules were localized into 10 languages. Each text string had to be manually pasted. Text formatting had to be done on a textbox-by-textbox basis. Extra rounds of review were required to ensure that styling was consistent throughout the localized creative; this was necessary to account for human error. The debrief revealed all areas of inefficiency and unnecessary cost.

We made some simple recommendations to the client about how to build an XML-driven Flash module with shared styles and room for text expansion. Text extraction for translation was automated. Re-inserting or flowing the translated text into XML was automated. Style changes applied across the entire module at one time. These changes toward a fully internationalized creative amounted to a 40% reduction in overall time required. Those time savings translated directly into cost savings for our client.

Conclusion

Controlling the storage, accessibility, style and format of text in your creative leads to increased efficiencies and decreased costs. Internationalizing at production start requires thinking and planning, but will ultimately return more manageable localized documents that require less time to reconstruct and clean up.

5 February
2010

Bi-directional Language Solutions in MS Word

By Darron | Best Practices, General | No comment yet

Rolling out an e-learning module into other languages presents a number of challenges, none of which are as daunting as the prospect of having to localize into a bi-directional (bidi) language. Bidi languages run from right to left and include Arabic, Hebrew, Urdu and others.

Bidi text can cause trouble for a number of reasons:

1. Most of us develop in English on left to right systems (ltr), and right to left (rtl) languages can struggle on these systems.
2. Bidi languages can contain both ltr and rtl text. That text should be encoded differently, and that can cause flow issues.
3. Different software applications treat bidi languages differently. Some support it well, and some do not.
4. Some software applies its own encoding schemes, and that can be troublesome in conversion.

Read more

Connect with us, Keep up to date with Wordbank's Social Media