## Translating your site and setting up RTL

URL: https://hub.jkdevstudio.com/knowledge-base/tutorial/translating-and-rtl
Updated: 2026-09-15
Summary: Translate theme strings, build multilingual content and check right to left layout, and understand why these are three different jobs.

Three different jobs live under the word "translation", and confusing them is why people get stuck. They are solved separately.

## Right to left works by itself

Set the site language to a right to left locale in [[Settings > General]] and the whole site flips: layout, alignment, spacing, the theme's own components. There is no RTL switch to find and nothing to configure, because text direction is a WordPress property and the theme follows it.

What does not happen automatically is a visual check. Direction changes layout in ways nobody predicts from a settings screen, so walk the site and look at:

- [ ] Navigation and dropdowns
- [ ] Directional icons, meaning arrows and chevrons that now point the wrong way
- [ ] Forms and their labels
- [ ] Tables
- [ ] Galleries and sliders
- [ ] Any third party widget, which is where problems concentrate

The theme handles its own components. A third party plugin that never considered right to left is where you will find the broken layout, so check before launch rather than after.

## Translating interface strings

These are the words the theme and plugins print: button labels, form messages, the text around your content. This is one language for the whole site, and it needs no multilingual plugin at all.

Both products ship a `.pot` file, which is the list of every translatable string with nothing filled in. The theme keeps its own in its `lang` folder, and the Pro plugin keeps a separate one in its own. You translate from that template into a file for your language.

There are two ways to do it, and neither is better than the other:

:::deflist

[Poedit](https://poedit.net/) on your computer
: Open the `.pot`, translate, save a `.po` and `.mo` pair for your locale, upload them. Comfortable if you are translating everything in one sitting.

[Loco Translate](https://wordpress.org/plugins/loco-translate/) in the admin
: Reads the same templates and edits translations on the site itself, which suits fixing twenty strings without a round trip.

:::

Two practical points. Keep the finished files where an update will not overwrite them, which for WordPress means the languages folder outside the theme rather than inside it. And revisit the translation after a release, because new features bring new strings and an untranslated string falls back to English.

WordPress documents the whole mechanism in its [internationalization guide](https://developer.wordpress.org/apis/internationalization/) if you want the background.

## Multilingual content

This means your posts and pages existing in more than one language. It is a different job and needs a dedicated plugin.

That plugin handles the parts that make a multilingual site work: translations of posts and taxonomies, language specific URLs, per language menus, SEO metadata per language, and the links between versions of the same page.

The theme works with any established multilingual plugin. For three of them it also ships a switcher, so the language control is drawn by the theme and looks like part of the site:

<a data-type="kb-embed" href="/knowledge-base/integration/weglot-language-switcher">Weglot language switcher</a>

<a data-type="kb-embed" href="/knowledge-base/integration/translatepress-language-switcher">TranslatePress language switcher</a>

<a data-type="kb-embed" href="/knowledge-base/integration/wpml-language-switcher">WPML language switcher</a>

**Which to pick.** [Weglot](https://weglot.com/) and [TranslatePress](https://wordpress.org/plugins/translatepress-multilingual/) both translate the rendered page, which is the lighter approach and the one we would reach for first: setup is short, and the site keeps working the way it already did. [WPML](https://wpml.org/) is the oldest of the three and stores a translated copy of everything in your database, which makes it heavier to run and harder to undo. It is fully supported and has its own switcher, so use it when something you depend on requires it rather than as a default.

<div data-callout="info">

**A translation plugin and a translation file solve different halves, and a site needs both.**

The plugin does not translate the theme's interface strings for you, and a translation file does not make your content multilingual. People usually set up one of the two and then wonder why half the site is still in one language.

</div>

## Common questions

<details><summary>Do I need a plugin for a single language site that is not English?</summary>

No. Setting the site language and supplying a translation file for the interface is the whole job. A multilingual plugin would only add machinery you never use.

</details>

<details><summary>Where do I put my own translation file?</summary>

In the WordPress languages folder rather than inside the theme, so that a theme update replaces the code and leaves your translation where it is.

</details>

<details><summary>Do I have to translate the theme and the Pro plugin separately?</summary>

Yes. They are two products with two templates, and each one carries only its own strings. That is also why a partly translated site usually turns out to have one of the two files missing.

</details>

<details><summary>Some strings stay in English after I translate</summary>

Either those strings are newer than your translation file, or they come from a plugin whose own file is missing. Translations are per component, not per site, and each theme and plugin carries its own.

</details>

<details><summary>The direction looks wrong on one element</summary>

Isolate it first: deactivate third party plugins and check that element again. If it corrects itself, the plugin is the source and its author is the one who can fix it. The theme's own components are ours, so send those to us with a screenshot.

</details>