Extension talk:Labeled Section Transclusion

Problems with Installation
I am trying to install this extension but I do not know what I am doing wrong. I copied all of the files and saved them separately into textpad as whatever name the download site has them as (lst.php, default.settings, etc.). I entered the require_once commands into defaultsettings.php and then it did not work. Is there anything I did not do correctly?

awareness of templates
Currently labels must be part of the text source of an article itself. It would be nice if the label could be buried within a template. Partly for esthetical reasons and partly as this would allow to easily transclude the contents of template parameters. Example: You use a template in your articles for, say, year of birth and year of death of people. You want to transclude the person´s name (i.e. the page name) and the two dates. If transclusion does not understand templates, you will have to put section markers around the parameters when calling the template in each article. If transclusion can handle templates you will be able to hide the labels in the template (writing them only once!).


 * This is a limitation of the MediaWiki parser, which doesn't allow XML-style tags in templates; I assume this was deliberate. It affects all extensions, it's just more obvious with this one.  I'd really like to see this, myself, but it appears that it can't be done. -Steve Sanbeg 16:41, 21 November 2006 (UTC)


 * Although, I must admit the Parser documentation is somewhat sparse, so it's always possible I'll discover some hook to do this. But at least for now, it's not obvious. -Steve Sanbeg 15:39, 22 November 2006 (UTC)


 * just to bookmark 6312, for the same problem in the cite extension. -Steve Sanbeg 23:23, 5 December 2006 (UTC)

shortcut for simple transclusions on paragraph level
In not so few cases you may want to transclude exactly the text body (paragraph) which belongs to a section header defined by === my headline === or so. It would be boring to put transclusion labels around all these paragraphs. There should be a shortcut for such situations. Maybe one could use a "+" symbol or a "#" as a prefix for the section name to refer to the text body of headings. It could be left to the inclusion mechanism to identify the correct level of the heading; the transclusion would have to contain everything up to the next heading on the same level (including embedded subheadings and their bodies).


 * This was discussed at wikisource:project:Labeled section transclusion but it was dropped. In part, this was because they were more concerned with exactness of which parts are transcluded than a shortcut, especially since the most common use won't be the same as sections.  There may be other issues with using visual markup to denote the sections; i.e. someone changing the name of a heading wouldn't know that they also broke a transclusion.  It may be possible to have some way to put a mark in the text, that would be transformed to the normal markings when the document is saved, but I'm not sure how to do that, or how well-liked that would be. -Steve Sanbeg 15:51, 22 November 2006 (UTC)


 * I understand the purists but I really felt tempted to offer a little hack which would allow transclusion of chapters as a a whole. If you have many existing documents which use a common template and therefore have a chapter with identical name you wouldn´t really want to embrace them all with section tags I guess. In my definition a "chapter" is the text after a ==heading== up to the next heading (or up to the end of the document), regardless of the next heading´s level. Very pragmatic, very simple.


 * My suggestion is to use the heading text with a prefixed "#" to indicate the transclusion of a chapter. This is at least downward-compatible to the current solution. You can find the source on my metawiki homepage meta:User Talk:Algorithmix. You will notice that it was originally triggered by the wish to enhance another extension called DynamicPageList2. In the discussion of that extension you will find more details.


 * Let me add an example : You have documents about people which contain a short "Summary" statement about each person, maybe including year of birth and year of death. And there are other capters named "Education", "Work" etc. Somewhere in the 'person' document you have a link to another document, say a 'city' where the person lived. My idea is to automatically include a list of people [together with a summary statement about each person] into the city document. Using DPL and LST together this can easily be done and looks really nice. I see this as a logical extension to "inverted links" which carries semantic information beyond the pure name of the referring page.Algorithmix 23:12, 23 November 2006 (UTC)


 * Hi. It seems to me that the more flexible the feature is, the more useful it becomes. Adding an additional option to transclude "regular" sections (what you refer to as "chapters"), as well as labeled sections, would be great, and indeed was contemplated in the original discussion. Does "downward compatible" also mean that it would be easy to incorporate in the coding? Dovi 21:27, 25 November 2006 (UTC)


 * Yes, in fact it is already contained in my version of the coding (Just ignore the first part about DPL2). "Downward compatible" means that you could write something like to use the feature as it is, i.e. based on explicit section markers, and something like  to include the regular section ("chapter body") of a section carrying the heading "Some Headline". If the parameter starts with a "#" it will be interpreted as a heading name otherwise as a section label. Try the source code of my homepage to test it if you like. Algorithmix 23:44, 25 November 2006 (UTC)


 * My main concern is that when a lot of people are collobarating, using headings that are intended as visual markup to denote sections could cause a lot of confusion when someone changes a hading, and has no idea that they're breaking transclusions. This could be useful on smaller sites.  However, since the wikimedia software doesn't even support redirecting to section headings, I suspect that having this as an integral part of the extension would make it more difficult for us to get this installed on wikimedia projects.  We probably want to hold off on making significant, non-obvious changes until this gets installed, unless we know we have enough support for them that it won't impact what we're trying to do.
 * As far as implementing it, I can see two ways it could be done: either fully integrate it into the wfLst_pat_ function, so we could mix and match section marks & headings, i.e. to transclude from a heading to the end of a section, or vice versa, or implementing another parser function (similar to what I did with the #lstx function, to avoid adding weird syntax to do exclusion) as a sort of extension to the extension. Although the first would be more flexible, it's also more likely to derail what we're trying to do.  Since we don't need all of that functionality (for example, it would allow excluding a section marked by a heading, which is consistent, but unlikely to be useful), this may be a better way to go.  Then, site that want a stricter approach could install the core functionality, while those that want more convenience could add to it. Probably, putting your functionality in a #lsth function would be the way to go.-Steve Sanbeg 19:32, 27 November 2006 (UTC)
 * As you have seen I created a second variant of wfLst_pat called wfLst_pat_heading. I did not want to intermix the two ways of describing/tagging relevant portions of a text. To me it would sound quite logical to have a corresponding #lsth function which uses the heading based transclusion approach only. This would easily allow a configuration switch to deactivate the heading based selection mechanism for SysOps who are concerned about the volatility of headings. Personally I still think that headings could be used; after all mediawiki accepts something like myArticle as a valid link. Changing the heading breaks this link. Nobody seems to be very concerned about that today. Maybe that is because you still are guided to the beginning of the article if the heading has changed. My proposal for #lsth is therefore as follows: if no matching heading is found the reaction should depend on an option which is specified together with #lsth; in standard mode (non-obligatory heading) nothing happens, in "obligatory mode" we include the first 100 characters of the article. This is an analogy to putting you to the top of an article if the heading based href link fails. Algorithmix 21:22, 27 November 2006 (UTC)


 * Yeah, I was concerned about having a seperate pattern function in one of the existing parser functions; adding another parser function would be better. I don't think splitting on characters will work; you could get weird results if you split in the wrong place in formatting.  Altough it would be possible to transclude the introduction, it's probably better to just use either an empty string or a link, which has less potential for weirdness, and would probably make the error easier to find & fix. -Steve Sanbeg 22:21, 27 November 2006 (UTC)


 * A link would be the perfect solution. It could show the desired heading text but it will -- as a heading with that text does not exist -- behave as usual, i.e. it will link to the beginning of the document. And in case mediawiki will some day offer a means to fix this type of "slightly broken link", LabeledSectionTransclusion will benefit from that without further effort. Algorithmix 22:49, 28 November 2006 (UTC)


 * I've put another extension at http://mediawiki-tools.cvs.sourceforge.net/mediawiki-tools/extensions/LabeledSectionTransclusion/, based on your code. Currently, it works the same as #lst: a missing page shows a red link, a missing section shows an empty string.  -Steve Sanbeg 23:00, 28 November 2006 (UTC)

Intuitive name
Hi. At the Wikisource page, someone suggested using a more intuitive term in the code than "lst". If and when this becomes widely used, not only is the code "lst" likely to make no intuitive sense to the user and be hard to remember, but the "l" (letter) is highly likely to be confused with "1" (numeral).

As it stands, the most basic coding works as follows. Sections are marked off as:

this is a chapter

And they are transcluded by using:

May I suggest a more intuitive term for the transclusion code? It seems to me that the easiest to use remember would be precisely:

Or maybe even just:

What do people think? Personally, I think I slightly prefer "section" to "sec" (second choice). But any other suggestion for any other word that can be used more intuitively would be fine as well. It doesn't really matter as long as it is usable. Dovi 14:18, 20 December 2006 (UTC)

P.S. Other supporting options would be used just as already proposed. Section exclusion as:

or maybe

and "regular" sections with heading as:

or maybe or

Whatever people think looks and works the best. Dovi 14:32, 20 December 2006 (UTC)


 * Since it hasn't been installed on a project yet, it would be possible to rename it. But a simpler solution may be to create an alias, either globally or per language.  Then we could just keep the functions named after the extension, and treat this as a localisation issue. -Steve Sanbeg 16:17, 20 December 2006 (UTC)


 * Is it important to keep the function named after the extension? Dovi 20:20, 20 December 2006 (UTC)
 * Probably not, but it would seem simpler on special:version. Naming parser functions seems a bit odd, in that the name that's shown on special:version can't be called directly (it's only called through an alias) and I think can't be the same as a parser tag.  Which means it can't be named section, since that would conflict with the tag, but it could be called section.  So renaming these may not be worthwhile; the names now are probably reasonable, and we could always add longer names if desired.  We can even put off the language availablity issue until someone suggests using non-English names for them. Myabe we just need section, section-x & section-h or similar aliases for people who'd rather they're readable than short.-Steve Sanbeg 18:49, 21 December 2006 (UTC)

What do you think of these for the actual code:
 * for "include section"
 * for "exclude section"
 * for "header section"

Simple and to the point. It actually seems to me that aliases in general are less important. In English the code itself should have names that do the job without confusion, and if other languages want to create aliases they can, but the code shouldn't depend upon that.

What worries me is that as actual code, the three letters "lst" are not intuitive enough, and that especially in English they are highly likely to be confused with "1st" (as in "first"). Dovi 06:45, 27 December 2006 (UTC)


 * I was thinking that it's more consistent to have a common prefix, with something to seperate words, which is why I was thinking of #section (clearly the most important function), #section-x & #section-h. It would be possible to use #section-i (or #i-section) or some other name.  I'm not sure if adding a prefix letter with no delimiter would be as clear, but something to think about.


 * AFAIK, the names in the code don't actually do anything, they're just displayed in special:version. If we do decide that we don't need a function named #section, then we could rename them, though. -Steve Sanbeg 20:37, 31 December 2006 (UTC)


 * Any of these options sounds good, doesn't really make too much of a difference.Dovi 13:21, 2 January 2007 (UTC)

Bug with section indices with "empty" headings
There is what I believe to be a small bug when using #lsth to transclude a heading "section" from a page where there is an empty heading "section". Let me explain with an example from an imaginary page Foo:

= Section 1 =

Section 1.1
Some text.

Section 1.1.1
Some more text.

If I transclude Section 1.1 on imaginary page Bar with  , then try to use the [edit] link on Section 1.1.1, I will actually be directed to edit Section 1.1. On Foo, the section numbers in the edit link for the three sections will be 1, 2, and 3. But on Bar, the edit link for Section 1.1.1 will have section=2 instead of section=3.

It looks like this happens because Section 1's "section" contains nothing. If I add a blank line before the Section 1.1 heading, things get back to normal.

Let me say that if this does get fixed, I probably won't upgrade. On the site I'm managing, we're already making fairly heavy use of this extension, and I'm currently leveraging this bug. I'm writing this up here for the benefit of users of this extension, and also in case anyone has feedback of a better way to achieve this.

Another example page Foo2:

= Section 1 =

Section 1.1
Some text.

Section 1.1.1
===Section 1.1.1 (transcluded from Foo2)=== Some more text.

Section 1.1.2
===Section 1.1.2 (transcluded from Foo2)=== Even more text.

Now if I transclude Section 1.1.1 on page Bar2, I get the heading "Section 1.1.1 (transcluded from Foo2)", whose [edit] link ends with section=3. Following this link will bring up Section 1.1.1 for editing. Without transcluding the empty "Section 1", the link on the transcluding page would end with section=4 and bring up the undesired Section 1.1.2 when clicked. --Ken Crowell 16:24, 30 January 2007 (UTC)


 * Thanks for the feedback. I fixed a problem with the regex, which seems to take care of that.

Generally, if you want to be precise about what is transcluded, it's probably better to use the more exact #lst, instead of #lsth, i.e.

= Section 1 =

Section 1.1
Some text.



Section 1.1.1 (transcluded from Foo2)
Some more text.



Section 1.1.2 (transcluded from Foo2)
Even more text. 

It's also possible to use #lsth with a mix of wiki & HTML sections. HTML sections don't work very well in transclusion anyway, and so are generally ignored by lsth both for inclusion and when counting offsets (by default, mostly for efficiency). i.e. section 1

section 1.1
some text

Should have similar effect; the HTML section currently won't be counted. -Steve Sanbeg 16:46, 31 January 2007 (UTC)