String translation

A string, in translation, is a short piece of text that lives in code rather than in your content: a button label, a menu caption, a form error, the "Add to cart" on a shop page. String translation is the work of translating those texts, as opposed to the posts and pages an editor writes. In WordPress the term usually means the theme and plugin texts that a content translation plugin does not reach on its own.

Where strings come from in WordPress#

WordPress developers prepare their code for translation by wrapping each visible text in a function such as __() or _e(), with a text domain that says which plugin or theme the string belongs to. Translators then work in a PO file for each language, and WordPress loads a compiled MO file named after the text domain and the locale, such as my-plugin-de_DE.mo. When a translation exists, WordPress prints it in place of the original.

That system works well for strings a developer wrapped and a translator covered. Three kinds of text fall outside it:

• Text the developer never wrapped, which no translation file can reach.
• Text you typed into settings screens: a theme's footer line, a plugin's notice, a widget title.
• Strings in languages no one has translated the plugin into yet.

How translation plugins handle strings#

Plugins that store each language as a separate post translate your posts and pages, but theme and plugin texts are not posts, so they add a separate screen for strings. WPML calls its module String Translation, and WPML's purchase page lists it among the things its entry licence, Multilingual Blog, leaves out. There someone finds the strings, often by scanning the theme and plugins, and translates them in a list where they appear without the page around them. A one-word label such as "Order" can mean a purchase or a sequence, and the list does not say which.

TranslatePress works on the rendered page instead. Its WordPress.org listing says you translate the entire page at once from the front end, output from shortcodes, forms and page builders included, and that it can translate the dynamic gettext strings WordPress, plugins and themes add. It saves each translation per string in its own database tables.

Strings in a rendered-page translator#

LangRelay also translates the page WordPress renders, after the theme and every plugin have printed their text, so a theme's footer line, a plugin's button and an editor's paragraph are found and translated together, with no list of strings to build first. By default a translation then goes live as soon as it is ready, with free checks that hold a page with untranslated text, the wrong language or a changed price, and the approved text is served from your own site.

Text that repeats across a site, like a footer line or a "Read more" link, is a single unit in LangRelay. It is translated once, and every page that shows it uses that translation. When one word needs two translations in different places, LangRelay's design separates the two uses with an explicit label that a person sets; it does not infer them from where on the page the text appears. Setting such a label is on the roadmap, and today identical text shares one translation.

Some text is not on the rendered page when it loads. A mini-cart or a notice that JavaScript adds later is translated in the visitor's browser when the same text has an approved translation elsewhere on the Site. The WordPress admin is outside LangRelay's scope: it translates what visitors see, and the admin keeps WordPress's own language packs.

For how this works on a store, see how to translate a WooCommerce store. The WordPress translation guide covers the whole setup, and localization vs translation puts strings in the wider picture.