Our own website runs in four languages. Not four sites, and not a main site with translated copies bolted on: one site, one content model, four languages, each with its own URLs, menus, and metadata. We build the same way for clients who serve multiple markets, and the single most important thing we have learned is that multilingual is not a feature you add later. It is a decision you make on day one, and Drupal is one of the best reasons to make it with confidence.
Multilingual support is built into Drupal's core rather than supplied by a plugin. Content, configuration, menus, URL paths, and interface text are all translatable natively. That means a well-planned Drupal site does not treat translation as an afterthought or an export-and-import ritual. It treats it as part of the everyday editorial flow, which is exactly where it belongs.
Here is how we structure that in practice, and what we tell every editorial team who will live with the result.
One site, one content model
The alternative approach, a separate site per language, looks simple until you run it. Every update happens twice or four times. Every design change is repeated. Content drifts: one market has the new service page while another still shows last year's. Reporting splinters into disconnected views. And the copies inevitably fall out of step, because keeping several sites identical by hand is a chore that always loses to a deadline.
With one site there is one content model and one codebase, and language becomes a property of the content rather than a copy of the site. An article exists once, with its translations attached to it. When the design changes, it changes for every market on the same day. When a field is added to a content type, every language gets it at once. The structural work is done once and shared. Only the words are per-language, which is how it should be, because only the words differ.
Planned from day one
The day-one part matters because the crucial multilingual decisions are content modeling decisions. For every field on every content type we ask one question: is this translated, or is this shared? A product photo is usually shared across languages, while an image with text baked into it is not. A price is shared, a testimonial is translated, a downloadable brochure might be either. Getting these choices right up front is quick. Changing them later, once content already exists in several languages, is careful migration work.
Planning ahead also keeps costs honest. When a site is built for one language and converted later, the conversion touches everything: templates that assumed a single language, hardcoded text, menus assembled by hand. When multilingual is in the architecture from the start, adding a language later is mostly a content task, translating, rather than an engineering project. It is entirely reasonable to launch in one language on a multilingual foundation and switch on the second language when the business is ready, without rebuilding anything. The foundation does not care how many languages are active. It only cares that the possibility was designed in.
Every language a first-class citizen
A translated site earns trust only if it is complete. That means localized URL paths, not English slugs above foreign-language text. It means page titles, meta descriptions, and social sharing metadata translated per language, so each market is indexed properly and shared links look right. It means menus whose items, order, and even structure can differ per language when the markets need it. And it means the language switcher takes the visitor to this page in the other language, not back to a homepage. Media follows the same rule: captions, alternative text, and attached documents are translatable wherever the market calls for it.
Search engines are an audience here too. Each language version of a page declares what it is and how it relates to its siblings, so a search in each market surfaces the version written for that market. Multilingual SEO is not a separate discipline layered on top at the end. It falls out naturally when every language is treated as a full citizen of the site from the beginning.
Translation inside the everyday editorial flow
The workflow question decides whether a multilingual site stays multilingual. If translating means exporting spreadsheets, mailing them around, and pasting the results back in, translations will lag and the secondary languages will quietly rot. In the setup we build, translation lives next to editing: an editor viewing any piece of content can see which languages it exists in and which translations are missing or outdated, and translating is a tab away, with the source text alongside the fields being written.
That visibility is the quiet hero. When an editor updates the original page, the site knows the other language versions are now behind, and that status is visible instead of being tribal knowledge. Publishing also works per language, so one translation can wait for review while the original is already live. None of this requires heroics from the team. It requires the site to have been set up by someone who expected translation to happen every week, not once at launch.
What to translate, and what not to
The practical advice we give every editorial team: do not aim to translate everything, aim to translate deliberately. Cornerstone pages, services, products, and anything a customer reads before deciding to buy: always, and written or at least reviewed by a person, because these pages carry your voice. News with a short shelf life: often only in the languages where that news matters. Legal pages: translated carefully and reviewed properly, never machine-translated and forgotten. Internal or niche content can exist in one language on purpose, rather than existing badly in four.
A partially translated site is fine. An accidentally partially translated site, where visitors hit missing pages at random, is not. The difference is not budget. It is making the decision consciously, per content type, and having a workflow that shows the current state at a glance.
Living with it
We maintain our own four-language site with a small team, which keeps the advice above honest: every workflow we recommend is one we run ourselves, week in and week out. The pattern that makes it sustainable is always the same. One site. Translation decisions made in the content model, once. Status visible to editors, always. New languages added by adding words, not by adding infrastructure. Set up this way, a multilingual site is not a multiplied workload. It is one site that speaks to each of your markets in their own language, and that remains one of the most concrete ways a business can show a market it is serious about being there.