By looking at what people described as their use case, there is a considerable amount of interest in a CAT (Computer Aided Translation) support tool in Drupal. While Drupal 6 could (and will by default or with a contrib module) provide a translation interface for nodes, content created in professional systems is often not translated inhouse, translation work is outsourced to professional translators. These professionals employ tools to remember previous translations, build on existing terminology and reuse what is already done.

At Drupal.hu, we host a list of Hungarian Drupal sites, into which submission is open. But publishing is moderated, partly because screenshots should be taken somehow, and we often get false submissions. The Visegrad.info Internet Magazine seemed to be a false positive too, it's footer saying that it runs on 3N CMS. But looking at the source code, obvious snippets like @import "/misc/drupal.css"; showed that 3N CMS is actually Drupal. So I was on to see, what company developed this wonderful product.

The Hungarian Drupal interface translation team used to use a private Subversion repository to store translations. Our reason for that was that we initially had many people contributing, and it seemed to be difficult to apply for CVS accounts for each of them. It also happened that we had some of our own tools developed and used. Now there is not that many contributors and many of our tools are already migrated to Drupal.org (and the others can be migrated too), so we are moving to Drupal.org. This will most importantly be better for our users, so they can find Hungarian translations in the tarballs downloaded from Drupal.org, without browsing through our own translation repository.

Since the 4.7 version, Drupal has free tagging included by default. Unfortunately this only allows for a shared tag set for a node, so that when multiple people tag a node, those tags go into a common list. Who tagged the node is not remembered, anyone can remove any tags and add new ones (given the permission).

Some people argued that this system should be called folksonomy, because at that time that was the hype of the day. Luckily the free tagging name was kept. Although if you need real folksonomy support (per user tagging, editing of own tags, personal tag clouds but still powering a common tag set), you need to look into a contributed module. Interestingly there are two similar solutions for the problem: the community_tags module and the taxonomy_user module. Since I need this functionality for a project, I needed to look at them, so here is a rundown of the differences I see from looking at their implementation.

In a recent blog entry titled The future of Drupal interface localization lies in install profiles I showed you a proof-of-concept way for a new Drupal interface translation packaging format. As the Drupal 5 release is closing on us, and we were able to fix quite a few small glitches around interface translation related problems, I decided to clean up the packaging scripts and release them to the public, so other translation groups can try this distribution format and we might eventually get this up at drupal.org as the default.

I have uploaded the packager shell and PHP scripts to the tricks contributions area. I hope I have provided adequate comments in there to let you know what directory structure is expected by the script to work right. If everything is done fine, it should generate packages like our hu-5.0.tar.gz which is our downloadable for Hungarians interested in more advanced interface localization. We don't even have the previously used package format for download anymore.

I am that adventurous type to try to update weblabor.hu from Drupal 4.6 to Drupal 5.0 directly. This type of update is not recommended, because it is not ensured that everything will work fine. Unfortunately this time the direct update is not possible without some tweaking of the system.install files, but it seems to be doable.

The problem lies in the fact that Drupal 4.6 (and 4.7) supports only code defined node types, so there is a hook to ask modules about node types they define. That hook is called in two updates to fix variables and other changes in Drupal (between 4.6 and 4.7). For this to work correctly, one needs all modules he used in 4.6 (in 4.7) for the update script to query all node types.

Image

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!

Matt Mullenweg (the man behind Wordpress) says in a conversation:

The next version of Drupal is coming out with a pretty neat theme, called Garland. Here's a demo page where you can customize it and save you changes:

http://acko.net/garland/?q=admin/build/themes/settings/garland

This is pretty darn neat. Anyone interested in porting it? The toggle, logo, and shortcut icon bits are probably superfluous, but the color picking functionality is great.

As far as I know, this is the first time that a Drupal theme is ported to Wordpress. There is the feeling of some bad taste in the Drupal community about this port being done before Drupal was able to release this in Drupal 5 though. This still is a historical step in my opinion.

The results are announced (with my emphasis).

The final result, as voted for by judges from The Open Source Collective, MySQL, the Eclipse Foundation, and 16,000 users on www.PacktPub.com saw a tie for first place between Joomla! and Drupal. In the event of a tie, a fourth independent judge would be brought in. This was Apoorv Durga who is a member of CMSPros and runs his own blog [http://apoorv.info/] on portals and content management. This crucial vote ended up with Joomla! triumphing over Drupal by one point.

The final result was as follows:
1. Joomla!- $5,000
2. Drupal - $3,000
3. Plone - $2,000

Full details

We were happy to welcome Dries Buytaert in Hungary at our Drupal conference, around one month ago. We had Marcell Kiss-Tóth helping us with a video camera, and after his hard work with the editing, the conference session videos are now downloadable. You are most probably interested in Dries' presentation, since all other sessions were in Hungarian. The downloadable is very good in audio quality. You can download the video from drupalconf.amon.hu or alternatively from liktor.hu.

As a side note, after the conference, I also decided to publish my Drupal lego figure shots, which were used in my presentation. These are licensed under a Creative Commons license, so you can reuse them in your presentations or build upon them if you wish.