User Details
- User Since
- Apr 5 2016, 6:06 PM (255 w, 4 d)
- Availability
- Available
- LDAP User
- Jack who built the house
- MediaWiki User
- Jack who built the house [ Global Accounts ]
Fri, Feb 26
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. The Talk quote block template, on the other hand, doesn't contain the "cite" element.
Wed, Feb 10
@Taufik Thanks for the question! It's a noun, the summary of the edit. I'll update the message documentation.
Jan 10 2021
Nah, that task is about Convenient-Discussions.
Dec 10 2020
Oct 26 2020
Oct 11 2020
Somehow this is fixed, so hurray.
Sep 25 2020
@Iniquity This should be fixed, please recheck.
Sep 9 2020
Sep 8 2020
Sep 5 2020
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:
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*)".
Sep 4 2020
Aug 29 2020
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
…the color of the original icon doesn't change when the link is visited and is purple. So, ideally, either the icon should change its color with the link it is attached to, or it should be black. I would perhaps prefer the former, as a black icon creates unwarranted visual noise. And, yes, makes it seem like the icon is not clickable.Aug 20 2020
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).
Aug 19 2020
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.
Aug 18 2020
Not sure if it's feasible in my case.
Aug 13 2020
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.
Jul 28 2020
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.
Jul 15 2020
Jul 5 2020
Jul 2 2020
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:
Jun 28 2020
May 31 2020
May 30 2020
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.
May 26 2020
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:
- 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?
- 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.
- The 1 "untranslated" message (containing the word to) is in fact translated, it's just an empty string.
- 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.
May 24 2020
I guess everything is ready on my part. Is there anything else needed?
May 20 2020
May 19 2020
- No, sorry, just an artifact of a sloppy conversion from JS to JSON. Fixed.
- 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).
May 6 2020
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:
May 5 2020
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.
Apr 3 2020
Mar 12 2020
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.
Jan 25 2020
scratch codes or the QR code
Right, this is even worse than intercepting the code.
Jan 24 2020
Jan 5 2020
Can anyone from the ruwiki community confirm?
I confirm: a newly registered account didn't get Reference Previews.
Dec 17 2019
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.
Dec 16 2019
Nov 24 2019
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.
Sep 4 2019
Aug 8 2019
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
Jan 28 2019
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.
Jan 27 2019
Jan 26 2019
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.
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.
Jan 21 2019
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?
Jan 7 2019
Thanks.