Page MenuHomePhabricator

Custom system message no longer recognized on "Special:UploadWizard"
Closed, DuplicatePublic

Description

Setup

  • MediaWiki 1.33.4 (8f927cb) 17:20, 24 June 2020
  • PHP 7.2.24-0ubuntu0.18.04.7 (apache2handler)
  • MariaDB 10.1.47-MariaDB-0ubuntu0.18.04.1
  • Upload Wizard 1.5.0 (ac21297) 16:39, 25 March 2019

Issue
Original reported on the I18n mailing list.

I added a new system message key to the UploadWizard extension via configuration in the "LocalSettings.php" file called "mwe-upwiz-license-c". On the special page "UploadWizard" which is using it, it is shown as expected as <mwe-upwiz-license-c>. Now I added my translations to "MediaWiki:Mwe-upwiz-license-c" and "MediaWiki:Mwe-upwiz-license-c/en" etc. respectively. However on special page "UploadWizard" it still shows as <mwe-upwiz-license-c> after adding the translations.

Just to cross-check if MediaWiki recognizes my translations I added {{int:mwe-upwiz-license-c}} to my test page. Here everything shows up as expected and changes depending on the user preferred language.

This is what I have tried apart from also using a fresh browser:

  • Setting $wgMainCacheType =CACHE_NONE; did not work.
  • Setting $wgParserCacheExpireTime = 0; dit not work
  • Running the "rebuildmessages.php" maintenance script did not work.
  • Running the "rebuildLocalisationCache.php" maintenace script did not work.

Suggestion received

You need to also add it to the message dependencies of the "ext.uploadWizard" ResourceLoader module - backend logic can look up messages on the spot, frontend logic cannot. Probably something like ... would work.

$wgExtensionFunctions[] = function () {
    $wgResourceModules['ext.uploadWizard']['messages'][] = 'mwe-upwiz-license-c';
};

It does not after adding this after the UploadWizard call, I'm afraid.

Although UploadWizard should do this itself if it exposes its messages to be configurable, so I'd say this is a bug.

This is why I am reporting this issue.

Note
This must be at least a MW 1.33.x regression (pls do not tell anybody it is still on this branch, will be upgraded next week) since I have done the same on a MW 1.31.x there it is working fine:

  • MediaWiki 1.31.12 (71da50e) 4. Jan. 2021, 01:26
  • PHP 7.2.13-1+0~20181207100540.13+stretch~1.gbpf57305 (apache2handler)
  • MariaDB 10.1.37-MariaDB-0+deb9u1
  • Upload Wizard 1.5.0 (1ba0e4e) 17. Apr. 2018, 21:25

The respective wiki is up for the upgrade to MW 1.35.x within the next fortnight. I will also report back if MW 1.35.x cause an issue.

Event Timeline

That regression against 1.31 is very weird... AFAIK this was never supported in UW, so if it did work, it must have been by accident. I actually have a task filed for that, see T262257: Load license messages properly. It would require quite a few deep changes to how UW handles its config and setup, so I put it off until my other patch related to its config is merged. The extension is basically unmaintained now, so that could never happen. Oh well.

For me the easiest thing to do in order to make this work was to fork UW and modify extension.json, which is horrible and something you should never do, of course. :)

@Ostrzyciel

That regression against 1.31 is very weird... AFAIK this was never supported in UW, so if it did work, it must have been by accident.

Thanks a lot for your comments. This started me thinking again. As a matter of fact I realized that I am using the solution mentioned on T262257 to make things happen in MW 1.31. I just totally forgot about it and now after looking at what I did two years ago ... Senior moments I'd call this.

I believe this issue can be merged into yours.