Enterprise Drupal
website development
in Washington, D.C.

Drupal is chosen for multilingual work more often than for anything else, and the projects still run over. The reason is usually that everybody said multilingual and meant four different things.

The first is the interface. Buttons, labels, error messages, date formats. Most of that already exists in the community translations, and it is the cheapest part.

The second is content. Pages, articles and records translated into each language, each with its own address, and linked to one another as versions of the same thing. This is what people picture when they say the word.

The third is configuration, and it is the one that gets forgotten. Menu labels, content type names, field descriptions, taxonomy terms, view titles, the text on a form. None of that is content and none of it is interface. Without translating it, a site can have perfect articles and a navigation menu in the wrong language.

The fourth is which parts differ rather than translate. A price list, a contact address, a regulatory notice, an entire section that exists in one language and not another. That is a structural decision, and it has to be made before the fields are designed.

Then the question of how a language is detected and switched. A path prefix is the usual answer and the clearest one.

Fallback rules need deciding explicitly. When a page has no translation, the reader either sees the original, sees nothing, or is sent somewhere else. Each is defensible for a different kind of content, and silence produces the wrong one by accident.

Search has to be told what to do as well. Results mixing languages look broken, and results limited to one language can hide the document somebody needs.

The honest planning note is that the cost is not the same for the second and the sixth language. The structure is paid for once. What repeats is the content, and that repeats forever, which is why the useful question is who maintains each language after launch.