Multilingual Websites: Getting DE, TR and EN Right

A website in three languages is not a translation project. It is a decision about how much editorial work a company can carry over the long run. What follows is what matters for a Berlin business serving customers who speak German, Turkish and English, from the shape of the addresses to the details that almost every project forgets.

The editorial question comes before the technology

Before anyone talks about domains, plugins or language codes, one uncomfortable question needs an answer. Who writes the copy in each language, who replies to the enquiries those pages produce, and how many hours a month are available for it?

We regularly see sites whose German pages are current, whose Turkish version still shows prices from two years ago, and whose English version introduces a team that no longer exists in that form. The most expensive mistake in a multilingual project is rarely technical. It is a language version that goes stale after six months, keeps being found, and creates expectations nobody can meet.

A rough figure from our own projects: each additional language costs roughly a third of the editorial effort of the source language, permanently. Not a third once, but in every month something changes. That workload spreads across:

• Service and pricing pages
• Team, location and contact details
• Case studies and blog posts, if they are maintained in more than one language
• Legal texts, after every amendment
• Email templates, proposal blocks and auto-responders

If that effort cannot be planned for, two well-maintained languages produce a better result than three mediocre ones.

Two current language versions look more professional than three where one is visibly falling behind.

URL structure: subdirectory, subdomain or country domain

For a company based in Berlin serving three language groups in the same city, the subdirectory is almost always right. The audience is not Turkey, it is Turkish-speaking customers in Germany. A country domain would send a signal that does not match the actual market, and it would start building its standing from zero.

One detail that gets overlooked: the source language belongs under a prefix too. If German pages sit at the root and the others under /tr/ and /en/, special cases pile up in routing, sitemaps and the language switcher. Three equal prefixes are cleaner. The root either redirects to the default language or evaluates the browser language exactly once, always leaving a visible switcher rather than forcing a redirect.

Translated URLs, not German paths under English text

If you translate the content, translate the address: /en/services rather than /en/leistungen, /tr/hizmetler rather than /tr/leistungen. URLs are read, shared and dictated over the phone. A German path under English copy makes the page look half-finished and wastes the keyword in the path.

The practical consequences:

• A slug map. One central record of which page uses which path in which language. Without it, the language switcher drops people on the homepage instead of the matching translation.
• Internal links. Build them from page identifiers, not hard-coded paths, or a single click will quietly change language.
• Redirects. A slug is a promise. When it changes, it needs a permanent 301, per language.
• Turkish characters. Slugs without ı, ş, ğ, ç, ö and ü avoid encoding trouble when addresses are copied or pasted into email. Transliterate consistently and write the rule down.

What hreflang does and does not do

hreflang tells search engines that several versions of the same content exist and which language each one serves. It is a hint for picking the right version, not a ranking factor. A weak Turkish page does not rise because of it; it is simply offered to the right audience.

Four rules cover the normal case:

1. Reciprocity. Every version points to all the others and to itself.
2. Canonical addresses. Always point at absolute, indexable URLs, never at redirects or pages marked noindex.
3. x-default. Mark one version as the fallback, usually the German page or a neutral language chooser.
4. Plain language codes. de, tr and en are enough. Regional codes such as de-AT only make sense when content genuinely differs for that region.

The mistakes we find most often in audits: a missing self-reference, tr-TR on a page aimed at people in Germany, references to non-canonical URLs, and contradictory declarations in the sitemap and in the page head. Teams that maintain both usually maintain neither correctly. One source is enough.

Translation is not word-for-word work

The noun-heavy German style that sounds serious in a service description turns clumsy in English and artificial in Turkish. English gets shorter and clearer with verbs. Turkish sentences, with the verb at the end, need headlines and straplines rewritten rather than carried across.

Forms of address differ as well. German stays with Sie, Turkish with the polite siz, while English has no such grammatical layer and creates politeness through word choice instead. Wordplay rarely survives the move and should be rethought per language.

Then come the forms, where most translations fall apart. A field labelled PLZ becomes posta kodu in Turkish and postal code in English, not ZIP, as long as the address is in Germany. A salutation dropdown offering Herr and Frau has no sensible Turkish equivalent and is better made optional or dropped. The phone field should default to +49 but accept +90. Validation messages need translating as much as captions and alt texts do, and those two usually stay German because they live in the media library rather than in the content.

The parts almost everyone forgets

• Email templates and auto-responders. Someone who writes in Turkish should not get a German confirmation.
• Legal texts. The German versions of the imprint, privacy policy and terms remain the authoritative ones. Translations are a service to the reader and should be labelled as such.
• 404 page, site search and cookie banner. All three typically run outside the normal editing system, which is exactly why they stay monolingual.
• PDF downloads. Price lists and data sheets are content, not attachments, and need an owner per language.
• The HTML lang attribute. Hyphenation, screen readers and automatic translation prompts depend on it, and it often fails to change when the language does.
• The language switcher. It should stay on the current page. Jumping to the homepage destroys context and is the fastest route to a bounce.

Keeping the maintenance load low

The difference between a multilingual site that stays current and one that decays is structural:

• Separate content from layout properly. What gets translated is text, not a page construction.
• One source of truth per text fragment. A phone number maintained in three places is wrong in two.
• Keep translations as structured files rather than copies of whole pages. Copies drift apart; files can be compared.
• Name one person responsible per language. Shared responsibility becomes no responsibility.
• Work through a short list before every release: new pages present in all languages, hreflang reciprocal, switcher correct on every new page, forms and error messages checked, email templates updated.

When a third language pays for itself

Three conditions should hold before a language is added. There is a real audience that cannot be reached otherwise. There is someone who can answer enquiries in that language, on the phone as well as in writing. And there is time to keep the content current.

If one of those is missing, the honest answer is to run a single language very well and publish one short, durable overview page in the second and third language covering services, address and how to get in touch. That is not a step back; it is a page that will still be accurate in two years.

If you are unsure which scope fits your team, we can look at your current site and tell you what is actually needed in each language. A short conversation is enough for a first assessment.