Mon, Jan 28
It can be switched on by var cdAllowEditOthersMsgs = true; ;-)
What's wrong with standard "Edit description" feature? Topic name edit is just like a normal message edit.
Sun, Jan 27
Sat, Jan 26
Theoretically this could be done by a plugin relying on cd.sectionsReady hook. But this may lead to problems with new messages navigation and messages highlight zone redrawal mechanism.
Thanks for the PR, but I think using CSS would be a better idea. We would have to add a space between items for white-space: nowrap to work properly.
Mon, Jan 21
Hello. @Aklapper, well, it's nothing but a small project, it's total code size is about 400 KB after Babel, 200 KB with uglification. I plan to spread it to other projects, so interproject communication on Phabricator would be nice. Its github repository is here: https://github.com/jwbth/convenient-discussions. So, do you ask to create a repository on Gerrit too?
Jan 7 2019
Dec 12 2018
Dec 9 2018
Dec 7 2018
Dec 5 2018
Nov 30 2018
@Schnark So, what is it based on? Technical unfeasibility? Perceived lack of necessity? There are users who are not happy about it. I think, some would say, there is no need in the hiding/showing functionality at all if the state is not saved in a cookie. The only thing it does when used on one page is saves a small amount of space.
Nov 29 2018
Nov 28 2018
The problem is that adding the class hatnote doesn't help, I've tried that on https://ru.m.wikipedia.org/w/index.php?title=Истомин,_Константин_Иванович&oldid=96534177.
Nov 27 2018
Oct 1 2018
Aug 27 2018
Aug 7 2018
Just to make you know: in ruwiki, we adapted RockMFR's "magic editintros" to work with VisualEditor (although the resultant script is rather hackish), see https://ru.wikipedia.org/wiki/MediaWiki:Gadget-blpEditNotice.js.
Aug 2 2018
@Krinkle Thanks for the detailed explanation.
Right now we have at least 3 widely used gadgets that would need such query, probably there will be more. Having 5–10 additional requests doesn't seem to make negligable difference. Many such gadgets also add elements that shift content on pages which in turn causes misclicks, so the earlier they run the better. Anyway, is it so difficult to implement? I thought splitting large JS files into modules according to the semantics of different code parts and loading them, together with other modules, in one package is exactly what ResourceLoader is for.
Right now many people who ask for interface-admin (see T190015) permissions in ruwiki are worried about the ability to edit gadgets data. But with the current state where the integration of JSON with gadgets is poor, the ability to load external JSON for gadgets is very limited. Hence, the efforts to integrate JSON with ResourceLoader as soon as possible are essential from the perspective of the interface-admin flag purpose.
Jul 30 2018
Can't the <style> tags be moved to some centralized place altogether? Their scattered presence in HTML causes problems like mentioned here, in T186965 and in T200704 (I opened the last task just recently).
Jul 29 2018
Moreover, it's true for user JS/CSS as well. As I remember, those used to be updated instantly.
- The behavior is not consistent: if a reference (the text at the bottom of the page) is visible to the user (i.e. if the citation link's (like ) target is visible in the screen), hovering the mouse on the citation link won't show a pop-up with the reference. Instead, the reference at the bottom will just be highlighted. You can see an example here (the citation link is at the right of the screen below the image): try hovering the citation link when the Sources section is visible on the screen or not. Note that this is an intended behavior which can be easily changed in the code and is common to both implementations.
Jul 17 2018
Yes, pretty much looks like.
Jul 15 2018
Jul 14 2018
As I can see, the first change is live. How about the second (adding newlines that weren't in the source)?
Jul 12 2018
Sure, purge is useless in such cases.
Jul 11 2018
No, was just trying to select an appropriate tag.
Jul 8 2018
That's very disturbing as many popular images are effectively spoiled after reuploading with minor adjustments.
Jun 23 2018
Don't really think it depends on that, but added.
BTW, my self-written code (see at the bottom) for 2017 wikitext editor works well in both cases.
Jun 21 2018
Jun 20 2018
Jun 19 2018
Okay I assume I'm wrong about opt-out (just too many fellow users reported that). The issue still stands though.
Jun 18 2018
Jun 16 2018
Jun 15 2018
Jun 13 2018
Jun 9 2018
We largely updated Reference Tooltips gadget in ruwiki, and welcome other wikis to update to it. Other suggestion is to create a global gadget based on it.
- Tooltip style & animations are updated to be consistent with Page Previews' style & animations.
- Many bugs are fixed (see the list here).
- Harvard-style citations are now supported.
- Tooltips inside tooltips are now working properly (they did work before, but there were bugs associated with this behaviour). See the animation.
- An option is added that allows to convert native browser tooltips for titled <abbr> tags and such into gadget tooltips. It is default on touch devices, allowing users of the desktop version on such devices to see them.
- The settings dialog is rewritten using OOUI (its modules are loaded on demand) and looks similar to the Page Previews settings dialog.
- Saving the settings doesn't require page reload anymore.
- The coding conventions are applied.
See more details at the gadget's mediawiki.org talk page.
Jun 8 2018
Thank you, @matmarex. Sorry, had to time.
Jun 4 2018
Jun 2 2018
Thanks, I guess that's it.
Jun 1 2018
I guess I'm incorrectly mixing DOMContentLoaded and moments of execution of its handlers here, here's one of my 2016 tests of in which order the hooks/events are fired on the action=edit page:
1480205746966 resourceloader.loadEnd 1480205747184 wikipage.content 1480205747356 wikipage.editform 1480205747566 ext.wikiEditor.toolbar 1480205747569 $ 1480205748301 doneInitialSections
Well, it was present in the documentation (now it's not). As I remember, it was a good way to catch a very early moment which used to happened even before DOMContentLoaded has fired. Not sure if it was conceptually appropriate for our purposes though; we used it to coordinate loading order of many related scripts & gadgets. Anyway, we now don't need it where we did, since we now do most of the task with gadget dependencies.
Scripts dependent on resourceloader.loadEnd hook have broken. Was it planned? Was the hook removed?
May 26 2018
May 18 2018
May 11 2018
Thanks! I guess the method we use was acquired from some documentation that is now outdated.