Nov 7 2019
Oct 18 2019
In T18691#5585283, @MusikAnimal wrote:
If there's a native way to easily get permalinks, people will eventually learn to use them, and save the follower of those links a lot of time. It's very un-fun trying to dig through archives and revision histories to just find the discussion.
Oct 14 2019
Some edge cases that came up while I was writing reply-link:
Feb 2 2019
Jan 10 2019
@Legoktm actually, would it be worth the effort to detect if it's a talk page (versus a template)? Transcluding pages in talk or project talk intuitively (in my opinion) shouldn't send out pings
brain fart, my bad
Dec 25 2018
Can we exempt localhost URLs from this? It would impede user script development.
Dec 18 2018
Nevermind, turns out I was messing around with my personal CSS a bit too much.
I've also linked to the on-wiki documentation from the tool's main page. Let me know if I should make any more changes.
Dec 3 2018
Nov 30 2018
+1 to all of what Anomie said.
Oct 30 2018
Basically just T207565, should be very easy (as the person who wrote a user script to do this)
Oct 26 2018
I've been getting this for some time on Firefox. Yeah, the logic for positioning the popups and divs is... a bit weird, even by Navigation Popups standards. Nevertheless I think there's some relatively low-hanging fruit with regards to mouse detection, so I'll do some more experimentation with that and see if we can fix it.
Oct 8 2018
Absolutely agreed, this is a great idea. Thanks to Tgr for making it. I'd rather not have the preferences for my app go in a freeform wikitext page, and this is much better!
Sep 28 2018
In general, it's important for bots to be able to ping editors. On ENWP, I plan to have a bot ping users from a centralized talk page to reduce spam.
This shouldn't happen, unless the process of archiving adds a new signature.
merged, as we should be talking about this in only one place
Sep 16 2018
Ah, I see. Could some text be added to indicate this, maybe hidden in a tooltip?
Sep 11 2018
I suppose, of course, that the interception performed by that extension is bypassed if someone uses the API.
Sep 2 2018
"Blacklist" and "whitelist" are the canonical technical terms for access control mechanisms like this. Changing the name would create unnecessary confusion.
Aug 23 2018
Was just burned by this today. At the very least, it would be nice to disable creation of two filters with the same name while we figure out what else the interface should do, because that's basically a bug.
Aug 19 2018
Possible explanation proposed by Brion on Mastodon, from https://mastodon.technology/@brion/100575141289871028: "there's some nbsp replacement around certain punctuation to handle patterns common in French"
Aug 16 2018
@matmarex Thanks for the link! That helps. I'm talking about the removal of mw-space editing perms from the sysop right. I assume it'll be the European mid-day SWAT, like the July 30th change? Or will the config be changed at a different time? I mostly am interested in what time on the 27th of August these other changes will happen.
Will the configuration changes to enable this (i.e. the user group changes) be on the deployment train for 1.32.0-wmf.18?
Aug 8 2018
I wrote a script that may help, at https://meta.wikimedia.org/wiki/User:Enterprisey/multi-lock-helper.js. It adds a link in the section header with a link to Special:MultiLock.
Jul 28 2018
Jul 11 2018
This happens again:
Mar 28 2018
Mar 27 2018
Mar 26 2018
Mar 25 2018
Mar 20 2018
@TheDJ Awesome - if there were other people willing to mentor on the community outreach/integration side of this, would you be okay with mentoring the parts strictly limited to the gadget code (assuming you're going to be available occasionally to check in on the code work)?
Mar 13 2018
Mar 12 2018
I'm not as experienced with extensions as I am with gadgets, so I don't think I would be the right person to do that. I was thinking about learning about extensions in time for next year's proposal round, though.
Feb 23 2018
Sep 25 2017
I can also take a look at this - the proposed patch looks pretty interesting.
Sep 17 2017
Problem still persists:
Jul 28 2017
Jun 28 2017
Jun 27 2017
TheDJ, yup, that'd be for the gadget. @Fomafix, are you using the gadget or the extension? Based on that error message, I think it's the latter.
Jun 24 2017
There is no variable (or anything else) used by Popups with the name $activeLink. I'm not sure how to fix this, so closing for now.
Commenting here to remind myself that if this goes into hovercards, I'll put it into navigation popups as well.
Jun 6 2017
@zhuyifei1999 (sorry for the delayed response!)
Jun 2 2017
I get these while stopping but not while starting, with the same traceback:
Jun 1 2017
May 3 2017
When I get back to hacking on Popups, I'll be sure to prioritize getting your patch working.
I like this idea; are you talking about taking the existing translations (the ones on each language's wiki, usually imported together with the main one from ENWP with a HTTPS request) and making them centrally available or something?
Jan 19 2017
Jan 6 2017
I'm not having this bug anymore (FF 50.1.0 on Ubuntu.)
Jan 2 2017
Dec 23 2016
Patch for review here.
Yet another formatting bug that would be fixed by T138803.
Nov 11 2016
If I'm reading T42284 right, this task shouldn't need any actual codebase changes - we only have to get an admin to mess around with the Mediawiki gadget config.
Oct 26 2016
Jul 19 2016
Note that Popups is going to have to stop checking for pg.re.basenames in isPopupLink() before this can happen.
Jul 16 2016
Jul 12 2016