@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. 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 topic.
• The solution that I see is to prepend labels like "Replying to" to the title (not including the number of new, not yet seen comments that is added in CD). 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.

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.

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.