Template talk:Section link/Archive 1

Archive 1

Subpage links render a fullpagename

Can it expand subpage links to the fullpagename? See testcase 12. It links fine, but it looks funny? — CpiralCpiral 08:44, 13 December 2015 (UTC)

 Not done. That's not what the template is for. It is for linking sections of pages. To make subpages look like sections would completely confuse people.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:39, 21 March 2016 (UTC)

Multi-level section links

Is it possible to use this (or another) template to generate links showing a series of subordinate heading levels? For example, Wikipedia:Manual of Style/titles hatnote include is used as a template to produce the following hatnote that appears on various MOS pages:

For complete guidance on the handling of titles of works, see (until the material is better consolidated): ...

• WP:Manual of Style § Punctuation §§ Quotation marks §§§ Names and titles (summarizes details at WP:Manual of Style/Titles)

That link is manually formatted with a pipe link, but it would be convenient to have a template that could reproduce this, e.g.:

{{section link series|WP:Manual of Style|Punctuation|Quotation marks|Names and titles}}

This would be especially useful because sometimes the lower-level heading does not provide proper context, e.g.:

• Wikipedia:Manual of Style § Choice of format

is much more ambiguous than:

• Wikipedia:Manual of Style § Dates and time §§ Days §§§ Choice of format

—sroc 💬 15:04, 22 March 2015 (UTC)

@Sroc: It would be easiest to make another template for this; {{section link}} already uses positional parameters to specify multiple pages, so we wouldn't be able to use the syntax that you suggested. As for a name, how about Template:Multi-section link? To me, "section link series" sounds like it could be the title of a navbox listing section link templates or something similar. — Mr. Stradivarius ^{♪ talk ♪} 01:08, 23 March 2015 (UTC)

Well, I went ahead and created it. Let me know if you think a different template name would be better. :) — Mr. Stradivarius ^{♪ talk ♪} 01:47, 23 March 2015 (UTC)

@Mr. Stradivarius: Brilliant! Love your work! Thank you. —sroc 💬 04:51, 23 March 2015 (UTC)

This could be merged, or the same features added here: {{Section link|1=Wikipedia:Manual of Style|1a=Dates and time|1b=Days|1c=Choice of format}}; it was actually already on my agenda to propose this (from last year; I forgot about it). My and someone else's request above to fix the comma and semicolon thing was needed first.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:45, 21 March 2016 (UTC)

Simpler syntax for intra-article links to section.

Hi.

Currently, this template works this way:

Syntax	Equivalent	Output
{{Section link|Example}}	[[Example#Notes|Example § Notes]]	Example § Notes
{{Section link||Example}}	[[#Example|§ Example]]	§ Example

Now I am asking myself if this is not an unnecessary. How Wikipedia pages (not just articles) have a section called "Notes"? When they do, how many times does an editor need to link to "§ Notes", with all the <ref>...</ref>, {{efn}} and {{ref}} that we have? Shouldn't we make it so that when only a single parameter is given, it is construed as a section link? I mean:

Syntax	Should be equal to	Output
{{Section link|Example}}	[[#Example|§ Example]]	§ Example

What do you think?

Best regards,
Codename Lisa (talk) 17:05, 22 December 2014 (UTC)

I agree that the current behaviour of the template with the second positional parameter omitted is nonsensical. However, changing the positional meaning of a parameter (with the first taking on the function of the second when the second is omitted), as suggested above; that is simply irregular. A more sensible approach would be to link to the lead of the article when the second parameter is empty or omitted. —Quondum 04:27, 3 March 2016 (UTC)

That has the same this-function-is-useless-and-confusing problem. "How many times does an editor need to link to section 0, when they can just link the article title, or if in same article, link to #top?".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:55, 21 March 2016 (UTC)

• Support. This makes eminent sense, and it would be more convenient than {{Section link|Example}}, which is far more "irregular". There are actually plenty of templates that treat the first parameter differently depending on the presence of a second, and people's heads no asplode.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:55, 21 March 2016 (UTC)

  Please clarify. "Support" seems to be for exactly what you are calling irregular here (i.e. you seem to be contradicting yourself).

• Comment: While I support removing the current nonsensical default "Notes" interpretation, I think it should simply link to the article when the second parameter is omitted. There is no utility to changing the interpretation to linking to the current article, since that is already provided by the empty first parameter option. —Quondum 15:21, 21 March 2016 (UTC)

Spacing after §

I find the space after the section character produced by this template (and by {{multi-section link}}) mildly problematic:

• It is unusual; in print I recollect seeing it with no following space; it also seems more intuitive without a gap.
• The gap allows wrapping at the end of a line between the section character and the first word of the section name; this should not be allowed.

I would like to see this gap removed, e.g. Speed of light §Measurement. —Quondum 13:36, 20 June 2015 (UTC)

It should be using a non-breaking space after the section character (§), just like {{section link}} should. This ought to be covered at Wikipedia:Manual of Style/Linking § Principles §§ Link specificity §§§ Section links. —sroc 💬 15:11, 20 June 2015 (UTC)

@SMcCandlish, Mr. Stradivarius, Quondum, and Sroc: The space should actually be U+202F   [[ |NARROW NO-BREAK SPACE]], which would restore the non‑breaking functionality lost when we replaced “ ” with “ ” —LLarson (said & done) 18:45, 25 February 2016 (UTC)

Many of the spacing characters do not work cross-browser yet, and that might be one of them (I know that  , the hair space, is one of them.) The most certain way to do this is with <span style="white-space: nowrap;">§&thinsp;...</span>}}: Use the thin space character, which definitely has no such support problem, between the section symbol and the content and use a the same CSS in {{nowrap}} around it to stick them together. And, yes, we should document this, and apply it consistently. I do support retaining some space, it just need not be a large one. It improves readability, searchability, and other usability (e.g. select and copy-paste) to not run the section character up against the text to which it pertains. There is no hard-and-fast rule about typography of the section symbol across all off-WP style guides; both the unspaced and spaced style are common. PS: I learned of the hair-space issue when I used it to slightly space the em dash away from the attribution in quotation templates, and people complained within hours that they were seeing a garbage character there.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:02, 25 February 2016 (UTC)

This proposal is better than mine. Cheers! —LLarson (said & done) 21:10, 25 February 2016 (UTC)

I cannot distinguish   from  , but let's rather stick with capturing the intent with the hope that fonts and browsers will become more consistent. I also agree with SMcCandlish's proposal as the most sensible of the options that I see. —Quondum 09:10, 26 February 2016 (UTC)

@Quondum: Its rendering varies by font; there are fonts in which the two are the same width.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:49, 21 March 2016 (UTC)

I realize this; it was implied by my mention of inconsistencies. —Quondum 15:27, 21 March 2016 (UTC)

Now that there's consensus for SMcCandlish's "white-space: nowrap;">§  at Module:Section link, these tests are missing:

• Resizing window to test template nowrap of "§ Practical" in Speed of light § Practical effects of finiteness
  
• Resizing window to test sandbox nowrap of "§ Practical" in Speed of light § Practical effects of finiteness
  

— CpiralCpiral 22:28, 3 March 2016 (UTC)

Note: If the thin space isn't quite as narrow as we like, it can be kerned a little with CSS; I have a bunch of virtual machines I can test that in, if we care that much.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:05, 4 March 2016 (UTC)

I'm still getting this, (and nothing's changed at Module:Section link):

Resizing window to test sandbox nowrap of "§ Practical" in Speed of light §
Practical effects of finiteness — CpiralCpiral 19:46, 4 March 2016 (UTC)

User:SMcCandlish, kindly implement the thinsp and nowrap. My window-resizing tests show no implementation of the above agreements concerning the spacing and wrapping has been done. Thank you. — CpiralCpiral 21:22, 20 March 2016 (UTC)

Added it to my todo list.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:37, 21 March 2016 (UTC)

Honestly, I'm just too busy with real work lately to deal with this kind of stuff right now. Someone else will need to implement this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:49, 10 June 2016 (UTC)

Template-protected edit request on 8 June 2016

I updated the module’s sandbox^[1] and testcases to reflect this discussion. —LLarson (said & done) 02:41, 9 June 2016 (UTC)

@Cpiral, SMcCandlish, and Quondum: Pinging for awareness. These changes look fine to me. Resizing the window to see the output of Cpiral's test right on this page looks fine too. — Andy W. (talk · ctb) 05:05, 9 June 2016 (UTC)

The diff looks good to me as well. --Izno (talk) 11:36, 9 June 2016 (UTC)

That is a somewhat ghastly hack, which has issues in Chrome BTW (which allows wrapping nested elements), so I disabled it. I do notice that the difference between   and   is negligable; a mere 1px, so why not use that instead? (I find these exotic spaces a waste of time; to space or not to space.) -- [[User:Edokter]] {{talk}} 16:31, 9 June 2016 (UTC)

I'd hardly call it (a nowrap html block, or whatever the appropriate terminology is) a hack. It might use more bytes than nbsp (representational ugliness/verbosity is unavoidable in HTML, and should be overlooked), but it is semantically cleaner. The width argument only suggests that ideally there should be a thinner space available. A non-character (e.g. kerning) instead if this could be considered as an alternative if the thinsp is not so nice. (I am also not particularly a fan of exotic spaces.)

Issues with interpretation by browsers is orthogonal, and I am making no comment on the Chrome observation. —Quondum 17:16, 9 June 2016 (UTC)

Come tho think of it, I wonder if it has actually been tested. Technically, the nowrap only holds until the last character inside the span. Everything after that is free to wrap, or at least subject to browser implementation. In any case, applying half-solutions is the same as aplying no solution at all. Either apply   as it does now, or   if nobreak is really that important. -- [[User:Edokter]] {{talk}} 18:40, 9 June 2016 (UTC)

In the world of HTML, one probably has to be pragmatic. If it works 80% of the time, and is acceptable in the remainder (e.g. if it wraps at that point for 20% of the browsers), any solution is fine. Solutions that work markedly more consistently should perhaps take preference. Any other approach would have us not allowing much on WP. —Quondum 21:11, 9 June 2016 (UTC)

@Cpiral, SMcCandlish, Quondum, Andy M. Wang, Izno, and Edokter: My apologies for the appearance of a hit‑and‑run. I’ve been occupied all day:

1. To my surprise, even though the span doesn’t include the section name, the behavior is exactly as advertised (it removed the possibility of a post‑§ linebreak on a Mac (latest Chrome, Safari, Firefox); Linux Ubuntu via VirtualBox (latest Firefox); Windows XP via Wine (Internet Explorer 8); Windows Server 2008 (Internet Explorer 11).
2. A sleeker narrow no‑break hyphen   (without the nowrap span) works in all of them as well.
3. Even §  and §§  are better than what we have now. —LLarson (said & done) 03:20, 10 June 2016 (UTC)

I support Edokter's   suggestion, but I have no strong preference on approach. — Andy W. (talk · ctb) 03:31, 10 June 2016 (UTC)

Where wrapping separates title and section, bind § to the section. Don't let it associate to the title (as a last word) when it happens at the end of the line. This way it looks better, esp. offline in print. For online use, there is a case to be made to ignore this "mild annoyance", 1) because the mouse performs a visual association, 2) because the mouse-click resolves the situation, and 3) because of browser incompatible rendering problems. These all appear salvageable. I hope that summarizes it.

There seems to be a definite consensus for the validity of Quondum's OP. Resizing the browser window show me that the sandbox version (my tests above) is that consensus. Cheers. — Cpiral§Cpiral 07:39, 10 June 2016 (UTC)

I think it looks awful with a full-width   (and the assertion that there's only 1px difference is silly and wrong; the difference in spacing will depend entirely on font and font size, among other potential factors, like letter-spacing, etc., that won't matter here), and the difference is quite significant to anyone who does typography and uses non-shite fonts because they care about typography and readability. No spacing at all would be preferable to full-width spacing, and it can be kerned with CSS to produce a fractional-em of visual spacing, but copy-paste without a space if that's desirable. But there's nothing "exotic" about  ; it's been around for a long time, and is supported in all browsers (  and its numeric equivalents are a slightly different story, as they don't work in a few old browsers that some people still insist on using, but do work in all modern ones). All that said, I'm just going to take the WP:DGAF route for now. I get tired of fighting with the lowest-common-denominator pundits, and have better things to do. Mangle it however you like; we'll fix it later after enough people complain and drown the punditry out.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:01, 10 June 2016 (UTC)

@SMcCandlish: It was because you knew what you talking about with this issue that I waited for two months before making a proposal. I understand you’re busy and DGAF, but I’d still prefer to see your idea. Especially: typographically speaking, I understand that no break should follow either, but does a narrow space follow §§ as well as §, or is §§’s full‑width?

I’m not sure whom the lowest-common-denominator pundits that intend to mangle the code are, but I’d hope you’d assume that they’re a real person with a good‑faith desire to collaborate. —LLarson (said & done) 12:03, 10 June 2016 (UTC)

I would use the same spacing or kerning between § and the wording following it, and §§ and the wording following, but nothing between the § and § of the §§.  :-) I do assume good faith (and wasn't referring to you), but also assume human nature, including the desire to exert control and engage in politics. We're all hominids here and that ancestry comes out in different people different ways.

Windows/Arial is the platform where I see only a one pixel diference, and that accounts for most of our readers. Seriously, we have to stop trying to micro-manage rendering with these kinds of CSS hackisms. They are anything but pragmatic is they only work for the select few, but add non-functioning payload for others. Come up with a solution that works for everyone, and I'm game. Because I'm sure as hell am not going to do anything that adds non-solutions for something that one may find "awful". When the choice is between pretty-lokking but non-functional solutions, and a solution that works universally at the cost of slightly less prettyness, functionality prevails, without exception. -- [[User:Edokter]] {{talk}} 10:55, 10 June 2016 (UTC)

The 1-pixel difference you see on your system is, again, a matter of the font size you run with. We've been over this before: You have great eyesight and lean heavily toward tiny fonts, opposing CSS changes that aren't optimized for minuscule font sizes hardly anyone uses, even at the expense of usability and accessibility improvements for people who use (and often have to use) larger fonts. At even slightly larger font sizes the space in question is more than 1px. (And there are far more people with imperfect eyesight than there are people with better-than-20/20 eyesight, so this prioritization of yours, at this project, needs to shift.) Moving on, you've not demonstrated anything to be "non-functional", only asserted that one exact sandbox didn't work quite as expected for you in a single scenario (but in a way that did not actually break anything, simply didn't fix in that one set-up what it does fix in others). Given the state of CSS compatibility between browsers, that's about the best we can hope for most of the time. "Not 100% functional in every scenario" is not synonymous with "non-functional". But there's a better solution anyway; see below.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:18, 10 June 2016 (UTC)

OK, let me just get one thing straight... I am not in anyway inclined to smaller font sizes. In fact, I only use the default font with a default size in my browser, on a default installation of windows, using default font metrics on a default monitor using default settings. And that is what most readers are using. You, however, seem to be under the impression that anyone is apparently using your non-default setup, whatever it my be. So, yes, the 1 px differecen is the default difference. You can only convince me by providing sourced statistics regarding user setups, which I know you haven't. So get of it already. I aim to make Wikipedia readable for everyone, not just you! -- [[User:Edokter]] {{talk}} 21:54, 10 June 2016 (UTC)

No, you really, really don't. Let's review Mediwiki talk:Common.css/Archive 16#Compensate for italic lean where you spent months filibustering an accessibility fix, all in the name of preserving a trivial difference (much more trivial than the one you're opposing here) for the tiny number of people using ridiculously tiny fonts, at the expense of everyone (a notable percentage of the population) who do not have great eyesight. So, I'm calling psychological projection shenanigans on this "I aim to make Wikipedia readable for everyone, not just you!" claim of yours. The opposite is clearly the case. And this is just one example of you opposing tooth and nail any kind of spacing-related adjustments no matter how bad, or outright confusing, the output without it looks (as in the case of the glossary template CSS tweaks). This anti-CSS, anti-accessibility, anti-usability campaigning by you, just to suit what looks best on your very non-average setup, really needs to stop. You've been WP:FILIBUSTERing this stuff for years.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:33, 15 June 2016 (UTC)

The code behind the proposal is not very elegant or clever, but both the nowrap spans proposal and the narrow no-break spaces worked consistently, degraded gracefully, and broke nothing, across a range of browsers and OSes, and kept the § on the same line as the word to which it belongs. —LLarson (said & done) 12:03, 10 June 2016 (UTC)

I have been trying to explain that the span does not work consistenly in Chrome under Windows, where it does allow a break after the span. That is why I oppose the span solution (and that because it is too much payload for such a minor issue). If you consider this an acceptable fallback, then I consider no solution just as acceptable. -- [[User:Edokter]] {{talk}} 15:34, 10 June 2016 (UTC)

An "either-or" like that amounts to no !vote in the matter. If a recent build of Chrome/Chromium is not treating white-space: nowrap; consistently with the rest of the browser world, then file a bug report with them; you know the drill. And there's nothing unworkable, inelegant, unclever, or inconsistent in using CSS and Unicode spacing characters for the purposes they were intended. If it works for most users, and fails with no ill effect in one, it's still a net win, with nearly no processing or maintenance overhead, just some code in fast-running Lua that probably 0.00001% of WP editors, and zero readers, will ever look at or care about. We've already expended more editorial time and energy arguing about it than would ever have bene spent, in 10 years, maintaining the code in question.

However, there's an even simpler way to force the desired behavior across all browsers: Using a non-breaking space between the § and the section name, and use a styled span to visually kern the two closer together, arriving at the em-width of the   or   character, which would actually be ideal with current technology. (See White space character and Em (typography) for em-width differences between the spacing characters, and how the unit is defined.) The average em-width of a normal space is four-per-em, or 0.25em. The width of a thin-space varies slightly, from 0.2em 0.167em to 0.125em, in paper typography, but 0.18 is probably a good bet for Web typography (hair-spacing can go down to less than 0.05em in paper printing, but let's not "split hairs"; it's generally larger online, around 0.125 to 0.08). IIRC, the span must have display: inline-block;, else a margin or padding adjustment won't work in all browsers). Conceptually, I think it would make most sense to do this with a small negative margin value, since that does not affect the size of the §'s container in other ways, while a negative padding would, perhaps with unexpected results in some scenarios. Worth sandboxing with colored text and backgrounds; don't have time for it right now. I would start with a test of <span style="display: inline-block; margin-right: -0.07em">. After some old browsers really die off enough to satisfy us that we no longer need to support them, just replace all of that with an actual NARROW NO-BREAK SPACE chararacter,   a.k.a.   (already works in everything people still use, except some old IE on XP and earlier). It's probably worth testing whether my -0.07em guestimate matches well with   and  , and adjust accordingly, after looking at with multiple common fonts (not just common on Windows). I'm behind on 4 projects, or I would just set up such a test page myself.

It should theoretically actually be fine to just use that pure-character-based   solution now, since WP, and much of the rest of the Web, already looks like ass to anyone using a stock, ancient XP system, and the old IE and fonts that came with that OS, since standards compliance was a joke, monitors were lower-resolution, so CSS fine tuning was often corner-cut, and the basic-to-none Unicode support the ancient fonts have can hardly display anything outside the range of ISO Latin-1, Greek, and Cyrillic, and just throws garbage characters for exotic languages, IPA, more recently-added diacritics characters, etc., producing gibberish in many WP and other pages for such users. Someone using a PC from 2001 has such a hard time with the Internet generally that a few additional � markers aren't going to matter. The most obvious way to test whether the community will accept such a change is to change the thin-spacing between the "—" and the attribution into hair-spacing. If people complain they're seeing a weird character there, they're using ancient browsers/fonts. If no one complains, these setups are close enough to extinct that we can just move on. I last did this test about a year ago, and got a grand total of two complaints (and reverted). Even Microsoft's "Extended Support" (security fixes only) for XP ended in 2014, and this problem should not affect Vista or newer. At some point XP die-hard users have to be left behind; either they're in such desperate straights that a few characters on WP are the least important concern they could possibly have in life, or they're clueless and the whole Web is a barely usable mess to them, or they're technical people maintaining such a system for a reason (and they know already that it should not be used for browsing the Web, being susceptible to malware and other attacks, and if they insist on doing it anyway, they're also technical enough to figure out how to install modern fonts and browsers on it).

PS: A third solution would be to use Lua to tease apart the words in the section name, and adapt the CSS in the present sandbox to span the section characters and the first (or only) word of the section name.
Lesson: "It can't be done, it's too complicated, we must throw up our hands and run away" is never the answer to a technical problem.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:18, 10 June 2016 (UTC)

We are building suspension bridges over small streams here. This is micromanaging browser rendering, and all this over a simple spacing issue; not a "technical problem". Also, why are you ranting about XP; no one has mentioned it here. All I'm trying to say is that we need to focus on the content, and not fuss about presentaion of such minor details. Out of millions of readers, we have, what, one complaint about the spacing of the paragraph sign? Is this really worth it adding overhead for this? -- [[User:Edokter]] {{talk}} 22:07, 10 June 2016 (UTC)

The fussing is coming from your end, though. CSS was invented for fine-tuning of Web presentation style, including typography, yet no other Wikipedian objects as frequently or at such length to using it. It's like being opposed to screwdrivers at all costs, because hammers must be used for everything, no matter what. It is worth it to add the nearly nonexistent overhead of a bit of CSS to improve legibility and professional appearance, or no one would ever kern anything anywhere, and the entire discipline of typography would have gone the way of the lost art of jousting, practiced only but a few odd aficionados. The real overhead here is the amount of editorial productivity wasted arguing with you every time someone wants to use CSS here. There's a general consensus in the real world that Wikipedia looks like crap compared to other websites, and aversion to doing anything but following WHATWG's basic defaults (which are advice for browser manufacturers, not website developers and designers) to the letter is the primary reason for this undesirable result. PS: I'm not "ranting" about XP, I'm pointing out the pertinent fact that lingering users of IE on XP are the only reason we still stick with a lot of poor design decisions, and some day we just have to stop handholding them (that day was actually quite some time ago, and we just haven't collectively mustered the will to get it done). Your suggestion that this is somehow not relevant to this discussion is a transparent hand wave.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:21, 15 June 2016 (UTC)

Arbitrary break 1

Whatever the result, let's update Module:Multi-section link as well for consistency (which currently makes a regular space to the right of §). FYI,   was introduced in June 2014, replaced with   in August, before being Luafied. (Did some research: Windows had a problem rendering   in 2009 or so, according to this. On the other hand, with high-resolution high-DPI devices/screens becoming more popular, the 1-pixel difference is augmented, since default factory settings set scaling at 150% or 175%.)

• Wikipedia:Manual of Style § Punctuation §§ Quotation marks §§§ Names and titles <--  
• Wikipedia:Manual of Style § Punctuation §§ Quotation marks §§§ Names and titles <--  

With all due respect to all parties, I'm in favor of the visual spacing balance and relative simplicity of  . I haven't been involved, nor do I have investment, except for this technical edit request. Consider this a third opinion of sorts. — Andy W. (talk · ctb) 04:14, 12 June 2016 (UTC)

Thank you. Now I see the spacing in contex (especially embedded), I have to say I prefer &nbsp; as well. -- [[User:Edokter]] {{talk}} 07:45, 12 June 2016 (UTC)

@LLarson: I'm ready to sync the updated Module:Section link/sandbox and Module:Multi-section link/sandbox. The visual difference of {{Section link}} will be the slightly increased spacing for each section. No visualspacing difference for multi-section, just that the right-side space is now  . See Special:Permalink/725325559 for live/sandbox diffs of the multi-section version. Note. the last 2 instances are not template calls, but hard-coded links: the first surrounds "§" with   and  . I'd support that sort of spacing if it had consensus, but that's probably for another time. — Andy W. (talk · ctb) 00:25, 15 June 2016 (UTC)

@Andy M. Wang: I’m not sure we have consensus for the wider space right now, either. Until SMcCandlish is available to create a sandboxed proposal, I think we should leave {{Section link}} as is and that {{Multi‑section link}} should emulate it (wrappable  s). —LLarson (said & done) 23:01, 15 June 2016 (UTC)

@LLarson: Made consistent. Thanks — Andy W. (talk · ctb) 23:05, 15 June 2016 (UTC)

I'm fighting a nasty dental infection right now, and barely have the concentration to read this, so don't wait on me. Agreed having these be consistent is good, and I can live with nbsp spacing, it's just not optimal, because it treats the section character as a discrete unit, instead of tying it a bit to the section name. I'm in too much pain to care right now, so carry on.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:21, 15 June 2016 (UTC)

Section link diff, and Multi-section link diff. Hope you feel better, man. — Andy W. (talk · ctb) 23:34, 15 June 2016 (UTC)

Possible doc info at Template talk:See also2

See Template_talk:See_also2#Problems_with_Template:Section_link_fixed.3B_could_be_put_in_documentation for some problems I had, posted about, and then D'OH-fixed. I think it could create useful documentation in See also, and maybe a note with a warning here (but I didn't read the documentation here closely enough to know). FYI/FWIW. Gotta run! Thanks! — Geekdiva (talk) 21:53, 6 November 2016 (UTC)

Edit request: pls add the new Category:Wikipedia section templates

Please add the new Category:Wikipedia section templates to the template.

-> Or would you say that it shouldn't be added to that category as the template is related to article sections but not for use in article sections? (In that case it could also be simply linked to from the category's text.)

--Fixuture (talk) 01:37, 8 January 2017 (UTC)

Not done: {{edit template-protected}} is usually not required for edits to the documentation, categories, or interlanguage links of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage. Primefac (talk) 01:53, 8 January 2017 (UTC)

@Primefac: But wouldn't that add the documentation page (Section link/doc) to the category instead of the template? --Fixuture (talk) 02:06, 8 January 2017 (UTC)

Not if you put them inside <includeonly>...</includeonly> tags. Primefac (talk) 02:08, 8 January 2017 (UTC)

@Primefac: Alright, so I just added it like so but the template still doesn't show in Category:Wikipedia section templates. I tried purging the template already. Or does it just take some time until it appears in the category? --Fixuture (talk) 03:39, 8 January 2017 (UTC)

Fixuture, you added the category to Template:Anchor/doc, but not to Template:Section link/doc. You'll see that Anchor shows up in the category, though, so you did that right. Primefac (talk) 16:41, 8 January 2017 (UTC)

@Primefac: I know, and it shows up for me now as well. It didn't show up yesterday. Thanks for your help! --Fixuture (talk) 17:03, 8 January 2017 (UTC)

Translating # to §

The use of '#' in links is never intended to be displayed to the reader, and the natural translation for display is to '§'. I notice that several templates were recently (presumably when translated to a module) updated to do this translation automatically, such as {{See also|Article#Section}}, {{Main|Article#Section}} and no doubt several others. It would have benefit if this (or a sister) template would do the same, so that all of the templates are uniform in this respect. I, for example, to avoid typos or unwittingly linking to a duplicately named section, navigate to the required section from the table of contents, then copy the string from the browser navigation bar. But then I have to manually substitute the '#' with a '|' – not much work, but nevertheless mildly irritating. Would such an update be considered here? —Quondum 06:05, 23 May 2017 (UTC)

Single argument behavior

It seems very counterintuitive that, given a single argument, this template assumes the argument to be a page name, and links to a "Notes" section that may or may not exist. If only one parameter is given, shouldn't it be assumed to be a section on the current page? Currently, that requires the workaround of leaving a blank first parameter, but it would not be complicated to implement the more intuitive behavior. Any reason this is like this? —swpb^T 12:48, 20 September 2017 (UTC)

@Swpb: You're right, but it's a pain to have optional leading parameters in templates, and it just requires typing a second |, so I don't find this a major limitation.. 104.153.72.218 (talk) 12:30, 20 October 2017 (UTC)

Add parameter to style the page name

We need a parameter, |display=, for styling of the page title, e.g. as Book Title or "Song Title" or whatever. Example: {{section link|The Last Temptation of Christ (film)|Controversy|display=''The Last Temptation of Christ'' (film)}} There's consensus for this already, in that we're instructed to do titles this way everywhere, even in disambiguation pages' entries (see MOS:DABPIPING). I would fix it myself, but my Lua is rather weaksauce, and doing it wrong could break a lot of stuff.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:21, 7 November 2017 (UTC)

@SMcCandlish: Would we want to style the section title as well? Currently, doing something like Douglas Adams § Dirk Gently series doesn't correctly link to the section. --Ahecht (TALK
PAGE) 14:22, 7 November 2017 (UTC)

Fair point. Trying to keep the parameter names short, or it becomes more trouble than it's worth to use the template. I guess |sdisplay= would work, and we'd need |sdisplay1=, |sdisplay2=, etc., since this template supports links to multiple sections. I've avoided |style= because we almost universally use that for passing arbitrary inline CSS, and it would be confusing; similarly |title= is used for providing a tooltip (in inline templates) or a title heading (in box templates), so I picked "display" as probably good enough.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:31, 7 November 2017 (UTC)

@SMcCandlish: I see your point, it's not so straightforward. In the meantime, I mocked up the first part in the sandbox. Check out Template:Section link/testcases. --Ahecht (TALK
PAGE) 16:17, 7 November 2017 (UTC)

Schweet. I'm not sure how stringent the check is, that's generating "was ignored since it is not equivalent to the page's actual title." Is it just stripping markup from |display= and seeing if the result == |1=? Or is it doing some kind of "what does this eventually resolve to?" test?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:33, 7 November 2017 (UTC)

@SMcCandlish: I'm essentially trying to replicate DISPLAYTITLE, but I'm not sure if there's a way to automatically remove formatting (nothing was obvious in the documentation). To simulate this, I just take the page name and display name, strip any quotes or HTML markup, find the canonical names, and compare them. I don't try to resolve redirects. I've gone ahead and implemented it in the module -- please update the documentation. --Ahecht (TALK
PAGE) 23:12, 7 November 2017 (UTC)

You're hired! LOL. Been thinking about how to transition the {{Term}} and {{Defn}} system into something more robust. I"ve made it better incrementally, but it would be great if Lua just took whatever people input as the first value of {{Term}} and output as valid HTML anchor while also displaying as-given, instead of making people use two parameters. I think this would also reduce the processing overhead of the template in massive glossaries like Glossary of cue sports terms.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:24, 8 November 2017 (UTC)

@Ahecht: I updated the /doc for the |display= parameter.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:35, 8 November 2017 (UTC)

And already used it in an article [2]. Woot.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:30, 8 November 2017 (UTC)

Auto-parse the #

This template could be vastly improved by using the code in {{See also}}, {{Main}}, etc., that auto-parses Foo#Bar, so we don't have to manually convert this to Foo|Bar in the template parameters.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:21, 7 November 2017 (UTC)

The Lua that does this is likely in a function that can be called, since all the Lua-handled hatnote templates seem to have this feature.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:34, 7 November 2017 (UTC)

@SMcCandlish: It's easy enough to recreate from scratch -- it's just two regular expressions. See Template:Section link/testcases. --Ahecht (TALK
PAGE) 23:48, 7 November 2017 (UTC)

Working fine for me, including with |display=: The Last Temptation of Christ (film) § Controversy.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:38, 8 November 2017 (UTC)

@SMcCandlish and Ahecht: You can just use the one we already have. It's at Module:Hatnote#Format link - call it from within a Lua module with require('Module:Hatnote')._formatLink(link, display), or use the {{format link}} template. — Mr. Stradivarius ^{♪ talk ♪} 13:33, 8 November 2017 (UTC)

Better done with direct require, to reduce the number of discrete templates being called.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:39, 8 November 2017 (UTC)

@Mr. Stradivarius: I don't see any easy way for that to work with multiple sections, since that function returns a formatted string, not the page and section variables (we would want something like {{Section link|Article#Section 1|Section 2}} to work). However, I can steal the logic from that module since it reduces the number of regexes I have to write. --Ahecht (TALK
PAGE) 14:34, 8 November 2017 (UTC)

Since it doesn't break anything, I went ahead and implemented this. {{Section link|Foo#bar}} will now produce Foo § bar. --Ahecht (TALK
PAGE) 17:46, 10 November 2017 (UTC)

Decode fragment encodings

Sometimes bytes for certain characters (multi-byte Unicode characters and some ASCII characters that appear elsewhere in URLs) are encoded in the format .%2X (. plus two uppercase hexadecimal digits): that is, similar to URL encoding, but with a different prefix. At least, that is what I've observed; strangely, I haven't been able to find any information about this online.

I propose automatically decoding these encoded anchors: for instance {{section link|Phonological_history_of_English_consonants#.2Ft.E2.80.93r.2F_merger}} → Phonological history of English consonants § /t–r/ merger (encountered in this edit). I added this feature to the equivalent of {{section link}} on Wiktionary, using this function in wikt:Module:links:

local function decodeAnchor(anchor)
	return (anchor:gsub(
		"%.([0-9A-F][0-9A-F])", -- lowercase a-f is not used
		function (hexByte)
			return string.char(tonumber(hexByte, 16))
		end))
end

It would be quite a convenient feature to have these anchors be automatically decoded by the template. (It's also handy to have underscores automatically replaced with spaces, as in the example above, but that is a separate issue.) I don't have template editor rights on Wikipedia as I do on Wiktionary, so someone will have to make the decision as to whether this feature should be included. — Eru·tuon 02:18, 17 November 2017 (UTC)

Percent encoding of anchor

On Wiktionary, in the equivalent template Template:section link, I was linking to w:Hindustani phonology#Vowels [ɛ], [ɛː], and the brackets were preventing the parser from generating a link. The same thing happens with this template: {{section link|w:Hindustani phonology#Vowels [ɛ], [ɛː]}} → [[w:Hindustani phonology#Vowels [ɛ], [ɛː]|w:Hindustani phonology § Vowels [ɛ], [ɛː]]].

Percent-encoding the hash part of the link fixes the problem. (In this case it was enough to percent-encode the brackets, but it doesn't hurt to percent-encode the whole hash: maybe there are other characters that will cause this problem.)

It might be a good idea to do the same thing in this template, in case the issue arises here on Wikipedia – though there aren't many cases of square brackets in section headings. — Eru·tuon 21:30, 5 July 2018 (UTC)

Intrapage section links broken in editor preview

For example, if you're viewing this talk page, the following link should point to Template_talk:Section_link#foo: § foo.

But if you open this in the editor and click "Show preview", you'll find that in the displayed preview, the link points to something like https://en.wikipedia.org/w/index.php?title=Template_talk:Section_link&action=edit#foo. Not sure if this is a symptom of some more general issue with previews, but I couldn't see anything related at Help:Show preview. Dindon~enwiki (talk) 23:25, 22 January 2019 (UTC)

" It should not be used in running body text."

Where can the reader learn more on this? Where is this stated? How should editors code links within single articles? The doc tells us nothing. CapnZapp (talk) 20:48, 16 November 2018 (UTC)

I'm curious about this too. I went to Wikipedia:Manual_of_Style/Linking to find out more and saw that, ironically, that very page uses the slink template many times throughout the body text, e.g. Do not be afraid to create links to potential articles that do not yet exist (see § Red links below). or As per WP:NOTBROKEN and § Link specificity above, do not.... Ok, maybe the rules are different for the WP namespace, but then in MOS:SECTIONLINKS it says...

To link to a section within the same article, e.g. in the lead of Promotion (chess), write: [[#Promotion to rook or bishop|§ promotion to a rook or bishop]]. You can also use the {{section link}} template for this purpose.

So what is the truth? Dindon~enwiki (talk) 23:00, 22 January 2019 (UTC)

I went ahead and boldly edited the text in question to instead say "This template is intended primarily for use in hatnotes rather than in running body text". Per WP:TDOC, Editors should defer to official policies or guidelines when template documentation pages are inconsistent with established community standards and principles... Template documentation pages can be written without much—if any—debate, as opposed to Wikipedia policies that have been thoroughly vetted by the community. Colin M (talk) 23:53, 4 February 2019 (UTC)

This is still not clear, at least to me (which is why I'm here!). It still does not explain why its use in running body text may be inappropriate, and in fact it's phrased weakly enough that it's not clear that it is inappropriate—it just implies as an aside there was thought given by the template developers to hatnotes, and not running body text). More importantly, it doesn't suggest an alternative (which may be, "just leave the # there", I guess?).

--NapoliRoma (talk) 15:21, 31 May 2019 (UTC)

I am guessing that this is due to point #11 at WP:LINKSTYLE: The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links. I suppose it is possible that users could follow offline links to articles if the link is in the {{section link}} format, but there's no guarantee that the content that is linked to would be available in every given offline context. — Mr. Stradivarius ^{♪ talk ♪} 23:14, 31 May 2019 (UTC)

OK, that makes sense (at least for what the rationale was, if not the correctness of the rationale). It also suggests some further guidance would be usefl; both here and perhaps in WP:LINKSTYLE: in the case I was pursuing, the link was to a section within the same article, so it would eminently "followable" by any offline/republish reader. The use of § as opposed to # would be an improvement for at least print readers, in fact, since # is a very online symbol, and § is the more expected/preferred symbol in printed material.--NapoliRoma (talk) 23:32, 31 May 2019 (UTC)

I have been bold and re-edited the text, per above.--NapoliRoma (talk) 07:01, 1 June 2019 (UTC)

Problem with page names containing HTML entities

I was trying to link from Talk:PlayerUnknown's Battlegrounds to PlayerUnknown's Battlegrounds, and discovered that {{slink|PlayerUnknown's Battlegrounds|Gameplay}} works (PlayerUnknown's Battlegrounds § Gameplay), but {{slink|{{ARTICLEPAGENAME}}|Gameplay}} doesn't, because {{ARTICLEPAGENAME}} expands to "PlayerUnknown&#39;s Battlegrounds" and the # chatacter confuses the fragment parsing: {{slink|PlayerUnknown's Battlegrounds|Gameplay}} produces "PlayerUnknown's Battlegrounds § Gameplay". Ugh.

This breaks Template:Article link which depends on {{ARTICLEPAGENAME}}. Does anyone feel like taking a crack at fixing this? 23.83.37.241 (talk) 08:55, 13 April 2018 (UTC)

 Done. {{slink|{{ARTICLEPAGENAME:PlayerUnknown's Battlegrounds}}|Gameplay}} now produces PlayerUnknown's Battlegrounds § Gameplay. --Ahecht (TALK
PAGE) 14:27, 13 April 2018 (UTC)

@Ahecht: At this edit you added this:

page = mw.text.decode(v, decodeNamedEntities)

On a whim. I added this to the sandbox:

require('Module:No globals');

because I think it is generally a good idea to do that. Module:No globals choked on decodeNamedEntities as a nil value. The documentation for mw.text.decode() says that the second argument is a boolean. Did you intend something special for decodeNamedEntities or is this simply a copy pasta error?

In the sandbox, I have set the second argument to true so that Module:No globals is muted.

I wonder if there is something that I don't understand about mw.text.decode(). In the debug console, regardless of the presence, absence, or, when present, the assigned value, the second argument seems to be ignored because all of the html entities that I tested were always decoded (yeah, limited test so perhaps I'll write some code to explore this further).

—Trappist the monk (talk) 11:58, 8 June 2019 (UTC)

decodeNamedEntities. Though the documentation doesn't say it, apparently mw.text.decode() always decodes numeric entities but requires decodeNamedEntities as a boolean true to decode named entities that are not one of these: <, >, &, ", and  . So:

=mw.text.decode('©', decodeNamedEntities) == mw.text.decode('©', decodeNamedEntities) → false

=mw.text.decode('©', decodeNamedEntities) == mw.text.decode('©', false) → false

=mw.text.decode('©', decodeNamedEntities) == mw.text.decode('©', true) → true

=mw.text.decode('©', nil) == mw.text.decode('©', true) → true

=mw.text.decode('©', false) == mw.text.decode('©', true) → true

=mw.text.decode('©', true) == mw.text.decode('©', true) → true

=mw.text.decode('©') == mw.text.decode('©', true) → true

This does not work for &add; because it would appear that php(?) / MediaWiki(?) doesn't understand that named entity: &add; → &add; (should be a '+' character – at least so says our article at List of XML and HTML character entity references § Character entity references in HTML)

—Trappist the monk (talk) 13:08, 8 June 2019 (UTC)

@Trappist the monk: Yeah, I copied and pasted the function call from its documentation, but forgot to replace "decodeNamedEntities" with a boolean. Your fix in the sandbox looks good. --Ahecht (TALK
PAGE) 13:21, 9 June 2019 (UTC)

underscores

I recently wrote this:

{{section link|Help:Citation_Style_1#Auto-formatting_citation_template_dates}}

Help:Citation Style 1 § Auto-formatting citation template dates

I copied the parameter value from my browser's address bar (because I'm lazy) but then, to make it look pretty when it was rendered, I had to manually replace the underscores with spaces:

{{section link|Help:Citation Style 1#Auto-formatting citation template dates}}

Help:Citation Style 1 § Auto-formatting citation template dates

(took two tries, actually because I missed one).

That just seems silly to me. Is there any reason why line 99 of Module:Section link:

value = value:match('^%s*(.-)%s*$') -- Trim whitespace

should not be changed to:

value = value:match('^%s*(.-)%s*$'):gsub ('_', ' ') -- Trim whitespace and replace underscores with the space character

—Trappist the monk (talk) 14:38, 9 May 2019 (UTC)

I've long wished for this feature. If there are situations where underscores are needed, it would be easy to add a parameter to tell the module to leave them unchanged. Unfortunately I suppose if someone intended to leave in underscores in an existing use of the template, some bot work adding this parameter would be needed to ensure that they remain. — Eru·tuon 14:59, 9 May 2019 (UTC)

Alas, I think you're right: Category:Articles with underscores in the title. So some sort of |keep-underscores=yes parameter may be required ...

The sandbox module now strips underscores unless |keep_underscores=yes:

• {{section link/sandbox|Help:Citation_Style_1#Auto-formatting_citation_template_dates |keep-underscores=yes}} → Help:Citation_Style_1 § Auto-formatting_citation_template_dates
• {{section link/sandbox|Help:Citation_Style_1#Auto-formatting_citation_template_dates}} → Help:Citation Style 1 § Auto-formatting citation template dates
• {{section link/sandbox|Help:Citation_Style_1|Auto-formatting_citation_template_dates}} → Help:Citation Style 1 § Auto-formatting citation template dates
• {{section link/sandbox| Help:Citation_Style_1| Auto-formatting_citation_template_dates | nopage = no damit! }} → Help:Citation Style 1 § Auto-formatting citation template dates
• {{section link/sandbox|| Auto-formatting_citation_template_dates }} → § Auto-formatting citation template dates

Should probably change |nopage= so that contradictory or nonsensical values, no damit in my example above, are ignored.

—Trappist the monk (talk) 12:56, 10 May 2019 (UTC)

I had an idea, though it would require regular maintenance work: have the module check that the title is one of the articles with underscores in the title and if so display it with underscores. This would alleviate the concern that some article titles that should have underscores would not be displayed with them, without involving a bot. The disadvantage is that this requires regularly retrieving the titles in Category:Articles with underscores in the title and putting them in a data module, because Scribunto has no way to determine whether a page is in a category. An alternative unreliable and potentially inefficient method would be retrieving the article text and looking for %[%[%s*[Cc][Aa][Tt][Ee][Gg][Oo][Rr][Yy]%s*:%s*[Aa]rticles[ _]+with[ _]+underscores[ _]+in[ _]+the[ _]+title%s*|?[^%]]+%]%] (to be very forgiving about formatting) – unreliable because it assumes that the category is never added by a template and that the category link is never in a comment and potentially inefficient because the wikitext that is fetched could be quite large, which would add to Lua memory (searching on the other hand will probably be fast). — Eru·tuon 19:56, 10 May 2019 (UTC)

I have further tweaked the sandbox to use Module:Yesno, renamed |keep_underscores= to |keep-underscores=, and required |nopage= to accept only the 'yes' values known to Module:Yesno.

Without objection, I shall update the live module to use the sandboxed version.

—Trappist the monk (talk) 13:30, 8 June 2019 (UTC)

I have updated the "Template parameters" table to include description of |keep-underscores=. How do I make the table not wrap keep-underscores at the hyphen? Also, should |nopage= and |keep-underscores= have "boolean" type or some other type? (You've mentioned Module:Yesno – does it use "boolean" or its own type?) — UnladenSwallow (talk) 10:07, 30 September 2019 (UTC)

I don't use that abomination that is ve so I'm speaking from willing ignorance. I don't think that you can no-wrap hyphenated parameter names in the parameters table – wiki markup is not allowed (does not work) in TemplateData. On my wide-screen desktop, there is no line break at the hypen.

|nopage= and |keep-underscores= are boolean. Module:Yesno returns a Lua true or false when given the appropriate "yes" / "no" / ... string.

I don't know what Auto value means, but I hope that it doesn't act as a default so that every instance of this template added to a page by ve hides the page and keeps the underscores.

—Trappist the monk (talk) 10:45, 30 September 2019 (UTC)

Autovalues are prefilled values (in wikitext, so can use substitutions). I have removed them. — UnladenSwallow (talk) 15:57, 30 September 2019 (UTC)

Section display and italics in sections

I do not currently see a way to create a section link using this template to Baconian method#Idols of the mind (idola mentis) which would italicize idola mentis. I propose adding a new parameter |section-display= comparable to the existing |display= parameter. I also suggest that this template could automatically remove italic marks from wikilinks, so that

{{section link|Baconian method|Idols of the mind (idola mentis)}}

would produce

Baconian method § Idols of the mind (idola mentis) (https://en.wikipedia.org/wiki/Baconian_method#Idols_of_the_mind_(idola_mentis))

instead of

Baconian method § Idols of the mind (idola mentis) (https://en.wikipedia.org/wiki/Baconian_method#Idols_of_the_mind_(%27%27idola_mentis%27%27))

Daask (talk) 16:17, 2 October 2019 (UTC)

If we implement automatic removal of italic marks and  and  tags from page name parameter and section names parameters, then we probably won't need |display= at all. — UnladenSwallow (talk) 12:19, 3 October 2019 (UTC)

Apostrophes

In the same spirit of laziness as Trappist the monk above, I used this template recently with the portion of a URL pointing to a section of an article (New York's 1st congressional district § List of members representing the district). Thankfully, the underscores were replaced with spaces, but the ugly apostrophe remained. I'm not familiar with Lua and I haven't worked with regular expressions in a while - would someone be willing to do the same kind of thing for apostrophes in page/section titles? Airbornemihir (talk) 00:10, 19 December 2019 (UTC)

I've tweaked the module to percent-decode the positional parameters.

—Trappist the monk (talk) 00:35, 19 December 2019 (UTC)

Trappist the monk thanks! Airbornemihir (talk) 05:56, 19 December 2019 (UTC)

This is a very nice feature. (Looks like I need to add it to Wiktionary's version.) — Eru·tuon 06:59, 19 December 2019 (UTC)

Edit request (broken test)

I found a broken test case:	{{section link||#%7B%7Bu%7D%7D}}	§ {{u}}
Compare to:	{{section link||#Q}}	§ Q
I fixed it in {{format linkr}}:	{{format linkr|#%7B%7Bu%7D%7D}}	§ {{u}}
	{{format linkr|#Q}}	§ Q

and I ported my fix to this sandbox. I made sure that there was no code diff before editing sandbox. Please therefore copy sandbox to main. Psiĥedelisto (talk • contribs) ^{please always ping!} 17:51, 30 June 2020 (UTC)

 Done Primefac (talk) 19:17, 30 June 2020 (UTC)

A bug in this template: incorrect capitalization

In the course of copy-editing the article titled Window function I found this sentence:

Defining  L ≜ N + 1,  a confined Gaussian window of temporal width  L × σ_t  is well approximated by:

$w[n]=G(n)-{\frac {G(-{\tfrac {1}{2}})[G(n+L)+G(n-L)]}{G(-{\tfrac {1}{2}}+L)+G(-{\tfrac {1}{2}}-L)}}$

where $G$ is a Gaussian function:

$G(x)=\exp \left(-\left({\cfrac {x-{\frac {N}{2}}}{2L\sigma _{t}}}\right)^{2}\right).$

But the phrase "confined Gaussian window" had an incorrectly capitalized initial "c", so I changed it. But then the link, which used this template, no longer worked. So I expunged the use of this template. This template should be deprecated if this bug cannot be fixed. Michael Hardy (talk) 03:37, 6 November 2020 (UTC)

@Michael Hardy: Unfortunately, we can't simply capitalise the first letter of the section name in the link, as MediaWiki allows section names starting with a lowercase letter. We would have to add a "displaysection" parameter or similar so that the section name and the section link can be different. — Mr. Stradivarius ^{♪ talk ♪} 02:06, 14 February 2021 (UTC)

References

Embedding in another template?

Is it possible to embed this template inside another one? If so, how? thanks. Nurg (talk) 22:03, 13 February 2021 (UTC)

Probably, did you try? Templates are processed in order inner-most first.

—Trappist the monk (talk) 23:15, 13 February 2021 (UTC)

Here is an attempt, which does not display correctly:

For the publishing aspect, see [[:Research § Publishing]].

Nurg (talk) 01:59, 14 February 2021 (UTC)

The result of:

{{For|the publishing aspect|{{section link|Research#Publishing}}}}

is:

'"`UNIQ--templatestyles-0000005D-QINU`"'<div role="note" class="hatnote navigation-not-searchable">For the publishing aspect, see [[:[[Research#Publishing|Research §&nbsp;Publishing]]]].</div>

So, you are attempting to have a wikilink within a wikilink which MediaWiki doesn't allow.

—Trappist the monk (talk) 02:07, 14 February 2021 (UTC)

Defaulting to § Notes

It appears that when the second parameter is blank or omitted, the default target section Notes is added:

{{slink|1=Main page|2=}} → Main page § Notes

{{slink|Main page}} → Main page § Notes

Looks like module code for this is section = sections[1] or 'Notes'

This is strange and unexpected behaviour. Also, it introduces problems when automating this template: beforehand, absense of section name is unknown. (as opposed to: typing a single page, when one knows there is no section to be added).

Could it be considered to add a new parameter to perform

"When |section= is empty, do not display nor use any 2nd part"?

-DePiep (talk) 15:04, 18 February 2021 (UTC)