Hi, Biogeographist, and thanks for your style fixes at BibTeX. I noticed that among other things, you added a couple of embedded anchors to section headings. Please note that embedded section anchors can be useful so that incoming links will still work after a heading name change, but they are best used when "there are many links to the old title".
When there are no inlinks to it, an anchor is unnecessary, and when there are just a couple, it's best to just adjust the wikilinks with the old section name to the new one, rather than embed an anchor in the target article, which makes a more complex section heading that many editors don't know how to handle. Finally, when there are so many incoming links that it would be too time-consuming to fix them all, then please use the {{subst:anchor}} or <span id=...> style recommended at MOS:SECTIONANCHOR, and not "{{anchor|Foo}}" format, which causes the "undesirable behavior" that you can read about at the guideline.
In the BibTeX case, anchors in two section headers were involved: one of them had no inlinks so wasn't needed, and the other had three: from EndNote, Refer (software), and RIS (file format). I adjusted the links in those three, and removed the embedded anchors from BibTeX. (To find inlinks, you can do an advanced search: like this.) While embedded section anchors have their uses, please don't add them willy-nilly, and most of all, please avoid adding them when there are no incoming links to the anchor at all. Thanks, Mathglot (talk) 21:56, 26 June 2024 (UTC)[reply]
- @Mathglot: Thanks for the message. I just learned about {{subst:anchor}} a few days ago before you commented here, when I re-read MOS:SECTIONANCHOR. That guideline must have changed, because the last time I read the guideline some years ago it didn't explicitly say to substitute the {{anchor}}. So now I know to do that.
- However, I disagree with you that we can determine that there are no inlinks simply by searching Wikipedia, because Wikipedia is on the World Wide Web, and there could be inlinks from anywhere on the Web, or in people's browser bookmarks. I think it is reasonable to retain anchors for old section names that existed for a long time and could be linked from off-wiki (especially in a page like this one that is the best reference source on its subject on the Web), so I will restore those anchors in BibTeX but in substituted form. (If there is a guideline that explicitly contradicts my reasoning here, please point it out to me.) I agree with you that anchors shouldn't be added willy-nilly, but this isn't such a case. Biogeographist (talk) 15:10, 28 June 2024 (UTC)[reply]
- @Mathglot: And I reverted another removal of an anchor by you because that anchor is the target of a couple of redirects. Perhaps you forgot to check whether the anchor was a redirect target? Biogeographist (talk) 15:19, 28 June 2024 (UTC)[reply]
- Hi, BG (is that an okay moniker for you?). Good point about redirects; I support your addition to the explanatory note at MOS, and the revert is fine. I played around a bit to see if one could search for redirects from advanced search, and I'm not completely convinced one can't, but haven't found it at first blush. On the other hand, I don't agree with the part of having to deal with offline links with fragment ids from the internet. The HTTP 301 response (or any of the 30x responses) does not support a redirect from a URI + fragment, only from a URI (which may target a fragment, but not come from one). Neither does the
<link rel> title element ( link rel support for redirect-from has been proposed as part of the W3C spec for HTML but never accepted, afaik). - Although response code HTTP 301 (permanently moved; i.e., redirect) has been available on the internet for ages, I'm sure you've had the annoying experience of trying to visit a web page that you know exists, only to get a 404 Not found error back from the site after they have done some internal re-org; we have all been there. Wikipedia handles that with redirects, so that people off-wiki can still find our articles that have been moved. However, the ability to find an internal section on a page (via #fragment) has never been part of the HTTP 30x or other codes; there never has been a way to do this server-side via an HTTP response or a HTML <head> element, afaik. Yes, you can add a destination anchor (the <span id=...> technique; the <a> tag can also do it; we don't have access to <a> in the wikicode, as we do for <span>), but embedding it in a section header is very klugey imho and I don't favor doing that just because somebody somewhere on the internet might have a bookmark to it in their browser. Let them get redirected to the top of the page and then find their content on the page, and fix the bookmark.
- There's no reason the mediawiki software couldn't be enhanced to handle this in a clean way, with some new element, maybe #REDIRECTSECTION, that would be designed to follow a section header in the wikicode, and be interpreted into HTML with the requisite anchor in the right place; if you've ever looked at the generated HTML of one of our articles, you know that there are tons of elements you don't see in the wikicode, nor would we want to. That would be the right way to handle section redirects, imho, and then it wouldn't be so distracting having them at the top of a section. That's just my take; maybe I'll add something about it at WP:VPI. Once again, thanks for your contributions to the discussion, and your improvements to the explanatory note. Cheers, Mathglot (talk) 02:10, 29 June 2024 (UTC)[reply]
- @Mathglot: OK, you've convinced me at least for the case of BibTeX, so I'll revert my re-addition of the anchor tags there. Biogeographist (talk) 12:49, 29 June 2024 (UTC)[reply]
