It was about time for both moves, right? Yeah!

I've first experimented with moving to Drupal 7 on a copy of my blog this January, and that went relatively well. I've had issues with one node module update function and non-unique entries in my files table, but the inconsistent data issues I fixed myself, so the update went smooth. However it did not go live due to hosting and other issues. Of course I don't need to look too far for hosting, Acquia provides fantastic hosting offerings, and just using the cloud hosting product for this migration turned out to be a pleasure. The version control based automated deployment, drag and drop workflows and the availability of command line tool power combined made me able to migrate my blog in a couple hours (with the DNS turnover taking what felt like lots of time after that).

As with all updates, I took a long look at the modules I'm using, and decided to drop some. I've dropped the Feeds module setup for twitter aggregation that I've set up in 2009. I still intend to tie in twitter, but that setup was too much for this simple task. I might end up porting the Aggregator item promotion module that was originally written for the drupal.org redesign but then went unused, to Drupal 7. I've also dropped tagadelic and my flickr feed.

On the other hand, I tried to give more strength to the useful content I have, so decided to create a book module powered compilation of my multilingual Drupal 7 article series for easier navigation. I also believe that this simple configured version of the Bartik theme gives more room to my content and is overall cleaner and more professional compared to what I had before.

Hopefully I'll have some time to tinker with this new setup as time goes and improve it continually. So far I'm definitely satisfied with the results and believe it will be better for my readers as well with the speedier service and slick look.

I'd like to hereby thank my previous provider, hoszting.com for the hosting space they've provided me with over the years.

A bit of an exception for my English speaking readers, a little Hungarian word-fun for Easter.

Mindig hiányában voltam a frappáns húsvéti locsoló versikéknek, ezért idén elhatároztam, hogy a klasszikus zöld erdős témában eszperente módon fogalmazom meg a gondolatot. A kiindulási alapot és a leírandó képeket ez adta meg:

Zöld erdőben jártam, kék ibolyát láttam,
El akart hervadni, szabab-e locsolni.

Namost tudjuk, hogy ez így elég unalmas, viszont a képeit mindenki nagyon jól ismeri. Íme tehát a költeményem:

Eszperente permet-rege (nem vers)
melyet eme szerzet szerezett, s lelkesen elrebegve kedveskedhet vele

Elkezdem.

Elmentem egy helyre, melyen termetes fenyvesek terpeszkedtek eltelve,
S mellette kecses, csepp leveles nefelejcset nedvmentes, kellemetlen helyzetben feszengve leltem, melyben nem cseperedhetett.
Nem kertelek! Eme, kezembe helyezett nedvvel fejedet megpermetezhetem-e? Lehet?

Alternatív befejezési formák: Megengeded?, Nem ellenzed?, Kedveskedne neked?.

Jó verselést holnapra!

While writing the Drupal 7 multilingual features posts and planning for the upcoming items in the series, I always wanted to figure out a framework for thinking of these items and to match core features and modules with contributed module functionality. Drupal 7 clearly is a multilingual system with additional contributed modules only. Also, there are so many modules involved that a summary of which Drupal objects they work with and what functionality they serve would be clearly beneficial to summarize in an overview.

Drupalcamp Stockholm is coming up shortly in just 3 weeks on May 6-7, 2011.

I'll be there with my collegue Jeffrey A. "jam" McGuire. While Jam will tell you how to accelerate your business with Drupal Gardens and Drupal Commons, I'll provide a fresh look at Drupal multilingual site building including latest developments with the git migration and localize.drupal.org and present you great tips and a framework for thinking about Drupal security best practices.

See you there!

With the basics of node and site settings translation behind us, we are getting to the more complex parts, at least in terms of the user interfaces involved. While with node translation you get a tab on each node to translate it (regardless of setting up translation sets or using translatable fields), and with settings translation, you get quick jump links, the subsystems that work with textgroups will require a better understanding of how the Drupal systems relate.

Three ways to think about language support

When people want to have language support for their site, they typically think of one of three things:

1. Being able to mark an object as in one language. With node translation this was achieved by language enabling nodes.
2. Being able to mark an object as in one language and relate it to others as being a translation set. For nodes, this is supported by Drupal core's content translation module.
3. Finally, being able to translate pieces of the object that need translation and leave the rest alone. Load the right language variant of the object dynamically as needed. In the case of nodes, this is achieved with the contributed entity_translation module (formerly translation.module).

The first case is great when you don't need to translate the object, the second is great when you need to use translations in different contexts (for nodes, you can maintain a separate comment set, put in different menus, etc). The last is great when you want to maintain the object the same way regardless of language. This might be great for an e-commerce site. Read part 4 of my blog post series for exact details for nodes.

Applying this to blocks, the i18n module provides functionality (1) and (3), but not (2) at this point. Translation set support is being implemented for various objects (menus, paths, etc. are already covered by i18n), but not blocks yet. (1) is very simple to use, but (3) will be a real pain if you don't read this blog post...

While Drupal improves its multilingual features with every version and there were numerous improvements with Drupal 6 and 7 especially, there are still lots of things for which contributed modules are needed, and multilingual support is not consistent (neither in some cases usable) with these modules. There is sizable customization and glue-code building required.

Karsten Frohwein thought to take these problems and organize a group of contributors to take a deep look at them, conceptualize on better solutions and do actual implementation in a concentrated environment. Thankfully, as with great ideas, he got lots of support from companies and individuals interested, so the Internationalization SprintCamp is a go between the 11th and 15th of May 2011 in Berlin. Key contributors are being confirmed one by one, so this event is promising to be a great and high energy one for improving multilingual features and fixing bugs. There is place for up to 20 people, so we are looking for developers who can join and help. Contact Karsten through the Impressum page or leave a comment here with your contact information (such as drupal.org username or user URL).

The sprint is sponsored by the German Drupal-Initiative e. V., Comm-press, undpaul Drupal Development, Acquia and others. We are planning to do couch-surfing to reduce costs and increase fun. If you'd like to help sponsor, contact Karsten.

Ps. we will hang around in the #drupal-i18n IRC channel throughout the sprint, and distribute information and guidance for anybody who'd like to join and help virtually. See http://drupal.org/irc for more information on Drupal's IRC channels.