Customizer replaces original strings by translated strings

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.

Sun	Mon	Tue	Wed	Thu	Fri	Sat
-	8:00 – 13:00	9:00 – 13:00	9:00 – 13:00	8:00 – 12:00	8:00 – 12:00	-
-	14:00 – 17:00	14:00 – 18:00	14:00 – 18:00	13:00 – 17:00	13:00 – 17:00	-

Supporter timezone: Europe/Zagreb (GMT+02:00)

Tagged: Bug

This topic contains 12 replies, has 3 voices.

Last updated by Bruno Kos 1 year, 9 months ago.

Assisted by: Bruno Kos.

Author	Posts
October 7, 2024 at 9:30 pm #16263562
erikM-19	When making any change in the customizer, original strings which are set in the customizer are replaced by translated strings. Issue is related to this closed ticket: https://wpml.org/forums/topic/string-language-changes-after-updating/. I now managed to reproduce! It occurs when a user has a different profile language set than the default site language, and changes something in the customizer. Video: hidden link Can you please fix this bug? P.s. If you like I can give you access to a sandbox where the issue is reproduced and you can try as much as you like. I did not have the option to add a private reply to this ticket, perhaps you have to reply first in order for me to have that option?
October 8, 2024 at 8:35 am #16264443
erikM-19	For the record, the setting "Editing language - set admin language as editing language" is disabled in the sandbox where the issue is reproduced. Please let me know if you like access to this sandbox so I can relay in a private reply. Thanks! hidden link
October 13, 2024 at 10:20 am #16282960
Osama Mersal	Hi, Thank you for contacting WPML support. Sorry for the late reply; it was due to a higher workload. Before your ticket is assigned to one of my colleagues, please allow me to walk you through some initial debugging steps. This will help speed up the support process. 1) Thanks for the video. Please log in to this hidden link and replicate the issue there, as the sandbox site on your old ticket has been removed. If the issue is replicable, please let us know how to reproduce it. 2) Could you please share your Debug information with me? You can read a detailed explanation about it here. (http://wpml.org/faq/provide-debug-information-faster-support) The debug info will give me much information about how your site is configured. Best regards, Osama
October 14, 2024 at 9:21 am #16284759
erikM-19	Hi Osama, >> If the issue is replicable, please let us >> know how to reproduce it. I don't understand, you just said thanks for the video where the issue is reproduced 😀 >> Please log in to this sandbox site and >> replicate the issue there, as the sandbox >> site on your old ticket has been removed. The link you provided for your sandbox provider is not working. Which is no problem for me, as I already created a new sandbox @ InstaWP for you. Is this okay for you? Please enable private replying so I can share login credentials with you. The option has not yet been enabled in this topic by you. Thanks! Kind regards Erik
October 14, 2024 at 12:08 pm #16285849
Bruno Kos WPML Supporter since 12/2018 Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	Hi, I've tested the staging environment at this link: hidden link It appears to be working correctly so far. To help narrow down any potential issues, I'd like to see if we can replicate the problem you're experiencing in this staging environment. This would rule out any problems caused by caching or specific server settings on the live environment. If reproducing the issue on the staging site isn't too time-consuming, it would be very helpful. If that's not feasible, I've marked your next message as private so you can securely share any credentials needed to access the live environment for further troubleshooting.
October 15, 2024 at 2:56 pm #16291547
erikM-19	Hi, I have reproduced the issue in your sandbox. I have set this reply to public as it does not contain any sensitive data. Here is a video showing how to reproduce the issue: hidden link Simply make any random change in the customizer, and the original Dutch strings will be overwritten by their English translations. In my example, I changed the container width. A few remarks: - In "String Translations," set the priority to "Vereist" (Required) to quickly identify strings where the original has been replaced by English. - For your convenience, here’s a spreadsheet that shows where to find these strings in the customizer: hidden link Looking forward to hearing from you. Thanks! Best regards, Erik
October 16, 2024 at 7:45 am #16293698
Bruno Kos Supporter	I am checking this with our 2nd tier and will keep you posted.
October 16, 2024 at 9:40 am #16294501
Bruno Kos Supporter	Is this issue specific to the Astra theme, or does it also happen with other themes? (If it's related to Astra, does it require the Astra Pro plugin?) Additionally, does the issue depend on whether the default language is set to something other than English?
October 16, 2024 at 1:41 pm #16296055
erikM-19	Hi Bruno, I installed the Astra Pro add-on to give you easier access to more and easy accessible input fields in the Customizer. My guess is that this issue also exists without the Pro add-on. I use Astra across all my sites, as it's a widely used and trusted theme. Additionally, because WPML is fully compatible with Astra. Quote: "Astra is a recommended theme thanks to its commitment to continued compatibility and partnership with WPML. Astra is fully compatible with WPML." Looking forward to your findings. Thanks.
October 17, 2024 at 7:29 am #16298407
Bruno Kos Supporter	This has been escalated to our 2nd tier team team and may take some debugging time, I'll get back to you as soon as I have any news or questions for you.
October 21, 2024 at 3:03 pm #16313151
Bruno Kos Supporter	Can you please try the following: 1. Navigate to the file located at `wp-content/plugins/wpml-string-translation/inc/admin-texts/wpml-admin-texts.class.php`. 2. Locate the method `WPML_Admin_Texts::icl_st_set_admin_options_filters`. 3. Modify the condition from: $isAdmin = is_admin() && ! wpml_is_ajax(); To the following: $isAdmin = is_admin() && ! wpml_is_ajax() \|\| (($_REQUEST["wp_customize"] == "on") \|\| $_POST["screen_id"] == "customize"); This change should allow the correct handling of the admin options filter when working in the customizer environment. Can you tell me if this works for you?
October 21, 2024 at 6:52 pm #16314130
erikM-19	Hi Bruno, I can confirm that seems to fix the issue on my end as well! Can you include this fix in the next release of this plugin? Looking forward to hearing from you. Thanks. All the best Erik
October 22, 2024 at 5:03 am #16314935
Bruno Kos Supporter	I cannot say into which version will it go, it is up to developers to decide. But I will keep this thread updated as soon as there is some movement in that direction.