We also figured out a simple, but very effective way to localize software and documentation. If you’re a software or web service publisher, read on to learn more. It’s a simple solution to a tricky problem, and will work real well with the new tools due out in the next month.

Software and website localization is one of those things that most project managers avoid doing. If they do it at all, it is almost always an after-thought and is not done very well except in large projects. We’re working on a simple token based system for localizing applications and websites. This will probably evolve a bit more in the next month, but we’re pretty close to a final specification.

The basic idea is to create tokens for each snippet of text, html, etc that is needed in a website, graphical user interface, etc. The token is simply a nicknamed object, e.g. mywebsite.loginbutton, that is replaced with text, html, or any other data type. This in of itself is not new. Many web publishing systems use this type of approach. I built a similar content management system for my first business, an online buyers guide for phone systems, ten years ago (though not for the purpose of site localization).

SLS is, as it suggests, a simple way to localize applications and websites. The system works as follows, and is easy to implement in a wide range of scenarios. Let’s imagine that you have a web user interface that you want to make available in many languages. With SLS, you simply do the following.

• Any object that needs to be localized, a button label or paragraph of text, is referenced as a token (e.g. mywebsite.faq)
• When a user visits your site, you identify their language preference via a drop list or browser preferences, this is a locale code such as es-ar (Argentine Spanish).
• The web application does a simple replace operation to replace the token with the contents of a file that is cached on its local disk (e.g. /localization/mysite/es-ar/faq), if there is no definition for that token in a the desired locale, you try to fetch a copy from http://localizationserver/mysite/es-ar/faq. If that doesn’t work you revert to the default language or display an error message.

All you’re doing is a server side include from local disk (after caching a file from a network token server if the local file does not exist or has not been updated).

Creating And Maintaining Localization Sets

This is easy because the localization server is just a web server that stores files in an organized directory tree, typically in the structure:

/_projectname_/_language-locale_/_objectname_

The web server or application simply mirrors these files by doing HTTP downloads from:

http://serveraddress/_projectname_/_language-locale_/_objectname_

You can make the token management system simple or fancy. For a simple system, you’d just create the tokens in a text editor, upload them via FTP. That’ll work for closely managed projects. For a fancy system, you can create a web based front-end that allows translators to view, add and edit translations for any token. This will be a good idea for more complex projects where the inventory of tokens is changing constantly. Even the fancy version of this is pretty simple to build.

Volunteer Translation and Localization

A website or application that uses this system can be designed so that users can participate in translating and localizing the tokens. This can be done via a separate translation and localization interface, or via an in situ localization tool that displays a small icon next to each token.

Dedicated Translation and Localization Interface

In this scenario, translators go to a dedicated web interface where they can view, edit and contribute translations to the tokens used by the application or site. Translators may be volunteers, or may be paid, or some combination of the two. The web interface displays a list of tokens for the source language website or application. Translators will then create translated tokens in whatever languages they speak. Again, the tokens can represent anything. Some might be labels for menu buttons, while others are full-length documents. This makes the system very flexible.

As the translations are created and updated, the translated tokens become visible to readers and users.

In Situ Translation & Localization Tool

Chris Messina made this suggestion, and offered a great example of what this might look like. Here we ask users if they want to help localize a website or application. If this option is enabled, it displays a small WWL icon next to each token or UI element. Clicking on this icon triggers a popup form that asks the user to contribute or edit a translation for the object. This is then stored by the localization server and, subject to system rules, will become available to other users.

This approach will enable translators to understand the context of what they are translating (a menu bar for example). The translations are saved to the localization server, which publishes them via the simple HTTP method outlined above. We assume that developers will want to implement access and workflow control measures on top of this basic process. The goal of this document is to outline the basic process, which can be adapted as needed to specific projects.

Summary

This tokenized approach to the problem of localizing a website or application, while simple, will work well for many applications. By utilizing existing services, developers do not need to build an unwieldy and difficult to understand system. The solution can be as simple as a web/ftp server that hosts dozens or hundreds of files in an organized directory tree. The application or website that uses these tokens simply does a file read and replace operation which, with caching, will be fast and not involve complex back-end systems or a big performance penalty.

We’re working on some tools based on this approach that we’ll demo at Foo Camp in June. So stay tuned for more information. If you’d like to experiment with this in your applications, send us an email. Thanks.

As WWL grows, we are building a network of professional software developers to assist clients in embedding WWL techniques in a wide range of web publishing and information services. Watch for more announcements about WWL partners in the upcoming weeks.

• Access Control Lists
• Workflow Management (i.e. Review Before Publish)
• Randomized Peer Review
• Support For Commercial Translation Service Bureaus (via simple web services and email interfaces)
• Support For Integration With Publishing And Content Management Systems

The package we are developing will be published as open source software. The document processing system is being developed in Ruby on Rails. Other tools are being developed in PHP. We are looking for a few publishers to sponsor the project, and to provide feedback on the project roadmap, feature requests, etc.

We are also happy to announce that Alexey Gavrilov and his group at Metalink is joining the project. They will be customizing the Ning social networking platform. This system will make it easy to create and join translation communities about any site or subject. We are testing it now at groups.worldwidelexicon.org.

We also found an email to RSS service, Mail Bucket, which is an easy way to convert an email newsletter to RSS, and then to import the RSS feed into the Worldwide Lexicon. If you have an email newsletter, you can forward your mail to your_newsletters_name@mailbucket.org. Then register http://www.mailbucket.org/your_newsletters_name.xmlwith WWL. It’s that easy.

• David Anderson – Berkeley, CA, USA : advised us when we were working on the Lexicon@Home project (David is the director of the SETI@Home project)
• Jonathan Augenstine – Pasadena, CA, USA : worked on the multilingual instant messaging system
• Phil Bekker – San Francisco, CA, USA : our second translator, he’s helping with French
• Chris Cunningham – Madrid, Spain : worked on GNUtrans and MIMS
• Melinda Green – San Francisco, CA, USA : built an early version of our multilingual instant messaging system
• Martin Korben – Buenos Aires, Argentina : our first translator
• Mike Mangino – Chicago, IL, USA : he and Elevated Rails developed our translation wiki prototype
• Thor Muller – San Francisco, CA, USA : he and Ruby Red Labs helped us in early stages of the translation wiki project
• Pixelstud (aka Jayson McAuliffe) – San Francisco, CA, USA : created our logo
• Jonathan Vaught – South Carolina, USA : he and Elevated Rails developed our translation wiki prototype