Blog

API Updates for Translation Management

We're getting ready for a new release of Translation Management. This version will include upgrades to the translation service API, so if you're using it, now is the time to upgrade your module too.

New in Translation Management 6-1.2

We'll close all pending issues for this release. Long standing issues have been:

  • Buggy Google Translate - thanks mscharley for the patch!
  • Compatibility issues with Postgresql - we got the initial patch from Monty and added more fixes. Thanks!
  • Crashes, uninstall problems and resigning translators - all will be included in the 6-1.2 release.

Translation Service API Changes

We went through usability testing and found that it takes a mind-reader to "discover" the professional translation options in the module.

Obviously, <shameless plug>being a translation service focusing on website translation and software localization</shameless plug>, we're eager to fix this.

Translation Management 6-1.2 will consolidate the management of in-house translators with translation services. They would all appear in the same page. This should make it easier for website admins to get the overall picture of who's translating for them.

Adding new translators would be simpler too. Users will choose the language pair, what 'kind' of translator and add. This is how it will look:

Add translators

For this change, we need a bit more information about different translation services. This includes a brief description and a link to 'learn more'.

These changes will not break backward compatibility. Older translation service modules will continue functioning. However, they will not benefit from these upgrades and thus will get less exposure to potential clients.

If you're building a translation service module that connects to Translation Management, please contact us for more details. It's being worked on right now..

Revisioning Translation

We're happy to release the first beta version of the Revisioning Translation module.

This module allows using advanced workflows that use both the Revisioning and Translation Management modules.

Content admins can choose to schedule items for translation. Translation will only begin when the editorial process completes.

This means that admins don't need to keep track of a complex editorial content and then send to translation. They can tag what needs translation and it will be sent automatically when the document is ready.

The module is in Beta now. To use it, you will also need to download the recent Beta of Translation Management modules. We'd love to get feedback and see how it's working for you.

SEO for multilingual Drupal sites

nodewords

SEO is important for most Drupal sites. It also needs to be multilingual.

The Nodewords module allows you to add meta data to your content. The Translation Management module already handles translating meta data that is added to each node.

Nodewords also allows you to add custom meta data to your pages. For example you can add custom meta data to all you blog entries without having to add it to every page. Translating this data is a little more tricky.

The Nodewords module implements hook_preprocess_page() to add its meta data to a page. In this process it uses the drupal_alter function to allow the variables to be altered. This looks like a perfect spot to insert any translations.

How do we enter the translations?

The t() function can be used to translate interface strings. Any strings passed to the t function will be added to the locale tables and the translations can be entered via the Translate interface, /admin/build/translate. This looks ideal for us. The problem is, this is not what the t() function is designed for. It's meant to be used to translate fixed strings from php code. eg t("Read mode...")

You can read more about the use and miss-use of t() in Gábor Hojts' article.
http://groups.drupal.org/node/1827

The other option is to use the i18nstrings functions. This is designed to be used for this sort of purpose. The problem here is that we need a unique identifier that we can use to save the string. In this case we don't have that, we only have the string text itself.

Any ideas?

We're looking for creative ideas on how we can use i18nstrings, drupal_alter and Nodewords together.

What do you think?

Migrating Translation Management to D7

We're migrating the Translation Management module to Drupal 7. Things are progressing pretty well but it's not a trivial task.

The focus of this migration is making sure that the module's core runs on both D6 and D7. We don't want to have to maintain 2 separate branches. This has required creating wrapper functions for all D6/D7 specific calls. The new database API has made things interesting.

What's working so far.

Drupal 7 has now centralized a lot of the multilingual functions to single spot, admin/config/regional. This is a big improvement over D6 where multilingual settings were spread out over a number of different menus. This has given us a nice spot to add the Translation Management menu.

Drupal 7 Regional Configuration

Drupal 7 is still missing a lot of functions needed to make a complete multilingual site, functions that the i18n module provides. Once we have completed with migration of the Translation Management module we will be working with the developers at i18n to migrate their module to D7.

Multilingual Content Management Guide

Congratulations! You just wrapped up two months of work and are ready to deliver to your client.

The only thing missing is training - lots of it.

Running a complex multilingual Drupal site means a lot of hassle. And now, you're going to have to train your client so that they can do it too.

ICanLocalize wrote a tutorial on managing multilingual sites that use i18n and Translation Management.

The tutorial covers the basics:

Then, it goes on to talk about more advanced stuff:

What do you think? Would you find this useful for your clients?

Translation Analytics - A Reporting Tool

The next major addition to Translation Management will be the addition of a reporting tool.

This reporting tool will answer questions like these:

  • How are translations progressing?
  • Who's the French translator, responsible for the delays?
  • Which urgent documents are still not translated?
  • Are all marketing documents for product X translated?
  • How much work did we send to translation service Y in June?

To answer these questions, and more, we're setting up a Translation Analytics tool, which would work very similarly to the famous Google tool for Website Analytics.

Translation Analytics

The idea is that you can define special taxonomy for documents, like urgency, budget code, project, etc. The Translation Analytics will identify these fields and create database entries for them.

You will be able to drill down through the translation statistics and create reports that give you the information you're looking for.

Translation Management will collect this data for you. You can specify which taxonomy terms it should track and add to the Analytics report.

What do You Think?

This tool is intended for project managers, who want to know how their budget is used and how the project is progressing.

What kind of information would you track? Any ideas, before we dive into the implementation?

How to Translate Interface Strings

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.

l10n Client and Translation Management

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.

String translation screen

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

Queued strings

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.

Translation Management for Production Sites

Translation Management is out of beta and ready for production sites!

We're using it for our own Drupal Translation site and it's running smooth.

This is an important release for us as it includes migration from the old ICanLoclaize translator module to the new Translation Management module. Many of our clients have been waiting for this.

To migrate from ICanLocalize Translator to the Translation Management module you need to:

  1. Download and install the Translation Management
  2. Delete the ICanLocalize module from your modules directory.
  3. Enable the Translation Management modules from admin/build/modules/list
  4. Run update.php
  5. You may also need to select "Update Display" in the translation dashboard when you first view it.

Meet Us in DrupalCon Copenhagen

We're giving a session about Translation Management in DrupalCon next week.

It's on Wednesday, Aug 25th at 4pm.

We'll talk about who needs Translation Management and go over case studies of users such as CNN, International Red Cross and UNAIDS.

We're also going to use this opportunity to discuss plans for Drupal 7 support and the 'big picture' of building and running multilingual Drupal sites.

Translation Management for Drupal 7

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?

Translation Management - Last Beta Release

We have just released what should be the last beta release of the Translation Management module. The next release should be non-beta, ready for production sites.

We're pretty happy with the module now. The module provides a unified translation interface for Drupal and allows translation to be done locally by Drupal users with the Translator role or translation jobs can be sent to external translation services for translation.

Translation Service Providers Interface

Two translation services are already using the module's API and can do translation jobs via Translation Management.

icanlocalize

ICanLocalize specializes in website translation and software localization. A global network of professional translators, paired with world class translation tools allow delivering accurate translation at very low rates.

OTH

OneHourTranslation is optimized for quick turnaround and fast jobs.

More translation service providers are already working on building their interfaces for Translation Management. The beauty is, that site admins are never locked in to any specific provider. They can assign each translation job to any of their translator or to a translation service provider.

Admins can choose which translation service to use according to the need of the moment, availability and fields of expertise. Lock-in is a thing of the past!

XLIFF Import and Export

This release includes a complete XLIFF interface. Translators can either edit using the module's Unified Translation editor or download an XLIFF file to edit offline using their favorite CAT tool. To use the XLIFF export and import, you must have the XLIFF module enabled.

Improved Email Notification Messages

When the admin sends new documents to translation, translators receive email notifications. When translations complete, the admin is notified back (http://drupal.org/node/875998).

WYSIWYG Translation

If you have CKEditor, Translation Management will use it in the Unified Translation editor. Translation Management will automatically enable visual editing for fields that were originally written using a visual editor (http://drupal.org/node/874644).

Automatic Setting for Home Path
The module now includes special handling for the home page path. All translations of the home page will have the same path, without having to edit it manually (http://drupal.org/node/874946).

Lots of Small Bug Fixes
Besides these new features, we've also fixed a handful of small bugs (like http://drupal.org/node/874138). We'd like to thank everyone who reported bugs and encourage you to continue. We'll do our best to address everything as fast as possible.

Syndicate content