Add a way to disable asynchronous translation updates

[pavelevap]

Today I updated plugin on my localhost and there were also some language updates? But I did not want them, because I am working on localization files. How could WordPress on localhost update my development language files even if I did not choose it? My files were more recent than these from GlotPress. There are probably some Wordpress.org changes because it is first time I can see this?

I am using Czech version (cs_CZ), but also sk_SK was updated? Why? I tested this version in the past, but I do not want to update it (it is not active).

And why is there message "Plugin reactivated successfully." after each language update?

[nacin]

• It would help to see the complete output you see when you update.
• It updates everything that is installed.
• Core language packs just got turned on for 4.0-alpha builds. They are 3.9.1 strings, and there for testing purposes.

[pavelevap]

OK, main problems:

1) Language packs should be updated only when APPROVED by user. We can select plugins and themes, so why we HAVE TO update all language packs? Many users found that they can modify localization files on SAFE place in wp-content/languages which is no more SAFE? When somebody will try to translate some strings, language packs will deliver it to users even if they made custom profesional localization? I update one plugin and receive all current languages.

2) Localhost should be removed from overwriting files by automatic updates. It works for point releases etc. Localhost is developers work in progress, you SHOULD NOT change there anything by automat. You are not doing localization, but I do and you deleted my Poedit files without warning. I am not happy even if I have backup :-(

3) I do not want update all languages which I tested in the past. I want to update only current language. And only when I want to do it and select which one. How can I achieve this?

4) Which rules trigger language updates? You are checking my localization files? You are checking GlotPress?

Other testing:

I deleted current cs_CZ files to test and tried to update one theme. There were updates of cs_CZ and sk_SK (nothing changed - why update?) and twice. See screenshot.

After, there is still notice that my language files are out of date. And I can update again and again.

Message about reactivating plugin is gone now.

[pavelevap]

Today I updated one plugin and localization files were updated once again. And message "Plugin reactivated successfully." is back, see attached screenshot.

Could you please turn off these automatic updates for localhost? I am working on updated localization and really tired of backing up files a restore them. You are going to destroy many files on localhosts and testing developers installations :-(

I tried to add to my plugin file, but it does not work:

add_filter( 'auto_update_translation', '__return_false' );

[luciole135]

With any version of PHP I get the message "Some of your translations are not updated." that persists after the update of the French translation.
On 4.0-beta1-20140716 the problem is still here.

[SergeyBiryukov]

Related: #28949

[luciole135]

The problem is still not resolved with version 4.0-beta2-20140725.
Do you think you will be able to solve it before the official release?

[ocean90]

I can reproduce Update_missing_files.png​. Translations are updated twice when updating a theme. Both with the same object object(Theme_Upgrader)#4455 (6) {...}.

[pavelevap]

Severity "major" was added because WordPress is overwriting "safe" directory wp-content/languages. This directory was promoted for custom edits and every tutorial you can find, there is a notice "save your translation into wp-content/languages to avoid overwriting by plugin/theme". But this place is not safe anymore and it is major change for translators, because they are not warned (!) and their files are automatically overwritten.

[luciole135]

With any version of PHP I get the message "Some of your translations are not updated." that persists after the update of the French translation.
On 4.0-beta3 the problem is still here.

[WebNashr]

This problem is not just for localhosts but also for live sites. I for example didn't like some of translations and changed them for my live site. Now every time I update a plugin or theme I have to restore my translations and it's just impossible.
There must be a button in updates page for translations and only when an admin WANTS to update translations they update. The same way as plugins and themes.

[knutsp]

I think many site builders have started using wp-content/languages/plugins|themes/ as a safe location to store custom translations. This has been the case until language packs started to be implemented and updated.

We need a safe place for custom translations. I suggest this priority:

wp-content/languages/plugins|themes/custom/plugin|theme-name-la_CO.mo (new custom safe location)
wp-content/languages/plugins|themes/plugin|theme-name-la-CO.mo (for language-packs)
wp-content/plugins|themes/plugin|theme-specified-location-la_CO.mo (legacy)

(la_CO = language code)

This would be an enhancement. A new ticket?

[pavelevap]

knutsp: Yes, wp-content/languages is used as a safe location by many developers and translators and it is not possible to change it now and delete their customizations. What about create new specific directories? For example wp-content/languages/language-packs, wp-content/languages/language-packs/plugins and wp-content/languages/language-packs/themes for automatic updates? Or only wp-content/language-packs, etc.

[pavelevap]

Discussion in IRC makes me sad too :-(

Language packs should be updated only when APPROVED by user. We can select plugins and themes to update, so why we HAVE TO update all language packs?

Localhost (SVN) should be removed from overwriting files by automatic updates.

Nobody replied to my comment with issues: https://core.trac.wordpress.org/ticket/28571#comment:2

There are also many examples, how plugin authors recommend using wp-content/languages for custom localization files and edits:

​http://docs.woothemes.com/document/woocommerce-localization/#section-6
​https://easydigitaldownloads.com/docs/using-your-own-translation-files/

How can new system handle following situation? Frontend 100%, Administration 90%, Multisite 10%. What will be distributed to users? Now we can make a package, About page and some Help text were in English and all users were happy. And now? Only frontend file will be distributed? Then it is a regression because 90% of administration strings will be missing...

[markoheijnen]

I'm unsure what the best solution for this is, just like others. The assumption that wp-content/languages is a safe location to me is a bad one and I don't think because of that core should have their own language-packs folder inside languages.

Also the way WooCommerce and EDD describing seems to be more then fine. I checked the code from EDD and how they describe should not break because WordPress will store the files as /languages/plugins/edd-nl_NL.mo and not /languages/edd/edd-nl_NL.mo. That said, I have no clue how other plugins deal with it.

I do like the idea of having the default value of the filter auto_update_translation depending on the environment. But shouldn't it already being ignored if your installation is using version control or is this an exception?

About your last issue, currently someone can also package a language which isn't that well translated. Not to mention that users can download a package that is really old (2.8.5 is the oldest we currently have). So the new situation in general would be better.
What I would love to see is that we use the overall percentage and that needs to be higher then 90% (or any number) before showing up in the list. Otherwise users can download from the rosetta website.

[pavelevap]

markoheijnen: Thank you!

1) Safe location

Yes, assumption that wp-content/languages is safe can be bad, but really used. I did not notice that mentioned examples use other subdirectory. But see for example following links:

#23721 (and others). Users need some safe directory for modified localization files (and they use wp-content/languages now, especially for plugins and themes).

​https://wordpress.org/plugins/codestyling-localization-preserver/ Plugin to preserve modified localization files.

There was need for users to modify localization files, because of plugin and theme updates overwriting localization files. So, users started using wp-content/languages and nobody told them not to do it. And we have to deal with it even with WordPress core, because there will be more problems with themes and plugins. And overwriting modified localization files is not a good solution.

2) Approved language updates

I am not sure, why we can decide not to update WordPress, plugins or themes, but language updates are forced as default. I understand that it should work automatically for users not to bother them, but current (trunk) state is not ideal.

What about selection of available languages updates? Users can select what can be automatically updated (and they can change it in the future). It can be as simply as plugins or themes. Users can check WordPress, Akismet and uncheck Twenty Fourteen, because they have own customization here. And users know what will be automatically updated (no strange and hidden process in the background). And in this case we can forget for point 1, because users can simply choose not to update. Everybody happy...

3) Do not overwrite developers installations

I tried to add following code to plugin file (or functions.php in 2014 theme):

add_filter( 'auto_update_translation', '__return_false' );

Language updates still coming :-( Maybe it is due to SVN localhost installation? I am not sure, but it is really annoying because of using Poedit and my files are always overwritten.

4) Distribution of translation

I still think that some kind of button (checkbox per project in GlotPress) is needed. Instead of packaging the whole localized version, there could be a simple checkbox for every MAJOR version (minor can work automatically). It is still great improvement for translators, only one checkbox per project (for WordPress it should combine all subprojects), no problem with handling minor versions, etc. Translators could check when they think it is done and distribution can start. No script can find that localization is ready to use! As I wrote in my example (frontend 100%, administration 90%, multisite 10%), localization is ready and standard user does not notice any English strings. How can script do it? When administration was 88%, we did not want to allow distribution, because of About page was not complete (and every users will see it). So 88% for administration was not ready, but 90% was. In the next major version it can be different. No script can handle it and if it will be done in this way, translations will be postponed until 100% (so many users will not have their localized version, even if it is ready for using).

5) More languages

I tried Slovak version, but do not use it now. I do not want to automatically update all languages versions I tried in the past. How can I do it? Why there are inefficient checks for files which are not used? It can be automatically updated when I switch back to Slovak version? Users will be annoyed, because they can see that Slovak version is updated too and they do not know why (they forgot that they tried this version in the past).

6) Never ending out of date message

See new ticket: #28949.

7) Problem messages

Screenshots with errors are still valid. Also string "Updating translations for WordPress (cs_CZ)" is displayed several times and user do not know what is happening behind...

I can create new tickets for some of these issues, but some points in current state are BLOCKERS (regression, bad user experience, overwriting files), I guess.

[markoheijnen]

1) Safe location
I don't think we can help the plugin CodeStyling Localization Preserver in any way. They guessed the location was fine but it wasn't. What they could and should do is to release an update to move all those files to another location and hook into WordPress so those will get loaded. They should be able to use the hook override_load_textdomain.
Also I don't believe a typical user would change those files them self because in the end they need to concert the po file to mo.

2) Approved language updates
This one should always be done automatically because that fits to most our users. I will see if I can write a plugin that would allow you to stop updating certain languages of plugins/themes.

3) Do not overwrite developers installations
Never saw that but I will see if I can reproduce it.

4) Distribution of translation
Nacin did give an answer here: ​http://make.wordpress.org/polyglots/2014/08/11/trying-to-wrap-my-head-around-the-4-0/#comment-255912. I think it's not important for 4.0 to be fixed but we should evaluate the process when we have feedback from a group of translators.

5) More languages
I rather keep it there. There is no problem in updating all languages. Also there is no language switch in the admin possible so when you switch the language yourself it would mean it will take a while before the languages are updated.
Also when core does the updating then multilingual need to hook into something.

6) Never ending out of date message and 7) Problem messages
This are issues and hopefully can be addressed at some point.

[pavelevap]

Ad 1) Believe me, it is a common practice. I saw many custom localization files and that is why I am really worried about automatic updates (and overwriting files). I can also add other "tutorial" examples:

​http://blog.milandinic.com/2013/01/16/how-to-avoid-overwriting-of-wordpress-theme-translations/

It was mentioned sometimes (before language packs were alive) and it was quickly spread through translators community.

Ad 2) No, it could work automatically for new installations (and newly installed plugins and themes). But for current plugins and themes should be users notified and allowed to select what they want (your current localization or automatic updates). This is what users really want (know what is happening). There are many other custom localizations - somebody translate theme with Poedit and upload .po and .mo files. Now, somebody else translate theme in GlotPress and custom localization will be overwritten. It is really common, I saw custom localization files for about 10 % of installations...

Yeah, I know that it is maybe possible to make plugins for better language management, but I am worried about existing installations.

Ad 4) Nacin replied also here: ​http://make.wordpress.org/polyglots/2014/08/07/how-will-wordpress-4-0-language-installation-work-i/#comment-255969

It is very important for 4.0. How can I release language files in usual form (frontend 100%, administration 90% and multisite 10%). It is possible to start distributing this language version for 4.0? Translators should be involved during beta period, I do not understand why it was not tested yet a why there were no posts on Polyglots. You can design automatic system, distribute incomplete translation, overwrite custom localization files and then ask for feeadback?

Ad 5) There should be language switcher in administration for 4.0, as I remember. I can work with it in current trunk, see #15677. Yes, we can update everything, it is not a big deal, but I do not like it, because it is inefficient. Automatic system can be really smarter. But it is no blocker for 4.0, I guess.

​http://make.wordpress.org/core/2014/05/21/internationalization-goals-for-4-0/

There were many goals for 4.0 and I am not sure if everything is ready for release...

[ocean90]

Replying to ocean90:

I can reproduce Update_missing_files.png​. Translations are updated twice when updating a theme. Both with the same object object(Theme_Upgrader)#4455 (6) {...}.

Addressed in #29234.

[ocean90]

Replying to pavelevap:

I tried to add following code to plugin file (or functions.php in 2014 theme):

add_filter( 'auto_update_translation', '__return_false' );

Language updates still coming :-( Maybe it is due to SVN localhost installation? I am not sure, but it is really annoying because of using Poedit and my files are always overwritten.

The reason is that these translation updates are automatic/async and not in background (WP_Automatic_Updater is not used), which makes all the fiters and constants obsolete.

If you don't want file changes done by core, you should set the DISALLOW_FILE_MODS constant to true. If you don't want async translation updates you can remove the action:

remove_action( 'upgrader_process_complete', array( 'Language_Pack_Upgrader', 'async_upgrade' ), 20 );

[nacin]

Hmm. We should run auto_update_translation during async updates, I think. Asking dd32 for his thoughts.

[pavelevap]

ocean90: Thank you, but constant DISALLOW_FILE_MODS is not a solution, because it stops also plugin and theme updates? I tried also your remove_action example, but after upgrading one theme (Dashboard - Updates), language files were overwritten once again (using latest trunk)...

[ocean90]

Replying to pavelevap:
Try this one (PHP>=5.3):

add_action( 'upgrader_process_complete', function() {
	remove_action( 'upgrader_process_complete', array( 'Language_Pack_Upgrader', 'async_upgrade' ), 20 );
}, 1 );

[pavelevap]

Thank you, it works now! And is it possible to stop only core WordPress files and let plugins and themes to automatically update their language files? Automatic language updates should not run by default for localhost (SVN) because developers (translators) can test and modify localization files (it works fine for example for core automatic updates).

[pavelevap]

Ad 1) Safe location: Why language packs does not use as primary target directories defined by load_plugin_textdomain() and load_theme_textdomain()? It would really makes sense, these files are also overwritten by plugin/theme updates, so they could be automatically stored there?

[luciole135]

The problem is still not resolved with version 4.0-beta4-20140824.
Do you think you will be able to solve it before the official release?

[pavelevap]

ad 2) Are there any hooks which I could use to create list of available translations ready for updates (on Dashboard - Updates screen)? I tried to search, but I could not find anything (or was looking in the wrong way).

[valeriosza]

I do not know if it would be the right place.

but when I update the language packs, it shows that the update was successful, when back in the Updates screen, it says that the translation packages are outdated.

[luciole135]

Replying to valeriosza:

I do not know if it would be the right place.

but when I update the language packs, it shows that the update was successful, when back in the Updates screen, it says that the translation packages are outdated.

I reported the same problem regularly for six weeks already ...
And still no correction!

[ocean90]

Replying to valeriosza:

I do not know if it would be the right place.

It's not, please read #28949.

[luciole135]

Replying to ocean90:

Replying to valeriosza:

I do not know if it would be the right place.

It's not, please read #28949.

Yet Ipstenu (Mika Epstein) put the problem solved on alpha / beta and thanks Stephen to say it's here!
​http://wordpress.org/support/topic/translations-are-not-updated

[ocean90]

28571.2.patch​ adds two filters to Language_Pack_Upgrader::async_upgrade(), one to entirely disable asynchronous translation updates and one fine-grained filter for selective disabling, based on type.

[pavelevap]

And what about original point of this ticket? Do not overwrite languages automatically on developers (SVN) installations? And other problems, for example wp-content/languages not safe anymore for plugins and themes custom files?

[nacin]

28571.diff​:

• Simplify it to one async_update_translation filter, which mirrors auto_update_translation exactly. (If you have a callback other than returning true or returning false, you'll probably want the same logic in both cases.)
• Makes it so an SVN install doesn't see async upgrades at all. Small price to pay for now.

[pavelevap]

Nice, so I can use $language_update in async_update_translation for simply removing some theme from language updates?

Are there any hooks which could be used to create list of available translations ready for updates (on Dashboard - Updates screen)?

What about safe location?

[pavelevap]

And any chance "čeština" will be uppercased before release? :-) #29283

[nacin]

Replying to pavelevap:

Nice, so I can use $language_update in async_update_translation for simply removing some theme from language updates?

yes.

Are there any hooks which could be used to create list of available translations ready for updates (on Dashboard - Updates screen)?

yeah, somewhere. :)

What about safe location?

You can make your own if you wanted to. Untested, but this would probably work:

add_filter( 'load_textdomain_mofile', function( $mofile ) {
    $local_mofile = str_replace( WP_LANG_DIR . '/plugins/', WP_LANG_DIR . '/local-plugins/', $mofile );
    $local_mofile = str_replace( WP_LANG_DIR . '/themes/', WP_LANG_DIR . '/local-themes/', $mofile );
    if ( file_exists( $local_mofile ) ) {
        return $local_mofile;
    }
    return $mofile;
});

[pavelevap]

I tried to search, but I could not find anything usefull to modify Updates screen (or was looking in the wrong way). Is there really something (some action)?

As regards safe location: Yes, I know about load_textdomain_mofile. I have also plugin (contains some fixes for our language): ​http://wordpress.org/plugins/cestina-pro-wordpress/

But there is one important thing, current directory is used by many users for custom localization files. Beware of Polyglots revenge by deleting their files automatically :-)

[ocean90]

In 29694:

Language Pack Upgrader: Allow to disable asynchronously translation updates.

• Don't touch VCS installs.
• Use the async_update_translation filter (which corresponds exactly to auto_update_translation) to entirely disable it, or based on the update offer.

props nacin, ocean90.
fixes #28571.

[pavelevap]

There is a function list_translation_updates() which is called in wp-admin/update-core.php, but without any available action? There is only core_upgrade_preamble action, but this is bellow all updates. There should be any action to allow similar behaviour as it works for themes and plugins? Should I reopen or create new ticket? Or is there any other way?

[ocean90]

Replying to pavelevap:
Please create a new ticket for this enhancement. It should also include a good use case and maybe also a patch.

For 4.0 you can hide the form with CSS (form[name="upgrade-translations"] {display:none;} and add your own with the core_upgrade_preamble action.