HelpWP is fully translatable. Every user-facing string passes through __() / _e() / esc_html_e() with the text domain helpwp, and a translation template is bundled with the plugin.
Plugin header values
Text Domain: helpwp
Domain Path: /languagesThese tell WordPress where to look for translation files when a non-English locale is active.
The .pot file
The translation template is at languages/helpwp.pot. Hand it to a translator, or open it in a tool like Poedit or Loco Translate; both produce the matching .po and .mo files for your target locale.
File naming
WordPress expects translation files in the languages/ folder, named with the locale:
languages/helpwp-fr_FR.po
languages/helpwp-fr_FR.mo
languages/helpwp-de_DE.po
languages/helpwp-de_DE.mo
languages/helpwp-bn_BD.po
languages/helpwp-bn_BD.moThe .mo is the compiled binary – that is what WordPress actually loads. The .po is the human-editable source.
Regenerating the .pot
If you maintain a fork or you want to refresh the template after a code change, run:
composer run-script makepotThis calls wp i18n make-pot . languages/helpwp.pot --exclude=node_modules,release,tests under the hood. WP-CLI is required for the script to work.
Loading translations
Translations load automatically when WordPress detects a matching locale in Settings -> General -> Site Language. Switching the site language to French (for example) and refreshing the admin should show all HelpWP strings translated, provided languages/helpwp-fr_FR.mo exists.
Per-user translations
Individual users can pick a different language in Users -> Profile -> Language. HelpWP respects this; an admin reading WordPress in French still sees the plugin in French even if the site default is English.
Translating front-end JS strings
A small number of strings in assets/admin/js/ai.js and assets/common/js/init.js are hard-coded English. These are admin-only labels (button states like Generating…, Copied!) and are not currently localized. If you need them translated, edit the JS file directly.
Was this doc helpful?