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.
Close to a yer ago, Drupal 5 was released with a basic installer which makes new site setups easier, but it was still just the beginning. The real power as we thought was in contributed install profiles which allow you to set up different site types with ease.
The new Drupal 6 we are preparing for release comes with a nicely themed installer, which has a site configuration form (check out the video!)and even more capabilities for an install profile to hook into and do cool things on install. But despite encouragement from different parties, and even a DrupalCon Barcelona session by Boris Mann on install profiles, where some people became enthusiastic about building core install profiles for Drupal 6, the base system does not show off the different possibilities still.
However, yesterday Dries Buytaert posted an interesting note to the development mailing list, saying:
I don't mind having two or three profiles ship with Drupal core. They could help market install profiles and gives people one or two concrete examples to start from when building their own profiles. I think this would come a long way in helping to promote install profiles.
Specifically, I'm willing to accept a dummy.profile that populates your Drupal site with some dummy data and that gives you a kick start by pre-configuring a number of common things (i.e. it could create an about-page at q?=about, and it could setup a contact form that is accessible from the primary navigation). In fact, I wouldn't mind a blog.profile either -- it could also setup 'tags'-vocabulary with a term 'Drupal' or something.
If we think this is important, and if they emerge within the next day or two, we could ship those with Drupal 6. These are important usability/strategic improvements, not API changes.
We have seen some new functionality developed for Drupal 6 in tight collaboration quickly, and fortunately, there are existing code bases to build on for a single user blog install profile (thanks to Matt Farina for the link) or a 'dummy' profile. Let's keep quickly moving on these and we will get good examples of cool Drupal use cases, as well as a lot more visibility for Drupal's install profile support.
Due to the Microsoft event, I had no time yet to blog about the very first Hungarian Drupal User Group event, which took place in Szeged late last week, and was actually organized by the Belgian living in Hungary: Kristof Van Tomme. He has a very good sense of selecting what makes a fun event. The meeting started off with a short presentation by Kristof about Drupal's main selling points, then continued with a discussion on collaboration possibilities, and ended up with some fine wine tasting at a different location.
One of the intesting takeaways from the event was that numerous people showed up from Temesvár, which is located in Romania 200 kilometers away (close enough so they said). Actually, Budapest (Hungary's capital) was equally far, however Hungarian developers mostly showed up only from around the city. So it turned out to be an "international" gathering of sorts, especially with Kristof translating wine introductions from Hungarian to English.
The day was topped off with a world music concert by the relatively new Fabula Rasa formation (beware, popup not required for proper site operation). They played great music and told unbelievable fantasy stories built around every song they have. We arrived a bit late, but they were also late starting so the few of us who kept being there from the group enjoyed the whole concert into the night.
Of course this great gathering started off some powers in Budapest for a meeting there, and organization is underway. We will see how it goes hopefully soon.
A few weeks ago, I received a surprise invite from the Hungarian Microsoft office to an event in Redmond, WA, which turned out to be due to my strong involvement with the Hungarian PHP community, but was also luckily connected to my Drupal 6 work. I was lucky to be able to set aside the required days for the so-called Web Development Technology Summit, which seemed to evolve around PHP people and Microsoft technologies. Interesting mix!
This was my first time in the US, and would be able to tell you fun stories for hours about how one gets a visa quickly, copes without a credit card (but with a debit card), with a phone not working in the US, with a plane coming 6 hours late, with fun border officers who were (really) a pleasure to discuss web development technologies with, without a hotel room booked, without a name card prepared at the event, with extreme stuff billed in the hotel, a plane leaving 24 hours late (overnighting on Northwest's expense) and finally with luggage missing (but received a day late) back home. So it was a very fun experience all around, especially looking how I was able to team up with people spontaneously to solve problems on airports, which helped me out in some cases.
But actually, I was more interested in what Microsoft is up to with inviting some interesting heads from the PHP community, including three well known Drupal developers, as well as Gallery, Facebook, CakePHP, PHP core developers, and so on.
A few days ago Károly Négyesi (known to most as chx) announced that he organizes a (virtual) cirtical issue queue cleanup event for the 3rd of November, in which people gathered on the #drupal IRC channel will focus on fixing bugs in the critical issue queue.
webchick, desbeers, dvessel, davidstrauss and myself will spend part or all of November 3 with one goal in mind: empty out the critical issue queue for Drupal 6. In case we reach this goal and we have more time, well, there are a number of noncritical bugs and an even bigger number of patches that need work. Come, join the fun on #drupal on irc.freenode.net [...]
A few hours ago, Raincity Studios also announced that they are organizing a (real life) event for the 31th of October, titled the Disguised Drupalist Debugging Day. The Raincity event involves snacks and lots of help even for people starting to get their feet wet in patch rolling.
At last but not least, people from the Netherlands organize their first DrupalJam event for the 16th of November, which additionally to hosting sessions also includes a translation sprint, which admittedly is not direct code getting into Drupal 6, but nonetheless a very good opportunity for people to test every corner of Drupal 6, while translating them, and at the same time using the localization tools heavily, giving them some boost.
Things seem to line up nicely, and seeing Drupal 6 getting more and more stable by the day is very gratifying. In related news, the Drupal 6 development version is so stable, Angie Byron (known to most as webchick) just started her blog site on this version.
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.
Some time ago, Szilveszter Farkas approached me to be one of the presenters of the Free Software Nights meetings, of which the first event happened to be yesterday. I was talking about the Drupal history, the community and business environment. But it also turned out early this week that I am going to help out with the Drupal security releases, which also happened to be yesterday evening (my local time).
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?
We organized Drupal Conference Hungary 2007 for this past weekend. After last fall's first local conference, this was our second big event in Hungary. The conference had more then 150 registrants, so we needed to close the registration in advance to let people have seats in the session room. Unfortunately this year we were not so close to the 90% show up percentage we had last year, so the room was not fully packed. However, this was the only negative point I was able to spot.
Whenever you spot an untranslated string on your Drupal site, you need to:
Remember the string or at least some unique identifier from the text.
In Drupal 6 go to Administration - Site building - Translate interface - Search tab; in Drupal 5 go to Administration - Site configuration - Localization - Manage strings tab.
Enter what you remembered in step 1 and hit submit.
Identify the string in the result list or if it is not found, go back to step 1 and find an actually unique part of the string to search for.
Hit Edit on the item in the result list if found.
A form with all languages are displayed, fill in the translations you want to provide.
Go back and check whether the translation was used properly.
This is quite time consuming and error prone. Of course a lot of people suggested that we should have a solution which gets closer to the user, but it was not implemented before. So here I am to tell you that there is a solution for you which just works and eliminates nearly all of the steps above.
Due to 
A few weeks ago, I received a surprise invite from the Hungarian Microsoft office to an event in Redmond, WA, which turned out to be due to my strong involvement with the Hungarian PHP community, but was also luckily connected to my Drupal 6 work. I was lucky to be able to set aside the required days for the so-called Web Development Technology Summit, which seemed to evolve around PHP people and Microsoft technologies. Interesting mix!
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.
