As some people started to pop up in the issue queues of modules I develop as part of my Summer of Code project, I though it would be great to take this time and provide a generic overview of how the different projects relate, what is possible already, what will be possible later (as planned). My Summer of Code project consisted originally of three components, of which one was about Drupal 6 core improvements, and two about contributed modules/functionality. I detailed nearly two weeks ago that the remaining two were redefined to an online localization server project. Here is how this looks architecturally:
The general goal is to get all translations out of CVS, and provide a central, web based translation interface for all releases of all projects (modules, themes, install profiles). There is experimental implementation for the project module integration I explained earlier. Although there are smaller issues to work out on the project module side (to provide better data for my module's needs), the project connection is working nicely. So the localization server grabs project releases, and collects project-release-file-line-string relations. All releases of all modules are parsed, which is (will be) a lot of initial work on the server, but otherwise we cannot tell what translatable strings we need for all releases. So the localization server knows what project, what release, what file and what lines a specific string appears at. (It does not store the errors noticed while parsing, but it is the next step there).
The localization community component is not up to the latest changes in the server yet, but it's inner workings are still to be defined. It should have a sane UI to browse between all the project releases without being too intimidating. I am weighting different options here, still to be defined. Another interesting question here is how to support storage of plural versions of strings in the database (the Drupal core way is not really attractive, but it was not possible to make it better in Drupal 6 itself). Finally the last open question here is how to store "editing histories" of strings. Whether to store all actions made on strings: suggestions made previously, users who suggested and (possibly) approved strings, and so on.
The remaining component is the localization client, which is in development for Drupal 6. The new Drupal version provides the possibility to support on-page translation, which I took my last days to develop an experimental localization client implementation for. The implementation allows users of a Drupal web site to translate strings on the actual pages where the strings are displayed. So on the Drupal welcome page, the on-page translation form allows users to translate the welcome message paragraphs, the displayed menu items, the breadcrumb items, the page title, and so on. This needs a small theme.inc modification, which might get into Drupal 6, as it is a logic improvement in the engine code. Test/support the patch please!
Where is work to be done in the coming days?
- Better project and localization server integration (project and release listing from updates.drupal.org)
- Getting localization community up to date with the latest project integration model
- Better UI for localization client