As a maintainer of Drupal's locale module I try to find creative ways to help people localize their sites. Our focus in Drupal 6 was on more features for content translation and interface translation imports, while the built-in locale interface was nearly untouched. We even complicated it a bit with the textgroups feature which might or might not get used by contributed modules at the end.
In a previous post, I announced the new localization client module which strives to solve some of the problems with the built-in locale module translation interface by bringing an AJAX powered widget close to the site translator. While this module is a very good looking way to solve the translation problem, it has two weaknesses:
- You can only translate what you see on the site pages you browse by. Some text is only shown in emergency, when form values are not filled properly, when some backend data is not accessible, etc. Some text is even restricted to different user groups. So you can only translate the most visible parts of your site.
- Closely connected, but slightly different issue is that you cannot translate strings with plural versions at once. If your page shows 3 years ago, you can translate @count years ago but not 1 year ago (the singular form) or @count years ago and friends, which are used when the language in use has more then two plural forms. The Drupal database gives no clue in relating these for translation, so we cannot help users intending to translate all these at once.
Although locale module provides a more complete solution, allowing you to have a translation percentage overview as well as filter untranslated strings and work on them, you are still restricted to the same old, hard to use interface. If you'd like to improve on the interface issue, you can switch to use potx module to extract Gettext translation templates from your modules, then use some desktop Gettext editor which suits your taste and then import the translation back to your site. For most people though, the "favorite Gettext PO editor" question is like asking about the best time to go to the dentist. If we can do better, then why not?
Enter the localization server module suite also developed as part of my Google Summer of Code 2007 involvement (watch the video of the interface). Back in the SoC days, I made some bad decisions about the architecture of the module which I am trying to recover from now. The changes make the module suite much more complex looking, but at the same time allows you to use the fruits of the work, so this tool will not be restricted to drupal.org, and I'll not be the sole maintainer for life ;)
Warning: the localization server module suite is in heavy development. Some modules might be renamed along the way, complete functionalities might be broken out to submodules and so on. So only use it still to alfa test the functionality.
In recent weeks, I took a decent amount of my free time to rearchitect the module suite, and although the process is still underway, I needed to stop to ask for your help in making one of the most user facing components work. The module suite now consists of the following components:
- l10n_community module
- As it stands now, this should have been named l10n_editor or l10n_ui. It basically provides a user interface on top of some tables defined for storage of projects, releases, files, lines and strings, as well as string translations. I hope we get the Young Hahn touch for the interface soon, but functionally this works nicely. Allows you to translate strings to languages set up in locale module with some default role based permissions. Supports importing PO files as well as exporting PO packages in the form required by Drupal 6. Only requires a connector to work (see below), and the PEAR Tar classes for the package generation.
- l10n_groups module
- Builds on the simple role based permission model in l10n_community and maps languages to organic groups, adding a permission layer in which organic group membership and administrator status can restrict translation and suggestion submission permissions. Different groups can have different permission models: an open model where all members can suggest and translate as well as approve suggestions and a controlled model where only admins can approve suggestions and members can only post suggestions.
There are two connectors ready to be used and one connector planned to connect l10n_community to different environments:
- l10n_drupalorg connector module
- Synchronizes projects and releases, downloads tarballs from drupal.org and parses the files extracted from them to provide translatable strings. Also provides a nice welcome screen. Intended to be used on drupal.org itself to provide a community interface (with l10n_groups) for central translation of all modules and themes to lots of languages.
- l10n_localpacks connector module
- Looks into a configurable directory on the local file system for subdirectories (projects) and tarballs (releases). Uses the drupal.org standard tarball naming convention to identify project names and release versions form the file names. Extracts translatable strings from the tarballs. Intended to be used at companies for translating in-house modules and/or doing custom project translations for client needs (where forking official project translations is a requirement).
- l10n_onsite connector module (planned!)
- This would look into the projects installed locally (just as update_status can identify projects installed), would parse files installed locally and allow usage of the same UI for local site translation. There are a few open questions which need to be answered though.
All-in all the direction is to let the localization server operate in different environments: be it the drupal.org server where more then a thousand projects need to be translated into dozens of languages, as well as a company intranet where some modules need to be translated, to an actual Drupal site where the maintainer would like to make sure everything is properly translated. Download the comparison chart if you are interested how the different modules compare.
The basic problem I am stuck at now is that there is a considerable mismatch between what structure Drupal needs for optimized translation lookups and what my module suite components need for an optimized translation interface, and when we'd like to marry the two in l10n_onsite, this shows.
If you are interested in solving this issue and helping bring a complete localization tool set to your site, continue in the drupal.org issue I opened for this problem: Make l10n_server support local Drupal site translations.