Skip Navigation

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

Problem:
The client is unable to see the translated string "month" in secondary languages on their website, despite using JavaScript to append this string and the

wp_localize_script

function for localization.

Solution:
1. Ensure all strings are registered:
- Navigate to WPML > Theme and plugins localization and scan your themes and plugins.
2. Re-register and translate strings:
- Go to WPML > String Translation, delete all occurrences of the problematic strings, enable the "Look for strings when rendering pages" option, visit the frontend, and then add translations.
3. Check database charset configuration:
- Ensure the database charset in

wp-config.php

is set to

utf8mb4

.
4. Regenerate .mo files:
- Use the troubleshooting section under WPML > Support to regenerate .mo files.

If these steps do not resolve the issue, it may be necessary to use custom CSS for translation or further debug the JavaScript implementation. Custom programming, however, falls outside our support policy. For more complex issues or custom implementations, consider hiring a WPML contractor from https://wpml.org/contractors/.

Please note that this solution might be outdated or not applicable to your specific case. We 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 problem persists, please open a new support ticket at https://wpml.org/forums/forum/english-support/.

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 9 replies, has 2 voices.

Last updated by Mihai Apetrei 3 months, 4 weeks ago.

Assisted by: Mihai Apetrei.

Author Posts
July 16, 2024 at 1:18 pm #15960707

peterJ-48

Background of the issue:
If we enable the option "Look for strings when rendering pages" from string translation on the backend then we can see the translated string on the frontend. If we disable the "Look for strings when rendering pages" option from string translation on the backend we cannot see the translated string but we can see the English string on the frontend.

Symptoms:

Questions:

July 16, 2024 at 1:29 pm #15960818

Mihai Apetrei
Supporter

Languages: English (English )

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

Hi there.

Before this ticket gets assigned to one of my colleagues, I will try to help.

Explanation of the Issue:

The "Look for strings when rendering pages" option allows WPML to dynamically search for and translate strings during page rendering. When this option is enabled, WPML scans the page for any strings that need translation on-the-fly, ensuring that all strings appear correctly translated on the frontend. Disabling this option means that WPML will rely on previously registered and translated strings. If these strings were not correctly registered or saved, the default language strings (often English) will be displayed instead.

Here are some recommendations to resolve the issue:

1. Ensure All Strings Are Registered:

- Go to WPML > Theme and plugins localization.
- Scan your themes and plugins for any strings that need translation.

2. Re-Register and Translate Strings:

- Go to WPML > String Translation.
- Search for the problematic strings and delete all occurrences.
- Enable the "Look for strings when rendering pages" option.
- Visit the frontend where the strings appear.
- Return to WPML > String Translation, search for the strings again, and add the translations.
- Disable the "Look for strings when rendering pages" option.
- This method helps in ensuring that the strings are correctly registered and translated in the database without the need for dynamic rendering each time

3. Check Database Charset Configuration:

- Ensure that your database charset in `wp-config.php` is set to `utf8mb4` instead of `utf8` to support a wider range of characters, including symbols and special character.

4. Regenerate .mo Files:

- Go to WPML > Support > Troubleshooting.
- Look for the option to regenerate .mo files. This can help in ensuring that the translations are correctly compiled and recognized by the system

Here is also a list of existing tickets on this same topic:
hidden link

Following these steps should help in resolving the issue where translated strings are only showing when the "Look for strings when rendering pages" option is enabled.

Please let us know how things go.

Mihai Apetrei

July 18, 2024 at 11:38 am #15972193

peterJ-48

Hi Mihai,

We followed the steps as you suggested but still we are not able to see translate the string "month" into secondary languages.

See the video recording : hidden link

July 18, 2024 at 8:58 pm #15974835

Mihai Apetrei
Supporter

Languages: English (English )

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

Hi there.

Thank you for the update.

Maybe there is some caching active?

I would like to request temporary access (wp-admin and FTP) to your site so I can better examine the issue. The needed fields are below the comment area. When you log in to leave your next reply, the information you enter is private, meaning only you and I can see and access it.

Our Debugging Procedures

I will check various settings in the backend to see if the issue can be resolved. Although I won't be making changes that affect the live site, it is still good practice to back up the site before providing us access. In the event that we do need to debug the site further, I will duplicate it and work in a separate, local development environment to avoid affecting the live site.

Privacy and Security Policy

We have strict policies regarding privacy and access to your information. Please see:
https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/

**IMPORTANT**

- Please back up the site files and database before providing us access.

If you do not see the wp-admin/FTP fields, your post and website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box.

The private box looks like this: hidden link

I will be waiting for your response.

July 19, 2024 at 10:34 pm #15980060

Mihai Apetrei
Supporter

Languages: English (English )

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

Hi and thank you for the credentials.

I can confirm that I was able to log in successfully.

I am spending more time on this and I will get back to you as soon as I have more feedback.

I will leave the ticket assigned to myself for the moment.

PS: This is just a note that I won't work over the weekend. I will get back to work on Monday. (I'm mentioning this in case a reply comes this weekend.)

Kind regards,
Mihai

July 22, 2024 at 7:19 pm #15988871

Mihai Apetrei
Supporter

Languages: English (English )

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

Hi there and thank you for your patience.

The issue here is that the string that you are referring to ("month") is added to the website through custom CSS as you will see in the screenshots I'm attaching. The strings from your screenshots are different ones and not the ones showing on the front end.

So, you will need to use CSS to "translate" that content.

Custom coding falls out of the purpose of our support policy but I will be happy to share an example for Swedish and you can use this example for the other languages.

Please add the following code to your website's backend > Appearance > Customizer > Custom CSS > and then save it:

html[lang="sv-SE"] #wcfm-main-contentainer .wcfm_membership_box_head .wcfm_membership_price .amount:after {
    content: "/månad";
}

Now, you should see the correct string in Swedish.

I hope that you will find this information helpful.

Screenshot 2024-07-22 at 22.15.08.png
Screenshot 2024-07-22 at 22.13.56.png
July 23, 2024 at 6:35 am #15990500

peterJ-48

Hi Mihai,

I'm sorry for the inconvenience! We are using Git Flow and for some work we switched the branch to new.memidos.com and that's why you got another content creation with CSS.

Now, we have changed the branch where we have the issue with the translated "month" string.
See the Screenshot of the string "month" in the secondary language : hidden link

We have added string "month" with "js'. (I know we can translate string with CSS but we have 20 languages. ​​so we prefer to manage translated strings from string translation.)

Js code for append string "month" :
----------------------------------------

jQuery(document).ready(function ($) {
$('.wcfm_membership_price .woocommerce-Price-amount.amount').each(function () {
$(this).append('<span class="translated-month">/' + object_back.month + '</span>');
});
});

And this is localize script for translation :
------------------------------------------------

$translation_array = array(
'back' => __( 'Back', 'memidos' ),
'month' => __( 'month', 'memidos' ),
);
wp_localize_script( 'app-js', 'object_back', $translation_array );

In our case translated string "Back" is working fine but translated string "month" is not working on the frontend.

Check on mobile view "Back" string is working fine :
----------------------------------------------------------
Screenshot of English language : hidden link
Screenshot of secondary language : hidden link

Let me know how we can see translated the string "month" into secondary languages ?

July 24, 2024 at 8:26 pm #16000280

Mihai Apetrei
Supporter

Languages: English (English )

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

Thank you very much for making things clearer for me.

Unfortunately, it is not possible to translate this string with String Translation because it's added into JavaScript and not localized.

WordPress currently only offers a localization API in PHP, not directly in JavaScript.

To fix this and make the text translatable, you can use the "wp_localize_script" function: https://developer.wordpress.org/reference/functions/wp_localize_script/

For more details, please check the reply from my colleague here: https://wpml.org/forums/topic/string-translation-138/#post-9698875

Kindly note that custom programming work is beyond the scope of our support. If the above suggestions didn't help or you're unsure about how to achieve it, we suggest contacting one of our 3rd party contractors that specialize in custom work with WPML
https://wpml.org/contractors/

July 25, 2024 at 6:54 am #16001570

peterJ-48

Hi Mihai,

I think you didn't read my reply properly, I already mentioned that we used "wp_localize_script" function for translation in this thread : https://wpml.org/forums/topic/translated-string-not-showing-up-in-frontend/#post-15990500.

To fix this and make the text translatable, you can use the "wp_localize_script" function:
Reply : We already use "wp_localize_script" function. see the below code.

This is localize script for translation :
--------------------------------------------

$translation_array = array(
'back' => __( 'Back', 'memidos' ),
'month' => __( 'month', 'memidos' ),
);
wp_localize_script( 'app-js', 'object_back', $translation_array );

In our case translated string "Back" is working fine but translated string "month" is not working on the frontend into secondary languages.

Check on mobile view - We can see translated the string "Back" into secondary languages.
----------------------------------------------------------
Screenshot of English language : hidden link
Screenshot of secondary language : hidden link

But we can't see translated the string "month" into secondary languages.
---------------------------------------------------------------------------------
Frontend URL : hidden link
Screenshot of the string translation : hidden link
Screenshot of secondary language : hidden link

I hope you come back to me with proper solution.

July 25, 2024 at 7:24 am #16001700

Mihai Apetrei
Supporter

Languages: English (English )

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

Hi there and welcome back!

Yes, I just wanted to confirm that this is the way to go, the right direction, but in our case, at some point, it seems that something goes wrong and needs to be properly debugged on a deeper level.

However, this approach where translations are introduced via JS/jQuery requires custom work.

While we are able to provide some quick recommendations and directions like I did above, implementing or debugging custom code falls out of the scope of our Support Policy.

That is why I mentioned above that you will need the help of a WPML contractor or a developer to properly debug and implement this custom solution.

We have a very big database of amazing customers and it would literally be impossible to help each client that needs custom implementations for their site even though we would love from all our heart to be able to do that.

I hope this explains the situation a bit better.

Thank you very much for your understanding and cooperation.

Mihai