'''Feature Discussion or Comment pages''' This page is talking about a possible feature for MoinMoin to have one ore more pages for discussion and/or comments. While in many cases it is fine or even preferable to have discussions about a page's contents ''on'' the page itself, it may sometimes be nice to have comments/discussion on seperated page(s). This is especially true for write protected pages. The question is how should we implement this feature in MoinMoin? <> ||Please feel free to refactor this page. Be careful where to add additional content. Always keep in mind that each page needs to be kept readable! A good guide is to always start refactoring your own contributions. If everybody does that we get a much better overview.|| ||For the rest of this document I suggest to use the term '''"discussion"''' to indicate something like '''"discussion, comment or other related text or page"''' to keep the language used more concise. Maybe also to avoid confusion with the '## '-''"comments"'' that are possible within the raw text of a page anyway.|| ---- As some other tips/ideas have come up, it's probably good to keep an open mind towards a mechanism for 'discussions' that is ''not necessarily'' based on seperate pages, but might have discussions inline and tagged as such so that a 'display/parser layer' can ''optionally'' show these tagged sections depending on the user's choice (button in theme or setting in preferences or such). If discussions are implemented as seperate pages, it should also be trivial to display an associated (sub)page with discussions as an 'included page' so that those who want it can still have the discussion visible directly on the 'main page'. == How other Wikis do it == * MediaWiki uses one discussion page per page. == General Considerations == * Not just 1:1 relations - Maybe it would be good to consider the fact that some discussions might actually be relevant to more than one page (and that Wikimedia's 1:1 relation between articles and discussions doesn't really provide for this). * Take I18n into account - The simplest case being that if for example it would be decided to use some 'standard' subpage for discussions (like maybe {{{/PageComments}}}) it might be better to have the 'standard' name for such a page configurable as a variable somewhere. Of course, supporting ''multi-lingual'' wikis would probably require some more thought than just one variable name. == Workarounds == * Make Sub Pages * Discussion Tree * Have pages with ending `Discussion` to show that people should discuss there * Link to pages and tell people that they should discuss on the linked page. * Use a theme that has a discussion page implemented (Monobook?) * Make a category {{{CategoryDiscussionPage}}} * ''I suppose everything (even n:n relations) could be handled by Category markers, but that system would also break real easily as soon as someone forgets to add any/all the appropriate marker(s) in a page - but it's a start'' -- Arp * Use [[MacroMarket/PageComment2|PageComment2]] macro to present users with an 'Add Comment' box that allows them to write their comment and then submit it to have their comment appended to the bottom of the page. * The problem with this was(is?) that in many cases one wouldn't want comments cluttering the (bottom of) a neat documentation page. However, when implementing seperate discussion pages it might still be a good idea to have a similar add-on for those who feel it's needed. see more below ---- === Sub Pages === Depending on the implementation one side effect ''might be'' that now some way would be needed to distinguish between 'main pages' (that can have a discussion subpage) and such pages that can't have discussions associated (like maybe the discussion pages themselves). This could possibly be as trivial as adding a {{{CategoryDiscussion}}} or something to such page or meta data to the same effect and not allowing creation subpages for pages with such an identifier in it. Pros: * Can be implemented as a mere guideline for a quick start. * As a first step a simple link to {{{/PageComments}}} can be added at the top/bottom of the page contents in the template. * As a second step it should be fairly easy to support this in code and themes to make it more accessible to novice users. * Throwing out all the discussions before redistribution means simply ignoring all {{{"*/PageComments"}}} pages. Cons * It seems some people don't like subpages. One reason mentioned is that they can make renaming a hassle (to me it seems the {{{RenamePage}}} action could fairly easily be adapted to a {{{'RenameTree'}}} for such purpose??) * n:n Relations are not straightforward. A simple first step could be to also have a standard {{{/RelatedPages}}} or {{{/DiscussionIndex}}} subpage that takes care of linking to the 'n' related discussions (and these could have links back), or to simply have the 'n' links in the {{{/PageComments}}} page. * If discussion pages are created that are relevant to more than one 'main content' page there is no clearly defined location for such discussion other than maybe it being 'hosted' by one of the pages it applies to. * I18n and support for multi-lingual wikis is not straight forward (what name(s) to use for the subpage?). ---- Without pinning anything down on exact names or having only one standard subpage name or various - how useful do you think this method could be? * It does the trick for what I need to do for now (works mostly as a template supported guideline), and I feel confident I'll get it integrated with the user interface quite neatly soon enough. Although my system will eventually need to be more complex with translated versions of a document, probably in subpages too, each with their own (translation)discussion page attached. Of course these would also be related to some general discussion page about the main document (hence support for n:n relations would be sort of neat). -- ArpKruithof === Discussion Tree === Another solution that might be considered is the creation of a 'Discussions' tree of subpages that more or less copies the wikis structure in a seperate tree with discussion pages for every 'real' page in the wiki that needs one. For the Moin``Master pages this might result in a tree like: {{{Discussions/HelpOnAdministration Discussions/HelpForBeginners Discussions/HelpOnInstalling Discussions/HelpOnInstalling/MinimalWiki}}} Links to these discussion pages ''could'' be worked into the page contents (easy but ugly/unwanted) or maybe into standard themes or so (if a page with the same name exists under the /Discussion tree display a link to it) Pros: * Can be implemented as a mere guideline for a quick start. * As a first step a simple link to {{{Discussions/TheNameOfThisPage}}} can be added to the page contents in the template. * As a second step it should be fairly easy to support this in code and themes to make it more accessible to novice users. * Filtering out the discussions simply means throwing out that one tree {{{Discussions}}} (all files named "Discussions/*") * The {{{Discussions}}} tree would also be logical place for pages that contain discussions relevant to more than one 'main content' page (1:n relations). Cons: * n:n Relations are not straightforward. A simple first step could be to have the page {{{Discussions/TheNameOfThisPage}}} contain the 'n' links to (other) related discussions. * If discussion pages are created that are relevant to more than one 'main content' page there is no clearly defined name for it other than maybe the name of one of the pages it applies to. But at least people will have a general idea where to create (or look for) such pages. * I18n and multi-lingual wikis require some extra thought (variables?) on naming the {{{Discussions/*}}} tree. As the names of the subpages in the tree follow the original page names the issue is probably only with the base name. ---- Comments: * It 'feels' a bit awkward to have the discussion page(s) 'somewhere else', but it seems to be a valid possibility. If others would feel strongly that this is the best way to go I would probably eventually rework my system to adhere to that standard. The best reason for using this I could think of now would be that it offers a more logical location for discussions that don't necessarily relate to one specific page (the n:n thingy). -- ArpKruithof == Possible Solutions == === With NewPage Macro === It is not quite difficult to do it by the NewPage macro. {{{ if parent == '@SELF': parent = f.page.page_name }}} is added behind the lines for @ME then you can get with `[[NewPage(template,Discussion,@SELF,Discussion)]]` a button labled Discussion which does create on the page where it is called a subpage `/Discussion`. This button could be placed where you want on the page or it could be integrated into the action menu. -- ReimarBauer [[DateTime(2006-08-23T20:20:21Z)]] And here we have an example for an action macro for a Discussion page of a page -- ReimarBauer <> {{attachment:Discussion.py}} === Meta Data to find Discussion Pages === In order to create an n:1 relationship for pages:discussion, meta-tags or maybe macros could be used in the raw text of a page to indicate where the discussion for the page (or section?) takes place, and have a preprocessor and themed links point to the appropriate discussion - similar to the way this is solved for the MonthCalendar macro. This would also alow for a series of related pages with one introduction page, where the discussion could be hosted at the intro page, and place {{{[[DiscussAt(Intro)]]}}} (or whatever) on each one of the related pages. Then clicking on the Discussion link from any of the related pages will take me to the discussion page related to Intro ({{{Discussions/Intro}}} or {{{Intro/PageDiscussion}}} or whatever). This may be challenging to render correctly because when directed to the discussion page, it would be good to know 1st that this is "Intro's Discussion" page and 2nd a link to return to the page of origin would be wanted. Perhaps linking could be rendered as tabs or maybe a dropdown list or pop up box with all links to 'related pages' - being pages that link to a page with '{{{discusssion}}}-tags' and/or pages that the current page links to itself, and/or maybe even a complete list of all te subpages of the current page. Pros: * No fixed names/locations for the discussion would have to be decided on * Hence easy I18n * Easy n:n realations possible Cons: * Definitely requires integrations into themes and supporting code * Not easy to start implementing without above support in place * Filtering out the (links to) discussions before redistribution not very straight forward ---- Comments: * Personally it seems to me this would be a very flexible system that could also provide hooks for other creative ideas for interlinking pages. I had been thinking about creating something to work a automagically created dropdown list/menu with all the subpages to a page into the theme/user interface and this would combine neatly with such an effort. -- ArpKruithof === Meta Data and Inline Discussion Sections === Having my attention drawn to the discussion on MetaDataInMoin it seems that some of the ideas presented there might very well be used to 'tag' certain sections of a page's raw text as 'discussion' (or whatever) by using either the discussed meta data tags or XML-like tags (maybe DocBook?). The parser could then either display these sections with the main content (possibly in various ways) or suppress them altogether. I can't say anything sensible about this option until I've found time to play with it. But maybe these statements are valid anyway: Pros: * All-in-one: No clutter of distributed pages is needed to accomodate the discussion. * Discussion sections can be displayed very near the 'main content' that they apply to. * Appropriate tagging would easily allow for various 'classes' of comments/discussion or other meta-content to be displayed or not. * I18n and multi-lingual pages are better supported as long as having 'english' tag names is not considdered to be a problem - assuming these will be invisible when the page/discussion is dispayed. Cons: * All-in-one: Filtering the discussions out could be more cumbersome. * All-in-one: The raw text will probably be much more cluttered with tags and discussion text, which will make editting harder for novices (I'd say it would almost ''require'' a 'section editting' mechanism to be implemented as well). * n:n Relations between discussions and 'main content' sections/pages seem more problematic?! ---- Comments: * I'm certainly going to play with this because I like the idea of tagging to add more meta-structure to the contents and maybe using this for better 'printable' versions of the pages too. If it turns out that the system is very flexible I might be tempted to try and weave discussions and section editting into this to so users have a choice of displaying discussions close to their relevant 'main content' sections, or at the bottom of the page (or wherever) or not at all. But it might still have the discussion text in seperate files/pages (as includes)? -- ArpKruithof === Extending "More Actions" Menu === Mayby for now just include the patch posted on the MoinMoin users mailing list (http://permalink.gmane.org/gmane.comp.web.wiki.moin.general/4016) that adds a ''Comment'' item to the 'More Actions' menu, in order to make it easier for users to create a comment page as a corresponding subpage. I guess both, the ''Comment'' item in the menu, and the name of the subpage, could be localised via the system messages machanism, e.g. ''Diskussion'' and ''!DiskussionsSeite'' in German. However, I'ld prefer to see this solved more like it is done in MediaWiki (no, not everything in MediaWiki is bad...), i.e. a link to a "Comments" page on every page by default, maybe as a simple link like "Attachments", or as a tab like "!FindPage". -- MartinBayer <> <> === TwinPages, SisterSites, ... === While discussing on #moin-dev (2006-12-02) we maybe found a completely different and more general approach to solving the requirements above: * (./) separation - it is on another wiki. * (./) no need to exclude it for moin export dump, for example. * (./) no TitleIndex pollution with comment sub pages * (./) no i18n problem - the pagename is just the same on the original wiki and the comments wiki. Just the interwiki name is different. * (./) if 1:1 is not enough, you can add other discussion pages and use wiki or interwiki links to refer to them. A page on MoinMaster wiki could list some TwinPage on MoinMasterComments wiki where users can put comments. With nice integration into theme, this should solve quite some problems and even open new possibilities, because this is a general mechanism and not limited to comments. To show a link to the comment page, we either need some sort of "wanted sistersite" (so it display a link to that site even if the page of the same name does not exist yet) or special theme support. Links: * FeatureRequests/SisterSites SisterServerCode TwinPages (AdoptedPages) * http://www.usemod.org/cgi-bin/mb.pl?MetaWiki * http://c2.com/cgi/wiki?SisterSites * http://www.usemod.org/cgi-bin/mb.pl?TwinPages * MacroMarket/EmbedWikiPage shows a way to embed a page from another wiki in a page In my humble opinion, this means to prefer programmers' interests over users' interests (again). This here is likely to be the most wanted feature in MoinMoin (the second most is section editing). Please don't solve it in a way that is most easy for the developers to implement, but in a way that makes MoinMoin gaining ground in usability concerns and in competition with other wiki engines (esp. MediaWiki).<
>Discussion pages and the pages they are referring to need to be kept together: a discussion page will often provide information why something is or is not on the main page, or why something is wanted or not on the main page, or why something is put in that way and not in another, and so on. Both, the main page and its discussion page, need to be seen as an informational unit.<
>Thus, it would ''not'' be an advantage to have the discussion pages in an other wiki, and I'm not only thinking of all those who are not running a wiki farm, but need a solution that works "out of the box" in one single wiki. Also, it would not be an advantage to have the discussions not in an export dump or backup, as this might strip off usefull information from the wiki's content seen as the archivement of an editing community. As far as indices are concerned, one could think of a solution similar to that used for the template and category pages. And last but not least it would by any means break usability if links (WikiName``s) on comment pages leaded to other pages or even to nowhere as they do on the corresponding main page, and vice versa. To explain the users the proper use of InterWiki links for comments would be as difficult as it is now to explain the proper use of subpages for the same scope. In view of usability, I therefore consider this a non-solution. -- MartinBayer <> I think you are mistaken. Fistly, this is not about "cloning" MediaWiki, it is about implementing something the user community wishes. Secondly, even if this meant to copy from others, it would be insensate to refuse a solution only because a competitor invented it before us. (Shame on us we did not think about it first!) Thirdly, Wikipedia is not a special use case of its own, it is just an other wiki from the type "knowledge management". And in almost any knowledge management wiki you want to show only up-to-date content, proof-read by the editor community, and not all the myths that might exist on the topic. That's why you separate the facts from the discussion.<
>I could not disagree more with you saying that this is against the wiki principle. Having "clean" pages does not mean not having a continuos reviewing process - far from it! They are the result of the efforts of the wiki's editor community. If you don't want to show the results in the first place, maybe a Forum is more suitable for you?<
>So, the only question that remains is: do we want discussion pages or don't we (it is not: do we want to clone MediaWiki)? If we want discussion pages - and this is what I think our users do -, I plea for a solution that leaves nothing to be desired for usability.<
>I yet again remind the existence of the Dialogue principles, Part 10 of ISO 9241 ''Ergonomic requirements for office work with visual display terminals'', which '''require''' a dialogue system to conform to suitability for the task (the dialogue should be suitable for the user's task and skill level), self-descriptiveness (the dialogue should make it clear what the user should do next), conformity with user expectations (it should be consistent), and suitability for learning (it should support the user to learn the dialogue system). And I doubt if splitting contents from the discussion related to it is a good solution for means of usability: I already mentioned the efforts that will have to be done to train the users on the proper use of InterWiki links, and I already mentioned the overhaed work that all (volunteer) administrators will have for setting up, maintaining, and backing up two wikis instead of one. -- MartinBayer <> === CommentWiki === I implemented WikiName: syntax in 1.6. Before, you had to use `WikiName:PageName` to get a full interwiki link, but in 1.6, if you just omit the `PageName`, it will take you to the same pagename in the other wiki. So having comments just means to have a `CommentWiki:` link in the navibar. :) Can you show that new functionality on the test wiki. I believe it does teleport me to the commentwiki. If so I do like to add a config var to use something like a refactored MacroMarket/EmbedWikiPage to get the page rendered in the actual wiki so I could use acls, theme, navigation elements, macros and parsers of the current wiki. Editing the page needs to be done on the commentwiki, previewing on the currentwiki. -- ReimarBauer <> Not yet (have to refactor some navibar code first). But if you click the comment link, it will take you to the comment wiki. There could be the same type of link to bring you back to the content wiki. Teleporting to the other wiki is not always a problem... Not in a farm where you have CommonUserAccounts. Or? Might be a problem for true SisterSites on remote machines where you have no user account or on a farm where you don't have CommonUserAccounts.. A config var for adopting/embedding a page (see AdoptedPages) or just interwiki-linking it (see SisterSites and TwinPages) would be very nice... Use wiki rpc v3 'getPage', 'putPage' for AdoptedPages? (See my thoughts on having a new version 3 of wiki rpc at WikiRpc) I like these ideas above very, very much. We might need this general linking concept also for AccessibleMoin. I think it shouldn't be a problem to integrate these ideas of SisterSites in Reimar's marvelous patch above for generally being able to have some supplement page to a wikipage ('Discussion', 'Image and Mediasources', 'To Dos', 'Iso Doc Remarks', 'Notes'...). The idea is: if you put u'!CommentWiki:' instead of u'!DiscussionTemplate' in supplementation_page_template you can change the behaviour of supplement pages in Moin. Maybe even it should be possible to provide a list of interwiki links in supplementation_page_template to have more than one sistersite only. Instead of a simple link you now get a drop-down-list-box in the theme to choose "%s on %s" % (supplementation_page_name, supplementation_page_template[0]) and so on... We need onyl to remove the ':' at the end of supplementation_page_template[0] for proper display.. == Do we need this at all? == Please indicate how you feel about having an (optional) system to NOT display discussions on a 'main content' page. * I might still use the wiki but I ''really'' '''do''' need to use some workaround for this. -- ArpKruithof * I really want this. -- AlexanderChemeris * It's pretty critical. Our users won't be arsed to do that manually, which means discussion won't take place. Which means the wiki will be useless. -- [[kamagurka]] <> * I really want this, too. -- DavidMontgomery ---- Please indicate how important it would be to you if we could agree on a method or even just a guideline (soon) so you can start implementing it in the knowledge others will use the same method and tools and enhancements can be developed together. * I'll get it done on my own eventually, but if I put effort into it I'd much rather work on something others would want to use too -- ArpKruithof * There '''must''' be standard way. -- AlexanderChemeris * Before I roll my own I'll deploy another wiki engine. -- [[kamagurka]] <> * Far better to be standard, but I won't be troubled to have to do something on my own using subpages. -- DavidMontgomery ---- Please indicate how important it would be to you to be able to (optionally) display discussions fragments near the section of 'main content' that they discuss * 5 - If a page needs to be displayed cleanly (optionally), I can live very well with discussions on a seperate page, but if it could be realized to have discussions 'blend in' or 'suppressed' by a simple click that would be brilliant too. -- ArpKruithof * 8 - Great idea. May be use something like sidenotes? * 7 - I never actually thought about this, but it would be awesome. -- [[kamagurka]] <> * 3 - Not important to me, although I can see some benefit. -- DavidMontgomery == Where to integrate it into the UI == Reimar, thank you for your macro. I think it could be integrated into the UI on different places: || '''1''' || {{attachment:proposal_buttom.png}} || calling the macro from a button in the main menu line || || '''2''' || {{attachment:proposal_tab.png}} || extending the modern theme in order to have an additional tab || || '''3''' || {{attachment:proposal_menu.png}} || adding the macro to the "more actions" menu || || '''4''' || {{attachment:proposal_item.png}} || putting it into the main menu line, next to "attachments", "info", and so on || I would prefer clearly solution #4, as it is most consitent to the existing concepts of our UI. Solution #3 means to hide it from the user, and solution #1 is just ugly. Solution #2 is emulating the MediaWiki, or !MonoBook theme, but less consistent than solution #4, as all other tabs are leading to (main) pages, not to (information) pages related to the current page (like "attachment", "info", and so on). Now the tricky part: * Which of the solutions drafted above could be done with your macro? Without additional work it is now added to the more actions menu (3). If you like to put it in the main menu line (editbar) (4) the themes needs to be changed and a switch added to `wikiconfig.py` that it is on default disabled. A similiar entry to `__init__.py` as for `infoLink` needs to be added and then called in the `editbarItems` function. e.g. {{{ def discussionLink(self, page): """ discussion for a page """ _ = self.request.getText return page.link_to(self.request, text=_('Discussion', formatted=False), querystr={'action': 'Discussion'}, id='discussion', rel='nofollow') }}} May be we should add a feature request about a configurable editbar, that would avoid a switch. ''A bird in the hand is worth two in the bush.'' I suggest to choose design #4, and to extend the themes, and the wikiconfig, both, instead of waiting for a configurable editbar to come. And I suggest to do this already for the 1.6, as this feature is something where MoinMoin could gain ground in its competition with MediaWiki. Users like discussion (or: comment) pages, and they want them in MoinMoin, too. Extending the navibar(2) with an addtional tab means creating a page where a macro is executed if the user clicks on that page. This action macro can't be used for that and the NewPage macro would create without the page information from which page it is called from the discussion page on the wrong page. So (2) can't be solved this way. For (1) it is bad to place a button on a page because someone hitting enter executes this button. We should avoid this confusion. In principle it is a differnt definition in `discussionLink` necessary for that. <
> <
> If it is configurable to have that entry or not I would prefer an editbar entry. * When clicking on the link (or selecting the item from the menu or whatever), will the user be lead directly to the discussion page, if it already exists, and otherwise be promted to create such a page? (IOW, does it work just like a link to a wiki page?) (./) he will get the page in `action=edit` mode. So, how could someone ''just read'' the discussions/ comments for a page? * How about localization? You see, I've already called it `Diskussion` (German), in English it should read `discussion` and so on. localization should not be a problem that needs to be done the same way as for `DeletePage` in `__init__.py` search for `DeletePage': _('Delete Page', formatted=False),`. Thanks, -- MartinBayer <> -- ReimarBauer <> == Patch == ##based on 1514:b3665210e63e the complete changeset with localisation ##inline:complete_discussion_patch.txt I do think there are further changes to the theme needed and/or to the function discussion.py. E.g. we can handle it in that way that in the theme the first five lines of the discussion page is shown with a link to get the whole discussion page. And then the user can use the normal Edit action or Discussion to add some sentences. Something like ''more ... '' will than link to the Discussion page. IMHO these "more..." things show bad taste. Plus this would privilege the fist entry on the discussion page, which not neccessarily is the most important. Plus we already have something like that, see MacroMarket/PageComment2. If it's not wanted to see some discussion entries below the actual page the discussion action could be changed to switch only without `action=edit` to the discussion page and the user who want's to edit could choose the edit action. If the page does not exists a template could used to create the page. -- ReimarBauer <> I would prefer that, because in edit mode you can't read the page's contents (only in the editor). Presumely users don't want only to write comments, but also to read the comments of other users. However, if we do it that way, what difference rests between this solution and a simple link to `["./discussion"]`? -- MartinBayer <> The link is enough. Then the user could decide the common way to edit or to go back to the main page. There are some more things which I have to change in this patch after some discussions with ThomasWaldmann on IRC. -- ReimarBauer <> based on 1515:b3a47164c22a a new patch for this feature -- ReimarBauer <> {{attachment:supplementation_page_patch.txt}} I will do some more changes on this patch the next time (may be in two weeks). * it will be changed to be not configurable to choose the name of the supplementation page. This would be done later. At the moment it does make this patch to complicated and I believe we will later on do have a better idea to implement different names or more pages. Step by step ;-) * I will add a new var to multiconfig.py something like ´enable_supplementation_page = False´ so it could be used to setup wikis different. * I will add a new pragma var too. So it could be en/disable from a user for a page too I do need a vote from you now for the first initial name of that page: ||Comment|| :-) || ||Discussion|| :-) || -- ReimarBauer <> I would prefer the name discussion page. This is well know to most wiki users due to some well known wikiengine. I don't think we should introduce extra complexity and usability problems. Just think of the discussion about calling history info! See UsabilityObservation/HowToGetHistory . There are certain grown, inofficial standards, and we should meet them, I think. -- OliverSiemoneit <> I don't see a problem to name it discussion if the main page is always opened to edit but if not a comment is semantic the better solution. while it is not important for the solution let's see the votes. if discussion is the more known word it is easy to change. -- ReimarBauer <> == New Patch for 1.6 dev == {{attachment:supplementation_20061202_patch.txt}} === Documentation === From within wikiconfig it could be controlled. The default configuration given from multiconfig is: ||supplementation_page || False|| ||supplementation_page_name || u'Discussion'|| ||supplementation_page_template || u'!DiscussionTemplate'|| From within a page a user could control it if he sets a pragma on that page. ||#pragma supplementation-page off|| disables the link to the supplementation_page_name for this page|| ||#pragma supplementation-page on|| enables the link to the supplementation_page_name for this page|| If it is enabled it looks like: {{attachment:edit_bar.png}} -- ReimarBauer <> == Old Discussion == Although I've worked most of this into the above text I'll leave these original discussions to still react to or as a reference for now... ---- 1. In order to create an n:1 relationship for pages:discussion, we could add a macro/meta-tag/preprocessor/?? to a page to indicate where the discussion for the page takes place, and have the themed links point to the appropriate discussion - similar to the way this is solved for the MonthCalendar macro. Thus, my wiki may have a series of related pages with one introduction page - I would host the discussion at the intro page, and place {{{[[DiscussAt(Intro)]]}}} (or whatever) on each one of the related pages. Then clicking on the Discussion link from any of the related pages will take me to the discussion page related to Intro ({{{Discussions/Intro}}} or {{{Intro/PageDiscussion}}} or whatever). This may be challenging to render correctly because when I land on the discussion page, I would want to know 1st that I'm on "Intro's Discussion" page and 2nd that I can easily return to the page I came from - perhaps these could be rendered as tabs or similar. a. Another similar solution would be to automatically host discussions on the parent page (I actually like subpages ;-)). --[[http://veewiki.com/IanEpperson|Ian Epperson]] ''Hi Ian, thanks for the contribution! I think this variant was definitely missing from the above list so I reworked it a bit and gave it a place there and added a vote/comment header for it. Please do feel free to:'' * ''Rework that (or any other) text in the proposals section.'' * ''Also leave your vote/comments on any of the items prepared for that (or add your own).'' --Arp ---- 1. pages can be marked as discussion pages and you can tell a wiki page what discussion page should be used. Why that? Because in Wikipedia there is the problem that a 1:1 solution for discussion means that related discussion are discussed on seperated pages. but discussion really is tending to be for more than one page. ''I very much like the idea of having a n:n relation between possible 'main' and 'discussion' pages - excellent suggestion! At the same time I'm a bit worried that it would make the system less transparent/straigtforward to use (to find all related discussionnpages with a page and vice versa) so it would probably really need software support within the moin code as oposed to being just a guideline or so - but surely something to keep in mind while thinking about solutions'' -- ArpKruithof == General Discussion == MartinBayer reverted my two hours work where I tried to condense the discussion that has gotten more and more messy. See also his comments on my homepage: ThiloPfennig. I do not agree that this is a discussion page. I think this is a FeatureRequest that needs to go from ThreadMode to DiscussionMode. This is not a page for 1-2 people who actually still know where what belongs. We need overview and not the same arguments in every place. I especially diagree very much disagree to tell people to add their comments where they like without considering the effects. I have moved Martins comments to another place, although I found it to me more general. I would very much appreciate if we could work on some points of criticim and not go into an EditWar. So please talk before you act and better make this version better before you destroy hard work (I have reverted my version one time) -- ThiloPfennig <> Everybody is invited to participate on the page FeatureRequestsDiscussion ---- The logic/structure of this page does confuse me now a bit. If you like to refactor it you may think on splitting it in more than one FeatureRequest. From my point of view the summarizing of ThomasWaldmann over sister pages and my derived patch with the discussion of OliverSiemoneit does solve a lot of the issues here. As always MoinMoin policy is not trying to make a "perfect release" there will be something opened for further discussions and may be something new too. We have used with the users homepage on MoinMaster and MoinMoin already something like a sister page without generalizing it. I do prefer the possibility to choose between sister pages and embedded pages. I do have needs for boths in our wikis. If you like to move my comment to a better place feel free to do it. -- ReimarBauer <> I have put all solutions and workarounds in some sections. You misunderstood my edits. I agree the to points you have made. And I also think that all solutions that really are other feature requests should move to other pages. my refactoring was not ment to unsolve a solved issue but rather to make this page more readable. I also think that many points are now solved. I think if we really have THE final solution somebody could write a summary of what will be definitely implemented. -- ThiloPfennig <> ---- some new ideas to get this i18 trouble off {{attachment:supplementation.py}} {{attachment:editsupplementation.py}} the theme patch is based on current 1.6dev code from 7487f00da9bc {{attachment:theme_patch.txt}} ToDo: patch of edit, patch of RenamePage action, patch of PageList * edit needs to change the url to Page?action=supplementation * RenamePage needs to rename the supplementation sub page too * PageList the supplementation needs to be hidded from that * Template usage needs to be added it works now the following way. If you select discussion you get if the supplementation page exists this loaded and you get the url MyExample?action=supplementation&editor=text shown. The edit url is changed to MyExample/?action=editsupplementation&editor=text and does call edit to change the page. If the page doesn't exist it is created. So we don't see in the url the complete pagename. -- ReimarBauer <> The i18n problems are still open any ideas are welcome. -- ReimarBauer <> ---- CategoryFeatureImplemented (in 1.6)