Drupal 7

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.

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...

In the previous part of this series, we talked in detail about translations for nodes. For this next piece, I've promised to cover site settings and layout (blocks and friends). As the multilingual landscape progressed (Jose Reyero released the first beta version of the Internationalization module for Drupal 7!), I decided to dedicate this piece to site settings only. That sounds pretty basic and boring, but we have some good news and improvements here that developers should hear too! Read on for more information on how this crucial piece of the puzzle looks like in Drupal 7.

In the second part of my article series, before we got on a developer detour, we discussed that Drupal's software interface translation can be pre-provided and collaborated on by the community, but this time we turn to your own content. What's considered content on a Drupal site? Well, in a broad sense, anything that you enter beyond the software user interface translation. For this article, we will limit our discussion to nodes only, and move on to the rest of the structure and page building elements in later pieces.

As promised at the end of the previous piece of my Drupal 7 multilingual post series, this part is turning to developers to spread some awareness of new features and possibilities in Drupal 7. We've talked about context support and new language selection features, and I'd like to share some tips with you to use them right. I'd also like to share an updated version of my Drupal 6 localization cheat sheet as well as its appropriate version for Drupal 7 with you and look at how can you hook into the heart of the language system.

The previous piece in my series covered the basic language features in Drupal 7, including setting up which languages are available. Merely adding a language to your site will not make Drupal do much though. The site "in that language" will still look entirely English. The reason for this is that Drupal works with English as the default interface language and will fall back on that each time you have no translation for something. Until you provide Drupal with translations, it will still be entirely English. While weaved into my Drupal 7 multilingual series, changes explained herein affect Drupal users on all Drupal versions. Let's see how obtaining and working with translations changed not so recently and how can you get most out of that on Drupal 7!

This is part one in a series of posts on the new multilingual features in Drupal 7 core and contrib. I was sadly not as involved in the core mutilingual work that I wanted to (was busy working on localize.drupal.org), so I need a refresher myself on some of the finer details of what is going on. Therefore my journey through the new features, which I thought would be useful for you dear readers too. Thankfully many bright folks picked up the work and drove a good bunch of new functionality in terms of multilingual support into the new version. Let's begin!

I remember how skeptical I was looking at some presenters traveling around to multiple conferences with "the same" presentation a decade or so ago. Having been a course instructor for years and being a presenter for even longer, it looks completely different now. It's not that the topics you cover under the same looking umbrella can be quite different, you also find much better ways to express whatever you want to tell your audience as you experience feedback.

Of course the best would be to present your story crystal clear from the start, but despite being an enthusiastic follower of Garr Reynolds and Nancy Duarte, you'll undoubtedly need lots of time anyway to take a relaxed look on your story and distill to the level needed to form a great presentation. I've actually found it quite hard to refine my slides without actually showing/presenting them to an audience. The faces, questions, smiles and sometimes plain staring expressions you get tell you how you'd done and you can derive ways of how can you improve.

Two interesting examples are my slides on Drupal 7 and localize.drupal.org.

Things been quite quiet lately here on my personal blog. This does not mean that my days were not action packed though. I was quiet due mainly to being busy with working on all the Drupal 7 usability exceptions and blogging directly on the localize.drupal.org news blog.

It is time to share the love and show these to more people around my region. So I'll go to Prague and show what Drupal 7 has on offer and how can people translate Drupal easier then ever before. With two sessions on the schedule, I'll be busy this weekend to show all the awesomeness going on these areas.

The Prague event still has 70 free (as in beer) seats open as of this writing, so it is not late to register! My colleague Robert Douglass will also be there to present sexy search and Acquia. There will be a pretty heavy Hungarian contingent going presenting about Druplash, Services and Amazon EC2 integration plus our Hungarian in honor, Kristof van Tomme presenting knowledge management integration in Open Atrium.

There are plenty reasons to come, so don't miss out!

Mark Boulton created the new Drupal wordmark as part of the Drupal.org redesign efforts. As highlighted by Jeff Traynor of Raincity Studios, the newly relaunched Drupal.com now uses this new wordmark as identification for Drupal and the wordmark is also destined to land on Drupal.org as part of the redesign (implementation unfortunately still underway).

So why not include the wordmark in shipping software as well? A logical step would be to have it on the installation and update (also known as maintenance screens). The patch for using the new Seven administration theme for installation and updates does just that. Because it is only a first approximation of how this should look, I'd love to get help cleaning it up and polishing things like lining up items, correct font sizes and fixing graphics - so we get a really polished experience for people's first Drupal encounter as well.