So, you just launched your new enterprise website on Adobe Experience Manager (AEM) with a single master language and are ready to start launching other languages to make your site multilingual. While this may seem like a straightforward multilingual content deployment project, you’ll soon discover that there is are quite a few things to think about to get the process and job done right.

Let’s break down every stage of the process—from scoping through to launch and beyond. We focus here on Adobe Experience Manager (AEM) as the leading enterprise content management system in the market, but you'll find much of this will apply if you're working with another system as well.

First, let’s begin by splitting the project up into smaller phases that we can then discuss in more detail as we go.

Step 1: Scope

Depending on your roadmap, it may have been a while since the initial scope and budget was set for the complete roll-out of all the new languages. This may have changed expectations and, as a result, the scope of the project.

When scoping a new language roll-out, there are several other considerations that need to be made:

Future content

As translation projects can easily take up to a month (or even several) to complete, it’s important to keep in mind not just the existing content, but also the future content that’s yet to be created.

Age of content

While it may be tempting to simply translate everything you have into your master language, many enterprise sites house older content that may not actually be worth translating. When reviewing your site, it’s important to consider whether content that may already be several years old will add any value once it’s translated. For example, a blog post from 3 years ago may be unlikely to gain a lot of traffic in any language.

Local content

Aside from the small variations between local languages (like American versus British spelling and grammar), localising content for specific countries can often require larger alterations to ensure that the translated information matches the quality and nuances of the original. For instance, specific regions may call for existing content to be migrated that doesn’t exist in the master language and, in some cases, even identify a need for additional content that doesn’t yet exist at all. This is the ideal time to do a full local content revision.

Step 2: Planning

Once you have clearly defined the scope, you can begin planning the project. However, in order to plan a project that launches several languages at the same time, there are yet more things to consider in addition to the main phases that we have covered so far.

Trial

Implementing a trial period is key to making the project a success. This phase allows you to make sure you are in a good place with the connector (more on this later) on the technical side of things whilst also giving you time to check that the whole team fully understands their role within the process.

One technical pitfall we often see is a lack of thorough testing which can create a number of unexpected issues, such as components not being translated, or fields being translated when they shouldn’t be. Similarly, one of the main problems that we see in terms of the process is the underestimation of time requirements. Projects like these deal with a lot of pages and content that require a significant amount of time to perfect. While it may seem simpler to just assign low bandwidth to this task, content managers and language champions require a lot of time for management, review and approvals.

AEM translation connectors

Let’s delve a little deeper into AEM translation connectors which should be a big part of your technical trial. Depending on the translation agency you use, there may be translation connectors available. Assess the capabilities of these connectors in detail because not all of them have the same features.

Here are a few factors to consider:

• Translation memory: Can you send updates for content on certain pages back through the connector and will the translation agency only translate the adjusted content? This is important for efficiency and costs.
• Number of pages per translation project: Sending thousands of pages at once will probably not work or could make the system very slow.

• Some data may not have to be translated (think about backend fields).
• Some data may just require a country/language change but no translation (think about backend fields for forms).
• Some data should never be touched and therefore not sent at all.

Exceptions / Feedback

Reserve ample time for exceptions and feedback. As previously mentioned, unforeseen technical issues may arise, particularly in the backend of the system rather than the frontend (if you have a proper design that is). The trial period can really help to reduce the number of these problems, although it’s difficult to account for everything if your enterprise site has many templates and components. Feedback rounds will get faster as you progress, but you should still incorporate learning curve time here.

Step 3: Execution, Approval & Launch

The core of the workload is execution, getting the content over to the translation agency and having them translate it. Sounds like you can just sit back and get back to work once the translation comes back right? Not quite…

Overview

Sending thousands of pages to the translation agency will require some oversight. While it does help that AEM works well with projects and workflows out of the box, it would be best to have a clear understanding of  what these projects contain and before planning a timeline and workload that the translation agency can handle. Assigning the creation and management of these projects and workflows is best left to a technical team member. It doesn’t necessarily have to be a developer, but someone with an understanding of the systems would be ideal for making sure the whole process run smoothly.

Execution

Regular contact between content and development teams is essential as issues that may arise may need input from either, or both disciplines. Sometimes it may be easier to adjust the content, while other instances may call for a more development-based approach. For example, buttons with functioning character limits can often break when the language is changed to something like Russian and the same content becomes longer. To solve a common mobile issue such as this, both the content and development teams must communicate effectively. Although in this case the broken design only needs a simple frontend fix, the teams must still coordinate to get it done.

Approval & Launch

Make sure that your approval process is precisely laid out from the start, as a lack of clarity here will cause delays and clutter the workflow with additional clean up work. It is also important to have a staging area where content managers and language champions (or any other stakeholders) can review the translated content clearly and within a preview mode that allows them to see the content as it would appear on the page. Although it may seem straightforward, you should carefully consider how to stage this so that stakeholders are able to access and review your content, bearing in mind that typically not all stakeholders have access to lower/test environments.

Examples of translation causing design errors

Step 4: Training

It is essential to implement training for any new situation or altered system. Training is usually focused on process and system changes. Operations will most likely require a new process to which the whole team will need to adjust. To keep this running smoothly, preemptive knowledge-sharing and training are required. Having the team involved during the requirements phase helps to maximise buy-in and acceptance of the new process. The same applies for system changes, involve users early in the process of requirements, before build and roll-out begins. Very often questions and concerns arise around foreign languages or character sets which can cause interruptions and confusion for the users if not trained and prepared to deal with such eventualities.

Step 5: Go Live

The go-live planning depends a lot on your DevOps and go-live strategy but should be planned carefully. This is the moment that the pages will go live and will be accessible to the public whilst the old pages and URL’s (if applicable) will go offline. Make sure there is a solid and tested launch plan and that team members know what to expect and possibly execute.

Step 6: Operations

Though perhaps not completely part of the project, it is important to start thinking about how to run normal operations. Launching new languages means there’s an impact on your marketing and content organisation and the content velocity will go up. Consider updating your processes and investigate technical solutions to help maintain efficiency, like our dashboard for translation management described in this blog post.

Finally, I wanted to touch upon the team setup a little bit to emphasise and visualise how extensive a multiple language launch project is. In another post we’ll go into more detail about how these roles work together to make a launch successful. The image below really demonstrates the magnitude of such a project. It’s likely this doesn’t even begin to cover everyone involved however, it is a good example of the core team needed to roll out multiple languages.

In addition to what roles are involved and how the team would work, there are a few other topics that we have not yet discussed, including URL redirects which cover so many things it can almost be considered a side project that runs parallel to the language launch project. Another interesting topic is live copies (MSM)—which is an AEM solution for handling master content—and how it is rolled out to other languages with synchronisation options. We’ll discuss both these topics in later posts so stay tuned!

If, in the meantime, you are looking for support on launching multiple languages for an enterprise website, come talk to us! We have extensive experience with language launches in many languages, including: Arabic, Russian, Chinese, and Japanese.