The video recordings of FrOSCon are available now.
Anyone interested, finds the BitTorrent links in the d.o handbook pages [1].
A streaming version of all twelfe videos is available on our website at erdfisch.de [2].

In cooperation with our freelancers Claudia Todt and Kai Thierfelder, who actually did all the hard work with filming and capturing, we managed to produce some nice videos. Thanks to them and all the other people involved, we had a great time heard many interesting things.

[1] http://drupal.org/node/172315
[2] http://froscon.erdfisch.de

Matt Westgate, co-author of Pro Drupal Development, is going to give us a lesson on Theming! The lesson will start with an existing HTML/CSS theme and carry us through basic "Drupalizing" to get us about 80% of the way there. Then we'll look at how to leverage template.php and Drupal's PHPTemplate system to take us the rest of the way to a fully customized theme. Chapter 8 of Pro Drupal Development on The Theme System is available online for free so everyone can see how concepts from the book are applied to a real world example. Should be an awesome lesson from a great teacher so make sure you mark the date.

http://drupaldojo.com/lesson/28

I'm part of a tech startup who is basing our website off of Drupal 5.

We have a small team of developers who work on building the site simultaneously. We use subversion for code management. In previous (non drupal) environments , working together was easy: all the functionality, content, roles, etc were hard coded right into our code and template files.

Planning for DrupalCamp is well under way! Venue, Sponsors, and Speakers - we're ready to rock and roll .

If you're interested in attending, speaking (we do still need more speakers), or sponsoring, contact me at cleverclevergirl at gmail.

Event Info

• Date: September 8-9, 2007
• Location: AOL Beverly Hills campus

331 N. Maple Dr.
Los Angeles, California 90210
Yahoo Map
Google Map

We will need everyone's REAL NAMES in order to let them into the event. Please send an email to drupalcampla@gmail.com with your real name and your meal preference (omnivore, vegetarian, vegan) ASAP or we may not be able to let you in.

Official registration for counting purposes is at http://upcoming.yahoo.com/event/221082

Read on for more info:

What needs to be an install profile?
Please comment with your ideas!

After over 1.5 years of development (since 29/11, 2005), plus number of developers contribution, and help of Drupal 6.x schema API, a new Oracle driver for Drupal 6.x is now ready for testing.

The latest version of Oracle driver overcome a lot of Oracle-specific limitation, and able to work well as like as existing Drupal database driver, e.g. MySQL and PgSQL.

DrupalCampNYC3 is over and everything has finally been wrapped up. The camp was a big success bringing over 130 people together for one full day of Drupal Goodness and a second day of developer hacking. As usual the crowd consisted of people from all walks of life from the complete new-to-drupal person to the advanced Drupal hacker. It was a great time. Thanks to everyone that attended!

I'm glad to announce development of a buddylist 2.x module. Our team needs buddylist's functionality for a project, but decided that buddylist's (1.x) quality is too bad for use in our project and that the effort to fix it wouldn't be worth the trouble. So we'll build buddylist 2.x..

Buddylist 2.x design decisions:

• use views (for now with usernode..) for all buddy listing, so they are
  extensible and customizable
• use workflow-ng for all notifications, which provides e-mail notifications - or whatever you want (just write the appropriate action..)
• to simplify only the buddylist modus with "Confirmed buddies" will be
  supported - no one-way buddy connections
• only implement the basics in the module, other things should be built as add-ons.
  So there will be no buddy-group functionality, or tracker integration (for
  this views can be used nevertheless).
• we have also planned to develop an extension, which shows the shortest
  buddy connection to other people later
• Probably there will be no need for changing the db-scheme. So
  upgrading would be just a matter of replacing the module.

So in short the pros/cons of this design will be:
+ small, stable, performant module
+ good code reusing
- a lot of dependencies (views, usernode, worfklow-ng for notifications)

development will be done by nodestroy

Dear Drupal interface translators!

Your valuable work helps Drupal to actual world domination, so we try to support you all ways possible to be able to more efficiently organize your time to translate Drupal projects (the Drupal core system itself, as well as contributed modules, themes and install profiles). Currently your work involves lots of manual steps and several "esoteric" tools:

• You either find translation templates for the actual release of the project or not. Even where templates are available, they are not always updated to the actual software release you are working with. So most of the time you need to go and generate templates yourself (previously with extractor.php, these days with potx module).
• You need to use a Gettext Portable Object editor of your choice (could be a simple text editor or a specialized tool). If you work with a contributed project, you possibly need to use msgmerge, and other command line gettext tools to merge files, prefill previously done translations, etc.
• You need to translate text already translated in other modules, and/or in Drupal core itself, unless you also merge with core translations as part of your workflow.
• Once ready, you need to get your file committed to CVS, which requires a CVS account and a good amount of branch/tagging knowledge, so you put your file to the place it belongs.
• But for already released projects, you cannot push your updated translation which were not ready in time, the translations are not coordinated.
• And on top of all this, users of modules need to manually upload PO files even if they uploaded them with the module, and obviously expected them to be imported with the install process.

Only local images are allowed.The original thinking behind the localization server project at large is to simplify Drupal project translation tasks for people. So creating an intuitive interface is important. Among some backend changes (like storing string extraction errors per release, so we can funnel them back to developers to fix), I took most of the recent days with simplifying the UI of the server, and coming up with more user guidance where possible.

The result is a brand new home screen, which provides an overview of what this server is all about, what are the steps required to contribute and gives important pointers to the lesser known global translator communities. I also took considerable amount of time collecting a list of languages, which will be used to launch the site. I took the contributions CVS HEAD of the translations folder, and did count 58 languages, to which more-or-less Drupal core is translated. There could be more languages in contributed module translations, but it is not likely. I also needed to collect the plural formulas for these languages, which was not easy in all the cases (more below). The result is a realistic overview of languages, of which my second screenshot only shows a small amount.