Sat, Oct 5
@Daimona: Larske has now removed a dangling | at the end of https://sv.wikipedia.org/wiki/Special:Missbruksfilter/115
Adding svwiki 115 to the list. This filter is now erroring out since svwiki is already using the new parser.
I have informed Svensson1, Larske and JohanahoJ about this at https://sv.wikipedia.org/wiki/Wikipediadiskussion:Redigeringsfilter#Filter_115
Sep 1 2019
This would be trivial if appropriate HTML was added to https://en.wikipedia.org/wiki/Template:Convert and extremely unreliable as things currently stand (you would basically have to run a regex substitution across the entire page).
Aug 28 2019
Aug 17 2019
Aug 14 2019
I wonder if this means TemplateStyles don't work in indicators either?
Well, you would have to add the mw-parser-output class yourself for it to work. See T37247, https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/352835/ and T188443.
Aug 13 2019
Absolutely, I'm very happy that you're trying to sort things out! 👍
Things are still broken. For a minimal test case, see for example https://sv.wikipedia.org/w/index.php?diff=46200983
Aug 11 2019
Same as T189095?
Aug 8 2019
The colon is there in the screenshot you added (directly below "Active filters"). I should probably mention that this is not a new issue – it's been like this since Recent Changes was revamped. This is just speculation from my part, but it looks like some developer tried to add the colon there to emphasize that the filter has to do with namespaces (which contain colons), but added it on the wrong side of the namespace itself (i.e. :MediaWiki instead of MediaWiki:).
Jul 19 2019
I'm confused. Shouldn't it be set to false?
Jul 18 2019
Jul 17 2019
Can't reproduce the problem in Firefox, Chrome or Edge. User:Pamputt/common.js contains a lot of old junk.
gives "JQMIGRATE: jQuery.fn.bind() is deprecated".
gives "ReferenceError: hookEvent is not defined".
Jul 14 2019
This happens when the servers are under too heavy load. Looking at https://commons.wikimedia.org/w/index.php?title=Special:Contributions/Alexis_Jazz&offset=&limit=500&target=Alexis+Jazz it seems you have made 353 edits in one minute. That's almost 6 edits per second. That is several times faster than bots are allowed to edit on any Wikimedia project I know of. Even doing this with a bot flag would not solve the database retention problems you've seen. Doing this without a bot flag is absolutely crazy, as not only are you still editing too fast for the servers, but you'll also flood Special:RecentChanges, making life much harder for the few brave heroes there who try to catch vandalism. I suggest you read up on some etiquette before making any further edit:
Jul 8 2019
See also T49512.
Jul 7 2019
Same as T184858?
Jun 9 2019
May 13 2019
This is wmgUseSandboxLink in https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/InitialiseSettings.php
May 11 2019
As Izno said, this reduces composability.
Apr 22 2019
This comment looks strange:
/** * Algorithm to convert Gregorian dates to Thai solar dates, * Minguo dates or Minguo dates. * * Link: https://en.wikipedia.org/wiki/Thai_solar_calendar * https://en.wikipedia.org/wiki/Minguo_calendar * https://en.wikipedia.org/wiki/Japanese_era_name * * @param string $ts 14-character timestamp * @param string $cName Calender name * @return array Converted year, month, day */
Is it supposed to say "Thai solar dates, Minguo dates or Japanese era names"?
Apr 17 2019
Mar 31 2019
How can "edits" ever be stored as a "cookie"?
They can't. A cookie can only hold around 4–10 kB or so.
This is easy to do as a gadget or user script:
Caused by T205581.
Can confirm. I recently made
as a workaround.
Mar 29 2019
Mar 28 2019
Mar 25 2019
Mar 22 2019
@Jseddon, @Rxy: Just editing MediaWiki:Sitenotice isn't good enough because it's going through the revisions and picking another one at random. You need to hide it with CSS like this: https://sv.wikipedia.org/w/index.php?diff=45286235
I'm gonna go ahead and say it's an off-by-one error. For
it seems to show the [ current - 1 ] revision.
There is $.getJSON.
Mar 19 2019
@Krinkle, it's the PHP 7 beta feature that can be enabled in the preferences.
Mar 15 2019
Mar 11 2019
Feb 18 2019
Jan 11 2019
I have no issue whitelisting the rest: <mark>, <progress>, and <time>. (Of these, <mark> seems the most obviously useful.)
What about <meter>, <details> and <summary>?
Jan 9 2019
Dec 27 2018
I don't think there's anything the parser (or any other part of MediaWiki) can do to change this behavior. It's completely up to the browser as far as I know. Would love to be corrected if I'm wrong.
Dec 6 2018
The diff in https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-4o7rea2lrkhv4y4/ is illegible. All I did was adding <details> and <summary>.
Dec 5 2018
you'll probably want to re-evaluate UA stats after Nov 17 to see what the true final fallout is
Dec 4 2018
nor is the TOC headline in blue
I am struggling to understand what you mean by this, but it sounds like a regression, and an unintended one at that. You should probably file a new task about this, and tag it with "Regression".
Dec 2 2018
Nov 30 2018
If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.
should it be "§" instead of an arrow?
This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.
Nov 28 2018
Nov 17 2018
As JJMC89 has already noted, this is because '' in wikitext opens an <i> tag. This <i> tag is then closed before the closing </code> so that the tags do not overlap incorrectly, causing the ; to be italicized. The following wikitext gives the intended result:
Nov 11 2018
Nov 6 2018
Can confirm. I recreated the minimal test case live in case that helps anyone:
Oct 27 2018
Oct 26 2018
Has the Parsoid patch that removes the p tags around style tags been deployed, and if so, when was it deployed? I'm asking because I'm still seeing style tags wrapped by p tags on for example https://sv.wikipedia.org/api/rest_v1/page/html/Anv%C3%A4ndare%3ANirmos%2FAnders_Bj%C3%B6rck
Oct 25 2018
Oct 24 2018
So, this was a combination of 3 things:
- While the massmessage-optout-category category certainly is recognized by MediaWiki, it of course isn't added by MediaWiki. It is added manually by the users. This was a brainfart on my end.
- On Swedish Wikipedia where I investigated this, old pages had the category "Pages with obsolete Vega 1.0 graphs". It had since been localized to "Sidor med föråldrade Vega 1.0 grafer", but the pages were still in the old category. This is a MediaWiki bug in itself. I have now resaved the pages so that they are in the new category and moved the category to the name that MediaWiki uses.
- MediaWiki no longer adds any "Pages containing blacklisted links" category. It used to do this (the category key was spam-blacklisted-category). It was disabled for performance reasons in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SpamBlacklist/+/122285/ Unfortunately, English Wikipedia manually adds this category using a template (Blacklisted link inline) which fooled me. This category really should be deleted on projects where it is empty, and hopefully the admins on enwiki can rename their category, although I doubt they would agree to that.
Oct 22 2018
Oct 17 2018
Oct 16 2018
@Bawolff I'd like to get svwiki in report-only mode. Should I start a discussion with the community about this now, or is it way too early?
Oct 8 2018
Filters can add tags. Doesn't this create the same chicken-and-egg problem that has already been described in T53421? Or am I completely misunderstanding what this task is about?