Using the Integrations Directory with WPML or Polylang

The Integrations Directory plugin stores your integrations as standard WordPress content. It does not ship any built-in translation features, language switcher, or wpml-config.xml file. That is good news for multilingual sites: because everything is ordinary WordPress data (a public custom post type, a public taxonomy, post meta, a shortcode, and a few option strings), you can run a fully multilingual directory by pairing the plugin with a dedicated translation plugin — either WPML or Polylang. The translation plugin does the translating; the Integrations Directory plugin simply serves whichever language’s content is active.

This article explains, honestly and practically, what needs translating and how to wire it up with each plugin.

What actually needs translating

A complete multilingual directory has several moving parts. The translation plugin (not the Integrations Directory plugin) handles every one of them:

• The integration posts — the title, body, and logo (featured image) of each entry, plus its two custom fields (Preview Text and Website URL).
• The Categories — the terms in the integration_category taxonomy that group your directory.
• The Custom Filter’s criteria — the terms in the integration_criteria taxonomy. This one is special and gets its own section below.
• The directory page — the WordPress page that holds the [integration_directory] shortcode.
• The Settings strings — the Custom Directory Title, the Description, the Custom Filter’s display name, and the Back-to-Integrations URL. These are site-wide option strings, not per-language by default.
• A language switcher — so visitors can move between languages. This comes entirely from WPML or Polylang; the plugin does not provide one.

How the pieces map to translation

Before diving into either plugin, it helps to understand how each piece is stored, because that determines how it gets translated.

• Integrations are a standard public custom post type (integration, URL /integrations/{slug}) supporting title, editor body, and featured image. Both WPML and Polylang can translate it once you enable that post type as translatable.
• Categories are a standard public, hierarchical taxonomy with an admin UI. Both plugins translate it term by term, and each translated term gets its own per-language slug — an important detail for the shortcode.
• Custom Filter criteria are a taxonomy registered hidden (not public, no admin UI, not in REST). Because of that, the translation plugins’ UIs may not list it automatically. This is the single biggest gotcha — see The Custom Filter (criteria) caveat below.
• Preview Text (_previewtext) and Website URL (_integration_website) are post meta. Each plugin lets you decide, per field, whether to translate the value or copy it across languages.
• The logo is the featured image; a translation can reuse the original image or set its own.
• The Settings are plain, single, site-wide WordPress options (saas_integration_custom_title, saas_integration_description, saas_integration_custom_url, saas_integration_filter_name). The plugin does not register them for translation, so making them multilingual takes one extra step in either plugin.
• The directory is deployed by placing the single [integration_directory] shortcode on a normal WordPress page. You translate that page, and on each language’s page the directory shows that language’s published integrations.

If you use WPML

WPML translates each piece in a different screen. Work through them in this order. Note that translating the Settings strings requires WPML’s String Translation add-on (bundled with the multilingual CMS tier); the rest works with WPML’s core multilingual features.

1. Make the Integration post type translatable

Go to WPML → Settings and scroll to the Post Types Translation section. Find Integration in the list and set it to Translatable – only show translated items (so a language only shows integrations that exist in that language), or Translatable – use translation if available or fallback to default language (so an untranslated entry still appears in the source language rather than leaving a gap). Save. The post type now appears in WPML → Translation Management so you can send entries for translation.

2. Translate the Category terms

Two steps. First, in WPML → Settings, scroll to Taxonomies Translation and set the Categories taxonomy (integration_category) to Translatable, then Save. Second, go to WPML → Taxonomy Translation, pick the taxonomy from the dropdown, and enter each term’s translated name and slug. Remember that each translated term now has its own slug.

3. Translate each integration

Open WPML → Translation Management (or use the language “+” links on the Integrations list) to create each translation. Translate the title and body, and decide whether each translation keeps the original logo or sets its own featured image.

4. Handle the Preview Text and Website URL custom fields

Go to WPML → Settings → Custom Fields Translation (historically labeled “Multilingual Content Setup”). Find _previewtext and _integration_website and set each:

• Preview Text (_previewtext) is reader-facing — set it to Translate so each language gets its own blurb.
• Website URL (_integration_website) is usually the same everywhere — set it to Copy (kept in sync on every save). If different languages should point to localized vendor pages, use Translate (or Copy once) instead.

5. Translate the Settings strings

The four Settings options are not auto-registered, so you register them as admin texts. The simplest no-XML route: go to WPML → String Translation, expand the utilities/“Not seeing strings you are looking for?” area, click Admin Texts Translation, tick the option group that holds the directory settings, and add them to String Translation. Then translate saas_integration_custom_title, saas_integration_description, and saas_integration_filter_name per language on the String Translation page.

For the Back-to-Integrations URL (saas_integration_custom_url), translate it too — but point each language’s value at that language’s directory page (see Per-language directory pages & shortcode tips), not at the default-language page.

6. Build the per-language directory page

Translate the page that holds the shortcode using its “+” translate link. Keep the [integration_directory] shortcode tag intact in the translated page — WPML’s translation editor preserves shortcodes. When the translated page renders, the shortcode runs in the context of the current language and returns that language’s integrations.

7. Add the language switcher

Go to WPML → Languages and enable a switcher in the placement you want: a menu switcher, a widget switcher, or a footer switcher. (Custom placements are also available via shortcodes such as [wpml_language_selector_widget] once you enable custom language switchers.) The switcher links each directory page to its translated counterpart.

If you use Polylang

The Polylang flow mirrors the WPML one, but the screens differ. Translating the Settings strings in Polylang requires registering them yourself, which means a small code snippet — covered below.

1. Enable the Integration post type for translation

Go to Languages → Settings, find the Custom post types and Taxonomies module, and click its Settings link. Check the box for the Integration post type, then save. (Polylang only lists post types and taxonomies registered as public — the Integration post type and Categories qualify, but the hidden Criteria taxonomy will not appear here; see the caveat section.)

2. Translate the Category terms

In the same Custom post types and Taxonomies panel, check the box for the Categories taxonomy (integration_category) and save. Each term in the Categories admin now shows a language column and the “+” translation links, exactly like core categories. Translate each term — and note that each translation gets its own per-language slug.

3. Translate each integration

On the Integrations list, use the language column’s “+” links to create each translation, then translate the title and body. When you create a new translation, Polylang copies the source post’s metadata and featured image as a starting point; you can then change the logo per language if you want.

4. Handle the Preview Text and Website URL custom fields

Polylang’s custom-field handling lives in Languages → Settings → Synchronization. Be aware of two things:

• When you create a translation, Polylang already copies all post meta (including Preview Text and Website URL) from the source as a starting point, so you can simply edit the Preview Text on each translation to localize it.
• The Custom fields synchronization toggle is all-or-nothing — turning it on keeps every meta key in sync across translations. Leave it off if you want different Preview Text per language (the usual case). If you want the Website URL to always stay identical across languages, turning sync on will enforce that — but it will also force the Preview Text to match, so most directories leave sync off and simply edit each translation.

5. Translate the Settings strings

Because the plugin does not call pll_register_string(), the four Settings options won’t appear in Polylang’s strings table on their own. Register them with a small snippet in a mini-plugin or your theme’s functions.php, hooked on the admin side:

• pll_register_string( 'integration_directory_title', get_option( 'saas_integration_custom_title' ), 'Integration Directory' );
• …and the same pattern for saas_integration_description (pass true as the fourth argument for a multiline textarea) and saas_integration_filter_name.

Then translate them at Languages → Translations (the “Strings translations” table; Administrator access required). Two practical notes: the option must already have a value before the string appears in the table (empty strings are not listed), and to make the translated value display on the front end the output must be wrapped in pll__() / pll_e() — which the plugin does not do for these options. In practice, the most reliable approach for these site-wide settings is to keep them in a language your audience shares, or to override their output via the registered string in a small snippet, rather than expecting the plugin to swap them automatically. Treat string-level translation of the Settings as an extra, optional step.

For the Back-to-Integrations URL (saas_integration_custom_url), point it at each language’s own directory page (see the tips section below).

6. Build the per-language directory page

Create a linked translation of the page that holds the shortcode, and place the [integration_directory] shortcode on each language’s page. Polylang resolves the language from the URL and serves the matching page, so each language’s page renders its own integrations — provided the post type is registered as translatable (step 1).

7. Add the language switcher

Polylang offers three ways to add a switcher: a widget (Appearance → Widgets, added via the Polylang Language Switcher / Legacy Widget block), a menu item (Appearance → Menus → add the Language switcher item; enable it under Screen Options if it’s missing), or the template tag pll_the_languages() in your theme. The switcher will not show a language that has no published content for the current item.

The Custom Filter (criteria) caveat

This is the most important section. The Custom Filter is backed by the integration_criteria taxonomy, which the plugin registers hidden — not public, no admin UI, not in REST, no rewrite. Criteria are managed on the plugin’s Custom Filter admin page and assigned per integration via a checkbox meta box.

Both translation plugins build their term-translation lists from taxonomies that are exposed in the normal WordPress admin. Because integration_criteria is hidden, it may not appear in WPML’s Taxonomies Translation list or in Polylang’s settings checklist. If you do nothing, the criterion names can show up in the directory in their original language regardless of the visitor’s language. There is no setting in the Integrations Directory plugin to change this. Here are your honest options, from simplest to most technical:

Option A — Keep criteria language-neutral (usually the best choice)

If your criteria are structural or short (think feature flags, plan tiers, or codes), the cleanest design is to not translate them at all. Use one language-neutral label that reads acceptably to your whole audience. This avoids the entire problem and keeps the filter working identically in every language. For many directories this is the right answer.

Option B — Translate the displayed labels as strings

If you only need the displayed criterion labels localized (and you don’t need separate per-language criterion archives), you can run the label text through WPML’s String Translation or Polylang’s pll_register_string() + pll__(). This is a display-only swap: it changes what visitors read, but it does not create language-specific terms or slugs.

Option C — Register the taxonomy for translation via a small snippet

If you genuinely need the criteria themselves translated as terms, you can register the hidden taxonomy with the translation plugin without changing how the Integrations Directory plugin registers it:

• WPML: add a wpml-config.xml file (in a small companion plugin or your theme) declaring <taxonomy translate="1">integration_criteria</taxonomy> — optionally with display-as-translated="1" so untranslated criteria fall back to the default language instead of disappearing. WPML reads this file automatically and the taxonomy becomes translatable even with no admin UI; translate the terms under WPML → Taxonomy Translation.
• Polylang: use the documented pll_get_taxonomies filter to add integration_criteria for language filtering while keeping it off the settings screen. The standard pattern registers the taxonomy only when Polylang is not rendering its settings list (the filter’s $is_settings argument), which is exactly right for a programmatically managed internal taxonomy.

A word of caution and honesty: do not simply flip the taxonomy to public=true just to make it appear in the translation UI — that also exposes it on the front end and in the REST API and changes query and archive behavior. The config-file (WPML) and filter (Polylang) routes are the targeted, supported ways to do this. Also be realistic: Option C is a developer task, the exact behavior depends on your specific WPML/Polylang version, and you should verify on your actual site whether the criteria appear in the translation screens before promising fully translated criteria. If in doubt, Option A is the dependable path.

Per-language directory pages & shortcode tips

The directory is just the [integration_directory] shortcode on a page, so a multilingual directory is a translated page per language:

• Translate the page, keep the shortcode. Create a translation of the page that holds [integration_directory] and leave the shortcode tag in place on each language’s page. On each language’s page the directory shows that language’s published integrations, because the translation plugin filters the main query by the current language.
• Verify the language filtering for the criteria, not just categories. Standard query filtering covers the public post type and Categories automatically. If you used Option C to make criteria translatable, double-check that criteria filter correctly per language on the live site.
• Watch the per-language term slugs. Translated Category (and, if translated, Criteria) terms have different slugs in each language. If you pass category="…" or criteria="…" to the shortcode, a hard-coded default-language slug will not match the translated term and the filtered directory can come back empty in other languages. Two reliable fixes: (1) on each language’s translated page, write the shortcode with that language’s term slug (since each page is a separate post, this is explicit and dependable); or (2) keep the term slugs language-neutral so a single slug works everywhere. The neutral-slug approach eliminates this class of bug entirely.
• Point the Back-to-Integrations URL at the right page. Set saas_integration_custom_url for each language to that language’s own directory page, so the “Back to Integrations” link never sends a visitor out of their language.
• Let untranslated entries fall back if you prefer. If you don’t translate every integration, WPML’s “use translation if available or fallback” mode (and the display-as-translated option for taxonomies) keeps the listing from showing gaps; Polylang instead simply omits items with no translation in the current language. Choose based on whether you’d rather show source-language content or hide it.

Translating the plugin’s interface

Everything above is about translating your content — the integrations, categories, and filter options you create. Separately, the plugin’s own interface strings are translation-ready: the visitor-facing labels on the directory (the search box placeholder, the “Sort by” label and the sort names, the “Load more” and result-count text), the post-type, category, and badge labels, and the block editor’s controls are all wrapped for translation under the text domain integration-directory.

To translate them, add a locale .po/.mo pair to the plugin’s /languages folder (it ships with a README and a template to start from), or use a translation plugin such as Loco Translate to generate them from the WordPress admin. Once WordPress is running in that locale, the directory’s built-in wording appears translated automatically — there is no per-string setup in WPML or Polylang.

Heads up: this is separate from WPML and Polylang. Those translate the content you enter; they do not translate the plugin’s built-in interface labels, which come from the .mo files described here. In practice you use both together: WPML or Polylang for your integrations and taxonomies, and the text-domain translations for the plugin’s own wording.

Test it

Always test the finished directory logged out, once per language. Two reasons specific to this plugin:

• The front-end directory is behind a license gate — it is hidden unless the license is valid. This is unrelated to language, but it means a logged-out check is the only way to confirm visitors actually see the directory.
• Administrators always see the directory regardless of the license state, so an admin-only check can mask a gate problem. Log out (or use a private/incognito window) and visit each language’s directory page directly.

For each language, confirm: the page resolves at its translated URL, the title/description/filter name read in the right language, the integration cards show the localized Preview Text and correct logo, the “Visit Website” button points where you expect, the category (and any criteria) filters return results, the “Back to Integrations” link stays in-language, and the language switcher moves you cleanly between the directory pages.

For related setup, see the sibling KB articles Setting Up the Integrations Directory, Using the Custom Filter, and Configuring the Directory Settings.