Nothing to see here...
User Details
- User Since
- Mar 16 2015, 6:21 PM (495 w, 8 h)
- Availability
- Available
- IRC Nick
- AfroThundr54230
- LDAP User
- AfroThundr3007730
- MediaWiki User
- AfroThundr3007730 [ Global Accounts ]
Sep 1 2019
Aug 31 2019
So far as I can tell, we've yet to resolve the matter of retrieving the old data from the education extension. This should probably stay open until then.
Jun 9 2019
In that case, since this is a long-running epic -- one who's main task has not yet been resolved -- I have reopened it, and also added the other task for tracking.
I believe that's what this bug is already doing, judging by the related tasks list, comments, and commits. Changing the title might be more apt than closing (something like "Support native client-side SVG rendering"). Also when considering that its related subtasks are still open, it doesn't make much sense to close at this point.
Wasn't this bug about native client-side SVG rendering, without relying on third-party scripts?
May 8 2019
Is there any plan to let the maxage parameter work correctly? Currently it still returns a Cache-Control header with max-age=0 despite explicitly setting it to a higher value. Using bcache=1 isn't changing the behavior either.
Apr 20 2019
@kzimmerman First off, thanks for checking up on this.
Apr 9 2019
Just my two cents, but wouldn't it make sense to reserve all one-, two-, and three-letter URLs for future use? The extension could start the counter at four-letter codes (like 'aaaa' or something) and leave the shorter ones open. That would allow the single letter ones to be used for important things like projects, and the two- and three-letter ones to be used for language codes and such.
Mar 12 2019
If we're concerned about new users being shown unnecessary info, this could be restricted to logged in users or even privileged users when using Special:CreateAccount
Mar 3 2019
@Tbayer Sorry to keep bugging you, but have you been able to find time to finish this? We've been making waves on the Village Pump (again), and with the new discussions underway, I think this data would help shed some light on how the namespace is used. Off the top of my head, I can't think of anything else to add to the above request - not until we see the data, at least. Thanks again for looking into this.
Jan 4 2019
No worries, I figured things would slow down over the holidays.
And your request had the bad fortune of being the first time that this issue in our existing data surfaced...
Nice. Gotta keep you guys on your toes somehow. :)
Jan 3 2019
Dec 30 2018
Dec 13 2018
First off, thanks for looking into this. Now let's dig in.
Dec 11 2018
If you were to add a user preference "Don't open redlinks in edit mode" that applies regardless of the currently configured editor, that would pretty much solve the problem. The interface would just have to not append &action=edit to links that have &redlink=1 in the URI. I have a bit of user JS doing pretty much this exact thing as mentioned in T195914.
Dec 5 2018
I agree with @NickK that being able to show more than 1000 entries is very handy for RC and CVN work. At the moment I have to use multiple tabs, each with different filters to "break up" the number of entries, since I'm limited to only 1k per tab. Perhaps restoring the previous limit of 5k would be better? If it's a question of users abusing the high limits, maybe limit it to extended confirmed or higher?
@1997kB I didn't think about that. Then yes, we'd need a way for sysops and account creators to override that. I'm not even sure how that would work. Would there be a box added to Special:CreateAccount to input a global account name and force local creation? Or would there be a limited access to Special:Block specifically to override the account creation blocked flag?
An alternative would be to modify how the "Account creation blocked" flag works, so that it doesn't apply to an autocreate via the global account.
Dec 2 2018
Also repeating here: that snippet above using just an a.new selector only works for redlinks in the page body (since they're only generated inside mw-parser-output). It will still leave links with &action=edit elsewhere in the interface (article/talk page tab, edit history, contribution history, log entries) if the page is nonexistent. Adding an option to not open the new wikitext editor in edit mode on new pages would be helpful.
Nov 27 2018
I agree with Majora and Risker that this change should be communicated to all the projects affected (enwiki is already aware, of course). This should be posted to all the relevant Village Pumps or equivalent.
Nov 26 2018
@Tbayer Just curious if the analytics team had time to pull any data for this yet.
Nov 19 2018
As I just posted on WP:VPT, I use the following snippet in my common.js to neutralize the annoying behavior:
(function() { var len = document.links.length; for (var i = 0; i < len; ++i) { var l = document.links[i]; if (l.href.indexOf('&redlink=1') > -1) { l.href = l.href.replace('&action=edit', ''); } } })();
Essentially, we would like to be able to disable the default behavior of automatically opening redlinks in edit mode.
Nov 16 2018
Nov 14 2018
Related VP discussion: WP:VP/T#Issue with my Special:Contributions page?
Oct 21 2018
Issue opened on Github: https://github.com/openzim/wikimedia_wp1_bot/issues/7
Oct 6 2018
Thanks for looking into this. We're still in the process of discussing the construction of the RfC and the criteria for the guidelines, so we have time. We want to be thorough and build a proposal that will withstand thorough community scrutiny. You can see the ongoing discussion for details on how that's progressing.
Sep 28 2018
Sep 21 2018
Sep 13 2018
Ok, so I managed to pin down why the editor save box doesn't show up sometimes. When editing a non-talk page, clicking the tab for that page triggers the editor save box (e.g. "read" tab on an article, "project page" tab on project namespace, etc.), but clicking anything that would change the URL (talk page, main page, your user page, etc.) triggers the browser's unsaved changes prompt (so no ability to discard).
Sep 10 2018
Aug 9 2018
This sounds to me like something that T107595 (Multi-Content Revisions) could be useful for.
Aug 6 2018
Jul 6 2018
Jul 2 2018
Perhaps there should be a user preference implemented to turn off bot-generated notifications.
And now the latest example: https://phabricator.wikimedia.org/p/Vvjjkkii/ - Wrecked several thousand tickets, before they were disabled on 20180630.
Jul 1 2018
I think we've got them all at this point. At least I don't see any more from his activity feed. I stand corrected.