Hi Arafat,
Thanks for the report.
This is currently a limitation of the Bricks WPML integration. Code controls are intentionally not registered for translation by default, as they commonly contain PHP, CSS, or JavaScript that should remain the same across languages.
The code under Page Settings → Custom Code is also stored as part of the page settings rather than as regular translatable element content. WPML therefore copies it to the translated page, but the individual code fields are not available in the Advanced Translation Editor.
We already have an internal request covering cases where code needs to differ between languages. We’ll move this forward and look into providing an opt-in filter that allows code controls, including page-level code fields, to be registered for translation in these special cases without making every code field translatable by default.
In the meantime, there are two possible workarounds.
Option 1: Output the code conditionally based on the current language
For tracking scripts, conversion tags, or similar snippets, the safest approach is to remove the language-specific code from Page Settings and add it through a child theme or a PHP snippet plugin.
For example:
add_action( 'wp_head', function() {
$language = apply_filters( 'wpml_current_language', null );
if ( $language !== 'de' ) {
return;
}
?>
<!-- Add the German-specific script here -->
<?php
}, 99 );
Option 2: Copy the page settings once, then edit each translation manually
WPML has a Copy once setting for custom fields. This copies the original value to the translation initially but does not keep the translated value synchronized afterward.
You can add the following under WPML → Settings → Custom XML Configuration:
<wpml-config>
<custom-fields>
<custom-field action="copy-once">_bricks_page_settings</custom-field>
</custom-fields>
</wpml-config>
After saving this configuration, open each translated page directly in Bricks, change its Page Settings → Custom Code, and save. WPML should then preserve that translated page’s page settings during future translations instead of copying the original value again.
Please note that _bricks_page_settings contains all Bricks page settings, not only the custom scripts. This means every language can then have independent page settings, but later changes to the original page settings will not automatically synchronize. The field will also not appear in the Advanced Translation Editor, so the translated values must be maintained manually in Bricks.
I hope that helps!