Drupal 5 comes out with a nifty new feature (among a lot of others): it only creates database tables and imports CSS files for modules turned on. It is a logical step to do the same with interface translation files. The practice up to Drupal 4.7 was to generate smaller translation template files for translators, so they can better work with strings and collaborate with version tracking tools. These smaller files were merged into one big translation file, which was given to end users to import if they needed the Drupal package work in their language. What should be the new model, and how do we support it? Do I have a working (starter) solution? Yes. Read on!
Maybe we are in time to change the previous practice for the first Drupal 5 interface translation packages, but even if this is not going to happen, the format will surely get changed soon anyway. We need to support importing of translations for only the enabled functionality (themes, modules). For this to work, we need to hand over the smaller translation files to end users, and provide some automatism to import them when needed.
Drupal 5 supports installer translation out of the box. So if you have a languagename.po file in the install profile folder (eg. profiles/default/de.po for a German translation) the installer offers this language, and you can install Drupal on a German interface. But Drupal is still English when you open it up. We need a custom install profile which turns on the automatic translation import functionality for the Drupal interface. This profile is now called autolocale, and can be found as a simple file in the autolocale module folder. This profile turns on the autolocale module, so that it can look at the modules turned on in the install process and import their corresponding small translation files. For this to work, the translation files need to be in some standard place to get found.
This already works almost perfectly (there are some small interesting side effects to work out). The next step would be to support automatic import of translation files for modules turned on at a working (live) site. Maybe also support removing of translations for modules turned off (although there is no metainformation in the database now to support such a feature).
I have the Hungarian community alpha test the new package format and the install profile. I did code some ugly looking shell and PHP scripts to generate this package format, but it works nicely. I fully intend to share the package generation code, especially for drupal.org to refine and use for next generation interface translation packaging.
You can try or look at the Hungarian package if you wish, since it is publicly downloadable from: http://drupal.hu/forditas/forditasdrupalhu/forditas/hu-5.0.tar.gz The screenshot presented above shows me registered and greeted with a Hungarian first user information screen. This was impossible to get before due to the workflow of enabling locale module and importing translations later.
The package structure (files in package) to make the process work is as follows:
// Module PO files
modules/aggregator/po/aggregator-module.hu.po
modules/block/po/block-module.hu.po
modules/blog/po/blog-module.hu.po
modules/blogapi/po/blogapi-module.hu.po
modules/book/po/book-module.hu.po
modules/color/po/color-module.hu.po
modules/comment/po/comment-module.hu.po
modules/contact/po/contact-module.hu.po
modules/node/po/content_types-inc.hu.po
modules/node/po/node-module.hu.po
modules/drupal/po/drupal-module.hu.po
modules/filter/po/filter-module.hu.po
modules/forum/po/forum-module.hu.po
modules/locale/po/locale-inc.hu.po
modules/locale/po/locale-module.hu.po
modules/menu/po/menu-module.hu.po
modules/path/po/path-module.hu.po
modules/poll/po/poll-module.hu.po
modules/profile/po/profile-module.hu.po
modules/search/po/search-module.hu.po
modules/statistics/po/statistics-module.hu.po
modules/taxonomy/po/taxonomy-module.hu.po
modules/throttle/po/throttle-module.hu.po
modules/tracker/po/tracker-module.hu.po
modules/upload/po/upload-module.hu.po
modules/user/po/user-module.hu.po
modules/watchdog/po/watchdog-module.hu.po
// Include PO files and general PO
modules/system/po/common-inc.hu.po
modules/system/po/file-inc.hu.po
modules/system/po/general.hu.po
modules/system/po/system-install.hu.po
modules/system/po/system-module.hu.po
modules/system/po/theme-inc.hu.po
modules/system/po/unicode-inc.hu.po
// Translation for default profile and localized profile
profiles/default/hu.po
profiles/autolocale/autolocale.profile
profiles/autolocale/hu.po
// Module to handle the import at install time
sites/all/modules/autolocale/autolocale.info
sites/all/modules/autolocale/README.txt
sites/all/modules/autolocale/autolocale.install
sites/all/modules/autolocale/autolocale.moduleThe best thing again is that Drupal does not need to be modified in any way. The installer interface translation is supported out of the box in Drupal 5 and the other features are possible to implement by hooking into Drupal when needed.
Nice work
This is a great idea which, I think, would finally encourage people to make po files instead of just manually translating strings using the locale module. Please keep working on it.
Hi, it would be good to use
Hi, it would be good to use the :google translator ajax API" to autocomplete teh translation forms, when the pop up in HTML, like that instead of re-typing them all, then you could just verify the google translations that looked fine, and just change a couple of words in cases that were abit inaccurate.
issues
Issue for l10n_client: Add automatic translation suggestions using Google AJAX Language API
Issue for l10n_server: Let Google suggest translations
i made a crazy code that
i made a crazy code that translates gettext files. i did the ubercart.po in 20 minutes which is 3k strings. i invented lots of php tools that stop google corrupting codewords as much as possible.
it would be good if google translate API provided an option to keep code words intact, i.e. words beginning in % @ !, because at the moment, commands with % @ ! are moved arbitrarily, and also translates the code string that they are attached to, so !product becomes @produkt. etc.
Else it may be accurate to make drupal exclude strings with @ ! %, from the translator. here is an example:
great example
This is a great example that the Google translation service provides jibberish which should not be distributed as official translation for any language. The Hungarian version you presented here totally makes no sense (given that Hungarian is my mother tongue).