Home›Support›English Support›[Resolved] Issue after changing default website language and Woo Shop page language
[Resolved] Issue after changing default website language and Woo Shop page language
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is using the 'String translation' plugin to manually translate specific strings from English to German. However, the translations are not appearing on the frontend. Additionally, changing the default language and the language of the WooCommerce SHOP page caused layout issues, including a corrupted menu and missing logo. Solution: We recommend ensuring that the client has write access to the
/wp-content/languages/
directory. This is necessary for the 'String translation' plugin to function correctly and save translations that will appear on the frontend. If the client is unsure about their hosting permissions, they can verify this by moving their website to another server to see if the issue persists. If needed, we can provide a Cloudways instance for testing. For more detailed instructions, please visit https://wpml.org/de/faq/cannot-write-mo-files/#if-i-dont-have-write-permission-how-can-i-get-my-hosting-company-to-grant-it-to-me.
If this solution does not resolve the issue or seems irrelevant due to being outdated or not applicable to your case, 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 further assistance is needed, please open a new support ticket at WPML support forum.
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.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Hi Ruediger,
To be on the save side, am I right that the related .PO files should have been saved in the languages folder by default after completing the string translations in the editor and the 'Saved' confirmation?
Please look at the sub-folder "wpml" on: /wp-content/languages/wpml.
BTW: What do I have to do to make the WPML error message on top disappear?
I created a new ticket for that case and answered it already.
I followed the instructions of your new ticket and I was able to make that error message disappear. So this issue is resolved.
Looking at the given sub-folder "wpml" showed no .PO files at all (please see screenshot attached). It looks like .PO files do not get saved after completed translations in the string translations editor. But the translated text still remains in the editor.
I followed the instructions on the related community tickets but nothing helped.
Am I right that saving related .PO files should happen automatically in the sub-folder "wpml" to make completed translations appear on the frontend? And should remain saved there? I ask this because I was able to upload .PO files to the sub-folder "wpml", but after refreshing the page they were gone again.
If .PO files should remain in the sub-folder "wpml", I guess this is definetely a hosting related issue and I'll open a support ticket there immediately.
Please let me know the answer to my latest question so we could set this issue to resolved.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Hi Ruediger,
MO files would be OK here, as these are already compiled PO files. You can also try upgrading after a full backup to 6.5, as WordPress introduced new methods to convert these files to PHP files (they merged the "Performant Translations" plugin into the core).
It will probably not solve the issue here, but it's worth a try to see if anything is actually written on /languages (you will also see .json files here) and /languages/wpml. But I agree; this really looks like a hosting issue.
The site is already running on 6.5.2 since release but no improvement. I also clicked to the troubleshooting page within WPML help area and made a full reset at the end of the page to start from scratch. But no way either after making some translations with the string translation plugin again. I then generated again the related .PO files and searched for relevant translations in the edited text of the files. But no result of the translations.
I want to open a support ticket now with the hosting company, but still lack of a complete understanding of what I should tell them where to start troubleshooting. All I could tell them at the moment is that the translated strings in the editor of the related section of the plugin shows up as 'SAVED' as soon as I leave the editor. As the translated text still is saved when clicking the pencil it seems sure that at least those translated strings are saved in the database.
But from that point on I have no idea what should happen to make the translated text displayed on the frontend. Can you help me with some advice what I should tell or ask the support team of the hosting company?
They only need to check if you don't have write access to /wp-content/languages/.
If you need proof, move your website to another server and see if it works. If you don't have one, I can provide you with a Cloudways instance where you can migrate the installation via a plugin. So, the hosting company has proof that it's only not working in its environment.
I got a reply from the support of the hosting company and this is proof it is a related issue to the hosting environment:
---------------
"First important thing to know is that language files are considered part of the application. That means that for tenants, the same rules apply as for plugins and themes: language files are shared and immutable. That means, especially if you're trying to translate menu items (strings that are part of the software), you'll be able to translate these in a version editor, after which a deploy will make these translations available to all tenants under that version.
If you're looking to translate posts and the like, WPML is unfortunately not a solution that is workable on Wildcloud. As they don't allow to change the location of translation files, these translations will always interfere with the multi-tenant aspect of the platform."
--------------
Translations of posts and the like I do not intend to do. This is not relevant.
I followed their instructions to translate menu items (strings that are part of the software), to be able to translate these in the version editor, after which a deploy made these translations available to all tenants under that version. Worked out of the box, but only regarding the writing of the .MO files to the tenant wpml folder (please see screenshot attached).
The .MO files you see there came from the translations I did on the version (66) in those three domains. But on the frontend of the tenant site there was no translation displayed yet.
I then looked at the string translations editor section of the tenant site and searched for all translations complete. There were no translations in the list. So I started to repeat those 66 translations inside the tenants editor section again one by one, hoping that the time stamp in those saved .MO files in the wpml folder would change. But his was not the case.
So I stuck again at the same point. Translations remain in the string translations editor but .MO files do not update.
Maybe I still oversee some configuration part. Any idea what could be the missing part?
Thanks
Ruediger
BTW: I still hold the support ticket open on Wildcloud and hope to get some more information from there. They are informed and on the same page.
If you can provide us with a test instance there, we can try to find specific workarounds. However, without full access to the test, we can only think of solutions theoretically.
the 'Pantheon' workaround sounds interesting to me, as this would be a tenant specific solution. Which is my focus for all string translations. Let me explain:
I was making some string transalations in the admin area of my version site to see if the related .MO files were written and saved thereafter in the wpml subfolder of the file system. Which was true. So I deployed this files to all tenant sites and the files showed up at each wpml subfolder too. But it did not result in displaying the translations on the frontend.
But this doesn't make sense anyway as any individual string translation for a specific tenant site would have to be made kind of 'globally' on the underlying version site and thereafter get deployed to all tenant sites running on that version. Apart of that it would recommend activating and configuring at least two WPML plugins (core and string) to make those translations happen. Which is not good, because the version site is intended to hold only the code of each pluging but WITHOUT activating the plugin itself.
While trying this kind of workaround there were two WP core updates to 6.5.2 and shortly thereafter to 6.5.3. The overall result apart of some other possible reasons was that I was running into a serious timeout desaster (503 for the version and 504 for the tenants) for all sites, which we had to resolve over the weekend first. I don't know yet which was the root cause but we are analyzing the log files.
Anyway, this is the reason why I don't think the 'sync-translation-files-for-multiple-server-setup' is a good idea. The support of Wildcloud has got both links from me and they are thinking about a workaround that might fix the problem. As soon as I get a proposal I'll let you know.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Hi Ruediger,
Thank you for the update. Please let me know once you receive feedback. If a satisfactory solution isn't found, my offer to test this in a WildCloud test environment with our devs remains open :).
the support of Wildcloud told me that there is no way to work with WPML services because of the restriction of WP core files in their environment. So I guess there is no doubt about anymore that it is a hosting related issue.
