https://gerrit.wikimedia.org/r/#/c/29431/

Please test whether that change has fixed the problem.

(In reply to comment #2)

Please test whether that change has fixed the problem.

Related?

PHP fatal error in /usr/local/apache/common-local/php-1.21wmf3/extensions/Translate/tag/PageTranslationHooks.php line 248:
Call to a member function getSourceLanguage() on a non-object

Wikimedia error got when trying to properly move the page mentioned on bug 42025. Move seems to have failed (unless it's still in job queue).

(In reply to comment #2)

Please test whether that change has fixed the problem.

Unfortunately it hasn't. I get the same error when trying the move from above (https://meta.wikimedia.org/wiki/Special:MovePage/Research:Wikipedia_Editor_Survey_August_2012/Questions):

Request: POST http://meta.wikimedia.org/wiki/Special:MovePage/Research:Wikipedia_Editor_Survey_August_2012/Questions, from 208.80.154.8 via cp1001.eqiad.wmnet (squid/2.7.STABLE9) to 10.64.0.132 (10.64.0.132)
Error: ERR_READ_TIMEOUT, errno [No Error] at Wed, 14 Nov 2012 09:18:51 GMT

It's probably depending on proper fix of 41278 then.

I can't test this bug now because for some reason it finds only 29 pages to move (only translation pages, no translation unit pages), which of course avoids the timeout...

Has it been partially moved?

Lqt is not enabled on meta so I it can't be causing the slowness :(.

On the other hand Seddon just moved successfully some other page, but I don't know what is the limit of pages causing timeout.

(In reply to comment #7)

Has it been partially moved?

I don't think so, all the pages seem there.

Lqt is not enabled on meta so I it can't be causing the slowness :(.

Never underestimate the power of the brokenness in LQT. :p

On the other hand Seddon just moved successfully some other page, but I don't
know what is the limit of pages causing timeout.

That page was any close to 3000 translation units like this.

I think fixing this no longer depends on bug 42244, and removing the "always UPDATE" from LQT basically resolved this issue. So I'm closing it.

Feel free to reopen with actionable new information if there remains anything.

There's no indication that this was fixed, comment 6 is still current.
However, this time I was less wise and – hoping this had really been fixed – I confirmed the move, which wasn't completed nor logged, so we're now in a situation like bug 44865.
Is the translatable page corrupt forever?

I haven't been able to reproduce this locally. I need help to debug this on wmf servers.

We're scheduling this for the current sprint. It's very hard to reproduce. We are going to do that on test2 initially. If we cannot reproduce there, we may have to test it in a production wiki.

Gerrit 56115

Patch has been merged. We're going to test on test.wikipedia.org with a page with 23 translations and 605 sub pages.

(In reply to comment #14)

Patch has been merged. We're going to test on test.wikipedia.org with a page
with 23 translations and 605 sub pages.

About 3 hours later, it got moved. https://test.wikipedia.org/w/index.php?title=Special:Contributions/FuzzyBot&dir=prev&offset=20130327125000&limit=632&target=FuzzyBot
I purged the translatable page and all the translation pages appeared on the language bar, although marked as empty (normal; translation percentages usually takes a couple weeks to update, in my experience), and translations are there.
When this is deployed on Meta and I figure how to reverse the partial move caused by bug 44865 (see comment 10), I'll test with the page from comment 0.

Comment 0 page fixed as well, all pages moved smoothly (4837 moves in total)
https://meta.wikimedia.org/w/index.php?title=Special:Contributions/FuzzyBot&dir=prev&offset=20130406204951&limit=4837&target=FuzzyBot although I still don't see the completion message in [[m:Special:Log/pagetranslation]].