It'd be amazing to have some URL equivalent to "&action=edit§ion=new" so that the interface could be called via a link like this
Talk:Talk pages project/New discussion
Jump to navigation
Jump to search
That might be possible in the coming weeks (probably with an additional &dtenable=1 code in the URL).
In the coming weeks, the New Discussion Tool will become available as a Beta Feature at the Arabic, Czech and Hungarian Wikipedias.
As the work finishes to make this happen, we are thinking about preloaded text and how the New Discussion Tool can support pages that use this functionality. As part of this thinking, we have two questions for you all:
Questions
1) As someone who would like for people to be able to use the New Discussion Tool on a page that uses preloaded text, what do you think about the "Approach for enabling preloads" (below)? What problems could you foresee arising from this approach?
2) On what page(s) at your local wiki do you think "Question #1" should be shared? Reason: we'd like as many people as possible who look after talk pages that use preloads to share what they think about this approach.
Approach for enabling preloads
- Copy and paste the page's existing preload text onto a new page
- Modify the existing preload text to ensure it meets the requirements (listed below)
- That's it. People who have the New Discussion Tool enabled would now be able to use it on this page. People who have not enabled the New Discussion Tool will see now changes to their experience for adding a new discussion topic.
Preloaded text requirements
- Instructions are included within the
editintroparameter instead of wikitext comments (<!--...-->) - If you have a signature (
~~~~) in the preloaded text, ensure it's at the end so that the tool doesn't insert another one - Avoid
{{subst:…}}syntax - Remove redundant instructions, like advising people to sign the new topic they create since the New Discussion Tool will do this automatically
Hi, Peter, I’ve never made a preload nor seen that manual page before now, so I’m looking at this from the n00b angle! Is the idea that you would change a button/link from ?action=edit§ion=new&preload=Old_preload_with_comments to ?action=edit§ion=new&preload=New_preload_without_comments&editintro=New_instructions?
The difficulty I see is that the edit instructions aren’t very noticeable with DT disabled. At least on w:en where I tested, they sit above the copyright warning.
hey @Pelagic – we appreciate you thinking about this. A comment and a question in response to the feedback you shared...
Is the idea that you would change a button/link from ?action=edit§ion=new&preload=Old_preload_with_comments to ?action=edit§ion=new&preload=New_preload_without_comments&editintro=New_instructions?
I'm going to ping @Matma Rex who I think can answer this question best.
The difficulty I see is that the edit instructions aren’t very noticeable with DT disabled. At least on w:en where I tested, they sit above the copyright warning.
Would it be accurate for me to understand the "edit instructions" you mentioned above as referring to how the <!-- Some instructions in a comment. --> appears on this page in edit mode?
If so, I agree with you in assuming this would be difficult for someone who was not explicitly looking for this to notice.
Although, in this particular context, we are talking about the edit notice(s) that can appear:
- In the visual editor, within the toolbar's "⚠️" button. See: Help:VisualEditor/User guide#Getting started: the visual editor's toolbar.
- In the source editor, above the copyright notice (as you noted above).
Does the above help clarify what we mean by "edit instructions" in this context?
Yes.
Sorry for the delay in returning here. Yes, we’re talking about the same thing. The editnotice/editintro is fairly obvious in VE and NWE, but less so in the classic editor.
In source mode, <!-- instructions in a comment --> are the most noticeable, but in VE they are truncated.
If updating the preloads to the new format means they will work less well in classic editor, then users may not want to change.
Yes, it seems problematic on huwiki as well (“production” form, linked from the welcome template), although at least the copyright warning is below the edit box, not above it. Adding class="mw-message-box" to the container of the edit intro area could help, at the cost of potentially breaking (making look ugly) some edit intros. By the way, this particular preload may work out of the box (although I raised some concerns about the preloaded title in phab:T270797#6783966 that haven’t been answered yet). On the other hand, the user rename form is never going to work with these constraints.
This question is probably best asked on the technical village pump of the Hungarian Wikipedia, people caring about preloads are probably most likely to be found there.
These examples and links are helpful – thank you for sharing them here, @Tacsipacsi. Some resulting questions for you below.
...it seems problematic on huwiki as well (“production” form, linked from the welcome template), although at least the copyright warning is below the edit box, not above it.
Can you share in more detail how the approach could conflict with this form? At first glance, I didn't see anything in this example from hu.wiki that seemed problematic. Although, I suspect you are noticing something I'm not...
(although I raised some concerns about the preloaded title in phab:T270797#6783966 that haven’t been answered yet
Shoot. I'm sorry the question you raised has gone unanswered for this long. Would it be accurate for me to understand the question you are raised in T270797#6783966 as: "Would it be possible for the preloads to automatically populate the "Subject" / "Title" field immediately when the tool opens?
On the other hand, the user rename form is never going to work with these constraints.
Is this because of the "Avoid {{subst:…}} syntax" requirement?
...it seems problematic on huwiki as well (“production” form, linked from the welcome template), although at least the copyright warning is below the edit box, not above it.
Can you share in more detail how the approach could conflict with this form? At first glance, I didn't see anything in this example from hu.wiki that seemed problematic. Although, I suspect you are noticing something I'm not...
As Pelagic also noted, the edit notice is—in our opinion—hard to notice using the full-page editing interface, it doesn’t stand out properly.
(although I raised some concerns about the preloaded title in phab:T270797#6783966 that haven’t been answered yet
Shoot. I'm sorry the question you raised has gone unanswered for this long. Would it be accurate for me to understand the question you are raised in T270797#6783966 as: "Would it be possible for the preloads to automatically populate the "Subject" / "Title" field immediately when the tool opens?
Not exactly. I expect that subject preloading will work, my question is whether the complex wiki syntax (~~~) will be supported.
On the other hand, the user rename form is never going to work with these constraints.
Is this because of the "Avoid
{{subst:…}}syntax" requirement?
Yes.
@Tacsipacsi: this additional context is helpful. Comments in response below...
As Pelagic also noted, the edit notice is—in our opinion—hard to notice using the full-page editing interface, it doesn’t stand out properly.
Ah, okay. Understood. A key consideration we will have in mind when implementing edit notices within the New Discussion Tool is making sure people notice them. This idea is captured in the "Requirements" section of T269033's task description. If you think this can be articulated more clearly, please comment as much on that ticket.
...my question is whether the complex wiki syntax (~~~) will be supported.
Yes, the New Discussion Tool's Title field should already support ~~~ and other wikitext. See: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User_talk%3APpelberg-test&type=revision&diff=482568&oldid=479512.
@PPelberg (WMF) I only just saw this, but glad to hear it's in the works. For en.wikiversity, this'll be super helpful e.g.:
- This link uses a preload talk template to format up comments such as those on this list. It uses
subst:but I think that's to omit the commented out text.
I agree with the recommendation to use the editintro parameter for instructions - it'd be much more robust and readable for new users anyway.
Ideally, the preloaded template would be opened into editing mode immediately upon pageload (i.e. without having to click the template and select edit).
The logical places to post Q1 there would be Wikiversity:Colloquium (and probably link to that discussion from Talk:WikiJournal_User_Group).
Additional query: Would the preload functionality be at all possible in the standard reply link? This could be super useful for formatting up certain kinds of structured discussions (example using review and response templates).
I'm just trying this out for the first time on enwiki. The edit box is preloaded with "Description". That's a little confusing, since "description" makes me think of edit summaries. Maybe change that to "Type you message here"?
Type your message here kind of implies the user should type their reply in it though.
Since many people don't seem to notice the add topic tab I wonder if it is somehow possible to insert a link that opens the interface for a new topic from anywhere.
Adding new topic works quite well on already existing talk pages, but it should also work on red talk pages. Most of the Wikipedia articles have got red/nonexistent talk page, but the new topic button does open the old wikitext editor even with this new beta feature turned on.
It is planned, but it is not straightforward how it should work. See phab:T270323 for the design task. (By the way, the interesting thing is that “most of the Wikipedia articles have got red/nonexistent talk page” isn’t true in all languages, for example 97% of talk pages exist on enwiki.)
It's taken me to notice until now but use of discussion tools loses me access to the CharInert gadget on en:wp so I have to remember all markup that I wish to use rather than having one-click access to useful markup functions. Nthep (talk) 17:17, 14 March 2021 (UTC)
Thanks for this note, Nthep. Which items in CharInsert do you use the most? I use the items for Extension:Translate (and it might be a good thing: I was typing one by hand the other day, and a tag that should have said <translate> came out of my fingers as <strangle>, which kind of sums up my feelings about it). I don't use much else. What's most useful to you?
Special characters like endash, emadash, greater equal to etc then markup phrases like nowiki, code, sup, sub, strikethorugh, non-breaking space. Occasional use of accented letters. Nthep (talk) 21:29, 22 March 2021 (UTC)
Nthep, character formatting such as sup, sub, and strikethrough are available now in the visual mode, and should be available soon in the wikitext source mode. How often do you use non-breaking spaces on a talk page?
@Neitram, I believe you had a similar problem.
only when demonstrating their use
Partial progress: There is now a toolbar in the wikitext 'source' mode. It still doesn't include the special characters. If you want to try out the toolbar for the wikitext source mode, go to the end of Special:Preferences#mw-prefsection-editing on your home wiki and tick the box for "Enable experimental tools in the quick replying and quick topic adding features' source modes"
Now, that's something you don't do when you write a new section by yourself but that might happen if you're using templates. Even if autosigning templates (currently) don't work, this issue should be fixed:
If the title field is left blank but an edit summary was entered, the edit summary is taken as the title and the standard summary /* $1 */ New section is used.
This is caused by the very old idea of just moving the edit summary texbox above the edit textbox when a new section is added instead of using a seperate title textbox. The API works accordingly.
My suggested solution is (sorry that this requires a breaking API change but I think not many bots actually use this API feature) that the edit summary will not automatically be used as the title. Instead, if just a title and not an edit summary is given, the summary will be autofilled. If an edit summary is unwanted (whyever), an empty edit summary parameter can be added to the api request
You can add edit summaries by clicking the 'advanced' dropdown below the editor
In the German Wikipedia, we use templates that include a signature, like de:template:Hallo. It's best to use it by opening the full page edit form and put {{subst:Hallo}} at the end of the page because that allows you to write an edit summary. Or you use it by just putting it in a new section (without a title) and saving without an edit summary. The template automaticly adds the title and the signature.
The New Discussion feature allows to set a custom edit summary without needing to edit the whole page. You don't need to enter a title but since you did not write ~~~~ at the end of the page, the tool double-singes the message.
It would be nice if you find a way to solve this without changing the workflow of users using the old way of editing talk pages.
That might be difficult.
Are you using the wikitext "source" mode in the New Discussion tool?
Yes I am
Perhaps the German Wikipedia is better, but at the English Wikipedia, there are about 500 welcome templates, and you have to memorize which template includes the signature, and which one does not. Although it would involve changing the workflow of users using the old way of editing talk pages, I think that standardizing the templates might be the best solution.
In the meantime, if you click "Add topic" on the user's talk page, you get the New discussion tool, and if you click "Add topic" on its "View history" page, it will give you the old way of editing. That might help you while they work on a real solution.
I think that when you click the give feedback link at the end of the new section form, you should get to this page and not to Talk:Talk pages project/Replying.
Me too.