User Details
- User Since
- Oct 7 2014, 7:05 AM (341 w, 5 h)
- Availability
- Available
- IRC Nick
- Mormegil
- LDAP User
- Mormegil
- MediaWiki User
- Mormegil [ Global Accounts ]
Wed, Apr 14
Jan 25 2021
Another problematic expression cached as a problem is x \in \mathbb{C}, see https://test.wikipedia.org/wiki/Cached_deprecated_math, any change (e.g. to y \in \mathbb{C}) makes the deprecation to disappear.
Jan 15 2021
Well, yes, for Czech, the subscription confirmation e-mail seems to be sent correctly, now. But as I said above, it is a problem for all languages using non-utf8 encoding in Mailman. E.g. Polish is still broken (“Pro�ba o potwierdzenie zapisania si� na list�”).
Jan 7 2021
Yes, they would break because they are in the wrong encoding.
Jan 5 2021
Those files are provided by the debian package, and are not considered convfiguration files. This would mean that every time we update the debian package from the distro, those will get overwritten until the next puppet run; I would prefer not to go down that path, or down the path of rebuilding the package ourselves.
Jan 4 2021
+1 from me. I think it should not be worse than the current state. :-) (Read: It might break something but that thing is probably already broken now.) But if there is a Mailman expert (definitely not me), please stand up!
Dec 22 2020
Dec 14 2020
This is unfortunate, especially combined with the fact the mobile app displays only the local enwiki description (even when there is none, displaying “+ ADD ARTICLE DESCRIPTION”!), but the edit goes to Wikidata, overwriting the already existing description with the newly added (which is usually worse, obviously). And… the description is still “+ ADD ARTICLE DESCRIPTION” after the edit.
Oct 14 2020
The title of this issue undersells the problem quite a bit. In other words, mobile recent changes and watchlist are basically unusable right now, since all (diff) links are broken (leading to the full view instead of the diff).
Jul 13 2020
Jun 18 2020
So… this is a duplicate of my ancient T14495, right? :-)
Jan 28 2020
And screenshots of e.g. the enwiki example:
OK, but this happens all the time to me (I was surprised not to find a bug already reported), so I guess it should not be too difficult to come with some more examples:
- https://cs.m.wikipedia.org/wiki/Special:MobileDiff/18085597 (missing space at the start of the red del marker “a[ ]kladnými”)
- https://cs.m.wikipedia.org/wiki/Special:MobileDiff/18093137 (missing space at the start of the green ins marker at “Konstantinopoli.[ ]Bratři”)
- https://en.m.wikipedia.org/wiki/Special:MobileDiff/135792555 (just a random diff: missing space at “in[ ]late”)
…
Jan 27 2020
Nov 6 2019
Oct 23 2019
I found this bug only after reducing my broken query until only this was left:
SELECT (MIN(?name) AS ?name) WHERE { }
Also, I noticed COUNT and SAMPLE work fine, while the other aggregate functions do not support this aliasing. If it is an error, a better error message would definitely come handy.
Oct 11 2019
Sep 27 2019
Wat.
Sep 6 2019
Jul 24 2019
OK, I have fixed the problem for cs by purging https://www.wikidata.org/wiki/MediaWiki:Mainpage/cs but that’s not a great solution…
Jul 22 2019
Possibly related? We have found a similar problem with missing P6736 data: Q38192330 has P6736 (since 2019-07-03), but it cannot be found using WQS.
Jul 14 2019
Once again, this solved itself by purging the page, probably just a cached version of the broken state.
Jul 12 2019
Test Wikidata works fine for me, the broken display disappeared on purge.
Jul 11 2019
I just reported T227814.
Jul 9 2019
Came here with the same problem, and indeed, uBlock Origin blocks fingerprint.js as well.
I’ve had the same problem, turned out some ad-/privacy-blockers block the loading of fingerprint.js, see also T86799. After adding an exception for wikidata.org to uBlock Origin I use, everything works fine.
Mar 30 2019
Thanks for the clarification!
Mar 27 2019
Mar 20 2019
@Ammarpad, no, I don’t think so. That task shows a screenshot with a mismatch of the displayed badge and the detail. That works fine for me. My problem is that the mark-as-read is ignored, and the notification still shows as a new one.
Mar 14 2019
Mar 13 2019
D’oh! I was wondering if I am the only one bothered by the current behavior, as I was unable to find any issue. So after a long time, I decided to offer a patch. But the bug has been there for half a year?!? No idea how I was able not to find it. Sorry for the duplicate and thanks for the merge.
Mar 12 2019
Oct 8 2018
Well, it is different now. Arguably better, but not great either. It seems when you remove all text from a sitelink (and the Publish button gets disabled), the trashcan icon for the cleared sitelink gets disabled as well. So that saves you from the dead end reported in this bug. However, I don’t see why the trashcan icon is disabled; when a user does not know the “proper” way to remove a sitelink is to click the trashcan icon and removes all text from the sitelink as the first step, why disallow clicking on the trashcan to remove the whole sitelink row? Note that using the workaround from the original report (write anything into the “new project” field and remove it), the Publish link will get enabled even with an empty sitelink field, and by publishing, the sitelink gets removed correctly.
Sep 5 2018
Jul 9 2018
Nov 15 2017
Jun 30 2017
Right. Also, I came here to report a bug/request which would be, I guess, solved by this one: AFAICT, if I remove an optional permission to an application, but come back later and the application asks to reauthorize (reauthenticate, really), the permission is automatically re-added and there is no way to prevent it in the login dialog. I need to approve the application, which re-adds the permission and redirects me to the application, then manually go to Special:OAuthManageMyGrants and remove the permission again.
May 17 2017
Mar 21 2017
Right, C: was used as a convention for hand-created redirects into the category namespace, but it never was a category namespace alias (IIANM).
Mar 16 2017
On enwiki, c: is an interwiki linking prefix to link to Wikimedia Commons. Therefore, page titles cannot start with such a prefix at all, there are no pages on enwiki starting with “C:”. It is not (and never was) a shortcut redirect to the Category namespace. There is a convention of using CAT: as a shortcut to redirect to categories, and there are quite a lot of those.
Feb 10 2017
Dec 23 2016
Dec 16 2016
Aug 12 2016
What about just something like “All search results for foobar”?
Jun 14 2016
There is a much better workaround than wrapping into a <span>: Just place a <nowiki/> before the <indicator> or after the </indicator>. Example usages:
Jun 2 2016
May 19 2016
Apr 20 2016
OK, I’ll try to be very specific:
Apr 6 2016
Mar 30 2016
Feb 24 2016
I thought this behavior could be fixed by having the .column-break-inside-avoid moved from .mw-category .mw-category-group li to .CategoryTreeItem. (With the complication of the latter being defined in the CategoryTree extension, while the former in generic MediaWiki, therefore, we would need to keep the current behavior in MW core, but override it in the extension.)
Oct 21 2015
Oct 2 2015
@Schnark: I see… if ( document.documentMode === 9 ) kinda explains why the bug appears _only_ in IE9 mode, but not in IE10 nor IE8.
Oct 1 2015
I am able to reproduce this behavior on cswiki using IE11 with developer toolbar and IE9 emulation:
Sep 23 2015
Sep 21 2015
Sep 17 2015
Sep 16 2015
This is hardly the first case this exact problem appeared in MediaWiki. And while solving it perfectly this time (including the declension mentioned above) would be nice to have, going with something simple (again) would be acceptable, I guess.
Aug 22 2015
Aug 14 2015
I went to a foreign wiki I have never visited before and as the first step after my account was autocreated there, I went to [[Special:Preferences]] to change the UI language to something I can cope with. With the JS still loading and the page displayed as one big list instead of the tabbed interface, I changed the language; then the JS finished loading and the display switched to a nice tabbed interface… with the Save button disabled, since I modified the setting prior to the script run. So I needed to change something there and back again in order to be able to save the language setting.
May 19 2015
May 15 2015
I have found the cause: The problem is that edits through API (that is the difference, @Catrope re your comment) pass through the AbuseFilter twice: The first time, via the onAPIEditBeforeSave hook, the second time via the onEditFilterMergedContent hook. Only the second hooks gets the post-merged content.
May 13 2015
@Oriodrim: Yep, I guessed the same in the linked dupe, AbuseFilter seems to see the pre-automerged version of edits from VisualEditor.
Apr 24 2015
Apr 13 2015
(I am not sure if I should open another bug, reopen this, or what.)
Mar 30 2015
Mar 27 2015
Mar 25 2015
Mar 24 2015
What exactly is the long-standing behavior? <indicator> is a completely new tag, it has no long-standing behavior. How many long-standing XML-type tags are supposed to have empty output (and usually expected to be on a separate line)? Definitely not <references> – empty references are a marginal case.
Mar 19 2015
Mar 11 2015
Feb 18 2015
Not sure how index got into the list; the only index message translatewiki.net knows about is a message from an obscure/unmantained IndexFunction extension.
Feb 16 2015
OK, as this seems to have stalled somehow (are we the only wiki to use this? or are we the only wiki to have noticed the redundant whitespace caused by this?), I have used the workaround on cswiki to wrap all <indicator> uses into (otherwise useless) <span>s.