Home›Support›English Support›[Resolved] String Translations present/correct in l10n.php files and Database, but not displayed as translated ...
[Resolved] String Translations present/correct in l10n.php files and Database, but not displayed as translated ...
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported an issue where string translations are correctly present in l10n.php files and the database but are not displayed as translated on the French or German versions of their website. The problem appears randomly, with about 90% of strings correctly translated and 10% remaining untranslated. The client suspects a conflict between l10n.php, .json, and .mo files in the /wp-content/languages/wpml folder. Solution: We suggested that the issue might be due to the use of multiple text domains within the same plugin, which can complicate the translation process. WordPress guidelines recommend using a single, consistent text domain per plugin for proper localization. For more details, refer to the official WordPress Plugin Handbook. Additionally, our second-tier support team advised loading all text domains using the
load_plugin_textdomain
function. Here is an example of how to implement this:
If there are more text domains, they should add new lines accordingly.
If this solution does not resolve the issue or seems irrelevant due to updates or different circumstances, 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. If problems persist, please open a new support ticket.
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.
Background of the issue:
Hello I opening and reporting this issue because with the latest versions of WPML, when my users are on the French or German version of my website, they do see some String translations not translated and in english, which is a serious issue in terms of serious of work for us.
I had to put in place a custom workaround, using the "gettext_{domain}" filter hook of WordPress to solve myself the problem...
I have the feeling that the new performance files, the l10n.php are correct and match with what is in the Database and interface (where the right translations are indicated), but in the same time, there is (I suppose) a confusion and cohabitation with .json and .mo files in the /wp-content/languages/wpml folder.
That's my theory, and it's quite random, because for one specific domain/context, I see 90% of the String translations well displayed and translated, and 10% with no reason : not translated....
We need your help on this, it is a production website.
WPML Multilingual CMS -> Version 4.7.1
WPML String Translation -> Version 3.3.1
Here is my workaraound php code, within a PHP class:
Symptoms:
String translations are present and correct in l10n.php files and the database but are not displayed as translated. Users see some string translations not translated and in English on the French or German version of the website. The issue is random, with 90% of strings displayed correctly and 10% not translated.
Questions:
Why are some string translations not displayed correctly despite being present in l10n.php files and the database?
Is there a conflict between l10n.php, .json, and .mo files in the /wp-content/languages/wpml folder?
I followed the link given by the supporter: hidden link, but it's impossible to replicate the issue in this WordPress website because we have specific domain and .mo/.l10n.php files that cause the problem. Then a scan on our proprietary WordPress plugin should be performed in order to retrieve the concerned String Translations. Can we have a dev-team or dev-level assistance on that please?
Unfortunately, developers aren’t usually available on the support forum.
As I mentioned, we can escalate the issue, but we’ll need steps to reproduce it. In these situations, I think the best approach would be to create a staging site and remove all the data except for the error. That way, we can test further.
Hi Shekhar, thanks for your reply. I found a way and managed to get the mysql DUMP of one of our websites having the bug. Do you want it ? How to share here ? I also have the .zip of a proprietary plugin of us, having the string translations to shown
I can download the plugins and database from there, but there is no theme, can you also provide me steps where I can see the strings not being translated properly along with few strings examples.
Here is the link to download a proprietary theme, also coming with a bunch of string translations:
hidden link
Normally, with the 2 provided plugins and this Theme, you should trigger a new String Translations scan, by checking them (checkbox in the dedicated page).
Then there is one domain/context standing out with a lot of Strings: leadup-frontend.
There you can for instance, after adding French as secondary language, translated yourself a bunch of basic ones that are listed in String Translations.
Once they all have English and French, you should add WooCommerce, create 1 product, go to the Catalog page, add a product to your cart, and then go to the Checkout page.
On that page, our 2 proprietary plugins add and update some native fields displayed there, with String Translations coming along. If you switch to that same user experience, in French, the checkout page (also translated as a page) should display String Translations from the domain/context "leadup-frontend" not translated... in english instead of french...
For instance: Birthdate, one of the fields label on that checkout page, should be "Date de naissance" but is still "Birthdate" in that page.
Do you see ? in addition to the theme, you should add WooCommerce and create a product to buy
Wow, excellent, bravo Shekhar for going to that level.
All the text you are viewing in that /checkout/ page, the labels, the placeholders of not-filled fields and so on, all of this text is available in the String Translations dashboard of WPML, after a scan
The idea is to translate that /checkout/ page in French for instance, as well as all those String translation in French too. Maybe it's cumbersome but please add those corresponding translations. And then reproduce that buying user experience, in the French version of your local/reproduction WordPress site.
and according to my screenshot, there is a checkbox supposed to add a Birthdate field in the /checkout/ page. This field comes with a series of String translations, such as "Birthdate" under the "leadup-frontend" domain/context.
Please also translate those associated String translations.
Finally, to be more close of what we do have here in our high-traffic high-audience WordPress websites, you might need to install and add the plugin WP-Rocket, even the free version is OK. We do use this plugin extensively, and sometimes, it can conflict with some WPML String translations...
In the settings of WP Rocket, the slug or URL: /checkout/ should be added in the textarea of exceptions, forcing WP Rocket to not cache that slug for any visitor, and letting the WordPress + WPML showing the latest version of it, and fresh/up-to-date String translations.
Please tell me if all my new indications were clear or not enough I can
Your screenshots suggest 2 things :
- you are still in english, the default language we know it works, because String translations in hard code are in english first
- you are viewing that page while being connected as a WordPress dashboard user.
The problem we saw was:
- for the french audience visiting our french website, so please switch to that configured/added language
- that audience, high traffic, are not connected users, but simple visitors of the french website, going throughout a classic WooCommerce buying experience, when at no moment it's proposed to login.
That's the 2 conditions you need to respect for being more close to our configuration.
Then, I see your demarch and approach, consisting in trying hard to reproduce the issue before escalating it or stopping it there... but as WPML paying customer, my company and entire IT department confirm the issue is there and serious, with large business implications. We just cannot have some String Translations translated, and some other not, in our french or german websites versions. That's not acceptable. We are highly dependent on WPML for our multi-communities websites, with high traffic and hits, the impact is really big and to not understimate.
Time is money, while you are trying to reproduce our bug, it's days and days for your organisation with no concrete fix, and an unbearable waiting from my management. I got pressure to fix this ASAP. So please consider right now you would not be able to reproduce exactly the issue " just - like - that " in a simple scientific or pseudo-scientific demarch, and somebody for your tech department might really need to be involved, hands on our systems even, on our internal infrastructure, in order to figure out what is raelly going.
I gave you a database dump, that suggests a series of WordPress plugins needs to be installed and activated. The problem is maybe there, a conflict... versions can also be a problem... We need to fix this ASAP Shekhar. Please consider the gravity for us
I've attached screenshot in French — I only translated the birthdate to check the issue.
As mentioned earlier, I’m unable to escalate the issue without being able to reproduce it. Due to the volume of requests we receive, our second-tier support and development teams can only handle issues that include clear reproduction steps or a specific location where the issue occurs.
I followed the steps you described but couldn't replicate the issue. I'm happy to continue trying, but I must inform you that without a reproducible case, I won’t be able to escalate it further. This process ensures issues are addressed efficiently and accurately.
To assist us, you can share a site dump, which would significantly help with debugging. If that's not possible, we may need to continue with a trial-and-error approach until we can replicate the problem.
Shekhar, you need to meet me halfway in that case. My CTO told me it is not possible to share like that an entire environment, with client, customers and sensitive data. it's a total no go.
What do you think, if I provide you with an access, to the WordPress environment, as an administrator, for let say : 2 weeks. Then you have full ability to do whatever you want in the backoffice, and see from your own eyes what happens on the front, as a not connected user...
We can also provide you with a live debugging access to the root server, where the WordPress and WPML files are hosted (things we usually give to technical guys).
I propose that, because here, maybe the issue is not replicable, and we are loosing valuable time. Do you see what I mean ? the apple needs to be cut in two for this special situation
