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!
Translation liberation
Translators used to use the CVS version control system (as well as issue queues) on drupal.org to contribute translations. Well, drupal.org is about to switch to git, so that should solve all problems experienced before, right? Not so much. Many translators are happy without version control accounts, so they use issue queues to submit translations. The submitted .po files are not easily merged with existing ones, and even if they are, how can a random module maintainer tell if a newly submitted Danish translation is better then the one already available?
Then there are the source files for translations themselves. Module maintainers used to be instructed to generate these files with the Translation template extractor module for the benefit of their translators. Many did not do this or had outdated templates lying around. Even if their templates were up to date though, translators only had a chance to get their work into new releases of projects before they were packaged and wrapped up. While project maintainers could change anything last minute, translators had no chance to keep up.
Even if they kept up, they had significantly more work to do over and over again. Many modules reuse source strings from Drupal core or other modules. With project space separated for these projects, translators needed to go and translate often the same strings all over again. If they made a mistake on one of those strings in one project, websites could get bad translations for certain strings all around. Drupal can only maintain one translation per string, so if a string appears in tens or hundreds of projects, there should be no need to translate it as many times.
And then, even if the template was perfect, the translation was up to date, and so on, when you update modules and themes, Drupal has no consideration for the updated .po files in your project directories. It will only import translations on first encounter, not when updates are performed. So in short, translators have no way to get updates of their translations out for existing projects and later updates are often not imported.
There must be a better process for project maintainers, translators and users!
There comes localize.drupal.org
The goal of localize.drupal.org was to solve most of these problems. First, it automated project and release discovery and parses each release for translatable strings, so outdated templates should not be a problem. Then it provides a web user interface as well as the possibility to import translations done offline. No requirement for version control accounts (but it keeps fine grained history of each translated string individually still). It decouples translations from projects, the translation files are downloadable separately. So project releases can be followed up by translations later, and the same project release can get fixes for its existing translations. Localize.drupal.org also shares translations between projects, so there is no need to duplicate work per project/release. Translations are packaged for download through ftp.drupal.org for fast access.
Just the first few of the languages available
Wait, this is much harder for users, isn't it?
Ok, so we decoupled the translations from projects. So Pathauto, Views, VotingAPI, etc. will not include translation files anymore. Wait, does that mean that you'll need to download as many translation files as many modules/themes you use? Think if you use 30 modules, you'll need to download 31 translation files, right (including Drupal core)? What if your site needs to support 3 languages? 93 files! That sounds bad. Also, translators can fix and improve their translations anytime, so if you are interested in all the fixes and updates, you'll need to keep coming back and downloading and importing new ones. This is clearly not scalable!
We were of course perfectly aware of this, so Jose Reyero built the Localization update module (insert fanfare sound here). Of course figuring out which projects you use on which versions and grabbing and importing those files can all be automated. This is the goal of the module. So even if you use 30 modules and need to support 3 languages, it will support you by keeping your translations up to date automatically. It even supports custom local changes to translations, and keeps track of them.
While the module is not perfect yet, my general recommendation is that you start using this module (on Drupal 7 and 6 alike) as soon as possible. In the best case, you start off your Drupal site with this module on. There is a full install profile called Localized Drupal to help you get started with Localization update right away. It includes installer translations for languages on localize.drupal.org and works with Localization update to download core and contributed module translations for you. Please help spread the word and suggest starting off with this profile for newbies who need a localized Drupal website out of the box!
Admittedly there are a few gotchas: the Localization update module interface could use some simplification (and cleanup), localize.drupal.org will not parse dev snapshots so if you are not running concrete versions, currently translations will not be downloaded and finally if you are memory or runtime limited, you might benefit from seek based translation file imports, which are not yet included. You can keep yourself updated through the module's issue queue.
Localization update functionality
Once you enable Localization update, you'll get a configuration page and an update page at the usual places. Administration » Configuration » Regional and language » Languages will now have a subtab for Translation updates. You can configure the update behavior here, including the possibility to store the downloaded files locally (for easier use in a multisite setup for example). Home » Administration » Configuration » Regional and language » Translate interface will now have a tab titled Update which lets you review your localization update status and perform outstanding updates.
When you enable a module or theme, localization update will look for its translation on localize.drupal.org and download and import as configured. The module can either keep your translations up to date on cron runs, or let you update translations manually when you see fit for better control. Whenever you edit translations on the Drupal built-in web interface or with Localization client (see below) the affected strings will be marked custom automatically. Further localization updates will not modify your custom strings, letting you keep your own modifications to the community translation.
This is all there is to Localization update. If you keep your site updated with new strings, old unused strings are not removed though. This is not a new problem, it was true for all previous versions of Drupal. There is an outstanding feature request for translation template extractor to provide services to overcome this little problem.
Improving translations and contributing back
To complete the localization cycle, you'll find the Localization client module useful. This is, as mentioned, also included with the Localized Drupal install profile. If you've used this module before, it is worth another look (and an update), since there are great new fixes and improvements in the latest versions.
The only time this module has a visible user interface is when you are viewing translated pages. In that case, the interface displays translated text, but typically, not all of the strings are translated by the community. This module lets you fix and improve the translations as you browse around your pages. It displays a toolbar at the bottom of the page that you can open up to see the list of strings displayed on the page. A quick-search feature is available to limit the strings to ones you are looking for. Once you pick a string, it displays the source text and lets you enter/edit the translation.
This module can be used to contribute back to the community too! Its admin page is on the Sharing tab at Administration » Configuration » Regional and language » Languages. Here you can enable sharing your submitted translations with a server, which is localize.drupal.org by default. However, merely setting up sharing on the server level is not enough to make it work. The module will keep reminding you on its user interface if the server is set to share but your personal key is not set up. The server keeps track of who submitted certain strings, so you need a private key set up in your user profile to identify yourself with submissions. Once that is in, each of your submissions also goes to localize.drupal.org simultaneously to local submission.
Localize.drupal.org has a slightly outdated description of setting this up, but you'll be able to figure out the small differences.
Developers next
The next part in this series will take a little detour from the user interface and cover how topics in the first two parts affect developers. Then we'll come back in full force to see content, field and entity translation. Stay tuned.
Awesomeness
The new Drupal 7 multilingual systems is dripping with awesomeness! Thanks for the article.
Thanks again for clarifying
I learned a lot. Keep going!
What about multilingual menues?
I was able to translate content with D6 and D7, and I used i18n with D6 to translate menues (but this was somewhat awkward). If you could provide some insight into a simple and straightforward way to translate menues this would be much appreciated.
coming up
Coming up in a later piece.
Excellent set of posts Gabor!
Excellent set of posts Gabor! Thanks for putting this together
I have one question, though, about the translation process, how long does it take to a translation done via localize.drupal.org or localization client to get populated in the .po files?
currently at most a week
Currently, most teams are set up to have moderation. If you are not on a moderator level, your suggestion needs to be vetted to be included in the .po files. For moderators, they can directly submit "final translations" or say "moderated strings". Currently the .po file generation system is tuned to generate the .po output at least in a week after the new translations are in.
There are plans to make it quicker, but it would not go quicker then a day or two or the constantly refreshed files would make the l10n_update and other clients hammer the server with constant pulling of files. It is never going to be immediate, but less then 7 days looks like achievable. Of course it all depends on translation activity as well. If everybody starts to translate hard, the timing can stretch out longer.
Translations overlap
Perhaps I should post this to Drupal.org but I am having a lot of trouble with this sentence:
"Drupal can only maintain one translation per string, so if a string appears in tens or hundreds of projects, there should be no need to translate it as many times."
It sounds smart at first but having dealt with multilingual websites, its not that easy. The best way to illustrate the problem is with the example of abbreviations. Let's take the abbreviation DFO. While in the government of Canada context that mean Department of Fisheries and Oceans, in India it means Divisional Forest Officer.
The root problem is that context can change the meaning of words, and therefore there translations. Currently there doesn't seem to be a way around that. The ideal solution would be to have IDs (with namespacing) for strings so that you can use already existing ones or define your own.
Thoughts?
context
Yes, Drupal 7 already supports context for strings, so you can specify additional information on the meaning. So a more correct explanation is that "same strings with the same context share translation, however context is empty by default, so most strings share translation by default; it is the job of developers to provide context for strings".
Can you have a foreign
Can you have a foreign language as the default URL and english as a subdomain like url (www.somesite.com/en). I have had problems with multilingual sites having a foreign language as the default URL.