Setting to major; for templates this means making them unusable.

This is all related to using master/slave setup. Wikimedia does not have an environment where this can be reliably tested, so we cannot work towards resolving this.

Amir, I see you are changing priorities. Does this mean that as a product manager, you're going to put resources to fixing this issue? If so, can you please indicate where I can see how this issue is being treated on your backlog?

• Bug 66416 has been marked as a duplicate of this bug. ***

This also happens on Wikidata. Example:

[[d:Wikidata:Status updates/2014 07 12]] (marked for translation at 21:03, 12 lug 2014)

[[d:Wikidata:Status updates/2014 07 12/en]] (page still does not exist as of now)

This bit me again today. Any chance it might get fixed?

In T56579#1394150, @JeanFred wrote:

This bit me again today. Any chance it might get fixed?

I do want this bug fixed. Due to nature of the bug (not easiest to reproduce) and other commitments I cannot give you a good estimate though.

We may have a first example from a non-WMF wiki: https://meta.miraheze.org/w/index.php?title=Special%3ALog&type=pagetranslation&user=&page=Request+features%2Fheader but https://meta.miraheze.org/w/index.php?title=Request+features%2Fheader/en&action=history
I asked @Reception123 to provide further information on their setup etc.

have more details on the setup

@Nemo_bis @Reception123: actually this happened because I disabled the cronjob for runJobs.php (the reason for that is not related to this task, but because of a wiki import). Because that wiki import is (mostly) done now, I re-enabled the cronjob, and the Translate pages look good again.

What is the workaround for this bug in the meantime? Are you supposed to manually create the /en page?

@kaldari now you need to mark the page for translation, then do a useless dummy edit (common thing is adding/removing space inside <languages />), mark the page for translation. Sometimes it is not enough and you need to make another useless dummy edit and again mark the page for translation. After these 2 or 3 markings FuzzyBot usually awakes and the /en subpage is created.

The same is to be done if you are adding new translation units to the text, otherwise it's impossible to translate them.

Fortunately it is not required to do it when you just modified existing units.

If you just modified translation page template sometimes it is easier to manually update translations pages (by adding a new line in a unit of its translations which would not actually add anything but will cause the page to be updated which would look like your edit) than to do all that stuff of poking FuzzyBot (especially if there's just 1 or 2 translation pages).

That's what translate adminship looks like nowadays. I must say that while its OK to do once or twice, when you are doing it regularly it becomes really, really, really annoying. (Especially when you discover that some important template works a wrong way because 3 days ago when you were editing it you have forgotten to do this stuff of repeated markings for translation which is like your fault but actually it's the fault of the damn bug since you are not actually normally required to do all this black magic rites in order to make things work)

This occurs repeatedly on wikimania2017wiki, which uses language features heavily including translatable templates.

This occurs repeatedly

Yes, this happens nearly 100 % of the times one marks a page for translation.

While investigating T53731, I also had a look into this. The problem here is that when the MessageUpdateJob does the edit during the first mark for translation, PageTranslationHooks::onSectionSave() terminates at if ( !$handle->isPageTranslation() || !$handle->isValid() ) conditional because isValid() is false for some reason and the TranslateRenderJob that usually creates the page doesn't get run. Maybe the source language page should be created when the page is marked for translation for the first time instead of depending on the save hook (through MessageUpdateJob) to create the /en page?

Change 281698 had a related patch set uploaded (by Glaisher):
Rebuild MessageIndex before running TranslateRenderJobs on source lang translatable page

https://gerrit.wikimedia.org/r/281698

Change 281698 merged by jenkins-bot:
Move several updates to TranslationsUpdateJob when page is marked for translation

https://gerrit.wikimedia.org/r/281698