If this is too complex at this stage of development, I could suggest falling back to : intentation if the comment has more than one line, as starting each line with * is IMHO much more misleading and potentially annoying than choosing : indentation for a whole comment, since it violates the principle "bullets denote comments". (As a side note, this doesn't affect CD users as they see thread lines on the side of comments, not bullets or plain indentation, see example.)

Accessibility is actually one reason why some of RuWP users argue for using *, not :, as well, since : are description lists that necessitate the use of <dt> (; in the wiki markup). I haven't conducted research on how <ul>s (*) and <dl>s are actually treated by screen readers and such, and that information is welcome.

Thanks for implementing this change. The implementation is faulty though. Perhaps I should have mentioned this earlier, but it didn't came to my mind and you didn't ask.

In T29766#7624332, @Krinkle wrote:

In T29766#7615521, @SD0001 wrote:

In any event, making the withgadget feature opt-in is trivial with a boolean option. Something like [allow-impromptu] or [anywhere=allowed], with the documentation mentioning that the option allows the gadget to load by permalink even on accounts that have not chosen to enable it.

Note the patch suggested by @Ammarpad: https://gerrit.wikimedia.org/r/752995.

In T298909#7613916, @DLynch wrote:

Potentially fragile, but if you get in before DT actually does its initialization then you can disable a lot of it by changing the properties on mw.config.get( 'wgDiscussionToolsFeaturesEnabled' ). e.g. mw.config.get( 'wgDiscussionToolsFeaturesEnabled' ).newtopictool = false will stop us from hooking the relevant new-section links in the first place...

Thanks, I'll check it out.

In T298996#7614747, @Krinkle wrote:

Note that VisualEditor has a plugin interface, which is based on loading RL modules that are listed in mw.libs.ve.targetLoader.addPlugin, or wgVisualEditorPluginModules, or queued via mw.hook( 've.loadModules' ). If a gadget is using this today, then presumably it is already working as intended.

Thanks for sharing this. There was a race condition in the code previously suggested by the docs (or at least this ended up in RuWP's Common.js):

mw.loader.using( 'ext.visualEditor.desktopArticleTarget.init' ).then( function () {
  mw.libs.ve.addPlugin( function () {
    return mw.loader.using( 'ext.gadget.gadgetName' );
  } );
} );

– this had resulted in tools sometimes being loaded, sometimes not when the user opened &action=edit or &veaction=editsource directly instead of clicking "Edit source" on the article page. With the updated code, all gadgets and even user scripts I checked get loaded in time to add their button.

In T204201#7615575, @PerfektesChaos wrote:

Every useful gadget may be called from an external wiki. In this case, no Gadgets-definition is present, and there is no official support for cross-wiki usage of gadgets via URL yet.

Wouldn't URLs like https://en.wikipedia.org/w/load.php?modules=ext.gadget.Navigation_popups work cross-wiki? (Although I agree, forbidding some action=raw URLs seems a little extreme.)

In T259864#7614888, @matmarex wrote:

I started looking into matching your implementation of indentationCharMode: 'mimic', but then I realized that Russian Wikipedia uses the 'unify' mode, which already matches the behavior of DiscussionTools, as far as I can tell. Am I missing something?

No, that's correct. I just thought you came to a conclusion that mimicking the comment being replied to is better than simple unify from the perspective of the junior-senior contributor dynamic :-)

In T259864#7610216, @ppelberg wrote:

In a meeting the Editing Team had on 15-Dec-2021, we came to think a good first step (see "Thinking" below) would be to implement an approach similar to the mimic mode @Jack_who_built_the_house described in T259864#6931828.

Just want to note that the current behavior of CD's mimic mode is to repeat the indentation of the previous comment when posting a comment at the first level (i.e., replying to a topic), not the indentation of the comment being responded when replying to a reply. The broad idea behind that is:

• There can be different indentation styles on the same wiki. For example, you can often see topics at EnWP's Village pump where people use * indentation despite that in most other places, : is the convention.
• On default settings, at least for the first level comments, the tool should work as users expect on the wiki. So, mimicking the style already used is the safest way.

Right, CD currently displays a warning notification and offers a link to disable (that performs an option API request), although when Reply Tool gets enabled in Russian Wikipedia by default, I expect a lot of confusion among users about what is DiscussionTools and why they need to disable it, so I was thinking about automatically disabling it on the part of CD and displaying a notification about that.

In T204201#7606993, @Ciencia_Al_Poder wrote:

As per template gadgets, it may be useful a magic word or TemplateStyles-like extension that loads a specific gadget on the page, rather than defining the list of pages/templates it should be loaded on the gadget definition. However, for security, those gadgets should probably be explicitly marked as "safe to be included in pages" in the gadget definition.

A list of pages/templates as a condition seems like a bad idea to me, I explained why. A more reasonable choice is a category that can be hidden. Hard to say whether a magic word or an explicit option in gadget definitions is better. But not all gadgets that should load based on category could be described as "template gadgets". Both English Wikipedia and Russian Wikipedia currently have an universally loaded code for a BLP notice for pages with "Living people" and "Possibly living people" categories. In Russian Wikipedia, these categories are added by templates, but in English Wikipedia, they are placed in every article. So, a magic word will not work in that case.

In T204201#7606993, @Ciencia_Al_Poder wrote:

Until all of this gets ever implemented, it may be a good idea to split those gadgets into 2: Move all the gadget contents and dependencies to a new hidden gadget, and leave on the primary gadget only the logic for activation, and a call to mw.loader.load() that loads the hidden gadget. This would reduce the length of JavaScript code that gets loaded on all pages that don't make use of these. The drawback would be it takes more time to load (probably not critical for most gadgets).

We did exactly that (except that we didn't split each gadget – just included the conditioning code in Common.js) for default gadgets for actions, special pages and namespaces, and now, as actions is introduced in Gadgets-definition, starting to remove this code. Hopefully the same happens for special pages soon. Namespaces could be less urgent/relevant.

I currently think, after page actions as selectors are implemented, the next capabilities worthy of implementation can be special pages and categories. For example, in Russian Wikipedia:

• We have as much as 7 default gadgets for special pages.
• We also have a significant number of scripts/gadgets that run depending on the content of the page (generally, inside templates). I see "Transcluded page" is mentioned in the task as a separate item, but I suspect a (most likely, hidden) category would serve better as a selector. Not too specific, template moves wouldn't affect gadgets, multiple templates can contain the same category.

In T298359#7591899, @Majavah wrote:

the current optimization on most logos is performed using this script. I tested them on this image which produced about 25% savings on the raw file size.

Thank you for showing where to look. So, it's basically zopflipng that worked in this case.

npm install --global zopflipng-bin
zopflipng --lossy_transparent -m Wikipedia-logo-v4-ru-xmas_135px.png --prefix="optimized-"

I too got a 25% (well, 24%) smaller version, and I don't see any visible quality loss (don't look at the previews, click – Phabricator applies its own compression to previews):

Original	Result

In T298359#7591792, @Jack_who_built_the_house wrote:

the CSS gadget in ruwiki exists not as an initiative of the interface administrators, but as a will of the community, part of which wants an easy way to opt-out all logo changes

By the way, could there be a technical way to have logos be changed by request and still keep a way to opt out of changes? This way, the gadget could still work to cancel the logo change. Something like this:

<a class="mw-wiki-logo mw-wiki-logo-temporary" data-original-logo="//ru.wikipedia.org/static/images/project-logos/ruwiki.png"></a>

Then there should be a way to specify in the config that some logo is temporary (if there isn't already).

In T298359#7591702, @Majavah wrote:

Yes. To clarify, this is a sysadmin-imposed policy that all interface administrators are expected to follow.

Thanks for informing. But there is a problem – the CSS gadget in ruwiki exists not as an initiative of the interface administrators, but as a will of the community part of which wants an easy way to opt-out all logo changes. Interface administrators also can't override community decisions. Obviously, interface administrators (and me personally) could initiate a discussion where we could describe the official guideline, but it's not 100% that this discussion ends with its adoption.

Now that this lucky day is near, I want to remind that with this patch, MediaWiki makes a small step to reduce the attack surface involving Interface admins. After data is moved to .json that is bundled with the gadget, people who hold this flag solely due to a need to edit some data stored in JS will no longer need it and can have their permissions revoked with no worries.

Look, this task wasn't positioned as "Timeless skin doesn't deliver something that is officially supported by MediaWiki". (I'll rename it so that it better conveys this.)

In T298359#7590974, @Izno wrote:

Yes. See meta which points to T256295: [[meta:Logo#Temporary logo variants]] should not advertise local CSS overwriting. (I found a couple places on MediaWiki wiki that still advertise this.)

Thanks. The guide for changing a logo is also helpful (which answers my first question – a good timing is probably achievable). But I'm not sure that the community would consider the reason mentioned here (traffic increase) as enough to give up the convenience of disabling the logo (although I know that this could be seen as a manifestation of a bias editors have against readers). The current ruwiki logo size is also quite low, 8KB, so traffic increase is insignificant. And it is cached.

...I forgot one of the main reasons why a gadget is used – some users just don't like the logo being changed. So, unless there is a way to have different logos for different users according to their preferences, CSS hacks will be used, I believe.

@Izno Do you mean a config change should be requested every time a logo is desired to be changed? Is it possible to have a good timing for such logo changes? Also, I know for sure that wikis exist that use custom logos for particular pages. Can you demonstrate how this can be done in a way other than a CSS hack?

In T271906#6743248, @Ciencia_Al_Poder wrote:

If you're talking about the CodeMirror editor, it may be doable (if not done already), and this task would need to be assigned to that project.

This would be extremely helpful for Russian Wikipedia where all &nbsp; are replaced with a symbol by an automatic instrument (Wikificator) that is enabled by default. The lack of such highlighing is the root of many disputes that are easily avoidable. (The most recent is today.)

In T297071#7550699, @TJones wrote:

I can also put in 126 4-byte smiley faces (😀😃😄😁😆) or 4-byte CJK characters (丽丸𠄢乁你)

I think you can put 63 of them (tested in Chrome and Firefox), it's just that '😀'.length and '丽'.length returns 2.

DiscussionTools also doesn't work on pages with % in the fragment.

Thanks.

T296149 that I created documented a similar bug except my task was about on-page navigation using the table of contents. But by all appearances they have the same root issue. So, both on-page navigation with "Back" and "Forward" and keeping the scroll position in the case of cross-page navigation are impaired.

Will there be any uses left for the "unsubscribed" state in the database? (First of all, I'm trying to figure out whether I should keep track of this state in Convenient-Discussions, if I make CD's behavior the same as planned here. But also one could wonder what will be the point of keeping "unsubscribed" entries in the database after the differences in behavior disappear.)

Is there any global task dedicated to moving MediaWiki further to the Ajax paradigm, or are there any such plans at all? This feature is one that came to my mind as well, but I thought I makes not much sense as long as history pages aren't dynamically updated as well, like the modern watchlist does. I see that MediaWiki is deemed to be just OK with static pages (given that Ajax has been around for a very long time, and only few pages have adopted it so far), but I don't quite see what would change for the worse if it moves in that direction, and I clearly see what would change for the better.

In any case, there must be high demand for receiving notifications right when the comments are left, not after a delay. Topic subscription is a great innovation that makes Wikimedia projects closer to the original meaning of the "wiki" part of their name by eliminating the pain of constantly refreshing the watchlist (or even visit different watchlists if you're active on different wikis as long as MediaWiki-extensions-GlobalWatchlist is not in its best shape).