Last modified: 2011-03-13 18:05:27 UTC
On Wiktionary there is some content, such as quotations, that would be nice to remain hidden until the user chooses to see it; otherwise they could easily dominate the page. It would encourage people to add quotations to pages. Currently some users are making seperate Quotation pages, which might make pages harder to maintain in the future. Here's a suggested syntax: ===-Quotations-=== It would then have the same [show]/[hide] link as the table of contents. <div> tags could be used instead of the <table> used by the TOC. A pretty neat way of doing it: http://www.evolt.org/article/Collapsible_page_elements_with_DOM/17/45831/
Created attachment 198 [details] allows creation of headers that are collasped until clicked on This patch is more of a proof of concept then a proper patch. It does do what it says it does, it adds my suggested syntax though it doesn't implement the nice [show]/[hide] of the TOC.
(In reply to comment #1) > Created an attachment (id=198) [edit] > allows creation of headers that are collasped until clicked on Please supply a unified (-u) patch.
please compare with bug 3560: lengthy sections should have the option to hide/show (collapsable)
*** Bug 3560 has been marked as a duplicate of this bug. ***
*** Bug 4326 has been marked as a duplicate of this bug. ***
Pasting from Bug 4326 comment #1: A friend of mine is working on an extension that might interest you. See http://meta.wikimedia.org/wiki/ShowHide_Extension and http://crash.vikimedija.org/index.php/ShowHide . [...]
The extension has one major issue in that it will not allow hidden sections to show up in "printable versions" on either my (sorry, intranet) site running 1.5 or on the example site listed above...
That doesn't sound like a major issue to fix. I just like my syntax better. :P
*** Bug 5826 has been marked as a duplicate of this bug. ***
This would be a MAJOR ENHANCEMENT to the useability of Wikipedia and Wiktionary. And it would go a long way to resolving the differences/ ongoing battles between inclusionists and deletionists. (Deletionists would see as little as they want to see, inclusionists would see as much as they want to see. I will attach a much more compreensive user statement of how it can be implemented, and the benefits. So, how do we get this escalated for some real action ?
Created attachment 1654 [details] More comprehensive user requirement/suggestion, justification document There is more value to this than meets the eye on the simple requests so far. Could be a major improvement to the user experience, and resolve some raging battles. Yet probably easy to implement. User Requirement/Suggestion & Justification document.
No, this wouldn't have anything at all to do with inclusionism/deletionism. Collapsable sections are inaccessible, and useless for printed and other such forms of pages. Going to WONTFIX this.
Collapsable text can already be done through css, at least on en.wikipedia. Maybe you need to copy some css and construct a template?
Richard's idea was way too complicated. No one is going to understand what some numbers at the top of the page mean. As far as inaccessibility, it should really only be used when the alternative is to create subpages - those are even more inaccessible. On printed pages, obviously it would just print everything...
"No, this wouldn't have anything at all to do with inclusionism/deletionism." Collapsible sections WOULD GO a long way to resolving inclusionism/deletionism disputes. WONT FIX implies it was a bug report. It was an improvment suggestion, based on many years of intervening between tech heads who suggest technical solutions like using personal CSS, and real world users. I do not accept this verdict by one single techhead, against 6 votes for it. If it doesn't fit into a Bug fix system, then where are serious suggestions for improvment to be put. Or don't we have such a system ????
Both bug reports and feature requests for MediaWiki are placed on this tracker. We tend to use WONTFIX in the case of feature requests which we aren't planning on implementing for one or more reasons, and INVALID to close false bug reports. To start long-term discussion, you are welcome to use one of the many mailing lists to bolster support for the idea, provide a convincing argument that it would be useful, and suggest a decent means of implementation which works for more than just the users with JavaScript enabled. Please be aware that features in MediaWiki come about via a concensus of the active developers, with our lead developer Brion having the final statement over what does and doesn't happen. We don't often count votes as it is our experience some users don't understand what is best for them. For what it is worth, I too am opposed to the idea of hiding bits of information, making reading documents complex where there is no clear need...I am against a technical solution to a social dispute between several classes of users, some of whom are misguided. I won't close the bug WONTFIX, but don't be surprised if someone else does. And please don't war over it in that case.
A soluion for the small number of users without javascript is not necesary, they can see everything, no big deal. And this should be seen as alternative to subpages, doesn't have much to do with inclusionism etc. The status of a ticket really isn't that important from my experience with other projects, no reason for bugzilla-drama. ;)
As an experienced senior business systems analyst, with 28 years in the IT industry, starting as a technical programmer, but for the last 20 years mainly being the go- between to interpret user needs to IT techos, I've got to say I'd back my own opinion. All that you've done is make this user further lose faith in the developer community as just a bunch of ego techos who just don't understand the users, even when they put together a user requirement document. So, what do you developers really understand about the inclusionist/deletionist debate, and what kind of solutions are you working on in this area. By all means, let me know where you conduct these discussions. Of course, I'm assuming that if you want users to contribute, it will be in a place that doesn't take technical expertise to take part. Is that too big an assumption ?? Seriously,I want to help bring the user perspective to the developer community in a better way, since so many technical solutions are being offered, instead of real user friendly ones. Contact me on rb_wikitech@boult.mailshell.com
I've been thinking about this same problem for a long time. For my solution, the key is Bug 6104, which would include CSS classes for all sections and sub-sections. Site CSS, user CSS, and with some enhancements, user preferences would then be able to choose which sections are visible or hidden by default quite easily. The feature is held up by complex markup on Wikipedias that Wiktionaries do not suffer from. Somebody could implement a simple solution now for Wiktionaries which would be disabled on Wikipedia until a full Wikipedia-compatible solution can be developed.
Patch is far too old to be applied and has serious flaws (extension of wikimarkup, breaking reverse compatibility, breaking XHTML validity) for a feature of such questionable worth. The typical use case of MediaWiki is for article-style pages, where this feature would not be useful and would just clutter the interface. It would be perfectly reasonable as a custom script if desired, but not part of the core software. If the core needs flexibility increased in some way to enable this (e.g. bug 6104), please open separate bugs. WONTFIX.
