Home›Support›English Support›[Resolved] String translation generates .mo files for product attributes and we want them saved only in databas...
[Resolved] String translation generates .mo files for product attributes and we want them saved only in databas...
This thread is resolved. Here is a description of the problem and solution.
Problem: You are using WPML to translate WooCommerce admin texts, but the plugin generates .mo and .php files for product attribute translations, which you prefer to store only in the database. This issue is causing difficulties in changing translations of WooCommerce product attributes and caching problems with custom post types. Solution: WPML generates .mo files to utilize WordPress core's translation loading optimizations. Currently, WPML does not offer an option to disable the generation of .mo files. If you're experiencing issues with changing or retranslating product attributes, we recommend opening a new support ticket for further debugging. Additionally, the JSON files you mentioned are not related to WPML but are part of WordPress. For more details on these files, you can visit https://wordpress.stackexchange.com/questions/326332/unknown-language-json-files.
If this solution does not apply to your case, or if it seems outdated, please check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. We highly recommend opening a new support ticket if further assistance is needed. You can do so 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.
Background of the issue:
I am using WPML to translate WooCommerce admin texts like the store address. After using String translation, the plugin started generating .mo and .php files for content not translated using String translation. The files include 'wordpress-LANG.mo' and 'wordpress-LANG.l10n.php', which store product attribute translations. I want these translations stored only in the database.
Symptoms:
The plugin generates .mo files for product attributes, which I want stored only in the database.
Questions:
Why does WPML generate .mo files for product attributes when I only translated WooCommerce admin texts?
How can I ensure product attribute translations are stored only in the database?
Thank you for contacting WPML support.
While you are waiting for one of my colleagues to take this ticket and work on it, let me provide you with the first debugging steps or if I can help with the issue quickly.
WPML generates .mo files to leverage how WordPress core loads translations. WPML creates these files from the translations stored in the database so your site can benefit from WordPress’s built-in performance optimizations when loading strings.
At the moment, WPML does not include an option or setting to completely disable generating .mo files.
Can you please elaborate on why this is an issue for your client? If it's a common scenario we may consider this as a feature request, but in any case, it will take time 🙁
I wouldn't agree that WPML generates those files for all of the translations as those files didn't appear until we translated a few strings using String translation.
We use WPML on a lot of other projects and don't have those files on any of them. This is the first time seeing those files. Since those files appeared, it's been impossible to change translations of WooCommerce product attributes. Which I don't think needs explanation why it's an issue. Furthermore, we seem to be having caching problems with custom post types, whose slugs translations are for some reason also stored in those files.
Why are there so many language .json files for one language? (I'm attaching a screenshot).
it might be that it did not appear at first, but most of the content is saved like this. Whatever you can see in WPML String translation is saved as MO files inside languages/wpml folder. So it is page builder content, taxonomies, slugs, admin text, PHP strings and etc.
If you have can not change /retranslate a product attribute that looks like an issue but should not be caused by what you reported. I advise opening a new ticket so we can debug it further.
As for JSON files, these do not come from WPML. The files you see in the languages folder are not from WPML; we have a different folder inside "wpml". JSON are WordPress files:
I still wouldn't agree that most of the content is saved like this and it's an issue since client can edit translations on the production site, which are then stored in those files in languages/wpml folder. But if I don't have those files locally, I'd overwrite their translations when I deploy new updates to the code.
Pulling the files from production every time I want to deploy code changes to not lose translations from production just isn't a good workflow for us. And I don't understand how to avoid that issue.
Thanks for getting back to me. I can understand your trouble, but I am afraid not much I can do to help here. This is the expected way WPML works and has worked.
You can check for texts in WPML String translation, and most of them are saved in those files. Except for page content or similar that can be saved in post meta translation table and etc. Also most of these texts are static ones like PHP translation or attribute name / page slugs and etc, so it should not require many updates when deploying.
Hope this helps a bit; let me know if you have any other questions.
The website we have problems with has a lot of content, for example there are over 800 product attributes, so it is a big issue when deploying.
Sometimes we cannot even edit the translations, and when that happens I have to delete the PHP langugae file from the server and translate the attribute label again.
The files wouldn't be a problem if they worked properly, but clearly they don't, and interfering with content and having to delete files directly from the server because of content issues is not something any developer would be happy with, nor is our client.
We have to launch soon and I already see that it's going to be a daily issue with the client because the files aren't generated properly and it blocks the translations from being added / edited. Can you at least look into files being generated properly without the need to delete them for them to regenerate?
New threads created by Dražen and linked to this one are listed below:
