Opened 10 years ago
Closed 9 years ago
#28949 closed defect (bug) (fixed)
endless loop in wordpress updates translations
Reported by: | Kniebremser | Owned by: | |
---|---|---|---|
Milestone: | WordPress.org | Priority: | normal |
Severity: | normal | Version: | 4.0 |
Component: | Upgrade/Install | Keywords: | |
Focuses: | Cc: |
Description
I use WordPress 4.0 trunk in german. I always get a message that is not up to date translation. I click on update, the German language file is updated. WP tells me everything is fine. Not a minute later I get back the message: a translation is not up to date, it is again updated the German language file. The whole can I repeat throughout the day.
Change History (38)
This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.
10 years ago
#4
in reply to:
↑ 3
@
10 years ago
Replying to ocean90:
Hallo Dominik!
Ich habe erst die Diskussion auf irc verfolgt.
Wäre es nicht einfacher die Aktualisierung für WordPress Übersetzungen temporär zu deaktivieren, wenn man trunk im alpha-Stadium installiert hat. Die Aktualisierungen werden erst ab einem bestimmten Punkt aktiviert, z.B. Beta 1.
Der Abgleich der Sprachversion darf auch nicht das Datum der Beta oder RC beinhalten. Das wäre zuviel Aufwand. Jeden Tag für jede Sprache eine neue Version.
Das ganze ist nur eine Idee von mir. Ich habe noch eine andere, aber da weiss ich nicht, ob dies technisch machbar ist.
Grüße aus Kölle
#5
@
10 years ago
- Milestone 4.0 deleted
- Resolution set to invalid
- Status changed from new to closed
After some testing there is nothing wrong here. The API currently only returns language packs for tests.
// $url https://api.wordpress.org/core/version-check/1.7/?version=4.0-beta4&php=5.5.10-1%2Bdeb.sury.org%7Eprecise%2B1&locale=de_DE&mysql=5.5.35&local_package=&blogs=1&users=1&multisite_enabled=0" //$options array(4) { ["timeout"]=> int(3) ["user-agent"]=> string(38) "WordPress/4.0-beta4; http://de.wp.dev/" ["headers"]=> array(2) { ["wp_install"]=> string(17) "http://de.wp.dev/" ["wp_blog"]=> string(17) "http://de.wp.dev/" } ["body"]=> array(1) { ["translations"]=> // This is originally a json string array(4) { ["admin"]=> array(1) { ["de_DE"]=> array(4) { ["POT-Creation-Date"]=> string(0) "" ["PO-Revision-Date"]=> string(24) "2014-05-08 10:32:15+0000" ["Project-Id-Version"]=> string(14) "Administration" ["X-Generator"]=> string(13) "GlotPress/0.1" } } ["admin-network"]=> array(1) { ["de_DE"]=> array(4) { ["POT-Creation-Date"]=> string(0) "" ["PO-Revision-Date"]=> string(24) "2014-04-15 09:13:30+0000" ["Project-Id-Version"]=> string(13) "Network Admin" ["X-Generator"]=> string(13) "GlotPress/0.1" } } ["continents-cities"]=> array(1) { ["de_DE"]=> array(4) { ["POT-Creation-Date"]=> string(0) "" ["PO-Revision-Date"]=> string(24) "2011-12-08 16:48:38+0000" ["Project-Id-Version"]=> string(19) "Continents & Cities" ["X-Generator"]=> string(13) "GlotPress/0.1" } } ["default"]=> array(1) { ["de_DE"]=> array(4) { ["POT-Creation-Date"]=> string(0) "" ["PO-Revision-Date"]=> string(24) "2014-05-08 10:38:43+0000" ["Project-Id-Version"]=> string(11) "Development" ["X-Generator"]=> string(13) "GlotPress/0.1" } } } } } // respond array(2) { ["offers"]=> array(2) { [0]=> array(10) { ["response"]=> string(11) "development" ["download"]=> string(57) "https://wordpress.org/nightly-builds/wordpress-latest.zip" ["locale"]=> string(5) "en_US" ["packages"]=> array(5) { ["full"]=> string(57) "https://wordpress.org/nightly-builds/wordpress-latest.zip" ["no_content"]=> bool(false) ["new_bundled"]=> bool(false) ["partial"]=> bool(false) ["rollback"]=> bool(false) } ["current"]=> string(18) "4.0-beta4-20140816" ["version"]=> string(18) "4.0-beta4-20140816" ["php_version"]=> string(5) "5.2.4" ["mysql_version"]=> string(3) "5.0" ["new_bundled"]=> string(3) "3.8" ["partial_version"]=> bool(false) } [1]=> array(10) { ["response"]=> string(10) "autoupdate" ["download"]=> string(57) "https://wordpress.org/nightly-builds/wordpress-latest.zip" ["locale"]=> string(5) "en_US" ["packages"]=> array(5) { ["full"]=> string(57) "https://wordpress.org/nightly-builds/wordpress-latest.zip" ["no_content"]=> bool(false) ["new_bundled"]=> bool(false) ["partial"]=> bool(false) ["rollback"]=> bool(false) } ["current"]=> string(18) "4.0-beta4-20140816" ["version"]=> string(18) "4.0-beta4-20140816" ["php_version"]=> string(5) "5.2.4" ["mysql_version"]=> string(3) "5.0" ["new_bundled"]=> string(3) "3.8" ["partial_version"]=> bool(false) } } ["translations"]=> array(1) { [0]=> array(7) { ["type"]=> string(4) "core" ["slug"]=> string(7) "default" ["language"]=> string(5) "de_DE" ["version"]=> string(9) "4.0-alpha" ["updated"]=> string(19) "2014-01-01 00:00:00" ["package"]=> string(60) "https://global.wordpress.org/builds/core/4.0-alpha/de_DE.zip" ["autoupdate"]=> bool(true) } } }
See also comment:1:ticket:29233 and comment:1:ticket:28571.
A flag/filter to disable async upgrades is handled in #28571.
#6
@
10 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Yes, I know, that is only for testing purposes, but then there should be delivered language version only in the case of change in GlotPress? I updated language packs, did not make any changes on GlotPress side, so there is no need to update languages (.po file header is newer then latest GlotPress change). And languages are not up to date. This ticket should be open, until testing mode works correctly, I guess...
#7
@
10 years ago
- Resolution set to invalid
- Status changed from reopened to closed
pavelevap, please be a little bit more patient.
After the first real language packs are out and the issue still exists we can re-open this. But not now.
#8
@
10 years ago
The point of testing is to be able to report errors, yes?. There is something wrong when it behaves like this, even if it's expected at the current lever of completion. The issue exists, but it will probably be fixed in due time, ok. But this ticket should be open until it can be solved as "fixed".
It doesn't matter if it probably is the wp.org API that needs to change. This affects core functionality, and should be tracked as a core issue for trunk until all facts are at the table.
It's discouraging to see this ticket insistingly being closed as "invalid" when it's not.
#9
@
10 years ago
knutsp: I agree.
ocean90: Exactly, I was patient really long time (problem was reported 2 months ago in other ticket). And reported issue does not work in current trunk and it is real problem. Tickets are usually closed when issue is fixed. I do not understand why it should be closed when it is not fixed (one week before release). I will not reopen this once again to avoid confusion, but this issue is not fixed and should not be marked as fixed.
#10
@
10 years ago
- Milestone set to 4.0
- Resolution invalid deleted
- Status changed from closed to reopened
Language packs are a work in progress, but this is still a current issue that needs to be tracked.
#12
@
10 years ago
http://wordpress.org/support/topic/is-the-core-update-message-buggy?replies=10#post-5922248
Just the same problem here. The update says it is successful but the update icon says it needs to be updated every time.
#13
@
10 years ago
- Milestone 4.0 deleted
- Resolution set to worksforme
- Status changed from reopened to closed
I'm going to close this. It will be handled when new packages are built. All that's being seen right now is the persistent nag not unlike the request to always update to the latest nightly core build. If it is still a problem come 4.0-RC, please reopen.
#14
follow-up:
↓ 15
@
10 years ago
Still does not work (even if RC1 version), should I reopen? Also, updated language files are for 3.9.x branch and not for Development GlotPress project.
#15
in reply to:
↑ 14
@
10 years ago
Replying to pavelevap:
That's correct. Language packages aren't re-build yet, see http://api.wordpress.org/translations/core/1.0/?version=4.0.
#16
@
10 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
1) Neverending loop is still there.
2) When updating plugin from Plugins screen, there is following message: "Invalid Data provided." during automatic language packs update. When updating same plugin through Dashboard - Updates, then everything works.
3) After updating language packs, there are files from 3.9.x branch even if I am using 4.0 RC1.
#17
@
10 years ago
- Resolution set to worksforme
- Status changed from reopened to closed
For point 1 and 3:
It will be handled when new packages are built.
For point 2:
Create a new ticket please.
#18
@
10 years ago
ad 1 and 3) Nacin wrote that it should be reopened when it does not work during RC, see https://core.trac.wordpress.org/ticket/28949#comment:13:
"If it is still a problem come 4.0-RC, please reopen."
ad 2) #29425
#19
@
10 years ago
Unless I'm missing something, the endless loop here is the same loop we have for betas in general, i.e. it always says there's an update if you're on a development version.
#20
@
10 years ago
Sergey: Maybe you are right, but nobody told us about it. But in this case, it would be nice to have also latest localization files from Development GlotPress branch installed (current are 3.9.x). And it also shows 1 update available for localization files, but not for development WordPress version. There should be also notice "You are using a development version..." like for WordPress files.
#21
@
10 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
Hi Guys!
Excuse me, I need to open the ticket again.
Have 4.0 Final installed and the problem is still there.
Now I will be offered again by the new German language pack fürRC2.
#22
@
10 years ago
- Resolution set to fixed
- Status changed from reopened to closed
It's the same thing.
#23
follow-up:
↓ 24
@
10 years ago
Still there in 4.0 stable: always has an update for fr_FR and fetches the RC2.
#24
in reply to:
↑ 23
@
10 years ago
Replying to GregLone:
Still there in 4.0 stable: always has an update for fr_FR and fetches the RC2.
+1 sv_SE
#25
@
10 years ago
The translations were marked RC2 but they were the 4.0 final translations. Think of it as 4.0-RC2+.
I've shifted everything to "4.0" now, though.
This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.
10 years ago
#29
@
10 years ago
- Keywords close removed
- Milestone set to WordPress.org
- Resolution fixed deleted
- Status changed from closed to reopened
Okay, actively investigating this again.
#30
@
10 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Hey all. I'm very sorry about this. I was wrong this whole time. It was absolutely a bug in the API.
The installed languages that get sent to the API for parsing get passed off to the translations library, specifically check_for_translations_of_installed_items(). That function is fine, it's what gets passed in that wasn't. It needed to pass in specifically that textdomain's languages, not everything that gets sent. For core, it was passing everything, so looking for a key of 'ru_RU' made no sense because it was at ['default']['ru_RU']
.
Passing through the 'default' data wasn't enough, though. The language pack is identified by the PO-Creation-Date, which for a core language pack is the latest date of all containing PO files (default, admin, admin-network, and cc). So it had to figure out which one has the latest date based on the data passed back and then make sure that's the date that gets passed through for comparison.
This is now all fixed and has been deployed for the last 50 minutes or so. Sorry again for the trouble.
#31
@
10 years ago
Wow!
Thank you, Nacin.
I think some of us contributing on this ticket got a bit frustrated, being closed several times.
#33
@
10 years ago
I think we should have a word to @blamenacin ;-)
#35
@
10 years ago
Learn from this.
- Let all new things be testable during beta and RC cycle
- Don't be so "trigger happy" to close a ticket when the issue still exists, even if it can be explained and "will be fixed"
- Essential wp.org APIs that directly affects core is not "just" a meta ting, but a concern for core
We all do wrong assumptions, and assumptions in general. That is not the main problem here, but it contributed. What was missing was a bit of humbleness, and respect for the ones testing and giving feedback.
Nacin seems to have been alone on this. Nacin is a human being. Why is he alone on these issues?
But I'm so happy this was finally resolved, I forgive anything.
We learn! Cheers!
#37
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
- Summary changed from endless loop in wordpress updates translations to endless loop in wordpress updates translations (v4.5+)
Hello everyone,
The bug is back. It reappeared in v4.5 and has persisted in 4.5.1 and 4.5.2. Running english version site and update loop is there again. How did it make it back into release?
Can the fix be reintroduced? -Thanks.
Related: #28571