scratch codes or the QR code

Right, this is even worse than intercepting the code.

Can anyone from the ruwiki community confirm?

I confirm: a newly registered account didn't get Reference Previews.

I can confirm the stated behaviour. I've registered a new account after logging out from my account. The new account didn't get any of the beta features except ReferencePreviews.

Ruwiki uses the same Reference Tooltips gadget as enwiki. I've made the last big update to it in both wikis. The beta feature has several shortcomings some of which are critical to many users. I and other users have pointed some of them out on the project talk page.

For anyone interested, I've solved this in my script with these two commits.

Hello. This change broke $.wikiEditor.modules.toolbar.config.getDefaultConfig() usage in my widely used script for talk pages. Thanks to getDefaultConfig(), wikiEditor could have been used for any textarea of choice. I had to hardcode the toolbar config like this: https://github.com/jwbth/convenient-discussions/commit/b861eadf553bba4e8718b129ab41bde3cec11d3f, adding 42KB to the code size. Please tell is there a nicer way to overcome this. @Catrope @Krinkle

It can be switched on by var cdAllowEditOthersMsgs = true; ;-)

What's wrong with the standard "Edit description" feature? Topic name edit is just like a normal message edit.

Theoretically this could be done by a plugin relying on [cd.sectionsReady](https://ru.wikipedia.org/wiki/Участник:Jack_who_built_the_house/Удобные_дискуссии#Хуки) hook. But this may lead to problems with new messages navigation and messages highlight zone redrawal mechanism.

Fixed here and here.

Fixed here.

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.

Hello. @Aklapper, well, it's anything but a small project, its 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?

Thanks.

@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.

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.

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.

@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.

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).

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 [1]) 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.

Yes, pretty much looks like.

As I can see, the first change is live. How about the second (adding newlines that weren't in the source)?

Sure, purge is useless in such cases.

In T179544#3734623, @MaxSem wrote:

I have a silly question: why do we even use reference names in IDs? Because these IDs are also using reference numbers, they're not stable anyway.

No, was just trying to select an appropriate tag.

That's very disturbing as many popular images are effectively spoiled after reuploading with minor adjustments.

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.

Okay I assume I'm wrong about opt-out (just too many fellow users reported that). The issue still stands though.

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 code is refactored. Tooltips & elements having them are objects now. The script used jQuery and pure JavaScript inconsistently – now it uses the first everywhere where appropriate (performance losses are negligable).
• Old IE support is removed (JavaScript isn't loaded to them anyway).
• The coding conventions are applied.

See more details at the gadget's mediawiki.org talk page.

Thank you, @matmarex. Sorry, had to time.