Extension talk:DiscussionThreading

great idea --Lleoliveirabr 16:37, 5 April 2007 (UTC)
Very good extension, i always waited for something like this, but i need something with Portuguese BR language. This can be done? The way to install the extension is not good, have to do many modification to MediaWiki core files. Thinking in another way? Hope the development with this extension not be stopped soon. I didn't install this yet, but be sure I'll install when you tell me how to add Portuguese BR language.

re: great idea -- Jpond 03:14, 9 April 2007 (UTC)
Internationalised it this afternoon. You now need to also add the following array after the [en] array into the internationalisation file. I'd also appreciate it if you'd add the modifications on-line to the internationalisation file DiscussionThreading.i18n.php for others to use.

The file you need to change is DiscussionThreading.18n.php (also loaded into your extension directory). You can use this as an example (after changing the text of course).

$wgDiscussionThreadMessages['lang1'] = array(	'replysection' => 'lang1 - tag',	'replysectionhint' => "lang1 - hint",	'threadnewsection' => 'lang1 - new',	'threadnewsectionhint' => "'lang1 - Start a new thread" );

If you could tell me the BR words and phrases, I'd be glad to add them.

Competitive simultaneous edits - last person to save, wins
Peter Blaise asks: Is it subject to the MediaWiki anomaly of, when 2 people have a page open for editing at the same time, the "last person to save, wins"? I think the MediaWiki "last person to save, wins" single page orientation is a significant limit that must be overcome, not just for true discussion thread capability, but to respect the contribution of threshold contributors. The real challenge is for MediaWiki to grow to incorporate email-type real list-serve management for discussions, and perhaps for articles, also. I know many people who would not re-post nor revisit if their typing were "lost" due to bad timing during competitive simultaneous edits, as happened at the demo site for this beta test. However, I honor your pursuit. Perhaps the "first person to save"'s typing is immediately dropped one notch down in the page history and is not lost after all? I've yet to comprehend how history works, so I have a steep learning curve.

Note, however, that I will try this extension in a closed environment of a dozen editors of legal policy, and I hope it will survive for public release of the wiki project. Thank you very much.

Re: Competitive simultaneous edits - last person to save, wins -- Jpond 16:15, 9 April 2007 (UTC)
This is something you should take up with the implementers in the BugZilla space. In the words of the core developers, the standard answer is "don't try and turn MW into something it's not intended to do."

Remember, this functionality is intended to enhance and make usable - not necessarily to supercede exiting functions such as a listserv. Note that the MW developers use listserv's as their primary form of communication and documentation.

As devil's advocate to this line of thinking, my program managers basically went passive agressive on me and stopped using the collaborative discussion function until I added the automated tagging. Too many complaints about no one knew who was talking and who they were discussing with.

Installation Questions
1) it appears that there are 2 modifications to linker.php but they both appear to be the same???

The edit was to two different functions, the line number in the second one should have been 1062, changed --Jpond 12:29, 21 April 2007 (UTC) 2) the require_once line followed by the $wgSectionThreadingOn line would both be in the local setting file

3) the first major section of code would be save to DiscussionThreading.php in extensions directory

4) the second major section of code would be saved to DiscussionThreading.i18n.php in the extensions directory

At this point I am not getting the thread. I must have missed something in the installation. any ideas would be of great help Thanks --Dtsig 04:29, 21 April 2007 (UTC) I also had to do a weird manual flush of the php caching (see new instructions) --Jpond 12:29, 21 April 2007 (UTC)

Added Installation Instructions --Jpond 12:09, 21 April 2007 (UTC)
Sorry - agree the instructions were missing, have been added at:

Extension:DiscussionThread_Article

Installation Success and 3 ideas, --Dtsig 17:30, 25 April 2007 (UTC)

 * Bravo .. worked through first time (well actually I forgot the < in the php tag when defining the international php page and got a bunch of text at the top :-).
 * Here are 3 changes I am thinking of:
 * add tab NEW next to the edit/reply tabs. This would allow the creation of a new section automatically.  Now the user has to EDIT the page
 * Same can be done by pressing the + tab. Agree this is confusing, do you think the new link would resolve? --Jpond 15:59, 25 April 2007 (UTC)
 * Yeah. One of the things we are trying to do is remove as much of the markup as possible (not really possible but :).  So in this case the New tab would create a new == Comment Title == level item.  Similar to that mentioned below about creating a new discussion.--Dtsig 17:30, 25 April 2007 (UTC)
 * a popup box for entering text. might make the users a bit happier not editing in all that goopy html/MW stuff
 * Interesting, but a lot of work. --Jpond 15:59, 25 April 2007 (UTC)
 * If threading is on, instead of a blank page create a first header. edit/reply never show until there is a 1st level item (or so it seems).
 * The way I read this is the first time someone hits the 'discussion' tab, it would automagically pop into the create section (e.g., same as + tab).--Jpond 15:59, 25 April 2007 (UTC)
 * Yes, with the top level already there. Something like == Comment Name == This makes sure that the top level is there.  As I mentioned, the edit/reply tabs don't show up unless there is at least header tag. Possibly something like this?

$wgHooks['EditFormPreloadText'][] = 'newPage'; function newPage(&$text) {	$wnew = $_GET['new'] if ($wnew==1) { $temp1 ="== Comment Title Here =="; $text=$temp1; }	return true; } --Dtsig 17:58, 25 April 2007 (UTC)

Looking at this --Jpond 18:07, 25 April 2007 (UTC)
Summary: I'm going to be looking at this to see if possible:
 * 1) First Click on Discussion to go into '+' (add section) mode
 * 2) Modify header bar to include 'new' link
 * 3) Will not use pop-ups (too many browser variables), but will investigate using the '+' (add section) form for replies as well as new.  The downside here is that the text to which the responder is refering will not be visible.  No guarantees on this one.

No schedule on this, I'm really tied up on some other things for the next couple of weeks - will not be before the release of 1.10.

The above will require additional patches - which really isn't desireable.
 * Cool .. i might look at putting the text into the page automatically (at least on a new page). Will pass on any results --Dtsig 18:53, 25 April 2007 (UTC)

Requested Enhancements Implemented --Jpond 03:33, 15 May 2007 (UTC)

 * 1) First Edit of Discussion now goes into add comment mode (heading + text)
 * 2) Header bars now have [new][edit][reply], the 'new' link goes into add comment mode
 * 3) I'm not going to try and implement pop-ups - just too much effort
 * 4) modifications to EditPage.php no longer required - implemented in hooks.  Linker.php still needs minor patching

Conflict with another extension --Dtsig 15:39, 11 May 2007 (UTC)
We have been having problems getting Extension:SelectCategory extension to work when it finally dawned on me that there must be a conflict somewhere. So I started turning off all extensions and trying one at a time with SelectCategory. This is the only one that caused a conflict. Would it be possible for you to look into this? I have noted on the other extension the same information and would appreciate it if the two of you could play nicely . Let me know of any info, setup or testing needed. Thanks

Re:Conflict with another extension Extension:SelectCategory --Jpond 16:42, 11 May 2007 (UTC)
This pointed out two problems, there was not a 'return (true)' statement when the discussion threading was disabled (though I don't think this was causing the problem. We think the problem may actually be a conflict somewhere in the 'wfDebug' function used for debugging MediaWiki.  In reality, this isn't needed in production, so both lines should have been removed anyway - and this seemed to fix the problem.  On another note, this function is very commonly used and may show up somewhere completely independently of DiscussionThreading.

Re:Conflict with another extension Extension:SelectCategory --Dtsig 16:50, 11 May 2007 (UTC)
After testing as we suggested it does appear the the problem comes from the wfDebug Thanks again for the quick response to the problem. DTSig