Platform guide
How does Smart Add-Ons WPML and Polylang translation actually work under the hood?
Every add-on string — group names, field labels, option text — routes through one generic filter, saue_translate_string, which the plugin never assumes a specific translation tool implements. WPML and Polylang each hook that same filter with genuinely different strategies: WPML registers strings once by context and name and looks them up by that same key, while Polylang has no persistent registration at all and re-registers every string from scratch each time its own Translations admin page loads, looking translations up by the original text instead. Translation only ever applies on the storefront, cart, checkout and order — the admin group editor and CSV exports always show the original source text, on purpose.
Smart Add-Ons WPML and Polylang translation support is built around one small, deliberately generic filter rather than two bolted-on integrations — this is exactly how that filter gets used differently by each plugin, read directly from StringTranslator.php, WpmlIntegration.php, and PolylangIntegration.php.
One filter, no assumptions about which tool is active
Every translatable string — a group name, a field label, an option value — passes through exactly one filter before it reaches the storefront:
$translated = apply_filters( 'saue_translate_string', $value, $context, $name );With no multilingual plugin active, nothing hooks this filter and the original string passes straight through. This is what lets the same core plugin support WPML and Polylang without either being a hard dependency, and it’s the same extension point documented in the PHP hooks guide for a custom translation layer of your own.
Smart Add-Ons WPML and Polylang translation: WPML registers once, permanently
WPML’s integration registers each string once, by context and name, using WPML’s own real string-translation API:
do_action( 'wpml_register_single_string', $context, $name, $value, false, $language );
// ...
$translated = apply_filters( 'wpml_translate_single_string', $value, $context, $name );A genuinely subtle correctness detail is handled explicitly: add-on strings are written in the site’s default language, which isn’t necessarily the language WPML’s String Translation module considers its own default. The code resolves wpml_default_language and passes it into registration explicitly, rather than silently assuming English. There’s also a one-time backfill (backfillExistingGroups(), hooked to admin_init) for groups created before WPML String Translation was ever activated — gated by a version-stamped option so it registers every existing group exactly once, and specifically waits for WPML_ST_VERSION to be defined so it doesn’t mark the backfill “done” while only WPML core (not the String Translation submodule) is active.
Polylang: no persistent registration, re-registered on demand
The Polylang integration’s own doc comment states the constraint plainly: “Polylang does not store registered strings: pll_register_string() must run on the request that renders or saves Languages → Translations.” So rather than registering on save like WPML, it re-registers every string from every group, but only when that specific admin page is actually being loaded:
if ( $page !== self::STRINGS_PAGE ) { // 'mlang_strings'
return;
}
foreach ( $groups as $group ) {
foreach ( StringTranslator::collectStrings( $group ) as $string ) {
pll_register_string( $string['context'] . ': ' . $string['name'], $string['value'], 'Smart Add-Ons', ... );
}
}Translation lookup is also fundamentally different from WPML’s — Polylang doesn’t use context or name at all, only the original text:
public function translate( string $value, string $context, string $name ): string {
return function_exists( 'pll__' ) ? pll__( $value ) : $value;
}Because nothing is persisted between requests, a deleted field or option simply stops being registered the next time the Translations page loads — Polylang’s own “Clean strings translation database” option is what removes the now-orphaned translations, rather than this plugin needing an explicit unregister step the way WPML’s integration does with icl_unregister_string.
What never gets translated: the admin editor and exports
StringTranslator‘s own file header states this explicitly: strings are translated “only for storefront, cart, checkout and order contexts… Admin and export payloads always carry the original strings so the group editor never saves a translation back over the source text.” That’s a deliberate safeguard — without it, an admin editing a group while viewing the site in a secondary language could accidentally overwrite the original source text with a translated copy on save.
Common questions
Does this require WPML or Polylang's premium tiers?
The WPML integration specifically checks for WPML_ST_VERSION, meaning it depends on the String Translation module rather than WPML core alone. Polylang’s string translation is part of the free plugin itself, with no separate module required — a real, checkable difference in what each side of Smart Add-Ons WPML and Polylang translation actually needs installed.
What happens with both WPML and Polylang active at once?
Both integrations hook the same saue_translate_string filter, so whichever one registers last would run last and its return value would win — an unusual, unsupported site configuration in general, since running two multilingual plugins simultaneously isn’t a combination either plugin itself typically supports. Smart Add-Ons WPML and Polylang translation is built to work with exactly one active at a time, not both together.
For the full PHP hook list this translation filter is part of, see the hooks guide, and WPML’s own String Translation API documentation (opens in new tab) for the wpml_register_single_string function referenced above.
Comments