I still cannot reproduce. Are you sure it's not about the JobQueue?

Can you elaborate on "Special:PageTranslation will not work anymore". How does it not work? What do you see?

Good evening and thanks for the reply, here are some additional information

I am using a wiki Admin account logged in

If I have "$wgGroupPermissions['*']['read'] = true;" , when I add <translate> tags in a page, I can click on the "Mark this page for translation" link which redirect to a page like /mediawiki/index.php?title=Special:PageTranslation&target=Test5 and I can split the text, set language to translate and it is working. Furthermore the page /wiki/Special:SpecialPages , I can see and access the /wiki/Special:Translations + /wiki/Special:ImportTranslations + /wiki/Special:Translate + /wiki/Special:PageMigration + /wiki/Special:TranslationStats + /wiki/Special:PagePreparation + /wiki/Special:MostTranscludedPages + /wiki/Special:PageTranslation + /wiki/Special:SearchTranslations

If I have "$wgGroupPermissions['*']['read'] = false;" and "$wgGroupPermissions['user']['read'] = true; " , when I add <translate> tags in a page, it still redirect to /mediawiki/index.php?title=Special:PageTranslation&target=Test5 where I get the error

No such special page
You have requested an invalid special page.
A list of valid special pages can be found at Special pages.
Return to Main Page.

Here is the list of 3 Special Pages not visible anymore in /wiki/Special:SpecialPages and not accessible once I set "$wgGroupPermissions['*']['read'] = false;"

• Translation page migration => /wiki/Special:PageMigration => "No such special page" error
• Prepare page for translation => /wiki/Special:PagePreparation => "No such special page" error
• Page translation => /wiki/Special:PageTranslation => "No such special page" error

So my problem is that for some reason even logged in as an admin, I do not have access to 3 of the Special Pages listed above if I do not give read access to " "$wgGroupPermissions['*']['read'] = true"

Do you have any clue of the possible reason why am I missing these 3 Special pages or how I could debug this please ?

Thanks and Best Regards

Someone else had the same problem, I don't remember if it was you or someone else.

The thing is, the only possible causes I can think of are either that $wgEnablePageTranslation is set to false, or that some other bad extension (or LocalSettings.php?) overwrites $wgExtensionFunctions before the callbacks there are run. What extensions do you have installed?

Good morning

Thanks for the hints
I don't think I am the one that did report this problem. I am having this problem since a while in version 1.26.2but did not had taken the time to address it yet. My problem is that on a fresh new mediawiki installation where I only installed MediaWiki_Language_Extension_Bundle I was still having the problem

Info

1. And you're guess was right, during mediawiki installation, I did enable all available core extension including 'ConfirmEdit'
2. Now that I know the extension causing the problem, look what I found in google https://www.mediawiki.org/wiki/Topic:Rmhtjo61vj58l5pe that is why it is "ringing a bell" to you

Actions

1. I did disable ConfirmEdit and now the Translation pages are available again !!

@Nikerabbit:

1. In https://www.mediawiki.org/wiki/Help:Extension:Translate/Configuration#Sample_configuration I did see during setup the "Bug 34182: needed with ConfirmEdit" and I did insert the line but it did not help
2. Could you please confirm that the workaround in https://www.mediawiki.org/wiki/Help:Extension:Translate/Configuration#Sample_configuration even using the "*" group is not working and maybe add a warning to disable the 'ConfirmEdit' in this case ?

$wgGroupPermissions['*']['skipcaptcha'] = true; // Bug 34182: needed with ConfirmEdit

Thanks and Best Regards

### New core extension section ####

# Enabled extensions. Most of the extensions are enabled by adding
# wfLoadExtensions('ExtensionName');
# to LocalSettings.php. Check specific extension documentation for more details.
# The following extensions were automatically enabled:
wfLoadExtension( 'Cite' );
wfLoadExtension( 'CiteThisPage' );
#wfLoadExtension( 'ConfirmEdit' );
wfLoadExtension( 'Gadgets' );
wfLoadExtension( 'ImageMap' );
wfLoadExtension( 'InputBox' );
wfLoadExtension( 'Interwiki' );
wfLoadExtension( 'LocalisationUpdate' );
wfLoadExtension( 'Nuke' );
wfLoadExtension( 'ParserFunctions' );
wfLoadExtension( 'PdfHandler' );
wfLoadExtension( 'Poem' );
wfLoadExtension( 'Renameuser' );
wfLoadExtension( 'SpamBlacklist' );
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
wfLoadExtension( 'TitleBlacklist' );
wfLoadExtension( 'WikiEditor' );

It was actually https://www.mediawiki.org/wiki/Topic:Syqiagn418wtzb8n that I was thinking of. It seems to be an accident that ConfirmEdit also causes this issue, which is as far as I can see completely unrelated to the captcha issue.

I was able to reproduce. It only happens with ConfirmEdit in REL1_27, not in master branch. The fix is fc71c869e17dce2c283d8d2667f132f81820a8a5 which I have asked to backport.

For you, if you don't need the extension, disable it. You could try running the master version, but it might not be compatible.

Thank you, for the time being, I will keep the extension disabled and test once a backport is done in 1_27

Thanks and Best Regards

Change 307707 had a related patch set uploaded (by Florianschmidtwelzow):
Use TitleReadWhitelist for automatic whitelist

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

Change 307707 merged by jenkins-bot:
Use TitleReadWhitelist for automatic whitelist

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

The backport works for me.

Can this be closed now?

Good morning

I will test it when available in the 1.27.2 on my debian stretch and will give my feedback if you need it
Since several people did already test the backport and informed problem is fixed, you could close the ticket right now too

Thanks and Best Regards