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:
Being able to mark an object as in one language. With node translation this was achieved by language enabling nodes.
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.
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).
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.
Google is at it again! The legendary Google Summer of Code (GSoc) is organized again for 2011, and it should be lots of fun for students, mentors and organizations alike. GSoc is a summer-long activity for students where they can work on interesting and real problems with open source projects and earn money in the process to pay for college or whatever they wish.
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 proposed two sessions: How to integrate the core Drupal 7 usability improvements with your module and Drupal's new localization infrastructure and where do you fit in. I think both are important topics. Drupal needs contributed modules and distributions to be top notch in terms of usability (even more so then core) and it needs localized interfaces and communities to help it spread in all kinds of cultures. While the first session is more coder oriented, the second will hold invaluable information for site builders and translators as well (while keeping module builders in the loop).
There are already almost 300 people signed up for this event, so it looks to be shaping up to be fun and busy again. If you are working with Drupal, do not pass the opportunity to get yourself integrated in the community. This event is great to get started or just keep it up. There are various reasons working on Open Source software is going to benefit your career.
