Drupal 6 and the Multilingual Problem Nobody Budgets For

Drupal 6.0 shipped February 13, and the release notes lead with the crowd-pleasers. A friendlier installer. Drag-and-drop menus. Simple automation with actions and triggers. Faster page loads. All welcome.

But the feature that matters most for institutional sites is the one that reads driest in the announcement: a rebuilt language system. Language detection, content translation, and interface translation are now built in. For anyone serving audiences in more than one language, that dry line is the release.

What faking it looks like

To appreciate the plumbing, look at what institutions do without it. The pattern arrives on our desk a few times a year. An organization needed a Spanish or French version. The CMS had no real concept of language, so someone cloned the site. A full copy, translated once, launched proudly.

Within months the copies drift. The English site gets the new program pages, the updated policies, the redesigned navigation. The Spanish site gets whatever someone remembers to port, which rounds to nothing. No workflow connects an edit to its translations. No report shows what is out of sync. Nobody owns the drift.

Two years on, the translated site is an archaeology exhibit wearing the institution’s name. It is actively worse than absent, because visitors cannot tell which content is current and which is fossil.

The failure was never translation quality. It was architecture: treating languages as separate sites rather than as versions of one site. That is precisely the distinction Drupal 6 now encodes in core.

What the new language system provides

• Language as a property, not a copy. Content carries a language, and translations are linked versions of the same node. The system knows the English and Spanish program pages are siblings. That is the foundation everything else builds on: sync reports, navigation, workflow.

• Detection and switching. Visitors can be routed by browser language, URL prefix, or their own choice. Path structures like /es/ and /fr/ stay clean and search-friendly. The mechanics we used to assemble from contributed modules and hope are now settings.

• Interface translation in core. The buttons, labels, and messages around the content translate through core’s locale system. That is the part teams forget until launch week. Community translation packs cover dozens of languages, and you can override them where your own vocabulary demands.

• The i18n ecosystem on firmer ground. The contributed modules that handle the advanced cases now build on stable core foundations instead of making up for their absence. Translated menus, taxonomy, and blocks all benefit. The stack gets shorter and sturdier at once.

What no software provides

Now the candor section. Platform capability is where multilingual projects start, not where they succeed. The questions that actually decide outcomes are organizational, and they belong in your planning documents before any setup begins.

Which content localizes? Rarely everything. The honest answer is usually a core of high-value pages per audience, maintained well, over a full mirror maintained badly.

What happens when the English page changes? Someone must be told. Someone must translate. Someone must approve. Name them, or the drift begins on day one with better tools.

Who owns each language? A language without an owner is a clone with extra steps. And what is the year-two budget? Translation is an operating cost, not a launch cost. Institutions that budget it as a one-time line item have pre-purchased the archaeology exhibit.

We have started writing these answers into project charters for multilingual work, above the technical architecture. In our experience the charter predicts success better than the module list.

The rest of the release, for the builders

Multilingual is our headline, but three other items deserve the builder’s note. Menu administration goes drag-and-drop, which sounds trivial until you have reordered a forty-item institutional menu through the old interface. That was a form of penance.

The new actions-and-triggers system handles light automation in core. Notify this editor when that content type is submitted. Unpublish on a date. Modest machinery that trims a plugin dependency or two.

And core now includes update-status checking. The dashboard reports when core or contributed modules have new releases, including security releases. As we argued when WordPress shipped the same thing, ‘we didn’t know’ was the leading cause of unpatched sites. The software itself has now retired that excuse.

Performance also moves. Menus and path lookups are cached more aggressively, and page loads measure quicker out of the box. The standing configuration advice from our Drupal 5 coverage still applies on top: page caching on for anonymous visitors, CSS aggregation enabled. But the baseline you are configuring from is better.

Who should be paying attention

The audiences for whom this release moves the platform conversation. Universities recruiting internationally, where students and their families increasingly expect materials in their language and judge the school by them. Manufacturers with regional markets, whose product and support content drives real revenue in each region. And nonprofits and health organizations serving multilingual communities at home, where language access is mission and, increasingly, obligation.

For all three, ‘one platform, many languages’ has just become an affordable architecture rather than an enterprise line item. The vendors selling six-figure licenses on multilingual capability should expect harder questions this year.

Upgrade notes and a closing position

Briefly, for current Drupal sites: 5-to-6 is a real upgrade project on the pattern we described last year. Take a module-readiness inventory first. Contributed modules will need months to fully catch up, so sites without urgent needs can let the early adopters find the sharp edges. Sites on 4.7, now two majors behind, should hear the firmer version: the path lengthens with every release you skip.

The position worth closing on: multilingual is an operating commitment, not just a technical feature, and this release makes the technical part affordable. Pair Drupal 6’s plumbing with honest workflow answers and you will ship international sites that stay true over years. Adopt the plumbing and skip the answers, and you will produce better-built drift. The software just stopped being the excuse, which was, all along, the most useful thing software could do.

A last practical note for anyone starting the multilingual conversation internally. Begin with an audience inventory, not a language list. Which markets and communities do you actually serve, in what numbers, seeking what content? The answer usually surprises. The languages leadership assumes matter and the languages the data supports are rarely the same list. Serve the audiences you can name. The rest is configuration.