Talk:Talk pages project/New discussion

About this board

Providing guidance to avoid talk forks

3
Sdkb (talkcontribs)

One mistake that I frequently see newcomers making is starting the same discussion in multiple places, which goes against w:WP:TALKFORK. This creates a lot of messiness: it uses up editor time because folks type out comments others have already given elsewhere, makes it harder to keep track of things, requires work to reconcile differing outcomes, can be seen as inappropriate canvassing/forum shopping, etc.

It occurs to me that the new discussion tool might be able to help address this issue by identifying possible discussion forks as they happen. The trigger for this would be if a non-extended confirmed editor starts writing a new topic that has the same header as a topic they recently (say, within 31 hours) started at a different page. (A more advanced version could parse the content as well, looking for, say, > 90% similarity.) When that condition is met, it would trigger an editnotice that would say something like Please do not start the same discussion in multiple places. To draw attention to a centralized discussion, use the Please see template to leave an invitation.

Would it be possible to develop this feature, @ESanders (WMF)/@PPelberg (WMF)? (This might also be considered a possible implementation of Edit check.)

ESanders (WMF) (talkcontribs)

Our new comment metadata database would certainly make such a feature possible: being able to generally querying all discussion topics on a wiki. I'm not sure if the team would be able to prioritise such a feature at the moment, but filing a task would be a good place to start.

Sdkb (talkcontribs)
Reply to "Providing guidance to avoid talk forks"

How do I remove an automatic signature?

9
2A02:C7C:BD2C:B500:6537:3289:B52D:DCB9 (talkcontribs)

Title says it all.

2A02:C7C:BD2C:B500:6537:3289:B52D:DCB9 (talkcontribs)

Forgot to tell you, but this is related to the DiscussionTools extension.

103.85.158.138 (talkcontribs)

In a few rare cases set out by local project rules it might be necessary to not add a signature. How can one turn off the automatic signature?

This post was hidden by Tacsipacsi (history)
This post was hidden by Tacsipacsi (history)
This post was hidden by Tacsipacsi (history)
TheDJ (talkcontribs)

You just edit the page like you used to, instead of using DiscussionTools.

Leptictidium (talkcontribs)

No longer, apparently.

Whatamidoing (WMF) (talkcontribs)
Reply to "How do I remove an automatic signature?"

How to avoid an automatic signature

8
188.22.145.177 (talkcontribs)

In a few rare cases set out by local project rules it might be necessary to not add a signature. How can one turn off the automatic signature?

Whatamidoing (WMF) (talkcontribs)

Use the [edit] or [edit source] button.

Caeciliusinhorto (talkcontribs)

This option doesn't seem to be available for me in a mobile browser when creating a new talkpage. Am I missing something?

Tacsipacsi (talkcontribs)
103.85.158.138 (talkcontribs)

This option doesn't seem to be available for me in a mobile browser when creating a new talkpage. Am I missing something?

Tacsipacsi (talkcontribs)

Indeed. I reported this at phab:T334727. As I mentioned in the task, a workaround for the time being is removing action=edit&redlink=1 from the URL.

This post was hidden by Tacsipacsi (history)
Tacsipacsi (talkcontribs)

I forgot to report back here: the task has been resolved, now the pencil icon should be visible after clicking a red talk page link.

Reply to "How to avoid an automatic signature"

Shift key sends cursor to beginning of that line.

1
AxG (talkcontribs)

Basically what the titles says, I've tried it in both source and visual, but pressing the shift key sends the cursor to the beginning of that line.


Edit: I don't know if it might be because of the GoogleTrans gadget, after reading https://phabricator.wikimedia.org/T156228 Just a thought?

Edit2: Yep, turned it off and it's fine.

Reply to "Shift key sends cursor to beginning of that line."

Please fix the vague instructions

2
Filelakeshoe (talkcontribs)

Trying to turn this useless feature off just took me far too long - and I'm sorry, but it is useless. Aside from the markup / special characters toolbox being gone, restricting the input box to rich text with like 4 formatting buttons means I can't add things like noinclude and nowiki tags which are commonly used by experienced editors on talk pages.

At the top of the new topic box, I see a link telling me I can switch back to "the legacy experience". Hallelujah, normal service is temporarily restored. At the top of this screen I see an invitation to "visit preferences to set the legacy experience as your default". I followed the link and saw no reference to the "legacy experience" anywhere. Eventually I guessed that the relevant option was "quick topic adding". Why not just tell us that, rather than using vague marketingspeak in one text and the actual name of the feature in the other?

Whatamidoing (WMF) (talkcontribs)

I'm glad that you were able to find the right item in preferences.

@PPelberg (WMF) will probably be interested in your idea about changing the wording on that message. It will take some time to get translations through, though, so even if the Editing team implemented the change today, it would likely be weeks or even a couple of months before it would be seen in practice.

The New Discussion tool is not limited to rich text. You can switch to the source mode.

The special characters tool is in the toolbar. Look for the ฮฉ icon. It's the same special characters palette that is used in the visual editor, which (depending on the wiki) is usually either the same or slightly bigger than the one in the 2010 wikitext editor's toolbar. If, on the other hand, you are looking for Extension:CharInsert (underneath the old wiktext editing window; it contains a limited number of special characters, but is mostly used for wikitext markup codes like <code><nowiki>Insert text here</code></nowiki>), then that is not included in these tools.

I generally find that nowiki'ing works automatically in the visual mode, but noinclude tags would send me to source mode. Can you give an example of a time when you wanted to post a comment that included a functional noinclude tag? Visible ones (e.g., to tell someone else what to type) are rare, amounting to just 9K out of 15.5M talk pages at enwiki. Functional ones, e.g., for the GA process, aren't normally added as part of a comment.

Reply to "Please fix the vague instructions"

Licensing and attribution of Wikisource translations

2
Nihil novi (talkcontribs)

In 2018 a very substantial translation of mine, bearing my real name, was deleted from Wikisource, without my being contacted, because it bore a GFDL license rather than a CC BY-SA 3.0 or 4.0 license.

If 3.0 licenses are discontinued in favor of 4.0 + GFDL, will provision be made to automatically upgrade current 3.0 pages to 4.0 + GFDL, so that more pages are not deleted without the authors' knowledge; or at least to notify the authors of planned deletions?

Is there a way I could consult appropriate staff about any possibility of restoring my deleted page? When I contacted a Wikisource staffer, I was informed that its resuscitation would require substituting "Translated by Wikisource" in place of my real name. I'm willing to contribute Wikipedia texts anonymously, but I feel that translators should, if they wish to, be allowed to contribute translations to Wikisource under their real names, and I would be glad to present my arguments for that.

Could I please be contacted at my Wikipedia talk page, if there should be any responses to my questions?

Thank you.

Nihil novi (talk) 07:05, 23 February 2023 (UTC)

Matฤ›j Suchรกnek (talkcontribs)

I think you have accidently arrived at a wrong page to discuss that matter.

Reply to "Licensing and attribution of Wikisource translations"
187.150.54.97 (talkcontribs)

to edit all wiki ned ip singon devace

Whatamidoing (WMF) (talkcontribs)

Which wiki do you want to edit? ยฟQuรฉ wiki quieres editar?

Reply to "ip singon devace"

Insert toolbar no longer visible

7
Summary last edited by Tacsipacsi 17:06, 2 March 2023 2 months ago

T249072: Add support in toolbar for special characters within DiscussionTools

Nihonjoe (talkcontribs)

This new talk page topic editor no longer has the insert toolbar (with Latin, symbols, Greek, etc.) characters. Please put it back. -- ๆ—ฅๆœฌ็ฉฃ Nihonjoe (talk) 19:33, 2 September 2022 (UTC)

PPelberg (WMF) (talkcontribs)

hi @Nihonjoe โ€“ are you referring to the special characters toolbar pictured below? If so, then this is functionality we will be introducing soon. If you'd like, you can track our progress by following this Phabricator task: T249072.

A screenshot showing the special characters toolbar that appears within the visual editor on desktop devices.
Special characters toolbar
Nihonjoe (talkcontribs)

Thanks for the information. Okay then, how do I turn off the new editor and use the old one? I use that toolbar multiple times daily, and not having it makes things extremely difficult when I'm working on characters with macrons, umlauts, accents, and so on. -- ๆ—ฅๆœฌ็ฉฃ Nihonjoe (talk) 23:03, 2 September 2022 (UTC)

PPelberg (WMF) (talkcontribs)

I use that toolbar multiple times daily, and not having it makes things extremely difficult when I'm working on characters with macrons, umlauts, accents, and so on.

Understood!

Okay then, how do I turn off the new editor and use the old one?

  1. Visit: Special:Preferences#mw-prefsection-editing
  2. Disable the "Enable quick topic adding" setting
  3. โœ… That's it
Nihonjoe (talkcontribs)
86.115.107.96 (talkcontribs)

That ain't no good for anonymous user. And I mostly only need the line-break code, which does not occur by pressing Enter.

Tacsipacsi (talkcontribs)

The good news is that the special character tool has become available in the reply and new topic tools in the meantime (unless you disable the toolbar, but doing so also requires logging in). Although I donโ€™t know what line-break youโ€™re speaking about, I donโ€™t find a such thing in the special character toolbar of either the new topic tool or the edit toolbar of the legacy full-page editor (WikiEditor). (By the way, pressing Enter once indeed doesnโ€™t create a line break indeed, as it has always been in wiki code. You need to press Enter twice to create a paragraph in unindented mode (new topic tool), one Enter works only in indented mode (reply tool).)

Reply to "Insert toolbar no longer visible"

Ways to make "starting new discussions" easier

6
Summary by PPelberg (WMF)

You can see how this research is being applied to this project by reading this task: task T249784

PPelberg (WMF) (talkcontribs)

What pages/wikis are you aware of that have implemented a unique way of starting a new discussion?

We have listed some examples of we are aware of below.

Additional context

Knowing what alternative solutions individuals and wikis have already implemented to make it easier for people to start new discussions will help us:

A) More deeply understand the issues people see with the existing start a new discussion experience and

B) Identify solutions we ought to consider incorporating into the new experience we are starting to design.

PPelberg (WMF) (talkcontribs)

The "unique ways of starting a new discussion" we are currently aware of:

  1. On the French Wikipedia's wikitext talk pages, there is an Ajouter un sujet link at the bottom of each talk page.
  2. On English Wikipedia's Teahouse, there is a large Ask a question button at the top of the page.
  3. The English WIkipedia's {{Talk header}} template includes a link that states: Click here to start a new topic.
  4. Some editors, such as this one at cswiki, have put buttons at the top of their user talk pages.
  5. On the French Wikipedia's "Request to administrators" page, they have a button at the top of the talk page that reads Make a new request.
Whatamidoing (WMF) (talkcontribs)

There's also the [Edit source | Add section] gadget (e.g., at dewiki and Meta-Wiki).

Pelagic (talkcontribs)

Also the full-width blue button โ€œAdd discussionโ€ in Minerva. And the small blue โ€œ+โ€ button at top-right of user talk pages in iOS Wikipedia app. (Yes, I know the scope of this project is desktop Vector, but we can still take inspiration from elsewhere, no?)

Pelagic (talkcontribs)

Oh, I see that phab:249784 is closed, should we close this thread also?

phab:T247485 only tested pages with the gold template, but not any of the ones with big buttons, so it didn't come close to the range of 249784.

Looking at the dates, those two ran in parallel. Is there a plan to do a third round of user testing on some more page types described in 249784?

Pelagic (talkcontribs)

French talk pages have a small link ยซAjouter en sujetยป, that allows you to add section from the bottom of the page without scrolling back to top.

Reply to "Ways to make "starting new discussions" easier"
Summary by Matma Rex

We've implemented the feature with an opt-in in T269310. There is documentation available at Special:MyLanguage/Help:DiscussionTools#Experimental: Preloading message content.

PPelberg (WMF) (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

Approach for enabling preloads

  1. Copy and paste the page's existing preload text onto a new page
  2. Modify the existing preload text to ensure it meets the requirements (listed below)
  3. 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 editintro parameter 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
Pelagic (talkcontribs)

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&section=new&preload=Old_preload_with_comments to ?action=edit&section=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.

PPelberg (WMF) (talkcontribs)

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&section=new&preload=Old_preload_with_comments to ?action=edit&section=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:

Does the above help clarify what we mean by "edit instructions" in this context?

Matma Rex (talkcontribs)

Yes.

Pelagic (talkcontribs)

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.

Tacsipacsi (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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?

Tacsipacsi (talkcontribs)

...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.

PPelberg (WMF) (talkcontribs)

@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.

Evolution and evolvability (talkcontribs)

@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).

Evolution and evolvability (talkcontribs)

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).

Whatamidoing (WMF) (talkcontribs)

I don't think that's been considered before. phab:T285358 is the bug number; feel free to edit it to add more information.

Matma Rex (talkcontribs)