Multilingual Websites for Cultural Organisations: What's Actually Needed

Cultural associations, language schools and cultural initiatives are almost never monolingual. A German-Serbian association in Hamburg, a language school with international participants, a cultural project applying for public funding while trying to reach a community: in every one of these cases, the people you want to reach don't share a single language.

The website has to reflect that. The only real question is how much of it is genuinely necessary — and who will carry the ongoing work.

Because that is where multilingual websites fail. Not on the technology. They fail because six months later one language version is current and the other still shows last year's events.

First, the uncomfortable question: which content really needs two languages?

The most common mistake is translating everything. That doubles the maintenance work permanently — for an organisation that is usually run by volunteers.

A split by audience works better:

Always in both languages: homepage, about, contact, registration forms, legal notice and privacy policy. These are the pages where people form their first impression — and they rarely change.

Usually in one language only: event reports, photo galleries, internal matters, minutes. This content addresses the existing community, which already speaks the language in question.

It depends: event announcements. A reading evening held in Serbian doesn't need a full German page — but it does need a short German paragraph with the date, the venue and the language of the event. Someone who doesn't speak the language still needs to understand what it is and whether they are welcome.

This split isn't a cost-cutting measure. It's the difference between a website that is still maintained in two years and one that gets abandoned.

Three technical routes, and when each fits

Route 1: Two language versions with a translation plugin

The standard approach in WordPress. Every page gets a linked translation, and a language switcher moves between them.

Fits: organisations with many pages, regular new content, and more than one person maintaining the site.

Worth knowing: translation plugins reach deep into WordPress. They slow the site down, complicate updates, and switching plugins later is laborious. For small websites, that overhead is often out of proportion.

Route 2: Manually maintained page pairs

Each page exists twice, at separate addresses — for example /events and /rs/events. A simple switcher in the menu connects them.

Fits: manageable websites of ten to twenty pages whose structure doesn't change constantly.

The advantage: no additional plugin, no dependency, full control over every single page. The two versions can even differ where the audiences need different information — which in practice is often the sensible choice.

The drawback: every new page requires remembering to create its counterpart. That's a question of discipline, not technology.

Route 3: Multilingual by design, from the start

On modern websites outside WordPress, multiple languages aren't an add-on but part of the structure: all text lives in separate language files, addresses begin with a language code, and content is created per language.

Fits: organisations planning for the long term, needing more than two languages, or intending to connect the website to registrations and member areas.

Worth knowing: more effort up front, and maintenance depends on a clear structure. In return, the site stays fast and maintainable.

Why automatic translation is rarely the answer

Adding a translation widget takes ten minutes. Tempting — and for cultural organisations, almost always the wrong call.

Legal texts must not be machine-translated. Your legal notice and privacy policy are binding. An automatic translation is not a valid version of either.

Cultural content loses exactly what matters. An event title, a book title, a literary excerpt — machine-translated, it reads clumsily at best. For an organisation whose entire reason for existing is language and culture, that is a credibility problem.

Search engines don't treat it as a separate language version. If you want to be found in Serbian, Turkish or Polish, you need real pages with real text.

Automatic translation can serve as a stopgap for reports and archive material. For anything that shapes the first impression, it can't.

What has to be technically right for this to work

Four things that are frequently missing:

Separate addresses per language. Not a switcher that swaps the text on the same page. Each language version needs its own URL — otherwise it can't be linked, shared or found.

Language markup in the source code. Search engines need to know which pages belong together and which language each is in. Without it, your own language versions compete with each other.

A language switcher that stays on the same page. Someone switching language on the events page wants the events page in the other language — not the homepage.

Language in forms and confirmations. Somebody who registers for a workshop in Serbian shouldn't receive the confirmation email in German. That's the moment it becomes clear whether multilingualism was meant seriously or only applied to the surface.

A typical scenario

A cultural association running regular events in two languages. The website has around fifteen pages. Registrations currently arrive by email, mixed across both languages, and one person transfers them into a spreadsheet by hand.

A sensible scope: core pages in both languages; event announcements with the full text in the language of the event and a short paragraph in the other. One registration form per language, both writing into the same central list and sending the confirmation in the language used to register. Reports and photos in one language only.

The result isn't a perfectly mirrored website. It's one that reaches two audiences and can still be maintained by a single person.

---

Planning a website in two or more languages? Send me a short note about who you want to reach and who will maintain the content afterwards. Those two answers determine the right solution — and I'll tell you honestly if the simpler route is the better one.