Sun, Oct 18
Sep 24 2020
As more wikis are updating to MW 1.34+, this is impacting more people. See for example https://www.mediawiki.org/wiki/Topic:Vuij4e8ea5ydavbn. Would be nice to see this fixed in a new point release of the extension.
Sep 12 2020
Sep 6 2020
Aug 16 2020
Aug 3 2020
This is possible in pure CSS these days with minimal dodginess; see for example the .floatable-header CSS at https://yugipedia.com/wiki/MediaWiki:Common.css and an example usage at https://yugipedia.com/wiki/Historic_Forbidden/Limited_Chart.
Jul 24 2020
Jul 15 2020
Jul 3 2020
Jun 28 2020
No idea; I don't know if it's actually still in use either. If not, then obviously this task is unnecessary and can be reclosed.
I'm not keen on the amount of work left in the hands of the merging interface admin in your proposal, @DannyS712. In particular, for an extension it should be possible to mark the forked pages as forks and indicate what page they're forked from, and have some mechanism to mark a particular revision as approved, at which point the special page could pull most of the required info automatically from the fork when an iadmin merges it back in. If it's a concern, the special page could allow certain fields to be modified pre-merge (e.g. tweaking the summary), but in general I feel much more comfortable not requiring the iadmin to manually copy so much (less chance for errors to creep in, etc).
Jun 23 2020
Jun 12 2020
Jun 9 2020
Jun 6 2020
In light of T254646, I believe this should be revisited. The problem with "shiv" is that it immediately evokes imagery of violence. At least in the US, it might also be considered a microaggression against people of color, given the gross racial imbalance in US prisons compared with the general population. Even if this isn't true, WMF projects purport to be inclusive of everyone, which includes current and former prisoners, for whom "shiv" is likely to be an unpleasant reminder of their experiences in the system.
Jun 5 2020
@Jony the people who are members of the MediaWiki-Email project are not automatically the best people to actually work on tasks; I'm personally a member for my own tracking purposes, and don't do any MediaWiki development work myself (beyond occasionally filing or commenting on Phab tasks).
May 30 2020
May 29 2020
May 24 2020
The same thing happens if you use <noinclude/> instead of a comment, with the same HTML output. Probably it would also happen this way with <includeonly/> and <onlyinclude/>, though I didn't test these.
May 23 2020
I'd still like support for multiple tasks, but I don't think that should block. As is, it looks fine.
This can be sort-of done using AbuseFilter, e.g. https://www.mediawiki.org/wiki/Special:AbuseFilter/58, but it's not ideal.
May 17 2020
May 16 2020
May 15 2020
Did you accidentally leave out or add in a hex, or swap the values? 0x3DC594 (the offset you stated; note there are six hexadecimal digits) is way less than 0x2DB1B30 (the file size you stated; note it has 7 hexadecimal digits). Even if it's meant to be an offset from the TIFF directory (located at 0x2D1A3A per the tiffinfo output from your previous comment), that only gets up to an absolute offset of around 0x6ADFCE.
May 14 2020
May 13 2020
May 9 2020
Apr 27 2020
I can't speak for anyone else, but its (lack of) resemblance to <syntaxhighlight> was not one of the reasons I had in mind when I proposed the deprecation of <source>, and similarly I don't think there's any reason to require a new shorthand element to have a resemblance to <syntaxhighlight>. To that end, maybe a tag name like <codehighlight> or <coloredcode>? I'd also suggest <sh>, but I have no idea how safe it'd be adding a two-character tag when it's not inconceivable that a tag of the same name could be added to HTML at some point.
Apr 24 2020
Apr 23 2020
Apr 22 2020
Yes. Sorry if it seems like I talked around that instead of just saying it outright.
Honestly, the reliance on wl_notificationtimestamp to determine whether to email users is the root of a lot of problems; IMO the easiest fix would be the addition of a field that indicates whether the user has been emailed about the page yet.
Apr 21 2020
The specific circumstance is where the imported revision is newer than the current local revision of the page, and would thus replace it and trigger jobs. In this case, if the revision text is identical, there is no point in importing the revision. This can happen if you imported a template or module at some point in the past, and then on the source wiki an edit was made and undone, or the page's protection was changed, or a similar action was performed that generates an empty revision/diff (which will then have a different, later timestamp and (often) a different editor from the older imported revision), and then you reimport the current revision of the page. If the revision to be imported is older than the current local revision, it doesn't really matter if it gets imported or not, and if the export contains the full page history instead of only the current revision, it should be imported regardless (and/or an option to skip importing these revisions should be provided).
Apr 20 2020
Apr 19 2020
Apr 17 2020
Apr 16 2020
<syntaxhighlight> is not particularly "new"; it was added as an alternative to <source> in revision 50696, in May 2009 (in response to T20820). Not that this invalidates concerns for non-English speakers, of course, but I don't have any good answer for that.
Apr 12 2020
As far as I can tell, the old parser does this too (I get the same result testing on a 1.31 wiki that doesn't have Parsoid installed). That doesn't invalidate this issue, but changes it from a bug report to a feature request IMO (and makes it a potentially-breaking change).
Apr 11 2020
Apr 10 2020
I'd be surprised if this hadn't been considered before (and even more surprised if there weren't technical issues I'm unaware of that make it unpalatable), but a potential method for deprecating MediaWiki:Mobile.css at least in the short term would be flags that could be used on styles in MediaWiki:Common.css to mark them as intended for mobile and/or mobile-only, something like /* @embed */ being used to tell ResourceLoader to embed the following object directly in the stylesheet, or /* @noflip */ being used to prevent directional CSS from being changed for opposite-directionality languages. The software (be that MobileFrontend, or ResourceLoader, or whatever else) would then generate a mobile stylesheet from Common.css by stripping everything without the flag, and in the case that mobile-only styles are supported/present, a nonmobile stylesheet with all the mobile-only styles would also be generated.
Apr 8 2020
Apr 7 2020
Apr 6 2020
With few exceptions, the important part of talk page archives is the actual discussion. Many lint errors arise from deprecated markup constructs that impact the readability of pages they appear on (a good example is closing tag semantics, which have changed in the past few years; many talk pages/archives from the distant past have malformed tags which, under the current parsing semantics, cause various styles like strikeout, superscript, or small to be applied to the entire rest of the page); therefore, I would argue, updating this markup is important for preserving the readability of these archives, and broadly speaking does not change the actual text, only the underlying markup and the styling applied to the text. In this light, these updates are desirable and positive. As for the purely preservationist perspective, well, the original markup is still present in page histories.
Mar 30 2020
Possibly TranslateWiki, but honestly I'm the wrong person to ask.
You can modify the message via MediaWiki:Linkstoimage (for files that are used on at least one page) and MediaWiki:Nolinkstoimage (for files that are unused). I've modified both of these on a couple of the wikis I am/was an administrator on, see examples on Yugipedia: MediaWiki:Linkstoimage, MediaWiki:Nolinkstoimage.
"File usage" only lists pages that embed the file directly on-page ([[File:Example.png]]); "What links here" also lists all pages that link to the file's description page ([[:File:Example.png]]). I've always thought the messaging in the "File usage" section was misleading.
Mar 29 2020
Mar 17 2020
Ahh, it seems I never enabled scripts for wikidata.org in my script blocker, so this login issue is unrelated to the past one on a third-party wiki that I mentioned in the OP. Enabling scripts fixed the login. Sorry for the false alarm!
Mar 16 2020
Feb 26 2020
Feb 16 2020
This works as expected on a wiki with Arrays 2.1.0; unfortunately I don't have any wikis to hand with Arrays 2.2.0 to test on.
I'll note that none of the related pages on MW.org that I checked (the main extension page, as well as the /Development and /DE subpages) have any significant edits from more recent than 2015 or so, the only related talk page I saw only has a single topic from two years ago, and WikiApiary doesn't list any wiki as having it installed. Other extensions have been archived for less; my vote is to go ahead with archival.
Feb 5 2020
Jan 27 2020
Are you sure that's the regex responsible for the replacement?
Jan 26 2020
Jan 25 2020
Jan 23 2020
Considering @tstarling is a WMF developer, archiving this extension probably should wait until he gives the go-ahead.
Jan 22 2020
I'd also love a similar extension that automatically converts CMYK images to RGB
As I understand it, this isn't possible to do losslessly, so it wouldn't be a good idea to do so automatically for all CMYK-colorspace images.
Jan 20 2020
I wasn't aware announcements were posted to that list for point releases of non-WMF-deployed extensions, @Aklapper 😛
Jan 17 2020
The extension was marked archived by its author/maintainer (@jeblad), so I'd call that good enough reason to go through with the whole archival checklist here. Even ignoring that, though, the last version was released in 2010, and there's a good chance it doesn't work with any supported version of MediaWiki (though if someone wants to test, feel free).
Jan 16 2020
According to WikiApiary, it's only used on 43 wikis, which are running (at most recent) MW 1.28.2. I think its functionality is covered by TitleBlacklist these days?