As some of you might be aware, a group of talented and very determined people sprinted in Berlin about a month ago just to improve the i18n module for almost a week. A lot of great improvements made it in including tests, translatable contact forms and even some great usability improvements. Jose Reyero and Friederike Schmiedebach have great posts about the sprint.
Before continuing my article series, I wanted to touch quickly on the usability improvements, because my previous piece presented a pretty grim picture of textgroup based translation solutions such as blocks. Well, i18n module is still using that backend, but the new user interface improvements will make the translation process much more transparent and a lot easier to work with when managing Drupal configuration.
Let's do a quick recap of the block translation process to see these improvements. For blocks, you have an option to translation-enable the created block, which saves your block properties as translatable and then you had to look them up on the locale module user interface, a pretty disconnected place from where you managed blocks. Then when you edited the block, you needed to go through the process all over again. This was explained in my previous article in detail. Not anymore with the current beta versions of Internationalization module for Drupal 7! If you grab the beta7 version of the module for Drupal 7 available now, you'll see a much better process.
When you create a block, the checkbox to enable translation for it now also magically pops up a button titled Save and translate which will - as its name suggests - save the block and bring you right to the translation page. But not to that confusing locale UI we discussed previously, no.
Most objects now have a unified Translate tab which for blocks will look like this:
Yes, this is just a local tab on the block configuration screen, and it is modeled closely after the node translation screen. It lists all possible language versions of this block marking the source as such. When you go to translate the block to a certain language with the appropriate translation link, you'll see all the related fields of the block that need translation, but not anything else. No more fiddling with cryptic IDs for the block properties! These fields are prefilled with your original language version, and can be edited to translate them, just like for node translation.
These translation pages will save the values entered to the same database as before, so you can still edit translations en-masse on the locale module user interface, but everything is local to the blocks now as well, which is much more comfortable. What's even better is that the translation feature is now also accessible from the contextual menu on the block, so you can just go right into fixing translations for a block:
Finally, while I've shown these for blocks, most other translation modules in i18n will do the same. Say you have your contact forms, your contact form editing screen will include a Translate tab that does the same.
I think these usability improvements planned and implemented by many smart people at the Berlin Internationalization sprint with feedback remotely from the Drupal usability team are great to make your translations much easier. Thanks to Acquia for sponsoring my involvement! Now plans for a later version of Internationalization module include to move away from the locale textgroup feature so that you can easily change your site default language anytime (which is not at all advised now) and have a much improved user experience when translating your site overall.
With these usability improvements in place, I can finally go ahead and explain menu translation in my next blog post. It became much easier to understand recently but there are still some things to keep in mind. Until that is posted, you can check out all of my Drupal 7 multilingual tutorials at http://hojtsy.hu/multilingual-drupal7 - Happy reading!