User Details
- User Since
- Jul 19 2020, 9:03 PM (131 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Prototyperspective [ Global Accounts ]
Mon, Jan 9
This refers to talk page posts on Wikipedia. For example it happened here.
Sun, Jan 8
Dec 13 2022
I could log in again after checking "Keep me logged in". However, it should also work without checking that box and I think that box was previously checked (so I used to log in with that) but wasn't anymore.
Oct 14 2022
The problem still exists with 102.3.0esr. The TOC is not readable, this should be fixed asap, albeit I don't know how many users are affected.
Sep 13 2022
Aug 31 2022
It is the latest in Debian, 91.13.0esr
Don't have that. But here's how it looks like when I change the Firefox preferences to Font size 16 where it used to be size 24:
like in:
(here's mine)
So the issue seems to occur only with a certain font-size (if it's supposed to look like in my screenshot). I thought the font-size 24 was the default but maybe it isn't or it's only the default for some configuration. Whether or not it's the default doesn't matter much as it should work with all reasonable font-size configs.
Aug 30 2022
Maybe the 3rd screenshot that I just added makes it clearer just how incredibly bad it is. Now that the issue with it overflowing into the article text is fixed, this bug really should get fixed as well.
Aug 8 2022
Aug 6 2022
Aug 5 2022
Jul 27 2022
I don't remember changing the font-size and until recently this wasn't a problem. Moreover, in these settings I have "Allow pages to choose their own fonts, instead of your selections above" checked.
Jul 26 2022
It happens with all widths and zoom levels that I tried with (earlier Firefox than 102) and also when I add ?safemode=1 to the url. Restarting the browser didn't help. I never had this problem until 22 July and it's very annoying as it hides parts of all articles. What did you change on 21/22 July?
Jul 22 2022
Jun 19 2022
No, wouldn't know which page would be more relevant than a VillagePump discussion, but after all it's in English Wikipedia's code so thought it would best go here. Also I'm not that worried about this issue, it simply should get fixed asap but it isn't particularly important or annoying to me personally. I wondered why nobody solved this yet and searched for discussions about it but found none.
Jun 17 2022
Mar 3 2022
Filtering for "Automated contributions" (either "Bot" or "Human (not bot)" is already possible on Special:Watchlist.
I don't consider what I proposed simple, I only consider showing links to the categories at the bottom of the page relatively simple. These are plain HTML links and can be retrieved with the API afaik,
Mar 2 2022
This has been authored in 2014 and has still not been implemented in 2022 even though it would be simple to show this information at least in a simple way. I'd just like to add that one could implement this by adding a category trees browser instead of a plain list of wikilinked categories.
Done. Also: this Wishlist proposal seems relevant to the issue and vice versa: Grouping watched pages.
Mar 1 2022
Fair point and that's why I only raised this in a comment at that task. Most likely, it depends on some substantial core changes implemented first. But still this could become a Global Watchlist -only or -first feature instead of getting built into the current main Watchlist.
Yes, that's true – I should have made it clearer that it would be implemented so that it only loads these after pressing the button to show the watchlist (maybe it could preload and only show the first few items for each watchlist) ie per AJAX.
This could be built into the global watchlist (currently here).
Feb 2 2022
Jan 15 2022
Jan 11 2022
It's a clear and common use case. It's so simple and quick to just hide a div which is why even a relatively small advantage of this would make it worth. Once they have been hidden one could show day-headers, just like on the English Wikipedia. I'm not sure why it wasn't built like this in the first place: why put timestamps on the left without any option to change that instead of having a header per day (which people are used to, makes a lot of sense, and is the well-tested approach)?
Very useful info but I would disagree if you're saying that custom common.css would be a solution to this:
it should be configurable on the GlobalWatchlist page. Meaning somewhere at the top of the page you have a small gear icon where you can find settings where there is a tab, e.g. "UI", to customize the UI with a few, clear options, including a checkbox for "show timestamps". This option could use this css class or just hide the div the timestamp is contained in. Wasn't it decided that VueJs will be used in the future? In that case it would be even simpler to toggle this.
Jan 10 2022
Alright, thanks for the info – didn't notice there were separate task forms.
I think the extension isn't of much use if it's not known and used. Hence, there should be a config at the Watchlist page of English Wikipedia and other language Wikipedias once the extension is ready for it.
Jan 9 2022
On mobile the code is functional, however looks a bit odd. We likely want to tweak the CSS to fully fix this issue
Jan 7 2022
Dec 26 2021
Dec 22 2021
Thanks for the infos. Will propose it there (albeit having even more options could be a problem and this should be in the options of the Watchlist page if it's not enabled by default). Probably has been proposed earlier too.
Dec 17 2021
Dec 7 2021
This is already implemented here: https://en.wikipedia.org/wiki/User:Prototyperspective/gadgets/aWorkingWatchlist.js
Dec 6 2021
Okay Clump managed to actually address my reasons. He stated that "they are all mediawiki projects".
That is false in that they are not the MediaWiki software.
See https://en.wikipedia.org/wiki/MediaWiki:
The only question I ignored is whether I developed MediaWiki so far. It's irrelevant. As I already stated even if it was the hardest thing in the world it should still be on that page because it's about MediaWiki development. Currently that page doesn't even list a MediaWiki extension. In contrast, you keep ignoring all my points and don't address them. These include the context of the link and the title/purpose of the page. New MediaWiki developers requires MediaWiki development.
Dec 5 2021
It's good to have this discussion and I think it's moving closer to reasons. However, I still can't see reasons for why MediaWiki shouldn't be there. I repeat what I have said before:
Well fine, that's your opinion. Apparently you'd like to have volunteers to not develop MediaWiki. Is MediaWiki not important software to you? I'd like to understand why you oppose this and also think that it's necessary to provide a reason for closing this.
Reopened: it makes absolutely no sense to not even mention MediaWiki even though it's the core, main Wikipedia/Wikimedia project and has a large backlog of open issues (even utterly basic ones like a working Watchlist) and a severe lack of new developers.
May 20 2021
I rendered a smaller version and the upload went through. I think that it was caused by the filesize. Please fix the error-message and please consider raising the filesize-limit.
May 19 2021
This seems to be related: T279407
Do I need to rerender to be able to upload it? I'm asking because the rendering (with Kdenlive) takes a lot of time and in that case the error-message should say so.
Feb 28 2021
@Aklapper Please see (including the link):