One catalogue, three languages, not three websites

A beauty academy in Warsaw runs a catalogue of a hundred and thirteen courses and forty-one instructors, and the whole thing has to exist in Polish, Ukrainian and Russian.

Every client I have had with this requirement assumed the difficulty was translation. It is not. Translation is a cost you can quote, schedule and finish. The difficulty is structural, it appears in month eight, and it is expensive.

The failure everybody builds first

The intuitive solution is to copy the site. Three languages, three sites, or three parallel page trees. Everybody understands it immediately, which is exactly why it gets built.

Then a price changes.

Somebody updates it in Polish. The Ukrainian page keeps the old price for four months, until a customer arrives quoting it. Somebody adds two new courses in Polish and Russian, and forgets Ukrainian, so the Ukrainian catalogue silently has fewer courses than the others. An instructor leaves. Their profile disappears from one language and stays on the other two, still taking enquiries.

Within a year you do not have one business in three languages. You have three businesses that increasingly disagree with each other, and no way to see the divergence, because nothing anywhere reports it. There is no error. Each page is individually valid. The system has no concept of “these three should match”.

The cost is not the drift itself. It is the trust: a customer who finds two different prices for the same course on the same company’s site now has a question about everything else on it.

What to model instead

The fix is to be precise about what actually varies by language, and it is much less than people assume.

A course has a price, a duration, an instructor, a category, a format — online or in person — and a schedule. None of those are language. A course costs the same number of złoty whichever language you read about it in.

What varies by language is the text: name, description, what you will learn, requirements.

So the model is one course record, holding the language-independent facts, with translated text attached to it. Change the price once and it is correct in three languages the same second, because there was only ever one price.

This is why “which plugin should I use” is the wrong first question. The plugin decision follows the content model. Get the model wrong and no plugin will save you; get it right and several plugins will do.

The questions that decide the build

Before any of this is implemented, four things need answering, and they are business questions rather than technical ones.

What happens when a translation is missing? There are only three honest options: hide the item in that language, show it in a fallback language, or show it partially translated. Each is defensible; the wrong one for your business is a real problem. A course you cannot enrol in should probably be hidden. A safety notice should probably fall back rather than vanish.

Do all languages have the same catalogue? Sometimes not, legitimately — a course may only run in one market. That is a real business rule and the system needs to express it deliberately, so that “missing” and “not offered here” are different states rather than the same accident.

Who maintains each language, and how do they know there is work? If the answer is “the office manager, when she remembers”, you have already built the drift back in. A useful system shows an editor exactly what is untranslated.

Does the URL structure suit the markets? Subdirectories per language are usually right for one business serving several languages. Separate domains suit genuinely separate market presences and cost more to run. This decision is very hard to reverse once search engines have indexed it.

The technical details that are always wrong

Three things I find broken on nearly every multilingual site I audit.

Missing or wrong hreflang. Each page should declare which language it is and where its equivalents live. Without it, search engines treat your translations as duplicates and pick one for everybody, and you find your Polish page ranking for Ukrainian searches. Note the distinction between language and locale: I worked on a site serving en-CA, en-US and uk-UA — that is two languages across three locales, and the site’s own copy had been calling it three languages for years.

Language chosen by IP address. Do not. A Ukrainian speaker in Poland gets Polish. Someone on a VPN gets whatever country the exit node is in. Detect from the browser’s language preference at most, offer a visible switcher always, and remember the choice. Never redirect silently — few things feel more broken than being unable to reach the page you were sent.

The switcher that dumps you on the home page. If a visitor is reading a course page and switches language, they must land on that course in the new language. Sending them to the home page means they now have to find the page again in a language they were already struggling with. This is a five-minute fix that almost nobody does.

The bit that is genuinely harder than it looks

Text length. German and Ukrainian run substantially longer than English for the same content; Polish is not far behind. A button designed for “Enrol” gets a word twice its width, and your navigation wraps onto two lines at exactly the screen size where it breaks the header.

The only reliable defence is to test the layout in the longest language early, not at the end. Design that only works in the shortest language is not multilingual design, it is monolingual design with translations bolted on.

Search deserves the same care. Ukrainian and Russian are heavily inflected — a course searched for in one grammatical case will not match a title written in another unless you handle it. Default database search will quietly return nothing and the visitor will conclude you do not offer the thing you offer.

The summary I give clients

You are not building three sites. You are building one system that speaks three languages.

Everything that is not language — price, duration, availability, category, relationships — lives once. Text lives in versions. The interface shows editors what is missing, and the rules for missing content are decided by you rather than discovered by a customer.

Get that right and adding a fourth language later is a translation project. Get it wrong and adding a fourth language means maintaining a fourth copy of a business that already contradicts itself in three.