Mon, Aug 21
Either I can't reproduce the issue you're describing or I don't understand your report. I see the "Show" button, and I see the pagination.
Currently it's not possible (other than by submitting patches upstream), but folks have been working on it.
I've done the cleanup this morning. Ended up editing 486 pages. Many were already cleaned up by conscientious editors, some were false positives (broken syntax for coordinates etc. from old edits).
Thu, Aug 17
There seem to be only three legitimate templates on Commons with potentially confusing names:
select page_title from page where page_namespace=10 and page_title rlike '^[0-9]+$'
- Since '0' would be the first language on the list, this could only end up being used for some fairly rare languages with names starting with 'A' (e.g. Abkhazian in the English localisation), or if the user chose the first entry from the list without reading it for some reason. Still, this might have to be checked by hand. Starting from the end of https://commons.wikimedia.org/w/index.php?title=Special:WhatLinksHere/Template:0&namespace=6&limit=5000&from=60258200 (currently "File:1260Pulilan Bulacan Landmarks Road Constructions 47.jpg").
- They are not a problem – there are only 356 languages on the list so these could not have been generated.
We could put a star emoji there (CSS-only, generated with :before/:after), normally hidden behind the image (using some positioning/z-index tricks)? ;)
For the record, I think the gradients proposed by @Edokter in comment T63099#653216 above and https://test.wikipedia.org/wiki/MediaWiki:Gadget-ImagelessTabs.css look like a good starting point. Perhaps someone would want to turn that into a patch.
What is a LocalWikiDexFile, and why are GIFHandler and PNGHandler trying to handle it? :o Perhaps you have some extension that isn't cooperating with MediaWiki right.
Special:Upload is broken in this way on https://test.wikipedia.org/, https://test2.wikipedia.org/ and https://www.mediawiki.org/, but apparently not on he.wp (or other production wikis I checked). Perhaps this depends on some configuration too.
This was apparently the first report of this, but the other one has gotten more comments.
By the way, the two other features that the patch relies on also didn't exist when the original code was written:
- Disallowing data-mw-* attributes from wikitext was added in 2015: rMWb62f0e91564f: Reserve data-mw and data-parsoid attribute prefix for trusted values
- Support for data-* attributes in the navigation was added in 2016: rMW88f4eca6d8e6: Allow 'data-*' attributes in personal tools links
Yes, fixed and deployed.
With the fix for T148265, I think this is in fact resolved?
Notably, this changes the checkbox on Special:UserLogin (finally!):
VE itself uses a pencil for the concept of editing, brackets for source editing and eye for visual editing. I think we settled on this unhappily after considering a few different things (T97451 and T116417 look relevant). If you invent a better metaphor, VE team might want to hear about it too
This is not a formal review, but some quick thoughts about the HeaderCount extension:
- It looks like the extension is not in our repositories on Gerrit, but only on GitHub. It would have to be imported first, so that we can do deployments without relying on external services.
- Looking at the code, it looks like the extension does nothing to make sure it is reading the latest page content after a page has just been saved – we'd have to test it, but I think it would basically require purging a page every time after it is edited to get the correct results.
- It also doesn't account for heading generates by embedded templates.
A similar issue is reproducible on Special:Upload on test.wp (https://test2.wikipedia.org/wiki/Special:Upload?safemode=1), but no on any others pages I tested.
I posted a quick notification about it: https://commons.wikimedia.org/wiki/Commons:Village_pump#.7B.7B83.7C.E2.80.A6.7D.7D_and_similar_broken_templates_in_UploadWizard_uploads
After this is deployed, we'll need to find and fix the broken uploads. I will be doing that.
Also – given that these are still not translateable in the year 2017 (really…?), I think it would be valuable to choose a name more likely to be familiar to non-native English speakers. So I would vote againts "refine"/"refines" :(
I don't know if you're looking for more ideas (I only saw this scrolling by on IRC), but there's a lot more words that could be used.
I don't think they're related, This is about passing disabled: true or calling .setDisabled( true ).
I have not seen what happens, but the worst case is that the interface gets so messed up that users have trouble reaching the Preferences page and changing their skin back. (The page Special:Preferences has all custom CSS turned off for this reason, but if you don't know how to get there other than typing the URL this can still be problematic.) Perhaps folks just erred on the side of caution here. This should not block other deployments, I think.
Per https://fr.wiktionary.org/wiki/Wiktionnaire:Wikidémie/août_2017#D.C3.A9ployement_de_Timeless it seems that existing on-wiki custom CSS conflicted with Timeless.
Mon, Aug 14
Sun, Aug 13
Hmm, yeah... that'll require some extra effort to make sure it works with all the skins, but it seems like a better long-term solution.
This is actually a core feature that doesn't for with Timeless - see resources/src/mediawiki/page/watch.js.
I kind of feel like however this is done for Vector, it'll need to be done differently for Timeless... probably should move that code to Vector and redo it in Timeless.
Thanks for the comments Pau.
I think we should mention this new feature in next Tech News - note that it's off by default for now (you have to turn it on in preferences). I wish we could turn it on for everyone, but let's see how well it's received first :)
Sat, Aug 12
This patch probably helps by standardizing how the log messages are generated, but I'm not really sure what this task is exactly about -- if anyone knows what it's about, please test it :D The patch should go live to Wikimedia wikis next week.
I blame the partial mw-ui styles D:
Fri, Aug 11
Also documented at https://www.mediawiki.org/wiki/Manual:Skinning_Part_2#Screenshots
With these patches merged, 24 skins out of 42 in our version control have screenshots.
The most famous one from Poland! https://en.wikipedia.org/wiki/Koziołek_Matołek
Yes, MediaWiki's parsing is different from normal HTML parsing, but the very point of this task was to bring them closer for consistency. This has been accomplished therefore this task is resolved. If you disagree with the premise then I'm afraid you're the only one.
I tried to include it, but it's shown me some error message so I skipped it. Maybe I'll look at it again later and try to actually read what the error says. I don't think it's a major problem if it's inconsistent; I won't be taking screenshots of all skins forever so they will soon enough become inconsistent anyway.
Here are 24 screenshots for all the skins in our version control that I could effortlessly get to work and that did not have obvious huge rendering issues. They're at 1280x800px.
Thu, Aug 10
I've taken screenshots of hopefully every possible state of the popout in Timeless with the latest version of the patch. They look fine. (They look fine in RTL too but I've had enough of taking screenshots.)
I am sorry but you're wrong. Here's a simple test file you can use to verify that <b/> is parsed as an opening tag. It is so in modern browsers, and it has always been (I tested with Firefox 3.6, I don't have older browsers readily available.)
I am having trouble distilling meaning from this long comment, but I think you're wrong on at least one point. <elementname/> has only been equivalent to <elementname></elementname> in XHTML; in HTML, <elementname/> means the same as <elementname> (it's just an opening tag and the "stray" slash is ignored). As some tags like <br> do not require a closing tag, this is not a problem for them, but for tags that require contents it is.
We actually have a separaete task T68295: Come up with a sane way of including screenshots with skins and displaying them in the UI for screenshots, let's continue there.
https://gerrit.wikimedia.org/r/#/c/371107/ changes some of those, but not all.
This has now been done as part of T47221.
https://gerrit.wikimedia.org/r/#/c/129095/ is merged! Better late than never.
If this turns out to be a widespread issue, it is probably possible to implement a workaround, but for now yours is the only report of this problem.
Yes, that's what that patch is supposed to do. This means you're missing the 'fileinfo' PHP extension – you somehow disabled it. MediaWiki requires it for correct operation. (Sorry, this was previously not properly documented – no one noticed, so apparently most normal installations include it.) Please get it enabled and see if that helps.
I rebased the patch. I had to rewrite it a little bit, since this code apparently changed a lot in the meantime.
Wed, Aug 9
Feel free to add me back to this task when my input is needed.