(In reply to comment #0)

But with the new integration of the CentralNotice and
Translate extensions, setting the state became a mandatory part of the
workflow
for banner translations.)

It always was, though not respected consistently.

(In reply to comment #1)

(In reply to comment #0)

But with the new integration of the CentralNotice and
Translate extensions, setting the state became a mandatory part of the
workflow
for banner translations.)

It always was, though not respected consistently.

Mandatory by what definition? I meant mandatory in the sense of "necessary for the translation to appear in the location where readers are supposed to read it". That's the banners in case of CentralNotice, and the actual software interface in the case of UI messages being translated on Translatewiki. But most translations on Meta-wiki differ from that, in that the page where the translation happens is identical to the page where readers will read the result.

I'm marking this duplicate of bug 53748. It doesn't have the same detail but it is the root cause for this.

• This bug has been marked as a duplicate of bug 53748 ***

Just for fun I generated some pretty graphs about loading the URLs in comment 0, but it's useless because now the loading stops after about 6 s only and the workflow state selector never appears (aborted because of timeout).
http://www.webpagetest.org/result/131128_65_QA9/
http://www.webpagetest.org/result/131128_H3_QBE/
http://www.webpagetest.org/result/131128_DW_QK4/

(In reply to comment #4)

Just for fun I generated some pretty graphs about loading the URLs in comment
0, but it's useless because now the loading stops after about 6 s only and
the
workflow state selector never appears (aborted because of timeout).
http://www.webpagetest.org/result/131128_65_QA9/
http://www.webpagetest.org/result/131128_H3_QBE/
http://www.webpagetest.org/result/131128_DW_QK4/

I've rerun them and now the screenshot at completion includes the workflow selector. Yay!