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.

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

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

Users should confirm they want to leave the page without saving

Guycn2 (talkcontribs)

Hello. I have just written a message using Flow.

Accidentally, I opened a link on the same tab, and consequently my entire message was lost!!

Even after I clicked the "back" button on my browser, I couldn't see the message I had written.

This happened even though the option Warn me when I leave an edit page with unsaved changes on my preferences IS checked!

To avoid such cases, users should be prompted if they write a message and try to leave the page without saving. I hope this talk page is the right place for this request.

Trizek (WMF) (talkcontribs)


Thank you for your feedback, this is the right place for it.

Some people already requested that feature. I'm going to ask developers if they can fix it soon.

Guycn2 (talkcontribs)

Thank you :)

Reply to "Users should confirm they want to leave the page without saving"

Beta features: enable, disable, enable doesn't seem to work

Dereckson (talkcontribs)

@Lionel Scheepmans reports on fr.wikipedia to have enabled, then disabled Flow. The wikitext archived talk page was successfully restored. But then, they toggled on the beta preference again. Nothing happens, while the user expected to get back Flow.

Lionel Scheepmans (talkcontribs)

See also this page :

And this one :

I've also remove {{Page de discussion wikitexte convertie en Flow|archive=Discussion utilisateur:Lionel Scheepmans/Flow Archive 1|{{Page de discussion wikitexte convertie en Flow|archive=Discussion utilisateur:Lionel Scheepmans/Flow Archive 1|date=2016-06-18}}date=2016-06-18}} from my talkpage after disabled Flow.

Reply to "Beta features: enable, disable, enable doesn't seem to work"

How to move a topic to another discussion?

Dvorapa (talkcontribs)

Any option?

Quiddity (WMF) (talkcontribs)

Not at the moment. phab:T88140 tracks that feature.

Reply to "How to move a topic to another discussion?"
Stefahn (talkcontribs)

I wanted to search for a specific term on Skin talk:Chameleon and didn't find a search option. I ended up here reading that implementing the search option is postponed. Is there a plan when it will be available?

For me it's essential to have a search option.

PS: I tried but it doesn't seem to find content that was posted in Flow...

Tar Lócesilion (talkcontribs)

You're not alone. Later this year, there will be a satisfaction survey. Keep it in mind and take part.

Trizek (WMF) (talkcontribs)

Special:Search does not includes Flow topics. That's a big issue and, unfortunately, that's something which requires a lot of resources to be integrated and maintained. As Tar wrote, we are going to have a survey (I hope soon), in which search is included as a possible priority.

Reply to "Search on 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)

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)

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)