Translate WordPress content and interface strings with a maintainable workflow

Separate site language from the user’s dashboard

WordPress’s language setup guidance explains selecting available languages and language files. Confirm the intended site locale and current translation availability rather than treating an English fallback as evidence the whole installation is broken.

The user-profile documentation describes an individual administration-language preference without changing what visitors see. Check the user preference and visitor-facing language separately when a logged-in editor reports a different result.

For a fictional Portuguese editor maintaining an English publication, a Portuguese dashboard does not require translating public English articles. Conversely, choosing Portuguese in a site setting does not rewrite the database content of an English article into Portuguese.

Choose an architecture for genuine language versions

The multilingual WordPress handbook describes different approaches: linked language versions, alternatives stored together, generated-page translation or separate sites. They have different content ownership, portability and integration implications.

Before selecting an implementation, define source language, target languages, URL structure, editorial responsibilities, custom-type/field support, navigation and update synchronization. Check the actual plugin or service’s current feature and cost limits. Do not assume its free edition supports every language, URL or content model.

A browser translation feature can help an individual reader, but it is not proof that the publisher maintains reviewed language-specific pages. Avoid automatically replacing source content or rolling out several overlapping translation systems before checking how they store versions and identify the original language.

Diagnose untranslated theme or plugin strings

WordPress’s plugin internationalization guidance explains text domains and marking strings for translation. For a missing label, identify its exact original text, owning component, installed version, locale and context.

Check whether a translation exists for that component and locale, whether the supported language pack is installed and whether an option or saved field supplies the text instead. Two identical English phrases can belong to different text domains or contexts.

Do not edit plugin PHP or JavaScript merely to replace a word. Updates can overwrite the change, and a global find/replace can alter unrelated strings. Prefer the component’s documented customization/localization mechanism and report an untranslatable string to its maintainer with minimal public evidence.

Understand translation files without assuming one format

The localization handbook explains POT templates, PO translations and traditional compiled MO files. These concern software strings, not a backup of translated posts or a universal file into which every paragraph should be pasted.

Modern WordPress can also use PHP-based translation files; the WordPress 6.5 translation changes introduced that additional runtime format. Do not assume a visible PO edit necessarily updates whichever compiled/runtime file is actually loaded.

Block Editor internationalization documents the JavaScript translation path and script-associated JSON data. A PHP label being translated does not establish that an interactive block’s JavaScript strings are loaded correctly. Follow the installed component’s supported generation/loading workflow rather than renaming files until something changes.

Translate the complete reader task

For a fictional contact page, translate the title, explanation, field labels, required-field messages, submit state, error/success feedback and any confirmation email you own. Check the route a reader follows, not just the words visible before interaction.

Review navigation, footer links, category names, search/empty results, image alternatives and relevant downloads. Adapt examples and terminology where appropriate while preserving facts. A price, service limit or safety instruction should not change meaning because a sentence sounds smoother.

Keep placeholders, variables and markup intact under the component’s documented translation rules. Plural forms and context matter; a one-word substitution can be wrong in a full sentence. If machine assistance is used, review the output and any service data-sharing/cost settings before sending unpublished or private material.

Record the source version and reviewer so later factual updates can be applied to every maintained language version. Do not claim a translation is current solely because its page still loads.

A small translation register can contain the source URL, target URL, last source change, translation status, reviewer and open questions. For a tutorial update, identify the affected steps and screenshots, revise the corresponding language versions and check their destination links. Mark an unfinished version as pending review internally rather than silently treating the previous answer as verified.

Keep a short terminology list for recurring interface names and technical concepts. Distinguish a translated explanation from the actual label a reader will see in their installed software. If the provider publishes only an English settings label, retaining that exact label alongside a translated explanation can make the instructions easier to follow.

Give readers predictable language navigation

Use clear language names and connect equivalent pages where they exist. When a translation is missing, communicate that honestly instead of linking to an unrelated homepage under the same title. Preserve a deliberate route back to available content.

Google’s multilingual-site guidance recommends distinct URLs for language versions and cautions about forced redirection based on presumed language or location. Let readers reach the version they choose and inspect what crawlers can access.

Language and region are different decisions. A Portuguese-language page does not automatically provide Portugal-specific pricing or contractual information. Identify the content’s actual scope and avoid presenting translated US facts as if they had been verified for another market.

Check language metadata and alternate-page relationships

The W3C language declaration guide explains identifying a document’s language and language changes within it. Verify the actual rendered page, especially where templates or a translation plugin choose the document attributes.

Google’s localized-version guidance describes hreflang relationships between corresponding URLs, including self and reciprocal references. Use supported language/region values and maintain the relationships consistently with the available versions.

Language declarations, hreflang and canonical choices serve different purposes. Do not mark an untranslated page as a completed alternate or point every language’s links at one generic destination. A technically present annotation neither translates content nor guarantees indexing or rankings.

Preserve updates, custom translations and rollback

Document where custom strings and language versions live, who owns them and how updates are deployed. An update can add or change source strings; a content refresh can make an older translation incomplete. Review those dependencies rather than treating translation as a one-time launch task.

Use our theme customization guide for saved components versus theme files, and the content review guide for maintaining factual versions. Neither replaces the translation system’s own export/recovery requirements.

Start with a complete, reviewed reader journey and a recoverable implementation. The useful result is understandable, accurate content and working interaction in the intended languages, with clear maintenance ownership—not a flag icon or a changed site-language dropdown.