User:FreedomFighterSparrow/Sandbox2

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)

Proposed Enhancements

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 bugzilla: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#Labeled Section Transclusion. You will notice that it was originally triggered by the wish to enhance another extension called meta: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

{{#lst:someArticle|mySection}}

to use the feature as it is, i.e. based on explicit section markers, and something like

{{#lst:someArticle|#Some Headline}}

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#its first heading]] 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:

<section begin=chapter1 />this is a chapter<section end=chapter1 />

And they are transcluded by using:

{{#lst:article|chapter1}}

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

{{#section:article|chapter1}}

Or maybe even just:

{{#sec:article|chapter1}}

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:

{{#sectionx:article|chapter1}} or maybe {{#xsection:article|chapter1}}

and "regular" sections with heading as:

{{#sectionh:article|chapter1}} or maybe {{#hsection:article|chapter1}} or {{#sectionhead:article|chapter1}}

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:

• {{#isection:article|chapter1}} for "include section"
• {{#xsection:article|chapter1}} for "exclude section"
• {{#hsection:article|chapter1}} 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 {{#lsth:Foo|Section 1.1}}, 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 deliberately left empty -->
= Section 1 =
== Section 1.1 ==

Some text.

=== Section 1.1.1 ===

<includeonly>===Section 1.1.1 (transcluded from Foo2)===</includeonly>
Some more text.

=== Section 1.1.2 ===

<includeonly>===Section 1.1.2 (transcluded from Foo2)===</includeonly>
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 begin=1.1.1/>
===Section 1.1.1<includeonly> (transcluded from Foo2)</includeonly>===
Some more text.

<section end=1.1.1/><section begin=1.1.2/>
===Section 1.1.2<includeonly> (transcluded from Foo2)</includeonly>===
Even more text.
<section end=1.1.2/>

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.

<h1>section 1</h1>
==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 {{#lst:article|chapter1}}. 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

=={{{2}}}==
{{#lsth:{{{1}}}|{{{2}}}}}

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)

But then the edit link would be wrong. It would be nice when using lsth to include a useful edit link as well. 72.165.173.27 18:59, 11 August 2009 (UTC)

Includeonly / noinclude tags are ignored

When transcluding a section containing <noinclude> and/or <includeonly> 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)

This is still a problem, it doesn't honour <noinclude>83.216.114.194 05:07, 23 March 2015 (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 <section> 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: 
<dpl>, <section> and <rss> 
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 '<section begin=chapter1 />this is a chapter<section end=chapter1 />' in the 'article' page, and '{{#lst:article|chapter1}}' in the target page, I just get '{{#lst:article|chapter1}}' 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)

No, this is the same as regular transclusion, it just selects which part to transclude. Removing all templates would require another extension to be written -Steve Sanbeg 14:27, 1 April 2008 (UTC)

Error message after installation

When I try to install this extension, it is shown in the Special:Version page, but on each page I get the following message now:

Warning: call_user_func_array() [function.call-user-func-array]: Unable to call LabeledSectionTransclusion::setupMagic() in C:\Web\htdocs\mediawiki\includes\Hooks.php on line 114
Warning: array_slice() [function.array-slice]: The first argument should be an array in C:\Web\htdocs\mediawiki\languages\Language.php on line 1105
Warning: array_slice() [function.array-slice]: The first argument should be an array in C:\Web\htdocs\mediawiki\languages\Language.php on line 1105

What is wrong? I am using MediaWiki 1.9.0

I'd guess that when the extension was modified to use the new parser, it somehow broke backwards compatability with old mediawiki versions. You may want to try using either a newer mediawiki or older LST -Steve Sanbeg 14:27, 1 April 2008 (UTC)

Bugreport: #lsth breaks template expansion/parser functions

wenn I use #lsth to transclude a section, Templates and parser-functions are not evaluated (and are shown as-is, i.e. like </nowiki>User:FreedomFighterSparrow/Sandbox2</nowiki>). If I transclude the same text with #lst, it works. For a demonstration, see here.

We use MediaWiki-1.12.0, LabeledSectionTransclusion is an SVN-checkout, revision 32412. -- Mati 15:30, 25 March 2008 (UTC)

• It isn't a question of #lst or #lsth but you can't transclude the same section twice in the same page (make lsth first and lst second and lsth will work and not lst).--Nbrouard 09:04, 1 April 2008 (UTC)
  • That sounds like there could be a problem with the caching in the new preprocessor. -Steve Sanbeg 14:27, 1 April 2008 (UTC)
• It hase been reported on https://bugzilla.wikimedia.org/show_bug.cgi?id=12906 and the workaround works for me!--Nbrouard 08:04, 8 April 2008 (UTC)

Suggestion for LST tags to act as anchors

Suggestion: Would it be possible for this extensions to be upgraded with the additional feature that the LST tags (to begin sections) also automatically act as anchors, such that the point within in a page where a section begins can be linked to?

On "anchors" I am referring to the functionality described in M:Help:Link#Manual anchors. Dovi 14:01, 31 March 2008 (UTC)

Yeah, I guess we could either normalize the section name or add an id argument, and render it is a span or a tag to get that effect -Steve Sanbeg 14:27, 1 April 2008 (UTC)

Templates

lst does not work when the section tags are transcluded. This was pointed out above in 2006, and you indicated that this was because the parser does not allow XML style tags in templates, and that this was a problem for cite as well. In w:User:Simetrical/Ref test 2, cite seems to work fine at the moment. I did my own test and while lst still does not work, the text between the ref tags comes through fine when ref tags are transcluded -- the same functionality that we want from lst. Are you sure that it is not possible to make lst work properly with templates? --71.17.30.236 02:32, 1 April 2008 (UTC)

That part of the parser has been completely rewritten, but I haven't had the time to fully understand the new one, to see what all the affects of that are. -Steve Sanbeg 14:27, 1 April 2008 (UTC)

I recently began working on a text that requires exactly this functionality. Embedded within the text are letters (in special fonts) that refer to comments made on the main text by a variety of different persons. My idea was to present the text in two formats: One with these letters as links to comments, the other without them (because they interfere with the flow of reading), and letting the user decide which version he wants to use (with or without letter-links to comments). So I tried putting the letter-links within LST tags, and then using lst-x to produce an automatic version of the text without them. That didn't work, of course, because transcluded section tags don't work, as pointed out above. Dovi 20:39, 1 April 2008 (UTC)

Any news on getting this extension to work from within a template? That would dramatically upgrade its functionality! Ethan1701 11:09, 3 October 2010 (UTC)

Seriously, that would make this extension work wonders for dynamic articles. But, Steve Sanbeg hasn't been around for a while, maybe somebody should try to edit the extension themselves. I honestly wouldn't know where to begin though. Smile Lee 19:47, 28 November 2010 (UTC)

Transcluding from Other Namespaces

I am trying to transclude an article from the User namespace but having problems. For example, I want to do {{#lst:User:Tester|chapter1}}

But that doesn't work. Is there a way to do this? -ahui 99.249.236.178 17:57, 11 April 2008 (UTC)

{{Brian7632416|VersionInfo}} <-(Darn, I can never remember that shortcut.)

Me, too. I wanted to transclude the "Most viewed pages" section from Special:Statistics. Any info on transcluding from "other" namespaces? -Brian7632416 04:08, 16 September 2008 (UTC)

Me, again. I just learned learned about the config setting $wgAllowSpecialInclusion, which, according to Manual:Configuration settings, will "allow special page inclusions such as Special:Allpages}}," but enabling that config doesn't let me transclude all special pages, just {{Special:Newpages}} and {{Special:Allpages}} (so far). I still cannot transclude {{Special:Statistics}}, for example, so I can't get to {{Special:Statistics}}'s section titled "Most viewed pages." Brian7632416 00:10, 20 September 2008 (UTC)

The extension just does the normal transclusion (except defaulting to main namespace instead of template) then pulls out the requested sections. User namespace should work fine; many of the early test cases and examples were done that way. With special pages, it's coded into the page whether they are transcludable or not, although I believe the trend is to make more of them transcludable. -Steve Sanbeg 20:23, 22 September 2008 (UTC)

Bugreport: lsth.php has wrong function call

lsth.php has, in its current revision (rev. 34149), a bug: line 97 of the code calls method_exists with only one parameter, basically the call uses the wrong syntax. The patch is trivial:

Index: lsth.php
===================================================================
--- lsth.php    (revision 34149)
+++ lsth.php    (working copy)
@@ -94,7 +94,7 @@
     $result = substr($text, $begin_off);


-  if (method_exists($parser->getPreprocessor))
+  if (method_exists($parser, 'getPreprocessor'))
   {
     $frame = $parser->getPreprocessor()->newFrame();
     $dom = $parser->preprocessToDom( $result );

(This assumes that the check is indeed necessary. It could just be cut out as well, if that doesn't break older versions) -- Mati 09:34, 3 May 2008 (UTC)

lst bug when used in combination with regular transclusion and footnotes?

Hello, on s:en:On the expression of a number in the form 𝑎𝑥²+𝑏𝑦²+𝑐𝑧²+𝑑𝑢² I use lst to render a footnote spanning two pages. I'm pretty sure it worked before but now the last footnote, at the bottom of the page breaks off abruptly. The relevant pages are s:en:Page:On the expression of a number.djvu/3 and s:en:Page:On the expression of a number.djvu/4. I've tried to fix it by replacing spaces with underscores but it just doesn't seem to work. Is that a bug or is there some kind of trivial error in my markup?--GrafZahl (talk) 15:31, 13 May 2008 (UTC)

Maybe the interaction between noinclude tags and parser functions has changed with the new preprocessor? I haven't had a chance to verify that, but that looks like the most complex part of what you're doing. -Steve Sanbeg 16:13, 14 May 2008 (UTC)

When <section> is itself transcluded

I have a image with the following in the text part:

<section begin=caption />Blah, blah, blah.<section end=caption />

And elsewhere I am linking to image

[[Image:Foo.jpg|thumb|{{#lst:Image:Foo.jpg|caption}}]]

This works a treat, and allows me to store the default image caption in a single place—namely in the image.

However, sometime I would the caption text to itself be generated by a template. E.g. with Template:caption defined as:

<section begin=caption />{{{text}}} &copy;&nbsp;{{{author}}}<section end=caption/>

…which I would like to invoke in the image text as:

{{caption|text=Blah, blah, blah|author=Joe Blogs}}

When I view the image page directly, this renders the caption correctly. However, when I try to include the caption elsewhere via #lst, it fails—seemingly because it tries to locate the 'caption' section before the {{caption}} transclusion has been processed.

Is there any way around this? (I'm using MW 1.12.0 with PHP 5.2.0 and subversion snapshot r36656 of LST.) —Ras52 00:07, 27 June 2008 (UTC)

I don't think there's an easy way to change the order the parser does things; it will look for the section first, then parse it. So I think the only way around it would be to move the section outside of the template call, i.e. <section begin=caption />{{caption}}<section end=caption/> -Steve Sanbeg 17:12, 27 June 2008 (UTC)

Transcluding Links Problem

I am running v1.12 of Mediawiki and have run into a problem with LST that occurs in Firefox 3.0 but works as expected in IE7. If I have a document 'B' from which I am transcluding a section 'S' into a document 'A' where the section to be transcluded contains local links to document 'A' i.e., [[#LinkToSomewhereInA]] it looks like the links in document 'A' are active, but when clicked they do nothing.

If I hover over the link I can see on the status line that the correct url is being selected. I need this to work in both IE7 and FF3. Can anybody help? Pmcintosh 15:33, 1 July 2008 (UTC)

lst and templates

Hello, this isn't working regarding the {{{text|}}} function in templates, meaning I can't specifically transclude the variable created from the given text that is submitted into the template. If that doesn't make sense, I'll try again:

{{SomeTemplate
|Number=100
}}

----
On the template page:

Template:SomeTemplate


Number: <section begin=NumValue />{{{Number|}}}<section end=NumValue />

Number2: {{#expr:{{#lst:{{PAGENAME}}|HealthValue}} / 10}}

Number3: {{#expr:{{#lst:{{PAGENAME}}|HealthValue}} * 40}}

It doesn't accept this function, is there a way to fix this? Right now the only way to get it to work is by replacing {{{Number|}}} with an actual number.75.85.8.65 07:02, 13 October 2008 (UTC)

You know, I really hate it when it logs me out like that... Daedalus969 07:02, 13 October 2008 (UTC)

A couple of questions

I have read through the documentation and the discussion page, but have not found the answer to three questions. I wonder if someone would help me out. First, is it legal to transclude a labeled section on the same page in which the LST reference occurs? Second, what happens if a LST call is made to a non-existent section on a page (hopefully the null string is returned). Third, early during the discussion it was suggested this extension is intended for deployment on the wikimedia projects. Will this be automatic or should we lobby for its inclusion? Thanks, Dnessett 23:39, 27 June 2009 (UTC)

I have experimented and found answers to the first two questions, so no need to reply to them. However, see next section for a possible bug. Dnessett 16:14, 29 June 2009 (UTC)

To clarify what this extension does a bit, it uses the normal transclusion to get the text, but allows flexibility in what section you want to choose. In affect, it's just a more flexible variation of the includeonly, noinclude & onlyinclude tags; where instead of defining sections by intended behavior, they're defined by name, and the behavior is selected by the transcluding page. So it would only be a bug if the extension does something unexpectedly different than regular transclusion. There is a loop detection in mediawiki to prevent pages from transcluding themselves, which sounds like what you're hitting. -Steve Sanbeg 16:35, 30 June 2009 (UTC)

Thanks. By the way, I think this is a very useful extension. I am fairly new to wikimedia projects, so I wonder what one has to do to make the case of installing it on one of these projects. It appears that the wikimedia servers are pretty heavily loaded and consequently there is great reluctance to install new extensions (correct me if I am wrong). If my reading is correct, does that mean attempting to get new extensions installed on project servers is unlikely to succeed? Dnessett 14:34, 1 July 2009 (UTC)

Thanks. The extension was written for wikisource, and is already active on all of the language projects. It should be reasonably straightforward to add to other small projects if there's community support. For big projects, i.e. the wikipedias, there is a higher standard for the load on the system, although I think any issues there were resolved when it was migrated to the new preprocessor. Tim Starling, who wrote the preprocessor, also migrated this extension, and is one of the people who decided what's active where, so you could check with him. -Steve Sanbeg 15:47, 12 August 2009 (UTC)

bug?

I was playing around with the features of this extension and wondered if I could build a counter. The documentation suggested otherwise, but I tried anyway. So, I opened a sandbox and entered the following: <section begin=Count />0<section end=Count />{{#lst:|Count}}. On preview this produced '0'. I then entered <section begin=Count />0<section end=Count />{{#lst:|Count}}<section begin=Count />{{#expr: {{subst:#lst:|Count}} + 1 }}<section end=Count />{{#lst:|Count}}. Somewhat surprisingly, on preview this produced '0 1'. Ahah, I thought, maybe I can build a counter after all. Then I entered <section begin=Count />0<section end=Count />{{#lst:|Count}} <section begin=Count />{{#expr: {{subst:#lst:|Count}} + 1 }}<section end=Count />{{#lst:|Count}}<section begin=Count />{{#expr: {{subst:#lst:|Count}} + 1 }}<section end=Count />{{#lst:|Count}}. On preview this produced: '0 1 1'. Not what I expected. It looks like the extension performs the first redefinition, but not the second. If it acted according to the documentation, it seems to me preview should produce either '0 0 0' or '2 2 2'. Dnessett 16:25, 29 June 2009 (UTC)

Even more confusing behavior: I continue to play around with the functionality of this extension. I had the last bit of markup above in a sandbox (named Second Sandbox). In a third sandbox I entered: =={{#lst:Second Sandbox|Count}} Title==. On preview, this produced: '011 Title' in header 2 styling. This suggests each redefinition of the section "Count" is concatenating the new value with the old value, rather than adding the values. This explains the behavior reported above (the redefinition returns a string and the parser is interpreting the '+' as string concatenation), but it is somewhat surprising. Dnessett 17:09, 29 June 2009 (UTC)

More on this problem: OK, I think I have figured out something. I removed the 'subst:' from the LST calls inside of the '#expr' calls in my most recent experiments, since when you save the experimental text, evaluates to the null string. This means 'Count' is null until the whole page is evaluated. {{#expr: {{subst:#lst:|Count}} + 1 }} becomes {{#expr: +1 }}, suggesting the parser is not interpreting the '+' as string concatenation. However, =={{#lst:Second Sandbox|Count}} Title== in a third sandbox still returns '011 Title'. Not sure why this is happening, since contrary to first paragraph in this report, in my experiments the section (re)definitions and LST calls are on separate lines. The output from this is '0 <br> 1 <br> 1'. Transcluding a string with linebreaks should separate the parts of the header onto separate lines, which breaks the heading syntax (i.e., '011 Title' should not appear in heading styling). Furthermore, it isn't clear how the redefinitions of 'Count' produce the string '0 1 1'. During page rendering 'Count' is null until some event occurs. It then should either equal 1 (the most likely possibility) or perhaps 0. So,the behavior of LST in this usage is still confusing. Dnessett 18:41, 29 June 2009 (UTC)

GOT IT After rereading the documentation, it is now clear what is happening. You can have multiple sections with the same name. In that case LST concatenates all of the section text. So, the first <section begin=Count />0<section end=Count /> provides the character 0. The second provides the next character (1) and the third provides the third character (1). Sorry for this somewhat loquacious exploration of LST. However, the experiments did demonstrate one thing not in the documentation. If you attempt to reference the value of a section within a page that defines the section, the result is the null string. Dnessett 18:55, 29 June 2009 (UTC)

Parser Caching

I'm having a problem with the latest svn and mediawiki 1.13.1 when having parser caching on. The problem is that after I edit a page with #lsth parser directives the page is then rendered such that {{#lst:XXX|YYY}} is rendered as a link as if it were [[XXX]]. This only seems to happen for the user that edited the page. The transclusion happens correctly for other users. Likewise for the user that edited the page the transclusion works when previewing the page, but the submitted page exhibits the problem. I can provide debug logging if needed. For now, I've turned off the parser cache. Any ideas what the problem might be? Eisner 20:00, 11 August 2009 (UTC)

It's not entirely clear what you're experiencing, but I can clarify a bit on how transclusion works. When there is an error transcluding a page, such as something that doesn't exist, or is transcluded from itself, that is rendered as a link to the page and an HTML comment describing the error. So things to check are the exact message in the comment, and whether the behavior is different between using the extension and doing a regular transclusion. -Steve Sanbeg 15:53, 12 August 2009 (UTC)

Compability with preload

would be nice if this could be compatible to preloading text somehow. Preloading a specified section somehow. This would allow new ways of creating template documentations with usage examples which could be simply preloaded in new articles without creating them twice on another page! --Danwe 14:14, 3 December 2009 (UTC)

How can templates know they are acting on a transcluded text?

In a sectionX which will be transcluded from a page with Pagename, I have certain terms which are embraced by a template, named TextTerm, like {{TextTerm|Demography|10}}, which will transform the first argument in bold face and link to the second argument which is a page i.e '''[[10|Demography]]'''. But in the page which will show the transcluded section, I don't want the link, only the bold face '''Demography'''. And thus the Template should be something like: {{#iftranscluded: | '''{{{1}}}''' | '''[[{{{2}}}|{{{1}}}]]''' }}

I am using it on http://en-ii.demopaedia.org/wiki/Demography which transcludes section 101 of page 10 http://en-ii.demopaedia.org/wiki/10#101 . But on the Demography page, other TextTerms which are in the same section 101 of page 10 would benefit of not being links because they refer to the same transcluded section 101: Population, Universe, Sub-Population, Inhabitants even if they are different pages for proper indexation.

Any suggestion to do it differently?--Nbrouard 19:03, 27 January 2010 (UTC)

You can use the markup described in help:transclusion i.e. <noinclude>[[</noinclude>text<noinclude>]]</noinclude>, or use the #lst function, which will allow you to mark exactly what you want to transclude in section markers. -Steve Sanbeg 03:04, 1 December 2010 (UTC)

Infinite recursion

With lsth : including from the page itself (yeah I know, totally bad idea) results in the apache process segfaulting, probably out of an infinite recursion. I don't know if it is the case with lst or lstx. The plugin should not crash like this even on this kind of input error. A check could be added for self-inclusion.. but for a longer path of execution, it is probably a lot more complex.

I haven't seen that behavior, although I haven't looked at it in awhile. The parser is supposed to track which templates it's seen, and substitute a normal link if it detects a loop; even transcluding a page from itself shouldn't work. Maybe there is a problem with how #lsth interfaces with that. -Steve Sanbeg 03:06, 1 December 2010 (UTC)

I have reported it on bugzilla - 36157. Beau (talk) 10:40, 22 April 2012 (UTC)

Bugreport: Cannot transclude the same section more than once on a page

If I try and transclude the same section <PageX#SectionA> multiple times, only the first one will be transcluded. Any transclusions of that same section after the first will only show a link to PageX.

This is happening with MediaWiki 1.15.3, ParserFunctions 1.1.1, and LST r44056.

I'm not sure if this is known/intended behaviour? There appears to be a mention of the same problem in #Bugreport:_.23lsth_breaks_template_expansion.2Fparser_functions

I tried disabling parser caching and it had no effect.

same in 1.22

96.49.135.43 02:12, 28 April 2010 (UTC)

Compatibility with Collection extension

I am trying to use LabeledSectionTransclusion-MW1.15-r47897 together with Collection-MW1.15-r48763 on MediaWiki 1.15.3. No other Extensions are active. I am using my own Render-Server.

Transcluding sections works fine within Mediawiki, when I try to render a Collection however all transcluded text turns out missing. Otherwise the PDFs look fine.

Is this a limitation in one of the extensions or is this some misconfiguration on my part?

Thanks for Your Help! --RayTRoX 20:21, 25 July 2010 (UTC)

Collection plugin use his own parser for wiki-markup (not for mediawiki result in html) so I don't see the way to make friendship between Collection and LabeledSectionTransclusion. Any ideas? User:Purre 7:27, 16 Mar 2011 (UTC)

Skipped headings in 1.16.1

We are running on mw 1.16.1 and #lst handles skipped headings properly, but #lsth does not. Is this an existing issue? --XTsukihime 15:08, 1 March 2011 (UTC)

Insert one section twice

I can't insert one section in two different place on the page (1.16)? Is this potentially possible? User:Purre 7:30, 16 Mar 2011 (UTC)

Potential name collision with HTML5

In HTML5, there is introduced a <section> tag, which designates a generic section of a page. Though this tag is not currently whitelisted by the parser, it is conceivable that it might be introduced some years from now. Also, even if the tag is not whitelisted, the presence of a Wikitag which is identical to an HTML5 tag will be confusing and a source of error. Is it possible to choose a new name that will avoid these problems, and deprecate the use of <section>? 203.39.56.36 06:28, 26 July 2011 (UTC)

<lst> seems like a reasonable alternative to <section>. Badon 22:23, 11 December 2011 (UTC)

Use of LSTH inside another parser function

Sorry, this is only vaguely related... I'm trying to include the results of an LSTH call as part of another parser function call.

In my code, the following standalone code works to include the text under the heading 'Mysection' on page 'Mypage':

{{#lsth:Mypage|Mysection}} 

However, I'd like to use this call inside the ExternalData parser to call it for each row returned from a database, like this:

{{#for_external_table: 
{{{fieldName}}} 
{{#lsth:{{{fieldName}}}|Mysection}}
<hr /> }} 

However, in this context, the first value of fieldName is printed correctly, but the text ‘{{{fieldName}}}’ is being passed to the LSTH call, which can't find the page and returns an empty string.

Cheers, Nick

Nevermind, wiki clearly evaluates templates from inside to outside, so I can't see how this could ever work. I've ended up hacking ExternalData plugin so that it detects special strings and calls the LSTH plugin directly to replace the text. Awful, but it works for now... Cheers, Nick 203.39.56.36 08:57, 29 July 2011 (UTC)

Installation issue

Having trouble installing LST. I am a total noob when it comes to php so no doubt have done soemthing bvery obviously wrong but when I put

require_once ( 'extensions/LabeledSectionTransclusion/lst.php' ); 

in my localsettings.php my homepage disappears to be replaced by this:

/[mediawiki]/trunk/extensions/LabeledSectionTransclusion/lst.php 	
Wikimedia  ViewVC logotype
Log of /trunk/extensions/LabeledSectionTransclusion/lst.php

Parent Directory Parent Directory | Revision Log Revision Log
Links to HEAD: 	(view) (download) (annotate) 

Revision 109709 - (view) (download) (annotate) - [select for diffs]
Modified Sun Jan 22 00:57:31 2012 UTC (5 months, 2 weeks ago) by reedy
File length: 13850 byte(s)
Diff to previous 109402

Bug 33868 - descriptionmsg is missing 

Fix line by kgh

Revision 109402 - (view) (download) (annotate) - [select for diffs]
Modified Wed Jan 18 17:12:00 2012 UTC (5 months, 3 weeks ago) by siebrand
File length: 13817 byte(s)
Diff to previous 107784

Remove use of deprecated LanguageGetMagic hook.
Add FIXMEs hackish uses.
Some misc. whitespace updates.

... and so on for about 300 lines! What am I doing wrong?

I am hosted by siteground and I notice all the other require_onces i have done are within "double" quotes and reference the extensions folder at like so

require_once( "$IP/extensions/[...]" );

I have tried editing the line to be consistent with that but it makes no odds. Have I done something stupid? ElectricRay (talk) 21:31, 9 July 2012 (UTC)

Transcluding one section multiple times on a page

This problem has already been mentioned in Bugreport: Cannot transclude the same section more than once on a page and Insert one section twice, but it never seems to have been resolved. When using {{#lsth:}} to transclude the same section two or more times on a page, all subsequent instances after the first generate links in place of the transclusion. This problem can be solved by using {{#dpl:}} calls (from Extension:DynamicPageList) instead, such as

{{#dpl:title=pagename|include=#sectionX}}

in place of

{{#lsth:pagename|sectionX}}

but it would be preferable to have the functionality built-into this extension (both because the syntax is simpler and because not everyone has access to dpl on their wiki). Thanks.

Michael Chidester (talk) 16:05, 31 December 2012 (UTC)

Version for older MediaWiki?

Hello!

Unfortunately this GIT download pages do not show which version supports older MediaWiki versions, just the requirements for the actual version are shown on the extension's main page (this now MW 1.18/PHP 5.3.x). So my question: Which version/revision of LST supports MW versions down to 1.15 and PHP 5.2.x?

Thanks very much! JörgM -- 79.242.14.11 13:53, 16 March 2013 (UTC)

Wikisource markup

I see that section transclusion in Wikisource is using a different markup than the default Extension:Labeled Section Transclusion, with things like ## label ## and {{#section}}. How were these introduced? Installing Labeled Section Transclusion and doesn't produce this behavior, and I've looked through the extension list for Wikisource and don't see any likely candidates. Thanks! ~ ~ Michael Chidester ^(Contact) 02:40, 13 May 2013 (UTC)

The ## label ## markup is a shortened version for done only to make editing more easy and managed by the easy_lst* JavaScript functions in oldwikisource:MediaWiki:Base.js. The shortened version is introduced when the edit form is loaded and converted to the longer version when the page is submitted for preview or save. Tpt (talk) 06:54, 13 May 2013 (UTC)

Translusion only once not more

Hi, i have a template called Template:Person that is as follow:

__TOC__

Hello Mr {{name}}

your address is: {{Address}}

and every time i import contacts in append mode if that person has two entries, on his Page "John" i am getting the following:

the Table of content that is good.

Hello Mr John

your address is: villa n1

Hello Mr John

your address is: villa n2

What i actually want is as follow: Hello Mr John

your address is: villa n1

your address is: villa n2

How can i do that?

#lsth doesn't honor noinclude

MediaWiki v1.21.1 #lsth doesn't seem to honor noinclude tags. If I explicitly declare a section, #lst honors the the noinclude. It would be nice to be able to use #lsth, as I am including a link template in the header of a few pages, and then including the headers all into another page.

Feature Request: Heading Level Drop

It would be nice if there was an optional tag to force all transcluded headers to be reduced one level. Many times, when I transclude a section, I end up with conflicting level 2 headers (and sometimes even lower-level headers). So I end up modifying the transcluded page to either not include the header in the section or to have a level-3 header. Could you add a way to make all transcluded headings drop a level? For example, any h2 would become h3 in the resulting page using the transclusion. --Darenwelsh (talk) 22:26, 14 January 2014 (UTC)

Isn't the purpose of the transclusion / #LST to import that work 'as is' not trying to interpret as something else? — billinghurst sDrewth 14:30, 16 January 2014 (UTC)

Equivalent of "What Links Here"?

In Special:WhatLinksHere you can see all pages which are doing full-page tranclusion (aka normal transclusion) of a wiki page. Is there an analogous special page for LST? Like "Special:WhatSectionTranscludesThis" or something? If not, does anyone know how hard it would be to implement?

--Jamesmontalvo3 (talk) 23:13, 13 February 2014 (UTC)

What links here is what to use, it works fine. LST selectively extracts text for display, the transclusion is just the same. The Wikisources demonstrate this

• page with two sections s:Page:Dictionary of National Biography volume 01.djvu/50
• WLH s:Special:WhatLinksHere/Page:Dictionary of National Biography volume 01.djvu/50
• articles s:Abell, William (DNB00) s:Abercrombie, John (1726-1806) (DNB00)

— billinghurst sDrewth 23:24, 13 February 2014 (UTC)

Possible conflict with ConfirmEdit

Hi

I've been using the #lsth function to format the intro header for subpages and have found a strange problem with the ConfirmEdit extension, or at least I think it's with the ConfirmEdit extension. Basically when I had the ConfirmEdit extension set to check everyone (sysops, etc) about half the time the intro header wouldn't be trans-included into the page and instead I would get a link to the page I wish was transincluded. Additionally only one or none of the semantic properties (I'm using the Semantic Mediawiki extensions) from the intro header would be recorded as existing in the new page during those times the intro header was transincluded.

When I set the ConfirmEdit extension to only check unregistered users, however, the trans-inclusion process seems to work as exactly as one would expect. Of course I plan to run a lot more tests but meanwhile thought I should pass this note on. Christharp (talk) 20:58, 25 March 2014 (UTC)

Renamed source article or section

How do we prevent broken transclusions when the original source page, article or section is renamed, moved, merged, expanded or otherwise not as originally sourced and transcluded? FanX | talk | 03:52, 9 April 2014 (UTC)

Compat.php ?

This file is in subversion, but is not included in the file set acquired by the Extension distributor. Should it be? Is it still required? Does one extension really depend on functions in a second extension which may or may not be installed?

Transclude the section(s) but excluding a section

I would like to inquire about the possibility of adding functionality that instead of allowing transclusion of a selection or transclusion of the entire page without section, would also allow transclusion of a selection and let a section be dropped.

Explanation:

• Currently #lst is for transcluding a certain single section (if it has one parameter), or for transcluding a range of sections (if it has two parameters in which case all of the text from the first to the second is transcuded).
• Currently #lstx is for transcluding the entire page except for any section(s) named in the first parameter (adding a second parameter allows for substitution in place of that first parameter).

This does not allow for the possibility of transcluding a section, or a range of sections, while leaving out certain tagged elements.

The need (with an example): At Hebrew Wikisource we have pages that combine two elements, namely the source text itself and certain navigation symbols that are added with editorial discretion. The latter are not part of the original text, but are still expected to be available in any modern edition. At the same time, there is real value in allowing for an automatic parallel version of the text without the visual interference of those navigation symbols, and this also allows for easier re-use (in terms of copying and pasting the text).

This possibility would be much easier to implement if the following functionality was available:

 {{#lst:Pagename|section1|x=symbol}}

In this case "section1" of "Pagename" would be transcluded, but without any of the elements labeled "symbol". Along the sames lines the following should be possible:

 {{#lst:Pagename|section1|section8|x=symbol}}

In this case the text from "section1" to "section8" of "Pagename" would be transcluded, but without any of the elements labeled "symbol".

Do people have any comments on the idea itself, or on how it might best be implemented? Thanks, Dovi (talk) 04:58, 21 August 2014 (UTC)

Perhaps this sort of thing is usually done via normal transclusion with noinclude? --Nemo 16:53, 23 August 2014 (UTC)

Thanks for your reply (just saw it now). Yes, that is how it is normally done. But by using "noinclude" you disallow ever letter those elements be transcluded. What I am proposing is allowing elements to be labeled with section names, and then when sections of the page are transcluded there will be an option not to include things with those section names. Dovi (talk) 15:51, 1 January 2015 (UTC)

Section title contains a template

Hi,

On some Wiktionaries, like the French, section titles contain templates, eg (cf. wikt:fr:careware) :

=== {{S|étymologie}} ===

We can't transclude this with

{{#lsth: careware | {{S|étymologie}} }}

or even

{{#lsth: careware | {{S|étymologie}} }}

Is there a way to transclude this? I read some of the extension page, but not found any answer.

Thank you by advance, Automatik (talk) 23:17, 7 March 2015 (UTC)

Have you tried:

{{#lsth: careware | Étymologie }}

-- [[User:Edokter]] {{talk}} 22:22, 8 March 2015 (UTC)

Yes, it doesn't work. Automatik (talk) 17:16, 10 March 2015 (UTC)

lsth.php

lsth.php seems to have been removed (apparently since [1]) so the installation instructions are no longer correct for

  require_once "$IP/extensions/LabeledSectionTransclusion/lsth.php";

. Does this mean that it's no longer necessary to add this line? Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 09:51, 9 April 2015 (UTC)

According to your link "Merge lsth.php into extension itself" [2], i.e. it is now part of lst.php. Therefore, you don't need to include lsth.php anymore. Nevertheless, the installation instructions need to be updated. Cjahn (talk) 13:11, 17 June 2015 (UTC)

making sections with template error?

Hello. I recently install this extention into my wiki, and then I made this template:

<onlyinclude><includeonly>;<section begin=0 />{{{1}}}<section end=0 /></includeonly></onlyinclude>

The objective of this template is for make auto-section with name of '0' for references, then to enable transclution for references into article page like {{#lst:Pagename|0}}. But after template applied, the Ist does not works: Is it a problem of extension or wiki syntax? - Ellif (talk) 13:25, 21 June 2015 (UTC)

Section tags used inside a template parameter

Coming from the English Wikipedia to post this question, but at Extension:Labeled Section Transclusion#Limitations, it states "As of 2014, section tags don't have any effect when used inside a template parameter. If page A contains a text {{B|X}}, there's no way {{#lst:A|...}} can access X." Is there any fix to this yet? From what I can tell, it has been an issue for a good number of years now. AlexTheWhovian (talk) 11:38, 22 July 2015 (UTC)

?? AlexTheWhovian (talk) 19:54, 3 October 2015 (UTC)

HELLLOOOOO?? AlexTheWhovian (talk) 10:10, 19 November 2015 (UTC)

A way to check if a section exists?

Is there a way to check whether a certain page contains a certain section? If not, can you please add a way to do so? Thanks, אלישיב ליפא (talk) 19:36, 19 September 2015 (UTC)

By passing $wgNonincludableNamespaces by the use of {{#lsth: function

So not sure if this a bug, mistake, etc., but I tested the following and found Label Section Transclusion bypasses the $wgNonincludableNamespaces setting. The test I did was:

$wgNonincludableNamespaces[] = NS_MEDIAWIKI; was set in the LocalSettings.php

I tested it with:

{{:Mediawiki:Common.css}}

and as expected only a link appears on the page I'm including it on. But if I use:

{{#lsth:Mediawiki:Common.css}}

The whole contents of Mediawiki:Common.css print out on the page since Mediawiki:Common.css has no headings to end an introduction.

Thoughts?

Christharp (talk) 04:51, 4 December 2015 (UTC)

Query about syntax

At Europa Universalis IV Wiki there are sections like <section begin=Form Mughals/>. Now saying {{#lst:Mughals|Form Mughals}} does the expected thing rather than only paying attention to the Form, i.e. if there's another section like begin=Form <something>, that one doesn't get transcluded. (On the other hand, {{#lst:Mughals|Form}} transcludes the others as well.) But this is unlike any other SGML-ish language I've ever seen: if HTML had such an element, this would set the begin attribute to Form and add another empty attribute Mughals. I'd like to write a program that automatically generates section tags from identifiers that look like flavor_fra.9100, and due to this weird behaviour, I'm unsure what would be valid. So what exactly is the syntax of the <section> opening tag? Hairy Dude (talk) 16:39, 27 January 2016 (UTC)

Reading the source, it looks like it just takes everything from the section= to the /> as the label. It looks like HTML, but it isn't, at all. Documenting. Hairy Dude (talk) 16:57, 27 January 2016 (UTC)

With Extension:Translate

But LSTh of Help:Extension:Translate/Page translation example#Step 4: Making changes, which has Translate markup, fails:=== Understanding how changes are impacting translations and translations units ===

Processing changes

Tracking changes is a very important feature, so let's make some changes and see how it works. When you open the page for editing you will see that it has been modified with markers like <!--T:1-->. These are added by the extension and help it identify which unit is which. This allows you to rearrange and edit those units. When editing the page, the markers should be left alone and their position in relation to the unit they belong to should not be changed. When moving a unit, move the unit marker, too.

When deleting a unit, delete the marker too. When adding new paragraphs, new markers will be added by the software. Do not try to do this manually, it may confuse the software. Markers you have deleted will also be automatically deleted by the bot in the existing translations.

If you do minor changes to an existing translation unit (adding a few words or a link to a paragraph), keep the marker. If you change a whole paragraph (delete and rebuilt it), delete the marker. This way, translators will have different tasks, between reviewing a fuzzy translation or create a new translation.

let's modify something!

Here is what you will do:

<languages /> <translate> <!--T:1--> Fréttinga is a small municipality in MungoLand, located on the BaMungo island. It hosts a population of about 400 people. It has some agriculture and fishing. Tourists like to visit it in the summertime. It has marvelous beaches with a lot of seagulls. == Services == <!--T:2--> <!--T:3--> It doesn't have many services. There is a shop, and a car ferry visits the island from the mainland once a day. In 2009 January the roof of the church in the island fell down. It was rebuilt collaboratively the following summer. </translate>

• 10. Make some additions as highlighted above
• 11. Click the "marked for translation" link at the top
• 12. Observe the changes
• 13. Click the "mark for translation" button (reminder: you have to be a Translation administrator for this)
• 14. Return to the original page

If you made translations as suggested in the previous step, you can now see those translations linked at the top of the page. You will also see that the translation is not 100 % up to date. If you go to the translation view, you see that the unit is marked as in need of updating.

Outdated translations will be highlighted by a pink background; the user is told that translation is incomplete.

The translation template view helps you to see what parts of the page are constant in all language versions (the "Translation page template", i.e. the parts outside ‎<translate>...‎</translate> tags) and also shows you if units have been moved around or deleted.

There might be a slight delay before all translated versions are updated, because there can be many pages to update.

You now know the basics, but this tutorial will continue with more things that you are likely to encounter. (it is in wikitext, this LSTh nothingness)

P.S. It stops failing if you substitute. Cpiral (talk) 09:48, 23 December 2016 (UTC)

See Parsing/Notes/Two Systems Problem (for translate tags showing) and Manual:Tag extensions#How do I render wikitext in my extension? (for subst).

Now does LST fail with CX? Yes. Is that why? I guess so. Cpiral (talk) 06:43, 9 January 2017 (UTC)

Possibility of transcluding the section tags via a template

Hello guys,

is there a possibility to transclude the section tags with a template. An example: I want to define a template Definition with the code

{{#tag:section||begin="Definition:{{{title}}}"}}
'''Definition: {{{title}}}'''

{{{definition}}}
{{#tag:section||end="Definition:{{{title}}}"}}

On an article MyArticle I use the above template via

{{Definition
 |title=wiki
 |definition
... definition of a wiki ...
}}

Now I want to include this definition via {{#lst:MyArticle|Definition:wiki}}. However, this does not work. It seems, that I cannot transclude the section tags properly. Is there a way to archive this? Of course I can write something like this:

<section begin="Definition:wiki" />
{{Definition
 |title=wiki
 |definition
... definition of a wiki ...
}}
<section end="Definition:wiki" />

However, I want to transclude the section tags via the template. How can I do this? -- Stephan Kulla (talk) 15:55, 27 March 2017 (UTC)

Hi Stephan,

Unfortunately, this isn't currently possible. LabeledSectionTransclusion looks at the raw wikitext of the page you are transcluding from, finds its markers (<section>, {{#tag:section}}) and only then parses that wikitext, in the context of the transcluding page. Since the template will only be parsed *afterwards*, it just won't find your section markers. A more thorough explanation can be found in phab:T39256#1390633, including a suggestion on how one might go about adding that functionality to the extension. FFS ^Talk 18:57, 28 March 2017 (UTC)