Running One Site in Two Languages Without Losing Either

Translation Is the Smallest Part

Most companies approach a second language as a translation project: export the copy, get it translated, put it back. The translation is the easy part and usually goes fine. What goes wrong is everything around it — the structure, the workflow, and the eighteen months afterwards during which one language quietly stops being maintained.

Plan for the maintenance, not the launch. Every page you publish from now on exists twice, and every change you make has to happen twice or the two versions start to disagree.

Decide the Source of Truth

One language has to be authoritative, and the choice should be deliberate rather than accidental. It is usually the language your team thinks in, because that is where new content will naturally originate and where nuance will be strongest.

Write it down and enforce it. Without a source of truth you get pages that were written in Turkish, translated into English, then edited in English only — and now neither version says the same thing and nobody can tell which is correct.

Localise, Rewrite, or Leave Out

Not everything deserves the same treatment. Legal text and product specifications must be translated accurately. Marketing copy usually needs localisation — the same argument made in language that lands in that market. And some content should simply not exist in one of the languages: a case study for a market you do not serve, or a campaign page for a promotion that does not run there.

Making that decision explicitly, page by page, prevents the most common outcome, which is a second language full of literal translations of content that was never relevant to that audience.

Structure and URLs Stay Parallel

Keep the two versions structurally identical: the same pages, in the same hierarchy, with predictable URL patterns. When a visitor switches language they should land on the equivalent page, not on the homepage, and when they do not, they should be told why rather than silently redirected.

The technical signals that connect the two versions matter for search, and they are also easy to get subtly wrong — the reciprocal declarations, the language codes, the handling of a page that exists in only one language. Our guide to international SEO covers the implementation in detail.

Let the CMS Model It

If your system treats a translation as a first-class version of the same item, the relationship is maintained for you and you can see at a glance what is missing. If it treats it as a separate page, the connection lives in someone’s memory and will not survive a staffing change. This is one of the questions worth asking before you choose a platform, as we set out in our guide to choosing a CMS.

The Workflow That Stops the Drift

Drift is the real failure mode. Six months after launch, the source language has eleven new pages and four updated ones, and the second language has none of them. Nobody decided this; it happened because publishing in the source language felt finished.

Make the translation part of the definition of done. A page is not published until both versions are, or until someone has explicitly decided the second version is not needed. That single rule prevents almost all of the divergence teams spend years cleaning up afterwards.

Track What Is Missing

You need a view that shows which pages exist in one language and not the other, and which translations are older than their source. Without it the gap is invisible until a customer finds it. Review that list monthly alongside the rest of your publishing work, in the same way the routine in our guide to content operations catches everything else.

Words That Must Not Be Translated

Every organisation has terms that should survive intact: the brand name, product names, and any established technical vocabulary your market uses in English. Nothing undermines credibility faster than a brand name that has been helpfully translated by someone following instructions literally.

Keep a short glossary alongside the brief — terms to keep, terms to translate a specific way, and terms to avoid — and give it to every translator and every automated tool you use. It takes an afternoon to write and prevents the same correction being made forever.

Where Machine Translation Fits

Machine translation is now good enough to be a useful first draft and still not good enough to publish unreviewed. Its failures are specific: it flattens tone, it is confidently wrong about domain vocabulary, and it produces text that is fluent enough that a reviewer skims instead of reading.

Use it where the cost of being slightly off is low and the volume is high, and never for legal text, regulated claims, or the pages that carry your positioning. And publish nothing that a competent human has not read end to end in context, because errors that survive review tend to survive forever.

Review by Someone Who Sells There

Linguistic accuracy is not the same as commercial accuracy. A translation can be grammatically perfect and still be too formal, too casual, or wrong about how a claim is normally phrased in that market. Machine output has the same problem in a more consistent form.

Have a final pass from someone who actually speaks to customers in that language — ideally in sales or support. They will catch the phrasing that is technically correct and commercially odd, which is exactly the thing readers notice and cannot articulate.

Design Has to Survive Both

Turkish text usually runs longer than English and uses longer individual words, so a layout tuned to English headlines will wrap awkwardly or overflow. Components need to tolerate the longest language rather than the shortest, and the review has to happen at real breakpoints in both languages.

Fonts matter too: verify that the typeface handles the full character set properly and that the diacritics are drawn rather than assembled. The details are covered in our guide to web typography, and they are the difference between a site that reads as local and one that reads as translated.

Do Not Guess What Language Someone Wants

Automatically redirecting visitors by location is one of the most reliable ways to annoy people. Someone in Turkey may want the English page, and someone abroad may want the Turkish one. Detecting a preference and offering to switch is helpful; forcing it and overriding a deliberate choice is not.

Make the switcher visible on every page, label each language in its own name rather than with a flag, and remember the choice so nobody has to make it twice. Flags represent countries rather than languages, and getting that wrong is a small signal that you did not think about this audience carefully.

Be Honest About the Ongoing Cost

Two languages roughly doubles the marginal cost of every future page, and that cost never goes away. Some organisations decide, correctly, that one excellent language serves them better than two mediocre ones, and that is a legitimate answer rather than a retreat.

If you commit, commit to the maintenance and not just the launch. If you want the structure, workflow and review process designed together rather than bolted on afterwards, our content team builds the localisation model into the content strategy from the start.