Guild Wars 2 Wiki talk:Requests for technical administration

From Guild Wars 2 Wiki
Jump to navigationJump to search

Adding the Popups Extension[edit]


So some of you may know of it, but a while back wikipedia added support for a popup module ( which creates a small overlayed box with the first few sentences of that page.

Now I bring this up, because in my opinions one of the most frequent issues I see on this wiki is people coming here, landing on a page, and feeling like they have to click on multiple pages to get whatever information they want for something minor like "Is this a sword or a dagger", "which event is the one I am looking for", etc. Now since we simply can't put all the information for everything everywhere, I think a good solution (or at least partial solution) would be to implement the module I described above.

Currently, one can reproduce the behavior on this wiki by adding a line in their common.js file (as done for example here)

Now at the moment, implementing it this way works pretty well for area pages, generic info pages, events, and some item pages. The extension also works wonderfully for the `hist` and `diff` on the Recent Changes page.

At the moment, it does "fail" (i.e give pointless info) for item pages with no sentences at the start of the page (like most ingredient items). It also really messes up when hovering over a custom user page (say a custom.js page).

I did take a few screenshots which are in this album if you want to see here

From a first glance, it would seem ideal to either take this extension and modify it to show all (most?) pages properly with a few extra conditions, or to build an extra module upon this extension (perhaps a more stable option?)

Now Chieftain Alex tells me that this extension depends also on a 2nd extension which we do not have ( Due to this there may be a need to maintain these extensions if mw updates break things, and misc tweaks may need to happen.

So at this point I've been going on long enough, I'm not 100% sure what the next step is, so I'll end my rambling and leave it at that.

p.s Inc here's another link to the Prezi you forced me to make. -Darqam 08:33, 29 October 2018 (UTC)

I think we should roll this out as an opt-in beta. It'll give us a chance to debug it for our wiki and check for any unforeseen issues. It'll also allow us to break the feature as we try to adapt or expand it, without bothering our larger user base. G R E E N E R 17:26, 6 November 2018 (UTC)
would you have to click or hover for these pop-ups? I feel like it might make certain pages annoying if everywhere you hovered you got a tool-tip pop-up. That said, as long as we can limit the amount of text displayed and what links actually display the tool-tip pop up, I'm game to try a beta of it.--Rain Spell (talk) 01:21, 7 November 2018 (UTC)
If it's similar to what Wikipedia uses, the hover box would only appear over links, which to be honest, I quite love. - Doodleplex 02:27, 7 November 2018 (UTC)
The pop-ups are on hover, however you do need to be hovering over a link for ~1 second, it doesn't appear instantly so you aren't spammed with them as you move your cursor. They also seem to take between 1-2 seconds (I think it's 1s and my pc is just slow today) for it to go away after you move your cursor off the link or outside the pop-up. You can also click elsewhere on the page for it to vanish right away.
So far I've been running this for a while, and there have been a few cases where it blocked me a little due to not realizing I put my cursor at rest on a link, but in my opinion the benefits of it outweigh the few minor annoyances.
I wouldn't be opposed to increasing the the timeout a tiny bit before the boxes popup, but anything more than 2 seconds would just feel too long. 1.25s or 1.5s still feels acceptable for me. -Darqam 08:49, 7 November 2018 (UTC)

Sorting pages with numbers[edit]

$wgCategoryCollation controls the algorithm used for sorting categories and $smwgEntityCollation controls sorting queries. I'm guessing both are still using the default setting uppercase. I propose to change them to numeric. The reason for this change is that articles with numbers in their names aren't being sorted appropriately right now. For example, Category: Infusions sorts 10-19 before 2. The nav in Hunter's Journal also sorts like this. Changing the settings would make them sort correctly. --BuffsEverywhere (talk) 10:07, 25 February 2019 (UTC)

Enabling video files[edit]

So this topic came up on the Discord a couple weeks ago that I've been meaning to bring up for proper discussion on the wiki. We use animated GIFs in a few places around the wiki where static pictures don't adequately show things, for example cosmetic auras such as File:Transcendence_animation.gif or finishers such as File:Spectre_Finisher.gif. The particular discussion was related to the new Celebratory Birthday Enrichment and getting a decent GIF within the file upload limit (8mb). This is because the GIF file format, while capable of showing animation, wasn't actually designed to and is horrendously inefficient at it (see w:GIF#Animation_formats for further background). This means even short, low-quality videos make for very large filesizes in GIF.

Wikipedia uses WebM and Ogg Theora for their video needs (see w:Wikipedia:Creation_and_usage_of_media_files#Video for details), as these free and open formats are capable of higher quality at much smaller file sizes. Looks like Wikipedia uses Extension:TimedMediaHandler to enable their display in articles. We would also need to add .webm and .ogv to our Manual:$wgFileExtensions to allow uploading those file types.

Thoughts? Do we want this, or is our current situation with animated GIFs 'good enough'? Any of our more technically-minded users see potential problems I don't? Of course there's the possibility of misuse, someone uploading something inappropriate for the wiki, but given that that's already equally possible for currently-available uploads and hasn't been a significant problem to date, I'm not too worried about it. One already needs to be autoconfirmed to upload, and there are generally enough nosy people around RecentChanges to notice if something needs dealing with. - Tanetris (talk) 12:41, 11 September 2020 (UTC)

Gifs are terrible and never impress like the ingame animations do. If the files are smaller too then it seems like a no brainer.
I can't imagine we'll have a flood of video files submitted due to the annoyance of creating them. We might want to consider creating a guide if we do get the extension installed (use windows game bar, then ffmpeg to create .webm?) -Chieftain AlexUser Chieftain Alex sig.png 21:32, 11 September 2020 (UTC)
Allowing webm definitely makes sense nowadays. I remember “back in the days” we considered something like this before (especially for sound files) but we would have had to use Flash back then for playback. Since there’s now browser support for native videos, we don’t have that issue any more, so the only issue left is content moderation which already applies to images and GIFs anyway.
If we want to show some video content on the wiki, then yes we should prefer e.g. webm/VP9 over GIFs for multiple reasons (size, quality, and ease of creation). poke | talk 23:01, 12 September 2020 (UTC)
Depending on what program they're using to capture (I don't know about windows game bar, don't have Win10), they may be able to save out directly to webm. And if someone already has a fancier video editing program (e.g. for cropping and the like, unless their capture tool has that built-in) that may be able to save to webm too. Else, other video formats can be converted to webm using ffmpeg, yeah. I played around a bit with XMedia Recode (a GUI frontend for ffmpeg) and it seems to do the trick just fine for those not comfortable with commandline, and can even do some simple editing. - Tanetris (talk) 14:30, 14 September 2020 (UTC)
ffmpeg -i whatever-source-file.avi target-filename.webm is really all that’s necessary in its most-basic form. The source file can be pretty much any container/codec combination (e.g. avi, mp4, wmv). poke | talk 21:40, 14 September 2020 (UTC)
Just to note it here, it turns out the extension can be configured to support mp4 as well (which is what Windows Game Bar spits out by default from my googling, and is otherwise an extremely commonly-used format), so no conversion would be necessary. This has been included in the request. - Tanetris (talk) 19:26, 8 December 2020 (UTC)


Currently the wiki users will experience one of the four following variants when clicking an image:

  1. Redirect to the file page
  2. Semantic mediawiki format gallery: opening a centered fancybox, with caption and navigation arrows appearing while hovering. E.g. used in the template Weapon set gallery.
  3. Widget Gallery: opening a top-left box without navigation arrows.
  4. Widget Fullscreen images: opening a top-left box with navigation arrows.

In order to provide the wiki users one consistent image viewing experience, I suggest to add the commonly used extension mw:Extension:MultimediaViewer: "The MultimediaViewer extension gives the user of a wiki a different interface for viewing full-size, or nearly full-size, images in their browser without extraneous page loads or confusing interstitial pages." --Tolkyria (talk) 10:20, 2 October 2020 (UTC)

Hi, Tolkyria. I'm certainly amenable to adding this standard extension, though I have a question. The extension's installation notes suggest using the BetaFeatures extension as well to allow users to disable it as a preference, and it also recommends the CommonsMetadata extension. Do you have any preference (no pun intended) one way or the other regarding the use of BetaFeatures? Regardless, I can test this on the dev wikis next week after I deploy the 1.34.4 update, one thing at a time and all that. Let me know what you think. Justin Lloyd (talk) 10:47, 2 October 2020 (UTC)
Thanks for this quick feedback. I would enable this extension on default, because leaving the page (i.e. redirecting to the file namespace) to view the image in full size is nearly always interrupting. E.g. achievement collection guides with several images, one map image and one location screenshot for each collection item; or simply checking a concept art image on a lore page,... That's what the two widgets I stated above have been designed for.
Before adding an official request, I would like to ask the community if there are any remarks or objections. --Tolkyria (talk) 11:49, 2 October 2020 (UTC)
I would welcome a consistent image experience (making the extension default). I can't quite tell, does the extension provide a link to the image for easy editing like it was added to Fullscreen images? —Kvothe (talk) 15:19, 2 October 2020 (UTC)
Yeah replacing those widgets with an extension makes some sense in providing a consistent presentation... my only concerns would be (1) whether it treats the "icons" that we sprinkle so effortlessly over every page would also be included in the mediaviewer + (2) how it responds to images which already link to pages. Have a look at for an example.
Responding to Justin's questions:
  • Betafeatures - I suppose having the ability to disable the gallery view based on login preferences would be kind of useful. I'd support having this available. (3) I should note I think the extension remembers the preference with your cookies or something too even without this extension. I suggest we could try with betafeatures and see if its ok.
  • CommonsMetadata - no this only provides information for images used from mediawiki commons, and as we upload all our images locally is useless to us on gw2w.
I'll have a look at the extension source in the meantime. -Chieftain AlexUser Chieftain Alex sig.png 16:33, 2 October 2020 (UTC)
Answering (1), "MultimediaViewer\resources\mmv.bootstrap\mmv.bootstrap.js" has a function named MMVB.isAllowedThumb. This checks for a couple of CSS classes, namely .metadata and .noviewer among others. So we can switch the viewer off if we wrap the icon templates in a metadata class for example.
Now got an answer for (2) too - I added a test to that page under - if you specify the link parameter then it doesn't bother with the preview gallery box.
(3) preferences are stored ("MultimediaViewer\resources\mmv.bootstrap\mmv.Config.js") with localStorage html5 under the name "wgMediaViewerOnClick" key-value pair, so would be cleared when a user clears their cookies etc. -Chieftain AlexUser Chieftain Alex sig.png 16:57, 2 October 2020 (UTC)
Kvothe, mw:Help:Extension:Media Viewer#How can I bypass Media Viewer?: No small icon on the top left, but Ctrl + left click opens the image in a new tab.
Icon templates are always linked, hence they shouldn't make any problem, even without css (same behaviour as your widgets); only the infobox icon on the top right would need an exclusion (e.g. by setting the link to the file page, again no css needed). --Tolkyria (talk) 17:34, 2 October 2020 (UTC)
I don't think it's a terrible idea to set the entire infoboxes as metadata anyway. -Chieftain AlexUser Chieftain Alex sig.png 17:41, 2 October 2020 (UTC)

Removal of the broken mw:extension:TitleKey and replacement with something that works[edit]

I'm thinking two separate requests here, the first is to just straight up remove the existing broken search extension. I'd like to check if searching in other namespaces works after doing that.

Then we should consider how best to provide a better search tool for the wiki. Personally I like the idea of copying what wikipedia uses, so to quote Tolkyria on Guild Wars 2 Wiki:Reporting wiki bugs#Autocompletion on search box uses Article (or Special) namespace only: "what about: mw:Extension:Elastica, mw:Extension:CirrusSearch and mw:Extension:AdvancedSearch, used by many wikis, e.g. wikipedia and mediawiki. See here for the provided features: mw:Help:CirrusSearch, but most importantly: we would be able to see namespace previews. Whether we want to browse templates or properties as wiki editor, files or categories as wiki user, right now it's quite tedious to find them without any preview." → i.e. i suggest we install all 3 of the suggested extensions.

I'd like any thoughts or comments before I just bung a technical request in. -Chieftain AlexUser Chieftain Alex sig.png 21:02, 7 December 2020 (UTC)

I'm kinda biased, but I want to point out once again that especially wiki editing without autocompletion preview outside mainspace is quite tedious. No matter if it's searching files, categories or templates, currently I'm relying on my browser address bar and have to hope that I already visited this wiki page once. For wiki users it's probably not that disturbing, they visit mainspace mostly (probably wiki users are interested in user guides of files), but nevertheless it's not very representative for the wiki if the autocompletion doesn't work.
Also the advanced search options, which are provided by the mentioned extensions, should be handy, right now the fulltext search is limited to "<exact text>".
Support. --Tolkyria (talk) 23:31, 7 December 2020 (UTC)
Yes please. --BuffsEverywhere (talk) 08:56, 8 December 2020 (UTC)
Request raised. -Chieftain AlexUser Chieftain Alex sig.png 19:29, 8 December 2020 (UTC)