<!-- Content Here -->

Three reasons why website localization projects fail

Many organizations go into website localization initiatives unaware of the complexities and best practices involved. When this happens, frustration is the usual outcome. Having seen a number of localization efforts struggle, I believe that the root causes fall into the following three categories. The good news is that all of these problems can be avoided with experience and planning.

Localizing the Long Tail

Choosing the first few markets to localize your website for is relatively easy: look for the ones with the most obvious market potential. A U.S.-based company may start with U.S. Spanish and Canadian French and then expand into some of the larger European and Asian markets. A company that has some history as a global business, may already have a physical presence in those high-potential markets. Subsequent waves of expansion, however, create some trickier choices. Should your next market be Poland or Brazil? Maybe the Korea holds the most promise. The thing is that you just don't know true market potential until you try and it may take a while to realize whatever potential exists.

At Lionbridge, we recommend grouping your markets into three tiers:

• Tier 1: Highest Revenue

• Tier 2: Fastest Growing

• Tier 3: Everyone Else

Tier 3 represents the greatest strategic challenge. You want to have a good quality presence in as many markets as possible. After all, outside of your home market, every market starts out as a Tier 3. If you enter a market, you need to do it right with an effort that is worthy of your brand. You also need to commit to maintaining that site into the future, otherwise you will fall into the "time capsule syndrome" where your local market sites look like they were frozen in time ages ago. But you have limited resources and you don't want to divert spending away from markets where you are succeeding.

To get into as many markets as possible without breaking the bank, you need to manage your localized sites extremely efficiently. The best way to meet that challenge is to use a translation proxy in a pattern that I call "International Mini-Site."

When you use a translation proxy, untranslated content is going to show through in the source language. In an earlier post (Preventing Source Language Bleed-Through), I talked about preventing this from happening. But that assumes that you want to pay to translate everything into all of your languages — and your Tier 3 sites may not justify that expense (not yet, at least).

The international mini-site pattern is like the "international snapshot" pattern but, instead of translating the full site, you proxy a much smaller site that is designed to have just enough information to get traffic and build business. Brevity, efficiency, and quality are key themes here. The international site should be cleanly branded (adjusted for culture, of course), search engine optimized, and ruthlessly edited to remove content that has organically grown over the years on your main site. If your main site (with all of its press releases, careers section, case studies, etc.) is 1,000 pages, your international site could be as little as five pages. Just explain what business you are in, describe your products, and direct customers where to buy. I often see this pattern in conjunction with using a platform like Marketo for marketing campaign landing pages (which can also be translated with a proxy).

Once you have your international mini-site, you can easily manage your translation spend. You can make choices about whether to make a global edit that you will have to translate into all languages, or do some locale specific rewording to improve search result placement in a local market search. Most importantly, you can manage your Tier 1 and Tier 2 sites without worrying about the cost implications of having to translate new content into all of your Tier 3 languages.

Just because the international site is small, it doesn't mean it is not important and you don't have to manage it. On the contrary, you need to pay as much or more attention to it. Because you have less content to work with, every word needs to count. This is where many companies go wrong. They treat their international sites as redheaded stepchildren rather than strategic assets with potential to uncover new growth opportunities.  By staying small, you can be more agile and responsive.  You can focus more on each page to optimize the impression it gives.  You might even find that your main sites would be better served by a major Spring Cleaning.

Preventing Source Language Bleed-Through

When considering a translation proxy to localize a website, people often ask "if we change the content on the site, what will visitors see while the translators are working on the new translations?" Unless you are using machine translation as a backstop for untranslated content, your source language is going to show through. This is because a translation proxy doesn't cache full pages. Instead, they apply translations one fragment at a time. If it doesn't have a translation for a fragment, the translation proxy will register it as a new string to translate and send the original text through. This is a necessary trade-off to support dynamic websites. You can shorten the period of bleed-through by increasing your translation responsiveness and throughput, but to prevent bleed entirely you need apply one of the following techniques.

These two techniques are really just variations on the same theme of pointing the proxy at two versions of your site: one for content discovery and another one for production.

International Snapshot

The "international snapshot" approach is where you create a non-current snapshot of your production site for international audiences. Depending on your translation velocity, this could be anywhere from a day old to a month old or more. Content discovery and translation is still done on the live site. But when an external visitor browses the site, they are getting a proxy-translated view of the snapshot. There is no bleed-through from the snapshot site because by the time the snapshot is refreshed, all of the translation rules have already been published. Here is a picture

This is what we are doing for the new www.lionbridge.com website. We wrote some scripts to do a full snapshot of the site (code, database, and other files) to another virtual host on the same servers. If you are using a more sophisticated platform than Wordpress, you could probably set up another publishing target and just publish there when you want to update your snapshot.

Translate Staging

The "translate staging" option follows the same pattern as international snapshot. With translate staging, however, you do your content discovery and translation on the staging server (which has content which hasn't been published yet) so your translations are ready before you publish your content. Once your translation queue is down to zero, you can publish your source content to your live site and the translation rules will be waiting to be used.

With "translate staging," you need to make sure:

1. Your staging site is publicly accessible. You will not be able to view the site through the proxy unless it is available on the public internet. For security reasons, you can limit access with a firewall and also add authentication to the staging site.

2. Your staging site only contains translation ready content. If you have are using your staging site for your editorial process, you might wind up discovering draft content that will never be published. Since this is obviously a waste of time and money, it's best to create a staging instance that only has content that is ready for publishing.

Here is a summary of the process

What to choose?

Which approach is right for you depends on your requirements. If, because of regulations or communications policy, you are required to publish new content to all languages simultaneously, you need to go with the translate staging option. If, like it is with us, you can allow your localized sites to lag behind the primary site, the international snapshot option is usually most attractive. And, of course, letting source content leak through may be acceptable if your site is less formal. The most important thing is that you have options.

Prioritizing Your Markets with Tiers

I have a lot of conversations with Global Marketing Operations customers about global content marketing strategy. Even though it is a small world, there are many markets on this planet and you need to be strategic with your investments to reach them. The model that our customers find most helpful is where we break down markets into three tiers

• Tier One

  Tier One consists of your top revenue producers. This is usually your home market plus a couple of nearby markets that have been doing business in for a long time. Companies that are new to internationalization may have only a single Tier One market. — any business from outside the home market is purely accidental. Mature global businesses might have 3 or 4 tier one markets. Some of the larger companies have up to 10.

  Tier One markets should have their own regional offices with marketing departments that are capable of generating original content that is tuned to the interests, culture, and calendar of local population. You can optimize the efficiency of these local marketing teams by translating and re-purposing content from your home market. But with that much revenue at stake, you should have a local presence keeping an eye on things from a local perspective.

• Tier Two

  Tier Two is made up of your fastest growing markets. Revenue may be small today and growth might be a short term anomaly, but you want to nurture these markets because some of them might have potential to be new Tier One markets for you. Collectively, Tier Two might be responsible for a considerable portion of your overall revenue grotj. You want to treat these markets with a first-class experience but you need to do it efficiently. Balance cost reduction with experimentation and responsiveness to opportunity in Tier Two. You want to tune and experiment to see what response you can get from these markets. But you don't want to over-invest because the long term potential may not be that great.

  Most of the content that you serve Tier Two markets is going to directly localized (translated and adapted for cultural compatibility) from the home market. Of course, you want to be able to filter out what you know will not be relevant. You should invest in things like local search engine optimization and social media and be paying very close attention to web analytics and sales data. You may need a local marketing team to do this, or you may not. Perhaps you land the local marketing team when the market shows movement toward your Tier One zone.

• Tier Three

  Tier Three is the long tail — all the markets that don't fall into tiers 1 and 2. You want to maintain a quality digital presence in these markets but you want to do it cost effectively. If you are successful, cumulatively Tier Three could be a decent profit source and can be the farm system to recruit your next Tier Two markets. Otherwise you will either over-spend or one of your competitors will beat you into a market with great potential because you didn't invest enough.

Market tiers should also drive your content technology architecture. If you have multiple, distinct Tier One markets, you will need a CMS that supports multiple semi or fully autonomous sites. Depending on your governance model, you might need to be able to "lock-down" certain site sections to give centralized corporate marketing direct control. Some companies are totally decentralized and allow Tier One markets to operate their own instance of the CMS. I wouldn't advise different markets going with a totally different CMS platform. Doing is more expensive because you need to maintain more expertise and you might need to do integration in order to share content.

Tier Two might start out with a translation proxy as long as the proxy technology allows you to easily filter and/or replace content. As it inches toward Tier One, you might want to give a Tier Two market a sub-site as long as your platform allows you to efficiently replicate and localize home market content. Otherwise, supporting the sub site will be more work than it is worth. Whatever you do, try to discourage Tier Two markets from building out their own infrastructure. It is costly and will be difficult for them to maintain to the level that your brand deserves.

Tier Three markets should never run their own websites. This is where embarrassing happen like butchered logos and layouts that look like they were stolen from GeoCities or MySpace. In my opinion, translation proxy is 100% the right choice for Tier Three. A useful technique here is to build smaller "International Site" on your home infrastructure. This site is style-guide compliant and brand-worthy but has pared down content and functionality. You don't update it as often and you avoid time sensitive content like an "upcoming events" section. Then you use a translation proxy to efficiently localize this site for all your Tier Three markets.

Most companies stumble into internationalization after years of vague expectation. They know there is opportunity outside of their home market and plan to get there one day. Then they find some compelling event that initiates a poorly executed project. This could be rogue site implemented by a team without time or budget. Or it could be a monster project that gets scuttled when people start to realize how hard it is to retrofit a WCMS for internationalization. If this sounds like your company, don't feel bad. You would be surprised how big and well known companies struggle with this.

The good news is that by strategically targeting markets and making the right investments to get there, you can easily outperform most of your competition.

Retro-Fitting Your WCM System for Localization

Not long ago, I wrote a post called Planning for Localization to give tips for enabling internationalization even if localization is not part of your initial launch requirements. As I mentioned before, internationalization is one of those requirements that gets de-scoped with much regret later on. How bad is it? In my experience, enabling internationalization post launch is often a non-starter.

The work involved breaks down into 4 categories:

1. Presentation template localization. Swapping out static strings for references to resource bundles or creating language-specific variants of templates. The level of effort depends on the number of templates and the extent to which they have static text. Text within images is particularly bad because finding the source files can be a real challenge.

2. Repository re-organization. There may be some work to re-organize the content hierarchy. For example, you might want to drop the primary language down from the root node to make room for other languages. This may affect the URL structure and you might need to do URL rewrites. Different platforms have different strategies for handling multi-lingual content. In the best case scenario, every asset has the built-in capability of being multi-lingual. In the worst case, the repository doesn't support internationalization at all.

3. Workflow updates. This is work to update the workflows to add steps for localization or triggers to instantiate a translation workflow when the asset in the pivot language changes. There is also an organizational aspect here. Often you need to have someone with both the language.skills and access to the staging area to preview localized content before publication.

4. Language fall-back logic and other multi-lingual configurations. This is kind of a catch all for any type configuration that you would skip on a mono-lingual website and only do for a localized website.

I asked around my network of systems integrators for their experiences and they are consistent with mine. Several of my colleagues said that an internationalization retro-fit often costs as much as a complete do-over. That can be in the $200,000 to $400,000 range. You might also need to add another couple hundred thousand dollars to license a new WCMS if your current platform doesn't have strong internationalization support. Others came in a lower worst case scenario of around 50% of the initial implementation cost. Of course, the level of effort depends on the size and complexity of the site, the native internationalization capability of the platform, and the number of internationalization corners that were cut in the initial implementation.

The problem is that you don't really know the extent of re-work involved until you start the project and dig into the code. Sites that have been around a while often have functionality or display templates that are rarely or never used. You still need to internationalize them just in case. Also, if you are working with a new systems integrator, they need to assume that the initial implementer didn't know what they were doing and buried stinky code all over the place. It's a bit like when you open up a wall for a small home project and you realize that some serious structural problems need to be addressed before you do anything else. So any fixed-bid proposal is going to be based on a worst case scenario of having to do extensive refactoring.

The systems integrators in my network have started to plan for internationalization in all of their projects. They ignore their client's request for a U.S. English-only website because eventually someone is going to realize the market potential of U.S. Spanish or opportunities for global expansion. If you are building a new website, make sure that your systems integrator thinks this way. If you are considering internationalizing your mono-lingual site by adding a new locale, the most practical solution is to deploy a translation proxy, which hosts the translations outside of your website. This means that no retrofitting is required and you can avoid all of that expensive and risky rework.

Google Language Tags

If you were not able implement a host-based strategy for your Global Business URLs, you might be able to implement Google's rel-alternate-hreflang tag. This article, Giving Google better instructions about language and country, provides a good explanation.

The basic gist is that if you are hosting multiple localized sites on the same host and using paths to keep them separate, Google is going to think that your UK site is just a duplicate of your US and just index those pages once. This will send UK traffic to your US site and undermine the value of your localization. Putting this link tag in the HTML head


<link rel="alternate" hreflang="en-GB" href="http://www.example.com/en-GB/about" />


will tell Google that there is a UK version of your US about page under /en-GB/about.

Reading through the Google documentation, it is probably a good idea to use this tag even if you have your different localized sites under different hosts. It can't certainly hurt.

Planning for Localization

Localization can be an elusive requirement for a website. During the platform selection process, internationalization is often listed as a "strong" requirement. Why wouldn't you want the ability to reach new markets? Then, during the implementation process, localizing gets downgraded as a "nice to have" or "future" requirement as time and resources dwindle and compromises need to be made to launch the primary language site. Eventually, localization becomes an "oh crap" requirement when someone expects to have a "Spanish version of the site up ASAP". After all, localization was part of the business case and a key selling point of the platform. Yes, localizing the site would have been as easy as hiring translators if only some accommodations had been made during initial implementation. But they were not. Hence the "oh crap."

While you may not have budget to localize your website during your initial CMS implementation, following these steps will make adding a new language easier down the road.

1. Learn how internationalization works on your platform.

   Different platforms have different approaches and best practices for internationalization. If you make the modest investment to fully understand these techniques, you will at least make educated decisions about how to defer localization and not rule it out. If you are working with a systems integrator, which I highly recommend, make sure they have experience building (and maintaining) localized websites on the platform.

2. Use the translation framework provided from the templating system.

   Any given web page will have a lot of static text that lives in templates (as opposed to in the content). For example, there might be a label on the upper right that says "search" or a copyright statement on the bottom of the page. It is not practical to manage these little "content crumbs" through your usual editorial workflow — they are small, numerous, easy to lose track of, and rarely change. But if you are planning on localizing your site, you don't want those strings in your templates either. It is much better manage these strings separately in "resource" or "message" files that can be shipped off to translators. Most templating languages come with a system for invoking externally managed strings. For example, in JSP Standard Tag Library, translated strings are invoked like this:

   
<fmt:message key="some.text"/>


   In eZ Publish they look like this:

   
{"Some text you are going to translate"|i18n('design/standard/node')}


   Setting this up is easy enough to do when you are building out your templates for the first time. However, it is very tedious to retrofit old mono-lingual templates with this system. You wind up doing it for templates that are no longer used "just in case." Worse of all, you have to visually re-inspect every pixel of the site because you are touching nearly every line of view code.

3. Keep text out of images.

   Having text in images adds a lot of friction to the localization process. First, you must remember to keep the image source files on-hand so you can produce the translated versions. Second, the translation process goes through additional steps of extracting and then re-imported the localized text. Managing all of those image files can be a real pain too. It is much better to float text over image backgrounds for buttons, navigation, and slides. Incidentally, applying this practice will also help with SEO and accessibility.

4. Make room for other languages.

   Think as your primary language as the first of several languages when you are designing your content repository and defining roles and workflows. These localized content collections need a place to live. They will need access control so that a local team can safely work in their content without risking the overall content repository. Pay special attention to how "global" reusable content components are managed and retrieved.

5. Buy your top level domains NOW.

   If you will be publishing your sites to different markets, start working on acquiring those top level domains (like .fr or .es). It will be really embarrassing to enter into a new market only to find someone else squatting on your domain.

6. Set the appropriate character encoding

   Most of the time this is a non-issue because most modern technologies default to UTF-8. Just make sure that you set up your databases with UTF-8 encoding and collation. Some older versions of programming languages require adjustments when dealing with Unicode too.

If you think localization may be in your future, plan for it now. Take the additional steps to reduce rework and risk when you are under the gun to get that new language published. If you didn't follow this advice, I would look into translation proxies.

Introduction to Translation Proxies

Recently, I have been doing a lot of work with translation proxies. A translation proxy is a service that sits in front of your website and applies translations so that different audience segments can see your content in their local languages. You point various DNS entries to the proxy so that request goes through the proxy service to your native language website. On the return trip, the proxy applies translation rules to the HTML in the response. It’s a little like when Google Chrome asks you to run Google Translate on the foreign language page you are looking at. However, unlike Google Translate, these translations are done by professional translators and there is a multi-step workflow to ensure that the translations express correct information and tone. Of the three ways that Global Marketing Operations can localize websites, translation proxy is the fastest growing option.

This approach has several benefits. Among them:

• There is no need for the core publishing platform to have multi-lingual capabilities

  
  

  The publishing platform behind the primary language site may not support localization features such as storing different localized versions of a piece of content or being able to easily localize display templates. Many CMS implementations start with a localization-capable product but then cut corners, which prohibits adding alternate languages down the road. Building a site for localization takes planning, skill, and investment that cannot be justified if localization is less than a drop-dead requirement at the time of the initial implementation. Retrofitting is a lot of work.

  
  



• You can translate both content and template text in one place

  
  

  In a typical translation scenario, we need to translate both the content (which the content contributors manage) and the presentation templates (code that the developers manage). See this screenshot for an annotated view (sorry for the color palette choice. I understand if you have a sudden craving for a Big Mac).

  
  

  

  
  

  With other localization approaches, you need to localize these aspects separately: the content through an editorial workflow and the template text through a software development life-cycle. In the translation proxy approach, all of this text can be localized together.

  
  



• You can leverage your main site’s interactive functionality.

  
  

  Because requests are proxied back to your primary language site, all interactive features (including search, contact forms, and even commerce transactions) will continue to be supported.

  
  



• Your content stays secure.

  
  

  Because the translation proxy only sees what regular visitors see, there is no risk to the security of the main site. The one thing you want to watch out for is transactional functionality. You want to make sure that the proxy service does not collect sensitive information that visitors submit to the website and also can create rules to ignore sensitive information coming back to the visitor.

  
  

Like with any technology, translation proxies are not ideal for every case. Here are some reasons why a translation proxy may not be right for you.

• Local markets cannot create original content in the proxy.

  A translation proxy only translates (or, in some cases filters) content from the main site. There is no clean way to add original content to a localized site managed by a translation proxy. This is perhaps the biggest show-stopper for some companies. If you have a local marketing team that wants the autonomy to develop original content for their local markets, a translation proxy is not going to help. They need to publish their content somewhere before it can be served through the proxy. Perhaps they could create areas on the main site for their specific regions but then they wouldn't be leveraging the proxy.

• A translation proxy will not allow you to neglect your localized sites.

  If you want to save money by putting up simple, (crappy,) static sites for local markets, a translation proxy is not a great solution. The translation proxy model is intended for managing localized versions of the primary site. Any new or changed content will display in the primary language until it is translated. You can contain translation costs by excluding certain sections from your localized websites (for example, you may not want to translate your blog or press releases). Still, with the proxy model, you need to consider the translation costs when you add new content to your website. One work-around could be to create a trimmed down, rarely-updated "international site" on your CMS and use the translation proxy to localize it for all your foreign markets.

• Translation volumes are difficult to predict.

  Unlike traditional translation projects, a translation proxy service is monitoring a constantly changing website so scope is going to be fluid. This is not an “invest and then rest” type of service. It requires a level of attention and planning commensurate with the level of work that is done on the main site. If you are serious about reaching into new markets, this investment should seem reasonable to you. It’s still cheaper than hiring in-country marketers to produce original content. Look for suppliers that offer a capacity model where you pay a fixed fee based on expected usage. This will protect you against a large per-word translation bill after your primary language authors have been particularly prolific.

While the translation proxy approach is not optimal for every business or website, its benefits are very compelling for many. A translation proxy may be worth considering if you learn that your sophisticated interactive website was not built with localization in mind and you want to serve new markets with the same level of experience that you serve your home market.

Daisy 2.2 released. Kauri keeping Outerthought busy

Outerthought recently announced version 2.2 of their Daisy CMS platform. One of the biggest improvements has been in the area of localization. Daisy, with its "variants" model, has always been strong in managing multiple language renditions of a content asset. With 2.2, Daisy has improved the way different translations of a document are kept in sync. For example, if your native language is English, you may create many incremental English versions of an asset and translate the major versions into the secondary languages. Daisy 2.2 allows you to map different versions of language variants and shows you when the mapped versions are not in sync. For a better, more thorough explanation, see Bruno Dumon's blog post on translation management.

I think that the Daisy 2.2 release has been ready to go for a while but the team has been working on a new web application framework called Kauri. I know what you are thinking: just what the world needs, another web application development framework. Take comfort in knowing that they are not trying to re-invent everything. They are re-using what they like but have decided to build their own runtime and their own template language. The runtime is based on a "Restlet" (as opposed to servlet) architecture and seems pretty interesting. While servlet based frameworks may be considered to heavy weight for REST style architectures, I think departing from a well known standard (like the Servlet standard) should not be taken lightly. Noelios, the company behind Restlets, is intending to take their Restlet API 2.0 through the Java Community Process this year (see blog post).

The creation of a new templating language makes me a little uncomfortable. While there is really no good standard other than JSP JSTL (not really a templating language in itself) and XSLT (too hard for most to learn), creating a new templating language (or any new language) is the developer equivalent of jumping the shark - an over the top attempt to break out of the status quo.

No templating language is perfect but there is value in working in an imperfect language that you know or that your IDE knows. Most templating languages go through a natural lifecycle where they start out architecturally pure but limiting (and often a little slow and buggy too), then they achieve stability, then they start to get ruined by the desire add programming capabilities that spoils the separation between layout and business logic. I would love to see a better standard in this area that will help slow the decay of a good templating language and bring some commonality between content management systems.

I will try not to pass judgement on the Kauri template language before I see it and I would love to see something that would make me want to teach it to a creative developer. I guess you could say that I have a healthy skepticism.

Magnolia Community Edition 3.5 (RC1) Available

This morning there was an announcement on the Magnolia user mailing list that the first release candidate (RC1) of version 3.5 is now available for download. If you were waiting for version 3.1, don't worry, you didn't miss it. It is the same release. Still, this is a pretty big release. Some of the more notable features is better internationalization support. It used to be that localized sites needed to be managed more or less independently with no real relationships between different translations of the same asset. The new version provides better support for 1:1 localization schemes. Future releases and add-on modules will provide more functionality in this area. The new version has also been re-factored to be easier to customize. For example, many of the configurations have been transformed into beans that can be overridden and extended. There is also better support for filters. Security has also been enhanced with URL level access control (in addition to content level access control).

The Enterprise Edition will be released after the Community Edition is final and stabilized. If you are using Magnolia Community Edition, you might want to download it and give it a try - especially if you have built modules. The Magnolia team has tried to support backward compatibility for 3.0 modules but you never know. Now would be a good time to tell them if there is a problem.