I have been to REMIX 07 today, which was basically a rehash of some of the Microsoft MIX conference topics and presentations for a road show stop in Budapest, Hungary. Although I use much less Microsoft technology then I actually go to the conferences, I mostly enjoy going because it inspires me. I see cool new stuff which of course escalates into cool new stuff I would like to implement with my tool set.

One of the simple ideas that occurred to me today was about in-place interface translation editing. It is so common a request to ask for in-place editing tools for translations in Drupal. Just recently, Boris Mann posted a pointer to SLS, which aims to be a more generic solution for the problem (although I commented there why I don't think it fits Drupal well). Unfortunately we only know in t() that we are working with a localized string, so we could print a span or div with metadata to allow some jQuery to tap in and allow translation editing. Unfortunately in t(), we don't know whether we deal with output for email, SMS, watchdog logs and so on, where the extra div or span would look very unprofessional (in a text medium!). So that rules out the PHP way we could add an in-place translation widget (forget about introducing another wrapper, t() is wrapped deep enough).

Over the past few months I’ve been researching how TYPO3, Joomla, Plone, and Drupal currently support multilingual content. Since this work was in part supported by Development Seed, I happily accepted the request to guest blog some of my findings.

This year, for the first time, a big two day Drupal event is going to be organized in Sankt Augustin, Germany as part of the FrOSCon 2007 conference (25th-26th August, 2007). Robert Douglass has more to say on this on the dedicated Drupal group, looking for speakers and sponsors for the event. The call for papers deadline of FrOSCon is closing up, you only have one week to propose a session on Drupal (or any other FrOSCon fitting topic) for the conference! Update: The Drupal session submission deadline for FrOSCon was extended to 1st July!

Lately I have been poking around workflows to better support translators. The localizer module suite has no built in workflow support, and i18n module suite has a very simple and limited built-in workflow, so for complex workflow requirements, people need to look elsewhere. Luckily, respected members of the community maintain the workflow and actions modules, which allow for setup of more complex workflows.

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.