Multilingual content management.

Multilingual content management governs how, when a page is updated, its counterparts in the other languages learn of it and are kept current.

Opening a site in three languages is a project; keeping it current in three languages is a habit. The first done without the second begins to drift apart within a few months: the Turkish page is updated, the German page stays as it was, and nobody notices.

The cost of the drift is not just inconsistency. A stale translation spreads wrong information in that market — an old price, a discontinued service, a changed process. And the user in that market stops trusting the rest of the site too.

Source language and derived languages

What working setups share is designating a source language: the content is written first in that language, the others derive from it. That clarifies which text is the original and keeps the translation flow one-way.

The alternative — every language written independently — gives better results in theory but cannot be sustained in practice: three independent content streams mean three times the editorial capacity.

On this site the source language is Turkish and the derivatives come from it. Which text is derived is marked in the files with a note, and the translated ones await the owner’s approval.

What about the missing translation

This is the most critical design decision: if a page is not yet translated, what is shown in that language? There are three approaches, and they give very different results.

1. The page is never generated — no page for that language, it does not enter the hreflang set. The most honest.
2. Shown in the source language — the page exists but the content is in another language. Confusing for the user.
3. Filled with machine translation — the page exists, the quality unreviewed. Risky.
4. A placeholder is shown — “this page is not yet translated”. Honest but empty.
5. Mixed — some pages translated, some not, and the set never declares the missing languages.

On this site the first approach is applied and protected by code: when a language has no content, no page is generated for that language and it does not enter the hreflang set. A missing field is not rendered — absence is preferred over invented text.

The rule is harsh but gives a consistent result: every published page is really in that language and really current. A half-translation cannot exist as a state.

A missing field is not rendered — absence is preferred over invented text.

The maintenance routine

The only way to prevent drift is making sure the others learn when the source language changes. There are a few ways to build that, and what they share is being automatic.

1. A version stamp — every translation records which source version it derives from.
2. A staleness warning — when the source changes, the derivatives are marked “awaiting update”.
3. An approval gate — translated but unverified text does not go live, or goes live marked.
4. An audit report — which pages are missing or stale in which languages must be listable.
5. A single source — the strings must live in one place; text embedded in the template doubles the translation load.

The last item is the most structural: when text is embedded in the template, the template is duplicated per language and one correction must be made in three places. When the strings live in a separate dictionary, the template is one and the text many.

On this site all the interface strings are in separate dictionary files and the templates are language-independent. A label’s counterparts in three languages stand side by side — what is missing is immediately visible.

Where the strings should live

On a multilingual site, where the text is held directly determines the maintenance cost. There are three common approaches, and the difference between them compounds over time.

1. Embedded in the template — the template is duplicated per language. One correction is made in three places. The worst.
2. A separate file per language — one template, many texts. A missing key is invisible.
3. One file with a field per language — three languages side by side per key. What is missing is IMMEDIATELY visible.
4. An external translation system — for large teams; too much overhead on small projects.

The third approach’s advantage is auditability: when a label’s counterparts in three languages stand side by side, what is missing is seen at a glance. In separate files a missing key is noticed only while the page renders — or never.

On this site the third approach is used: the interface strings are in one file, three languages under each key. And there is a contract — if a key does not exist in a language, that field is NOT RENDERED. No empty label and no source-language text appears; the field simply never comes out.

The rule looks harsh at first glance, but its result is consistent: every published text is really in that language. A half-translated interface cannot exist as a state.

If a key does not exist in a language, the field is not rendered — a half-translation cannot exist as a state.

Who translates

Once the technical order is built, an operational question remains, and it is usually the most postponed: who will translate, how often and on what budget?

1. A professional translator — the highest quality, the highest cost, the slowest.
2. A native-speaker team member — good quality, medium speed, capacity-bound.
3. Machine + human review — reasonable quality, low cost, fast. The most common balance.
4. Unreviewed machine — fast and cheap, but a reputation risk.
5. Mixed — conversion pages professional, informational content machine + review.

The fifth item is the right answer for most projects: not every page deserves the same investment. The contact and service pages deserve professional translation; an archive article can pass with machine translation and a light review.

The real question to ask while deciding is this: what do I lose if this page is translated wrong? If the answer is “a customer”, the investment is made; if “a bit of reputation”, a reviewed machine can suffice.

On this site the translated strings are marked in the file with a note and await the owner’s approval. Which text has been verified by a human can therefore always be known — and the unverified ones stand as a list.