Steps to replicate the issue (include links if applicable):
What happens?:
There's a text with content ⧼mobileoptions⧽
What should have happened instead?:
⧼mobileoptions⧽ should be an actual translation.
Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
/
Other information (browser name/version, screenshots, etc.):
/
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Make SpecialMobileOptions an UnlistedSpecialPage | mediawiki/extensions/MobileFrontend | master | +2 -2 |
Caused by c9c359be345e65575574b0b419e29cd876aa3570 (which fixed T365769) as subclassing the old MobileSpecialPage by default would create an UnlistedSpecialPage (see MobileSpecialPage::$listed and MobileSpecialPage::isListed()) but in folding the class' functionality into SpecialMobileOptions it was changed to extend regular SpecialPage instead of UnlistedSpecialPage nor does it call $this->isListed( false ); anywhere; hence the behavior you're seeing (an undefined string appearing on Special:SpecialPages).
The big thing here is to decide whether this was a regression or an intentional behavior change, because if the latter, the i18n string would need to be added (and in due time, translated); if this is a mere regression, it can be fixed by making the special page class an unlisted one again.
I think this should have remained an unlisted special page. Thanks for the diagnosis @ashley !
Change #1046766 had a related patch set uploaded (by Sportzpikachu; author: Sportzpikachu):
[mediawiki/extensions/MobileFrontend@master] Make SpecialMobileOptions an UnlistedSpecialPage
Change #1046766 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Make SpecialMobileOptions an UnlistedSpecialPage
Confirmed fix on https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:SpecialPages#mw-specialpagesgroup-other
Fix will go out with the deployment this week and be everywhere by Thursday.
Thanks @Kizule for raising this issue, @ashley for debugging and @Sportzpikachu for the fix!