WordPress 6.x brought significant changes to the block editor, site editing, and core performance, and a multilingual plugin that hasn’t kept pace with those changes can quietly break translation workflows, even when the plugin itself still technically “works.” Compatibility here is about more than just avoiding a fatal error.
What Changed That Affects Multilingual Plugins
- Full Site Editing and block-based themes changed how templates and template parts are stored and translated
- Block editor improvements mean translation plugins need to correctly handle nested blocks and block attributes, not just plain paragraph text
- Performance improvements in core WordPress can be undermined by a translation plugin that hasn’t been optimized to match
- Navigation blocks and site-wide menus need their own translation handling distinct from regular page content
WPML: Actively Maintained Block and Site Editor Support
WPML has invested specifically in supporting the block editor and Full Site Editing features introduced across WordPress 6.x, including translation support for block-based theme templates and navigation blocks. For sites built on a block theme, this dedicated support matters more than it would have on an older, purely classic-theme WordPress install.
Weglot: Output-Layer Translation Sidesteps Most Block Issues
Because Weglot translates rendered page output rather than working directly with block structure in the editor, it’s largely insulated from changes to how WordPress 6.x stores blocks internally. This architectural choice means Weglot tends to keep working smoothly across WordPress core updates without needing matching internal changes for every new block type.
TranslatePress: Front-End Translation, Theme-Agnostic by Design
TranslatePress’s front-end, visual translation approach similarly works on what’s actually rendered on the page, which keeps it largely compatible with both classic and block themes without needing deep internal awareness of WordPress 6.x’s block storage format. It’s worth confirming your specific block theme renders correctly before fully committing, as with any plugin.
Checking Compatibility Before You Upgrade or Install
Before upgrading WordPress core or installing a new multilingual plugin, check the plugin’s own compatibility statement against your current WordPress version in the WordPress.org plugin directory, and test the combination on a staging site first. A plugin can be generally well-maintained while still having an edge case with your specific theme or block combination.
Full Site Editing and Template Translation
If your site uses a block theme with Full Site Editing, pay particular attention to whether your multilingual plugin correctly translates template parts (headers, footers, navigation) and not just your page and post content. This is a newer requirement that older multilingual plugin architectures, built before Full Site Editing existed, sometimes handle less completely.
WordPress 6 Compatibility Checklist
- Confirm the plugin’s stated compatibility with your exact WordPress version
- Test translation of template parts if you’re using a block theme with Full Site Editing
- Verify navigation blocks and menus translate correctly, not just body content
- Test on staging before upgrading core WordPress on a live multilingual site
- Check the plugin’s update history for recent, active maintenance
Final Thoughts
All three major multilingual plugins remain well-maintained and compatible with current WordPress releases, but the way they achieve that compatibility differs. WPML’s deep block editor integration suits sites that want tight native support for Full Site Editing, while Weglot and TranslatePress’s rendered-output approach offers a kind of built-in resilience to core WordPress changes by working at the page level rather than the block level.