Hey everyone,
I’ve been experimenting with dynamic routing lately and wanted to share a lightweight approach to building multilingual sites, while also getting your thoughts on this architecture.
We all know how heavy traditional translation plugins (like WPML or Polylang) can be. They often create massive database overhead by constantly querying locales on every single page load, bloat the wp_posts table, and sometimes introduce layout conflicts with modern page builders.
To bypass all that third-party bloat, I built a Zero-Plugin Multilingual Architecture leveraging WordPress Multisite (Sub-directories) and Custom Fields (SCF/ACF).
Why this route?
-
Blazing Fast Performance: Uses native WordPress routing with zero locale-filtering overhead.
-
Isolated Databases: Each language gets its own clean database tables (e.g.,
wp_2_posts), making it incredibly stable for enterprise-level scale. -
100% Native Bricks workflow: No translation plugins messing with the canvas. Your translation team can edit text directly on the native Bricks interface per sub-site.
-
Automated Technical SEO: Includes native
<link rel="alternate" hreflang="...">injection into the<head>.
I have documented the complete step-by-step setup—including the .htaccess routing rules, custom field mapping, and the exact custom PHP engine to handle the dynamic language switcher and Bricks RCE whitelist—on GitHub:
GitHub Repository: GitHub - lubisnudin/bricks-zero-plugin-multilingual: A lightweight, zero-plugin multilingual implementation for WordPress Multisite and Bricks Builder. · GitHub
Let’s Discuss!
Obviously, this approach has its trade-offs. For instance, it’s probably not ideal for e-commerce sites running global shared inventories (WooCommerce).
I’d love to hear your feedback on this: Do you think this is a cleaner, more sustainable route for corporate/portfolio Bricks sites, or is managing a Multisite overkill compared to just using a plugin? What’s your go-to stack for handling multilingual sites in Bricks?
Let’s talk! 