This bug can be easily encountered in a OOUI dialog, even if you place the button to the right.

Fun fact: as far as I understand, in order to implement the section action menu as in this demo (it's hidden behind display: none but is present with the class ext-discussiontools-init-section-actions), you will need this fixed.

If the gradient is kept, a left-to-right gradient would make more sense from the design point of view. A center-to-right gradient, as I said, is leftover from the times when the menu looked like this.

Thanks, fixed in https://github.com/jwbth/convenient-discussions/commit/bd2e64c9bd6f14d6efce4743cc928f9bb9800e10, will be online soon.

Convenient Discussions should probably check whether $wgServer is a protocol-relative or a protocol-absolute URL, and prepend "https:" accordingly.

This is currently done in https://github.com/jwbth/convenient-discussions/blob/1c4beeefd9f97f1ec6b1fbd00b918966eeca7f44/src/js/app.js#L299.

If I understood you correctly, you talk about how the actual script behaves? Unfortunately, I didn't have time to update the script; plan to do it soon though.

@NguoiDungKhongDinhDanh This seems to be a Chrome bug. Works even on google.com. Good catch; wrong place though 😄

Thanks for the report. This is the result of the conflict with DiscussionTools. You may disable it in the preferences to get rid of this error. In case you want to continue to use them together, this error will be fixed in the next release.

Right, CD's comment editing capability incorrectly handled tables

1. having ! markup,
2. having a signature inside (which means the table markup is clipped at the location of the signature).

Thanks, will be fixed in the next release.

Right, the center-to-sides gradient (left over from the times when the menu looked like this) doesn't make sense in old Vector as well.

If this is too complex at this stage of development, and if the accessibility concern is considered valid (although it may need additional research, and if accessibility really is to be taken seriously, much would need to be rethough), 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 certain 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 and wanted to clarify the meaning of mimic in CD :-)

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.

Doing the above would mean all new comments people people using the Reply Tool at ru.wiki would be indented using * EXCEPT in cases where the comment being responded to was indented with an :. In this latter case, the Reply Tool would indent the comment being posted with a colon.

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 to 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/tag or an explicit option in gadgets definition 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 a 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 conditions have been implemented, the next conditioning capabilities worthy of implementation can be special pages and categories. For example, in Russian Wikipedia:

• We have as many 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 condition, 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. 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 of 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 (great credit to SD0001), 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 if the community would consider the reason mentioned there (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 for the use of gadgets – 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 preference, 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.