I received my signed copy of Pro Drupal Development around an hour ago from John K. VanDyk, and immediately rushed to the 18th chapter (on localization), to see how it shaped up at the end. I was helping out with reading the manuscripts of that chapter to help readers get the most realistic view of how locale module helps their life, what are the culprits, possibly bad routes to avoid, as well as side effects of some settings. It was a pleasure to help out on the book, and (as a result) a long time waiting for the book arriving at my house.
Well, back in 2003 when I joined the Drupal developer community (got my welcome mail from the drupal-devel list on September 15, 2003), I haven't thought I will be that involved with the system a few years down the road. It was (and is) a rather cool tool for a big Hungarian web development community website I was migrating from some ugly CMS... Now I do so many things around Drupal that it is not easy to track.
On the heels of my recent announcement that thanks to Raimund Bauer stepping in, the translation template extractor is now a separate project, I decided to look into where does this change need to get propagated into the Drupal Handbooks. To be honest, I have not really been around in this part of the handbooks before (although I am a lead member of the Drupal Hungarian translation project), and what I found was not actually pleasing. The Translator's guide seemed to be intimidating for newcomers, basic questions are sprinkled all around the guide's pages. The start page was in the first paragraph talking about what is *not* documented there, instead of trying to help people grasp how things work here.
The extractor.php file sat there in the translation templates project waiting to get criticized to death for being hard for beginners and even people experienced with Drupal. Fortunately Raimund Bauer come along to actually disturb the waters and start to build a web based interface on top of the extraction functionality. For maintainability reasons, this resulted in the extractor.php script getting move to the resulted project.
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.
