7 Keys for Multilingual Website Projects

July 26, 2018 | Charlie Hill
7 Keys for Multilingual Website Projects

The sales team has exciting news: they scored that coveted customer in Canada. The challenge: they are in Quebec, so now your website needs to be available in French. Your mission, and you must accept it, is to ensure legal compliance by releasing a French version of the website. How hard can that be? In truth, it can be very hard. Très difficile.

But it doesn’t have to be. Here are 7 Keys to bringing order and success to your translation project.

Note: there is a technical distinction between translation (T9N), localization (L10N), and internationalization (I18N). In this article we will use “translation” in the most generic sense, where it could cover all three terms, but strictly speaking, this is really an internationalization project. For a detailed treatment of their distinction, this provides a detailed explanation.


While all projects require a clearly defined scope of work in order to properly estimate the effort, there are two unique aspects for a translation project:

  • Pages
  • Content within the pages

Are there pages or sections of the site that will not be accessible to your new customers? For example, if the site has administrator pages not available to the general public, then the scope of work should clearly define which pages are accessible to the users and, therefore, will need translating.

Adding support for another language can also involve formatting content within the page, e.g. dates, numeric values, currency, and monetary values, as well as customized pop-up calendars/date pickers. Factors like culturally sensitive color schemes and left-to-right/right-to-left layouts, which are beyond the scope of this article, introduce a whole new set of concerns. And let’s not forget infographics, images with text and various multimedia, such as embedded videos. What started as a simple translation effort can take on a life of its own if you have to reshoot video or engage your UX team for new graphics.


With a clearly defined scope of work, the engineering team can start creating a detailed inventory of all content that needs translating. Your developers may have to dig like they are looking for buried treasure, because not all content may be visible when first visiting a page. Text can be hidden in expandable accordions, pop up widgets, help and error messages, and images. And don’t forget all the hard work you put into your SEO value: don’t lose your Google ranking because you didn’t translate your meta data and other SEO-related content.

And that is the easy part. Some content may not even come from your website. Text may come from external sources such service calls to external systems or even be hard-coded in databases. Will this text be translated at the source or will you have to take on that task?

For example, I recently did a French translation project for a site that displayed a member’s usage history that came from an external system that knew nothing about supporting French. Another project stored hard-coded values in the database and, therefore, schema changes were required for their localization efforts. Nothing is so simple that it cannot be made difficult.


It is essential now that the inventory of text your engineering team ferreted out be meticulously recorded and tracked, typically in a spreadsheet with columns for the translation and any notes to help the translator. Add this file to a task in whatever tracking system the project is using (you are using one, aren’t you?). Images, videos, and other resource files that require translating should likewise be tracked in one of more tickets.

Once a set of translations in a ticket is turned over to the translator you must resist the urge to add more translations to that ticket. It is the nature of translation projects that some content will be missed in the first pass. And second pass. And…you get the point. When missing content is found, open a new ticket rather than adding to an existing one that is already being processed. This will ensure that new content will be accounted for by both the engineering team and the translator, and will provide clear visibility into the state of the project.


As implied in the previous section, it is time to send the inventoried content to a professional translator and not fall back to using automated translators like Google Translate. While those services have their place, they are not good at accounting for context, cultural land mines, choices in translation, branding concerns and, possibly, even legal concerns. Your translations should be as professional as your design, coding, graphics, etc.

To ensure the best possible result, support your translator with good organization, e.g. uniquely named spreadsheets, and sufficient context to accurately translate the text. Descriptions, screenshots, and even access to test environments can go a long way toward contextual clarity. For example, just as “cart” has many meanings in English, it also has many French translations. Knowing that the context is "shopping cart” may narrow down the desired translation to “panier.” But maybe not. Your site may choose other phrasing e.g. for branding purposes when a word is used in a specific context. Help your translator help you.


It’s beyond the scope of this article to explore the potential technical coding challenges, but there is at least one common pitfall to be aware of: accidentally deleting translations. This happens more than normal in a localization project because translations are commonly stored in centralized resource files, making it easy for a developer to delete another’s translation and not notice it such as when resolving merge conflicts. To compound the oversight, since most frameworks use the default language for a string if the locale-specific string does not exist, this omission is easily overlooked until released to production.

To help protect against this, use appropriate branching strategies and group work by source file, where possible. When all translations have been added, auditing all resource files will help to uncover any translations that were either inadvertently missed or deleted, e.g. ensuring all language resource files have the same number of lines, etc. The final line of defense takes us to our next key for success: testing.


Translation projects need to be verified for correctness in three specific areas:

  1. Content
  2. Rendering
  3. Format

While verifying content is simply making sure that the text is in the correct language, verifying the rendering is ensuring it displays correctly. This can be a problem if the website is not using the correct character encoding and if the new language uses special characters, e.g. words like schön and compañeros. Additionally, words with apostrophes, where the English equivalent had no apostrophe, can be particularly troublesome because they can interact in unexpected ways with the code that is rendering it, especially if it is in code that uses single quotes.

Verifying format - ensuring the translated words fit in their assigned space in the supported range of devices and browsers - is key since translated words and sentences are seldom the same size in all languages. While your site will usually handle this variance fine, it is common to find problems where there is limited room, such as buttons, menus, and of course, mobile apps, where space is a premium. This may require working with your translator to find shorter alternate translations if space cannot be adjusted.

Because of this uncertainty, ALL translated text should be manually inspected, including error messages, tooltips, and help messages. Even if a word looks good on one page, do not assume the same word will be rendered correctly everywhere. Make sure that the first person to see incorrectly encoded text is not your customer, client, or users.


A localization project can have unexpected marketing implications, especially if you changed your site structure. Are the translations separate pages on the site, or the same page with different content? For larger projects, have you split off your translated content into a subdomain or subdirectory? If the answer is yes, the impact may stretch beyond user experience and impact areas like search engine optimization (SEO), digital analytics, and ease of reporting.

For SEO, you'll need to consider special flags on translated pages to tell search engines who to show the page to based on the user’s language preferences and/or location. Depending on site structure changes, a separate Search Console account may be needed, and analytics code may need to be adjusted. It’s important to keep those teams in the loop and ask for recommendations before you’re too far down a specific option.


The simplicity of a translation project can be deceptive. While the goal is straightforward, it is important to not underestimate the effort or to simply jump in and start replacing text. The keys outlined here will help you realistically estimate the project, set the team up for success, and make that strong first impression to your new customers by delivering a website that displays flawlessly in their language.

Bonne chance!