User talk:Biogeographist

This user might or might not have an academic degree, and considers the distinction irrelevant on Wikipedia.

"Wikipedia may be the largest collaborative initiative in history and influences what people the world over know or think they know. Its distinctive feature is the nonexpert, nonprofessional, noncertified, nonformal production of knowledge with credible content. Academics like to sneer at those characteristics, even as more and more of us acknowledge Wikipedia, support it, and use it in teaching. And why should we not warm to it? The rules of Wikipedia discourse are modeled after an ideal academy's. Arguments, not personal attacks or status, carry the day. ... Why, then, does Wikipedia work? In theory, it should not. In practice, it seems to be a new paradigm of organization, whose breezy anticredentialism tosses traditional hierarchies of knowledge production to the wind."

Allen, Barry (January 2017). "Review of Common Knowledge?: An Ethnography of Wikipedia by Dariusz Jemielniak". Common Knowledge. 23 (1): 104. doi:10.1215/0961754X-3692492.

---

"Thanks to a vibrant community united by a few core principles, plus detailed policies and safeguards against trolls and vandalism, Wikipedia has already become a piece of the knowledge ecosystem. Like science, its aim is to propose a synthesis of existing knowledge and conflicting interpretations of reality. ... The main criticism against Wikipedia is that it is a free-for-all domain without any professional standards. Yet even if Wikipedia has to be used with caution, it is not a free-for-all. On the contrary, the Wikipedia community has developed a consistent set of principles, rules, policies, and guidelines that have helped build consensus among a community of thousands of contributors (Jemielniak, 2014). ... Wikipedia encourages contributors to edit articles, and to reach consensus by engaging in discussion on the "talk page" in case of a disagreement. The process is typically Hegelian in nature: make an edit, then wait for the next change, and if there is opposition, seek a compromise. A variant of this policy is the BOLD, revert, discuss cycle: bold editing is openly encouraged in the policies, as it leads to discussion, which helps make articles better. This collaborative culture, which is unique to Wikipedia, makes the community a living organism, growing continuously, adapting to its environment and answering its critics."

Vandendorpe, Christian (October 2015). "Wikipedia and the ecosystem of knowledge". Scholarly and Research Communication. 6 (3): 1–10. doi:10.22230/src.2015v6n3a201.

Embedded anchors in headings

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)

@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)

@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)

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)

@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)