localization

Through the development of the Localization Server project, I decided that it is important that we use icons instead of boring text links especially that we need to communicate lots of different things and provide action buttons for multiple options in a small space.

We do not (yet?) have a graphics artist to help out here, so it turned out that whatever icon set we choose, there will be some problem with the icons size, the exact set of icons available, their color, and so on. So it occured to me that we have a huge set of symbols already in the Unicode character set which Drupal is using, so why not use those as icons?

GMail's labels, Mint's Peppermill site and others already use a trick to wrap a few tags with specific margins to get a rounded cornered button feel, and putting a Unicode symbol in as text makes for a useful button. It is definitely not as perfect as specially tailored icons, but it allows for a few neat things. Let's see...

The current Drupal process of translating with Gettext PO files, trying to get them into CVS before a release file is generated and then going over hops to update it properly is far from ideal. There are lots of drawbacks, and I started working on a web interface this summer, sponsored by the Google Summer of Code program to improve this situation. Unfortunately the server is not yet ready for prime time (on drupal.org), but there are a number of beta testing servers where some translation teams already try to leverage the cool things this tool offers, so I have lots of feedback on the issue queue.

In the last two weeks, I spent a sizable amount of my free time on improving the navigation user interface, and adding team features to the localization server, which resulted in a huge changeset, and consequently an 5.x-1.0-alpha2 release of the module, which is now available for download.

I put in a lot of thought into designing an interface which is both easier on the newcomers and on the experienced translators, but honestly I focused more on the experienced translators with as easy access to their work as possible, implementing "quick jump forms", direct linking possibility to the translation filter pages, and so on. Note that I am not a professional interface designer, I make plans up as I go along, based on user feedback and my own focus areas.

While there is still lot of room for improvement, I believe this user interface update makes using the application easier. I tried to concentrate on emphasizing the application aspects, but honestly this is not easy when you don't have control over the theme your application is displayed with. I played with adding a web application theme into the mix and requiring that for Localization Server onwards, but then decided that this can be done later if desired. For now the navigation changes can live well with any theme not exactly focused on web applications, but web sites. I see however that in the not so distant future, I might need to tie the interface to a theme, because that allows proper focus on a usable application interface.

Check out some screenshots of how the current interface looks on my Flickr account. Next up is fixing some remaining bugs, as well as new bugs introduced with this navigation interface update and finally improving on the translation interface itself.

In my short free hours the last few days, I was brainstorming on new features for the translation template extractor (this little module which extracts translatable strings from Drupal modules) to make both the translators and Drupal coders life easier. Today I am proud to announce, that I released the old stable code as Potx-5.x-1.0 and Potx-6.x-1.0 (which signifies that the development code was quite stable for some time now) and wandered to implement new features for the 2.0 versions of the modules. From today, the 6.x-2.0-dev branch contains the two new features I developed the last few days:

• The module now extracts translation templates for themes too, not only modules. This was an obvious feature request, but the original implementation was quite shortsighted, so the relevant part needed a full code rethink to support themes. This is good for translators.
• The bigger news for module and theme developers is that potx now comes with (experimental) coder module integration. For those who have not heard about coder module, this little piece of software helps you to upgrade modules and ensure they conform to coding guidelines. It even helps you avoid some common security problems. But until now, it did not help you review your translatability errors. In fact, I got bug reports on the translation template extractor that if a module passed coder's review, it should not have any localization errors. Well, when used together with potx-6.x-2-dev, coder module now offers a new code review option. You can check translatability errors of your modules right there!

How can we make this even better? Well, there are still some TODO items for potx module, which will be implemented later (and I am sure people would like to see a 5.x-2.0-dev backport of the new features), but obviously people will not be better if told they make mistakes, if we don't tell them what to do instead. So I sat down and carefully crafted the Drupal 6 translation cheat sheet for your consumption. This fine piece contains the PHP and JavaScript interface translation API functions as well as the functions used in the installer (such as .install files and install profiles). I also collected the three most common errors and provided two tools to help you ensure you do as best as you can. This cheat sheet also includes explanation of the different placeholder syntaxes used in t()-ed strings, which even I have not been able to get used to still.

I hope you will find the new features and the cheat sheet useful, and take some extra time to ensure your modules are properly coded for interface translation, when you upgrade them for Drupal 6. Remember, we are going to have a "multilingual release" with all the new language features, so it becomes increasingly important that contributed modules use the interface translation API properly.

Update: Replaced the file with the 1.1 version, as I noticed that the !html placeholder needs a security warning to ensure people are aware that usage of this placeholder is not advised.

Happy hacking!

Our localization tools and approach help us a lot in making the Drupal interface better, but we did not make use of these great features so far. I hope to involve you in making Drupal 6 even better with two simple ideas, which only require very simple tools, so anyone can contribute.

A few days ago, a simple idea came to me, to export all the Drupal interface texts as one big text file and get people spell check and correct things in it, in the hopes that we can turn the fixes into patches. While there are tools for spell-checking Gettext files (the format we use for translations), admittedly, spell checking a simple text file can be easily done in most office suites, simple command line programs, and the fixes are easy to integrate into Drupal. Thankfully a few guys jumped on the idea, and the first batch of trivial typo fixes are now in Drupal 6, leaving space for debates on spelling and wording of some remaining parts.

The logical next step is to improve the wording of Drupal interface elements. Sometimes a shorter explanation would do better, because it would actually be more welcoming for readers, and at the same time in some places, the existing explanations leave some to be desired. We can much more easily spot these problem areas, when browsing around, so if we would have a tool to "touch up" interface text while browsing around, it would help our work. It turns out that what helps people localize sites, is also a time saver here. See how Localization client is useful for improving the English interface itself:

• Install Drupal 6 normally, in English.
• Enable locale module, add your custom English language. Go to Administer - Site configuration - Languages - Add language - Custom language. Add "en-my" with "My English" as native and English name. Provide "en-my" as path prefix. Back on the language listing page, choose this language as your default.
• Download Localization client for Drupal 6 and enable as usual.
• Now for every user with proper permission (including user 1), a tool will appear on the bottom of the page. This allows you to modify any text displayed on the page, effectively fixing the interface for yourself.

Of course the fun does not stop in making all these yourself. To save you time and effort when you update your site later and some string might get modified to serve users better, it is best to share results with the community. You can easily export "My English" on the Locale module export page: Administer - Site building - Translate interface - Export. From here, you get a Gettext PO file with all empty translations and the touch up you provided.

Now everything is left before submitting this in the Drupal issue queue, is to focus this file on the actual fixes. Using the command line msgattrib helper enables you to do just that: msgattrib "en-my.po" --translated > "Drupal-fixes.po". Unfortunately this part is not as easy as clicking around (for people without gettext tools on their machines), but let me ensure you if this is the only part stopping you from submitting considerable fixes for Drupal 6, let me know and I'll help you out or get someone to help you.

Of course because all the above is pretty much automatable and could even live on a central server, an enterprising folk could easily go and set up a temporary site for interface touch-up collaboration. At the end, the result of the group effort can be submitted. Although these suggestions will be made into patches at some point, this is again a good way to help out without knowing anything about writing Drupal patches.

As a maintainer of Drupal's locale module I try to find creative ways to help people localize their sites. Our focus in Drupal 6 was on more features for content translation and interface translation imports, while the built-in locale interface was nearly untouched. We even complicated it a bit with the textgroups feature which might or might not get used by contributed modules at the end.

In a previous post, I announced the new localization client module which strives to solve some of the problems with the built-in locale module translation interface by bringing an AJAX powered widget close to the site translator. While this module is a very good looking way to solve the translation problem, it has two weaknesses:

• You can only translate what you see on the site pages you browse by. Some text is only shown in emergency, when form values are not filled properly, when some backend data is not accessible, etc. Some text is even restricted to different user groups. So you can only translate the most visible parts of your site.
• Closely connected, but slightly different issue is that you cannot translate strings with plural versions at once. If your page shows 3 years ago, you can translate @count years ago but not 1 year ago (the singular form) or @count[2] years ago and friends, which are used when the language in use has more then two plural forms. The Drupal database gives no clue in relating these for translation, so we cannot help users intending to translate all these at once.

Although locale module provides a more complete solution, allowing you to have a translation percentage overview as well as filter untranslated strings and work on them, you are still restricted to the same old, hard to use interface. If you'd like to improve on the interface issue, you can switch to use potx module to extract Gettext translation templates from your modules, then use some desktop Gettext editor which suits your taste and then import the translation back to your site. For most people though, the "favorite Gettext PO editor" question is like asking about the best time to go to the dentist. If we can do better, then why not?