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?


 * You should make the changes to LocalSettings.php, not DefaultSettings.php; then check Special:Version, to verify that the extension is loaded. If it didn't load, try checking your web server error logs for a reason, or try adding the line "error_reporting( E_ALL );" to LocalSettings.php", which may help show the error. -Steve Sanbeg 16:27, 29 May 2007 (UTC)

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)

Test wiki
Hi. Is there is test wiki where one can experiment with this feature in the meantime? Dovi 06:21, 14 June 2007 (UTC)


 * I don't have access to install it on any public wiki; convincing someone to install it on one of the offical test wikis would probably involde similar effort to having it installed on ws -Steve Sanbeg 20:43, 20 June 2007 (UTC)

Editing the origin article
Hi Steve...

Actually I'm playing around with your nice extension. In this context I'm faced with a standard problem of transclusion within wiki. When choosing the edit-button, the user isn't able to change the content of the article, because only the "transclusion-syntax" is displayed.

Do you think it would be possible to manipulate the edit-function in a way to refer to the origin article, in the case of transcluded content?

greets... --Demagggus 12:34, 15 October 2007 (UTC)


 * If I understand what you want, the simplest way is probably to just put headings in the text that's being transcluded. then, each heading will get an edit link which points back to the appropriate section in the original text. -Steve Sanbeg 15:26, 19 October 2007 (UTC)

Transcluding sections from different articles
Hi,

suppose i have many articles in which i annotated sections with the keyword "linux". in another page i want to display all the sections with "linux" as keyword; or a link to those sections.

i think, as per the current functionality, we need to use the article name as a parameter, like. but in my case, i have many articles, and i don't know the names. my requirement is to find where all i have relevent information on "linux".

can it be achieved?

Jack


 * That would be a pretty significant enhancement, to add a table to track which pages have which section. It may be more useful to put all those pages in a category, and use something like semantic mediawiki or DPL call LST on pages in the category. -Steve Sanbeg 23:06, 8 November 2007 (UTC)


 * You may want to have a look at Extension:DynamicPageList. It offers search criteria based on regular expressions and contains and embedded version of Labeled Section Transclusion. --217.111.20.10 20:31, 27 November 2007 (UTC)

Including the Heading in Transcluded Output?
I was wondering if it could be made possible to include the section title along with the body text when including a section with #lsth?

I was kind of surprised when I realized that ONLY the body text and subordinate headings were included. I think there should be an option to include the section heading as well.

-Steve


 * That was mostly done because if the heading wasn't transcluded, it would be easy to add; i.e. with a template like


 * but if it was added automatically, it couldn't easily be removed. It would be possible to add an option, but using a template is probably easier. -Steve Sanbeg 23:03, 8 November 2007 (UTC)

Includeonly / noinclude tags are ignored
When transcluding a section containing and/or tags, is their any way to get LST to honor them? I'd think it would be a fairly simple change to the code. --Jonathan Kovaciny 15:53, 10 January 2008 (UTC)


 * I'd think the parser should be able to handle those itself, although I haven't looked at it in awhile. It could also depend on the versions of mediawiki & LST you're using. -Steve Sanbeg 19:41, 10 January 2008 (UTC)

LST not working?
I've deployed the extension files and made the required changes to LocalSettings.php on my WM 1.11.x, PHP 5.x wiki. I checked the version page of the wiki, and it shows

MediaWiki: 1.6.10 PHP: 5.2.5 (apache2handler) MySQL: 5.0.45 Extensions: Parser hooks: DynamicPageList2 (version 1.6.4), based on DynamicPageList, featuring many improvements, by IlyaHaykinson, Amgine,Unendlich, Cyril Dangerville,Algorithmix LabeledSectionTransclusion, adds #lst and #lstx functions and tag, enables marked sections of text to be transcluded, by Steve Sanbeg ParserFunctions by Tim Starling StringFunctions (version 2.0), Enhances parser with string functions, by Ross McClure & Juraj Simlovic Variables, Define page-scoped variables, by Rob Adams Extension functions: wfSetupVariables, wfStringFunctions, (, setup), wfSetupParserFunctions, wfCalendarExtension, wfRssExtension, (, setup) and wfLabeledSectionTransclusionHeading Parser extension tags: , and Hooks: EditFilter: CalendarEditFilter LanguageGetMagic: wfVariablesLanguageGetMagic, wfStringFunctionsLanguageGetMagic, ExtDynamicPageList2__languageGetMagic, wfParserFunctionsLanguageGetMagic, LabeledSectionTransclusion::setupMagic and wfLabeledSectionTransclusionHeadingMagic ParserClearState: (ExtParserFunctions, clearState) visited from 192.168.50.140 Retrieved from "http://192.168.50.136/wiki/index.php/Special:Version"

(The wiki version is incorrect -- installed from 1.11.x, but copied some files from our 1.6.10 wiki over during the upgrade, which appears to have overwritten something.)

Anyway, when I put ' this is a chapter ' in the 'article' page, and  in the target page, I just get  displayed. Does that sound like a parser, or LST, issue?

Thanks -- com^lnssi^roberts^michael 1/10/08 13:06


 * Sounds like a parser problem; the parser isn't recognizing that the parser function is installed. Possibly that got messed up when you copied files, and no parser functions work, so you may want to try with a clean installation. -Steve Sanbeg 19:43, 10 January 2008 (UTC)

Thanks for responding. It looks like you're correct. When I get rid of the leading '#' sign, a la ParserFunctions for MW 1.6.10, LST works. What I did was install MW 1.11.03, then copy over all the content from our old 1.6.10 installation, which worked, but MW reports that it's 1.6.10, and PF apparently requires the 1.6.10 syntax, so apparently something I copied over wasn't content. -- MR

Hide templates?
Is there a way to completely prevent any templates in the source text from being transcluded? --Jonathan Kovaciny 21:56, 31 January 2008 (UTC)