There is great discussion forming on my previous posts on exportables and user provided text as well as the dangers of using t() for user editable data, and I can only hope we can keep that up! In that tradition, I'm cross-posting this piece to groups.drupal.org as well for discussion.

Regular readers could find this boring, but let's reiterate the three working modes that all objects should ideally be able to handle in Drupal to support multilingual site building.

1. Being able to mark an object as in one language.
2. Being able to mark an object as in one language and relate it to others as being a translation set. This is useful when you want to use the different language objects in different relations, track their history separately, have different permissions and workflows for them, etc.
3. 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. This is very useful for keeping external relations intact and sharing common fields between translations effortlessly.

There are certain things, where not all of these make sense. For the site's name for example, people would probably only use either (1) or (3). For a block for example, people should be able to use either based on their needs. (2) is useful to place blocks differently on translated pages, (3) is good to keep the placement consistent without effort. This can be different on a per-block basis. Same applies to nodes, menus, taxonomy, views, rules, and so on.

In my previous post titled Drupal's multilingual problem - why t() is the wrong answer posted on my blog and on groups.drupal.org for feedback, I've detailed issues with using t() as a translation tool for "user provided data". This post goes into some further details, a discussion of current solutions which could form basis for discussion of future solutions.

How can we even tell the difference between code and user provided translatables?

It is fair to assume that many multilingual sites will not have English as their default language (many not even as any of their supported languages), so we cannot assume that blocks, menus, and so on are entered in English. However, source code based strings are considered part of the user interface, and as such assumed to be written in English. What does this has to do with default configurations set up by modules and How do we reconcile this with the growing popularity of exportables and features (as in Feature module generated versioned export packages)? Let's look at these two questions.

Drupal is a great system to run foreign language websites on. The core itself is written in English and modules and themes are expected to follow suit. For developers, very simple wrapper functions are available to mark your translatable strings and let Drupal translate them to whatever language needed. These are the famous t(), the less famous format_plural() and a whole family of other functions. See my cheat sheet (PDF) and the drupal.org documentation for more on this.

Then there is "the other side", whatever does not come from code. Drupal works pretty well and very consistent if you want all of those to be in a foreign language (i.e. not English), but not in multiple languages (any of which can be English at that point). Drupal only has direct multilingual support in nodes (+ fields of entitites) and for path aliases. But life with Drupal means you work with all kinds of other objects like blocks, views, rules, content types, etc which are not "language-aware".

Unfortunately for building multilingual Drupal sites, this is the biggest problem that needs to be worked around. The contributed Internationalization module attempts to fill in the gaps, provide language associations and different workflows for translating these language-unaware objects. This works to some degree, but is really not easy without much help from the modules implementing these objects.

In 2003 I selected Drupal to replace an aging PostNuke system on a Hungarian web developer community site (weblabor.hu) that I helped ignite a few years before. Of course I needed it fully translated to Hungarian. If you were using Drupal back then, you may remember that adding a new language to your site meant running ALTER TABLE queries on your locale tables to add new columns, editing your settings file and handling database dumps of your translations (which was the only way to share them too).

Drupal has come a long way since then.

I just got back from Drupalcamp Stockholm 2011, which was an action-packed two days for me to say the least. Due to a busy schedule, I was only able to arrive last minute the night before and leave just right after my sessions on the second day. Once again I decided to do a multilingual session all over again starting from the drawing board. There are lots of new things happening plus I think I'm developing better models to explain the components involved, so I think it was a good idea to build a new presentation. I've also presented on Drupal Security on behalf of the security team, which I hope turned out to be a very informative introduction to some of the most important things to look for when securing sites.

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.