An agency pitches a client on a new site. Everything about the brief fits, design, CMS, timeline, until the client mentions, almost as an aside, that the site needs a German version by Q2 and Spanish is “probably coming.” That single sentence has killed more theme decisions than any pricing conversation.

If the theme hasn’t been checked against WPML or Polylang, the honest answer is “we don’t know yet.” Agencies don’t like shipping that answer to a client who’s already signed.

Brndle is a free, open-source WordPress theme built on Sage, Acorn, Blade templates, Tailwind v4, and Vite, a developer-facing stack, not a page-builder product. That architecture is exactly why the WPML/Polylang question comes up constantly for agencies evaluating it. Blade is unfamiliar to a theme reviewer skimming a repo (if the compiled-view behavior is new to you, see our walkthrough of Acorn’s view cache first), and “does it work with my translation plugin” is rarely answered by a README line.

So we went into the brndle-themes/brndle repository directly, the version on the main branch at the time of writing, 2.3.11, and checked. No marketing claim, no assumption carried over from how other themes behave. This is what’s there, what isn’t, and what you still have to verify yourself before a multilingual client site goes live.

Six blocks need a one-time string scan. Zero blocks need a theme fork. That’s the whole verdict, everything after this is the evidence.

In This Article

Why multilingual compatibility is a dealbreaker, not a nice-to-have

Multilingual isn’t an edge case in agency work, it’s closer to a default requirement for anyone building for a client with customers in more than one country. Switzerland alone makes a monolingual site a non-starter. Belgium, Canada, most of the Gulf, and a large share of EU-based B2B companies all expect at least a second language before launch, even if it ships empty on day one.

WPML and Polylang between them power the overwhelming majority of multilingual WordPress installs. WPML is a paid, long-established plugin with deep page-builder and WooCommerce integrations. Polylang has a large free tier plus a Pro version that adds the same class of features. We’ve covered the broader plugin landscape in our roundup of WordPress translation plugins; this piece goes one level deeper, into how one specific theme’s code actually behaves under the two most common choices. An agency that picks a theme without knowing how it behaves under either one is making a bet it can’t quantify.

The failure mode is rarely total breakage. Content usually translates fine, because post content is content, WPML and Polylang both work by duplicating or linking posts, not by hooking into a theme’s rendering layer. What breaks, when it breaks, is the thin layer of text the theme itself prints: a “Read more” link, a form’s success message, a button’s default label.

Those strings live in PHP, not in the post. If a theme didn’t wrap them for translation, they show up in English on every single language version of the site. That’s the failure a client notices in week one of a French or German rollout, and it’s the one this piece is built to pin down for Brndle specifically.

What WPML and Polylang actually require from any theme

Strip the marketing language from both plugins’ documentation and the technical bar for a “compatible” theme is the same short list, because both plugins solve the same problem the same general way: content lives in wp_posts and gets duplicated or linked per language; everything else, theme UI strings, widget text, menu labels, has to be registered separately.

RequirementWPMLPolylang
Theme UI strings wrapped for translation__() / _e() with the theme’s text domainSame baseline, __() / _e() or pll_register_string()
Where those strings get translatedString Translation module (scans theme files)Languages → Strings translation screen
Custom field / meta translation configwpml-config.xml (recommended)Meta box filters, no bundled config file convention
Hreflang tagsCan be generated by WPML core or by the themeGenerated natively by Polylang itself, theme-independent
Language switcherShortcode / widget / menu itemBlock / widget, ships its own

What WPML expects

  • Standard WordPress i18n functions. Every user-facing string in theme PHP wrapped in __(), _e(), esc_html__(), or equivalent, with a declared text domain matching the one in the theme’s style.css header.
  • String Translation for anything outside post content. WPML’s String Translation module scans theme and plugin files for those wrapped strings and lets a translator supply a value per language, independent of the post/page translation workflow.
  • A wpml-config.xml file (recommended, not required). This tells WPML which custom fields and widgets should be translated, copied, or left alone by default, so a site owner doesn’t have to configure every meta key by hand the first time they add a language.
  • Hreflang tags and a language switcher placed somewhere in the template. WPML can generate hreflang output itself at the core level, but a theme that prints its own is expected to do it correctly, one tag per language, pointing at the actual translated URL.

What Polylang expects

  • The same i18n baseline. Polylang’s free “Strings translation” screen (Languages → Strings translation) works the same way as WPML’s String Translation: it picks up strings registered through pll_register_string() or, for many themes, simply scans for standard __()/_e() calls under the theme’s text domain.
  • Clean separation between content and chrome. Polylang duplicates posts per language and expects the theme to pull content through normal WordPress template functions rather than hardcoding post data, anything non-standard there breaks per-language output.
  • A theme that doesn’t fight the language switcher. Polylang ships its own switcher widget/block; a theme header that already hardcodes a nav structure can conflict with where that switcher needs to render.
  • Hreflang, same as WPML. Polylang (both free and Pro) emits its own hreflang tags on the frontend independent of the active theme. A theme adding its own on top needs to avoid duplicating that output.

Notice what’s absent from both lists: neither plugin cares what templating engine generated the HTML. WPML and Polylang operate on the database layer, WP_Query, post meta, taxonomy, and on the final rendered output for things like hreflang and the switcher. A theme built on Blade that compiles down to ordinary HTML is invisible to either plugin at that level; they don’t know or care that Blade was involved. The question that actually matters is the one both lists converge on: did the theme wrap its own UI strings, and did it leave the content layer alone.

Brndle’s architecture, checked against those requirements

We pulled the brndle-themes/brndle repository directly and read the relevant source rather than relying on the README’s one-line compatibility claim. Everything below is labeled by how we know it:

  • Confirmed, we read the exact code or file.
  • Inferred, it follows from standard WordPress/Gutenberg mechanics given what’s confirmed, but we have not run it against a live WPML or Polylang install.
  • Untested, there is no evidence either way and you should verify it yourself.

Confirmed, from the source

The theme declares itself translation-ready: style.css sets Text Domain: brndle and includes translation-ready in its theme tags. Standard i18n functions are used throughout core theme files, navigation menu labels in app/setup.php, fatal-error messages in functions.php, and the admin settings panel’s color and font labels in app/Settings/ColorPalette.php and app/Settings/FontPairs.php are all wrapped in __('Label', 'brndle').

There is a dedicated WPML/Polylang compatibility class. Here is the actual logic, in full, from app/Compatibility/WPML.php:

add_action('wp_head', function () {
    if (! function_exists('icl_get_languages') && ! function_exists('pll_the_languages')) {
        return;
    }

    if (function_exists('icl_get_languages')) {
        $languages = icl_get_languages('skip_missing=0');
        if ($languages) {
            foreach ($languages as $lang) {
                printf(
                    '<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
                    esc_attr($lang['language_code']),
                    esc_url($lang['url'])
                );
            }
        }
    }
}, 1);

Read closely, that function checks for Polylang’s presence but doesn’t act on it. The early-return guard clears when either WPML or Polylang is active, but the actual hreflang-printing logic is gated on function_exists('icl_get_languages') only, which is WPML’s function. On a Polylang-only install, the hook runs, clears the guard, and then prints nothing.

In practice this is low-stakes: Polylang (both free and Pro) already prints its own hreflang tags on the frontend independently of the active theme, so a Brndle site running Polylang alone still gets correct hreflang output, just from Polylang itself, not from this theme hook. Worth knowing if you’re auditing the theme’s code rather than its rendered output, but not something a site owner will notice.

No wpml-config.xml ships with the theme, we checked the repository root directly and the file doesn’t exist. WPML will fall back to its defaults for any custom fields Brndle’s settings system uses.

Brndle currently ships 20 native Gutenberg blocks, not the 14 the README’s prose still describes, the README text is stale relative to the blocks/ directory, which lists card-grid, code, comparison-table, content-image-split, cta, faq, features, hero, how-it-works, lead-form, logos, post-feed, pricing, pull-quote, stats, tabs-accordion, team, testimonials, timeline, and video-embed. All 20 register through BlockServiceProvider the same way a custom 21st block you add yourself would.

Block content, the stuff an editor types in, travels as ordinary post content. Every block’s editable fields (FAQ questions and answers, pricing plan names, testimonial text) are stored as block attributes inside post_content, exactly like a core Paragraph block’s text. That’s the same layer WPML’s Advanced Translation Editor and Polylang’s post duplication already operate on.

Six of the 20 blocks bake theme-level UI strings directly into their Blade views, separate from the editable block content. We checked every block’s Blade template for __() calls that print hardcoded, non-editable strings. Here’s the exact inventory:

hero.blade.php              "Works with"
pricing.blade.php           "Billing period", "Save more",
                             "Most Popular" (×2), "Get Started"
video-embed.blade.php       "Video" (×2),
                             "Add a video URL in the block settings"
code.blade.php               "Copy code to clipboard", "Copy", "Copied",
                             "Code block: %s" (dynamic)
content-image-split.blade.php  "Add an image URL"
lead-form.blade.php         "Thank you! Your submission has been received.",
                             "Sending…",
                             "Something went wrong. Please try again."

All of them use the brndle text domain, so they’re technically translatable, but they live in theme PHP, not in the block’s saved attributes, which has a direct consequence: they won’t travel with the post when you translate it. They need a separate, one-time pass through each plugin’s string-translation tool.

Finally: there’s no evidence of actual WPML or Polylang testing by the Brndle team. No certification badge, no CI job referencing either plugin, no changelog line claiming a tested install, and no test file in the repository that exercises WPML or Polylang code paths. The README’s “Automatic hreflang tags” line under Plugin Compatibility is the entirety of the project’s own compatibility claim.

Inferred, from standard WordPress architecture

Baseline content translation should work the same as it would on any other block theme. Because Blade compiles to plain HTML before it ever reaches the browser, and because Brndle’s blocks register through the standard register_block_type() / render_callback path rather than a custom non-standard renderer, WPML and Polylang have no reason to behave differently on a Brndle site than on a default block theme. This is architectural reasoning from reading the code, not a result from running the plugins, see the setup section below for how to actually confirm it.

The six blocks’ hardcoded UI strings need explicit setup, not special treatment. Because those strings are registered with the standard brndle text domain, they should surface in WPML’s String Translation scanner and in Polylang’s Strings translation screen the same way any other theme’s hardcoded strings do. What we can’t confirm without running the scan ourselves on a live install is whether every single one gets picked up cleanly on the first pass, or whether some need a manual “register string” step.

Untested, verify yourself before launch

  • Whether a WPML or Polylang scan actually surfaces all the Blade-embedded strings listed above on the first pass, or whether any need to be added manually through each plugin’s string-registration API.
  • Whether the admin-only settings labels (color preset names, font pair names) ever need multilingual treatment on a given site, by default they’re only visible in the Brndle admin settings panel, not on the public frontend, so they’re a low priority unless a site customizes that.
  • Whether running both WPML’s and Polylang’s native hreflang output alongside Brndle’s own WPML-triggered hreflang tag produces duplicates in any edge case (multisite, subdomain language mapping, custom hreflang filters from an SEO plugin).
  • Behavior with WooCommerce + WPML/WCML together, since Brndle also ships WooCommerce compatibility and that three-way combination isn’t covered by anything in the repository.

Setting up and testing WPML with Brndle

  1. Install and activate WPML (Core + at minimum the String Translation add-on) alongside Brndle on a staging copy of the site, never test a new language configuration on production first.
  2. Run the WPML setup wizard and add at least one secondary language. Confirm the default language matches your site’s existing content language.
  3. Translate a page that uses at least three different Brndle blocks, a good test is a landing page with brndle/hero, brndle/pricing, and brndle/faq. Use WPML’s Advanced Translation Editor rather than duplicating manually, so block attributes translate as a unit.
  4. Check the rendered translated page for the hardcoded strings list above. Specifically: does the pricing block’s “Get Started” button and “Most Popular” badge show in the translated language? If not, that string needs registering.
  5. Go to WPML → Theme and Plugins Localization and run a scan of the Brndle theme files. Confirm the six Blade-embedded strings identified in this piece show up in the scan results, then supply translations for each through String Translation.
  6. View source on both language versions and confirm one hreflang link tag per language, each pointing at the correct translated URL, this is Brndle’s own app/Compatibility/WPML.php hook firing, not WPML core, so it’s worth checking directly rather than assuming it matches WPML’s own hreflang behavior exactly.
  7. Test the admin settings panel (color scheme, font pair, header style) under each active WPML language context to confirm nothing in brndle/v1/settings breaks when a secondary language is active as the admin’s working language.

Setting up and testing Polylang with Brndle

  1. Install Polylang (free or Pro) on the same kind of staging copy, and run its setup wizard to register your languages.
  2. Duplicate the same test landing page (hero + pricing + FAQ blocks) into a second language using Polylang’s “add new translation” flow from the post list.
  3. Confirm the translated blocks render with translated content for every editable field, question/answer pairs in the FAQ block, plan names in pricing, since those live in post content and should carry over cleanly through Polylang’s standard duplication.
  4. Go to Languages → Strings translation and search for the six hardcoded strings identified above (start with “Get Started” and “Copy code to clipboard”, those are the most visible on a typical landing page). If Polylang’s scanner doesn’t surface a given string automatically, that’s a signal it needs registering through pll_register_string(), a one-line addition a developer can make in a child theme or small companion plugin, not something that requires forking Brndle itself.
  5. View source on the translated page and confirm Polylang’s own hreflang tags are present and correct. Since Brndle’s own hreflang hook does not fire for Polylang-only installs, you’re checking Polylang’s native output here, not Brndle’s.
  6. Place the Polylang language switcher (block or widget) in the header or footer and confirm it doesn’t collide visually with Brndle’s existing header styles, test this across at least two of the eight header styles, since they lay out nav elements differently.
  7. If using Polylang Pro’s media translation, confirm it behaves correctly with block image attributes (hero background, logos block) that reference an attachment ID directly.

Known unknowns: what to verify before a client launch

None of what follows is a known defect, it’s the list of things nobody has published a tested answer for, Brndle’s own team included, as far as the public repository shows:

  • Whether the brndle/v1/settings REST endpoint’s data (color, font, header/footer config) needs any per-language variation on a site where different language versions want different branding, by design, Brndle’s settings are site-wide, not per-language.
  • Long-term behavior of the AI landing-page generation feature (/brndle-pages) on a multilingual site, it’s unclear from the repository whether generated pages are language-aware or need to be generated once per language.
  • Whether a future Brndle release will add Polylang-specific hreflang output or a bundled wpml-config.xml, neither is present as of 2.3.11, and there’s no roadmap reference to either in the public repo.
  • Performance impact of running String Translation or Strings translation scans against a site with many of the heavier blocks (pricing, comparison-table) on pages with dozens of block instances, not tested here, flagged for anyone running at scale.

FAQ

Does Brndle officially support WPML and Polylang?

Brndle’s README lists “WPML / Polylang – Automatic hreflang tags” under Plugin Compatibility, and the theme ships a dedicated compatibility class for it. There is no certification, badge, or published test report from the Brndle team beyond that one line, what you’re reading here is an independent source-code assessment, not an official compatibility statement.

Will my page content translate correctly without any extra setup?

Based on Brndle’s architecture, standard Gutenberg blocks with attributes stored in post content, rendered through a standard render_callback, content translation should work the same as on any other block theme. This is an architectural inference from reading the code, not a tested result; test it yourself with the walkthroughs above before relying on it for a client site.

What specifically needs manual configuration?

Six of Brndle’s 20 blocks (hero, pricing, video-embed, code, content-image-split, lead-form) print hardcoded UI strings, labels like “Get Started,” “Copy,” or the lead form’s status messages, directly from theme PHP rather than from editable block content. Those need to be picked up by WPML’s String Translation or Polylang’s Strings translation screen and translated per language; they won’t travel with the post the way question/answer text in an FAQ block does.

Does Brndle generate hreflang tags automatically?

For WPML, yes, confirmed in app/Compatibility/WPML.php, which loops through icl_get_languages() and prints a tag per language. For Polylang running without WPML also active, the theme’s own hook doesn’t currently emit anything, but Polylang generates its own hreflang tags natively regardless of the active theme, so the site still gets correct hreflang output, just not from Brndle’s code.

Is there a wpml-config.xml file bundled with the theme?

No. We checked the repository root directly and it isn’t present. That means WPML falls back to its own defaults for anything Brndle-specific rather than following theme-supplied preferences.

Does the admin settings panel (colors, fonts, header style) need translation?

The preset labels (color scheme names, font pair names) are wrapped in standard WordPress translation functions, but they’re only displayed inside the Brndle admin settings UI by default, not on the public-facing site. Unless a specific implementation surfaces them publicly, they’re a low-priority translation item.

Will the language switcher fit into Brndle’s header styles?

Not verified across all eight header styles in this assessment. Brndle’s headers (Sticky, Solid, Transparent, Centered, Minimal, Split, Banner, Glass) lay out navigation differently enough that a switcher placed via WPML’s or Polylang’s standard widget/block/menu-item method should be checked against whichever header style the client site actually uses.

Does this apply to Brndle’s WooCommerce compatibility too?

Brndle ships separate WooCommerce compatibility (gallery zoom, lightbox, theme-consistent wrappers) alongside its WPML/Polylang hook, but the three-way combination of Brndle + WooCommerce + WPML’s WooCommerce Multilingual add-on isn’t covered anywhere in the public repository. Treat it as untested until you’ve run it yourself.

Is Polylang Pro any different from the free version for this purpose?

The core mechanics covered here, Strings translation, post duplication, native hreflang output, are available in Polylang’s free tier. Polylang Pro adds features like translated media and a more advanced translation workflow UI, which may interact with Brndle’s media-picker-based blocks (logos, team, testimonials) in ways not covered by this assessment.

Should an agency avoid Brndle for multilingual client projects?

Not based on what we found. The theme follows standard WordPress i18n conventions in its core files, has a working (if WPML-only) hreflang hook, and doesn’t do anything architecturally hostile to either plugin. The honest caveat is that six blocks need a short, one-time string-translation setup step, there’s no bundled WPML config file, and nobody has published a tested result on a live multilingual install. For an agency, that translates to: budget a half-day of setup and QA per plugin before launch, not a blocker to picking the theme.

Conclusion

The useful finding here isn’t “Brndle is WPML compatible” or “Brndle is not WPML compatible”, it’s the specific, checkable list in between. Post and page content, including everything typed into Brndle’s 20 blocks, should translate the way any standard Gutenberg content does, because it’s stored and rendered the same way.

Six blocks carry hardcoded theme strings that need one pass through String Translation or Strings translation before a second language looks finished. The theme’s own hreflang hook only fires for WPML today, though Polylang covers itself natively either way. And there’s no shipped wpml-config.xml, no certification, and no published test report, just source code you can read yourself, which is what we did here.

If you’re evaluating Brndle for a multilingual client build, the walkthroughs above are the actual acceptance test: duplicate a landing page with a few different blocks, run the string scan, check the rendered hreflang, and look at the result instead of the README. That’s a half-day of QA, and it’s the same half-day you’d want to spend on any theme before putting a client’s second language in front of real traffic.