The Process of Making our Marketing Website Multilingual

Dimitris Glezos
August 1, 2016
7 min read

Part 3: Implementation and Launch

We’re finally back with part 3 in our series documenting our process for making our new marketing website multilingual. We hope you’re finding this to be a useful process example for how you can make your site multilingual too.

In part 1 of this series, we discussed how we determined the languages we’d publish our website in and the translation method we would use to deliver the content. In part 2, we discussed which content and sections of the site we’d translate, and how we’d prepare our translators with the right background information and resources to get the job done.

Now in part 3, we’re going to cover how we implemented and launched the site.

The Technical Side of the Equation

Our new website (like our old one) is a WordPress.org site, with a custom-designed theme. Our Transifex Live solution is ideal for our site, like it is for so many similar businesses. And we have our WordPress plugin to enable our advanced international SEO functionality; the plugin is available for anyone to use, downloadable from the WordPress plugin directory.

What this means from a practical perspective is that we first completed the process of building out our new site templates, designs, and navigation in our staging environment. It may seem obvious, but it’s important for companies that are redesigning and localizing in one large project to understand that effective localization cannot happen with incomplete source content. Your project timeline must accommodate these two items as discrete steps. You can launch your new site in your home language first, but if your objective is to launch all your content at once, you’ll need to have time in your launch schedule for your translation work. You’ll need to accommodate time for your translators to review the source pages, translate the content, review for quality and consistency, and then launch, all after your source site is (nearly) complete.

So for us, once we were nearly done with the implementation, focusing first on the sections of the site that would be translated, we set to work on implementation. That involved creating a new Transifex Live project in the platform, installing our WordPress plugin, and adding our API key in the plugin.

The next few steps included:

Creating our URL structure

In order to take advantage of the SEO set-up, we needed to create our language subdomains first. For a variety of reasons, we decided to use subdomains, so we would have our localized sites displayed on fr.transifex.com, for example. With the subdomains created we were then able to use our plugin to map our content to these subdomains, and the plugin automatically inserted our hreflang tags — pretty cool, huh?

Organizations using Transifex Live with our SEO plugin have the option of using either subdomains or subdirectories, based on their specific business requirements and preferences. To get more information on how to determine the URL structure that’s right for you, you can download our Essential Step-by-Step Guide to Website Translation.

Get our Website Translation Guide

Download now

Collecting strings for translation

The plugin also inserted the Transifex Live JavaScript into our page headers, which meant that all our content was automatically crawled and pulled into the system. We didn’t have to do any manual uploads because Transifex Live is designed to simplify this part of the process for website publishers.

Then we used the Transifex Live sidebar to go through the site and select all the strings we wanted to translate. This enabled us to place our translation orders with our partner e2f.

Tags and other supporting content

Although we discussed in great detail the determination of which customer-facing content sections would be translated, we did not get into the details in our last article of supporting content, like page descriptions, title tags, and more.

As you can see from the image below, these elements must also all be translated for every page where you are presenting translated customer-facing content. These are strings that must be collected and provided for translation in order for you to both deliver a complete experience to your multilingual end users as well as provide Google everything it needs to recognize your pages properly.


Creating the Right Customer Experience

Our next step was to review the site through the eyes of our customers. This phase of the implementation also involved some technical work, but the goal here was to create the best experience for our visitors who consume our site content in other languages.

As discussed in part 2, we are primarily publishing our top-level marketing pages in our translated languages, so not our long-form content that is presented in our resource library, for example. But our navigation still includes these elements of the site, and our homepage, in fact, promotes some of our most-consumed long-form pieces.


So how do we deal with these elements that won’t be translated in our current implementation so that we still provide our French-speaking visitors, for example, a good experience on the site?

In the case of the home page promotion of long-form content pieces, we’ve inserted a snippet of code that detects the current language selection in the browser, then hides this section of the page for visitors who have selected a language other than English. The resulting French home page then looks like this:

This then gives the French site visitors the appropriate experience, neither promoting content pieces to them in French that aren’t really available in French (if we presented a 100% translated home page) nor presenting them a wonky-looking home page with one section in English. Mais oui?

If you’d like to leverage this same technique, here’s an example of the CSS code snippet we used:

What about navigation?

Just hiding these sections is not an option as this tactic is not feasible when using Transifex Live.

What is feasible, however, is having the links to the English content open a new browser tab so that when a French visitor selects “Blog” in the navigation, the English-language version of the blog becomes available in a new window, while the French language navigation and content is still available to the visitor in his original window. Perhaps the visitor has some English proficiency and the blog content is then still available to him. Often developers are able to navigate technical articles in English, so this ensures that these types of articles are still available to our developer audience, for instance.

Is this optimal? Maybe not, but as presented in part 2 of this post, we don’t yet have the bandwidth to support translating all our published content, so this technique provides the best experience for the user given our current business capabilities.

The key takeaway is that you don’t strand your users, and you don’t overpromise by presenting them a link in their native language that then takes them to English (or another source language) content, leaving them feeling confused and dissatisfied.

The Finished Product

The result is that our site is up and running, serving our marketing content in our selected languages. From here, we’re working to maintain the content and experience, and measure our results. We’ll be returning with more on this on-going phase in a few weeks.

Dimitris Glezos

Subscribe to
Becoming Global

Get localization news and best practices delivered to your inbox each month.

FacebookgithubGoogle+Fill 88Twitter