Drupal related posts by Gábor Hojtsy.
As Tiffany published in the drupal.org post titled Drupal.org redesign officially underway in September, Mark Boulton design's activity with the drupal.org redesign is tied to a timeline, and will end in one week as originally planned. Whether this deadline is actually met or not, the fifth iteration of the prototype was posted on the groups.drupal.org group related to the redesign a few days ago.
For those better in the know then I am, Fluid.app might be quite old news. I however just got on the bandwagon recently, and I thoroughly enjoy it. Fluid is a Mac OS X application, which acknowledges the fact that we are not using "the browser" anymore, but we are working on our days jobs, using our private email, posting photos, chatting with friends, etc. And these are all distinct activities or tasks we do. So we would be more comfortable looking for our "photo app", "chat app", "email app" or even "work app", but most of our interactions are now done on the web, so all these are tucked under the "browser app".
Packt Publishing is at it again. They've published David Mercer's follow up to Drupal: Creating Blogs, Forums, Portals, and Community Websites, which was originally based on Drupal 4.7. The new book subtitled Build your own professional blog, forum, portal or community website with Drupal 6 tries to cater to the same audience but with greatly updated content.
David seems to be completely up to date on the Drupal 6 matters, as much as the March 2008 publication time allowed. This was one of the first Drupal 6 books on the market, and the author even managed to include a lengthy section on CCK. Hats off. Now that Views 2.0 is out for Drupal 6, many more people will consider using this new version as a base to start with. David caters to new users, not upgraders though, so this guide helps you get up to speed (and the Views covering books are still awaited on the market).
The book has a certain eye to detail in talking about things like setting up users and permissions. David even goes to note that setting up access rules for names or emails does not affect existing users. This practice was changed in recent Drupal versions, considering this a security bug instead of the way how Drupal works, and honestly, I don't think people expected to see this behavior noted in print. This attention to detail goes to extremes however in the examination of taxonomy. To my tastes, it would have been better to get down to more practical examples sooner instead of trying to organize the section around the theories of taxonomy. Same applies to coverage of HTML, where David tries to teach content producers certain HTML tags to write a feature-rich webpage. This might be a good idea for the theming section, but not where content is produced by end users.
All-in-all, I think this book is a good starter guide for Drupal 6 users, even if sometimes too detailed. You'll certainly need to be ready to learning a lot more from Views to CCK field modules while you actually build a more complex site, but starting off with a simpler website should be possible from the topics covered.
This story started almost a year ago, when I published my cheat sheet for the Drupal 6 localization API. Although Drupal 6 was not ready at that time, the localization API was as stable that the cheat sheet is useful without modification even today.
My intention with the cheat sheet was to start a localization API guide on Drupal.org and get the intricate details of this API documented for the general good. Over the past few weeks, i've managed to have time to actually sit down and document best practices and tips for these functions, and published the Localization API guide as part of the Drupal.org developer handbook (it is worth to check out the printer friendly version for a quick glance). While some parts of the guide are still under discussion and finalization (and I still plan two pages: one on emails and the other one on pointers for people looking to translate user provided data), the guide is pretty much complete as far as localizing the interface goes.
Another side of that old blog post of mine was new Translation template extractor support for the coder module. Well, that was basically tapping the existing errors into coder and make you figure out the rest. The existing error messages in extractor were however quite cryptic, like Invalid marker: t($joe). This is not really helpful in finding out what is the issue at hand, when you are not familiar with the finer details. This was unhelpful for both module authors and code reviewers, who were eager to fix these problems. I got several support requests in the extractor issue queue to clarify guidelines. So updating the error messages was clearly in order.
The result of these two efforts is that the latest development version of the extractor on the 6.x-2.x branch (update from CVS or wait for today's tarball to materialize) now supports nicely understandable error messages for coder module (and way better error messages for its standalone mode just as well) with links to the actual documentation explaining the underlying causes and details. This will hopefully end up in a new release very soon.
So do you have any excuses left to not write nicely translatable Drupal module interfaces?