Translating interface strings is always a painful process. Actually, it's difficult to achieve in many content management systems, not just in Drupal.

Unlike node contents, interface strings can come from many different places.

They can be part of Drupal core, from modules, themes or dynamically generated by the site's admin.

The hard part is locating these interface strings which appear to site visitors and translating them. To visitors, it doesn't really matter where the strings come from. All user-facing strings must be translated, for the entire page to appear in the right language.

Choosing Strings With The Localization Client Module

The localization client allows searching for untranslated strings easily. For site admins, the most important feature is the ability to spot strings as they are used on public pages.

Once installed and enabled, the Localization Client opens a panel at the bottom of public pages. These pages are viewable to admins only and not to site visitors.

Translation Management adds the Queue for translation button to the Localization Client panel. When you click on it, you're adding the selected string to the translation queue.

Strings that you queue here would be sent to translation from the Translation Dashboard.

Searching for Strings Manually

Drupal's core includes a simple string search tool.

Go to Administer » Site building » Translate interface and click on Search.

Enter the string to search for, choose the string's context (optional) and hit Search.

When you're using Translation Management, you'll notice the same Queue for translation button at the bottom of the search results.

Instead of entering the translations in this page, you can queue string for translation and send them via the Translation dashboard.

Sending the Strings to Translation

Once you've queues strings for translation, head back to the Translation Dashboard.

Go to Administer » Content management » Translation Management » Translation dashboard

You'll see everything that needs translation, including the interface strings that you selected.

This means that you can send interface strings to the same translators who work on the site's contents, without having to teach them about Drupal's string translation facilities.

Just as we're getting ready to release the first production version of Translation Management for Drupal 6, we're starting to think about what it takes to port it to Drupal 7.

The number and depth of the changes between Drupal 6 and Drupal 7 is impressive (to say the least). So, it looks like us and every other module developer will have to maintain a completely different branch for D7.

What we want to know is when folks might start using Drupal 7 for production sites.

Drupal 7 release date should be somewhere in September.

Do you have plans for starting to use Drupal 7 for client sites?

Drupal pages often link to one another. When you translate them, translated pages need to link to other translated pages and not the originals.

Translation Management includes a handy feature that does just that. It makes sure that any translated pages link to each-other.

The cool part is how it works. Unlike "post-processing" solutions, such as Multilink, Translation Management does the link updates in the database, when saving the nodes.

Supposing Page.A links to Page.B. The translator might first translate Page.A or Page.B. The way this link update works, it doesn't matter. When both pages are translated, the links will be updated as well.

This feature is enabled by default. You can control it by going to:

Admin -> Content Management -> Translation Management -> Translation Setting

Step 1) Check links to other pages when saving

If a page includes links to other pages, we check if these other pages have translations to the same language (as the page being saved). If so, we update the links so that they go to the translations.

In case there are links to pages that are not translated yet, we mark the page as dirty.

Step 2) Check all Dirty pages and update links in them

Next, we go through all pages marked as dirty. Remember, this means we scan all pages that link to other pages which were not translated before.

And, if there are no more links to other untranslated pages, we clear the dirty status.

Performance

This has minimal performance impact. All checks are done when saving pages, not when displaying them.

The changes are saved to the database, so nothing is needed when rendering.

Because we only scan dirty pages and not all of them, the processing time during each save is small too. As the translation progresses, older pages are all clean (only link to other translated pages) and we only need to rescan the last few pages.

Handling paths

This processing takes into account the paths module. When we see a link, we first convert it to the default URL. Then, we check if there's any translation and eventually, we reapply the path of the translation.

Works the same no matter who's translating

The link update operation is done when translations are saved in the module. It happens the same way if you translate from within Drupal (from the Unified translation editor or if you're sending out translations to a translation service (such as our ICanLocalize interface).

The end result - easier translation

This whole mechanism makes it easier to translate and to administer a multilingual site. Without it, someone needs to manually go through translations and update links in them. It's especially time consuming when you translate a page that has many incoming links.

One of the most critical features for the Translation Management module is being able to send translation jobs to translation agencies and receive back completed translations.

To illustrate the importance of this, I'll start with how not to do it, based on an actual case, we're working on.

Overly Complicated Translation Process

One of our largest clients is using a closed-code CMS. That CMS indeed has a translation module, so we can get jobs and return completed translations. However, the integration between the translation module and the CMS is loose.

As a result, the process for the content admins is complicated. Admins need to go from one page to the other and send each to translation. Then, they need to get the completed translations from us, go back to the pages and upload the translation files - one at a time.

This (kinda) works, but requires someone on a full time basis to manage translations.

Obviously, no one is happy with this arrangement. More work means higher expenses to the client and less profit for the translation service.

Streamlined Process for Translation Services

Tight integration is key to creating an efficient process. If the different blocks know how to operate with each-other, the user has less work to do.

The Translation Management module offers two ways to work with translation services:

• The built in Translation Service interface (in the TM module)
• The standard XLIFF module

These are complementary routs, which cater to different needs.

Proprietary Interface Directly from Drupal DB

Many translation services (like ICanLocalize) already have their own API for receiving and returning translation jobs.

For them, it makes little sense to go through another format. The easiest implementation is to get the fields for translation from the database and send directly to their server.

Translation Management includes the hooks that allow 3rd party module to interface to it and register themselves as translation services. We even use these hooks ourselves for our own interface.

Standard XLIFF Interface

On the other hand, some translation services and many freelance translators want to use a standard tool-chain to translate. They're willing to sacrifice some integration in order to use their existing tools.

For example, Trados (the most popular translation software), can read and write XLIFF. So, allowing translators to get the XLIFF output and return XLIFF to Drupal would be a huge leap in workflow for them.

Drupal's XLIFF module does most of the work we need. With some changes, it looks like it's going to play very nice with Translation Management.

Our plan is to contribute patches to the XLIFF module to achieve maximum integration, so that instead of duplicating the code in our module, we can rely on XLIFF to do the job.

Your Views on Translation Service Integration?

What do you think? Do you use translation tools? What kind of integration would you like to see?

We're going to talk about the Translation Management module in the TM For Enterprise session in DrupalCon Copenhagen.

If you're coming to DrupalCon, we'd love to meet you there and I'm pretty sure you'll come out with a thing or two from this session.

Know What Interests Your Clients

In this session, we'll spend some time teaching about the Translation Management module module, but it's not the point. You can do that yourself using the handbook.

What we'd really like to do is share our experience working with enterprise clients on multilingual Drupal sites.

When you deliver a multilingual Drupal site for a large organization, your work ends (sort of) and their work only begins.

Managing Translations Can Be A Lot of Work

Do you know how content managers, translators, reviewers, marketing VPs and upper management are all involved in the translation process?

If you're not exactly sure, you should attend the Translation Management For The Enterprise session in DrupalCon, because that's exactly what we're going to talk about.

Many European sites are multilingual, by definition (Canadian sites are multilingual by law). When you show your clients that you understand their needs for multilingual content management and know how to address them, you'll make them extra happy.

The methods folks use today involve sticky notes, excel sheets, hundreds of emails and a lot of manual work and wasted time. They know it, but have no better tools.

Translation Management Reduces Work for Your Clients

We're changing this with the Translation Management module. Your clients will enjoy a systematic solution for managing translations. They probably know that these solutions existed before, but never for Drupal and never without shelling out obscene amounts of money.

ICanLocalize, the translation business driving the Translation Management module is serving global organizations such as the International Red Cross and CNN. We're importing a world-class solution for Translation Management into a Drupal module. Free and open for all.

So, if you're coming to Copenhagen in August, we'd love to see you in our session. And, before going, you should check out the session page and vote for it!