Design for International Markets

Voice experiences aren’t restricted to a single market. You can publish your experience to additional international markets where Alexa is available. When you do publish to international markets, plan the design of your experience to accommodate language and cultural differences.

In this article:

• Localize for different markets
• Best practices for localization
• Build in localization
• Internationalize visual design

You've likely had the experience of reading the instructions for a product made in another country or language that the company translated poorly. The odd cadence or poor grammar makes it clear that the author was not conversant in your language or culture. Poorly translated and localized content negatively affects the user’s experience and trust in that product. When you do a poor job translating and accommodating cultural differences, it negatively affects your skill and it erodes trust with Alexa across different markets.

If you want to offer your skill in different international markets, you must localize the content to fit the language and cultural norms of that marketplace. Even within a country, you can have multiple dialects and cultural differences that you must account for. Different marketplaces also have different technical requirements set by the laws of that country that you must consider. You should design your skill to be flexible enough for the translation and cultural requirements per marketplace. You should consider localization as not simply language translation; it’s a cultural shift in the way Alexa converses with users.

When you design your experience, be sure to explore beyond the native culture and languages of your marketplace. Ask yourself the following questions when you design your skill:

• What countries and languages do I want to support and maintain over the lifetime of your skill?
• What level of translation and localization do I need? Do I have access to a native speaker for my localization work?

Keep in mind the following best practices when you design your voice experience for international markets.

Write short, complete sentences

Long, complex sentences are difficult to translate, and difficult to understand. Be mindful of long strings of nouns or adjectives, or long sentences that work better as short ones. While a given phrase might seem long now, it can be three or four times longer in languages with different grammatical structures, such as German or Turkish.

Avoid colloquialisms, puns, or local jargon

These cultural turns of phrase might have no equivalent or could be misconstrued in other languages, regions, or even a specific cultural demographic. Work with translators who are native to the region to help you find equivalent terminology only if it’s critical to content of your skill. For example, acronyms like “FAQ” doesn't translate well. Neither does “nine to five," because other countries and regions have different concepts on how long a work day is.

Define and use terms consistently

Be consistent in how you present certain names, terms, or actions in your skill. You might have to provide your translator a definition for the terms you’re using so that they help you find the appropriate term in the translated language.

Review all content for geopolitical inaccuracies or sensitivities. Check your skill’s content for culturally sensitive topics or terms that could cause offense. For example, an image in one culture can have a different meaning or can be offensive in another culture. You must check both the verbal and visual content to make sure you’re not offending your users in different markets.

Images have special risks that you should consider:

• Flags (flags are recognized differently by some countries)
• Maps (boundaries are recognized differently by some countries)
• People (including gestures, hands, feet, and race)
• Symbols and icons (national, political, religious, spiritual)
• Mature and risqué images
• Cultural inferences of colors, numbers, names, or events

When you build your skill for other marketplaces, consider the following best practices:

• Use Unicode (UTF-8) in your text.
• Prepare to handle location data by country, such as region or zip code.
• Plan for input handling changes by language type, due to different linguistic structures.

Don’t build prompt structure into code

Different languages place words in different order. A noun phrase is a noun plus, optionally, adjectives and articles. Grammatical rules in a respective language dictate in which order these words must come. When a noun phrase (NP) contains dynamic content (variables), don’t concatenate it.

Avoid string concatenation in code

Concatenating strings affects both internationalization and localization. While a common coding practice, don’t concatenate multiple strings to form a sentence. Although the strings concatenated together might form an acceptable English sentence, many languages have different grammatical rules. Translators might have to change the order of the words in a sentence, which could be impossible to do if you split a sentence into multiple strings.

Word order by language

Don’t concatenate either the subject or the object (code dictates the order of words). Code the string as one string and let translators shuffle the variables in the string (if either the nouns or adjectives are the variables). In addition, the adjectives and articles must agree in gender and case with the noun and its function in the sentence (subject, or direct or indirect object.)

The following table shows an example of word order differences by language.

When translators localize an English experience, the user interface and any other text typically require more space due to the different linguistic structures. As a rule, languages other than English have longer words, longer sentences, and might have larger characters (non-Roman characters). In addition, any data, such as dates or numbers, might take up more space as well.

Use overlays, layers, or callouts with graphics

Just like translating the strings in the UI, you also must translate any text in a graphic. If text is embedded into a graphic, it becomes much harder and expensive to update the graphic with translated text when the time comes. The best way to avoid dealing with localizing graphics is to minimize using graphics in the first place or to remove text in graphics.

Review all images

Use general images that are appropriate and easily understood in your intended countries and marketplaces. Cultural references may not be global. Even literal imagery can feel foreign. For example, mailboxes and tractors look different in Japan. If you use general images that you can use for a worldwide audience, you don't have to replace them when you launch globally or across different countries and marketplaces.

Beyond checking to make sure that images are appropriate for each culture or country, you also should make sure that the images display properly in each locale and if the right images are even displayed. For example, do the translated text overlays display properly on the images?

Apply the 30% rule

Account for at least 30% more space on your UI components around text. For example, some strings translated from English to German take up to 50% more space. To make sure you have enough space, test your content strings as soon as possible. Give yourself enough time to redesign the UI in case the translated text doesn’t fit.

Plan for line wrap and truncation

Your design should expand to fit the additional lines of translated text without seeming clunky or unreadable, especially for essential items such as navigational elements. If you can’t read the text without scrolling or truncation, have your translator specify where appropriate truncations should occur. You must define line wrap and truncation behavior for all layouts by using the text component. Use the maxLines property in the text component to call out text components that limit the number of lines – single line, two lines, etc.

Keep text labels short on buttons

Button labels should be short and concise so that translated versions can still fit in the same layout. If the English version is too long, in translated versions the button elongates, which pushes other UI elements off the screen. The same problem also often occurs for users that choose to enlarge the UI font size for better readability. Don’t put everything into a button. Break it out into body text above the button and keep the action-oriented text of the button short. For example, “Okay” or “Cancel.” If you can, avoid placing multiple buttons on a single row.

Minimize different font styles and capitalization

Writers often use font styles like bold, italics, underline, strike-thorough, and capitalization (such as making a label all capital letters) in English or other Roman-character languages to emphasize or visually differentiate certain text. When you use title capitalization or all capital letters, you must allocate more vertical clearance (line height and spacing) because some languages with heavy diacritics need more room to accommodate uppercase letters with accent and descent than in the same lowercase letters. However, some font styles might break language scripts, such as Chinese, Japanese, Arabic, and Hindi (to name a few) that don’t use bold, italics, uppercase, and lowercase. Instead, differentiate your text with formatting such as foreground/background color, quotation marks, visible borders, etc.

Consider the effect of spaces between words

In certain languages, such as Japanese, words don’t have spaces between them. This difference makes it difficult to process tasks like disabling substring matches. Because there’s no hyphenation or spaces between words, there’s no easy way to prevent "widows" in GUI displays programmatically. For example, the last line of a string might contain only one character.

Avoid multi-line clauses

Allow the line to wrap naturally instead, or break the clause in such a way that the parts are grammatically independent. When a single clause is broken into multiple lines, it can cause grammatically incorrect translations. Translators translate each resource independently and the translations, when visually combined, don’t make sense or has incorrect grammar. This problem can also happen when a string has embedded newline ('\n') characters, which translators don’t know what to do with and don't translate them. This is because many translation agencies don’t see the final on-screen placement of the text while they are doing their work.

Avoid dynamic text elements

If a multi-line clause includes an argument to be substituted dynamically, the translated string as a whole might not make grammatical sense. This is because the placement of the argument is forced to be at a certain position in the clause. To produce grammatically correct translations for such clauses, you must adjust the position of the argument within the clause. Translating variable text in a grammatically correct way requires knowing the grammatical gender and cases of the text being substituted in, which might not be information that is available.

This translation also requires a different message template for each potential grammatical gender and case. Instead, try rephrasing the message so the argument or variable element is omitted. If that's not acceptable, try rephrasing into a "subject:predicate-nominal" form. For example, the message, "Sort by <title|author|recent>," often appears as a button or other UI control. The verb "sort" and preposition "by" need to change gender in some languages depending on the dynamic text. Rephrasing into "subject:predicate-nominal" form, "Sort Order: <title|author|recent>" simplifies the implementation for proper localization.

Adjust numbers, dates, times

For date, time, phone number, file size, and other general number formatting, follow local custom.

The following table shows examples of dates and times in different locales.