Make WordPress Core

Opened 10 years ago

Closed 9 years ago

#28949 closed defect (bug) (fixed)

endless loop in wordpress updates translations

Reported by: kniebremser's profile 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

#3 follow-up: @ocean90
10 years ago

  • Milestone changed from Awaiting Review to 4.0

#4 in reply to: ↑ 3 @Kniebremser
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 @ocean90
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 @pavelevap
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 @ocean90
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 @knutsp
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 @pavelevap
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 @johnbillion
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.

#11 @ocean90
10 years ago

  • Keywords close added

#12 @a4jp.com
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 @nacin
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: @pavelevap
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 @ocean90
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 @pavelevap
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 @ocean90
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 @pavelevap
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 @SergeyBiryukov
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 @pavelevap
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 @Kniebremser
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 @nacin
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

It's the same thing.

#23 follow-up: @GregLone
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 @DaMsT
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 @nacin
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.

#26 @GregLone
10 years ago

Still...

#27 @a4jp.com
10 years ago

I have the language file update loop on Japanese websites as well.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


10 years ago

#29 @nacin
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 @nacin
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 @knutsp
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 @GregLone
10 years ago

I think we should have a word to @blamenacin ;-)

Version 0, edited 10 years ago by GregLone (next)

#34 @Kniebremser
10 years ago

Thank you, Nacin.

#35 @knutsp
10 years ago

Learn from this.

  1. Let all new things be testable during beta and RC cycle
  2. 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"
  3. 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!

#36 @ocean90
10 years ago

#29168 was marked as a duplicate.

#37 @deryasari
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?

https://wordpress.org/support/topic/wordpress-45-translations-wont-stay-updated?replies=3#post-8333639

Can the fix be reintroduced? -Thanks.

#38 @ocean90
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Summary changed from endless loop in wordpress updates translations (v4.5+) to endless loop in wordpress updates translations

@deryasari Thanks for your report, I'll respond to your post on the support forums.

Note: See TracTickets for help on using tickets.