WPML Compatibility thread

Hi Bricks team,
we are working on several project a year that requires WPML. (80% of our website are bilingual). We see that WPML is on the roadmap and we understand that you have a lot of stuff to work on with hundreds of request!

However, after spending at least 15 hours testing Bricks & WPML, we haven’t found any major incompatibility. We tested:

  • Different header/footer for different language (Menu is simply the WP menu which is automatically translated)
  • Regular page translation
  • Archive page translation
  • Custom post type archive & single post translation
  • Slug structure… etc.

Archive & single template don’t need to be duplicated and the correct content (from the post itself or acf fields) show on front-end. The only reason why we would need to duplicate/translate the Bricks template itself is if you have hard coded text (non-dynamic) in the template. For this, we simply use the wpml-icl-language-code condition in a code block (and we custom code the content, not using the Brick UI).

My question is:

**Is there something important we missed? What’s missing to make Bricks officially compatible that we should be aware of? It would be great if you could confirm what are the issue preventing Bricks & WPML official compatibility **


Hi there,

I’m in a very similar situation as John. Please let us know if there is any incompatibility between WPML and Bricks.

Thank you,

@thomas it would be awesome if you could just confirm if there is anything major regarding WPML compatibility :pray:

Just curious. Why do you prefer WPML instead of Translatepress?

@albertvisuals Because Translatepress is string based. If you change a single caracter in a sentence, you loose the entire translation in the second language. That’s a nightmare when you just want to correct a typo, or if the client update the site a couple times a year.

Also, Translatepress doesn’t allow us to use different content in the second language. (ex: Add a new section in the second language).

1 Like

Thanks for the insight. Would be wiser to use WPML for the future then.

Hi @JohnF! Just wanted to write to know if, after the time since you wrote this first post, you have found any issue regarding WPML and Bricks compatibility. I’ve tested myself, all seems good, but just checking if you found something I missed.

Thank you in advance.

Hi @websalia, we are completing a project using WPML and Bricks - launching thursday. (no ecommerce). There is no major issue. We are manually translating each post (not using WPML advanced translation editor).

For templates (Archive, single, etc.) we built only one template and we show the correct information conditionally using a custom condition based on a class. (Same for Header & footer)

1 Like

Hi @JohnF , OK, thanks for the details. Is great to know that it seems to be compatible by default with WPML, even if it isn’t officially.

Thank you!

Hi @JohnF, for pages are you just using WPML’s string translation to maintain styling?

No, we are simply duplicating the pages. I do not like to use String translation because if you change juste 1 caracter in the original language, then you loose the whole translation….

Also, content created using string translation can’t be exported if you ever decide to change your builder 3 years from now…

Which conditions you use for your templates?

1 Like


Anyone knows how to show one element based on language page condition?

I am building a multilingual site with WPML. The header has been handled very well, as Bricks+WML are showing the proper menu in each language. But I need to translate a small text on the header manually, and I would like to do it via a condition.

I would like to get something like this, but in Bricks Builder and with WPML: Polylang condition in Oxygen: how to use one template for different languages

Is that possible?

Thanks!! :slight_smile:

Insert this PHP code into your functions.php and then you will have the ability to select Dynamic data > WPML Language Slug in your condition settings. From there, use the language slugs to show or hide the element.

Hi @zestjosh!

Thanks for your help!

I have followed your instructions, but it is not working for me. So I may have done something wrong!

Here is my step by step:

1 - I have uploaded your code via WPCodeBox as a PHP snippet and enabled it:

2 - Then I have edited my footer template, and add three text blocks. One is for English, another one for French and a last one for Catalan. Catalan is the main language, and the other two are translations.

3 - I have set a condition on the English version, like this:

4 - I have also done this for the French version and the Catalan one:

When looking in the frontend, all I see is the Catalan version.

Any ideas of what I am doing wrong?


Based on the last screenshot, the issue may be that the conditions are set to OR instead of AND. Try hitting the + button at the bottom of the first condition and recreate the second condition ({wpml_language_slug} != fr) and then remove the last condition.

Hi @zestjosh !

Thanks for trying to help me out!

I have changed the OR condition to and AND condition, but in the frontend I am having the same (wrong) result.

The Catalan version is the one that have the AND condition to show this text when the wpml_language_slug is not ‘fr’ nor ‘en’:

The English text has the condition to show when the wpml_language_slug == en, and the French text when the wpml_language_slug == fr.

However, in the frontend I am still only getting the Catalan text in all three versions of the website (Catalan, English and French).

Any ideas?

Thank you!!

Could you try putting {wpml_language_slug} inside of a Basic Text element to ensure that it is working properly? Additionally, you could try switching the statements to check if {wpml_language_slug} == ca

I added {wpml_language_slug} inside a Basic Text and it is not working:

I have tried it in a Template and in a Page, and it does nothing. Also I have added your php code into functions.php on my child theme, instead of using WPCodeBox, but nothing changes :confused:

I just reviewed the code in my Gist and realized that a piece was missing and I just added lines 42-48! Sorry about that, just update the code and it should work as expected now.