Talk:Structured Discussions

Jump to navigation Jump to search

About this board

Structured discussions (Flow) is used on this page (documentation).

You can leave your message in any language, but answers will be made in English (or your language if we speak it).

Works in One NS, Fails in Another NS

Summary by Johnywhy

The are different fixes, depending on the source of the problem:

Wrong Custom-Namespace Declaration Order

The Flow declares must go after the declare for a custom namespace. Correct order is:

define("NS_PORTAL_TALK", 3005); 
$wgExtraNamespaces[NS_PORTAL_TALK] = "Portal_Talk"; 
$wgNamespaceContentModels[NS_PORTAL_TALK] = 'flow-board';

Wrong Native Constants

Pages in the Main namespace are simply NS_TALK, not NS_MAIN_TALK. The correct declare is:

$wgNamespaceContentModels[NS_TALK] = 'flow-board';	

Non-Registered Extension Constants

Extension:Page_Forms namespace constant is supposed to be PF_NS_FORM_TALK. But that constant does not work in the Flow declare-- you must use the actual number: 107. This works:

$wgNamespaceContentModels[107] = 'flow-board';	

It's unknown to me whether Page_Forms failed to register its constants correctly, or whether all extension must use numbers (not constants) with Flow.

Old Remnants

If you're correctly getting Flow in a namespace, except for one page in that namespace, there may be remnant junk in the talk page (even if it appears empty). Do the following:

  1. Browse to the talk page that won't load Flow, eg: Portal_Talk:Welcome
  2. Delete the Talk page using the Delete tab.
  3. Go to the content page for that talk page, eg: Portal:Welcome
  4. Click Discuss.
  5. You get Flow.
Johnywhy (talkcontribs)

I'm getting Flow in one namespace, but seeing old built-in editor in another namespace. But BOTH are set to use Flow:

wfLoadExtension( 'Flow' );
wfLoadExtension( 'Echo' );
$wgNamespaceContentModels[NS_DRAFT_TALK] = 'flow-board';		# WORKS FOR THIS NS
$wgNamespaceContentModels[NS_PORTAL_TALK] = 'flow-board';	# FAILS FOR THIS NS

What's my mistake?

Jdforrester (WMF) (talkcontribs)

How are NS_DRAFT_TALK and NS_PORTAL_TALK defined, and where? Are they defined at the same point, and is it before this code is executed?

Johnywhy (talkcontribs)

i updated the manual page here: Extension:StructuredDiscussions#Installing

"Important: You must put the Flow declaration after any namespace protections (even if they don't include TALK). Otherwise, flow may fail for some namespaces."

Feel free to revise as needed.

Johnywhy (talkcontribs)


The fix was moving these ns protections before the Flow declaration (even though _TALK does not appear here):

$wgNamespaceProtection[NS_PORTAL] =
$wgNamespaceProtection[NS_PROJECT] =
$wgNamespaceProtection[NS_HELP] =
$wgNamespaceProtection[NS_CATEGORY] =
$wgNamespaceProtection[NS_FORM] = array( 'editprotected' );

$egApprovedRevsNamespaces[] = NS_DRAFT;

Here are the namespace declarations in LocalSettings.php. This was already before the Flow declarations, so no change needed with that:

define("NS_DRAFT", 3000); // This MUST be even.
$wgExtraNamespaces[NS_DRAFT] = "Draft";
define("NS_DRAFT_TALK", 3001); // This MUST be the following odd integer.
$wgExtraNamespaces[NS_DRAFT_TALK] = "Draft_Talk"; // Note underscores in the namespace name.

define("NS_PORTAL", 3004); // This MUST be even.
$wgExtraNamespaces[NS_PORTAL] = "Portal";
define("NS_PORTAL_TALK", 3005); // This MUST be the following odd integer.
$wgExtraNamespaces[NS_PORTAL_TALK] = "Portal_Talk"; // Note underscores in the namespace name.
Johnywhy (talkcontribs)

plz see my new edits to the manual page. Tried to give it some better organization-- -not sure it's clear.

i think the phrase "put the flow declaration at the bottom of localsettings.php" is very UNhelpful, since MANY extensions say the same thing!

It's more useful to explain exactly which declares must come before the Flow declare.

Johnywhy (talkcontribs)

Oops. Not solved. I was mistaken.

I'm getting Flow on all expected pages EXCEPT HOMEPAGE.

The homepage is a redirect from Main_Page, and it's namespace is Portal, not Main.

It's called Portal:Welcome

All other talk pages in Portal namespace are getting Flow, but not Portal_Talk:Welcome.

I don't see any specific mention of Main_Page in localsettings.php.

I removed all protections on Portal in localsettings.php, and set protections on Welcome "Protect" tab to "All Users".

Didn't help.

Also, still working on some NS's, not others. Eg., works on Draft, but not on Form.

My current declarations:

define("NS_PORTAL", 3004);
$wgExtraNamespaces[NS_PORTAL] = "Portal";
define("NS_PORTAL_TALK", 3005);
$wgExtraNamespaces[NS_PORTAL_TALK] = "Portal_Talk"; 

define("NS_DRAFT", 3000); 
$wgExtraNamespaces[NS_DRAFT] = "Draft";
define("NS_DRAFT_TALK", 3001); 
$wgExtraNamespaces[NS_DRAFT_TALK] = "Draft_Talk"; 

$wgNamespaceProtection[NS_PORTAL] = 
$wgNamespaceProtection[NS_FORM] = array( 'editprotected' );

wfLoadExtension( 'Flow' );
wfLoadExtension( 'Echo' );
$wgNamespaceContentModels[NS_PORTAL_TALK] = 'flow-board';
$wgNamespaceContentModels[NS_DRAFT_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_FORM_TALK] = 'flow-board';		

Any ideas, @Jdforrester (WMF)?

Johnywhy (talkcontribs)

Resolved, partially.

The Fix:

  1. Browse to the talk page that won't load Flow, Portal_Talk:Welcome
  2. Delete the Talk page using the Delete tab.
  3. Go to Portal:Welcome
  4. Click Discuss.
  5. You get Flow.

Apparently, even though the talk page appeared empty, something was remnant that was breaking Flow.

I re-validated my fix above, to put Flow declarations after protection, and it turns out that has no effect.

Still broke:

Now i'm getting Flow on all Talk pages EXCEPT Main and Form talk pages.

AM getting Flow on Category and Help talk pages.

I'm thinking this might be related to constants. My Flow declares are:

$wgNamespaceContentModels[NS_MAIN_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_FORM_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_HELP_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_CATEGORY_TALK] = 'flow-board';		

Maybe NS_HELP_TALK and NS_CATEGORY_TALK are defined in MW core, while NS_MAIN_TALK and NS_FORM_TALK are NOT defined in core.

Anyone know if that's the case?

Update, further fixed:

Yep. NS_MAIN_TALK is incorrect. It's just NS_TALK. Extension default namespaces#MediaWiki Core

Now the only namespace giving an issue is Page Forms' NS_FORM_TALK. The manual says Page Forms Talk NS is PF_NS_FORM_TALK. However that's not working. So instead of the constant, i tried the actual number: 107. That worked.

So far, it looks like i'm now getting Flow on all talk pages.

I'll mark this resolved after more testing.

paste with wikitext locks up the browser tab

Alsee (talkcontribs)

I suspect this latest breakage is caused by Phabricator T155861: Migrate Flow to use the integrated VE/WT editor widget when it exists.

Steps to reproduce:

  1. Go to United States or any of the other 500 articles listed here.
  2. Edit source.
  3. Copy all. (CTRL-A CTRL-C)
  4. Click reply or create a new Flow post in wikitext mode. (Visual mode seems to be equally affected, but I only tested it once.)
  5. Paste. (CTRL-V)
  6. The browser tab locks up completely. Wait. Wait. Wait. In one case I tried waiting over 15 minutes.
  7. Kill the browser tab to escape.

Expected results:

  • Functionality and performance which is not catastrophically inferior or broken compared to existing talk pages. That includes, but is not limited to:
    • On a Talk page the entire sequence from clicking-edit, loading the editor, pasting any article text, clicking preview, and receiving that preview, can ALL be completed in under ten seconds in my experience. Taking twice as long might be a tolerable downgrade, but generating browser time-out popup errors is obviously unacceptable breakage.
    • On a Talk page, pasting any wikitext and previewing provides a correct wikitext render (and of course a correct preview-render of the wikitext). Flow's wikitext support is unacceptably broken, but that's been broken from day Flow was built.

Tip: When the WMF finally gets around to admitting Flow is never going to be accepted, and potentially starts a new project from scratch to address Talk pages, the #1 requirement for design development and testing is to copy paste various articles into it and make sure you're not breaking anything. Any project to replace/improve talk pages is NEVER going to be accepted if the team isn't treating that as a #1 MVP requirement from the start. Talk pages are not chatboards. Talk pages are a wiki-workplace, and editors have this odd expectation that we can copy-paste anything from anywhere to anywhere as part of our work. Any project ignoring that fact is just going to be a black-hole waste of staff-time and donor-money. (talkcontribs)

This is likely worse in a firefox browser. On a chrome browser it loads in a few seconds, less 40. This might be due to performance optimizations that chrome has.

No matter how desperately people want to blame developers. The simple fact is that the textarea input box isn't a magic bullet either. Pasting content equivalent to the maximum bytes (2MB) that can be saved, will mean the browser will also take a few seconds to load it. This might not be an issue for a sufficiently powerful computer, but it certainly will be a massive issue on older and less performant platforms like mobile devices, tablets etc.

Bad performance is quite simply an inherent design flaw of web-based development. Bad editing performance on the web in general isn't going to change in near future, unless editors are redesigned to either use plugins like flash or use "native" web based applications that aren't based on the DOM model or someone comes up with a way to overcome those deficiencies.

Anyway, one way to deal with pastes in general is simply to defer it when it is massive. Instead of pasting the whole content, it could paste enough to fill 3 or 4 screens , and asynchronously load the rest as needed. (talkcontribs)

Indeed, apparently it is an issue that has affected browsers (for years ) using = the "plain" wikitext editor.

In fact, there are claims that at some point firefox only allowed 64K in a textarea:

Alsee (talkcontribs)

The WMF was informed that Flow had fatal design flaws even before the prototype was built. Three of the most important wikis now have explicit consensus to refuse delivery of the defective product, other major wikis would also surely refuse refuse it if the WMF attempted to move forward on it.

The NewWikitextEditor was effectively built in secret, and as soon as the prototype was made available the WMF was informed that it had fatal design flaws. The biggest wiki has an explicit consensus refuse delivery of the defective product, and other major wikis would surely also refuse delivery if the WMF tried to move forward with it.

I come here pointing out that that the latest move to combine the two mis-designed products causes them to burst into flames, and your response is:

  1. List fictional problems that aren't affecting anyone.
  2. Tell me that Bad performance is quite simply an inherent design flaw of web-based development, which is quite absurd when our pre-existing tools have excellent performance.

I am *this* close to just reverting the two IP posts instead of replying.

There isn't a programming problem. There's a design problem, a strategy problem, and an ignoring-end-user-feedback problem.

Jdforrester (WMF) (talkcontribs)
I am *this* close to just reverting the two IP posts instead of replying.

Please do not blank other people's discussions just because you disagree with them. Such behaviour will likely get you blocked from this (or any) wiki.

Alsee (talkcontribs)

JDF, don't worry. It wouldn't even cross my mind to delete other people's discussions just because I disagreed with them.

But since you're here, perhaps you could make a content-relevant reply? Either on:

  1. The immediate issue of paste into Flow locking up the browser tab apparently due to integration of the 2017Editor; or
  2. preferably on the broader issue of the WMF explicitly disregarding community feedback on Flow and major multi wiki rejection of Flow + the WMF effectively building 2017Editor in secret and disregarding community feedback on 2017Editor and community rejection + the WMF just rolling forwards on both projects and making them go from bad to "kill the browser" worse. I'd really love for us all to work together better new and better wikisoftware, but there seem to be ongoing problems of strategy-conflict with the community and an isolationist approach to design.
Jdforrester (WMF) (talkcontribs)

Sorry, I don't feel I can answer your question. It seems to be based on a set of facts with which I am not familiar.

This post was hidden by Clump (history)
Reply to "paste with wikitext locks up the browser tab"
George Ho (talkcontribs)

The Archiving setup is either bad or very burdensome. There is no Archiving; instead, I have to click "Browse topics" and look for older discussions, or I have to scroll down to the bottom of the page to see more older discussions.

I don't like switching between "Source editing" and "Visual editing" to preview my messages before posting. It's annoying, and I have to switch back and forth every time to see what I've written. There should be a "Show preview" button. If not, what are other ways to preview messages?

Trizek (WMF) (talkcontribs)

The archiving system is indeed perfectible. There are some ideas around that, like have a better search system and/or tag/status to handle discussions (T90471).

Concerning the switch, that's also perfectible (tracked on T183382). Have you tried to edit in visual mode? For most cases I've seen on many discussions, the visual mode is sufficient.

George Ho (talkcontribs)

Besides filtering by date, how would filtering the messages improve the archiving system? Even filtering is not the same as searching by a page or another, which makes searches more flexible.

I've done visual editing by using Structured Discussions. However, this is nothing compared to wikitext editing. Indeed, the visual editor mode of Structure Discussions doesn't provide underlining or strikethrough at the moment. Nevertheless, I see that VisualEditor in en.WP provides both underlining and strikethrough.

I see that copying and pasting an internal link from a MediaWiki can result from [[MediaWiki]]. Oh wait... VisualEditor doesn't provide <code><nowiki></nowiki><code> or any HTML coding, like < and >. Wait... source should provide proper HTML coding, shouldn't it?

By the way, I can indent by pressing the space bar several times (or hold it for less than a second).

Trizek (WMF) (talkcontribs)

You can have tagging that would handle discussions status: ongoing, archived, vote open...

Concerning editing, you can have quite all you describe when you use visual mode to edit, like on the visual editor. That's a new learning path to get, but if you are curious of it, you may like it. After years of wikitext editing, I've now I've switched for good to visual editing for all my contributions when it is possible, both as staff or as a volunteer editor.

All what I'll describe below is mostly based on shortcuts, because the toolbar is kept short (some users have asked for an extended one). You can access the list of all shortcuts by pressing CTRL+/ or CTRL+SHIFT+/ when you edit, or check the keyboard shortcuts page (CTRL is CMD if you have a Mac.). You will have access to underlining or strikethrough so as code.

To have access to nowiki, here is a trick:

  1. type "{", "SPACE", "{", which wil give you { {.
  2. clear the space between the brackets : {{
  3. Finish typing your example: {{template}}
  4. You can have it shown as code: {{template}}

You can also call the template interface by typing two curly brackets like in code and then discard the search window (Escape key). Brackets will be nowiki-fied.

Storage of Structured discussions aren't using wikitext yet. HTML shortcuts will not work: you can't add <bold> or something else in it.

You can't indent by pressing space: it will be shown as working on visual editing mode, but will not be kept when you'll post the reply. Instead, you can create a blockquote by typing : at the beginning of a paragraph.

Hope this helps! :)

George Ho (talkcontribs)

I still don't see a shortcut to write out <nowiki></nowiki>

Also, does anyone else know and/or have they been told about the Ctrl+/?

Automated signature time and date is already done, but to see when a comment was originally made, I have to see a history log. This isn't like (~~~~) or (~~~~~), which makes dates more visible and usually helpful.

The shortcuts from Ctrl+/ don't provide tabling a chart:

Example Example 2 Example 3

They also don't provide list formatting:

  • Example
  • Example 2
  • Example 3
  1. Example
    1. Example 2
  2. Example 3

Another question: why switching from wikitexting to visual editing? How is visual editing more preferable than wiki editing? By the way, Microsoft Office has always provided visual editing but not some sort of coding.

Trizek (WMF) (talkcontribs)

I'm not sure to understand your first point. I can type <nowiki>. Or I can create nowiki-fied contents by using the process I gave you.

I tell people about ctrl+/ time to time, and there is the documentation about that. This said, I totally agree on the fact that it lacks a item in the menu and, good news, it is ready to be added.

Concerning time, you can see the the time for the last edit by hovering the relative time. To know the history, you indeed need to check the history page.

Ctrl+/ provides the shortcut to insert a table (bottom right on the panel). Then you have all tools to work on that table (insert rows, delete columns...). I also see shortcuts to increase and decrease indentation on lists (center of the central column) but you're right concerning list options that are missing.

Most cases you've surfacing are not in the toolbar, because on most discussions, having more tools is not needed. That was the design preset, but based on the feedback received (including yours), it is likely to be reconsidered. The new question is to know when it will be done.

Concerning VE versus wikitext, I'm not sure to understand your question. You want to know why VE is default? OR you want to know why VE is the previewing system? I also don't understand your example with Office. Sorry. :/

George Ho (talkcontribs)

For the first point, I should have said a "keyboard shortcut" for <nowiki>.

The "Insert" column contains only the keyboard shortcut to insert a reference, like an external source. I don't see anything else under the column. I don't see the keyboard shortcut to add a table.

Regarding VE vs wikitext, I'll elaborate: "Why did you prefer VE over wikitext? How was wikitext to you?" I didn't think about a second question before, like "Why is VE default?", but I can ask that right away.

Sorry also for being less clear on the Microsoft Office example. I'll elaborate by using one example: At Microsoft Office, I visually format a word by either bolding (i.e. either the "B" button or Ctrl+B) and/or italicizing ("I" button or Ctrl+I) and/or underlining it ("U" button or Ctrl+U). At wiki's VE, same thing, but I have to publish the changes.

Trizek (WMF) (talkcontribs)

It is strange that you don't have more items on the help fly-out. Which browser and OS do you use? Would you share with me a screenshot of what you see? Tip: most wikitext "starting" elements are shortcuts, like [[ to insert a link, {{ for a template or {| for a table.

VE is default because it is a rich text editor. Most conversations, like the ones we have, don't require much wikitext: you just need to type a message and see if it is well formatted, right? Structured discussions are used on several wikis as a safe place for newcomers: while using visual mode, they can start and participate to discussions without being obliged to know the discussions conventions. People who want to have wikitext by default can do so on their preferences (preferences that should be more visible, I admit).

I'm still not sure to get that Office example. When I use VE to write messages and I bold or italic some elements (using buttons or shortcuts), I see the results immediately. I'm under visual input mode, maybe you aren't? There is two systems on Structured discussions: visual editing and the 2017 wikitext editor. Maybe you are using that wikitext editor, that uses VE design? If so, you have to preview by switching to VE. Is it the case?

George Ho (talkcontribs)

I realize Opera 52, Firefox 59, and Internet Explorer 11 at Windows 7 don't show as many shortcuts as Chrome 65.

Oh... I have to use wikitext to format an image gallery.

Well, phab:T184701 and phab:T183382 already address the third point we're discussing.

Trizek (WMF) (talkcontribs)

Thank you for the screenshots. I think we don't have the same editor in mind when we speak: your feedback is based on wikitext editor, mine is on VE. :)

Using Firefox and Chromium last versions on Ubuntu, I have all those shortcuts and they work when I use VE mode. However, they are absent in the wikitext editor because that editor don't have (yet?) a visual assistance to insert a table or add hieroglyphs. However, have more options to add things, like a pre-formatted syntax for tables, would be welcome. This is done with the extended toolbar you'll find in the 2017 editor (Beta feature on most wikis) and have it on Structured discussions is covered by T93243. (I've edited it to get more features)

Have you tried to type <gallery> in visual mode? It opens an assistant with a search bar and formatting options for captions.

Ad thank you for that conversion. I really appreciate it.

Reply to "My feedback on this software"

Suggestion: Add an ability to restore flow board to previous state (e.g. revision, metadata)

4 (talkcontribs)


It is not possible to reset the flow board to a previous state (revision, flow titles, flow summary, flow description), unlike wikitext based discussions.

Proposed solution

  • Add a way to restore the content and flags of the board or topics to a previous state.
  • In a similar manner to the true database rollback, reset the content / metadata of the database to a prior state.

Note: This is explicitly NOT about rollback. The misnamed mediawiki "rollback" feature only works if all actions are by the same user, and multiple users / vandals can make a flow topic unreadable. An equivalent action with talk pages is editing a previous revision and clicking save.

Trizek (WMF) (talkcontribs)

Every elements on Structured discussion is independant. It is like resetting multiple pages at once. That would require further investigation. (talkcontribs)

According to Flow/Architecture, as you state, this might indeed be complicated due to how stuff is stored. While in a perfect world a true "reset" would be best, perhaps there is a temporary alternative. There are plenty of actions that it can revert easily. For example, if 50 different people edit the title of this thread 50 times. It would be trivial to simply revert the title to what it was on a specific revision. Currently, undo doesn't even currently work for title changes, so one has to copy the old title and save it as new.

Maybe in the short term, it would be useful to add "undo" to title changes, and maybe a generic "unhide all posts" would be be reasonable, along with a separate limit to how many things a regular user can hide, maybe 3 "hide actions" every 2 minutes or so.

Long term, if a "restore" is implemented this should probably only apply to a specific thread (excluding the board description).

This post was hidden by Clump (history)

MediaWiki message for empty board description

Summary by Trizek (WMF) (talkcontribs)

Hi! Is there a possibility to add a MediaWiki message, like MediaWiki:Talkpageheader, on top of Structured Discussions board descriptions? It is incredibly useful to have this message to have a setup like French Wikipedia has. I hope this can be added in Structured Discussions.

Trizek (WMF) (talkcontribs)

Hi! The header has been moved to the board description, to give immediate access to the conversations. Adding a header would allow people to add a lot of informations, that may hide the discussions or block people to discover where they can start a discussion.

What would be the goal of that header?

From my experience on my volunteer account, I see that people leaving me messages respect the advice posted in the sidebar, maybe because I've tried to design the sidebar to catch readers' eyes. Apparently, it works. But that's just an example. (talkcontribs)

Well, if sysops on wiki would add a lot of information to such header, it would be on their behalf. For now there isn't a simple possibility to add anything to Flow header in multiple discussions, you have to add Flow descriptions to every page and they are not available through templating then. MediaWiki messages don't have that problem.

The goal of that header for me is to have a simple message with some basic text on how to act in discussions. Adding this message to every single Flow board upon article creation would be burdensome.

Trizek (WMF) (talkcontribs)

Is it already implemented somewhere? (talkcontribs)

Do not really understand your question. It is present in default MediaWiki talk pages, like in French Wikipedia (the "Autres discussions" banner is added with a MediaWiki message I linked above), so it is a regression that this can't be done in Flow.

Trizek (WMF) (talkcontribs)

Now I see a case, thank you. I've documented it.

On the example you give me, we can see how the page is overloaded and discussions are not accessible. I know most elements are on the talk page itself, but if there is an integration on Structured Discussions, that would be done in consistency with the current design. MediaWiki:Talkpageheader would then be added on top of the sidebar. (talkcontribs)

Yeah, I wasn't talking about user-defined messages, board descriptions can have them if someone wants that clutter.

Thanks for help, hope this can be added soon.

Trizek (WMF) (talkcontribs)

You're welcome. I can't promise anything. That's on developers' hands for now and that kind of improvements is not on the roadmap...

Reply to "MediaWiki message for empty board description"

How to get Talk Discussion page here at mediawiki

Ljianyih (talkcontribs)

Hi, We think this mediawiki discussion page is very useful and nice, how can we install the discussion page like this one we're using here which is similar to reddit? (or any other highly recommended discussion plugins used by official mediawiki system)?

We have a mediawiki wiki site and the default discussion page couldn't be used by other users at all. We're not sure how to find any official or good extension to be used on all of our discussion page, and would prefer the official discussion style like this one used by mediawiki.

Ref: Talk:Structured Discussions

Trizek (WMF) (talkcontribs)
Ljianyih (talkcontribs)

Thanks for the reply. We're fairly new to mediawiki and once we saw this we're very excited to install this extension, glad we have finally found it. It seems like it is still under beta, and the page stated it would be great if advise can be obtained before the installation.

We have a fairly new mediawiki site , would it be recommended to install this plugin now with new mediawiki site with version 1.28? Thanks!

Trizek (WMF) (talkcontribs)

That tool stable enough to be used on several Wikimedia wikis, but is still on beta because some little bugs may occur. It is still maintained though so you can use it.

Structured discussions are supported for Mediawiki 1.27+ 1.28 will then work.

Mattflaschen-WMF (talkcontribs)

@Ljianyih First, note that 1.28 is End of Life (not getting security updates) (version lifecycle). So, you should first update to the latest stable version, 1.30 (Manual:Upgrading).

Also, please use matching branches. So, if you're using core 1.28 release (branch), use Structured Discussions (SD) REL1_28. If you're using core 1.30, use SD REL1_30.

If you are using a supported branch, you can simply download the right version of SD from Special:ExtensionDistributor/Flow .

Ljianyih (talkcontribs)

Thanks for the detailed explanation, they help a lot. Just one more question, does installing this extension automatically get enabled in discussion of all pages? We would like to get it enabled automatically in all default discussion page instead of having to insert code manually for each discussion (when click on the default discussion button on top navigation, user can just post directly). Thanks~

Mattflaschen-WMF (talkcontribs)
Reply to "How to get Talk Discussion page here at mediawiki"
Summary by Trizek (WMF)

Please use Structured Discussions/Sandbox for tests! (talkcontribs)

Let's go for it

"Structured discussions" are the status quo, this here is a step backwards, why this misleading rename?

Summary last edited by Diego Moya 08:39, 14 September 2017 9 months ago

Wikitext discussions use semi-structured layout, a flexible mechanism that provides a self-describing structure. The Structured Discussions project focuses on features that enable full-structured discussions by design, replacing the loose structure of talk pages with the rigid structure of a pre-defined database schema.

Sänger (talkcontribs)

Why did you use this misleading new name for Flow, where structured discussions are taking place on most regular talk pages now? They are usually even better structured, and definitely better to restructure, if necessary, than this weak forum impersonator.

I would file this under the same label as the bogus and deliberately biased "survey" for Flow: Deception of the community. Grüße vom Sänger ♫(Reden) 17:23, 13 September 2017 (UTC)

Sänger (talkcontribs)

A discussion with a structure is a structured discussion. Most discussions on talk pages are such discussions. As the WMF is denying the use of VE on talk pages without any valid reason, it's only possible to structure those discussions in the normal editor. But as they are as flexible as any wiki-page in the wikiversum, unlike this completely inflexible and rigid-like-concrete unstructured forum impersonation formerly known as Flow, they are even able to get restructured to a better arrangement, if this would make the discussion better readable, and the connections between the different edits are open for anybody like everywhere in the wikiverse in the page history.

This post was hidden by Diego Moya (history)
This post was hidden by Diego Moya (history)
Qgil-WMF (talkcontribs)

I have updated the summary trying to focus on answering the question at hand. I have hidden comments that were deviating from the topic. @Sänger, your opinion about the name and about the idea that wikitext discussions are structured too is clear.

The project name is not shown to users wherever this extension is enabled, and in this sense the name doesn't have an impact on actual users of this feature. The name is exposed to developers, admins, and people like us here discussing about a project. Discussions about project names are relatively frequent in the free software movement and other places. Statistically speaking, people just move on.

In any case, please let's keep a respectful and friendly tone.

Diego Moya (talkcontribs)

Wikipedia talk pages use what is called a semi-structured layout, as described at en:WP:THREAD.

Semi-structured content doesn't facilitates data-processing as well as a database schema does, but for human-facing content, the looseness and flexibility of a semi-structure is typically an incredible asset, as it allows to use the tool in ways and situations that weren't envisioned by the tool designer.

If the Flow developers want the tool to ever replace talk pages, they should be aware of and honest regarding what features they are removing, not just what they are adding.

Trizek (WMF) (talkcontribs)

Structured Discussions are a work in progress: features are not removed, but progressively added. Some communities are happy to Structured Discussions and are expecting new additions - we are working on it.

Diego Moya (talkcontribs)

I'm afraid you didn't understand what I meant by "removing features"; I was referring to features that would be lost in the change from wikitext pages to Structured Discussions pages.

There's an important feature in the current wikitext-based talk pages, which is that their structure is defined by the community, user-editable, easily reshaped with a text editor, and ultimately optional. This flexibility is seen as an asset by experienced Wikipedia editors, and thus a "feature".

The Structured Discussions team has made clear that they don't want to support a semi-structured tool with lightweight structure requirements defined in wikitext syntax. Thus, there is every indication that the aforementioned feature (let us call it "lightweight structure") is one that will not be made available in Structured Discussions, ever, by design.

Trizek (WMF) (talkcontribs)

"Lightweight structure" created by wikisyntax is complicated to reproduce with all details. This is the blank page effect: you can do anything you want using a blank page, and the visual structuration is then made by humans, progressively, for humans - other humans have to learn how to use the codes and the habits to enter the interaction.

Most machines requests are excluded from that, so as newcomers, alas: as you said, it is for experienced editors. For them, we are not removing talk pages. The new developments are only for Structured Discussions users, aka communities that use Structured Discussions; most of them use them to interact with newcomers.

> The Structured Discussions team has made clear that they don't want to support a semi-structured tool with lightweight structure requirements defined in wikitext syntax. 

For this year. As I was saying, features are progressively added: Structured Discussions are a work in progress.

Post a message, reply to it, reply to a previous messages is possible. Reply inside of a message is not possible (and even on unstructured wikitext talk pages, they are not the best practice for readability) but you can manually quote someone.

New developments will allow topic move and messages move. That will allow users to create sub-discussions or new discussions, which is the missing case for user-to-user discussions now. Which other cases from the lightweight structure do you have in mind? That would help for future prioritization. :)

Diego Moya (talkcontribs)

> "Lightweight structure" created by wikisyntax is complicated to reproduce with all details. This is the blank page effect: you can do anything you want using a blank page, and the visual structuration is then made by humans, progressively, for humans - other humans have to learn how to use the codes and the habits to enter the interaction.

I know it's not easy, but it's doable. Many people have requested that the WMF develop tools that would support most newbie-frendly workflows on top of wikitext, like those already available at the en:Wikipedia:Teahouse. Supporting basic lightweight structure at talk pages should be relatively easy, as shown by the fact that we already have some tools that actually do it, and seems fairly feasible for the reduced set of use cases that newcomers would need.

As many have explained, changing the underlying technology forces newcomers to learn to different tools, while a semi-structured discussion system on top of wiki pages would create a platform for new editors to progressively learn about wikitext.

Can you provide an explanation for why the WMF has never devoted resources to approach that kind of tools, many times have been requested by the community, and is using them to develop an entirely separate tool based on entirely different principles?

> For this year. As I was saying, features are progressively added: Structured Discussions are a work in progress.

Are you going to include features in Structured Discussions for lightweight structure? (a.k.a. editing the page structure in markup mode). This is huge news! ;-)

Seriously, "topic move" and "messages move" is less than what is possible in wikitext semi-structured pages; those features only solve a few use cases, but they fall way short from what lightweight structure is being used for in Wikipedia.

> Which other cases from the lightweight structure do you have in mind?

I have provided examples time and again during the last three years, at Talk:Flow and en:Wikipedia talk:Flow. Can you please create a central repository of community-requested use cases, so that we don't need to repeat them again and again?

Trizek (WMF) (talkcontribs)

> Can you provide an explanation for why the WMF has never devoted resources to approach that kind of tools, many times have been requested by the community, and is using them to develop an entirely separate tool based on entirely different principles?

Wikitext structured pages can't provide enough structure to have for example machine readable contents that would allow better interactions (through notifications) or create a sort of inbox for all messages you receive. We are in a loop, I think.

The Teahouse was a test about newcomers retention, not specifically about discussions. One of the aspects was indeed to ease discussions to increase retention, so a specific hack has been created for it. It appears that editors had more success when using the hack that opens windows to reply than regular wikitext. IIRC, it has motivated Flow's kickstart, to create a structured system that would give a more clear interface and more interactions.

> Are you going to include features in Structured Discussions for lightweight structure? (a.k.a. editing the page structure in markup mode). This is huge news! ;-)

Maybe later. We don't know yet. It is a possible option and all options have to be considered. But for this fiscal year, the plans plans are already defined.

> Seriously, "topic move" and "messages move" is less than what is possible in wikitext semi-structured pages; those features only solve a few use cases, but they fall way short from what lightweight structure is being used for in Wikipedia.

Allow me to disagree: if they solve a few use cases, I think they solve most done actions. The majority of interactions done daily in conversations are, I think, 4 types: create a new conversation, reply to someone (just below - regular reply), create a sub-discussion or move the topic to another place. There is of course extended cases, thousands, but they are proportionally a few.

> Can you please create a central repository of community-requested use cases, so that we don't need to repeat them again and again?

In theory, everything has been transferred as product definition on Phabricator or on category:Flow. But there is a lot of things in it and I haven't finished to explore everything.

Sänger (talkcontribs)

What's all this talk about machine readability? Do you want to endorse such projects like the Botpedia in Cebuano, i.e. get rid of those lousy editors, who dare to speak up against your fancy bling dreams?

No, machine readability has to be far far down on the list, and machine interactability should go straight to the bin. The Wikiverse is about people, the knowledge of people, who like to aggregate it. Machines may be useful in certain, restricted cases, but that#s it. If machines can't properly discuss, they should just shut up on talk pages.

And as Everything has been transfered as product definition on Phab or in category Flow: No, I don't care about dead projects, I wouldn't do anything to help Flow, as it's DOA. There is only stuff filtered through the eyes of proselytes, not even remotely everything.

And some things are deliberately delayed to promote Flow, like VE on talk pages, and everything related to VE on talk pages. It must not be done according to the Flow prophets, as it's blasphemy. Surveys are done based on deliberate false pretences, like no VE on talk pages without Flow, which is just an arbitrary decision by the WMF, not an axiom from the technique.

A wikipage is a wikipage is a wikipage, if you discount Flow, which isn't a wikipage, but something different, unconnected. Grüße vom Sänger ♫(Reden) 16:59, 14 September 2017 (UTC)

ChristianKl (talkcontribs)

Machine readability allows multiple new features.

It allows building features like having a list of all conversations that happen in a different category.

Machine readability makes it easier to display talk pages on mobile clients as talk pages are currently created with the desktop in mind. Given that mobile internet usage rises, it's good to have a structure that makes it easier for mobile users to interact with Wikipedia.

Currently, the act of achieving a discussion breaks links to the discussion. With flow every discussion has a stable ID that survives achieving a discussion. Having a stable ID for discussions is about machine readability. Stable links allow humans to find discussions.

Diego Moya (talkcontribs)

You don't need per-post machine readability for any of those features. Section-level thread detection, like the one available in the current editor, could be used to build them. Moving and renaming threads would require additional support from templates in wikitext, but it's still doable.

This post was hidden by Diego Moya (history)
Sänger (talkcontribs)

Flow/"Structured Discussions" remove nearly all features from normal talk pages and replace them with the very restricted feature we see here.

Indentation is limited, reorganisation impossible, seeing who answered what in huge discussions limited. It's a tool for short exchange and chitchat. Grüße vom Sänger ♫(Reden) 11:18, 14 September 2017 (UTC)

Jdforrester (WMF) (talkcontribs)
Wikipedia talk pages use what is called a semi-structured layout, as described at en:WP:THREAD.

Just to be super-clear: this is not true. It is not what "semi-structured" means in computer science. Wikitext talk pages are not self-describing machine-readable documents. If a help page on the English Wikipedia says that they are, it's misleading. User help pages should use human language terms rather than computer science ones anyway. :-) That said, I don't see a link from pages to – am I missing it?

Diego Moya (talkcontribs)

> It is not what "semi-structured" means in computer science.

In science, at some point what's true or false depends on how you define the terms. I still don't know how you define "structured" in a way that wiki talk pages don't have it, but it's good that you're switching to precise terms rather than the loose language used in the description page.

Wikitext discussions are text that "contain markers to separate semantic elements and enforce hierarchies of records and fields within the data", as defined by our article. The closest scientific classification I know for the kind of structure in wikitext discussions is Lightweight Structured Text, i.e. a way of processing the text incrementally to extract its structure from pre-defined parsing rules and expose it to generic tools.

Diego Moya (talkcontribs)

I've created a lightweight text processing rule to parse the comments in a wikitext discussion, and it is doing a very good job extracting the comments, written according to the norms that editors in the community follow. If some part of the page does not follow the norms, the pattern still infers some structure, which may not correctly align with the boundaries of the unformatted comments; and which is just how a human would try to process the norms.

The parsing rule is quite simple; it took me about ten minutes to write the part that extract the nested comments, mostly for remembering the syntax; and a few more minutes to add support for section headers. The rule is not complete, but it should be possible for a development team writing a dedicated parser to include proper recognition of signatures, add support for edge cases, and to degrade gracefully for the parts that don't follow any structure.

 line starts ("==") and ends ("==" or ("==" then Whitespace))
    or from (":" or "*") starts line
       to end of (line contains "UTC)")
    or from (line not (starts (":" or "*" or "==")))
       to end of (line contains "UTC)") or
           or line starts ("==" or Whitespace then "==")

There goes the argument that it is impossible to extract the structure of talk page discussions with software.

Sänger (talkcontribs)

A structured discussion is a discussion with a structure, no more, no less. Your insistence on the very narrow and restricted meaning of this broad defined two words are just misleading.

"Structure" has nothing at all to do with machine readability, and machine readability is nothing that is desired as a prime asset on a discussion page. Discussions take place between human beings, and discussion pages have to be designed to best serve human beings while interacting in a discussion, machines don't have to fit in.

Self-describing machine-readable documents is fine for nerds and as a self-serving nonsense, but has nothing in common with what's needed for wiki talk pages. Grüße vom Sänger ♫(Reden) 20:49, 19 September 2017 (UTC)

Diego Moya (talkcontribs)

Also, I've edited the previous discussion summary. According to en:wiki, semi-structured data is "a form of structured data...", so it is not true that wikitext discussions (as used in Talk:space) are not structured: they're merely not database-schema-structured.

Trizek (WMF) (talkcontribs)

@Diego Moya, I'm following the product manager expertise concerning structured discussions: current wikitext discussions are not structured from a technical perspective. The use of colons and other lists is structuring things for a human, but not for a machine. This is a big difference between a classical wikitext talk page, and XML or JSon semi-structured systems given as examples on the Wikipedia article you cite. This is why the discussion summary was written like this.

Diego Moya (talkcontribs)

> current wikitext discussions are not structured from a technical perspective

That's only true if you limit your technical perspective to relational databases, which is a pretty myopic perspective IMHO. The way wikitext conversations are structured is no different from how Python code is structured, for example; and you wouldn't say that Python code is not structured, would you?

It just happens that, since Talk pages are not compiled, users don't feel the need to produce syntactically correct discussions every time (nor they should to). That wouldn't prevent a software that was written for both humans and computers to parse the parts that are syntactically correct, and flag as "syntactically incorrect" and work around the parts that the machine can't understand; yet still make them available to the humans who know what to do with them. Many systems work that way, for example compilers and IDEs, and web browsers to some degree.

This approach would be incredibly more valuable to the community, and it's sad that you have decided to take the easy route without consulting your user base first, merely because the techniques involved are simpler for the developers.

Sänger (talkcontribs)

I couldn't care less but about machine readability, this is a project of interacting humans, and talk pages are for human interaction primarily. Grüße vom Sänger ♫(Reden) 11:20, 14 September 2017 (UTC)

Reply to ""Structured discussions" are the status quo, this here is a step backwards, why this misleading rename?"
Honischboy (talkcontribs)

I saw that (because much flow boards are "overflooded") sometimes posts are created duplicately. Why don't add a option to merge them? But the biggest matter is... How should that work?

Idea Problem
merge every replys sorted by timestamp in the same 'list' The comments have got another "directions" and so they will be "shaked" together
Use two collapsed lists Many pepole (me, too) won't read the collapsed lists
Use two uncollased lists one word: confusing
Trizek (WMF) (talkcontribs)

For now, the best way to do this is to close one of the topics as a duplicate of the other, with a direct link in the summary field.

I think T92907: Moving Flow Posts between Topics tracks this, more or less.

Reply to "Suggestion: mergeing topics"

Any way to have discussions on the same Page as article?

Schreibhan (talkcontribs)

I am running a MediaWiki within a company. My users keep pestering me that they want to comment an article below the article like on every single other platform they use. They simply reject the concept of a separate discussion page.

Any way I can get comments below an article in MediaWiki? (talkcontribs)
Qgil-WMF (talkcontribs)
Reply to "Any way to have discussions on the same Page as article?"