Wikisource talk:Labeled section transclusion

Usefulness
This looks great! I must admit I did not understand exactly what was meant before. This tool would really help us building the variety of texts we need, and eliminating any errors from duplication. It is really unrelated from the other tool I was talking about that Jude is workking on. Which is really more about how Wikipedia would link to the things we built. I also think this is unrealted to to the Template:verse which is about inserting html tags for wikilinks. If I am wrong and this would affect these things (or anyone thinks they should be somehow merged together) let me know. The whole idea of what WS:BIBLE is trying to do looks a whole lot more managable after reading this! The only downside I seee of this system is it will leave the edit screens un-friendly to proofreaders. But of course the benifits outwiegh that considerably, and in the end all these pages will be locked from editng. What do we need to do to get this implemented?--BirgitteSB 14:30, 31 May 2006 (UTC)


 * Hi. This has no direct connection to Template:Verse (which is very cool). The only connection between them would be whether the template itself would be included within the transcluded section. (I personally lean towards saying no, so that the user has the option to cite the verse in any format s/he likes, but this should obviously be discussed.)
 * If a person goes, say to the page for the KJV version of Judges, s/he can edit directly. It is only if s/he goes to a place where a verse or longer section is cited that editing is not direct. In that case there is the need for an extra click to get to the transcluded text: the link appears at the bottom of the edit page.
 * Well, if you like it, go vote for the bug and register support at the bottom of the page! Dovi 18:59, 31 May 2006 (UTC)

Technical issues
Some comments on the possibly tricky issues mentioned by User:Eloquence:
 * Parsing the sections without choking: There may be typos, missing end markers, dupe sections, etc.
 * Comment: Currently, when a section on a page is linked to but the section link is incorrect, the link simply takes the user to the top of the page being linked to. I.e. the section link simply doesn't work at all (and the default is the page). But perhaps here, if the section markers in a text have typos or are missing end links, then treat them like they simply don't exist, and have the user find a red link where he attempted to transclude (the same default just as if he tried to transclude a nonexistent page).
 * Indicating where a section is being used (refined Special:Whatlinkshere, needed for fixing broken transclusions).
 * Question: How does Special:Whatlinkshere currently work for transcluded pages? Why not leave it exactly as it is for transcluded sections of pages?
 * Making sure all the proper table and cache purge operations are done whenever a section is added/modified/removed.
 * Question: Is this any different than the current transclusion of whole pages?

Discussion of alternative solutions
(Moved from project page, where the alternatives are summarized.)

Consider, you can already transclude part of an article by marking it with. You can selectively exclude sections with partial substitution. Although inverting the logic to go from selective exclusion to selective inclusion is somewhat clumsy, it can easily be templatized. Obviously supporting a lot of sections would need a large template, but simpler than a lot of templates in wikipedia.

For example, see User:Sanbeg/Test, which transcludes a test document, one section at a time. This is a hand-written proof of concept that only supports 3 sections; but I can easily replace it with a mahcine-generated version for more sections when I get back to the office. The markup, on either the main document or the transcluded one, isn't complicated; and would be even a little simpler if the transcluded doc was in main space instead of user space.

If anyone has feedback for me, could someone drop a not on my wikipedia talk page? Thanks -Sanbeg 15:51, 5 August 2006 (UTC)


 * Thanks for working these examples out for us to discuss. Just to fill everyone here in on this.  Sanbeg had showed me this solution at Wikimania when I described our need for transclusion.  This really is all over my head, but the onlyinclude solution looks good in these examples.  I would like to know what the more technically inclined people here at Wikisource think of this solution.  --BirgitteSB 22:36, 7 August 2006 (UTC)

Hi, there is nothing presumtuous in proposing other ideas. That's what the wiki-world is all about! I looked at your proposal, but I guess (like Birgitte) though it looks good, but I really don't fully understand how it works. Could you explain it more fully? (I don't think it is "feature creep" to propose something for Wikisource; it has been done before with great results, and in any case this is a very broad function that could have many varied uses for many projects.)

It seems to me that there are basic criterion for how something like this should work:
 * 1) Easy, clear marking-off of sections in the source text (which does not appear when the text is viewed).
 * 2) Marked-off sections do not interfere with each other (i.e. they can overlap).
 * 3) A user-friendly, clear mark that allows transclusion of any combination of sections in any order.
 * 4) The ability to call up any kind of section, including a long section that includes formatting. (Explanantion: We already started discussing and testing a different kind of template that allows calling up small snippets of text. But it is rather violent to the source text, which exists entirely within a template.)

Does the template you propose accomplish these things? Dovi 08:09, 14 August 2006 (UTC)


 * Actually, now that I look at it some more, it seems like Sanbeg's idea it basically the same as what we have been testing at he:, and which was discussed here at Scriptorium some time ago. Namely: To put the entire source-text into a templates. At he: this was done using Parser functions rather than onlyinclude, but the result is the same. This is feasible as a temporary solution, but quite inconvenient for a number of reasons, which were discussed. Have I understood it correctly? Dovi 08:31, 14 August 2006 (UTC)

Template implementation
My thinking is that large sections and small sections are very different, so the solutions may not be the same. In Elegy I Comparative text, I just marked off the sections to be transcluded with &lt;onlyinclude>. If a document has several large sections, then they could be split into subpages, which would make that more manageable.

For small snippets, that would be cumbersome. So here it would be better to mark them off, like partially substitued arguments. I.e. if you put will display TEXT, unless ARG is defined. By marking each section with an ARG like sec1, sec2, etc, then you can selectively exclude sections by defining the corresponding ARGs when you transclude. You should be able to do the same with parser functions, i.e., just seems clearer.

Then, either by putting the body in &lt;onlycinlude> and marking each section, or just using an &lt;onlyinclude> for each section, i.e. &lt;onlycinlude>&lt;/onlyinclude>.

What my template does is to simply invert that logic; you specify which section you want to include, and it transcludes the requested page, selectively excluding the other sections.

I think this template pretty well accomplishes your points 1 & 3. For point 4, it may be better (at least with the current implementation) to use subpages for large blocks, and partial substitutions (like with my template) for smaller blocks.

I hadn't thought about nested sections. I'm tempted to think you could just use a recursive call (maybe two templates to simplify that), which should be fine as long as they don't overlap; if they did, you may need to split them, then glue them together when transcluded. But I haven't seen enough examples where section transclusion would be useful to look into the complicated cases.

A new extension, like a named onlyinlude, would enable a consistent solution for short & long sections; but would probably break badly on nested sections, since the current implementation uses simple regex substitution to select the parts to transclude.

So even if we ultimately want an extension, it may be better to see what we can do now with templates, to have a better ide a what to enhance, then plug the new functionality into the template. -65.119.214.9 15:10, 14 August 2006 (UTC) ack; did it log me out while I was typing that? -Sanbeg 15:12, 14 August 2006 (UTC)


 * The main complaint I have heard in regards to this system is that the template only allow a finite number of transclusions and will have to be edited each time a greater number is needed. It would be nice if poeple could leave some critque here as it really is above my level of understanding.  However I do think this works nicely for single large chunks like Elegy I Comparative text, and I think we should discuss the possibility of using this widely for poetry.  Is it possible to edit to automactically have the tags?  Lastly I also think this can be a useful way to set up a variety of examples to show the developers why we do need an extention and how widely it could be used.  I would like to learn how to use this method for setting up the English at Bible/Obadiah/1/1.  From what I understand of how the proposed extention would work, I think it would be rather easy to learn.  This method has a considerably higher learning curve (as in I cannot figure it out on my own) which is another reason it is not a good permanent solution for the more complicated examples.--BirgitteSB 16:05, 14 August 2006 (UTC)


 * It does allow a finite number of transclusions, but I don't think that should be too much of a problem. I'd assume the number of transclusions should be fairly stable, so if we make it big enough before it goes into widespread use, people won't need to worry about hitting the limit.  Since it's such a simple template, even if we allow a few hundred sections, it shouldn't be too hard to read, probably not too much harder than the tiny version that's there now, and much simpler than several templates I've seen.  Of course, you don't need to understand the template code to use it; only how to mark the text to include, and to call the template.


 * I'm not failiar with . Bible/Obadiah/1/1 Shouldn't be too hard with the template; either by creating another template that would specify a part not to show, or mark each number and section as a seperate section. -Sanbeg 17:23, 14 August 2006 (UTC)


 * Don't forget that we are talking about texts that are divided into literally thousands of subsections, and that it is far more convenient not to have to divide them into smaller independent pages. So number of transclusions is an issue. Also, in regard to the learning curve I agree with Birgitte: The way long pages or short are loaded into templates (we have done a few at he: like this) can easily put off someone who does not understand how to read or edit the code. It is also easy to "break" such templates entirely with small typos in the code (as opposed to a broken section label, which would cause no harm at all except when you try to transclude it).


 * In any case, I put a notice at he: about the discussion here, because it is relevant to our experiments too, and the proposed template may be a useful alternative. But I still think that a simpler, more flexible and far more intuitive method would be valuable. Dovi 17:53, 14 August 2006 (UTC)


 * I've transcluded Bible/Obadiah/1/1. I'm not sure what the practical upper limit is to the number of sections in the template.  I wouldn't worry too much about a few thousand lines of code or a few milliseconds to process it, but if it does get too unwieldy, then we might think about another implementation, which could be called from the template.  I don't know how the relative learning curve would be, but if there's any way I could make this simpler, let me know. -Sanbeg 19:21, 14 August 2006 (UTC)


 * I double checked the template size. A template that allowed 2k sections would be about 34 Meg, which probably would be a bit much for the servers to handle.  So a few hundred sections per article may be more feasible; otherwise you'd need to split into a new subpage every few hundred sections. -Sanbeg 19:33, 14 August 2006 (UTC)

I've finished marking up all of the chapters linked to from Bible/Obadiah/1/1, and put them in Category:Labeled section transclusion targets to make them easier to fid, and to have an obvious link to some kind of documentation for anyone who wonders wthat the markup is for.

I'm still not quite sure how much difference the learning curve would be, lathough that may be because I don't know what to expect from a parser feature. If I were to implement it, I'd probably do something like a combined onlyinclude/ifeq, i.e. &lt;includeifeq:sec|1>....&lt;/includeifeq>. This is slightly simpler that my, but the call to include it would be very similar. -Sanbeg 21:28, 17 August 2006 (UTC)

I've found a few other examples of where this transclusion could be done, and realised that many of them would benefit from a two level section numbering; both to make the numbering more logical, and to keep the inversion template(s) smaller.

But the target would need slightly more complicated markup, i.e.

Then I'd probably make an include template, like (or  if there's only one level) and figure out the logic to have it select whatever helper templates it needs.

Since this would be somewhat complicated, and could affect hundreds of articles in the near future, I thought I'd poke in and see if anyone had any objections/suggestions.

Thanks -Sanbeg 23:33, 18 August 2006 (UTC)


 * I asked brion to take a look at this and he believes "some extension or extension-like marker is probably best". I think the learning curve comes into play as the extension would allow the sections to be labeled in a user friendly manner rather than rely on arbitary numbers which may become hard to keep track of.  The editors I am thinking of will probably be much more familar with the nomenclature of  texts than parser functions.  Also I am hoping the extention could be implemented in a way that on the edit screen there may be line breaks between the markers and the included text.  This way people will immediately recognize the text they want to correct without being scared off by techy stuff they do not understand.  I really do like the way works with poems.  brion thinks my idea to incoperate it into is a very, very bad, but it is still wonderfully usefull to have along with .  However the template hack is not at all popular with anyone I have directed here.  Unfortunately they have only told me so on IRC and not actually commented here for your benefit.  Another advantage to an extention is it would be available to all language editons of WS without having to train non-english speakers on creating these templates.  I appreciate the work you have put into this but I don't see the community giving up on an extention being developed at this point. --BirgitteSB 01:20, 19 August 2006 (UTC)

Template versus extension
Thanks to both of you, Sanbeg for the effort he put into developing this solution and explaining it to the rest of us, and to BirgitteSB for taking it up with the Mediawiki experts on IRC.

In the wake of the template-solution discussion, I contacted User:Eloquence via e-mail and asked him to have another look at the discussion here. With his permission, I am pasting his reply here:

Dovi,

just because you _can_ do something with template syntax doesn't mean you should. ;-) The approach as implemented through Template:Sec is based on hardcoding a number of section identifiers and using the "default value" functionality of template parameters in combination with to display the right ones. The problems I see are:


 * 1) Ugly syntax all over the wiki source text. Syntax should be minimally intrusive.
 * 2) Complex template parsing for a fairly simple task (parser has to test presence of each parameter in the source, filter the onlyincludes, etc.).
 * 3) Putting all kinds of wiki syntax into parameter default values really stretches the parser to its limits, e.g. try putting {||} table syntax in between the.
 * 4) Fixed numbering in the source template means that you'll either have to number everything or will end up with an unmaintainable mess (why is section 3 before section 4, etc.)
 * 5) No way to do alternative scoping (overlapping sections) as far as I can tell.

I would strongly recommend not to uglify Wikisource pages with this, and to lobby for a more specific solution instead. ;-)

(end of Erik's letter)

So let's use the template solution if and when it is urgent and works, but let's keep trying to get cleaner solution implemented. Dovi 16:44, 21 August 2006 (UTC)


 * Thanks BirgitteSB and Dovi for your feedback. I'll hold up on adding new functionality (i.e. the subsections) since that doesn't seem to be the way we want to go at the moment.  Unfortunately, the only group I could find which needed to be created and only needed the current functionality was Bible/Philemon, so I guess it's a bit limited at the moment.

Certainly, I was aware that there are advantages to a parsing feature, although I think a lot of parser features were first done as templates, i.e. #if as.

But, I think that there are a few advantages to the template:
 * it works now
 * it's easier to find sample cases where partial transclusion would be useful while it's currently used.
 * it should be pretty trivial for a bot to migrate from the the template to the feature, or even to change the template to call the feature, and only bot the targets.

Although it's not preferable to a feature, as some of the recent discussions have shown requirements that templates currently can't implement, I think it's very preferable to cut & paste, which would be harder to retrofit. I'd think that it's preferable to waiting to create content; rather than waiting weeks for people to find useful cases and develop the content or retrofit it by hand, we could wait minutes for a bot to migrate them, and have many test cases immediately.

So, not a permanent solution, but possibly a reasonable way to shore up the specification for a feature, and migrate to it. At least now we (or at least I) have a better idea what the feature would like, and some examples of where we're currently using selective transclusion. -Sanbeg 22:30, 21 August 2006 (UTC)


 * Agreed. If there is a useful way to use it now, then let's do so and migrate it afterwards when a feature becomes available. I wonder if such a migration could be done via a bot? Dovi 04:11, 22 August 2006 (UTC)


 * Once it's marked up for machine readable sections, it shouldn't be hard for a bot to read and rewrite them. migrating the caller would require a fairly trivial template substitution (replate the template call with equivalent transclusion).  In the simple case, the callee could also be matched with a regex, if they're all marked up reasonably consistently.  In the complicated case, if things were wildly inconsistent, we'd need a simple parser that can understand the two syntactic elements that are used here, ( &lt;noinclude> and {{{ ) so it could rewrite those.


 * The tricky part in retrofitting this into the existing content was that the human readable markings could be ambiguous; I had to determine which type of marking was used, i.e. just a numbered line or {{verse}}, determine the section end based on that, and compare the numbers with an internal counter to make sure nothing was missed. It worked well in the bible books I worked on, but I don't know about other domains.  Once they're already marked, migrating should be safe & domain independent. -Sanbeg 22:24, 23 August 2006 (UTC)

another propoal
Zhaladshar pointed me to this page. It seems that we had the same problem on fr.wikisource. However I came up with a solution very different from that described above. I do not know which one is better, I did not have time to look at sandberg's one in detail. my solution works with hidden sections. it is possible to selectively hide desired parts of a page when it is transcluded, and it is possible to specify which part of the text should be hidden using parameters.

Here is an example: fr:« C'était alors, quand, les chaleurs passées, » The transcluded page uses the template "NouveauChapitre" as a delimiter. The template "Page" is called with two parameters, "from" and "to". check also here for feedback : http://wikisource.org/wiki/Wikisource:Subdomains_coordination

ThomasV 21:23, 7 September 2006 (UTC)


 * That's interesting. From what I can tell from a quick look, the main difference is that while mine numbers the sections, and only transcludes the selected one, yours names them, and transcludes the entire document, using CSS to hide the unwanted sections.  This does avoid some of the more cumbersome markup and the limited naming, but with the downside that it sends a potentially huge document for the browser to sort out.  Fortunately, the browsers seem to do that pretty efficiently.


 * Specifying from/to in the call instead of marking begin/end of the section is interesting. I think the recommended syntax for the feature so far is unecessarily complex to implement, but since I don't have a test installation currently, I can't play with hacked features yet.  I think using the current template syntax to call the transclusion would be much simpler.  Specifying seperate begin/end markers could be a better way to mark the transcluded doc, but it could also complicate an implementation as a feature, and would make migrating from a template implementation that words this way to a feature implementation that uses begin/end pairs more difficult. -Sanbeg 18:21, 8 September 2006 (UTC)

Thanks, Thomas. I think I understand the concept behind your example, though I am still working on understanding the syntax.

In general, I suggest cleaning this page up. This would involve providing clear summaries of the four current methods being used, and the long discussion being moved the the talk page. The four current methods, as I understand them, are:
 * The simplest is at he.wikisource, namely: putting each small snippet of text on its own page, and transcluding the smaller elements into larger texts. At he: there is now even a namespace for these snippets. This works, is clear and intuitive, but suffers from being extremely labor intensive.
 * Two template-based solutions:
 * At he.wikisource the entire text is put into a template, and sections of it are called up by using the "If" function in the parser.
 * At en.wikisource we have User:Sanbeg's similar solution, discussed at length here, which uses the "onlyinclude" function to call up sections of the text, which is also put into a template for this purpose.
 * At fr.wikisource we have Thomas' solution, in which the entire text is transcluded, but only a selected part of it is displayed.

I suggest writing up clear summaries of each method, with links to examples, in a final section to this page called "Alternative solutions" (or something like that), and moving the long discussion to the talk page. Dovi 18:29, 9 September 2006 (UTC)

A few comments/questions
What should be shown when viewing "C"? Wmahan 04:43, 10 September 2006 (UTC)
 * What happens if you try to transclude a section that doesn't exist? A red link is suggested above, but wouldn't the red link point to a page that already exists? That seems confusing.
 * Can a page transclude another section of itself, directly or through something like "A transcludes B which transcludes A##section"? If so, is there a good way to prevent loops?
 * It seems unfortunate that this would create a completely new type of section in addition to the existing ==Section heading== kind. It seems people might want to do similar things with both, such as create anchors to link to sections (" Article "), have edit links for sections, or have a table of contents listing the sections.
 * Suppose we have the following scenario:

Replies: Thanks so much for your feedback, Dovi 06:46, 10 September 2006 (UTC)
 * Section doesn't exist (or isn't properly labeled, which amounts to the same thing): Perhaps better than a red link, nothing at all should show up. Simple as that.
 * Page calling up a section of itself: I cannot imagine why a page should transclude part of itself. (The idea here is to take a section of a literary text which reappears in other literary contexts. There is no reason it should appear twice in its original context.) We already have the "onlyinclude" function, but a page cannot call up that part of itself. Why should this be any different?
 * New type of section: This may or may not be unfortunate, but it is absolutely crucial because (a) in most cases it will be undesirable to call up the section headings; (b) in many cases this is for small snippets of text that do not even have section headings. However, the additional possibility of transcluding a "regular" section heading sounds both natural and great!
 * In your scenario, isn't it obvious that C should contain only section one of B? Or am I missing something? It doesn't look ambiguous to me, because the section is always associated with a specific page.


 * Thanks for the answers. Regarding the last question, that's what I was wondering--whether sections can be transcluded in from other pages. Wmahan 16:15, 10 September 2006 (UTC)


 * This does touch on one thing I was curious about, which is how much we care about some of those degenerae cases. In the normal case, having the special calling syntax would likely make a more complicated implementation, and limit flexibilty in further extending this.


 * I agree that it would probably be best in most cases to show nothing when a non-existent section is transcluded, or someone tries to partially transclude a template with no sections. But I also have the sense that rather than bloat the code with special handling for these cases (esp. since I haven't seen any mention of them in any of the specifications) we could just as well say that it's an error to do that, and if you doyou should take what you get, even if you get the entire template transcluded. -Sanbeg 15:15, 11 September 2006 (UTC)


 * I notice that in the current version of mediawiki, if one transcludes a page with sections, these are treated as regular sections. Additionally, if there are multiple sections with the same name, mediawiki adds a "_2", "_3", etc to the section name. See what I currently have at User:Eliyak/work/sections. Scroll over the links in the Table of Contents to see how mediawiki has named them. --Eliyak T · C 20:12, 24 October 2006 (UTC)

Begin-end ugliness
Why does the proposal use and rather than and ? The proposed approach seems very anti-XML to me. Illformed documents where a begin has no matching end will not be detected by an XML parser. --LA2 10:49, 10 September 2006 (UTC)


 * The reason is to provide a solution for differing textual traditions for how to divide ancient and medieval books. Simply having "section name" lacks this flexibility, and the feature should be designed for maximum flexibility. The problem of what to do for a section with no matching end is raised above, and it is not such a difficult problem. On the other hand, perhaps it would be doubly effective to allow both possibilities: The more flexible "begin/end", and the easier "section name", depending on the document at hand. Dovi 12:42, 10 September 2006 (UTC)


 * Can you give an example of something that can be done with the proposed syntax that can't be done with matching tags? The proposal mentions overlapping sections, but supposing you had
 * A B C
 * Couldn't this be rewritten in the matching-tag syntax as
 * A B C
 * with the mapping  &rarr;   and   &rarr;  ? Or is that too inconvenient? Wmahan 16:15, 10 September 2006 (UTC)


 * Had to read that a few times ;-). This is of course possible to do, after all any unit of text is always a combination of even smaller units, and can be expressed that way.
 * The major disadvantage, its seems to me, is indeed inconvenience: In most cases, the overlapping divisions have simple labels (numbers or letters). With this solution, you can't simply label them within the text according to their normal labels. Dovi 18:55, 10 September 2006 (UTC)


 * Sorry if my description was rather opaque. Yes, the idea was to break everything into small, non-overlapping sections. I admit I'm not familiar enough with Wikisource to judge the tradeoff between the inconvenience of not allowing overlapping sections, versus the slightly less elegant syntax. Wmahan 03:03, 11 September 2006 (UTC)


 * As I recall, these XML-like elements aren't really parsed XML; the parser just uses a regex to match the begin/end. This works because they are simple and not nested.  Doing more complicated nested, where it's harder to figure out which begin/end tags match, would likely complicate the implementation.  Altough I also don't like having tags with generic names like begin and end, that could be changed by simply reversing the keywords, i.e. ,,, -Sanbeg 15:08, 11 September 2006 (UTC)


 * I'm pretty sure that they are parsed like XML, and the parser is pretty good about figuring out the nested structure of the document. For example, check out Poem extension. So I would support this suggestion ( text ). —dto (talk contribs)  16:58, 12 September 2006 (UTC)


 * Now that I have a working implementation (see below) I can give some more details. The current partial transclusions (onlyinclude, noinclude, etc) are parsed with regexps, and don't support nesting.  I haven't used poem, so I don't know if those can be nested or not, although that would be strange.  Now that I've gotten over my initial aversion to the single tags that are really used in pairs, I don't think it's such a bad idea to be able to insert section markers wherever you need, and not worry about interacting with other sections.  In my implementation, using paired tags would break both normal nested sections (which could be fixed with more sophisticated parsing) and of course the weird overlapping sections.  Although I don't know of any examples where that is useful, but it has been in the spec for awhile, so I'm assuming they exist. -Sanbeg 18:40, 12 September 2006 (UTC)


 * That makes perfect sense. I'm not sure what I was thinking when I wrote my comment above. Thanks for the clarification, though. —dto (talk contribs)  03:57, 14 September 2006 (UTC)


 * I support a syntax with a single tag, and "from ... to" parameters for inclusion, like in my proposal. This is way more flexible than "begin ... end" statements. ThomasV 19:07, 12 September 2006 (UTC)


 * Thomas, this may be a question of needs. For the examples you did at French Wikisource, you don't require "start" and "end." For the stuff we are doing in Hebrew, and hope to do as well in English with links, it is quite necessary. With due respect, I hope we will look for the solution that meets all needs. It is certainly "start" "finish" that is far more flexible in terms of its applications. Dovi 19:39, 12 September 2006 (UTC)

Yet another proposal - simplified feature
Now that we're listing the various altrenatives, I'd like to add another log to the fire, and propose the simplified feature.

Basically, we'd implement section markers in the text, i.e. this is a chapter

Then, we define a special argument when we transclude it; the combination of the special argument and the section marker would trigger labelled section transclusion! i.e.

The template would only define the location of the section; its behavior would be determined by the caller; i.e.

or even

I think this addresses all of the issues that have been brought to my attention in the non-feature implementations, while still being simpler to implement and more flexible than the one with the special calling syntax; I think this extra functionality will make it more useful to other projects as well.

We could also trim leading/trailing whitespace from the included section, and allow individual markers to be placed in templates (like to mark discussions in AFC/AFD header/footer templates).

I have the basic functionality working on my test installation, so if there's no objections I could list this, then do some work on polishing it up and writing a more formal doc. -Sanbeg 16:09, 12 September 2006 (UTC)


 * This sounds totally awesome... Wow.
 * The include/exclude/replace options offer a range of useful possibilities that I never even considered before, and that might prove useful in numerous contexts.
 * Where can your test installation be found? Dovi 19:53, 12 September 2006 (UTC)


 * Thanks. Unfortunately, there's a firewall in the way; as much as love to have some help testing it, I don't have anyplace to install it for that. -Sanbeg


 * whitespace complications: When Birgitte suggested that it would be useful to remove leading/trailing whitespace from the sections, I thought it'd be simple enough to do. Now, though, I'm thinking that if you transclude more than 1 section with the same name, it would make it harder to prevent them from blending together; it would be better if they blended iff you want them to.  I'm thinking to avoid the complications and just remove that function; maybe we could add a parser function sometime to allow trimming that.  I thought I'd see what everyone thought about that; how important trimming is, and what the desired behavior would be. -Sanbeg 21:35, 14 September 2006 (UTC)

examples
I've copied my test page here...


 * user:sanbeg/Sections a page with marked sections
 * user:sanbeg/Includer includes the above (works on my ionstallation, obviously not here)
 * user:sanbeg/Includer (subst) another version of the above, that subst's the transclusions. On my wiki, these look identical; here, you can compate the source of the transclude with the rendering of the subst.

BTW, when you look at user:sanbeg/Sections, you can see the < section ...> render because there's no feature here. With the feature, those would be supressed. -Sanbeg 22:06, 19 September 2006 (UTC)


 * To me this looks outstanding, though of course I lack the technical expertise to really understand its full implications. It would be really great if it could be fully demonstrated on a wiki that is not behind a firewall... But thanks for the amazing effort for something that looks really good. Dovi 13:48, 20 September 2006 (UTC)


 * Thanks; yeah, it would've been nice to let others contribute test cases, too. It isn't too complicated, though; so I guess now we'll see if the patch elicits any response, or follow up on wikitech-l if not. -Sanbeg 22:59, 20 September 2006 (UTC)

Current Implementation Status
Now that I've basically finished my implementation, I've started to try and figure out how to go about getting a feature into Mediawiki. For now, I'll primarily focus on an enhancement to poem; since that's less significant, it should be easier to move throught the process. As I figure out more things that need to be done, I may make some updates to the LST bug entry, so you may see periodic bursts of activity there. But at this point, I don't expect to get useful feedback on that until I find the right people to pester; which will happen once the poem enhancement is far enough along that I have a reasonable understanding of the process.

At any rate, that one does seem to be moving along, and I've recently incorporated both of these into the test system and made a few improvements to them. -Sanbeg 21:44, 9 October 2006 (UTC)

String functions
There would seem to be overlap between this feature and StringFunctions. Certainly, this could be implemented using string functions. I just wanted to bring this up, although I am not familiar enough with the pros/cons of using one or the other in this case. I am also not sure if the string functions are intended to be included in mediawiki by default at some point. --Eliyak T · C 05:38, 22 October 2006 (UTC)


 * The he: attempt to use Parser Functions (of which string functions are a part) actually failed in the end, because it seems there is a very short limit to the number of times such functions can be used for transclusion.
 * In any event, as in discussion above, LST will eventually (we hope) be applied so widely that it deserves a clear, user-friendly implementation of its own, no less so than for basic related functions such as or (which it might be able to replace as a more versatile option). Dovi 07:25, 22 October 2006 (UTC)

Parser functions
I've figured how to do this using an extension, with parser functions. This should make it easier to advocate it, since it means the extension could be installed per project, and won't require modifying the core parser code.

The main changes here are that
 * 1) This is no longer a normal transclusion, so you can't expect noinclude/includeonly, template parameters, etc. to coexist with this; which I don't think was useful anyway.
 * 2) this changes the syntax of the call to use parser functions.

For the new syntax, I'm thinking something like to include, and to exclude (with optional replace). Both would have an optional argument after these for the section ranges used in fr.wikisource.

This syntax to mark section boundaries is unchanged. -Steve Sanbeg 16:14, 3 November 2006 (UTC)

Not enabled?
Is there any specific reason why lst is not enabled yet? Is there anything we can contribute to speed up the activation process?--GrafZahl (talk) 14:33, 13 March 2007 (UTC)
 * A developer needs to approve it for security issues. You can remind them about it as I do now and again.  I don't know of anything else we could do :( --Birgitte SB  18:09, 13 March 2007 (UTC)


 * FWIW... the last "piece" of LST (lst-h) was finally activated on February 4, 2015. -- George Orwell III (talk) 07:25, 8 February 2015 (UTC)

Tools and Eye-Candy
Plz check out TopicTags Extension adds eye-candy and maintenance tools to tagged regions (by mw:User:Johnywhy)

Johnywhy (talk) 21:11, 18 June 2018 (UTC)