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 SettingsGeneral 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 follow 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, and it is worth checking before launch rather than after.
#Translating interface strings
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.
Two ways to do it, and neither is better than the other:
- Poedit on your computer
Open the
.pot, translate, save a.poand.mopair for your locale, upload them. Comfortable if you are translating everything in one sitting.- 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 if you want the background.
#Multilingual content
Your posts and pages existing in more than one language. This 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:
Which to pick. Weglot and TranslatePress 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 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.
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.
#Common questions
Do I need a plugin for a single language site that is not English?
No, setting the site language and supplying a translation file for the interface is the whole job, and a multilingual plugin would only add machinery you never use.
Where do I put my own translation file?
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.
Do I have to translate the theme and the Pro plugin separately?
Yes. They are two products with two templates, and each one only carries its own strings, which is also why a partly translated site usually turns out to have one of the two files missing.
Some strings stay in English after I translate
Either those strings are newer than your translation file, or they come from a plugin whose own file is missing, because translations are per component rather than per site and each theme and plugin carries its own.
The direction looks wrong on one element
Isolate it first by deactivating third party plugins and checking that element again, and if it corrects itself then the plugin is the source and its author is who can fix it. The theme's own components are ours, so send those to us with a screenshot.
#Still stuck
Open a support ticket and say what you tried and where it stopped. Your product, your domain, a screenshot and the exact message you saw are usually enough to settle it in one reply.
Last updated
