Dear Drupal interface translators!
Your valuable work helps Drupal to actual world domination, so we try to support you all ways possible to be able to more efficiently organize your time to translate Drupal projects (the Drupal core system itself, as well as contributed modules, themes and install profiles). Currently your work involves lots of manual steps and several "esoteric" tools.
- You either find translation templates for the actual release of the project or not. Even where templates are available, they are not always updated to the actual software release you are working with. So most of the time you need to go and generate templates yourself (previously with extractor.php, these days with potx module).
- You need to use a Gettext Portable Object editor of your choice (could be a simple text editor or a specialized tool). If you work with a contributed project, you possibly need to use msgmerge, and other command line gettext tools to merge files, prefill previously done translations, etc.
- You need to translate text already translated in other modules, and/or in Drupal core itself, unless you also merge with core translations as part of your workflow.
- Once ready, you need to get your file committed to CVS, which requires a CVS account and a good amount of branch/tagging knowledge, so you put your file to the place it belongs.
- But for already released projects, you cannot push your updated translation which were not ready in time, the translations are not coordinated.
- And on top of all this, users of modules need to manually upload PO files even if they uploaded them with the module, and obviously expected them to be imported with the install process.
So we, translators have quite a few problems. I know, I am a translator in the Hungarian team as well. But Drupal developers are working on ways to solve several issues for translators.
Drupal 6 improvements
There are improvements in Drupal 6 which make setting up localized sites a lot easier:
- The installer informs users where to get translation packs, so they can install localized from the start.
- The installer imports translations for all enabled modules.
- When you install modules, translation files are imported for them in all enabled languages.
- When you add a language, translation files are imported for all enabled modules/themes.
- When you enable a theme, translation files are imported in all enabled languages.
To make this all possible we came up with a convention: install profiles, modules and themes should have a 'translations' folder, where these translations are searched for. Note that this is a renaming of the 'po' folder convention used before, but is much less technical to be more intuitive for our users.
Anyway, this only works nicely, if there are actually translations available. So here the job turns to you: *deliver even better and more translations*. But we are not asking you to do this with the above toolset indefinitely. I am sponsored by Google Summer of Code to create better translation interfaces, which will automate most of the above tasks for you, and push CVS, gettext and project releases out of your way, if you are not interested in using them.
Localization server
The plan is to have a central server on drupal.org (somewhere like t.drupal.org, or translate.drupal.org or translations.drupal.org, you get the idea), where an organic group based interface will be set up with specific tools to support translation groups. Every language will have their own group. Participating in project translations will only require a simple account registration on this site. This site will serve as a one-stop-shop for all translations, so the CVS based storage will be discontinued. What the server will do for you?
- It will have a group set up for your language with discussion space, possibility to post guidelines and dictionaries (with generic content posting tools).
- It will know about all projects hosted on drupal.org, and will regularly update its data about all releases available.
- All releases will be scanned for translatable strings, and a big *shared* database will be used to relate these strings to projects and releases. This means that you don't need to translate 'Home' or 'Operations' more then once anymore. Because Drupal enforces translation sharing for the same strings, this site will do it too.
- You will be able to export translation templates and work offline with your well known tools if you wish, and finally import translations to the database all on a web interface.
- But you will be able to translate online on the web interface, string by string. This way translation projects can attract micro-contributions, if someone only has the time to translate a few strings, the web interface will surely fit nicely.
- Translation packages will be generated for all releases of all projects, without your intervention. You don't need to think about branching or other CVS wizardry. (In fact there is no branching support planned for the initial version, so you won't be able to translate 'Home' differently for Drupal 5 and Drupal 6).
All-in-all this might sound a bit like the Launchpad Rosetta interface run by Canonical, but is very much optimized to work with Drupal projects. I have seen some of the translation teams use project module and some use case tracker or some other home grown solution. At the Hungarian translation I work with, we developed the filebrowser module to provide an interface on top of our custom subversion repository a few years ago. The idea behind the localization server is to provide a better service for all translation teams without resorting to custom solutions to be set up by all teams themself. (There is nothing in this design which stops people to keep using external custom tools, but I hope we can work toward a better management tool, which would fit all groups).
This project is in the works for a considerable amount of time now, in fact Bruno Massa started the initial work as part of his "live translation" movement, which I took over to actually get rid all of us from the above described hassles. The reason to announcing this now is that there was no "meat" to show to you before. Now there are at least some screenshots, which show you how this service might look like. I still heavily work on the translation interface, so I cannot show that to you yet (although I know you would be eager to see it) and I welcome any feedback anyway, so feel free to post your opinions in the comments.
Localization client
There is an old feature request: provide an on-page (in-place) translation editor for Drupal sites. So when you notice translation errors or untranslated strings, you can just click and translate the strings on the same page (AJAX to the rescue), without going to the locale module interface and searching there. The localization client project (for Drupal 6.x!) deals with just that. There are new features in Drupal 6.x which make this possible, so I started a proof of concept implementation. Several people suggested that this functionality could be connected with the server, so you can share your translations with the community. This is not yet implemented, so stay tuned. The user interface of this module is also quite bare-bones, needs a nicer solution definitely. I would very much welcome people to help here out, as I would like to concentrate on the server component as part of my SoC.
Cleaning up the language list and plural information
An easy and immediate way you can help me is to read my SoC group post, and if your language is questioned for whatever reason (bad looking plural formula, bogus language code, too much language variants and so on), then please comment on the issue there. Also, if your language is not in the list, but you have translations in the Drupal.org CVS repository (or hosted your Drupal translations elsewhere), please also comment.