Last modified: 2011-12-31 17:12:06 UTC
In some kinds of documents (particularly legal documents), it is important to have section numbers. MediaWiki does reflect this in one respect: the auto-generated Table of Contents lists each line with a corresponding section number. However, the header itself -- within the body of the document -- does not display the section number. In the document linked (Wikimedia's proposed new Terms of Use), each section has been *manually* numbered. This leads to unsightly duplicate numbering within the Table of Contents. There are probably a number of technical approaches that could resolve this. I suggest one here, but it may or may not be the right one: Proposed solution: Introduce a new Magic Word, __DISPLAYSECTIONNUMBERS__, which will cause the numbers already included in the Table of Contents to be included within the document. Thus, the following lines: == Section 1 == Text text text == Section 2 == Text text text === Sectino 2.1 === Text text text Would be displayed as (and here I'm using all-caps to represent larger typeface etc.): 1. SECTION 1 Text text text 2. SECTION 2 Text text text 2.1 SECTION 2.1 Text text text
Possible refinement #1: It would be nice to be able to suppress this on a section-by-section basis, or on a header-level basis. For instance, maybe it's important for the H2 and H3 level headers to display their numbers, but not the H4 and H5 level headers. Some capability to define this throughout the page would be nice; and/or the ability to, on a granular level, suppress numbering on a given section.
Possible refinement #2: It would be nice to have some control over the display of the numbering: roman numerals, alphabetical ordering, etc. For instance, a document might need the following format: 1. Blahblah 2. Blahblah A) Blahbhal i Blabhlah ii Blahblah iii Blahblah B) Blahblah C) Blahblah HTML and CSS for <ol> include the ability to control this stuff on some level. That structure may serve as a useful model here.
There is a "Auto-number headings" preference comment 1 and comment 2 sounds like seperate bugs
Yes, the presence of a user preference is encouraging; perhaps something can be done to make that option available as a default attribute of a page, rather than subject to user preferences? I don't think these belong as separate bugs (at least not yet), because there is an important meta question to be addressed: what is the best path forward? I think it's important to keep all the components together until there is some consensus as to the best solution. If and when there is consensus, some of these ideas might be eliminated, some might be spun off as separate bugs..I'm not deeply familiar with the workflow here, but that's what makes sense to me, at any rate.
An alternative direction, as the outcome of a discussion on the English Wikisource Scriptorium: http://en.wikisource.org/wiki/Wikisource:Scriptorium#Ability_to_control_the_display_of_section_numbers (or, permalink: http://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&oldid=3484377#Ability_to_control_the_display_of_section_numbers ) Instead of making it possible to ENable the auto-numbering of section headers, we could take the approach of making it possible to DISable the auto-numbering within the Table of Contents. It turns out it is possible to do so, but currently this is reliant on a customization of the local wiki's [[MediaWiki:Common.css]] file, and the use of <div> tags. This is not ideal. Could this functionality be rolled up into a magic word, like: __SUPPRESSTOCNUMBERING__ ?
(In reply to comment #4) > Yes, the presence of a user preference is encouraging; perhaps something can be > done to make that option available as a default attribute of a page, rather > than subject to user preferences? The user preference has always looked useless to me, while the per page control makes sense if you need a non-default numbering of the sections: a magic word as in comment 5 would be useful. > I don't think these belong as separate bugs (at least not yet), because there > is an important meta question to be addressed: what is the best path forward? I > think it's important to keep all the components together until there is some > consensus as to the best solution. If and when there is consensus, some of > these ideas might be eliminated, some might be spun off as separate bugs..I'm > not deeply familiar with the workflow here, but that's what makes sense to me, > at any rate. First, big discussions shouldn't happen on bugzilla; second, comment 1 and comment 2 are indeed independent requests so they're usually put in different bug for better tracking. I don't understand why comment 1 would be useful; comment 2 asks a more granular control of how the TOC looks like; both can be replaced by manual work if the automatic numbering feature is disabled (comment 5). Comment 5 is uncontroversial, I think, and its resolution depends on whether it's considered worth a magic word; comment 2 perhaps is too much, if we don't want MediaWiki to be TEX.
OK, thanks for the detailed reply. (I'll confess I don't know the best place to have this sort of discussion, and would gladly take it elsewhere if you point out where.) However: I do think that moving forward only with Comment 5, and disregarding the rest, is acceptable. Whatever you think is the best process to follow reflecting that is fine by me. (Spinning off #1 and 2 into separate bugs and closing them, for instance..I really don't know how to best handle it.)
