Drupal 6 supports translation of content with the core Content Translation module. So you can create a page in English, then translate the page to Dutch.

But what if you attach a file to the English page? It does not show up on your Dutch translation. And what if you are using CCK and FileField? That's the case that I want to cover in this article.

First, I installed Drupal 6.6, enabled the Locale module, and added the Dutch translation (for the proper way of installing translations, see Addison Berry's screencast, Installing Drupal with a Translation).

I installed CCK 6.x-2.1 and enabled the Content module and some others (Node Reference, Number, Text, Option Widgets).

I installed the 6.x3.x-dev snapshot of FileField (it's better to use an actual release but I saw some bug fixes going into the module and figured I'd test it). I enabled FileField module.

I enabled the core Content Translation module.

Then I installed i18n 6.x-1.0-BETA6, which is the latest release of the Internationalization Module. I enabled the Internationalization and Synchronize Translations modules.

I needed a CCK content type to test with so I created one:

Well I've done it! I've written my first jQuery plugin. The plugin creates rollover balloon-help style tooltips for any element on your page. While there were a few different tool tips plugins that existed for jQuery, none of them seemed to quite meet my need for a NetFlix (or Google Maps) style talk-balloon popup.

It quickly became apparent that in order to accomplish this type of flexible talk-balloon tooltips, I was going to need to engage the use the HTML 5 canvas element (and a lot of high-school algebra and trigonometry). The result is BeautyTips, a flexible and smart tooltip which calculates the best position for each tooltip bubble and then draws it. Bubbles can have rounded corners with a variable corner radius, "spike" length, color, opacity, and much more.

BeautyTips in action on DoItWithDrupal.com

The canvas element is supported in modern versions of Firefox, Safari, and Opera. However, Internet Explorer needs a separate library called ExplorerCanvas included on the page in order to support canvas drawing functions. ExplorerCanvas was created by Google for use with Google Maps and several of their other web apps. Include it on the page according to the readme file and BeautyTips should work just fine in IE.

Beauty Tips was written to be simple to use and pretty. All of its options are documented at the bottom of the jquery.bt.js file and defaults can be overwritten globally for the entire page, or individually on each call.

A lot of energy in the Drupal world goes towards solving complex problems: giving administrators ways to build publishing workflows without writing code, integrating with cool new APIs, automatically translating site content into Klingon... You know. The usual.

With all of that energy focused on complex architectural problems, it's easy to lose sight of the simple solutions that Drupal provides for really common "classic" web problems. This really hit home the other week as I sifted through an old Zip disk with archives of sites I'd built for clients in the heady days of the late 90s. One by one, I started ticking off requests my clients had made that today's site-builders can solve in minutes with Drupal modules -- no wacky configuration, no complicated recipes. Just a simple, "Yes!" when a client says, "Can you...?"

In presentations I usually point out that Drupal is three things:

1. A content management system: The forms you fill out, the buttons you click, and the content you work with. The stuff you interact with every day while you manage your site.
2. A content management framework: The low-level APIs that let you extend and modify Drupal to make it do everything from ratings to image galleries to your dishes.
3. A community: The thousands of documentation writers, developers, testers, support providers, designers, and evangelists from all over the world, working together to make Drupal a better platform every single day.

It's this third point I'd like to talk a little more about today, by providing some insights into the general Drupal community philosophies that guide our interactions with one another, and as a result, the growth and direction of the Drupal project as a whole.

The Drupal community has several core philosophies, some of which are documented, others of which you just kind of pick up from spending enough time watching various interactions on the forums, on issue queues, and on the mailing lists. Here's a brief guide, for the uninitiated.

I recently evaluated ExpressionEngine for viability as a CMS replacement for Drupal. ExpressionEngine (EE) is a commercial CMS tool built on PHP and mySQL by EllisLab. A client of ours was attracted to its clean interface, built-in features, and expandability.

I was impressed by the well-designed UI and the flexibility of EE's templating engine. There are definitely lessons the Drupal community can learn from their attention to detail. In fact, as I explored the EE support forums, I discovered a great deal of antagonism towards Drupal -- to my surprise, it wasn't based on features or learning curve, but on the idea that Drupal is insecure.

In the forums, comments such as this were common whenever Drupal or other CMS systems were brought up for comparison:

Some reasons why one might not want to use Drupal?

[2/5] Drupal Acidfree Module “node titles” SQL Injection Vulnerability
[2/5] Drupal Unspecified Spoofing Weakness and Cross-Site Scripting
[2/5] Drupal Project Issue Tracking Module Multiple Vulnerabilities
[2/5] Drupal Project Module Script Insertion Vulnerability
[4/5] Drupal Comment Preview Arbitrary Code Execution