How do I disable automatic translation file updates?

You could load the Loco Translate pluign and put your preferred translation in the loco custom directory. Loco will look after it. Its explained here:
https://localise.biz/wordpress/plugin/custom-translations

So, as WooCommerce develops over time, you will need to find and add the new translations to your version of the translation file. This could become a burden.

I don’t know why you would want to do this. If its a few words or phrases that annoy you, you could change these with the Say What? plugin, then allow WordPress and WooCommerce to just do their thing and keep translations up-to-date. Your customisations in Say What? will take precedence.

My WP already has many plugins and I don’t want to add more. I’ve always used the translation by making changes to the .mo and .po files and it’s always worked well. After a few updates, I got this error. Is there any way to block the translation update coming from WOO? Or force it to search for my custom translation file? I’ve also used the code below, as indicated in this link: https://woocommerce.com/document/como-traduzir-o-woocommerce-localizacao/ but it’s not working either.

function load_custom_plugin_translation_file( $mofile, $domain ) {
  if ( 'textdomain' === $domain ) {
    $mofile = WP_LANG_DIR . '/textdomain/yourtranslationfile-' . get_locale() . '.mo';
  }
  return $mofile;
}

Hi there @jrmarins,

I understand your concern here.

I came across a similar issue with a merchant who seems to have a possible temporary solution to this issue. Please try the steps shared in this thread and let us know if this makes any difference?

Also, be sure to make a full site backup and where possible, try these in a staging site to avoid making any changes to your live store.

Let us know how this goes.

Hi, @ckadenge.
Thanks for the reply.
I’ve been using this solution for a while now, but it’s temporary. From time to time, the deleted files come back. I don’t know if it’s WordPress that creates these files or WooCommerce, but they come back again and I have to check every day to delete them again.
I’d like a definitive solution for this. WooCommerce could allow me to place the customized .l10n.php file inside language/woocommerce and only search for the translation from there, as it used to work until recently.

Hi @jrmarins,

Thank you for sharing your updates with us. While I’m unable to tell if the issue is related to the core WooCommerce or WordPress plugin, I’d like to confirm that an update is yet to be released and should be able to address the issue with translations.

I hope this clarifies any concerns.

Thank you for your patience and understanding.

Hi @jrmarins,

I am the author of this thread.
Indeed, this turned out to be a temporary solution. It happens the same as with you. I’m furious again.
I’m not a programmer and to deal with these problems I’m wasting a hell of a lot of time and nerves to delve into their profession.

But look now:
In new versions of WooCommerce (after 9.3.3), in this file
/wp-content/plugins/woocommerce/includes/class-woocommerce.php
on row 871 they changed this:
unload_textdomain( ‘woocommerce’, true );
You need to delete “true “.
Let the row become like this:
unload_textdomain( ‘woocommerce’ );
Your translation files should now be loading.
It works for me, try it too.
This will still be a temporary solution until the next plugin update. But at least we won’t rub every day .json-s as abnormal.

Now, in the following code I try to enforce completely new rules so that we can ignore the problem automatically for the future. If you use it, you no longer need to delete “true” from their code.
This is my latest version that I finally got working for me. Put the code in functions.php or in your own plugin:

add_filter('woocommerce_generate_json_files', '__return_false');
add_filter('woocomerce_update_translations', '__return_false');
add_action('after_setup_theme', function() {
    $locale = apply_filters('plugin_locale', determine_locale(), 'woocommerce');
    if (function_exists('unload_textdomain')) {
        unload_textdomain('woocommerce');
    }
    $custom_mo_file = WP_LANG_DIR . '/woocommerce/woocommerce-' . $locale . '.mo';
    if (file_exists($custom_mo_file)) {
        load_textdomain('woocommerce', $custom_mo_file);
    }
});
add_action('init', function() {
    if (is_plugin_active('woocommerce/woocommerce.php')) {
        load_plugin_textdomain('woocommerce', false, plugin_basename(dirname(WC_PLUGIN_FILE)) . '/i18n/languages');
    }
}, 1);

• This reply was modified 3 months ago by senseart.

Hi, @senseart
Thanks for your help!
I’m currently testing another workaround. I changed the permissions of the woocommerce-pt_BR.l10n.php file to read-only permissions. So, theoretically, the woo plugin wouldn’t be able to replace the file. I’ll wait a few more days to see if it stays the same. In the meantime, I’ll wait for woo to update the plugin and resolve this error.
If my solution doesn’t work, I’ll test your code next.

Thanks.

Yes, I also went through the idea of ??banning the recording, but 2 things stopped me. First I don’t know where the error will show that it can’t overwrite a file and what then will be blocked from my site. And secondly, I was looking for a global solution so that I no longer had to deal specifically with this problem.
My bigger concerns, however, are that for WooCommerce, our problem is not a bug, because these are probably the new trends for a faster site, with the mandatory use of loading .json files, not .mo and .po files.
They just need to redevelop the plugin itself to make .json and from the custom files as well.

I’ve been testing it for a few days and so far it’s ok.

I don’t think there’s a problem, the store won’t stop working because the translation file hasn’t been updated, the most that can happen is a warning in the log.

If any problems appear I’ll post them here.

on row 871 they changed this:
unload_textdomain( ‘woocommerce’, true );
You need to delete “true “.
Let the row become like this:
unload_textdomain( ‘woocommerce’ );

I’m glad this works in your case but, of course, we made this change for a reason, as it allows the textdomain to be reloaded later on in the request. Without this, it’s possible you (or others following this approach) may hit situations where your site will be left untranslated.

Hi, Barry

I understand you, but we can’t leave our site to load random translations. The kind that someone has decided are global and end, and not good at all for our case.
Better to take the risk of my site suddenly showing up in all English instead of Bulgarian than having it always translated, but not the way it’s good for us. In the first case, I will immediately notice that something is wrong and begin manipulation immediately, while in the second case, it may take days or weeks until I understand that only some words have been substituted for others.
I’d rather risk the new types of text fields (new variables) appearing to me in English. That way I will immediately know that there is a new functionality and I need a supplement to my translation. I download, I translate, I replace, and I need to know that it will stay there as long as I need it.
In the past practice for personalized translations, everything was perfect. Every time we will use that now our site will have “random translation”. Sooner or later others in the world will have our problem – necessarily. They just don’t know it yet.

Hello senseart,

Thank you for your reply.

I understand your concern about your site’s translations being inconsistent or not meeting your specific needs.

As explained in the last message, this approach now ensures the text domain can be reloaded later during a request. This change reduces the risk of leaving your site untranslated, even if it differs from the personalized translation practice you found effective in the past.

If you have any follow-up questions, feel free to ask. ??

Have a great day!

Hi, @doublezed2 and @barryhughes-1
And what about custom translations from now on? Will we never be able to customize our translations through a file in a specific location again? Will we have to render yet another third-party plugin to overload our WP?
Or is WOO looking for a solution so that we can have a file with our translations?

I understand you, but we can’t leave our site to load random translations. The kind that someone has decided are global and end, and not good at all for our case.

Of course. You obviously have a good handle on the situation as it relates to your project. I was mostly adding that warning for the benefit of others (ie, please beware and exercise caution before editing core code in this fashion).

Or is WOO looking for a solution so that we can have a file with our translations?

We are looking into this. I do think it’s a bit of a historic anomaly that we have supported this (it feels like a generalized, non-WooCommerce specific solution would be superior) but also understand it is something you and many others rely on.