Jump to content

User talk:Michael C Price/links

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
[edit]

This is a proposal to change the Repeated links section of the MOS. Please edit &/or comment on the talk page as you see fit.

Feel free to move the proposal/discussion straight to the Wikipedia talk:Manual of Style (linking) if you wish. I just thought we might establish some sort of consensus here first, out of the heat and fury over there. --Michael C. Price talk 10:07, 28 September 2010 (UTC)[reply]

As Hans Adler said (search for "13:22, 12 August 2009 (UTC)" in Wikipedia talk:Manual of Style (linking)/Archive 6), there are two types of links which should be distinguished. I think that, while it's useful to repeat "explanatory" links in each section, there's not much point in repeating "navigational" links to terms of which readers already know a basic explanation. For example, in Quark, the article electric charge is only linked in the lead and in the eponymous section, but lepton is linked to in several places. A. di M. (talk) 10:55, 28 September 2010 (UTC)[reply]
Good point. Perhaps that can be handled as "in general, but..." ? --Michael C. Price talk 11:10, 28 September 2010 (UTC)[reply]

Right now the proposal contradicts common sense. "link every section" - why? I see four whole sections of Article X on my screen, what's the point of having four blue links to the same? I'd say, keep MOS as is. If you think that regulating more linking will contain link-delink wars, it won't. It just shifts the neutral ground, but it will still be there, no less ambiguous then it is now. East of Borschov 11:52, 28 September 2010 (UTC)[reply]

If you see 4 sections on the screen, they must be short sections, and the proposal says "depending on their length".
I agree the ambiguity will still there - since there should always be room for judgement - but at the moment it says you can't ever link more than once - with some minor exceptions that seem to get ignored. All I want to do is move the battleground to somewhere more sensible. --Michael C. Price talk 12:02, 28 September 2010 (UTC)[reply]

I have to say I'm of the view that this is one area where we can sensibly cut down excessive linking in main article text, and the presumption must be in favour of not repeat-linking across the page as a whole, even if this ends up with slightly "top-loaded" pages. Exceptions will of course arise, in longer pages, or where, say, the focus of a later section is on some specific aspect of something. Eg for a scientist best known for discovering planet X - you might want to link planet X both in the lead, and in the section that looks at his work on that in more detail, even if it's quite close by. However, it's going to be hard to make quantitative judgments about that sort of thing. I think the current wording is kind of OK for this. I also think that infoboxes are quite a good place for shoving links to the more common - but nonetheless relevant - terms that can then be removed from elsewhere, especially from the lead, which is usually adjacent to the infobox after all. That can also be quite a good compromise with those who don't want the terms linked at all, were they to ever wish to take it. N-HH talk/edits 13:20, 28 September 2010 (UTC)[reply]

The problem with that is that the infoboxes aren't strictly part of the article, and can be left off in some contexts. Leaving a link only there, and not also in the article is essentially the same as not linking the term at all. Hence the exception for infoboxes and other meta content, which includes navboxes, and arguably see also sections.
As for the proposal to link in every section, I think the current clause allowing for exceptions in "particularly long" articles covers the necessary practice, like NH-H's example. The real issue is that the appropriate exceptions, such as that, the infobox exception, and the über-important "particularly relevant" exception to OVERLINK, are too-oft ignored to fit an idea that is of questionable application in a non-commercial setting; we're not trying to "drive" traffic anywhere in particular, unlike commercial sites. Or one that expects, even requires, readers to always read the entirety of an article in order (ignoring the fact that we have a TOC which links as readers often do skip to the section that they want); we're not here to teach people how to read, we are here to write articles they can read however they want. oknazevad (talk) 16:07, 28 September 2010 (UTC) PS, I realize my arguments regarding the links in the TOC could be used to support linking in every section. I still think it's overkill unless particularly relevant.[reply]

Redundancy

[edit]

The first bullet, "where a later occurrence of an item is a long way from the first" is redundant in scope and intent with "in a...section and possibly subsections, depending on their length". That is, the entire point of "in a...subsection and possibly subsections, depending on their length" is "where a later occrrences of an item is a long way from the first". This stuff needs to merge into one cohesive and clear statement. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 18:13, 28 September 2010 (UTC)[reply]

The simplest way is simply to remove the bullet point? If no one objects in a day or two, I'll remove it. --Michael C. Price talk 21:12, 28 September 2010 (UTC)[reply]
I'm not sure. It seems to me that we should be making it clearer that we mean only when it's a long way down from original link (see confusion in first topic on this page - someone thought it meant in every section, even when they are so short you can see 4 of them on one screen). — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 21:52, 28 September 2010 (UTC)[reply]
Since "long way" is now the relevant criterion - which is a good move, IMO - perhaps we can define it in terms of screen distance. I.e. one link per screenshot. --Michael C. Price talk 23:32, 28 September 2010 (UTC)[reply]
Be tough, due to varying screen resolutions. The details will require some discussion, but I agree with the principle.oknazevad (talk) 02:15, 29 September 2010 (UTC)[reply]
I've left "long way" undefined - I doubt we'll ever get an objective definition that sticks, but I thought the comment about mobile displays was pertinent. --Michael C. Price talk 09:30, 30 September 2010 (UTC)[reply]

Infobox

[edit]

The second bullet, "where the first link was in an infobox or a navbox, or some similar meta-content" is a crucial point, but I would reword it. For one thing, "meta-" is being misused here, and for another this is both too narrow and too broad. Try "where the first link is [note the verb tense fix] is in transcluded content, such as an infobox or sidebar template, an image caption or a table". Navboxes are not relevant here, since they are always at the bottom of the article and thus cannot be the first occurrence unless the only occurrence. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 18:17, 28 September 2010 (UTC)[reply]

The "meta-" part isn't really misused per se, but I'm not wedded to the term. As for the navbox mention, it is important, less anyone use it as justification to remove other links. oknazevad (talk) 02:15, 29 September 2010 (UTC)[reply]
I've reduced the rationale font size, since this is really just an (important) note to editors, rather than readers. --Michael C. Price talk 09:31, 30 September 2010 (UTC)[reply]

Tables

[edit]

The logic behind the recommendation isn't transparent. Rewrite: "in tables, as each row must stand on its own, because readers can re-sort tables in any order (either because editors have made the table explicitly sortable, or using third-party browser plug-in software)." I actually have and use a Firefox plugin that makes tables sortable even if they have no sorting source code, so this is not an idle concern at all. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 18:19, 28 September 2010 (UTC)[reply]

The logic behind the recommendation wasn't clear to me either - I just copied it over from the current MOS entry, assuming there was logic behind it. Feel free to edit it, that's what we're here to do. --Michael C. Price talk 21:40, 28 September 2010 (UTC)[reply]
Yes, an explicit rationale can't hurt.oknazevad (talk) 02:15, 29 September 2010 (UTC)[reply]

Glossaries

[edit]

A fourth case, and an important one:

  • In a stand-alone glossary article (or similar stand-alone list with entries that are linked to directly from other articles and which is not expected to be read from start to finish, but refered to piecemeal), each entry should appropriately link to terms both within and outside the page as if the entry were an independent article, as few readers ever find the first occurrences of the terms.

See Glossary of cue sports terms. You'll note that is a bit of a "sea of blue", and it has to be because virtually no one will ever read the entire thing, only the entry they arrived at for clarification of an in-context term used in another article. Glossaries are a very special case. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 18:24, 28 September 2010 (UTC)[reply]

Ooooh, I like! oknazevad (talk) 02:15, 29 September 2010 (UTC)[reply]

Bold overhaul

[edit]

I've done a bold overhaul of the whole thing, trying to integrate as many of the points from this talk page as I was able. This resulted in addition of explanatory prose. Given the interpretation wars over this section of the guidelines, I don't see that as a bad thing, even if otherwise I tend toward resisting long additions to any part of the MOS. If anyone thinks this went too far, please feel free to revert, but note that you've done so here and <blockquote> a copy of it here for further discussion/improvement. — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 22:37, 28 September 2010 (UTC)[reply]

It is a bit long. Perhaps some of it can go inside a <!-- -->? Perhaps we can define WP:navigational link and link to it? --Michael C. Price talk 23:29, 28 September 2010 (UTC)[reply]

Re: The real dispute: Relevance (explanatory vs. navigational linkage)

[edit]

See WT:LINKING#The real dispute: Relevance (explanatory vs. navigational linkage). — SMcCandlish Talk⇒ ʕ(Õلō Contribs. 23:15, 28 September 2010 (UTC)[reply]