Better translation support for Drupal contributions

Motivation

Translations of the Drupal core user interface to languages other than English are represented by their own projects on drupal.org. Each one has its own issue queue, official releases, project pages, and so on.

However, translations of Drupal contributed modules are difficult to find and use. They are only included in subdirectories of each contribution, so there is no way to search for all the translations for a given language across all contributed modules. Users can only download individual modules and manually search for the particular language(s) they might be looking for.

Furthermore, because of the way in which all files within a subdirectory of a source repository are tagged, packaged, and released together at the same time, it is very difficult for translators to keep their translations current in the official releases. This would require lots of coordination between the module developer and all of the translators who have contributed a translation of the given module, so that anytime the developer has to modify the translatable user interface, the translations would have to be updated before the official release was created.

Given the current situation, it is very difficult to provide any kind of translation status information about contributed modules. Unfortunately, due the changes for the new release system, the translation status page (which only presented information about core translations), is currently unavailable, as well.

Contributed modules have a wide range of quality when it comes to how easy they are to translate, too. Some modules do not provide a translation template file at all, and others only provide an out-of-date template.

In short, life for the translator of a Drupal contribution is rather difficult right now, and people who are interested in the internationalization of Drupal should consider making their task easier. This would encourage translations it to happen more often and more effectively.

Deliverables

• Automate the task of moving the translations of contributed modules out of subdirectories in each module, into their own directories in the source code repository (CVS), and generate project nodes for each one. This would involve learning some of the inner workings of CVS (yes, you really can rename files), designing a good directory structure that would be easy to use and understand for both translators and users. Putting each translation of each contribution into its own directory would provide the following benefits:
  • The translators could delay official releases of the translations until after the module developer releases, so they have time to translate the actual interface in a given release of an important module (for example, views-5.x-1.5), in the coresponding release of their translation of that project (for example, es-views-5.x-1.5).
  • Visitors at drupal.org could quickly view all contributed modules that have been translated to a specific language.
  • CVS access control for the translations could be enforced, so a dedicated language-specific team could have access to commit changes to any translations into that language, but not necessarily permission to modify any translation in any language.
• Research and develop improvements in how translations are imported into a live Drupal site, and ways to facilitate or automate the task when there are translation releases for both core and contributed modules.
• Extend the Project module to have a notion of parent projects (which could have other far-reaching and interesting implications that could be explored by a creative developer, beyond translations). Not only would this allow translations to "point to" the module they translate, this could provide a means for information about all translations to be automatically displayed on the "parent" project (the module). Because Drupal core and contributed modules use different version number conventions, having each translation know exactly what project it is translating would allow translations to always use the same version number scheme as the thing they're translating.
• Provide information about translation status relative to each contributed module that has translations, not just Drupal core, and make any necessary modifications to the Drupal packaging infrastructure to support this.
• Consider automated generation of translation template files when packaging contributed modules. Research storing translation templates in the drupal.org database, and provide a web interface for translating both core and contributed modules. This would make it much easier for translators to contribute to Drupal, without necessarily having to learn about CVS and revision control much (if at all). It could also allow common strings that are in the core translation for example, the words "Submit" and "Preview") to be shared among all translations of contributed modules, as well, instead of having to duplicate the effort.

References

Here are some useful issues where concepts around this project have been discussed, for background reading:

• Split contrib translations into their own directories and projects
• Make translation status work in the new release system
• Provide feedback to translators when there are errors packaging releases

Comments on this proposal

Live Translation
brmassa - May 28, 2007 - 03:39

Guys,

im already doing such module: Live Translation.

* On the server, it can scan directories and files to find translatable strings. All strings are kept on database. A web interface is provided for translation groups. Translator are divided into Language maintainers and supporters, who can suggest modifications, but they are not considered official.
* On the user side, it downloads from the server all new translations, on every cron. Piece a cake.

The module is quite useful for now. but the server scans the installed modules diretory, instead the CVS project directory. If anyone knows how to integrate with CVSlog and Project Release, your help will be welcome.

regards,

massa