Translating the plugin and the portal

Every string the plugin ships is translatable, on both the admin side and the affiliate portal, under the text domain squad-affiliate. That covers the strings written into the code — labels, buttons, email subject lines. It’s not the whole translation picture, because a programme also generates its own text: a creative’s name, a commission group’s label, a rank you invented. That third kind of text needs a different mechanism, and the plugin handles all three separately rather than pretending one mechanism covers everything.

Three kinds of text, three mechanisms#

• Strings the plugin ships travel in the standard .pot file, translated the way any WordPress plugin’s UI strings are.
• Text a merchant types into a setting — the label on a settings screen — is declared in wpml-config.xml, which WPML and Polylang both read directly out of the stored option without the plugin doing anything extra.
• Text in the programme’s own database rows — a creative’s name, a group’s label, a rank — is neither of the above: it’s not a shipped string, and no option holds it for WPML’s config file to point at. For this third kind, the plugin explicitly offers each string to WPML through wpml_register_single_string as it’s read, and asks for its translation through wpml_translate_single_string, the same public hooks WPML documents for any plugin to use. On a site with no translation plugin active these calls are simply no-ops — there’s no function_exists() guard needed, because do_action() and apply_filters() on an unregistered hook do nothing by design. Polylang answers the same hooks through its own WPML-compatibility layer, so nothing here is written twice for the two plugins.

If neither WPML nor Polylang is active, or a site runs some other translation tool entirely, a merchant-written string still has an escape hatch: the squad_affiliate_translate_merchant_string filter, for a site’s own glossary or a translation plugin the code has never heard of.

WPML and Polylang#

The plugin is WPML-compatible out of the box, through the mechanisms above. Affiliate records, referrals and payouts are not translated — they’re data, not content — but everything a person reads is: the portal, the registration form, the emails and the admin screens, plus whatever a merchant has typed into a creative or a group name.

What matters in practice is that an affiliate reads their own dashboard in their own language. A programme with affiliates in four countries is four audiences, and the portal is the screen they spend time in — the dashboard’s own page, when it has a WPML translation, is resolved to the correct language edition through the same wpml_object_id filter any multilingual site uses to find the right translated page.

Translating the emails#

Notification templates are translated like any other string, and each affiliate receives theirs in the language on their own WordPress user profile rather than the site default — the plugin switches to that specific user’s locale immediately before building the email and switches back immediately after, so one notification run sending mail to affiliates in several languages sends each one correctly rather than all in whichever language happened to be active when the batch started. An affiliate who registered with Spanish set as their profile language should not get an English payout notice just because the site’s own default is English.

Supplying your own translation#

Drop a .mo file into wp-content/languages/plugins/ named for the text domain and locale — squad-affiliate-es_ES.mo. Files there survive plugin updates, which files inside the plugin directory do not.

Currency and formatting#

Amounts are formatted with WordPress’s own locale rules, so decimal and thousands separators follow the site language. The currency itself comes from your store, not from the plugin — a multi-currency store pays commission in the currency the order was placed in.