Wikibooks:Reading room/Proposals/2011/August

Install the Labeled_Section_Transclusion Mediawiki extension?
I think could be useful in book organisation to allow answers to questions or notes to be collected together at the back of a book. Recent Runes (discuss • contribs) 23:56, 28 July 2011 (UTC)


 * Off hand, I can see it being useful for a centralized page of sourcing information, where the information is transcluded there from distributed other pages; and for a centralized glossary, where other pages invoke glossary entries by keyword to transclude the entry for that keyword.
 * There may be lots of other uses as well, on a per-book basis &mdash; because each individual wikibook may have its own unique structural features, so find its own unique uses for the extension.
 * If I'm understanding the extension page rightly, there's an option to support transcluding sections by heading . I suggest we opt for that.  The more flexibility we provide, the more interesting uses might be found by individual books.  --Pi zero (discuss • contribs) 02:56, 29 July 2011 (UTC)
 * This may solve the request made on Bug 10092 (Separate reference page for glossaries, bibliographies, etc). Helder 20:26, 4 August 2011 (UTC)
 * Seems like a good way to provide more options for editors. All the questions and answers on one page for printing, but selective transclusion in each chapter for assessment. – Adrignola discuss 22:03, 29 July 2011 (UTC)


 * Does anyone expressed an interest in using it ? If not, I don't see as a good practice to enable extensions that at a later time can result in collision (something else does the same function) or complicate the resolution of technical problems. --Panic (discuss • contribs) 22:48, 29 July 2011 (UTC)


 * I suppose the basic Mediawiki software or the Collection extension might be changed in future to perform a similar function, but I don't know anything about the future plans for these or if they even have any! Presumably, continuing support of this extension would be more assured if it is already used by a number of high-visibility pages. It would be interesting to know how much it is used on the projects which have installed it already (meta.wikimedia.org, *.wikisource.org, and en.wiktionary.org). Could that be checked? Recent Runes (discuss • contribs) 19:25, 1 August 2011 (UTC)


 * I've inquired at the . Having noted the extension was apparently made to order for Wikisource.  --Pi zero (discuss • contribs) 17:34, 2 August 2011 (UTC)


 * From the feedback my inquiry is getting, it seems Wikisource is heavily invested in this extension. --Pi zero (discuss • contribs) 16:49, 3 August 2011 (UTC)


 * They all mention an interconnection with the use of Extension:Proofread Page.
 * Is there a page that lists all the extensions we have active on Wikibooks ? And is this mw:Category:Extensions used on Wikimedia a list of the ones that are available to be used ? --Panic (discuss • contribs) 01:56, 4 August 2011 (UTC)
 * You'll find the list of extensions used on English Wikibooks at Special:Version. Helder 20:26, 4 August 2011 (UTC)
 * I can understand Wikisource using Labelled Section Transclusion and Proofread Page together, but I wouldn't expect them to have any coding interdependencies . (Apparently Proofread Page does use the #lst function of Labelled Section Transclusion, but I have not seen any dependencies in the other direction.) Recent Runes (discuss • contribs) 20:31, 4 August 2011 (UTC) Recent Runes (discuss • contribs) 19:38, 5 August 2011 (UTC)
 * Yes they are not interdependent like User Daily Contributions (Version 0.2.0) and Vector/WikiEditor (taken from the list above) but seem complementary.
 * I could see some uses for it, especially to address some issues we have with transclusions, this would help me at least. It does however seem a bit complex to normal users (that often do not understand transclusions at all) in any case I'm not opposing the adoption. For adoption do you need a specific number of supporting votes ? or does non-opposition to your proposal suffice ? --Panic (discuss • contribs) 01:14, 5 August 2011 (UTC)
 * I suppose we could follow the regular consensus process and have a straw poll while allowing time for input from anyone who might be on holiday. Recent Runes (discuss • contribs) 19:38, 5 August 2011 (UTC)

Apparently, collections won't include the transcluded sections that this extension includes, a section can only be included once on a page with this extension, and this extension uses a tag name that is reserved for use by HTML 5. --dark lama  20:09, 5 August 2011 (UTC)
 * My understanding of the technicalities is quite superficial, but there is a message that talks about "loading the Labeled Section Transclusion extension before Collection in LocalSettings.php" on the google group for mwlib which might be relevant. If the compatibilty with Collections can be fixed, then it might be possible to replace the potentially clashing "section" tag by "#section" or something else before compatibility with HTML5 becomes a problem. The feature that each section can only be transcluded once per page may be an acceptable limitation that would not prevent many useful applications. I would like to remain cautiously optimistic until we have more definite answers to these issues. Recent Runes (discuss • contribs) 11:51, 6 August 2011 (UTC)

Set $wgRestrictDisplayTitle to false
The script MediaWiki:Common.js/Displaytitle.js and the template Template:Displaytitle use javascript to replace the content of the top heading of a page. Rather than using javascript to change the title, I think it would be better to just set $wgRestrictDisplayTitle to false and use DISPLAYTITLE: to have the content there from the start. --Yair rand (discuss • contribs) 21:35, 8 August 2011 (UTC)
 * Although wgAllowDisplayTitle could be set to false, this is not recommend by the developers, as it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it..
 * For changes in titles such as French/Lessons/Introductory/Review (done through [ this template]), I think it is better to create (per book?) gadgets for people who want to have non-linkable, but nice, titles. Another option is to add the original title somewhere in the page as is done by pt:MediaWiki:Gadget-Títulos simples.js (see example), so that we still have access to the original title for copy+paste. Helder 13:07, 9 August 2011 (UTC)
 * PS: The part of the script which process the tab parameter doesn't seems to be working in all skins, e.g. at [ Cookbook:Carrot?useskin=vector] and [ Cookbook:Carrot?useskin=nostalgia], so I think it should be either fixed or moved to the JS pages corresponding to the skins where it works (MediaWiki:monobook.js, MediaWiki:modern.js and maybe some other skin). Helder 13:25, 9 August 2011 (UTC)
 * I've updated it to reflect a change that must of been made to id attribute, so the namespace tab/link should be working again in all skins that have one. --dark lama  14:43, 9 August 2011 (UTC)
 * In some skins (at least vector and chick) the first letter of the tabs is in Uppercase while on monobook (and some other?) it is in lowercase. Could you make the tab link to be consistent with the other tabs depending on the skin?
 * PS: It is good practice to prefix with "$" the name of a variable whose value is an instance of jQuery (such as $dt and $what). Helder 15:27, 9 August 2011 (UTC)
 * Template:Displaytitle is already in use. How is allowing DISPLAYTITLE: to modify the title worse than using displaytitle to modify it through js? --Yair rand (discuss • contribs) 03:07, 10 August 2011 (UTC)
 * Will editing of a page still show the real page path if $wgRestrictDisplayTitle is set to false ? Will it break any of our extensions ? (a change would require us to inform devs that they shouldn't continue to assume the flag as true) Has any other project altered the flag (Wikisource) ?
 * I think that the notion that "it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it." is important but to a lesser degree in Wikibooks. We often link to books, not to specific book pages, this mostly occurs inside the same book. Since displaytitle is available to modify the displayed title (and people are using it actively, I was not the first to see some benefits for Wikibooks specific needs). If the final result is the same I don't see why we shouldn't simplify the process.  --Panic (discuss • contribs) 04:06, 10 August 2011 (UTC)
 * Even when displaytitle is restricted, the edit page still shows the real page path regardless of displaytitle (see for example ), so it probably also does when $wgRestrictDisplayTitle is set to false. --Yair rand (discuss • contribs) 07:32, 10 August 2011 (UTC)


 * Symbol support vote.svg Support. So we can set $wgRestrictDisplayTitle is set to false, then to handle existing uses, have displaytitle use DISPLAYTITLE with a parameter. Though this would lose the tab name changing functionality, I wouldn't bemoan that and changing the basic interface is probably more objectionable than changing the title.  Changing displayed titles is consistent with pages on the Web that have titles chosen by the page's creator.  displaytitle does not show the page's real title when editing; see .  So if this setting does show the real title, it could be a superior option.  I do like situations like Muggles' Guide to Harry Potter/Books/Half-Blood Prince showing "Harry Potter and the Half-Blood Prince" and having the tab changed to "Book 6".  Few books change the tab, but the Cookbook changes it for all ingredients.  But special JavaScript could be used for the Cookbook, with everything else using the built-in function or the transition template.  At minimum it would open up an option for having titles altered without being dependent on JavaScript. – Adrignola discuss 14:06, 10 August 2011 (UTC)
 * I support not needing JavaScript for features whenever sensible. I think this is one such case. I know can be made backwards compatible by using the DISPLAYTITLE magic word to change the title while still using JavaScript to change the tab. --dark  lama  15:50, 10 August 2011 (UTC)