Globalization Plan - Recommended Solution

As discussed above, we face a number of challenges going forward with international web site development. Some of these, for example locales and character sets, are directly related to the addition of Asian and Eastern European languages. Others are indirectly related in as much as the number of supported languages has a great impact on development cost and time as well as long-term maintenance.Addressing each of these issues on an individual basis will inevitably create a patchwork solution that won't address the interrelated nature of the problem. I believe a comprehensive solution to the problem would have the following components:

Make international sites independent of U.S. Sites

Currently U.S. and international sites share folders, databases and admin tools (among other things). This has caused some difficulties as the tools, designs and other aspects of site development were all developed to meet the needs of the U.S. site and not of a multilingual international site. This limits flexibility when developing tools for international sites and often leads to the development of tools that are not necessarily optimal for either case (U.S. or international).

The process of moving the international sites into a consolidated international folder within the file system is already in the planning stages. This mainly achieves a functional organization, but also removes the ties that were built into the site architecture whereby sub-sites inherited information directly from their parent site. However, admin tools and database tables will still be shared following this change.

I recommend creating a separate international database that will share necessary product data with the U.S. through a synchronization of the databases established in SQL server on a transactional level (meaning every time a product id is added to one, it is further synchronized in the other). This will allow us to accommodate the necessary database changes as discussed earlier without rebuilding the U.S. databases.

In addition, I suggest separating the administration tools by creating an independent international administration area. This will make it easier to create and modify administration tools to suit the needs of international sites without adding the burden of forcing them to also meet the needs of the U.S. sites (and vice versa).

Create a Dynamic Design and Layout Solution for International

As discussed briefly, building the text of translations into the design (i.e. PSDs) for each site is likely not a sustainable long-term plan. The resources necessary to build and maintain these sites (even when the changes would seem simple) for a growing number of languages would continue to drive up the costs of development for international and dramatically hinder the responsiveness to changes when necessary.

In addition, a discussed earlier, using standardized resources such as resource bundles and the tools for maintaining those becomes difficult if not impossible. This further necessitates having individuals with little to no experience with a particular language handling the actual integration of translations. It has been my experience so far that this both slows down the entire process of international site development but unnecessarily complicates the process.

What I recommend is the creation of a secondary international design that, rather than being a duplicate of the U.S. design, is designed to take into account the specific needs of internationalized sites (for instance, less reliance on complex fonts where text would suffice thus simplifying translation). We can also incorporate a solution such as sIFR 2.0 (http://www.mikeindustries.com/sifr/) to allow for the inclusion of fonts where most needed.

This design can be used to create a fully-multilingual site capable of handling any of our supported languages within a single set of templates that call upon translated text as based upon the user's locale. This will allow sites for particular locales to be launched simply by adding in the translation information necessary. In addition, as seems standard in locale-based sites, locale support can be hierarchical. This means that, for example, the French (Belgium) locale would first look for translations specific to that locale, then , if nothing is located, move up a level to look for a general French translation. If nothing is found for French, the default locale information would be used (typically this is English).

Some final comments regarding how these international templates could work. While they could stay true to elements of the U.S. site design, it is my view that they would not, typically, be the same. The goal would be to develop the sites to support a form of "plug-in" style architecture, whereby functionality could be customized or extended through plug-ins that could be added on a per-site or even per-locale basis. This differs from existing sites in that it is an extensible architecture for building and maintaining international sites and not a stripped-down version of individual site development.

In Conclusion

I believe that we currently face an exciting but overwhelming opportunity to build upon our recent experience and create a comprehensive but sustainable solution for the long term development of international sites. We have seen a rapid growth in this area during the recent months, and one that clearly continues to gain momentum, and building the tools to manage that growth effectively will pay off dividends in both the quality of the international web sites and the costs of development and maintenance.