Not sure if this is helpful but I noticed this is the wrong message in the first place. The string that should show up here has the key questycaptcha-createaccount

The falling back to the edit message seems to be caused by the circumstance that Mediawiki thinks the createaccount message is "disabled". Not sure why that is.

https://github.com/wbstack/mediawiki/blob/11e0db9a177a9a0b28313ec5575f89308de710fb/dist/extensions/ConfirmEdit/SimpleCaptcha/SimpleCaptcha.php#L316-L324

When removing the condition, the correct key will be picked, however it won't be rendered correctly either.

So the problem seems to be: when building the localization cache, the execution of LocalSettings.php will only load the ReCaptchaNoCaptcha extension. The code path that loads the QuestyCaptcha extension is not being covered, so the localization strings for Questy Captcha are not included in the build.

However, when trying to load both extensions at once, an error is thrown:

Fatal error: Uncaught RuntimeException: The configuration setting 'wgCaptchaClass' was already set by MediaWiki core or another extension, and cannot be set again by ReCaptchaNoCaptcha.

Also see: https://www.mediawiki.org/wiki/Topic:Xwa6maqqyoz0cx7g

Right now, I am not entirely sure how we can solve this problem without having to patch one of the extensions.

Ugly hack https://github.com/wbstack/mediawiki/tree/fr/l10n-hack

Got the following reply from IRC:

<Reedy> tarrow: https://noc.wikimedia.org/conf/highlight.php?file=wmf-config/extension-list
1:36 PM <tarrow> Reedy: and where is that fed into rebuildLocalisationCache.php or equivalent?
1:40 PM <Reedy> tarrow: https://gitlab.wikimedia.org/repos/releng/scap/-/blob/47f7311df48b756f3cafa620a25ae296464aff4c/scap/tasks.py#L718-723
1:40 PM probably a few levels of indirection
1:41 PM <tarrow> Cheers! That looks very close to what we're looking for; still trying to understand if I care about MessageFileList vs the Dirs equivalent

I'm coming to the conclusion; but haven't managed to check that mergeMessageFileList.php being passed an extension list may then provide something that can be consumed by RebuildLocalisationCache somehow

We talked to charlie and this isn't a blocker for shipping UI part (T352426) but we ought to get on and fix it soon

Despite some time enjoying "the tar pit" I failed to really understand what scap is doing and therefore have something to try and replicate. My best guess is:

/usr/local/bin/mwscript mergeMessageFileList.php "
        '--list-file="<file with a list of the extensions we use>" '
        '--output="<file to store the merged messages in>"'

followed by

/usr/local/bin/mwscript rebuildLocalisationCache.php

I believe we may simply need to strategically name the output file something like ExtensionMessages.php or ExtensionMessages-<version>.php and also pass a force-version or plain version flag to rebuildLocalisationCache.php