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.
It seems like you have a few different domains set up within similar plugins. The textdomain was specifically looking for leadup while the textdomain is defined as leadup-core in the leadup-core.php file and in the strings, you’re using leadup-frontend.
I recommend using a single domain within a plugin code to make things easier to manage.
Ok ok I see now ... It partially works, because indeed we do have 4 or 5 domains starting with "leadup-XXXXXX"
When you hardcoded "leadup-frontend", so in the page hidden link, if you test now the process of buying a product in the french site, you should see that some string translations in other domains are not translated...
What you have pin pointed, is a line that is present in one side of our entire site, we are not doing this somewhere else... just there, it's a PHP Class handling our shortcodes, just that. It does not concern the other 99% of our site that has nothing to do related to shortcodes.
Then, the website I gave you is like the staging website. The production version of it, has String translations working properly with this same line... so I think this is a false positive here, that do not affect the entire site.
For the strings that's not working, can you use a similar text-domain and see if it helps.
The production version of it, has String translations working properly with this same line... so I think this is a false positive here, that do not affect the entire site.
I couldn't understand this, Do you mean the strings works properly on the production site without any additional fix?
We have 7 WordPress, each of them have 1 staging environment, and 1 production one.
On the 7 production websites, as a not connected user, String translations works, for now...
in the staging website I gave you, String translations does not work. The fix was developed as a fallback, so we are about to publish it on all production websites, because it is a fallback. I mean we think there is a problem not yet revealed in the production ones, and the staging have uncovered it.
The issue seems to be related to the use of multiple text domains. WordPress recommends using a single, consistent text domain per plugin to ensure proper localization and translation. If we adhere to this guideline, I don't believe we'll encounter any issues. Would you agree?
I've read it and it makes to sense to me sorry, we have as a company 12+ sites and domains, with WordPress and WPML in it, since a while we are customers, and basically, you are telling us and our entire IT department, that this issue with String Translations is due to the fact that we use more than one text domain...
WooCommerce, a notorious WordPress plugin we heavily use and be dependent on, use for instance one text domain, which is "woocommerce", and some String Translations of WooCommerce also don't work in this problem... so you are telling that between our proprietary plugins, which also use their own text domain, and WooCommerce, we do have to make a choice and remove them ?
Absolutely no, there is no way to accept that as an answer, we cannot do that as a generating profits business. That's not acceptable, if we do have +15 plugins, making available in WPML String Translations +15 different text-domains, we cannot remove entirely one or two plugins, just in order to reduce the total amount of text domains handled by WPML.
Time is ticking, we will have to remove your access, the issue is still present, please do refer this entire topic to someone from the dev department please, I got pressure from my management to solve this ASAP. We are a paying customer, we are not playing here.
