Jump to: navigation, search

About this board

The Collaboration team has enabled Flow on this talk page (documentation).

Previous feedback is on Talk:Flow Portal/Archive2 (using old Liquid Threads), and on our labs server.

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL (talkcontribs)

I get this error when I'm trying to use VisualEditor in Flow conversations:

[9149bd06] Exception Caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion.

VisualEditor is working on other sites normally.

I have these lines in my LocalSettings.php:

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

Parsoid seems to depub html > wikitext without problems.

Can you tell how to fix this?

Mattflaschen-WMF (talkcontribs)

What version/git commit of Flow and core do you have?

In recent versions of Flow, you need to use $wgVirtualRestConfig (recommended, if it's mentioned in your Flow.php) or $wgFlowParsoid* variables (either the only way, or a deprecated but still-working way).

Mattflaschen-WMF (talkcontribs)

You can see (either for $wgVirtualRestConfig or history of that for the old way). (talkcontribs)

I'm using the latest version. I haven't defined $wgVirtualRestConfig in my LocalSettings.php and I cant find this from Flow.php. Flow parsoid configuration looks like this:

$wgFlowParsoidURL = null; // also see $wgVisualEditorParsoidURL

$wgFlowParsoidPrefix = null; // also see $wgVisualEditorParsoidPrefix

$wgFlowParsoidTimeout = null; // also see $wgVisualEditorParsoidTimeout

If i set $wgFlowParsoidURL = http://localhost:8000 i get an error: [c949daba] Exception Caught: Failed contacting Parsoid and neither editor is working in Flow conversations. (talkcontribs)

This is what logfile says:

FlowHooks::initFlowExtension: Warning: $wgFlowContentFormat was set to 'html', but you do not have Parsoid enabled.  Changing $wgFlowContentFormat to 'wikitext' (talkcontribs)

...and i've checked: Parsoid service is up and running. I even tested it on http://localhost:8000 and its working normally.

Mattflaschen-WMF (talkcontribs)

What do you have for all the $wgFlowParsoid... variables in your LocalSettings.php? You only mentioned one. They should all (well, one or two are optional) be set to the same as their equivalent VE one is/would be.

If you use IRC, joining us in #wikimedia-collaboration on Freenode may be faster. (talkcontribs)

require_once "$IP/extensions/VisualEditor/VisualEditor.php";

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

require_once "$IP/extensions/Flow/Flow.php";

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

#$wgFlowParsoidURL = 'http://localhost:8000';

$wgVirtualRestConfig['modules']['parsoid'] = array(

  'url' => 'http://localhost:8000',

  'domain' => 'localhost',

  'prefix' => 'localhost',


I also have defined namespaces but I didn't write those here. I haven't made changes to Flow.php or VisualEditor.php.

Mattflaschen-WMF (talkcontribs)

If $wgVirtualRestConfig is not mentioned in a comment in Flow.php, there is no need to set it for Flow's purposes, and it won't have any effect on Flow (other than maybe confusing people).

You should uncomment $wgFlowParsoidURL and also set $wgFlowParsoidPrefix, $wgFlowParsoidTimeout, and $wgFlowParsoidForwardCookies.

I think:

$wgFlowParsoidURL = 'http://localhost:8000';
$wgFlowParsoidPrefix = $wgDBname;
$wgFlowParsoidTimeout = 100;
$wgFlowParsoidForwardCookies = true;

should work.

You can raise the timeout if wanted/needed. (talkcontribs)


$wgVirtualRestConfig is not mentioned in Flow.php. Should I use these in LocalSettings.php or Flow.php?

$wgFlowParsoidURL = 'http://localhost:8000'; // also see $wgVisualEditorParsoidURL

$wgFlowParsoidPrefix = $wgDBname; // also see $wgVisualEditorParsoidPrefix

$wgFlowParsoidTimeout = 100; // also see $wgVisualEditorParsoidTimeout

$wgFlowParsoidForwardCookies = true;

If set these settings to LocalSettings.php and comment in Flow.php I get: "Due to a technical error, this post could not be retrieved." Failed connecting parsoid. Neither editor is working (WysiWYG, VE). If I do vice versa I get the same error. If I set these above setting to both files I get the same error.

Why does it fail if i use VisualEditor for e.g. new pages and can save those successfully. Ii can still access and see parsoid running at the server. I've restarted the service.

If i comment these setting in both of the files, WysiWYG wikitext editor is working but VE gives: Exception Caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion.

My LocalSettings.php:

require_once "$IP/extensions/VisualEditor/VisualEditor.php";

$wgDefaultUserOptions['visualeditor-enable'] = 1;

$wgHiddenPrefs[] = 'visualeditor-enable';

$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

require_once "$IP/extensions/Flow/Flow.php";




$wgNamespaceContentModels[NS_USER] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_TALK] = CONTENT_MODEL_FLOW_BOARD;

$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

require_once "$IP/extensions/Echo/Echo.php";

If I add this to LocalSettings.php:

$wgVirtualRestConfig['modules']['parsoid'] = array(


'url' => 'http://localhost:8000',


'domain' => $wdDBname,


'prefix' => '100'


I get: [98970307] Exception Caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion (talkcontribs)

I corrected this one in LocalSettings.php:

$wgVirtualRestConfig['modules']['parsoid'] = array(


'url' => 'http://localhost:8000',


'domain' => 'localhost',


'prefix' => 'localhost'


I also tested echo 'Foo' | node parse and it is working. (talkcontribs)

Log file still says: Warning: $wgFlowContentFormat was set to 'html', but you do not have Parsoid enabled.

Mattflaschen-WMF (talkcontribs)

$wgVirtualRestConfig is not going to work with your version of Flow. Please do not change or post that setting.

Never change settings in Flow.php (unless you're a developer working on Flow, but that's a different matter). Please change Flow.php back to the version you downloaded.

Add the lines I mentioned to LocalSettings.php ($wgFlowParsoidURL, $wgFlowParsoidPrefix, $wgFlowParsoidTimeout, $wgFlowParsoidForwardCookies).

After changing LocalSettings.php, retest. If it doesn't work, post your full LocalSettings.php.

> Why does it fail if i use VisualEditor for e.g. new pages and can save those successfully. Ii can still access and see parsoid running at the server. I've restarted the service.

Flow uses a different set of settings. (talkcontribs)

Hi, Flow.php restored from the original file. Changed settings as you described - not working: Failed to contact Parsoid. Here is the LocalSettings.php:

#This file was automatically generated by the MediaWiki 1.25.1

# installer. If you make manual changes, please keep track in case you

# need to recreate them later.


# See includes/DefaultSettings.php for all configurable settings

# and their default values, but don't forget to make changes in _this_

# file, not there.


# Further documentation for configuration settings may be found at:


# Protect against web entry

if ( !defined( 'MEDIAWIKI' ) ) {



# Uncomment this to disable output compression

# $wgDisableOutputCompression = true;

$wgSitename = "Raksu";

####### UPLOAD FILE TYPES #######

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'doc',

    'xls', 'mpp', 'pdf', 'ppt', 'tiff', 'bmp', 'docx', 'xlsx',

    'pptx', 'ps', 'odt', 'ods', 'odp', 'odg', 'pdf');

# Custom Mediawiki settings

// Search settings

$wgAdvancedSearchHighlighting = true;

$wgEnableMWSuggest = true;

$wgUseTwoButtonsSearchForm = true;

#Set default searching

$wgNamespacesToBeSearchedDefault = array(

NS_MAIN =>           true,

NS_TALK =>           false,

NS_USER =>           false,

NS_USER_TALK =>      false,

NS_PROJECT =>        false,

NS_PROJECT_TALK =>   false,

NS_FILE =>           false,

NS_FILE_TALK =>      false,

NS_MEDIAWIKI =>      false,


NS_TEMPLATE =>       false,


NS_HELP =>           false,

NS_HELP_TALK =>      false,

NS_CATEGORY =>       true,



## The URL base path to the directory containing the wiki;

## defaults for all runtime URL paths are based off of this.

## For more information on customizing the URLs

## (like /w/index.php/Page_title to /wiki/Page_title) please see:


$wgScriptPath = "";

$wgScriptExtension = ".php";

## The protocol and server name to use in fully-qualified URLs

$wgServer = "";

## The relative URL path to the skins directory

$wgStylePath = "$wgScriptPath/skins";

$wgResourceBasePath = $wgScriptPath;

## The relative URL path to the logo.  Make sure you change this from the default,

## or else you'll overwrite your logo when you upgrade!

$wgLogo = "$wgResourceBasePath/resources/assets/raksu_uusilogo.png";

## UPO means: this is also a user preference option

$wgEnableEmail = true;

$wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "";

$wgPasswordSender = "";

$wgEnotifUserTalk = false; # UPO

$wgEnotifWatchlist = false; # UPO

$wgEmailAuthentication = false;

## Database settings

$wgDBtype = "mysql";

$wgDBserver = "localhost";

$wgDBname = "wikidb";

$wgDBuser = "";

$wgDBpassword = "";

# MySQL specific settings

$wgDBprefix = "";

# MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

# Experimental charset support for MySQL 5.0.

$wgDBmysql5 = false;

## Shared memory settings

$wgMainCacheType = CACHE_NONE;

$wgMemCachedServers = array();

## To enable image uploads, make sure the 'images' directory

## is writable, then set this to true:

$wgEnableUploads = true;

$wgUseImageMagick = true;

$wgImageMagickConvertCommand = "/usr/bin/convert";

# InstantCommons allows wiki to use images from

$wgUseInstantCommons = false;

## If you use ImageMagick (or any other shell command) on a

## Linux server, this will need to be set to the name of an

## available UTF-8 locale

$wgShellLocale = "en_US.utf8";

## If you want to use image uploads under safe mode,

## create the directories images/archive, images/thumb and

## images/temp, and make them all writable. Then uncomment

## this, if it's not already uncommented:

#$wgHashedUploadDirectory = false;

## Set $wgCacheDirectory to a writable directory on the web server

## to make your wiki go slightly faster. The directory should not

## be publically accessible from the web.

#$wgCacheDirectory = "$IP/cache";

# Site language code, should be one of the list in ./languages/Names.php

$wgLanguageCode = "fi";

$wgSecretKey = "secret_key_hided";

# Site upgrade key. Must be set to a string (default provided) to turn on the

# web installer while LocalSettings.php is in place

$wgUpgradeKey = "";

## For attaching licensing metadata to pages, and displaying an

## appropriate copyright notice / icon. GNU Free Documentation

## License and Creative Commons licenses are supported so far.

$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright

$wgRightsUrl = "";

$wgRightsText = "";

$wgRightsIcon = "";

# Path to the GNU diff3 utility. Used for conflict resolution.

$wgDiff3 = "/usr/bin/diff3";

# The following permissions were set based on your choice in the installer

$wgGroupPermissions['*']['edit'] = false;

## Default skin: you can change the default skin. Use the internal symbolic

## names, ie 'vector', 'monobook':

$wgDefaultSkin = "vector";

# Enabled skins.

# The following skins were automatically enabled:

wfLoadSkin( 'CologneBlue' );

wfLoadSkin( 'Modern' );

wfLoadSkin( 'MonoBook' );

wfLoadSkin( 'Vector' );

# Enabled Extensions. Most extensions are enabled by including the base extension file here

# but check specific extension documentation for more details

# The following extensions were automatically enabled:

wfLoadExtension( 'Cite' );

wfLoadExtension( 'CiteThisPage' );

wfLoadExtension( 'Gadgets' );

wfLoadExtension( 'ImageMap' );

wfLoadExtension( 'InputBox' );

wfLoadExtension( 'Nuke' );

wfLoadExtension( 'PdfHandler' );

wfLoadExtension( 'Renameuser' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'TitleBlacklist' );

wfLoadExtension( 'WikiEditor' );

# End of automatically generated settings.

# Add more configuration options below.

# WikiEditor settings

# Enables use of WikiEditor by default but still allow users to disable it in preferences

$wgDefaultUserOptions['usebetatoolbar'] = 1;

$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;

# Displays the Preview and Changes tabs

$wgDefaultUserOptions['wikieditor-preview'] = 1;

# Displays the Publish and Cancel buttons on the top right side

$wgDefaultUserOptions['wikieditor-publish'] = 1;

#Set Default Timezone

$wgLocaltimezone = "Europe/Helsinki";

$wgLocalTZoffset = date("Z") / 60;


require_once "$IP/extensions/UniversalLanguageSelector/UniversalLanguageSelector.php";

# EXTENSION: Visual Editor

require_once "$IP/extensions/VisualEditor/VisualEditor.php";

// Enable by default for everybody

$wgDefaultUserOptions['visualeditor-enable'] = 1;

// Don't allow users to disable it

$wgHiddenPrefs[] = 'visualeditor-enable';

// OPTIONAL: Enable VisualEditor's experimental code features

$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

// URL to the Parsoid instance

// MUST NOT end in a slash due to Parsoid bug

// Use port 8142 if you use the Debian package

$wgVisualEditorParsoidURL = 'http://localhost:8000';

$wgVisualEditorParsoidForwardCookies = true;

$wgSessionsInObjectCache = true;

$wgVisualEditorNamespaces ['*'];

#$wgVisualEditorNamespaces = array( NS_MAIN, NS_TALK, NS_USER, NS_USER_TALK, NS_CATEGORY);

# EXTENSION: Confirm Account

require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php";

#$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 0;

$wgConfirmAccountRequestFormItems['Biography']['enabled'] = false;

#$wgConfirmAccountRequestFormItems['Areasofinterest']['enabled'] = false;

 $wgMakeUserPageFromBio = false;

 $wgAutoWelcomeNewUsers = false;

 $wgConfirmAccountRequestFormItems = array(

 'UserName'        => array( 'enabled' => true ),

 'RealName'        => array( 'enabled' => true ),

 'Biography'       => array( 'enabled' => false, 'minWords' => 50 ),

 'AreasOfInterest' => array( 'enabled' => false ),

 'CV'              => array( 'enabled' => false ),

 'Notes'           => array( 'enabled' => false ),

 'Links'           => array( 'enabled' => false ),

 'TermsOfService'  => array( 'enabled' => false ),



# Disable reading by anonymous users

$wgGroupPermissions['*']['read'] = false;

# But allow them to access the login page or else there will be no way to log in!

# [You also might want to add access to "Main Page", "Wikipedia:Help", etc.)

# But allow them to read e.g., these pages:

$wgWhitelistRead = array ("Main Page", "Special:Userlogin", "Help:Contents", "-", "Special:Requestaccount", "Toiminnot:Pyydä_käyttäjätunnusta");

#$wgGroupPermissions['*']['createaccount'] = false;

# EXTENSION: Input box

wfLoadExtension( 'InputBox' );

# EXTENSION: Fancy Box Thumbs


# EXTENSION: MediaWiki Chat

require_once "$IP/extensions/MediaWikiChat/MediaWikiChat.php";

# EXTENSION: Access Control


# EXTENSION: User merge and delete

require_once "$IP/extensions/UserMerge/UserMerge/UserMerge.php";

// By default nobody can use this function, enable for bureaucrat?

$wgGroupPermissions['bureaucrat']['usermerge'] = true;

// optional: default is array( 'sysop' )

$wgUserMergeProtectedGroups = array( 'groupname' );

# EXTENSION: Enable Subpages

# Enable subpages in the main namespace

$wgNamespacesWithSubpages[NS_MAIN] = true;

# Enable subpages in the template namespace

$wgNamespacesWithSubpages[NS_TEMPLATE] = true;

# EXTENSION: Hide Prefix 

require_once "$IP/extensions/HidePrefix/HidePrefix/HidePrefix.php";


#The Flow extension provides a new discussion and collaboration system for talk pages

require_once "$IP/extensions/Flow/Flow.php";

#To enable Flow for a namespace, use $wgNamespaceContentModels. For example:




#$wgNamespaceContentModels[NS_USER] = CONTENT_MODEL_FLOW_BOARD;

$wgNamespaceContentModels[NS_TALK] = CONTENT_MODEL_FLOW_BOARD;


$wgFlowContentFormat = 'html';

$wgFlowEditorList = array( 'visualeditor', 'none' );

// Parsoid configuration

#Flow uses the Virtual REST Service to contact a Parsoid or RESTBase service. 

#If your wiki loads the VisualEditor extension, then you've probably already set this up.

$wgFlowParsoidURL = 'http://localhost:8000'; // also see $wgVisualEditorParsoidURL

$wgFlowParsoidPrefix = $wgDBname; // also see $wgVisualEditorParsoidPrefix

$wgFlowParsoidTimeout = 100; // also see $wgVisualEditorParsoidTimeout

$wgFlowParsoidForwardCookies = true;

//Flow talk notifications

require_once "$IP/extensions/Echo/Echo.php"; (talkcontribs)

Im still fighting with this issue. Please Help.

Wess (talkcontribs)

Have you found a solution for this?

Reply to "Using VisualEditor in Flow"
天帝驕子 (talkcontribs)

Anyone can help me to move zh:user talk:上天驕子 to zh:user talk: 上天驕子/Flow

Trizek (WMF) (talkcontribs)


Didn't you manage to do that by yourself, by deselecting Flow on your Beta preferences?

天帝驕子 (talkcontribs)

Thanks!I've tried it myself in the Taiwan user talk page, and I can't do this.

Trizek (WMF) (talkcontribs)

That's wired. We will investigate, I may recontact you about that.

Reply to "Help" (talkcontribs)

Normally, it is possible to get feeds using something like:

Is there an equivalent for flow boards / or topics?

Trizek (WMF) (talkcontribs)

You mean Topic:T1yb1chdkse6av65&feed=atom&action=history? Not at the moment I'm afraid.

I've created a task to track that feature request. (talkcontribs)

Yes. Just as described in:

Trizek (WMF) (talkcontribs)

I've used your documentation, and I confirm that request to have a RSS feed is not working on Flow: (talkcontribs)

I thought there was simply another way of getting the feeds.

Thanks for submitting the "feature" / bug report!

Reply to "RSS feeds"

Flow talk page converted to a wikitext page (reasons)

Syum90 (talkcontribs)

Hi, as asked by Quiddity I explain my reasons to request converting my Flow talk page to a wikitext page. I've requested this conversion because a wikitext page is more flexible and lighter, and additionally is much more easy to treat, at least for me. Thank you very much to Quiddity for helping me.

Syum90 (talkcontribs)

To be fair with Flow I have to say that in my opinion a Flow page is easier for newbies and also requires less maintenance when is edited by them due to its automatic placement of headers, comments and signatures. As a conclusion I think a newbie will prefer a Flow page but an experimented user will prefer a wikitext page because of its lightness and flexibility.

Trizek (WMF) (talkcontribs)

Thank you for your feedback, Syum90!

In your opinion, what is missing on Flow to have it adopted by experimented users?

Syum90 (talkcontribs)

I can't speak for other users, but there are several other things important for me: 1. we cannot restore one revision of the page directly, instead of this we have to hide all the further edits one by one; 2. the impossibility to use the rollback tool; some time ago we suffered a great spam attack by spambots here at mw, and it was very heavy for us to remove all their edits manually one by one instead of using the rollback tool; 3. the impossibility to use the edittools.

Some time ago we treat about Flow on meta at this RFC, you can get more feedback there.

Trizek (WMF) (talkcontribs)


Syum90 (talkcontribs)

There is another thing that I forgot: I heavily use popups and I can't use it to see edits on Flow pages at Special:RecentChanges; this is also an inconvenient.

Trizek (WMF) (talkcontribs)

Yeah, we know about that. Having a better way to deal with pages' history and RCs is something we need to prioritize.

AlvaroMolina (talkcontribs)

In my opinion, the Flow is a system of excellent and flexible talk, but for me the downside is that it is not very customizable (e.g.: I can not put a header like I do with my user page), if the developers could give that option and do not so limited, it would be excellent. For example, pages Semantic MediaWiki or TranslateWiki have a similar system in the talk pages, but if allowed to put headers on those pages. This is for now the only deficiency that has Flow, but for newbies, is an excellent way to manage more comfortably messages and not have much complication with using wikitext.

Trizek (WMF) (talkcontribs)

That header has been reported to the sidebar, because on certain pages, people didn't knew they were conversation due to header's height!

I use Flow on my volunteer talk page, and, with appropriate colors, things I want people to notice are perfectly seen, even if it is on the sidebar that may be perceived as not as visible as a header.

Tropicalkitty (talkcontribs)

I personally didn't like the long line of deleted comment messages before the next appropriate comment.

Trizek (WMF) (talkcontribs)

Collaboration team is going to release a survey soon, in order to collect suggestions and feedback and define priorities to support Flow. Your feedback is helpful to confirm the questions we ask. Thanks a lot!

Diego Moya (talkcontribs)

Trizek, there are two years worth of detailed community feedback at the En:Wikipedia talk:Flow archives. Will you be keeping track of that, or are we starting anew? Should we repost it into the new survey?

Trizek (WMF) (talkcontribs)

I am keeping track of that, Diego, but, as you know, there is not only English Wikipedia's opinion in the wikiverse! ;)

Some other communities are using Flow at the moment and they tell us they are very happy with it or don't give us negative feedback. We want to know how can we improve structured discussions for them, based of their requests for new features. Of course, feedback from any other interested users from any community will be welcome.

That survey, gathered with all feedback we already know about (from the page you linked and other resources), will help us to define a strategy for the future, in order to give a good and relevant structured discussion system to communities (called Flow or not) if they want one.

Reply to "Flow talk page converted to a wikitext page (reasons)"

How can I redirect a Flow page to a talk page?

Summary by Trizek (WMF)

Reported as task T102300

Sänger (talkcontribs)

Flow pages seem to have no possibility to be redirected to another page. How can this be done?

Trizek (WMF) (talkcontribs)

It is not possible at the moment, but there is a trick: make a /subpage in your userspace; page-move it on top of the empty Flow board.

I've pushed the task on Phabricator to have that problem solved.

Sänger (talkcontribs)

I'm asking about this talk page that should not exist but as a redirtect over here. As it's something the WMF has botched, it's their duty to fix it.

Trizek (WMF) (talkcontribs)

Flow is not on active development now. As I've said, I've pushed that request. I'll see if it is difficult to have it fixed as a bug, or if it is a new feature (which may be a little bit more complicated to code).

Your need is considered and I appreciate to have your feedback to push that need forward. :)

Sänger (talkcontribs)

Could you not simply delete that page and restart it as a normal talk page? That should fix it. There's nothing in there but my rant, I don't care about that history. And of course do the same with all other talk pages of translations, that should be redirects to the only valid one as well.

Trizek (WMF) (talkcontribs)

I'm going to delete that page and try to create a redirect.

About the idea of creating redirects for all translations units, that should be discussed with translators. :)

Sänger (talkcontribs)

It should be discussed with those, who are supposed to answer questions. If you create talk pages, or even just Flow stuff, in many languages, it's of course the duty of those who created them to maintain them and to answer the questions, you can't expect to have a proper discussion on drölfzig verschiedenen discussies here on this meta page.

Tropicalkitty (talkcontribs)

Sorry but I went ahead and disabled Flow on that page.

Sänger (talkcontribs)

Thanks for that constructive edit.

Is this something every editor can do, or is it restricted to admins?

Tropicalkitty (talkcontribs)

It's restricted.

Sänger (talkcontribs)

Unfortunately you deleted the correct redirect again, so now it's again a useless Flow Forum.

Trizek (WMF) (talkcontribs)

I'm afraid I don't understand your idea.

Having a redirect for all translation sub items is not related to Flow but to Translators practices, no?

Sänger (talkcontribs)

Translation of meta pages is about the readability of those pages not only for English speakers. To disperse the discussions of this topics to several unconnected venues is imho detrimental to a diverse community, they would be several disconnected discussions, and as I expect with the English hegemony in the wikiverse all other language discussions will go straight to the virtual bin.

How would you keep track about, say, 20 discussions in 20 languages her on this particular meta-wiki? How will you make sure tat all concerned people will even see the Chinese or German questions and discussions, if they are not bundled in one page?

Now you have to be bold to start a thread in a discussion in your own language, but it can be done, and those pages are at least watched, and some translators, not usually official ones, could a) translate to and from English and b) perhaps even answer straight away in the other language.

OK, the fanboys of Flow once promised that this should be possible with Flow, as every thread could be automagically (or manually) be attached to different discussion pages, and thus be monitored in one place. But last time this was asked for, it was not working.

Trizek (WMF) (talkcontribs)

So that discussion is not about Flow but about readability and discussing if it is relevant to gather discussions.

If I understand correctly, your point is still about redirecting all conversations by language about a translations to one place (imho, that's a good idea). You need then to discuss with other translators to decide if redirect all sub pages to one single place is the best option. That was my point since the beginning of that digression. ;-)

The feasibility by Flow is an other question, not related at all. Redirects will be done by the end of the current quarter, and that has been decided after your feedback. If translators decide to gather all translations to one place what would be then feasible both on wikis which use Flow or the classical discussion system. Flow, coupled with Cross-wiki notifications, give people the ability to know a new topic has been created about a translation.

Display Flow Topics on multiple pages and having a place to gather all discussions you watch are features that are possibly feasible. We are waiting for Flow satisfaction survey results to how more about these needs. I'll not expand about that, because you know the details and that's is off-topic. :-)

Sänger (talkcontribs)

It's not all conversations by language about a translation to one place, it's all conversations about a topic to one place. The translations are about one concrete topic in one same wiki, not about the transfer of articles in other wikis, or some meta discussions about translations in general. That's nothing to do with the translators, but with the stake holders in the meta pages content. The discussion pages I mentioned are the discussions for the topic, as they are in the translated versions of certain pages in the regular place where content discussions should occur.

The translated versions of pages here in one of the meta wikis, be it or or whatever, are for the better understanding and proliferation of the content of that page, and the associated talk pages are by definition as well about the content of the page. Currently, if a meta page is translated, there is as well a associated talk page for the translated language, and readers, that want to comment about the content will of course go there and write some remarks or questions or suggestions about that topic on that talk page, if it's not redirected to one unified talk page.

Trizek (WMF) (talkcontribs)

Do you have an example (even if it is a fake one)? Thanks! (talkcontribs)

from today.

and all other language versions of meta:Talk:2016_Strategy/Community_consultation/Communities as well from some time ago.

It was me, after a misclick on logout., Grüße vom Sänger ♫(Reden) 16:24, 20 April 2016 (UTC)

Trizek (WMF) (talkcontribs)


Both examples are not related to Flow but are depending of translators' practices. Having such redirects must be discussed with translators.

If you think mediawiki should automatically create these redirects, that will need a particular development for Extension:Translate, which is not the current topic.

Sänger (talkcontribs)

Both examples have nothing to with translators practices, but the usefulness of the discussions of the content. Flow is currently preventing the redirect of such pages, that's why Flow is involved. And regardless of the examples, it should be possible to redirect any talkpage if the owner/stakeholder wants it that way. Flow simply breaks the usual Wikipedia practises, again.

Those redirects should be decided by the content owners/stakeholders of the translated pages, not by the translators, at least at last. It should be discussed as a policy or such within the concerned community. Of course are translators normal editors as well, and will sometimes decide such stuff on their own, like I did then, but in general it's not something to be dealt with with translators only.

Trizek (WMF) (talkcontribs)

You know your attitude is just harassment? Anything I'll say about Flow will be challenged by you, just because you don't like that product. That's not constructive at all, and possibly reprehensible regarding Code of Conduct or other Meta policies.

Having a discussion about redirects with translators to define if that is a good idea is a constructive suggestion about how to improve the current workflow. It has nothing to do with Flow.

So please stop you attitude and change your behavior : redirects will be soon handled by Flow and the current discussion is definitely turned to be off-topic and not constructive.

Sänger (talkcontribs)

It's harassment to show the clear disabilities of Flow on the Flow talk page? That's a strange concept of harassment.

Again: The possibility, to redirect any talk page anywhere else should be in the hands of those, who have the legitimate say about this talk pages, id est the user with a bot on his bots talk page, the content stakeholder of a translated page for all those translated subpages and so forth.

Currently Flow prevents this, as is mentioned in the phab ticket. I only came by this problem, as I wanted to redirect a discussion page of a translated page to the right and only discussion page about the content, and was prohibited to do so by Flow.

Whether or not the different sub-pages that are created by a translation should be all redirected to the one and only original talk page (probably useful in most cases), of if in certain cases there should be language segregated discussion pages, one for each language, or bundled in close ones (/bay and /als should always be redirected to /de on meta pages like here), should be decided on a by-case base by the content stakeholders, not the translators.

Trizek (WMF) (talkcontribs)

I perfectly accept critiques about Flow and I'm the first one to discuss about its weaknesses.

What I don't accept is your conflict attitude and the fact that you challenge every comment I can make just because you don't like the product I'm working on. Your non-stopping critiques and your derogatory comments concerning my work here on on Meta are clearly harassment.

I've reported your attitude.

Sänger (talkcontribs)

Sorry about that, but it's a kind of afterpains the WMF inflicted on the community with their hostile and vile behaviour with MV/Superputsch, that used nearly all good faith towards WMF pet projects. It's definitely nothing against you in person, just the community harassing actions, for what still a sincere apology is missing, by the WMFers.

Imho Flow is just the next bling thing some people at the WMF want to introduce against the communities as a pet project, the same as with the completely botched VE, first take, that still has a considerable amount of people miffed, because despite lots of valid input the WMF forced it on the projects in a stadium, it was plain destructive and not even remotely ready for testing in the wild. And with the implementation against the explicit consensus of 3 projects of a futile bling-thing MediaViewer, just for the vain of Florice, to get the first mayor project done, despite its disregard for proper mentioning of licenses, lots of other problems, and not even the the tiny step from opt-out to opt-in was possible against the brutal might of superprotect. Then there were a bit minor things like was Gather and UserProfiles, and now there is Flow, the next pet project of the WMF. Why should anyone expect good faith by those who have acted so much against the community in the past with similar stuff?

As I said, it's not against you in person, I don't know you enough for that, it's against the attitude of the WMF towards the community, that was destroyed by actions of the WMF in the not so distant past. And it's moving further and further in seemingly similar directions and similar disasters, without an apology towards the community for this mean hostility.

First small sign of recognition of the communities will was the stoppage of Flow by Lila, suddenly the communities were listened to. And superputsch was ditched, even in a far too silent manner, without an apology for this declaration of war without a reason. And now I see this survey, that looks very much like Flow was not so ditched at all, that it was perhaps just the next deception, and the WMF secretly developed it further. Are you really surprised, that this gets such a reaction?

P.S.: VE is now absolutely OK, and I voted for allowing IPs to use it in the deWP, it was just pre-alpha when it was first forced upon the communities as compulsory. Perhaps Flow will one day in the far future, if all those promises about flexibility thousands of use cases will really become true, be useful as well, or it could be introduced as a page besides normal, flexible talk pages, but as it is it's not suited for prime time.

But I'd prefer a bit more good old maintenance instead of just looking for the next bling.

Keegan (talkcontribs)

False apologies help nothing, it's even worse when cushioned with "You started it." You say, "Sorry about that, but it's a kind of afterpains the WMF inflicted on the community with their hostile and vile behaviour with MV/Superputsch, that used nearly all good faith towards WMF pet projects."

No, Sänger, your improper language and aggression towards WMF staff occurred months before Superprotect, specifically towards me. You even used the same fake apology and said I'm probably not a bad person, but the WMF is asking for it, and that was a two years ago. You cannot excuse your horrible attitude and your harassment of people for things that you do not like. You need to walk away from the keyboard, go look in the mirror, and remember that you're talking to other human beings. Until then, don't talk about directly to anyone anymore.

Sänger (talkcontribs)

My first post here was about exact this MV/Superprotect disaster, and how the arrogant, brutal and hostile WMF tried to subjugate the communities to their will. It was about half an hour after superprotect, this declaration of absolute war against the community, and I perhaps didn't knew then about this extreme measure, but it was already clear, that they didn't intend to listen to any feedback that didn't support their biased and distorted mindset.

Trizek (WMF) (talkcontribs)

Humpf, that's not working. As I've said, I'll ask the Collaboration team about that.

Trizek (WMF) (talkcontribs)

That task has been updated and is now on the roadmap for that quarter.

Tropicalkitty (talkcontribs)

I'm now thinking it's up to the latter point. I'm awaiting decision on task T102300 because I don't know where this is heading...

Reply to "How can I redirect a Flow page to a talk page?"
Zhouyanqing (talkcontribs)


Polentarion (talkcontribs)

Hi there. I am an WP author from Berlin, working in both the English and German Wikipedia. I am member of the German Wikipedia:Projekt Moderation, which works on a sort of facilitator's toolbox and would like to introduce and easen facilitating in WP discussions. I am interested to touch base here and connect and present our work to the group and receive you constructive feedback and suggestions.

I am an active Toastmaster and I am more about practical Rules of Order than about Software. But Software should enable and regard actual practices in the actual Wikipedia.

We already got a visual editor in article space. Most of the discussions are being led in Usenet mode based on a comparably simple editor.

Some points

  • WP talk pages in articles on recent topics tend to develope facilitation, e.g. section proposals are being proposed and integrated into lists
  • Various communities have already developed and uses different templates and structures, e.g. in opinion polls, ArbCom and featured articles.
  • Any main page section has structured discussion templates, e.g. DYK in the enWP, or SG? in the deWP
  • In ArbCom style conversations e.g. statement fields, not threads are being used. The reslut is about result, less about chat

However, e.g. in the discussion of a lede or disputed section, basic visualization techniques - like a table with the existing version, state of the discussion and a proposal - are not being used on a regular base. Third opinions often get lost. Tools to compare and keep an overview - e.g. the TOC of an article and proposed general changes to it are not being used. Usenet style discussions are so 1980ies - and hinder the introduction of new members outside of the Anorak camp.

It already could be done in a much more constructive and structured way. Practical example - see

Point is - the current usenet style tries to keep all and everything visible. Facilitating is as well about hiding, removing and sorting stuff and showing the resulting compromises. If you need the thread, have a look on the version history.

That said, any project intentending to improve facilitating WP discussions should less try to implement Facebook or LiquidFeedback but helping to easen actual needs of the community. And of cause, the actual existing practices have to be involved.

How can Flow be of help in that respect? Have you ever done a survey of existing templates and discussion patterns here? And of cause, if useful, how to implement flow e.g. for the deWP facilitation project or a user page?

Trizek (WMF) (talkcontribs)

Hello Polentarion, and thank you for your message!

Collaboration team had plans to work on Workflows. The original idea was to create a toolbox with a lot of elements, and the combination of these elements can help people to create powerful tools to facilitate all workflows and processes. It has been presented during last Wikimania. For example, with this Workflows system, you can have a poll system which counts automatically every vote and give you real time results, a deletion-proposal system where people just have to give the motive and press a button to start the process and warn everyone, and so.

Flow is a brick on that project. Indeed, we need a structured discussion system to make it possible: the way wiki-talk pages are created make impossible any relevant search, or don't give you the possibility to watch only conversations that interest you. We also need a modern interface, because in 2016 a lot of people are not used to count colons or add signature after their messages! :-D

Flow has been delayed to focus on Notifications (we will release cross-wiki notifications soon) but we will make some improvements to Flow soon after a community consultation (Flow is used on some wikis, in a very active and important way for some of them).

Concerning your project, Flow can help you in many aspects. you can use the Summary field (see the glossary) to have the two sections that you want to compare. The discussion can be done below. The indentation system can be very helpful to create digressions.

If there is a consensus from a wiki-project to try Flow for a specific purpose, please report it to that page. Someone will create a Flow board where you need it. To have Flow on a user talk page, a more global consensus is needed due to the impact of Flow on Notifications (a poll opened to the whole community for example). I can help you to set it up.

And, of course, do not hesitate to contact me if you have questions or if you need clarifications!

Quiddity (WMF) (talkcontribs)

@Polentarion Hi. Just to add to Trizek's reply, I would suggest that you wait before starting a discussion, until after Phab:T125632 is completed. This will get a clearer basis of information for everyone, and enable a smoother discussion. The timeline for that task is not firm, but it will be a few weeks, yet. We can ping you, when it is complete. Hope that helps. :-)

Polentarion (talkcontribs)

My point is about schemes and structures that actually work with the existing software and community. In so far I still ask Flow developers to check what is ongoing in real life WP. ~~~~

Trizek (WMF) (talkcontribs)

We always consider and pay a lot of attention to what is happening on "real life communities", on all Wikimedia projects. I'm personally a strong advocate of going further to have tools that can fit advanced users and all their needs and newcomers, and this on all wikis. :)

Polentarion (talkcontribs)

Honestly, something like "we always consider and pay a lot of attention" is a claim, where is the beef and proof? At project Moderation, we have collected actual case studies.

  • Wikipedia:Projekt Moderation/TB Discussion of setup and TOC
  • Wikipedia:Projekt Moderation/TB Discussion of sections
  • Wikipedia:Projekt Moderation/Texbaustein Consensus buiilding for a complex task, e.g. a failed opinion poll or major controversy
  • Wikipedia:Projekt Moderation/Texbaustein 3M (third opinion formalities)
  • Wikipedia:Projekt Moderation/Textbaustein Consensus buiilding for the generic narrative of an article

Show me YOUr case studies, and I will believe you respectively be less doubtful about the sucess of Flow.

Trizek (WMF) (talkcontribs)

These resources were in my reading list, so I will raise the reading to the top. I'm pretty sure that may help future developments.

What case studies are you looking for? Cases where people are satisfied of Flow as a talk system? Cases where Collaboration team has worked to address communities requests? I'll be happy ti answer the best way I can.

Polentarion (talkcontribs)

No, we seem to talk about different topics. You seem to look for cases where Flow could have been of help. Its the other way round. Look for problems that need a solution ;) That would have avoided the failure of Flow in the community. As long as Flow stays a sort of White Elephant, a solution desperately looking for problems it probably will stay as such. Your answer, sorry to say, confirms that. I would have preferred a system developement that looks on actual and repeated discussion cases in the "real Wikipedia". You probably still need to build up case studies.

Trizek (WMF) (talkcontribs)

Well, I don't think I'm that out of topic: Flow has been changed sometimes to fit to address some particular community needs (for example ). On other wikis, like Chinese Wikipedia, people use Flow Flow as an "actual and repeated discussion cases". :)

As I write earlier, Flow is a brick. Flow can be used alone, but don't see it as a final product. That was the purpose of the Workflow project. Flow can be a brick to create more easier to use workflows, or may not be used.

We are not working on Workflows right now (focusing on Notifications first) but we keep it in mind that there is multiple and complex workflows. When we will work on these complex workflows, your experience with the Projekt Moderation will be really helpful for us to identify the needs and build tools that will address as possible cases as possible. Would you help?

Polentarion (talkcontribs)

Lets say, I am happy to be of help and I am glad you see the need to involve workflows. The discussion at the lede of enWP Al Maghtas is one of the practical examples in the enWP.

If you show me a place to translate my cases and case studies, I will do so, Attached find the titles ;)

  • Consensus buiilding in discussion of setup and TOC
  • Consensus buiilding in discussion of sections
  • Consensus building for a complex task, e.g. a failed opinion poll or major controversy
  • 3M (third opinion formalities)
  • Consensus buiilding for the generic narrative of an article
  • Consensus buiilding and Workflow for a newsticker article (large involvement, large amount of incoming sources like in Fukushima accident or Cologne NYE)
  • Decicion making and workflow for elections
  • Decicion making and workflow for AfD
  • Decicion making and workflow for disrupting behavior
Trizek (WMF) (talkcontribs)

If you can provide translations, that would be very helpful. There is no dedicated place at the moment for Workflows. Do not hesitate to start your translations on any wikipage, we can move those afterwards.

Thank you again!

Polentarion (talkcontribs)

Its not so simple ;). I formally ask to open a dedicated place, e.g. a project website within FLOW where actual showcases can be linked to with a short explanation of the case. Like my list, max 100 words for the explanation and a max of a dozen links. That would be a showcase in itself - its a wiki, and a collaborative effort.

Trizek (WMF) (talkcontribs)

Let me ask the Collaboration team about that. :)

Quiddity (WMF) (talkcontribs)

@Polentarion There has been some past research into workflows, at various levels of abstraction and detail. I'll link to, and very briefly describe, the most prominent pages and link-hubs.

Before coding started on Flow, the page Flow/Use cases was created (early 2013). It examines and describes the generalizable workflows that editors use, in 4 namespaces (talk, user-talk, project, and project-talk). It aimed to analyze workflows at a level that could be applied to all languages/projects, without getting into the specifics.

A more abstracted version of this, in a visual "flowchart" form, is in pages 27-31 of these slides (from Wikimania 2013).

Some additional ideas about how this community-creatable workflow system might work, are in pages 20-25 of these slides (from Wikimania 2015). There are some brief notes about this, at Collaboration/Workflows. Some of the other early Flow research, also used this idea (e.g. Flow/Block Module).

The most comprehensive page is m:Workflows, which I started putting together in late 2013, as a link-hub for everything that I could find. It lists workflow research by various people over the years, including links to more of the early Flow research/brainstorming pages. It also includes some examples of existing workflow-collection systems that the communities have created, such as the dashboards and template-compilations and other API/script/bot-updated pages.

Regarding how you can help (thank you!)... Hopefully the above links are useful and interesting for you. I've been re-reading your initial comment, and nodding vigorously, especially at "Tools to compare and keep an overview - e.g. the TOC of an article and proposed general changes to it - are not being used" (I'm so happy that we can update the "description" in phabricator, whereas we couldn't in bugzilla).

I'm also reading (a confusingly google-translated version of) w:de:Wikipedia:Projekt_Moderation, and am very interested. For example, the /TB_Abschnitt page seems to be describing the same ideas as in phab:T89575 ("Associate non-body content such as annotations and talk to a location in the article") - basically, having {{clarify}} be more than just a simple inline template, and instead have it be a link that pops open the relevant discussion, directly within the article itself. (I threw some very rough ideas together 2 years ago, related to gdocs comment system, plus touching on text-density and other elements, at ) I'd be very happy to read more about all of these ideas, and add what notes I can. Perhaps you could create 1 or 2 examples, either in Collaboration/Workflows/Examples or subpages like that, and we can slowly build up a structure around it as we go. A few editors in other languages have also offered similar help.

I hope that helps, and is neither too little nor too much information!

Polentarion (talkcontribs)

Yep, sounds like real work! I appreciate as well the links to project pages. Lets see what I can do.

Point is the current deWP:Discussion page rules are a sort of nuisance - they ask for a 80ies usenet thread. Its basically much more about the the thread of the discussion, not about the results.

What I would like to see on an abstract level, is 1) a sort of template-and-result oriented approach. That said, you do not try to display the course of the discussion, you try to display the results, hopefully the consensus (which hopefully is being built in the course of the enterprise). That approach (successfully done "over the Jordan" for the lede of the enWP Al Maghtas talk page) can be used on various topics, As said, TOCs, article lede, sections and the generic narrative, the images used for an article and so on.

2) would be structures for "newsticker articles" like Cologne NYE 2015/16 or the Fukushima accident. Point is, those articles talk pages get structured, since you have to cope with a large amount of suggestions, get them in the current structure (or change that) and discuss them in a sort of Triage approach.

  • Those who are likely to live, regardless of what care they receive;
  • Those who are likely to die, regardless of what care they receive;
  • Those for whom immediate care might make a positive difference in outcome.

Compare File:Triagemexico.jpg ;)

3) would be instruments at (talk) pages that already have a sort of structure, take disruptive behavior, AFD, third opinions, DYK, Arbcom, sondages and elections and other main page sections. You do not have to reinvent the wheel there, but FLOW lacked - imho - a sort of coverage of the real existing WP . Compare the Radio Yerevan joke: "Is it possible to build real socialism in Armenia?" Armenian Radio answers: "Yes, but better in Georgia".

4) We got an quite interesting opinion poll at the deWP currently, where a group of authors wants to introduce a sort of token system for AfDs. Its seems to be overkill and got a lot of flak, but the basic need for a sort of "like button" respectively bet and wager system is there. I think FLOW should envisage workflows, that allow to setup up WP Tools addressing and measuring and counting credibility and success of authors and their activities in different WP processes. Thats goes beyound AfDs. The DYK entry at the enWP e.g. asks authors to provide quid pro quo reviews, if they come up with candidates for the mainpage. That goes via a AGF rule, but it could be provided automatically.

My last point is about basic instruments. WP still lacks basic tools, lets say a flipchart, a display and a template and a box with basic instruments as you see from File:Moderatorenkoffer.jpg image wise. And a gavel and the power to use it. In the past, w:de:Wikipedia:Projekt_Moderation tried to introduce the role / office of an moderator (German word for Facilitator). That failed e.g. since the community was not willing to accept a further role besides sysops. From my point of view, they failed as well, since any facilitating needs a) Rules of order, will say a set of rules which is about formalities, not about content and b) facilitatating needs basic instruments and c) they did not dare to address the power game. How to get into real nasty discussions involving bunches of idiots talking bullshit and trying to hinder any progress? A facilitator needs some power or a secured place where his or her instruments are being protected formally. I tried to do that via local sections and set of rules being introduced at the start, but any software has to cope with the powers that be as well. ;)

These are my five cents so far. If suitable, copy it to one of the pages mentioned, if you need some enlargement, tell me where to work on. Regards P

Reply to "Rules of order in the actual WP"
Summary by Jdforrester (WMF)

Flow does it for you.

Aryan hindustan (talkcontribs)

How can we sign?

Tropicalkitty (talkcontribs)

Click on the [[ ]] box, and then use four tides to sign.

Jdforrester (WMF) (talkcontribs)

You don't need to sign, and shouldn't. It's part of the point of Flow. :-)

This comment was hidden by Tropicalkitty (history)
Nizil Shah (talkcontribs)

your name is already visible.. :D

Сунприат (talkcontribs)

If a participant makes a change posts in several themes, then how to check these changes?

For example (from 20:02, 5 February to 20:14, 5 February): - How can I check all these "edited"? and it is only in one post.

Trizek (WMF) (talkcontribs)

As you point it, the history page is the best place to see all these changes. Or am I not understanding correctly your question?

Reply to "Vandalism"

How do I indent an reply to a particular post?

Kghbln (talkcontribs)

Is see that people have maganged to actually indent their reply to a particular post within a flow thread. However when I click on reply I end up at the initial level.

He7d3r (talkcontribs)

For posts already saved, there is no way to change the indentation. See phab:T78253.

Kghbln (talkcontribs)

Thanks for noting this. From my past experience with LQT is was quite rarely necessary to relocate a post. So in my opinion not a front burner thing to have if at all.

Sänger (talkcontribs)

This answer to the original post, that should be in the same indentation level as all other answers to the original post, is in another level, while my answer to a post down the thread, that should be one more level indented, as it's an answer to an answer, looks like it's on the same level as the original post.

You've got to plan this indentation for real discussions, not for simple two-post threads. If it's not capable of working something like a real discussion with several dozens of posts, diverse sub-threads, it's useless. It's definitely not a proper replacement of a real talk page. It's just one more step in the facebookisation, read dumbing down, of the WP.

Edith says: This looks like an answer to He7d3r, while it's an answer to Kghbln, because the indentation is fucked up.

Kghbln (talkcontribs)

So why doesn't this post end up indented?

Kghbln (talkcontribs)

Either I am too stupid which may very well be the case or I am missing something. Dunno if I should be sad or grumpy right now.

Sänger (talkcontribs)

Try to indent 1. level

Edith says: Didn't work as expected, was possible before. Something seems to have changed.

Sänger (talkcontribs)

And answer something in-between, let's see how this will be indented.

Edith says: This is at the proper indentation place, the other answers just look like answers to the original posting. definitely a bug.

He7d3r (talkcontribs)

@Sänger: see phab:T93883.

Sänger (talkcontribs)
Next level indentation.
Trying the usual colon to indent, lets see what happens.

Edith says: Lines do indent, the post doesn't. The second line (scnr) was somehow more indented as I did this edit, dunno why.

Kghbln (talkcontribs)

Seems to be bug then. Let's wait for the fix. I production this would be a near fatal bug if one cannot move particular post to a new location like in LQT but even then. Have not figured out how to relocate posts yet. Probably a matter of user rights.

Quiddity (WMF) (talkcontribs)

See the clearest explanation at I CAN HAZ IDNETATION? - which I'll try to condense down into an FAQ sized answer, next week.

Kghbln (talkcontribs)

Ah, now I get it. I guess there is something to it. Since this is breaking with classic as well as LQT talk (10+ years of habit) it will imho indeed be very important to note this change quite prominently. If people do not know this they will definitively bang their heads against a wall like I did this morning. To cut it short: The issue is not how it will be done here, but telling people that it is done differently.

Hhhippo (talkcontribs)

Agreed. I like this indentation system, but it will only work if people understand what's going on, no matter which other systems they're used to. I suggested a very similar system half a year ago, including some visual clues telling the reader which way the conversation 'flows'. Maybe they can be implemented here?

Qdinar (talkcontribs)

i also wrote similar idea suggestion, in 2009-august-26 , for livejournal comments: .

Qdinar (talkcontribs)

and i have posted 2 images with 2 comment thread models in Topic:Senq838us190rqlp 1-2 days ago, and with idea to put threads one behind another, to make comments more compact (instead of, for example, collapsing them). these are that images: File:Compact-comments.png File:Compact-classic-comment-threads.gif.

Qdinar (talkcontribs)

there is a bug report page which asks about design: " With the new indentation model (T88501), should we make any visual design changes to the way indentation looks? " : phab:T88865 , - i have posted there about need of more informative labels.

Sänger (talkcontribs)

There is a difference between answering to the last post in a thread, like I do now, and answering the original post in this thread, and now this big difference is blurred methinks. Just have to test it with another answer to the original post.

Reply to "How do I indent an reply to a particular post?"