How to Set Up a Multilingual WordPress Site

Setting up a multilingual WordPress site involves more architectural decisions than it appears to. Installing a plugin and adding a language is a few minutes’ work; the method chosen, however, determines the maintenance cost of the years that follow, and turning back usually means a content migration project.

Contents

WordPress carries considerable weight in this discussion: it is the most widespread of the content management systems that make up 61.4% of all websites (W3Techs, September 2019 data). The question of multilingual structure therefore arises in the same form for a great many organisations.

Below we take the methods, the URL structure options, the text that falls outside content and the translation file workflow in turn.

Three ways to build a multilingual WordPress site

There are three basic approaches, and the choice depends on how far the content diverges between languages.

Method	How it works	When it suits
Single installation + translation plugin	The language pairing of every piece of content is held in the same database	If the content is largely the same across languages
Multisite network	Each language a separate site, administered together	If content and design diverge markedly between languages
Separate installations	Each language an independent WordPress	If there are separate teams, separate brands or separate legal entities

A single installation is the most practical option for most corporate sites. The versions of the same post in different languages are linked to one another; when a visitor switches language they arrive at the counterpart of the page they were on, not at the home page. That detail matters for user experience and is lost with separate installations.

A multisite network pays off if you need different menus, a different product catalogue and a different campaign structure by language. The price is doing the same work several times over: plugin updates, design changes and technical maintenance are multiplied by the number of sites.

URL structure: subdirectory, subdomain, separate domain

Once the method has been chosen, the first decision is the URL structure, and this decision has lasting consequences on the search engine side.

In a subdirectory structure the languages sit under the same domain like folders. The accumulated authority of the domain is shared, and the certificate and the technical administration are single. This is what is recommended for most projects.

A subdomain structure is used where technical separation is required, and it is usually the default option for multisite installations too. A separate domain makes sense for organisations that want independence in marketing terms, but each domain then has to build up its own authority from scratch.

Whichever structure is chosen, reciprocal language tags have to be set up correctly between the pages. If those tags are missing, the search engine may show the Turkish page to the wrong audience and the two versions compete with each other.

Criteria to look at when choosing a plugin

Translation plugins look similar in terms of functionality; the points on which they differ lie in technical detail. Four criteria determine the long-term cost.

The first is the data model. Some plugins hold translations as separate records, others store them as fields within the same record. The separate-record model makes it easier to rescue the content if you later have to move away from the plugin.

The second is export capability. If the plugin can export content in a standard format such as XLIFF, you can work with a translation tool; if it cannot, translation is done by hand in the interface and no translation memory is built up.

The third is scope: does it translate only posts and pages, or does it cover custom post types, taxonomies, menus and page builder blocks as well? The fourth is compatibility; the plugin needs to have been tested together with the theme, the page builder and the e-commerce platform you use.

These four criteria translate directly into budget. Choose a plugin that cannot export and every update is translated at the full rate; choose a plugin with narrow scope and menus and product attributes are managed by hand. Because the decision is taken once and changing it means migrating content, trying things out on a backup at the selection stage is the cheapest insurance there is.

Text outside content: theme and plugin strings

Not all of the text on a site is content. Phrases such as “Add to basket”, “Read more” and “No search results found” come from theme and plugin code. A translation plugin generally does not cover them.

These texts are software strings, and in the WordPress ecosystem they are translated with PO/MO files. Most widely used plugins come with a ready-made Turkish translation; it may be incomplete, however, or it may not match your terminology.

The practical approach is this: first the coverage of the existing translations is checked, then the missing and mismatched strings are listed and handled as a separate translation package. The package is small but has a direct effect on the first impression the product makes; an English button left in place at the payment step lowers conversion.

Custom-built themes call for one further check: if text is hard-coded in the theme, it will not appear in any file. In that case the theme has to be internationalised first, which means bringing the texts into translation functions.

The translation file workflow and translation memory

On small sites it is reasonable to have the translation done directly in the WordPress interface. As the volume grows, this method throws up three problems: repeated text is charged for again, term consistency cannot be checked and progress cannot be tracked.

The alternative is to export the content and process it in a translation tool. In this workflow the text is saved into a translation memory; on subsequent updates only the sentences that have changed are charged for. Industry measurements have found that roughly 40% of translation work is reusable (DePalma 2012), which makes a marked difference on sites that are updated regularly.

The critical point in the workflow is the reimport. Make sure that the exported file can be restored with the same structure once it has been translated; this should be tried out on a small group of pages in the first round. Loss of formatting, damage to the block structure and broken links show up here most often.

Maintenance, performance and backups

A multilingual installation produces more data and more queries than a single-language one. Additional records for each piece of content, language pairing tables and language switcher logic all come into play. On small sites the difference is not noticeable; as the amount of content grows, page load times may lengthen.

The measures to be taken are standard ones: making sure the cache layer works in a language-aware way, removing unnecessary plugins and putting the database tables through regular maintenance. If the cache is not language-aware, visitors may be shown a page in the wrong language; this is one of the most frequently reported problems in multilingual installations.

On the backup side the critical point is that the translations are backed up together with the content. Some plugins hold the language pairings in separate tables, and partial backups may not include those tables. On restoring, the content comes back but the pairings do not, and the sites are cut off from one another.

Finally, update discipline is needed. The translation plugin, the theme and the e-commerce platform depend on one another; a major version update to one can break another. Trying updates out first in a copy environment matters far more in multilingual installations than in single-language ones.

The order of setup and common mistakes

The order determines both the cost and the risk of having to turn back. The sequence below is one that runs smoothly on most projects.

1. Choose the method: single installation, multisite network or separate installations.
2. Decide on the URL structure and set up the language tags.
3. Choose the plugin against the four criteria and try it out on a backup.
4. Take an inventory of the state of the theme and plugin strings.
5. Pick 5–10 pages as a pilot and test the export and reimport workflow.
6. Approve the term list, then send the bulk content for translation.
7. After launch, test the behaviour of the language switcher and the on-site search.

Common mistakes arise from disturbing this order: translating content before the plugin has been chosen, leaving theme strings out of scope, linking the language switcher only to the home page and running a large import without taking a backup.

The Türkiye context

Three details cause particular trouble in WordPress installations with Turkish content. The first is the URLs: Turkish letters have to be simplified correctly in the links generated from a post title. A faulty conversion produces unreadable or duplicated URLs, and correcting them afterwards means setting up redirects.

The second is database collation. On sites migrated from older installations, the collation setting may not sort Turkish letters correctly and may affect search results. After a migration, the encoding needs to be verified as UTF-8 from end to end.

The third is on-site search. A significant proportion of users in Türkiye search without using Turkish letters. Whether the on-site search can match the query “sirket” with “şirket” is a detail that bears directly on sales in e-commerce. This behaviour does not come as standard in most installations; it is configured separately.

What does this mean for you?

If you are going to publish your site in Turkish and in other languages, settle the structural decisions before you discuss the translation budget. Translation carried out on the wrong structure gets done all over again in the months that follow.

1. Set out in writing how far the content will diverge between languages; the choice of method follows from that.
2. Verify whether the plugin can export in XLIFF or a similar format.
3. Price the theme and plugin strings as a separate item; do not assume they are included in the content quotation.
4. Do not start bulk translation before completing an export and reimport round with a pilot group of pages.
5. Ask for the translation memory to be handed over to you; the cost of later updates depends on it.

If you tell us about your installation and your plugin setup, we can work out together which workflow suits you. Write to us or request a quote directly; a page list and plugin details are enough for us to scope the work.

Frequently asked questions

Which method is better: a single installation or a multisite network?

A multilingual structure built with a plugin on a single installation gives you content pairing and ease of administration. A multisite network makes sense if the difference in content and design between the sites is large. For most corporate sites a single installation is enough.

How are the texts in themes and plugins translated?

These are software strings rather than content, and they are translated with PO/MO files. The content plugin does not cover these strings; they have to be planned as a separate item.

Should I use a subdirectory or a subdomain?

A subdirectory suits most projects; it shares the accumulated authority of the domain and keeps administration within a single installation. A subdomain is preferred for installations that are technically separated.

Should I have the translation done in the WordPress interface?

That works for short content. As the volume grows, exporting the content as XLIFF or PO and processing it in a translation tool is more efficient, because it gives you a translation memory and term consistency.

Sources

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 16–19.
• W3Techs (2019). Usage Statistics of Content Management Systems – WordPress 61.4% (September 2019 data).
• DePalma, D. (2012). Translation Productivity Benchmarks. Common Sense Advisory (2012 data).
• WordPress.org, Internationalization for Developers – theme and plugin strings.