I implemented some touch ups to the design of the Drupal.hu site recently, and although Edit Illyés (one of the top contributors in our local community) noticed that something is not right in Internet Explorer 6, we did not have a chance to look into it for some time. So finally, this became my opportunity to grab and test IEs4OSX, the brother of IEs4Linux.
Part of my Dock with IE6
Thankfully, there are people, who agree that Internet Explorer testing should not require a full virtual machine running with all the Microsoft Windows operating system booted up, let alone a completely different machine with this OS installed. IEs4OSX allows users to use the Darwine (Wine for OSX) system to run Internet Explorer versions from 5.0 to 7.0. Although the 7.0 version is still admittedly in beta stage. It run fine for me on Ubuntu with IEs4Linux, but my Mac runs on high CPU loads with it, and no page load ever finishes.
After all, this fine project (and some CSS modifications) saved Drupal.hu from going with the broken layout for IE6 users through the holidays.
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!
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.