Global learning can present some daunting challenges. I recently learned that 40% of training costs, industry-wide, are consumed in travel. Building scalable and easily deployed learning modules can greatly reduce travel needs and the associated cost. With that expenditure reduced, the cost savings come down to effective elearning (or mlearning) course development and delivery. Chances are you put a good deal of thought into the English course structure, design and development. You’ll want to apply that effort to your multilingual course, and you’d prefer to avoid exorbitant costs. Here’s a case study snap shot of how one of my clients accomplished this:

Over the course of 4 years, these efficiencies were introduced, and they ended up saving this client immensely. Altogether, there was a 12x reduction in localization costs. The client felt great because of the cost and time savings. I felt great because projects went much more smoothly. My company felt great because we increased our capacity to handle more jobs and clients without increasing heads. Requiring fewer resources to accomplish one job freed us up to go after new business. Everybody wins when these best practices are applied at the outset of the initial English course development. So do us all a favor, bookmark this and refer to it next time you are starting design and development on a course with global ambitions.

Give yourself enough white space to account for text expansion, and you'll save exponentially at localization.

Today I want to address white space. All too often we forget to account for it. Did you know that it’s not uncommon for target language text to expand up to 30% from the English? 30%! I have personally witnessed the unfortunate expansion of one tiny word on one tiny button to 300%. That’s an outlier, and perhaps statistically irrelevant, but it makes the point. We need to expect text expansion, and to account for it we need to include white space.

Consider the example in the pictures of “Try Again” buttons to the right. In English, this is a very nice button; the text fills the button nicely, and it is consistent with the style of the course it came from. Now consider the two Spanish examples, “Vuelve a intentarlo.” Note that our only options include breaking onto two lines and dramatically reducing the font size. The French “Recommence” also requires a font size reduction despite increasing the button size.

If the designer had followed the white space rule for localization, there would have been 20% white space on either side of “Try Again.” That would have allowed us to keep the font size and button width consistent with the English. This is important if consistency between languages matters, for multilingual users perhaps. It is also important if localization costs matter. While it doesn’t take too terribly long to decide to reduce font size, there are a number of costs associated with that decision. You pay for someone to make the judgement, for someone to approve the judgement, potentially for someone to reverse a previous judgement to conform to the final approval. You may have to change layout on the larger stage to accommodate an expanded button. That involves all the same costs as stated earlier plus more. If white space is insufficient on more than one string, then all of the above multiply by the number of white space issues, and then again by number of languages. It quickly becomes costly and time consuming.

While considering how much white space around a particular string may seem boring, if not banal, it is effort well worth it when it comes time to account for text expansion. So designers, heed my caution and build in white space. The stakeholders in the localization efforts will thank you (or at least they should).

Giving your localization partner source images with editable text layers saves exponentially on time and money.

Keep a repository of images with editable text layers. With a little scripting, it’s a snap to extract text from editable layers for translation purposes. Run the script the other way, and you can update the images with translations with just a couple clicks. This takes a few minutes, and the charge for such a service is minimal.

On the other hand, if you give your localization partner has nothing but static, flat images (e.g. jpg, png, tif, gif) then the images have to be internationalized before translated text can be inserted into the graphic. That involves wiping the text from the image and recreating whatever is behind the text. If the text is over a photograph that is going to take a long time and a pretty skilled engineer. Basic gradients and fills are much easier, but they still require time that would be unnecessary with editable images.

Reality check: Sometimes we’re just happy to get nice images from our design team, and we know there is no way we’re ever getting our hands on the original source. Other times, we repurpose existing images knowing that an editable source no longer even exists. In those or similar cases, budget some extra time and cost for internationalization.

There are currently a sizeable number of capabilities that the Flash environment provides that are just not possible to replicate with the current HTML5/JavaScript toolkit. Games, in particular, are not going to be easily portable, especially for the ones that make use of the more advanced features that Flash provides. Another area where Flash is by far the dominant platform is e-learning, where a sizeable infrastructure and community has built up.

We think that, just as print designers adjusted to the perceived lack of control when moving to the web, interactive designers will find workarounds and solutions to the current limitations in the HTML5/JavaScript toolkit. At the same time, JavaScript libraries will only increase in power and quantity, so we expect that Flash use for new content will begin to taper off within the next 12-18 months. It just doesn’t make sense for content creators to have that duplication of effort in the longer term, especially given the current economic climate.

From the point of view of a Localization Service Provider, the move towards HTML5 and related standards is a welcome change and something we look forward to. Having your content in an easily-accessible format means that it becomes possible to process the content for translation in a reliable, safe and cost-effective manner.

While the .swf file format has long been open and documented (allowing third parties to create or edit .swf files directly), the source .fla format has been much more of a ‘closed book’. This is understandable from a business point of view, but has made for some “interesting” times for us when attempting to localize Flash content where the source content isn’t always available, or where the original content creator hasn’t created their work in easily-reproducible ways. Moving to “open” (in a technical sense) file formats should reduce these types of issues significantly, and overall lead to a more productive localization environment.

John has worked in Localization for a long, long time but remains true to his geeky origins. He knows enough about Unicode to stun a moose but can still converse with normal people, despite his apparent need to refer to himself in the third person.

While fonts play into this, the base issue is typically encoding–especially when we’re talking about browser-based applications. Every digital character has meta data attached to it, and this data has to be decoded by the rendering application (e.g. browser). This meta data is a small packet of instructions to the application which, if followed, describes exactly how to put the information on screen. This info packet contains directives about what the base character looks like, whether it’s capital or lower case, what accents may be associated with it, how it interacts with other characters around it. Interaction with adjacent characters is an important one when dealing with scripted languages like Thai and Arabic. The same letter appears differently depending on its position in the term or sentence.

Encoding is set at the system or document level. We’ll talk in terms of XML. Setting encoding happens differently depending on the text editor, but there will either be a preference option to set or else it happens at the time of the save, as with Notepad. It’s important to set that properly the first time, otherwise it can be a struggle to convert the encoding without a script later.

Encoding is declared in the document head. This is something that a developer assigns in conjunction with setting the encoding. The declaration tells the rendering application what encoding the file is set to. Sometimes a browser can figure that out without a declaration, but why leave it to chance?

It’s a very good idea to always use UTF-8 as your encoding. This is because it has become the global Unicode standard for XML and many other markup languages. Why worry about researching which individual encoding supports Chinese, Japanese, German and Canadian French when UTF-8 will support them all? Not only does it make things easier from a development standpoint, but it makes multilingual pages (i.e. one page with multiple languages on it) much easier to develop and maintain. Additionally, your entire global suite will be more cohesive because the browser (or whatever rendering application you use) will not have to switch between encodings to support different target languages.

Consider how powerful it will be to leverage Flypaper’s ability to convert between Flash CS5 and Flypaper platform. All it takes is a little code sharing and some redevelopment of the UI and now Lectora can do the same. This is good news for Instructional Designers and content editors who would be able to get a fully functioning, custom Flash course from developers and make edits and updates themselves in a more comfortable dev environment (i.e. Lectora).

Similarly, Flypaper has been moving toward a multi-touch interface which is quite progressive. Certainly Trivantis will want to employ that technology in their existing suite of tools.

Of course some of this is still speculative, but I think that time is going to bear me out on this one, and we’ll see both of those (and probably more) integrations come quickly to Trivantis’ platform.

Whatever development tool you use, it’s nice to know that there’s a way to get at the text content easily for translation and localization. I’ve posted on this topic more generally before, but I’m revisiting it now because it’s relevant. There is a fairly straightforward process for getting text out of and back into PPT files…well, PPTX files. I detailed that process in an earlier post. Using the prescribed method allows you to (1) dump all your text into a central location, (2) send that text out to translators without fear that they will change your PPTX file’s styles and (3) quickly get the translated text back into the PPTX. Then you just need to go through the presentation once and do a little tidying on the text as text expansion may have caused some crashing.

As a final note, it’s always a good idea to get an in-country reviewer to look through the presentation to determine whether other content elements (pictures, movies) or structural items (left-to-right layout) need to be adapted to the target culture.