Making a website multilingual means translating two separate halves: the interface the site itself renders, and the content stored in your CMS. Most tools handle one and charge for the other, which is why localisation so often arrives as a paid add-on or a manual duplication exercise. This is what each half actually requires, what you should deliberately leave in one language, and how to avoid the half-finished state that makes a translated site look broken.
Why is multilingual usually an add-on?
Because the two halves are genuinely different problems. Translating the interface means routing, a language switcher, and a copy of every label, button and error message. Translating the content means every row in every collection needs a version per language, which changes the shape of your database rather than just its values. Tools built around a page-builder document tend to solve the first and bolt the second on later, usually as a plugin with its own subscription.
What the site half needs
Three things, and all three have to agree with each other.
- Its own routes. Each language needs real, separate URLs so a page in French can be linked, shared and indexed on its own. A language that only exists as a client-side toggle is invisible to search engines.
- Translated interface copy. Navigation, buttons, form labels, validation messages, empty states. This is the part people underestimate, because it is scattered across the whole site rather than sitting in one file of content.
- A switcher that survives navigation. Changing language should keep you on the page you were reading, not dump you at the homepage.
What the content half needs
Every translatable field needs a value per language, and the editor needs to see that as one field with language tabs rather than a pile of duplicated columns. The difference sounds cosmetic and is not: a collection with eight translatable fields across four languages is thirty-two raw columns, which nobody can edit reliably.
It also needs a fallback. When a translation is missing, the site should quietly show the default language rather than rendering an empty heading. That single behaviour is what lets you translate progressively instead of holding a launch until every row is done.
What should you not translate?
More than people expect, and getting this wrong creates work forever. Leave these in one language:
- Proper nouns. A person's name, your company name, a product name, a city. These are written the same everywhere, and giving them a per-language field means someone will eventually paste a slightly different spelling into one of them.
- Prices, dates and identifiers. Format them for the locale at render time rather than storing a separate copy.
- Images and files. Unless the image itself contains words, one asset serves every language.
The test is whether the wording genuinely differs between languages. Headings, descriptions and body copy do. A surname does not.
Are regional variants different languages?
Treat them as different, yes. British and American English are separate audiences with separate spelling, idiom and often separate pricing, so each deserves its own translation rather than one inheriting from the other. Any standard language code should work, including regional ones like pt-BR or en-GB, and a tool that only offers a fixed dropdown of major languages will eventually block you.
How does Modulify handle it?
As one request rather than two projects. Asking for a language sets up the routing, the interface copy, the per-language CMS fields and the translation of existing rows together, so you do not end up with a site that switches languages but shows English content underneath. Untranslated values fall back to the default automatically, languages can be removed, and the default language can be changed later without losing either language's text. There is no cap on how many languages a project can have and no separate charge for localisation.
What about SEO?
Real per-language routes are most of the answer, because each version can then be crawled, indexed and linked independently. Beyond that, keep the same page structure across languages so a translated page competes on its own merits rather than looking like a thin copy, and resist the temptation to machine-translate everything at once. A hundred badly translated pages perform worse than ten good ones, and they are much harder to fix later.
What to check before you commit
Four questions worth asking whichever tool you are evaluating:
- Does each language get its own URL, or is it a client-side switch?
- Does the CMS show one field with language tabs, or one field per language?
- What happens when a translation is missing, fallback or blank?
- Is localisation included, or is it a separate plan or plugin?
Those four answers tell you more than any feature list. If you want the wider picture of how a site gets built this way, start with the complete prompt-to-website guide, and see why a relational CMS matters for the structural half of the same story.
