Globalization and Translations
Multinational companies face many wide-ranging challenges when establishing a global digital presence. On the one hand, there is a strong desire to make each country site look and feel like a part of the same global organization, yet in many cases each country site may have unique requirements such as localized content, localized language, layouts that accommodate right-to-left reading or different imagery to better reflect local standards and customs.
When planning a site to meet the needs of a global organization, there are many considerations that need to be taken into account. These considerations range in complexity but each must be carefully considered during the planning and development phases to avoid the many mistakes and pitfalls common to such a rollout. Some of these pitfalls include items such as irrelevant content, design restrictions, broken layouts, inconsistent authoring experience, unsupported character sets and mixed language content.
Common Pitfalls of Site Globalization
Adobe Experience Manager (AEM) provides out-of-the-box functionality to easily create multi-language support with its Multi-Site Manager (MSM) tool. I find AEM’s integrated Multi-Site Manager tool the most robust and easy to use for creating, managing and maintaining multi-language, multinational websites. Sections of the site can be deemed the “master language” from which content is copied to the various language branches of the site using the MSM. Entire sections or individual selections are copied to the site’s supported language branches. But…
Solely translating content from a master site is not sufficient in the globalization of web properties. Problems arise when the content is translated from the master site, but it’s not actually created as region-specific content. Just because content is translated doesn’t mean it’s relevant to the regional site. Phone numbers, addresses, contact information and social links may be specific to the region and require additional regionalization, as opposed to just translation. There may be content related to products and services that may not be available in a given region, idiomatic expressions may litter the copy, and imagery may not be representative of the region, which all contribute to a regional site being disjointed. Special attention must be given to ensure the content does not contain forbidden or inappropriate material. For example, China blocks access to Facebook, so social sharing capabilities must allow for disabling selected links. Additionally, imagery that may be suitable for one region or culture may be offensive in another and require specific attention by a regional content manager to ensure it’s appropriateness for the targeted audience.
The implementation of a centralized governance model with a single approving authority over all web properties is not sufficient for addressing these concerns. The content approver must be well-versed in the language, restrictions and customs of the region. Workflow processes should be created and enforced at the regional level, such that the regional content manager has the final review and publishing authority. This is an example of a distributed governance model.
Often seen in large, multinational companies where subsidiaries and regions act nearly autonomously from each other under a common brand, a distributed governance approach works well when unique governance model requirements exist within different lines of business or geographic regions due to regulatory, political or industry differences. Authority can be delegated to regional content managers to manage their own workflows and controls while the global content team can still maintain a centralized view.
This approach is extremely flexible and gives local and regional business units the power to implement their own unique governance models to support regional regulatory or compliance environments. Common branding can be enforced but business units are given the latitude to create and approve their own content.
When regionalization is not at the forefront of design, numerous issues can manifest in site templates and designs. Layouts can become jumbled when page elements cannot handle variations in text sizes, or when the components and page templates themselves do not support the region’s language.
Page elements such as buttons do not always have enough “real estate” to accommodate longer words for different languages, which can break either the element itself or the entire page layout. Longer words push page elements across the page, causing wrapping or overlapping of elements.
For example, the main navigation bar in the image below shows what happens when the page is translated into French. As you can see, links are pushed to the left, causing them to overlap existing copy on the page because the design did not plan for the added length of text. One way to mitigate this is to employ character limits on the elements, or to allow for expansion when the limit is surpassed.
Layout does not allow for longer text
AEM supports easily establishing and enforcing character limits and other validation rules within the content authoring interface of a component. When character limits are not enforced, text in buttons must comfortably wrap within the element and allow for expansion when longer words are used. The buttons below are at the limit of their expansion without either reducing the size of the text or enlarging the button itself, and are not indicative of good design with globalization in mind.
Page elements and components should be designed to expand to accommodate larger, translated copy or have sufficient space to allow for the edge-cases for longer words.
Buttons where further expansion is not possible in French
Mixed Language Content
Some websites suffer from partially translated content, leaving the visitor with the impression that the site is incomplete, or the page was constructed without care. This is most noticeable when parts of the page are displayed in more than one language. The most common type of mixed-language content occurs when copy is embedded into graphics or photos. When these images are used across regional sites, the content can quickly become mixed-language, as seen below. At best, mixed-language content may confuse your audience, while at worst it may be completely unreadable.
The second most common type of mixed-language content involves the use of proper names, taglines or other company branding for products or services. When creating regional sites, you should always consider whether your branding and taglines should be translated. In some cases it may be appropriate to translate a tagline, while in other cases it may not.
When a regional site contains mixed-language content, links to either fully translated or nontranslated content can confuse the user. The site should warn visitors they are leaving the selected language for a different language. Furthermore, navigational items and language switching elements should be uniformly located and prominently displayed across all sites, so visitors do not get “trapped” in another region’s site if they are not familiar with the other language.
AEM provides built-in workflows to facilitate the translation and review process, including numerous connectors to third-party translation services including Translations.com, Lionbridge, and Clay Tablet, where native speakers of the language perform the translations. AEM also provides the ability to translate pages manually, directly in the tool, making content authoring for other countries a one-step process. Workflow processes are used to enforce rules that a page should not be published to the regional site until all content is properly translated, including imagery. A well thought-out site and Digital Asset Management (DAM) structure for pages and assets helps segregate content to easily target the correct regional content manager for approvals and publishing. Without a rigid site structure and taxonomy, targeting the right content manager is a difficult process and requires significant custom development to determine the correct content owner programmatically.
Specialized Layout Requirements
Languages such as Arabic and Hebrew are read right-to-left (RTL). Often times, layouts and imagery from a site’s master branch are not designed with these special language requirements in mind. For example, text within a background image requires sufficient space in the image to safely incorporate the copy and is usually displayed at one end of the image, as seen below.
When faced with using the same imagery on an RTL site, the copy may overlay the subject of the image. Simply flipping the image’s orientation on its vertical axis does not always solve the issue, especially when the image contains text in the background on items such as signage or computer displays. Templates and the supporting imagery must be designed to accommodate RTL display and reading.
Right-to-Left (RTL) Content
Components and calls-to-action should also be designed with RTL support in mind. This can be accomplished by creating a single component to support both orientations or by taking advantage of component inheritance.
AEM supports the concept of inheritance in which common functionality can be shared between linked components or linked templates, allowing for the extension and reuse of components through the sharing of common elements. When I examines wireframes and requirements, I look for common features across components and then design the component hierarchy to take advantage of this powerful feature. This significantly reduces not only the time to develop the components, but also gives the content author a familiar user interface to create content using similar components. In our examination of features within a local or regional site, we can determine how many of the components such as navigation, social integration, promotional pods, calls-to-action, and shared content can be utilized in multiple sites with little or no modification. This approach allows us to build a library of common components to use on subsequent regional site development.
Inconsistent Authoring Experience
In addition to a fully translated and regionalized public-facing site, it’s important to ensure the user interface for the regional content authors supports the native language of the content authors, giving them a robust, user-friendly authoring experience. Many times in content management system implementations, this key piece is overlooked and content authors are forced to create and manage content using a toolset in another language. All instructional copy in the component and the authoring interface should be configurable in a separate language when appropriate. This is easily accomplished using AEM’s translator interface. Key/value pairs are assigned for each supporting language where placeholder variables are used in lieu of literal copy and are retrieved using the “key.” When the authoring interface is rendered to the user, the placeholder key variables are replaced with the value in the translation table in the author’s native language.
Oftentimes, when globalization is not at the forefront of the initial architecture, copy is often “hard-coded” into the templates or components, meaning it cannot be updated ad hoc without interaction with a developer. It is imperative that all text in a component be configurable and translatable into different languages to support other regions.
Unsupported Character Sets
In some cases, there may be limitations with respect to the character sets required to create content for a given language. The need to support specialized character sets impacts not only the content as it appears on the site, but also impacts areas such as content entry, site search and SEO, to name a few. When considering support for globalization, character sets should be closely evaluated to ensure compatibility across all users.
Translation of URLs
Careful thought must be given when deciding whether the actual URL of the page should be translated. There is very little search engine optimization (SEO) benefit gained from translating the URL itself when the page content is already translated into the region’s language. However, there are some negative consequences of translating URLs. When using a tool such as AEM is used to create pages and content, the page URL is auto-generated to match the page title unless it’s manually renamed to something else. When the URL is renamed in the region’s language, it makes it difficult to track the page from which it originated. In AEM, the page title is used to generate the SEO-friendly name. When special characters or accented letters are used in the title, these characters are stripped out and replaced with a hyphen.
When planning a global site, there are many considerations that play a key role in a successful implementation. Careful planning and consideration should be taken from the outset to evaluate future requirements related to supporting multilanguage and multicultural requirements. Care and consideration should be given when evaluating things such as designs, workflows and the authoring experience in order to support regional content creation, curation and publishing. To maximize the end-user experience, design and templates should be built to not only support multicultural, multilanguage requirements, but to also provide a unified experience across all global sites. By carefully considering each of these items up front, internal stakeholders and site visitors will enjoy a personalized experience, leading to higher customer satisfaction and conversions.
-with Scott Oppliger