Extension:QWikiRemarks

Concept and Goals
'''This is a proposed extension that I have not yet completed. Any assistance, contributions or suggestions would be greatly appreciated.''' --Bakerq 19:24, 25 November 2006 (UTC)

The idea behind QWikiRemarks is to create a threaded comment system for MW that does not violate the concepts and philosophy of a Wiki.

The idea that everyone can edit any page on a Wiki is great for collaboration and refinement of ideas, but many people are afraid to touch another person's text or learn a new commenting system. Most people simply want to type their thoughts into a text box and have it appear at the bottom of a page of content. And that's understandable, people shouldn't need to learn an entirely new web construct to post a comment. However, most solutions I've seen that allow simple, threaded comments usually come in the form of a separate forum site or, at the very least, database schemes that exist outside of the regular Wiki database.

I don't need a fully featured forum package with subscription service. What I do need would satisfy the following requirements:
 * Exist entirely within the framework of the MediaWiki by:
 * Saving all comments on their own page (and thus their own history)
 * Save them all in their own Namespace to remove them from casual searches
 * Save all comments underneath the User's talk page
 * Still allow anyone to edit any page (keeping with Wiki philosophy), but:
 * Hide/obfuscate the source of the comments to prevent casual vandalism
 * Alert the user when their own comments have been altered
 * Provide structures for Quoting comments
 * Fully support Wiki Highlighting

What's wrong with LiquidThreads
LiquidThreads is very similar to what I'd like to do, but LT is designed for a different task. LT is a proposal to implement threaded comments as a replacement for the Talk page system currently in MediaWiki, and I wholly support that endeavor! QWikiRemarks, however, is not intended to replace the Talk System, but more to compliment it.

I see the Talk page as a location where contributors and editors can collaborate on the construction of a page or article - this is behind-the-scenes activity, it is content about the article, not content about the article's content. The QWikiRemarks comments would fill that role. Simple, easy-to-use, quickly-throw-in-my-two-cents comment system that everyone familiar with blogs would instantly know how to use. Also, it would be a somewhat limited comment system which would in no way replace a fully featured forum. This cuts down on its complexity but not needing all the bells and whistles of a fully-featured forum. Lastly, it is designed to work completely within the existing framework of MediaWiki with as little database modification as possible.

The Proposal
Articles would be able to use the following tags to set permissions on commenting:
 * :Do not display comment framework
 * :Prohibit anonymous comments

The extension would provide all framework for listing an article's comments at the bottom of the article. If a user is logged in and comments are allowed, a blank textarea and submit button would be provided for quick and easy commenting.

Comments to an article would be saved as a subpage in the QWikiRemarks Namespace, under the following convention: QWikiRemarks_Talk:Name_of_Article/Name_of_user/TimeStamp or QWikiRemarks:Name_of_Article/Name_of_user/TimeStamp

Question
And there lies the first question to solve. Should the syntax be Name_of_article/Username/Timestamp or should it be Username/Name_of_article/Timestamp?

Basically, it comes down to wondering which would be easier to search by.

Stylistically, and in keeping with the MediaWiki philosophy, each comment should be stored under the User's own page (Username/Name_of_article/Timestamp). However, pulling up a page an article and finding all of its corresponding comments could be difficult. I'm not sure yet if it is possible to do a search (even at the code level) for all pages that match "*/ArticleName/*". If this sort of a search is easily accomplished, then this would be the preferred choice. Otherwise, the comments would have to be saved as subpages under the artcle itself (Name_of_article/Username/Timestamp) and the built-in Prefix Search would be used to find all related comments.

Dual Nodes?
It seems as though I keep coming to the possibility of hosting the comment in TWO locations. Firstly being in the QWikiRemark namespace under QWikiRemark:ArticleName/UserName/Timestamp and again under User_talk:Username/Remarks/ArticleName/TimeStamp. This is, obviously, a terrible design, but I'm running into a brick wall trying to come up with another method of listing all comments by a particular user without creating and maintaining a seperate database which itself would be subject to data corruption. One of the goals of this extension is to exist entirely within the current framework without adding new tables.

Locked, Moved or Deleted Articles
If an article is locked, its comments should be locked as well. What about deleted articles? Moved articles should move their respective comments as well.

HTML Code and Framework
A number of HTML code snippets would be needed to construct the framework that is sent to the user when an article is displayed.
 * QWikiRemarks_AllComments_Wrapper:This would be the HTML that encapsulates the entire comment thread for the aticle. It could contain text stating that the following comments are not part of the original article, or have CSS styles applied to visually seperate it from the article body.  An HTML-commented keyword would be replaced with the thread of comments:
 * An extremely simple example would be:
 * 
 * 


 * QWikiRemarks_Comment_Wrapper:This block of HTML would be wrapped around each individual comment. It would, in turn, support the following keywords (each nested in an HTML comment):
 * A simple example would be:
 * A simple example would be:
 * A simple example would be:
 * A simple example would be:
 * A simple example would be:

On, noted:

These HTML blocks will be saved in the System Messages (MediaWiki Namespace). Doing so would allow for internationalization and sidestep the use of custom templates. The default values will be provided by the module.