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.
Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.
Background of the issue:
I am trying to update a string that has already been imported into WPML's String Translator. Specifically, I want to update a comment that was left and entered the moderation queue. Even before being approved, it appears in String Translator. If the comment is modified by the moderator, the original comment remains in String Translator.
Symptoms:
The original comment remains in String Translator even after it has been modified by the moderator.
Questions:
How can I update a string that has already been imported into String Translator?
How can I prevent the original comment from remaining in String Translator after it has been modified?
Reading through several of your tickets on the website, I gathered that there doesn’t seem to be a proper solution. So, I went ahead and deleted all the strings from the wcml-reviews domain and re-scanned them.
So alright, let’s say the issue is “solved” with this rather crude workaround – the problem, however, still exists: if we update a review due to a grammatical error, we need to delete the string and re-import it.
That said, there’s now another issue: the number of reviews shown in the String Translator doesn’t match the number listed on the WooCommerce reviews page.
The site has around 2,500 reviews, considering the only two languages it supports. However, only about 2,300 reviews have been imported into the String Translator.
Roughly 200 reviews are missing.
When trying to re-scan the reviews from the Troubleshooting section, I can see that there are still 80 reviews left to scan. I do it, but nothing changes once the process is complete. If I refresh the WPML page, it still tells me there are 86 reviews left to translate.
We have an in-house developer, so we’re not just improvising when it comes to solving issues. However, we’d really appreciate some guidance to make sure we’re not just trying things at random.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
Hi,
Given that "Register product reviews for translation" is enabled and we’re forcing reviews to be scanned, I can file a feature request for our developers to consider a more streamlined handling of updated reviews, but I can’t promise if or when it might be addressed.
Regarding the review count mismatch in String Translation, looking at the ticket you linked, I saw that our 2nd-tier team had tested modifying the code in:
// Prepare the query and store it in a variable
$prepared_query = $this->wpdb->prepare( $query, $args );
// Log the prepared query
error_log( 'Prepared Query: ' . $prepared_query );
// Execute the query
$this->wpdb->query( $prepared_query );
That revealed the issue in their case was due to emojis in the review content — for example:
“Je vous les recommandes 👌”
“Je l’adore!!💗💗💗”
These reviews with emojis weren’t getting registered properly.
Would you be able to check if the missing reviews on your site contain emojis? That could help us confirm if this is the root cause in your case as well.
Let me know what you find, and we’ll be happy to continue investigating from there.
WPML is a professional plugin, so I expect it to allow us E-Commerce Managers to handle WooCommerce in a professional way. If I receive a comment where the customer writes in poor grammar, or includes double spaces, triple commas, etc., we are forced to moderate it before publishing.
But what happens if WPML intercepts the string even before we publish it? I don’t understand how this feature still isn’t part of WPML—especially when WordPress settings are configured to “hold a comment in the moderation queue” rather than “publish immediately.”
Still, fair enough, we’ll play along. But in that case, I’d like to know the best way to handle this, because the issue remains for us regardless.
As for the other problem—BINGO! We do have a few reviews with emoticons, and it’s perfectly reasonable to assume that the missing ones might include emoticons too!
How do we import them?
Again, it’s 2025—it’s more than fair to expect that customers might want to express emotions through emoticons in their reviews… right?
🙂
New threads created by Bruno Kos and linked to this one are listed below:
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
I tried to reproduce this issue with emojis in the reviews: hidden link
But the scan never starts, not even if I add reviews before WPML is configured, given that the new reviews will already show in translation management as soon as they are added. Only pre-WPML reviews require scanning.
So as for the issue within your website, to troubleshoot this problem, I'll install the Duplicator plugin and generate packages for further debugging purposes. I'll ensure to exclude all media files to maintain a minimal package size.
You’re right—I personally submitted an entry on your test site and the strings do indeed appear immediately. So it does seem to be an issue specific to our setup.
Unfortunately, since it’s a live site that handles purchases, I can’t provide access. However, if you need anything specific—even from the database—please don’t hesitate to let us know. As I mentioned, we have an in-house developer, so feel free to ask more technical questions—we’ll understand and can follow along.
What I can tell you is that we’ve been using WPML for many years. We applied that workaround mentioned in the previous ticket, which we assume was created by your support team to help scan messages containing emoticons.
I can also add that for a long time, we had automatic string scanning disabled to avoid filling the database unnecessarily. We’ve always scanned plugin domains manually, only when needed.
But now we’ve re-enabled automatic scanning, since we’re about to carry out translations in several languages.
I ran another test on our site just to be absolutely sure, searching within the wcml-reviews domain strings for some of the emoticons that usually appear in reviews—but no results came up. So it’s clear that this is the issue. Just so you know, all our plugins are fully updated to the latest version.
Continuing with the test, I tried on our staging site—which is identical to our live site in terms of settings—and submitted a review with an emoticon. It was successfully imported! So it seems the issue isn’t related to the present setup, but is instead specific to past reviews.
If you need to take a look, I can give you access to our staging site. Could that be a good compromise?
It’s much easier for us than duplicating the site.
If so, I’d just ask that you check with us before carrying out any operations—even something like deactivating a plugin. Since it’s a site we actively work on, we need to maintain full control over what happens.
We’ve come up with an idea for a test before moving forward with your suggestion.
We want to try duplicating a review that includes an emoticon and is already in the database - but hasn’t been imported. The goal is to see whether a new entry (the duplicate) gets picked up this time.
If it works, we could simply duplicate all the records and remove the old ones.
Alright, we’ll go ahead with this test today and keep you posted. But if this does turn out to be the issue - why hasn’t a known problem like this been addressed?
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
From what I can see, there was one prior case like this, and while it did take some effort to debug, a workaround was eventually found. However, for reasons unclear, it doesn't seem like the issue was fully addressed at the time—no formal fix or follow-up was implemented.
It’s likely that the workaround was seen as sufficient at the moment, but looking back, it probably should have been handled more thoroughly.
