Hello,
Is there a way to control the numbering of sections so that:
* Some sections are un-numbered ==section unumbered== ==section 1== ==section 2== * Sections and subsections start from a value other than 1 ==section 6== ==section 7== * Subsections continue numbering upwards regardless of parent sectioning ==section unumbered== ===subsection 1=== ===subsection 2=== ==section unumbered== ===subsection 3=== ===subsection 4=== * Sections numbered with non-numeric numbering ==section A== ==section B==
Thanks
-John
This sounds like a feature request, which I take to be referring to the display in the TOC. My two cents on it:
- Some sections are un-numbered ==section unumbered==
Can you explain where this would be helpful? It would also be handy to be able to totally suppress certain sections from the TOC.
- Sections and subsections start from a value other than 1 ==section 6==
What would this be useful for?
- Subsections continue numbering upwards regardless of parent sectioning ==section unumbered== ===subsection 1=== ===subsection 2=== ==section unumbered== ===subsection 3=== ===subsection 4===
Can you give examples of why this would be good?
- Sections numbered with non-numeric numbering ==section A== ==section B==
Again, why?
In total, I think you're requesting a special operator which can go in a section to control its numbering, someting like as follows:
__SECTNONUM__ (don't number) __SECTSUBCONT__ (sub sections number continuously) __SECTALPHA__ (use letters instead of numbers) __SECTSTARTAT3__ (could be tricky to make work - perhaps something like __SECTFAKE__ could be used repeatedly instead to bump up the count)
to which I would add:
__SECTNOTOC__ (don't show the section at all in the TOC)
Steve
On 6/12/06, Steve Bennett stevage@gmail.com wrote:
What would this be useful for?
There are lots of documents (eg. legislation) that have special numbering schemes. Here's an example:
http://www.legislation.nsw.gov.au/summarize/inforce/s/1/?TITLE=%22Mining%20A...
The numbering scheme used here has unnumbered top level headings and numbered second level headings that do not restart numbering regardless of how they are organised under top level headings.
I'm not sure what the best way to deal with these cases are, but I am finding it difficult to store these sorts of documents under Mediawiki and still be able to have a sensible TOC.
As far as I can see, a manually written TOC is the only way at the moment.
-John
On 6/12/06, John Ky newhoggy@gmail.com wrote:
There are lots of documents (eg. legislation) that have special numbering schemes. Here's an example:
OIC, I was thinking in terms of Wikipedia. Yes, what you request seems quite reasonable. :)
Steve
John Ky wrote:
On 6/12/06, Steve Bennett stevage@gmail.com wrote:
What would this be useful for?
There are lots of documents (eg. legislation) that have special numbering schemes.
Then your likely best bet is to request a token which inhibits the NUMBERING of TOC entries, and add them manually, so that the numbers appear correctly regardless of the preferences chosen by the user.
Something like __NOTOCNUMBERING__ maybe? HTH HAND
On 6/12/06, Phil Boswell phil.boswell@gmail.com wrote:
Then your likely best bet is to request a token which inhibits the NUMBERING of TOC entries, and add them manually, so that the numbers appear correctly regardless of the preferences chosen by the user.
Something like __NOTOCNUMBERING__ maybe? HTH HAND
What, like:
intro text intro text __NOTOCNUMBERING__ ==A. Section A== aoeueou ==B. Section B== ===B. I. blah===
?
Would there be any differences between that and "true" numbering in the rendering process?
Steve
On Mon, 12 Jun 2006 13:11:20 +0200, Steve Bennett wrote:
On 6/12/06, Phil Boswell phil.boswell@gmail.com wrote:
Then your likely best bet is to request a token which inhibits the NUMBERING of TOC entries, and add them manually, so that the numbers appear correctly regardless of the preferences chosen by the user.
Something like __NOTOCNUMBERING__ maybe? HTH HAND
How about __NOTOCNUM__?
http://bugzilla.wikimedia.org/show_bug.cgi?id=4127
What, like:
intro text intro text __NOTOCNUMBERING__ ==A. Section A== aoeueou ==B. Section B== ===B. I. blah===
?
Would there be any differences between that and "true" numbering in the rendering process?
None visible; the invisible one is maintenance effort.
The patch above suppresses the auto-generated numbers from being prepended to entries in the TOC as well as to section headings when a user has selected the "Auto-number headings" option.
Yes, actually, that would be very helpful.
-John
On 6/13/06, Netocrat netocrat@dodo.com.au wrote:
On Mon, 12 Jun 2006 13:11:20 +0200, Steve Bennett wrote:
On 6/12/06, Phil Boswell phil.boswell@gmail.com wrote:
Then your likely best bet is to request a token which inhibits the NUMBERING of TOC entries, and add them manually, so that the numbers appear correctly regardless of the preferences chosen by the user.
Something like __NOTOCNUMBERING__ maybe? HTH HAND
How about __NOTOCNUM__?
http://bugzilla.wikimedia.org/show_bug.cgi?id=4127
What, like:
intro text intro text __NOTOCNUMBERING__ ==A. Section A== aoeueou ==B. Section B== ===B. I. blah===
?
Would there be any differences between that and "true" numbering in the rendering process?
None visible; the invisible one is maintenance effort.
The patch above suppresses the auto-generated numbers from being prepended to entries in the TOC as well as to section headings when a user has selected the "Auto-number headings" option.
-- http://members.dodo.com.au/~netocrat
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Steve Bennett-4 wrote:
On 6/12/06, Phil Boswell phil.boswell@gmail.com wrote:
Then your likely best bet is to request a token which inhibits the NUMBERING of TOC entries, and add them manually, so that the numbers appear correctly regardless of the preferences chosen by the user. Something like __NOTOCNUMBERING__ maybe? HTH HAND
What, like:
intro text intro text __NOTOCNUMBERING__ ==A. Section A== aoeueou ==B. Section B== ===B. I. blah===
? Yes, something like that...
Would there be any differences between that and "true" numbering in the rendering process?
Well, you wouldn't have the numbers doubling up if a user has "auto-numbering" enabled in their preferences (I forget which way around IP users see it).
You also wouldn't have the odd situation where the absolute level of headers makes no difference to the numbering, it's all relative to the highest level in use.
I see this as not very different to using __NOTOC__ to suppress the standard TOC to allow a {{CustomTOC}} to be used instead.
HTH HAND
Steve Bennett-4 wrote:
On 6/12/06, Phil Boswell phil.boswell@gmail.com wrote:
Something like __NOTOCNUMBERING__ maybe?
Would there be any differences between that and "true" numbering in the rendering process?
I forgot: one major difference would be that the numbering would appear in the anchor, so if you wanted to link to a section it would have to be [[example#A. Section]]
HTH HAND
On 6/13/06, Phil Boswell phil.boswell@gmail.com wrote:
I forgot: one major difference would be that the numbering would appear in the anchor, so if you wanted to link to a section it would have to be [[example#A. Section]]
IMHO, this kind of linking isn't that great anyawy. We should use proper anchors, as section names change so quickly (much more so than article names, at any rate), and there isn't (afaik) any way of finding out what links exist to a given section.
Steve
On Tue, 13 Jun 2006 11:41:57 +0200, Steve Bennett wrote:
On 6/13/06, Phil Boswell phil.boswell@gmail.com wrote:
I forgot: one major difference would be that the numbering would appear in the anchor, so if you wanted to link to a section it would have to be [[example#A. Section]]
So did I.
Unchecking the "Auto-number headings" option also has no effect - the manual numbering is displayed in non-TOC headings either way.
IMHO, this kind of linking isn't that great anyawy. We should use proper anchors, as section names change so quickly (much more so than article names, at any rate), and there isn't (afaik) any way of finding out what links exist to a given section.
And it causes unmemorable and long urls that are unsuited to Usenet articles and emails.
It's possible to use this form - here in combination with __NOTOCNUM__: === <span id="shortid">[[#shortid|1.1]]</span> Heading and TOC entry ===
This gets rendered as: 1.1 Heading and TOC entry where the TOC entry links as usual to the section heading as #1.1_Heading_and_TOC_entry, and the section heading links the "1.1" to itself as #shortid.
The only drawbacks that I've noticed are that when editing the section, the /*...*/ summary includes the unparsed html, requiring manual pruning of the <span>...</span>, and that the page returned after saving an edit to the section starts out unscrolled because the url uses a non-existent internal anchor: Article_title#.5B.5B.23shortid.7C1.2.5D.5D_Heading_and_TOC_entry.3F.
Otherwise this all works as expected on the MediaWiki versions that I've tried it under.
It could be automated so that the <span>...</span> is instead a wiki-interpreted syntax, and so that "shortid" replaces the regular anchor in the TOC. It could also be more worthwhile to store this somewhere in the database to keep track of links to the section, because these anchors change less often than the long, automated anchors.
On 6/14/06, Netocrat netocrat@dodo.com.au wrote:
IMHO, this kind of linking isn't that great anyawy. We should use proper anchors, as section names change so quickly (much more so than article names, at any rate), and there isn't (afaik) any way of finding out what links exist to a given section.
And it causes unmemorable and long urls that are unsuited to Usenet articles and emails.
For common ones, you can set up redirects to the section heading. That works, thankfully.
=== <span id="shortid">[[#shortid|1.1]]</span> Heading and TOC entry ===
Eep. :)
Steve
Steve Bennett wrote:
On 6/14/06, Netocrat ... wrote:
[>>Steve Bennett wrote:]
IMHO, this kind of linking isn't that great anyawy. We should use proper anchors, as section names change so quickly (much more so than article names, at any rate), and there isn't (afaik) any way of finding out what links exist to a given section.
And it causes unmemorable and long urls that are unsuited to Usenet articles and emails.
For common ones, you can set up redirects to the section heading. That works, thankfully.
That's welcome news: they didn't work the last time that I checked (1.5.x; just confirmed on 1.5.6), but I see that they do on a 1.6.5 install.
=== <span id="shortid">[[#shortid|1.1]]</span> Heading and TOC entry ===
Eep. :)
There are variations that avoid extras in the heading, but short of a core code patch they're also flawed.
[...]
Netocrat wrote:
On 6/14/06, Netocrat ... wrote:
For common ones, you can set up redirects to the section heading. That works, thankfully.
That's welcome news: they didn't work the last time that I checked (1.5.x; just confirmed on 1.5.6), but I see that they do on a 1.6.5 install.
What are you referring to here? The following definitely does NOT work:
#REDIRECT [[Article title#Section name]]
Timwi
On 6/15/06, Timwi timwi@gmx.net wrote:
For common ones, you can set up redirects to the section heading. That works, thankfully.
That's welcome news: they didn't work the last time that I checked (1.5.x; just confirmed on 1.5.6), but I see that they do on a 1.6.5 install.
What are you referring to here? The following definitely does NOT work:
#REDIRECT [[Article title#Section name]]
Heh, yeah, you'd think I would have noticed that by now. Well, I've probably created a dozen of those for the day when it does work.
Steve
On Thu, 15 Jun 2006 17:37:51 +0100, Timwi wrote:
Netocrat wrote:
[>> Steve Bennet wrote:]
For common ones, you can set up redirects to the section heading. That works, thankfully.
That's welcome news: they didn't work the last time that I checked (1.5.x; just confirmed on 1.5.6), but I see that they do on a 1.6.5 install.
What are you referring to here? The following definitely does NOT work:
#REDIRECT [[Article title#Section name]]
I clicked the redirect link that's displayed on the redirect page when redirect=no is a url query parameter and made a hasty assumption that the behaviour was identical to that when accessing the redirect page without redirect=no as a url query parameter.
So after all it's not the good news that I thought it was.
wikitech-l@lists.wikimedia.org