Forum Discussion
How are you designing courses for localization from the beginning?
I've been thinking a lot about localization as a design decision rather than something that happens after a course is built.
One thing I've learned from working on global learning projects is that decisions made early, including how text is handled in graphics, how media is structured, how reviews are managed, and how the course is packaged, can make a huge difference once you begin scaling across languages.
I'm curious how others approach this. What are you doing during the design and development stage to make localization easier later?
2 Replies
I haven't worked on a to-be-translated course since Articulate introduced Localization, so I don't have advice specifically for that. Here are some general tips from a "Going Global" presentation I did a while ago.
Write for easier translation. For example, avoid jargon and acronyms, and be careful with words that have multiple meanings.
Write simply, but avoid "telegraphic" writing. In other words, use articles (a, an, the) where appropriate. Those little word can clarify how other words are being used.
Use terms consistently. For example, software, program, and system are sometimes used interchangeably. But for clarity and to ensure proper translation, it's best to use just one term.
Consider the impact of differing grammars. For example, don't use the beginning of a sentence to lead into a set of bullet that end the sentence. And don't use fill-in-the-blank questions. In another language, the sentence structure might be completely different.
Consider what type of emphasis works across languages. For example, switching to ALL CAPS can't be replicated in languages that don't use upper- and lower-case characters. Italics can overly distort some characters.
Don't refer to work events as happening in a given season. When it's winter in the northern hemisphere, it's summer in the southern one.
Use the ISO date format YYYY-MM-DD. (A date like 01-10-2026 might be understood as January 10 in the U.S. but as 1 October elsewhere.)
Design to allow for widely varying text lengths. For example, in Storyline, you can set a text box to automatically add a scroll bar or to shrink the text if the translation is longer. In Rise, you have to be aware of the character limits in some blocks.
As much as possible, avoid images that include text.
Consider the impact of switching between a left-to-right language and a right-to-left language.
- Pay attention to whether or not images can/should be flipped. For example, in one of my courses, the translation folks flipped the images in the Hebrew version. But they hadn't noticed that one photo included a map of the world on the back wall. So I flipped it back to the original position.
- Avoid referring to the left or right side of the screen.
- I also avoided animations that flowed from left to right, so I didn't have to worry about ensuring the direction would be changed.
Thanks, Judy! These are great points. The one about avoiding text in images especially resonates with me. I've found that some of the biggest localization challenges can be prevented by making those design decisions early. I also really like your point about using consistent terminology. That can make such a difference once you're working across multiple languages. Thanks for sharing!
