Skip to content Skip to sidebar

This thread is resolved. Here is a description of the problem and solution.

Problem:
You are using the Next Bricks plugin for custom buttons on your website. Although the text for these buttons appears correctly in the WPML translator, the translated text does not show up on the frontend of the translated page; instead, the default text is displayed.
Solution:
The issue stems from the use of underscores in setting keys within the Next Bricks plugin files. Here is a step-by-step workaround:
1. Open the

nextbricks elements\elements\next_squeezy_radius_button.php

file.
2. Replace 'inner_title' with 'innerTitle'.
3. Edit your original page in Bricks (note that you will need to re-add the 'innerTitle' since the control changed).
4. Retranslate the page.
We recommend contacting the Next Bricks team to suggest they adjust this in other parts of their plugin as well.

This solution might be irrelevant if it's outdated or not applicable to your case. We highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the issue persists, please open a new support ticket at WPML support forum.

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: 

This topic contains 4 replies, has 0 voices.

Last updated by Dražen 3 weeks, 2 days ago.

Assisted by: Dražen.

Author Posts
November 12, 2025 at 9:36 am #17569458

denisW-4

Background of the issue:
I am using the Next Bricks plugin for custom buttons on my website. The text for these buttons appears correctly in the WPML translator along with other texts from the page. However, the translated text for the buttons does not show up on the frontend of the translated page. Instead, it displays the non-translated/default text. I contacted Next Bricks support, and they suggested reaching out to WPML support for assistance. I have tested this on a fresh WordPress installation with Bricks, Next Bricks, and WPML, and the issue persists. I also tried adding the plugin files as strings, but the button texts did, of course, not appear in the string translator. The issue can be seen on this page: hidden link

Symptoms:
The translated text for custom buttons created with the Next Bricks plugin does not appear on the frontend of the translated page. Instead, the default text is shown.

Questions:
Is this something the WPML support can help with?

November 12, 2025 at 10:08 am #17569652

Dražen
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hello,

I’ve shared the case with our 2nd tier team.

I’ll update you there as soon as I have any news.

Best regards,
Drazen

November 13, 2025 at 6:52 am #17573317

Dražen
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hello,

our 2nd tier have checked and issue is coming from plugin files.

Workaround

- Open the ...\nextbricks elements\elements\next_squeezy_radius_button.php file
- Do a search and replace to replace inner_title with innerTitle
- Edit your original page in bricks (you will need to re-add the innerTitle since the control changed)
- Retranslate the page

The authors of Next Bricks should make sure they don't use underscores in setting keys.

I advise to contact them and that they adjust this in other parts of their plugin also.

Regards,
Drazen

November 14, 2025 at 2:00 pm #17579410

denisW-4

Hi Dražen,

Thank you for taking the time and providing a full workaround for the issue! That does solve the issue of the texts not showing up on the frontend once translated.

I reported this to the Next Bricks team, and while I am not an expert developer, I have to agree with them on this; they asked if WPML could support the underscores? Instead of 'forcing' other WordPress plugins to adapt to the 'WPML-machine'.

From what I understand using underscores is not something uncommon, so other plugins/end-user might have had - or will have in the future - the same issue I do. And, this issue does not exist in other popular WordPress translating plugins.

Kind Regards,
Denis

November 17, 2025 at 6:40 am #17582403

Dražen
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hello Denis,

What you said is correct, but I did not explain the issue properly earlier, so let me try again.

Unfortunately, this is not the case here, as the issue is not caused by our code, nor does it require changes on our side. The theme that the add-on plugin is intended to work with already has this code in place, and this is simply how it integrates with WPML.

The rule/code that requires these adjustments comes from the Bricks theme itself. Since NextBricks aims to be an add-on for Bricks, it would ideally need to adapt to how Bricks handles this. Of course, they are free to contact the Bricks team to discuss this further—perhaps Bricks would be open to modifying their implementation. However, this is not something we can decide or change on our end.

The integration from Bricks /wp-content/themes/bricks/includes/integrations/wpml/wpml.php:

		// Loop over translations for this post
		foreach ( $string_translations as $string_id => $translation ) {
			// Split the string ID to extract various details (like element ID, setting key, repeater index, etc.)
			$string_parts = explode( '_', $string_id );

			$element_id  = isset( $string_parts[0] ) ? $string_parts[0] : false;
			$setting_key = isset( $string_parts[1] ) ? $string_parts[1] : false;

Hope this clear things up.

Regards,
Drazen