Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallSome links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
The right translation method depends on how the plugin is distributed. A plugin hosted in the WordPress.org directory can use the community translation system and language packs. A private, custom, or otherwise non-directory plugin normally requires its own POT, PO, and MO files. In both cases, the plugin’s text domain, locale, file names, PHP strings, JavaScript strings, and output escaping must all line up.
Choose the translation route first
Identify where the plugin comes from before editing files. The distribution method determines who controls translations and how updates reach your site.
| Consideration | WordPress.org plugin | Private or non-directory plugin |
|---|---|---|
| Where translations are managed | The plugin’s project and translation sets on translate.wordpress.org | Files managed by the plugin author, site owner, or translation team |
| Who controls approval | Directory translation contributors and project maintainers | The plugin maintainer or your own review process |
| Template availability | Usually provided through the project’s translation system | Obtain a POT file from the author, or generate one with WordPress internationalization tooling |
| Update distribution | WordPress language packs can deliver approved translations | You must update and deploy the PO/MO files yourself unless the vendor supplies them |
| Code coverage | PHP strings and JavaScript strings that the plugin properly internationalizes | The same requirement, but you may need to modify the plugin or ask its author to add missing i18n support |
| Review and security | Project review and contributor controls | Your own review is essential before installing or distributing files |
For a WordPress.org plugin
Open the plugin’s project on translate.wordpress.org, choose the target locale, and work in its translation set. Approved translations are normally distributed through WordPress.org language packs rather than by manually copying files into the plugin directory.
For a private or custom plugin
Ask the maintainer for the plugin’s POT template. If none exists, the maintainer can generate one with WordPress internationalization tools. You then create a PO file for your locale, translate its entries, compile it to an MO file, and install the resulting files.
#1 Best Overall
Identify the plugin slug, text domain, and locale
Before translating anything, record three identifiers:
- Plugin slug: the directory-style identifier used by a WordPress.org plugin.
- Text domain: the identifier passed to WordPress translation functions.
- Locale: the language and, where applicable, country variant, such as
de_DE.
For a WordPress.org plugin, the text domain must match the plugin slug. It should use lowercase letters and dashes. A mismatch prevents WordPress from associating your translation with the plugin, even when the translated words themselves are correct.
Understand POT, PO, and MO files
POT: the source template
A POT file lists the translatable source strings extracted from the plugin. It is a template, not a finished translation. It commonly contains msgid entries, source references, and metadata.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
PO: the editable translation
A PO file is the human-editable catalog for one locale. Translators enter the target-language text in each msgstr field, while leaving the source msgid unchanged. Poedit is one documented editor option; a plain-text editor also works if you preserve the file’s syntax.
MO: the compiled runtime file
An MO file is the compiled form WordPress reads at runtime. WordPress does not use an uncompiled PO file alone to translate displayed strings, so compile the PO after translating or changing it.
Translate a PO file safely
- Open the POT or existing PO file. Confirm that its text domain and source references belong to the plugin you are editing.
- Translate each
msgstr. Do not alter the sourcemsgidunless the plugin author changes the original string. - Preserve placeholders exactly. Keep tokens such as
%s,%d, numbered placeholders, HTML elements intended by the author, and plural forms in the correct positions for your language. - Translate plural entries. A plural record can contain separate translations for each plural form. Do not collapse those entries into one sentence.
- Review context and references. The same English word can require different translations depending on whether it is a button, status label, noun, or verb.
- Save with the intended character encoding. Use UTF-8 and retain the catalog header’s locale information.
Name and place the translation files correctly
Use the plugin text domain and locale in each filename. For example:
my-plugin-de_DE.pomy-plugin-de_DE.mo
For a manually distributed plugin, place the files in the plugin’s languages directory when that is the location expected by the plugin. WordPress can also load plugin language files from wp-content/languages/plugins. The correct location depends on how the plugin is packaged and how its translations are distributed; follow the maintainer’s documented path when one is supplied.
Keep the text domain in the filename consistent with the domain used in the plugin code. A correctly translated catalog with the wrong domain or locale filename will be ignored.
Make sure JavaScript is internationalized too
Translating PHP strings does not translate text generated in the browser. Every user-visible JavaScript string should be wrapped in a WordPress i18n function, and the script must register its translation file.
Rank #4
What the plugin code needs
- Use WordPress JavaScript internationalization functions for labels, notices, errors, and other visible strings.
- Call
wp_set_script_translations()for the relevant script handle. - Use the same text domain as the plugin’s PHP code and translation catalog.
When these pieces match, WordPress can load a corresponding JavaScript translation from the project’s language data when one exists. If a screen remains partly English, inspect the browser-generated interface as well as the PHP templates.
Install or update a language pack with WP-CLI
For a directory plugin, WP-CLI can install a plugin language pack with:
wp language plugin install <plugin> <language>
Replace <plugin> with the plugin identifier and <language> with the required locale. The command installs the available language pack; it does not create missing translations or fix strings the plugin has not marked for translation.
Verify the translation on the whole site
Set the site language in WordPress settings, install the relevant language pack when appropriate, and then test every place the plugin can display text:
- Plugin settings and administration screens
- Frontend widgets, shortcodes, blocks, and templates
- Validation errors, notices, and fallback messages
- Email subjects and message bodies
- JavaScript dialogs, menus, and dynamically loaded content
- Plural messages, dates, numbers, and strings containing placeholders
Check the site using the intended locale, not only the language used by the administrator account. If some strings remain English, determine whether they are untranslated, hard-coded without an i18n function, loaded from JavaScript without script translations, or associated with a different text domain.
Apply security and review checks
Escape translated output
Translated text is inserted into the application’s output, so escape it in the context where it is rendered. Use the appropriate WordPress escaping function for HTML, attributes, URLs, or other output contexts rather than treating a translation as trusted markup.
Keep URLs out of translatable strings
Do not put a raw URL inside an internationalized sentence. Use a placeholder and supply the URL separately. A malicious or mistaken translation could otherwise replace the destination with a different URL.
Review contributions before release
Treat submitted translations as untrusted input until a maintainer or other reviewer checks them. Look for altered placeholders, unexpected HTML, changed URLs, broken plural forms, and wording that could mislead users in an administrative or security message.
Quick Recap
Troubleshoot strings that stay in English
The entire catalog is ignored
- Check that the filename uses the exact text domain and locale.
- Confirm that the MO file was compiled from the PO file you edited.
- Verify that the files are in the plugin’s expected
languagesdirectory or inwp-content/languages/plugins. - For a WordPress.org plugin, confirm that the text domain matches the plugin slug.
Only some strings are untranslated
- The source string may not be wrapped in a PHP or JavaScript i18n function.
- The string may come from a separate JavaScript bundle without
wp_set_script_translations(). - The catalog may contain a different spelling, punctuation, or capitalization from the string emitted by the plugin.
- A plural or placeholder entry may be incomplete.
The translation appears, but the page is broken
- Compare every placeholder with the original entry.
- Check plural indexes and the number of translated forms.
- Inspect translated HTML and attributes for unescaped or unbalanced markup.
- Review any URL supplied through a placeholder rather than embedding it in translated text.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
