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!
the API part
I've also posted about the API behind these translation tabs at http://groups.drupal.org/node/152929 (although the API already changed a bit since then). So head there if you are interested in the API behind.
Presets & Language negotiation
Your work on languages has been magnificent, but I'm finding it hard to keep up. I would like to request some simple presets for typical use cases. especially regarding the language negotiation weightings! I spent a long time trying to get it right, and I still don't know if it's working as intended.
I would like to request some
Totally agreed that this would be highly beneficial, see:
http://drupal.org/node/322995#comment-4610066
Great posts all 7
I have read all 6 of your post last month and now 7 is here. It is great stuff. You guys are doing fantastic job in developing this multilingual system. Before studying your blog i was unable to understand multilingual system in D7. Now I know what I have to do to make a multilingual site in D7. Keep up the great work.
very helpful articles, thank
very helpful articles, thank you Gábor
article #6 seemed a little bit sparse, like it didn't contain as much information as the rest. but it was enough to describe block translations.
The possibility to change the site's default language would be really great (I mean you can still do it at this point but it won't work as expected).
eagerly awaiting your post on menu traslations
Thank you!
I like to thank you for your great work you have done with this tutorial, Gábor!
I'm working on multilingual website at the moment and you really saved me so much time. Unfortunately I'm stuck at the menus right now, therefore I am longing for your next party :-) Do you know, when you have the time to make it? :)
Best regards from Germany,
tharya
block translation
Wow, things have really improved a lot in i18n for Drupal 7 since last time I checked. Thanks to everyone for all the work done in Berlin.
Regarding multilingual blocks, I would like to share a little trick that might still be useful in some cases:
1. Create a node with some content you want displayed in a block. You probably want to disable comments and author information for that content type.
2. Make one or more translations of the node.
3. Make a view that displays a block.
4. Select Show -> Content and Full content.
5. Create two filters:
a) Content translation: Translation set node ID (=source node id of your node).
b) Content translation: Language (= Current user's language)
6. Save the view and enable the block.
Depending on the site language, the content of the block will also change.
For a simple text block, the method provided by the new version of i18n is easier, but if you want to include more fancy stuff, like images, I think the above method is smarter. And it can be used in Drupal 6 as well.
These articles really enlighten me
While building multilingual web sites (50% of them) I always have some difficulties and confusion in my head. This articles really helped me a lot. I spent whole day reading and testing all this setups on my local dev web site. Can't wait to put my hands on the next multilingual project :). Thanks Gábor!
Change default language right after install?
"...so that you can easily change your site default language anytime (which is not at all advised now)..."
So it's still not advised to change default language in Drupal 7. But what if you just installed Drupal 7 (with only English), is it still a bad idea to change default language for some reason? Or is it just after you entered any content that it is advised against?
And a follow up question:
Are there any downsides to choose another language than English as default?
More detailed: If my site only will be one language (Swedish in my case), but as a developer I need to use English when building the site, are there any downsides to set Swedish as default language?
Or would it be better to let the default language be English and for example force the site to use Swedish by hook_language_negotiation_info() as suggested in Use another language than “default” as standard?
use of default language
Well, the default language is basically used to assume language attachment for anything where you specifically do not set a language. Such as all taxonomy vocabularies and terms if you use i18n to translate them, the site name, blocks, etc. Once you create content/configuration in these areas, the default language is assumed for them. Once you change the default language, the assumption changes and existing translations will not be properly assigned. So as long as you don't have any content/configuration on the site, it is pretty safe to change the default language. If it would be unsafe at all times, it would not be changeable.
I agree it would definitely make sense for the more common "content is already created" case to have a configurable language fallback for detection, since that is why most people want to change the default language later.
hi,
hi,
I really would like to have only one form to translate my entities
for example, I have my content type article with the fields title, body and image but only the title and body are translatable in french and english
what I want to have in my node edit page is as following
title_fr
title_en
body_fr
body_en
image
all the languages would be on the same page and I think that it would be really simpler for the common users
any idea?
thx
tim