Article · WordPress

Multilingual WordPress: what I learned translating this site

This site exists in French and in English. I translated it myself with the free version of Polylang. These are the choices I made, the two problems that cost me time, and what I’d do exactly the same again for a multilingual site in Luxembourg.

The question comes up on day one

In Luxembourg, a professional website is rarely in one language. French, German and English are everywhere, sometimes Luxembourgish too. Before I’d even picked a theme, I had to answer two questions: which language is the default, and what do the addresses of the other languages look like?

Both decisions are painful to change later: redirects, SEO to redo, and often a loss of rankings while the search engines reindex everything. For my site the answer was straightforward. I’m a French speaker and my main audience reads French, so French sits at the root of the domain. English lives under /en/. If I ever add German, it will go under /de/ without breaking anything.

Subdirectory, subdomain or separate domain

There are three possible address structures. A subdirectory, along the lines of mysite.lu/en/, keeps everything on one domain and one WordPress installation. It’s a bit like a house with a wing per language: one postal address, one front door. It’s the simplest to manage, and the domain’s reputation benefits every language. That’s the one I chose.

A subdomain, such as en.mysite.lu, separates the languages a little more in the eyes of search engines. It needs a setting at the registrar and a certificate that covers subdomains. A separate domain, say a .lu and a .fr, sends the strongest geographic signal but multiplies costs, installations and SEO work. For a brochure site or a portfolio, the subdirectory is almost always the right call.

Polylang, WPML or TranslatePress

I compared the three most common plugins before starting. They don’t work the same way, and that matters more than the price.

Polylang creates a separate page or post per language, then links those items together. Each translation is a real WordPress entry with its own address, its own information for search engines and its own featured image. The free version covers pages, posts, categories, menus and theme text. It’s lean, adds no extra layer, and I noticed no slowdown on the site.

WPML follows the same separate-content logic with more options: translator management, connections to translation services, detailed support for WooCommerce. It’s a paid, heavier solution, suited to corporate sites or shops that need that level of tooling. TranslatePress approaches the problem differently. You translate directly on the site’s front end, sentence by sentence, while looking at the page. It’s very approachable for someone who isn’t comfortable in the WordPress admin, but you have less control over the structure of each translation, and per-language SEO is reserved for the paid version.

For a site I manage alone, with content I write myself in both languages, free Polylang was enough. I’d suggest WPML to a company that outsources its translations, and TranslatePress to a client who wants to do everything from the page without touching the dashboard.

What I actually set up

To begin with, I translated twelve pages and six posts. For each French item, Polylang creates an English draft that I fill in, and the two are then linked as translations of each other. I set the English home page as the home page for that language, so /en/ shows that page rather than the post list.

Categories are translated as well: “Articles” becomes “Insights”, “Projets” becomes “Projects”. Without that, an English post turns up under a category with a French name. For navigation, I created two menus, one per language, each assigned to the theme’s primary location for its language. The language switcher is a menu item provided by Polylang. Theme text that belongs to no page, such as the footer or a button label, is translated in Polylang under the Translations screen.

For contact, I have two Contact Form 7 forms, one per language. Each form has its labels, validation messages and acknowledgement email written in the visitor’s language. The legal pages and the cookie policy have to exist in every language too, and I very nearly forgot them.

The “EN” button kept sending me to the home page

For a while, clicking “EN” from a French page sent visitors to the English home page instead of the equivalent page. The cause turned out to be simple: the translations weren’t linked yet. Polylang doesn’t guess that an English page corresponds to a French one; you have to tell it in the “Languages” box of the editor, by picking the matching translation. As soon as the link exists, the switcher goes to the right page.

The second problem involved the form. Before I had one form per language, the error and confirmation messages showed up in English on the French version. A single form can only carry one language of messages. The fix was to duplicate the form, translate its texts and embed the right form on the right page.

SEO for a multilingual site

A well-built multilingual site tells search engines which version to serve to which visitor. That’s the job of a small invisible label added to every page (hreflang), which Polylang generates by itself once translations are linked. Again, unlinked content gets no label.

I use Rank Math, and I wrote a title and a description per language, by hand. The sitemap is also split by language. These settings belong to my technical SEO checklist for WordPress, which I apply to each version as if it were a site in its own right. What needs translating goes beyond the visible text. Before I consider a page translated, I check:

  • the page address, so an English page doesn’t carry a French word in its URL;
  • the title and description intended for search engines;
  • the alt text of images;
  • automatic emails, acknowledgements and notifications;
  • categories, tags and menu items.

One page, one language, and no machine translation without proofreading

Two rules I hold myself to. First: one page, one language. An English button on a French page, or a cookie notice left in French on the English version, makes the site look unfinished.

Second: no machine translation published without proofreading on a professional site. Today’s tools are useful for a first draft, but they produce false friends and sometimes outright errors on industry vocabulary. On a site meant to convince a client or a recruiter, one clumsy sentence costs more than the time spent proofreading.

Translating a site isn’t just translating pages. It means duplicating a whole structure, menus, categories, forms, emails, legal pages. Most of the problems I ran into came from something I’d forgotten to duplicate or to link, never from the plugin itself. With free Polylang, a subdirectory structure and a thorough checklist, a bilingual or trilingual brochure site can be done without any extra budget. That’s what I suggest to Luxembourg businesses still hesitating to take the step.

A position to fill? Let’s talk.

I am looking for a permanent position as a WordPress developer or digital marketing specialist, in Paris, elsewhere in France or in Luxembourg.