We have also localised an abundance of material over the years for our customers and much of this content has not been designed with localization in mind. Materials are often created by third parties such as external design agencies, and even if the same agency is used continuously by a client, the developers within these agencies change, and each time their approach differs. Only one aspect remains consistent – nobody has even thought about localising the material for the rest of the world.

In this paper we outline some of Brandt’s best practices in designing multimedia content with localization in mind. We have tried to keep the advice technology unspecific, although there would be a bias towards Flash as it has become so ubiquitous. These tips will help you think about your content from a global perspective and ultimately could save you time and money.

Size issues: “We’re gonna need a bigger boat!”

In localization text generally gets longer, sometimes 25% longer or even more. When you look at a mock-up of a design, just think of what Roy Scheider would say, and leave yourself plenty of room. What comfortably fitted on one page in a good font size might now need an extra half page, or a smaller font.

The same applies to menus. Your English menus may have had words of six or seven letters and fitted comfortably across the horizon of an interface. When translated, they suddenly run off the edge of the screen when they are expanded to ten letters each. Some designers may not like the idea of an unknown length of string in their design, but ALL designers should be able to design around it.

As well as translations requiring extra space in a design, extra menu options might be added or omitted for a particular country’s market; your design (both visually and from a technical aspect) needs to be flexible enough to deal with this.

Mac and PC: Development choices

While there are many final delivery formats that bridge the gap between Mac and PC, you should be aware of limitations of the development environment across platforms. Your client may need to revisit the development files on a Mac while you may have developed them on a PC. With Adobe / Macromedia products this has become a lot more seamless in recent years, but testing in advance is advisable. Also, see the section on font mapping for example.

Fonts

When choosing fonts remember to check if they contain the full extended character set. For example, they should contain accented characters (like à é è â ä å ç ê) and currency symbols (like ¥, €,ƒ or £). If they do not, the font may need to be changed or these characters created especially for the chosen font.

Font Mapping & OTF fonts

Multimedia development often spans multiple teams and platforms, for example a Flash project might contain animations from a graphic designer working off a Mac and then be given to a coder for actionscripting on a PC. Even though the same font might be installed on both the Mac and PC they are often called by differing names, or have slight deviations.

You often get a ‘font mapping’ dialog box asking you to choose a mapping from each font contained in the media file to the fonts installed on your system. Mapping the fonts can be hit and miss; you may not be sure if it should be extra bold or extra black, light condensed or just condensed.

To ensure consistency across PC and Mac platforms use Open Type Fonts (OTF) where the same physical OTF font file is installed on both the PC and Mac.

Audio scripts

When creating audio scripts, beware of scripting any items that are liable to change even in the distant future. These items should appear on screen in easy to alter text and referred to rather than explicitly spoken. A good example of this would be a voice over that mentions prices, dates, or machine specifications. If these are recorded and the prices or specifications change, you will have to go back to studio. If you must record these, include in the script alternate and additional takes which can be used instead.

Keeping your text editable

In your multimedia development environment keep all text editable. Rasterizing text (converting to a bitmap image) means that you cannot edit it easily. With Flash there is no reason to do this, and yet often we see bitmaps of text within flash files. This has the effect of both eating bandwidth and taking time to edit and replace. If an effect requires you to rasterize the font, then find another way to do it. For Photoshop graphics remember to keep the layered graphics along with the final flattened images.

No ‘letter by letter’ animations

Painstaking ‘letter by letter’ animations (which involve timeline keyframes of individual letters making up words) should be avoided. This is because the process must be repeated across multiple languages and with varying lengths of translations. The implication of this is that you cannot create a cross-language template because each language translation has different lengths. Instead use code to create this effect or choose a different animation type.

Be aware that animations that work with English content may not work with localised content. This might be due to translation length, sentence structure, icon/image confusion or the inability to be able to use three letter acronyms. You won’t always know in advance if this is the case, but being aware of it may mean you avoid hinging your design on a concept that might not work globally.

No embedded strings

It can often be a fast and tempting quick fix for a programmer, but in your development environment do not write code containing strings of text that will appear on screen. It is often quite hard to find or debug these and they are hard to translate as they are usually out of context. See also “Externalise your on screen text”

No concatenated strings

Using concatenated strings (where strings are programmatically joined together to create sentences) can be a fast way to develop applications based on one language. For example, “click on … the blue…circle”. However, they open a veritable Pandora’s box of coding problems for localization due to multiple numbers of genders for nouns and differing verb/noun word order across languages. You often end up having to have separate code bases for each language model.

Externalise your on-screen text

Most multimedia development environments now allow some method of externalising text into either an XML or other readable text format. This is then loaded into the media on the fly. The advantage of this is that it is easy to update or localise of the media without opening the development environment. It separates the style from the content and allows translators to work on the file without being in a development environment which they may not have, or which they may be unfamiliar with.

Pseudo-translate your media

If you want to see if your media will localise without any issues, you can pseudo-translate it by taking the strings and translating them using a free online translation website and then reinserting. This will give you an idea if your accented characters are supported and also whether space could be an issue with the translation length. See also the “Fonts” section for the treatment of extended characters.

Program in some shortcuts

When developing large interactive multimedia applications such as e-learning, games, quizzes or product matrix recommenders, include some code that allows you to see and alter your location within the application. This allows you for example to get straight to a screen where you know you have a bug, rather than having to wade through 14 screens or clicking 40 answers to get to where you want.

Creating and choosing graphics

Care should also be taken when creating graphics or sourcing stock imagery for a multimedia project. Avoid adding text to graphics where the expansion of this text will make the image look unbalanced. Remember that culturally there are different interpretations of what symbols, imagery and colour can mean. Also, imagery using visual puns should be avoided as it is impossible to localise across multiple languages.

Full quality layered graphics should be retained and provided for localization alongside the final graphics, for example, Photoshop PSD files, where each element/layer in a graphic can be adjusted, including text. Any specific graphics effects should be documented, as should the fonts used.

Video

Development of video poses its own set of challenges when it comes to localization. Care should be taken to keep the original uncompressed video as it often the starting point for localization rather than using the compressed finalised files, where much of the quality has been removed. Avoid overlaying and rendering text into the video field if possible, as it cannot be removed. For subtitling video content, consider using a final format that will allow subtitles to be created on the fly without being burned into the video, such as MOV or FLV with a player that synchronises the subtitles over the video.

For all aspects of video production, a detailed list of the software used, version number, effects settings (with screenshots if necessary), fonts used, raw music backing track (without narration), final compression software settings, original uncompressed sources, graphics and any other “ingredients” used to create the final video should all be stored together and archived for later use. Typically this will be a large archive, but is necessary for any future localization process.

In our experience, getting the correct archived video sources from a client has typically one of the longest lead times compared to getting anything else. Clients often do not realise that the final video files will not be good enough, and/or they do not know where the individual assets are.