Multilingual Websites: Choosing a Platform That Scales Across Languages

The language model comes before the feature list

Almost every platform marketing page says “multilingual support”. The phrase hides an enormous range of implementations, from a full language model baked into the core to a thin plugin layer that stores translated pages next to each other and hopes for the best. Choosing a platform for a multilingual website by comparing feature checklists is therefore unreliable. What matters is how the platform models languages, and whether that model matches the way the organization will actually publish.

Four questions shape that match:

• How many languages, and how symmetric are they? A site with one primary language plus a part-time English translation behaves very differently from a site where four languages must all stay current.
• Who translates? Professional translators working in batches, an internal team editing side by side, or machine translation with human review each imply different workflow needs.
• Is the site one website with multiple languages, or several regional websites that happen to share a brand?
• What URL structure does the business need — language subdirectories, subdomains, or country-specific domains?

The answers eliminate platforms faster than any feature comparison. A single-language site with vague “maybe someday” translation plans should not pay a complexity tax for a heavyweight language model. A five-language corporate site with legal review per market cannot survive on a plugin that breaks every time the core updates.

WordPress: multilingual through plugins, not core

WordPress core is language-aware but not multilingual. The admin interface can run in any locale, and WordPress allows setting the site language, but core has no concept of “this page is the German version of that page”. Translated content is created and related entirely by plugins.

This is workable and extremely common. Plugins such as Polylang and WPML implement the model that most teams expect: each translation is a separate post, linked to its siblings, with language-specific URLs like /de/ueber-uns/. Menus, categories and widgets each carry language assignments. SEO plugins generally cooperate with the major multilingual plugins to emit hreflang annotations.

The trade-off is architectural. The language layer lives outside the core update cycle, so the multilingual plugin becomes one of the most critical dependencies on the site. Its compatibility with the theme, the page builder and the SEO plugin has to be verified on every major upgrade. On a large site, the post-per-translation model also multiplies content: a hundred pages in four languages is four hundred posts to search, filter and keep consistent. Teams that run WordPress multilingually should budget for that structure in their editorial process, not just in the plugin license. If the site is built on WordPress, our WordPress development service covers planning this layer before the first translated page exists, which is considerably cheaper than retrofitting it.

WordPress fits best when the number of languages is modest, the team is already comfortable with its editing model, and the multilingual plugin can be treated as a first-class dependency with testing on every update.

Joomla: a built-in language layer with associations

Joomla takes a different position: multilingual support is part of the core. Content languages are declared in the admin, a system plugin routes visitors by language, and modules and menu items can be assigned per language. Since the association system was introduced, Joomla also ships a Multilingual Associations component that links an article in one language to its counterpart in another, so editors can work on pairs directly rather than managing parallel trees by discipline.

The strength of this approach is that language assignments behave like any other core property. Menu structures, modules and access levels all understand languages natively, so building a site where each language has its own navigation is a configuration task, not an extension-selection project. There is no single critical plugin whose failure takes down every language at once.

The boundary is worth knowing: Joomla’s core manages the language structure and the associations, but it does not provide the translation itself. The workflow of producing translated text — machine translation, translation memory, review states — still needs extensions or an external process. Joomla is a strong fit when the structure of the multilingual site matters more than the translation tooling, for example an organization site where editors maintain two or three languages by hand. For teams extending an existing Joomla site, our Joomla development service regularly deals with cleaning up language assignments that were added without a plan.

TYPO3: languages as a site configuration concern

TYPO3 treats multilingual publishing as a core architectural concern rather than a feature. Each site definition declares its languages with locale, hreflang value and fallback behaviour. Records — pages, news, structured content elements — are translated in a connected mode: the translation stays attached to its source record, inherits structural changes, and can fall back to another language when a translation is missing.

Two consequences follow. First, the page tree remains a single tree. Editors see one structure with translation status per page, which scales better mentally than four parallel trees. Second, the fallback chain is explicit and configurable: a German page missing a Swiss-German translation can render the German version, a placeholder, or nothing, depending on policy. For organizations where languages are governed — corporate sites with mandated translations, regulated industries, institutions — this control is the reason TYPO3 is often on the shortlist. The platform page on TYPO3 covers this positioning in more depth.

The cost is the usual one for TYPO3: the model is powerful but not casual. Configuration is done by integrators in TypoScript and site configuration files, not by toggles in the admin. A two-language brochure site will carry setup weight that Joomla or WordPress would not. Our TYPO3 development service exists largely because this configuration layer rewards experience.

Shopify: markets, locales and translated storefronts

Commerce multilingualism has a different shape: language and market are intertwined. Shopify addresses this through Markets, which bundles language, currency, and country-specific catalog and domain settings per market. Storefront content — product information, themes, pages and blog posts — is translated through Shopify’s translation APIs and the Translate & Adapt tool, and translated locales are served on subdirectory URLs.

The notable strength is that translations here are field-level rather than page-level. A product’s title, description and variants each carry their own translations attached to the same product record, so structure stays identical across languages and currency or payment settings can vary per market. That is a materially better model for commerce than duplicating product pages per language.

The boundary is content depth. Long-form editorial content, complex documentation and bespoke page structures are not Shopify’s center of gravity; the platform optimizes for catalog and checkout. A business whose multilingual needs are primarily “sell the same products in more countries” fits Shopify well, and our Shopify development service handles theme localization and market setup. A business that publishes heavily in several languages may still prefer a content platform in front of the store.

Decide the URL strategy before the platform builds it for you

Every platform discussed above can serve language subdirectories, but they do not all make it equally easy to change later. Subdirectories (/de/…) keep authority consolidated in one domain and are the most common choice; subdomains and country domains split it, but give regional teams independence. The hreflang annotations that tell search engines about language variants need to be consistent with whatever structure is chosen, and inconsistent hreflang across a large site is one of the more tedious problems to unwind.

Changing URL structure after launch means redirects in every language plus a re-indexing cycle. This decision belongs in the platform selection phase, together with the CMS comparison itself — it is one of the structural choices, like platform migration, that is cheap to get right early and expensive to fix later. The CMS selection framework and the platform migration decision guide cover the surrounding decisions; a language restructuring is significant enough that it should be treated with the same discipline as a migration.

Translation is an operating cost, not a launch task

The most common multilingual failure mode is not technical. It is a site that launches with four complete, well-translated languages and eighteen months later has one current language and three increasingly embarrassing ones. Stale translations damage trust more than missing ones, because visitors cannot tell which language reflects reality.

Plan for the steady state, not the launch: who updates a translation when the source page changes, how stale translations are detected, and whether partial translation with fallback is acceptable policy. TYPO3’s fallback chains and Joomla’s associations make that policy explicit; WordPress plugin setups and Shopify Markets both need a defined editorial process behind them. Machine translation has lowered the cost of the first pass considerably, but review remains the bottleneck, and the platform choice does not remove it.

The practical selection rule is simple: choose the platform whose language model matches the operating reality of the team. WordPress plus a mature multilingual plugin for a small number of languages and a comfortable team. Joomla when the language structure should be native and simple. TYPO3 when multilingual governance is a core requirement rather than an extension. Shopify when the multilingual problem is primarily a commerce problem. The wrong choice is not the weakest platform — it is the platform whose model quietly assumes a publishing discipline the organization does not have.