Forum Discussion

RonID's avatar
RonID
Community Member
1 month ago

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?

3 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.
    • RonID's avatar
      RonID
      Community Member

      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!

  • Holly_G's avatar
    Holly_G
    Community Member

    This is becoming a topic of discussion here as more of our content developers are creating content that will be translated in Articulate. I created some training content for my team to help them understand how to best prepare content for translation - including making sure all the text content is there first - the alt-text, captions, etc., avoiding all caps and industry jargon as much as possible, using complete sentences so the context won't be lost, avoiding images with embedded text as much as possible - this one is hard for some to get used to. 

    In Storyline, the biggest issues that I have found that need to be considered ahead of time are text spacing and audio with corresponding moving graphics. If audio is being added to a moving graphic slide, for example an introduction to a dashboard with arrows and boxes highlighting different features on the slide may appear perfectly timed in the source language but after being translated, the graphics are all either ahead or behind the corresponding audio. 

    The text boxes are a concern when designing in Storyline - you want to make sure that you'll have enough room for the languages that use more letters so that it's not overcrowded or requires a much smaller font. 

    I've encountered a number of bugs in Storyline as well - in states where the text literally changed to a different language (not even to the source language) and with multiple fonts being applied in translated versions, the layout issue finder not displaying all the issues but instead showing me text boxes that do not have a scrollbar ... it's been frustrating but is still easier than doing it all manually.