Do people refer to the logos by their position or their filename or the SVG filename? It happens that they are not coinciding.

Thanks for the ping. Yep, this is still happening (something was wrong with the links, I fixed them). Examples of articles where this is currently happening: https://ru.wikipedia.org/wiki/Кутузов,_Михаил_Илларионович, https://ru.wikipedia.org/wiki/Барклай-де-Толли,_Михаил_Богданович.

Yup. The task is to generate correct links to comments on talk pages. We have UTC timestamps on the watchlist page, but on other pages we will have to make additional API request(s).

So, for the purposes of Convenient Discussions, the best solution would be to have a UTC timestamp somewhere in a data attribute, like it is done in the watchlist (but not in user contributions pages, history pages and diff page headers). An alternative seems to be loading kilobytes of timezone data provided by modules such as Moment Timezone.

I should note that, in Convenient-Discussions, the issue is inferring the UTC time from localized time. So, if I correctly understand the workings of mw.user.options.get('timecorrection') (explained in T223002#5843155) and how user timezone affects log pages such as user contributions and history, while both solutions (by @SD0001 and @TheDJ) will definitely move us closer to correct behavior, neither of them will work reliably. On one page, both dates in DST and standard time can be present. So,

• With the current user timezone offset, only the most recent dates will be interpreted correctly.
• With Date#toLocaleString (if it is reliable itself), we can only do the opposite of the operation we need: convert UTC time to local time. So we can pretend we have a UTC date, infer the timezone, and then use it to correct the date. But the result of such conversion will be wrong during the several hours near the transition time.

Hm, I think the same issue appears when I try to save user preferences using the standard interface at https://commons.wikimedia.org/wiki/Special:Preferences.

In T259864#6914872, @Whatamidoing-WMF wrote:

@Jack_who_built_the_house, the team's wondering whether this should be handled as a config change (have to get a dev if you want to change it) or as a MediaWiki: message, which could be changed locally by any interface-admin. This might only be used at ruwiki, so I'd like to know what you recommend.

For ruwiki, I don't see much difference, as this value is unlikely to change. But I doubt this won't be used in other projects, since at least there are Russian projects other than Wikipedia that will likely use the same indentation, and that could also be the case for wikis in languages of Russia and CIS countries, since many of them have the same users and customs. But honestly I'm a rare guest there, and I don't know which indentation is used where. So, perhaps it would be easier for them to edit a MediaWiki message? I don't know.

These are fair points. Still, the main concern here, I believe, is readers, the absolute majority of whom don't ever visit talk pages, which gives your digit of 0,0001%. If there was a way to expose a page property to frontend other than configuration (that is set on all pages or something like that), it would be beneficial to a significantly higher share. Say, the nonewsectionlink property is de facto introduced to frontend via the presence of the #ca-addsection element.

Regarding __NONEWSECTIONLINK__ and discussion pages—in Russian Wikipedia, a lot of pages (including forums, the main meeting place, analog of "Village pump" in enwiki) use "New topics on top" topic order. Many of these pages don't use __NONEWSECTIONLINK__ because they are in the "Project" namespace, where there is no "Add topic" link anyway, but others do use. The other reason to use __NONEWSECTIONLINK__ is to have some special editing mode on the page, i.e., adding topics with preloaded text from a template (preload= query string parameter). These could be applications to participate in an event, to request a flag, to nominate a page for a certain procedure.

Don't know if it has any worth, but here's the model that Convenient-Discussions uses to differentiate between types of pages where the script can load. With each of these types of pages the script behaves differently.

Do you think the "cite" element should also be included in the list? Currently it is used in the English Wikipedia quote templates such as Cquote, Quote box, the search returns a couple of results where it contains signatures. The Talk quote block template, on the other hand, doesn't contain the "cite" element.

@Taufik Thanks for the question! It's a noun, the summary of the edit. I'll update the message documentation.

Nah, that task is about Convenient-Discussions.

Is this fixed globally? @eranroz I see extra whitespace in the TOC in hewiki due to your edit that is absent in other wikis (if you hover a section title, the leading space would be underlined, see below).

Somehow this is fixed, so hurray.

@Iniquity This should be fixed, please recheck.

Thanks to the coordinated efforts of @Iniquity, @IKhitron and also myself CD now supports RTL, and also LTR interface on RTL wikis and RTL interface on LTR wikis. Please reopen if you see any shortcomings.

But the problem is, we would need to lay it on top of the existing icon, and there is plenty of them on Wikimedia wikis.

If using an icon, the OOUI pencil icon could be used:

In T262073#6438125, @Iniquity wrote:

I'm not entirely sure if this function is needed. Nobody seems to do this on any site.

Well, the justification why it would be useful was made by @JAnD and @Sunpriat at https://www.mediawiki.org/wiki/Topic:Vtbmyswhmrwufpxv. When a page is edited with the standard interface, the title is "Editing [pagename]" so users can quickly pick up where they were editing.

Thanks.

So, project members can't edit their descriptions? Do I need to get added to Trusted-Contributors to be able to edit the description of a project I maintain? How do I do that?

So, my current thoughts are the following:

• In contrast with DiscussionTools, many comment forms can be open simultaneously in CD.
• In contrast with DiscussionTools, users may also edit comments, reply to sections, and add subsections (in addition to replying and adding a section). These may need additional labels if we decide to put labels in the title.
• We perhaps need to change the title as these forms receive focus.
• We probably don't need to change the title if a form loses focus, only when a form is closed. Users can click links, select text on the page and then quote it in the form—in these cases, they are still working with the form, still replying/editing/creating a section.
• The solution that I see is to prepend labels like "Replying to" to the title (not including the number of new, not yet shown comments that is added in CD in parentheses, like "(1)"). The correspondence could be:
  • "Replying at" for replies (both to comments and sections)
  • "Editing at" for edits
  • "New topic at" for new topics
  • "New subsection at" for new subsections
• The another solution could be adding some shorter, more technical labels like a pencil emoji ✎✏️✐ (though it's too flashy) or other character, maybe in square brackets. We could prepend "*" to the title like they add "*" in text editors to denote unsaved changes, but "*" is currently also used for new, not yet shown comments that may be interesting to the user, like "(1*)".

In T261391#6420710, @Ammarpad wrote:

Hi Jack, I did clarify that. I mean it's not clickable in isolation (separate from the link text). You can only click the link+icon as a whole.

I just don't think I know where the icon can be met in isolation if using the standard wiki markup. Isn't it always accompanying the link? I guess I should have said "makes it seem like the icon is not a part of the link".

@Ammarpad Thanks for a good counterexample. Now I don't have an opinion on this.

Note also that, as seen on the screenshot in the task description

Right, thanks for the correction.

When built, the code is actually as insecure as having an SSH key at github because it runs any code as given by github's master under user's credentials.

Exactly. So no matter via a SSH tunnel or via the repo content—we gave the code full freedom to send any requests it wants using "a general solution to avoiding IP range blocks on the wikis" that is Toolforge 😉 the second when we allowed any connection between GitHub and Toolforge. The method using a SSH tunnel is even less risky as it only allows to make requests, but not run arbitrary code, if I'm getting it right.

@bd808 Thanks for the demonstration, but if having to choose between:

• building and testing at Toolforge and
• say, setting up GitHub Actions to upload the content that needs to be posted to wiki to some place X (perhaps some third-party server or the artifacts feature in GitHub Actions if it's possible to reveal the artifacts to the outside world) and send a webhook that Toolforge will accept, pick up the content at the place X and then post it to wiki,

given my current knowledge, I would choose the latter. This is perhaps an extreme example, but if you say that even GitHub can't be trusted with the SSH credentials, then we shouldn't even try to connect to Toolforge from GitHub Actions except via webhook (even though I didn't see where Cloud Services or Toolforge terms of use forbid transferring credentials to entities like GitHub).

Some GitHub Action that would create a release on some trigger and initiate a webhook accepted by Toolforge maybe?

Actually, creating a release with archived build files will clutter the repo the same way, or even worse, as creating a folder with them will. Releases containing files don't make sense for my tool, since the build files are tied to the specific (Wikimedia in our case) environment, and there is no incentive for potential users to download them if they need another environment.

You haven't described a full use case, but one that I can imagine is a gadget maintained in a GitHub repo and a GitHub Action based deployment system for that gadget that updates one or more target wikis when new commits are merged to a specific branch or maybe when a tag is made.

Right, my use case is the Convenient-Discussions tool, and this is basically what happens when you try to deploy to Commons (an error is reported in the "Run npm run deploy --dev" section).

using GitHub Actions to edit pages on Wikimedia project wikis correct

Right, this is the idea. I could have messed up with the terminology here, so feel free to correct it; @Yurik initially came up with the idea of using SSH for the API requests (made via HTTP, you're right), so maybe he could elaborate more.

Not sure if it's feasible in my case.

Note that this task is a duplicate of T207448: Resetting a custom global preference via API does not work.

I've come across this with Convenient-Discussions trying to delete a property created for testing purposes, and I couldn't. I was lucky not to mess with the users' options (only faced this behavior while in the development stage)—they would have an undeletable junk option. A particularly unfortunate feature of this is that global preferences override local ones, so if there is a userjs- option with the same name locally, it has no effect.

I've come across this with Convenient-Discussions trying to delete a property created for testing purposes, and I couldn't. I was lucky not to mess with the users' options (only faced this behavior while in the development stage)—they would have an undeletable junk option. A particularly unfortunate feature of this is that global preferences override local ones, so if there is a userjs- option with the same name locally, it would have no effect.

One could think that this is not CD's concern, but why not? A probable solution would be adding a standard CD timestamp_username identifier to the section link, say, after _, and have the script search for the section that includes the comment matching that ID, and jumping to that section.

Currently, together with T256988: Allow to insert a template not only into a form with 'wpTextbox1' id (that task is about TemplateWizard), these are the two only buttons that can not be added and work properly in WikiEditor, attached to an arbitrary textarea. So please fix, Convenient-Discussions needs it so much.

I join. There is also an inconsistency in the fact that the button is added to any textarea that fires an wikiEditor.toolbarReady event:

I had added some more messages that look like this in English source: "reply to $1", but in translations those messages would need to use {{gender:$2}}. So, either I should ask you to add more exceptions to this commit, or I should use some kind of a placeholder ("reply to {{gender:$2|}} $1"), and then remove two spaces produced by this code for English in the code of my script. What do you think is better? Currently I've added such placeholders, so if we stick to that, the commit is no longer needed.

Also, what happens when a message with some key is removed from the source language file? Is it removed from the site also? What about its translations?

that can be circumvented by adding the language code to a validation blacklist that we have

Thanks.

Thanks! Two questions:

1. At https://translatewiki.net/w/i.php?title=Special:Translate&group=convenient-discussions&language=ru&filter=%21translated&action=translate, I see 4 "outdated" messages and 1 "untranslated" while they in fact are OK. What should I do with them?
   1. For the "outdated" messages, the following notice is shown: "Following parameter is unknown: $2". In fact, the $2 parameter is not used in the English translation because it's not needed there. But I will include it in the message documentation.
   2. The 1 "untranslated" message (containing the word to) is in fact translated, it's just an empty string.
2. Can I and/or other users edit the English source on the site? English is not my native language, so it's quite possible that the translation would benefit from other users' improvements too.

I guess everything is ready on my part. Is there anything else needed?

@abi_

1. No, sorry, just an artifact of a sloppy conversion from JS to JSON. Fixed.
2. Thanks, fixed.

So, as for messages, you can see the example here: https://github.com/jwbth/convenient-discussions/blob/master/i18n/en.json. Messages can have everything that the MediaWiki messages API allows ({{int:}}, {{gender:}}, {{plural:}}).

@abi_ Sorry, I had no time to update the repository properly. The path for translations has moved from src/js/i18n/%CODE%.json to i18n/%CODE%.json (there is the old path in the patch).

See the updated code (and the comments Iniquity added) at https://www.mediawiki.org/wiki/User:Jack_who_built_the_house/Convenient_Discussions#FAQ.

Done. Add the following code to your personal CSS and change the color values:

The script has been fundamentally reworked, so the issue is probably not relevant anymore. Recreate if it still persists.

The script has been fundamentally reworked, so the issue is probably not relevant anymore. Anyway, it's on a closed page, so too many steps will have to be made to check if it still persists :-)

Hm, that shouldn't be hard. In the beta version, this should do the trick:

mw.hook('convenientDiscussions.newCommentsMarked').add(() => {
  convenientDiscussions.sections
    .filter((section) => section.comments[0] && section.comments[0].newness)
    .forEach((section) => {
      convenientDiscussions.g.$root
        .find(`a[href="#${section.anchor}"]`)
        .css('font-weight', 'bold');
    });
});

This code bolds all section links in TOC that have the first comment marked as new.

Hello, as I read, this change targets "nested" subst's. Does this code fall into that? It changes User talk:Jack who built the house link to User talk:Jack who built the house#top if I post on my talk page.

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.