Home›Support›English Support›[Resolved] Layout and Hover Effect Regression on Translated Blog Page (WPML/Bricks Builder)
[Resolved] Layout and Hover Effect Regression on Translated Blog Page (WPML/Bricks Builder)
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported a significant visual discrepancy between the original English blog page and its Hungarian translation in Bricks Builder. Specifically, the header is not appearing as expected. Solution: If the menu items are too long, causing layout discrepancies, we suggested manually translating the menu to adjust the length of the items. For more detailed guidance, we provided a link to our documentation on translating menus: https://wpml.org/documentation/getting-started-guide/translating-menus/
If the solution provided does not resolve the issue or seems outdated, or if it does not apply to your case, please open a new support ticket. 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. For further assistance, you can also visit our support forum at https://wpml.org/forums/.
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.
**Description**
There is a significant visual discrepancy between the original English blog page and its Hungarian translation. While the English version correctly implements the hover effects designed in Bricks Builder, the Hungarian version (translated via WPML ATE) fails to render these styles correctly.
**Steps to Reproduce**
1. Open the English blog page and hover over a blog post card. hidden link
Observe the expected behavior: The purple overlay slides over the image, and the excerpt becomes visible only on hover.
2. Open the Hungarian blog page. hidden link
Observe the current behavior: The hover effect does not trigger. Instead, the purple section and the excerpt are permanently visible.
**Actual Result**
The hover animation is broken on the Hungarian page.
Because excerpts vary in length, the permanent visibility causes inconsistent card heights and large, unsightly gaps (white space) between rows.
The layout does not match the Bricks Builder configuration.
**Expected Result**
The Hungarian blog cards should behave exactly like the English ones.
The excerpt/purple overlay should remain hidden until the user hovers over the card.
Before this is taken by a colleague, let me see what we can do to expedite things.
There are a handful of known issues with Bricks, but this isn't one of them.
It will certainly help if we can take a look at the back end of your site to check you exactly you made that page, and to see if we can spot where it might be going wrong.
If you have a staging server available, that would be better so that we don't have to touch your live site.
Let me mark your next reply as private so that we can get log-in credentials from you—you may want to create a temporary admin user for us to use that you can later delete. And be sure to have a current backup of your site.
Thank you for the update and for fixing the template on the staging site. While I appreciate the manual fix, I cannot consider this issue resolved without further investigation into the underlying cause.
Following the WPML documentation, there is no mention that a user should "re-translate a page multiple times until the layout renders correctly." The fact that you had to update the translation for the "blog csempék (cards)" template for the **third time** (I have already translated it twice before) clearly indicates a **bug in how WPML handles or stores layout-related data** during the translation process.
This is not an isolated incident; we frequently experience that content translated via **ATE (Advanced Translation Editor)** fails to render styles or hover effects correctly on the front-end, despite being marked as 100% complete.
**I would like to request the following:**
1. **Bug Report:** Please file an official bug report regarding this behavior. Re-translating the same content multiple times is not a sustainable workflow or a valid solution.
2. **Root Cause Analysis:** We need to know why the CSS/Layout data from Bricks Builder is not being consistently applied to the translated version upon the first completion.
3. **Stability:** We can only close this ticket once the development team identifies the cause of this regression to prevent it from happening again.
Consistency is key in a multilingual setup, and currently, the system's reliability is compromised. I look forward to hearing about the next steps and the bug report reference number.
Hi Andreas,
I have attached two additional screenshots showing that while the hover issue might have disappeared after your manual update, new layout errors have emerged.
This proves that even after translating the same content for the third time, the rendered output remains inconsistent and buggy.
I would like to emphasize that this is a severe blocking issue.
Zsolt
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
On WPML > Settings > Custom Field Translation, I clicked "Show system fields" and set these fields to "Copy":
_bricks_page_content_2
_bricks_editor_mode
This seems to solve the CSS issues.
Take kindly note:
1) I can only escalate an issue to development if I can replicate it on a test site in a minimal setup. I can offer such a test site for this purpose, but I will need your cooperation in installing the latest version of the Bricks Theme.
2) When I visited your staging site for the first time, no content was showing up in the second language. There can be many reasons for this behaviour. For example, it could be that the migration from production to staging damaged the content.
3) As long as retranslating the content solves the issue, we can not confirm any bug. It might even be that there used to be a bug, which no longer exists in the current plugin/theme versions. Fixing bugs will not automatically fix the translated content; it will need to be updated afterwards.
4) I created a completely new test site on your staging using Bricks and translated it. It worked without issues. hidden link
The only issue you will see on this page is the menu layout, which is not a WPML issue. It is the theme that controls the design, and here, simply, the translated menu has more text. I would suggest lowering the number of characters for the menu items at Appearance > Menus while selecting the respective language and editing the translated menu manually.
Hi Andreas,
Thank you for identifying the missing "Copy" setting for the _bricks_page_content_2 and _bricks_editor_mode system fields. I will test if this permanently stabilizes the layout and the hover effects on the blog page.
Regarding point #3: While re-translating might solve the visual symptom, the underlying issue is that the initial translation process or a connection hiccup can result in a corrupted state. However, if these field settings prevent future issues, I am willing to monitor the site for now.
I will check the site site and get back to you if the issue persists.
Multiple supporters have been working on this staging site, which likely explains the "strange things" and inconsistencies you noticed.
I have just tested the page with the new **custom_field** settings, and unfortunately, **it still does not work properly.** On the first translation attempt, the design completely broke (please see the attached screenshot). It only rendered correctly after the second translation.
Regarding your point #3 ("As long as retranslating the content solves the issue, we can not confirm any bug"): **This position is untenable.**
It is unacceptable that the first translation attempt destroys the page design, especially when sometimes even a third or fourth attempt fails to fix it. This is the definition of **unreliable software behavior.** I am asking you to acknowledge a basic requirement: **WPML must generate the translated page flawlessly on the first click.**
I am fully committed to being a partner in finding the root cause of this, but please keep in mind that I have already invested many hours of my own time trying to resolve these recurring bugs between WPML and Bricks Builder.
Let’s move past the "re-translating fixes it" argument and find out why the synchronization fails in the first place.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
It is truly odd that the first translation fails, and the second works out. I can see page loading issues on your production site, but it does not seem to occur on the provided staging site: hidden link
Can you verify, please?
It would be ideal to have access to an updated staging site on which I can see the issue.
Regarding the issue you mentioned in your last message: that is actually a separate bug which we are handling in a different ticket. My apologies for the confusion; let’s keep our focus on the current issue.
As I stated previously: **let’s move past the "re-translating fixes it" argument and find out why the synchronization fails in the first place.**
Currently, on the staging site, you can compare the English blog page ([hidden link)) and the translated Hungarian version ([hidden link)). I had to translate this page twice, and as you can see, the layout of the two pages still differs. This is a major problem. For example, the menu on the Hungarian page should fit in a single line, just like it does on every other page of the site.
**I am asking for a definitive solution to ensure that a Bricks Builder page translated via ATE looks exactly like the original English page after the very first translation.**
There are only two possibilities here:
1. This is a **bug** that your developers need to fix.
2. This is the result of a **misconfiguration**.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
About the blog page:
The only thing that appears to differ here is the menu in the header, and this is expected, as the Hungarian menu items are too long. There appears to be one more menu item in Hungarian.
This design change is not coming from WPML; it is coming from the theme and is expected because the menu items are longer in Hungarian.
First, try to run WPML > WP Menus Sync. Note that this will only work as expected if all pages are translated.
