Unless I missed it I couldn't find anything saying when a Wikidata link should be used instead of individual interlanguage links. What's the cutoff number? Charles Essie (talk) 01:37, 25 November 2023 (UTC)

(I took the liberty of narrowing the section header from "Manual of style" to "When to link to Wikidata".) I don't think any such rule can be formulated. It's up to editors' judgement, which may depend not only on the number of languages involved but also on their relative accessibility and quality. I normally don't specify more than 2 languages, and then I prefer to link to the language that I consider to be a combination of quality, connection to the subject, and accessibility. Of course, a link to any language will expose all the others as well. Only if I can find no compelling combination, I link to Wikidata. -- Michael Bednarek (talk) 02:48, 25 November 2023 (UTC)

Charles Essie: Per WP:Village pump (idea lab)/Archive 38#Replacement for Interlanguage link template, "... Wikidata links are not allowed in text, and there is no ... exception for interlanguage links." If you want to argue about the sensibility of this rule or the validity of its determination, I'm with you on that.

FWIW, without going into my reasoning, I completely disagree with the idea that the editor should try to pick the best language versions for other Wikipedia users. OTOH, if you provide a link to any version of the article (aside from a link which happens to be a "referral"), then the target page will (on most language wikis, at least) have the full wikidata list... but for many wikipedia users, this fact probably isn't going to be top of mind. Fabrickator (talk) 03:22, 25 November 2023 (UTC)

Wikidata items are widely used in Wikipedia articles; see Category:Templates using data from Wikidata. This is comparable to links to Wiktionary, Commons, Wikisource, Wikiquote, etc. As for picking: editors pick things all the time (sources, images, sounds, further reading, external links), not to mention language and emphasis. -- Michael Bednarek (talk) 09:56, 25 November 2023 (UTC)

The rule is that Wikidata can't be used in text, which excludes, as an example, infoboxes, and specifically mentions that the rule applies to interlanguage links (which evidently fall within the definition of Wikidata links, even though they aren't actually links to Wikidata content). I don't personally agree with this rule, but it's a rule that presumably is still in effect. Fabrickator (talk) 18:58, 25 November 2023 (UTC)

I'm going to correct myself ... when clicking on the wikidata parameter in an interlanguage link, it actually does take you to the Wikidata page that has a section listing the links on different language Wikipedias. So as I now understand it, the issue isn't actually about the concept of displaying links to the articles in other languages based on what's in Wikidata, but just the fact that clicking on the template doesn't provide a nice user interface, requiring the user to figure out where the links are on the Wikidata page. I believe that there are some alternate {{ill}} implementations (e.g. on Polish WP) that provide an improved user interface. Fabrickator (talk) 19:15, 25 November 2023 (UTC)

The editor should absolutely try to pick the best, or at least "a best", language version. A personally curated ill link is what is genuinely useful. The point of this template isn't to show a catalog of interlanguage links, many of which likely are poor quality. Keep in mind Ill links are OPTIONAL. Use them when you have found a genuinely useful foreign-language article. Don't use them for completionist purposes. CapnZapp (talk) Fabrickator (talk) 20:29, 25 November 2023 (UTC)

I have added a test case showing that when an English-language Wikipedia article does not exist, and the corresponding foreign-language article does not exist, the two-letter link to the foreign-language article shows as blue instead of the appropriate red. I think this is misleading and should be fixed. Is there a reason for this link to be blue? – Jonesey95 (talk) 17:44, 18 January 2024 (UTC)

It is blue because it is an external link. There is no way for enWiki to know if a page on a foreign wiki exists. Primefac (talk) 17:47, 18 January 2024 (UTC)

Bummer. And I see that ifexist does not work with interwiki links. I'll add to the documentation. – Jonesey95 (talk) 18:29, 18 January 2024 (UTC)

It might be worth getting a bot to flag all uses of {{ill}} where the foreign link does not exist. —Kusma (talk) 19:30, 18 January 2024 (UTC)

That would be the only way (other than manual). As far as scoping, I'm not sure if db queries work across databases, e.g., en-wiki and fr-wiki; pretty sure they do not. I wonder if it would be technically possible to port the heap or temp table output of one query at en-wiki over to fr-wiki for further processing? What I'm thinking of, is a query at en-wiki that looks for {{ill}}'s and generates a 2-column temp table consisting of 1=name of en-wiki article red-linked in an {{ill}}, 2=purported name of French article it relates to from the foreign-link param of the {{ill}}, then export the result, then go to the fr-wiki db, import as temp table or heap, and join with French article table to generate 3-col output, adding col. 3 = boolean fr-article exists or not. Certes, in your opinion, is this doable? Or is this just all easier via bot, and not worth attempting that type of query? Mathglot (talk) 20:44, 18 January 2024 (UTC)

164k transclusions of this template, and 339 potential languages which can be passed to the template... even if only 20% are used by {{ill}} you're talking nearly a million possible datapoints to cross-reference. Primefac (talk) 21:07, 18 January 2024 (UTC)

One million is a very small number for a sql query, especially if the column is an index field, as it would be in the JOIN on the French side. The hard part is extracting the two parameters from all the ill's on our side, but that would only have to be done once. I would just scope it using one or two languages to start, French and German or something; if that wasn't feasible, no reason to go further. Mathglot (talk) 02:18, 19 January 2024 (UTC)

A Quarry query like SELECT DISTINCT iwl_title FROM iwlinks WHERE iwl_prefix="fr" would list {{ill}} targets but also direct links such as [[:fr:Exemple]], which we may or may not be interested in. For each language, we could put each resulting list into something that will filter for absent pages. That could be PetScan to list extant pages and diff with the original list, or a diff with a full list of pages obtained from a frwp dump, or even preview a list of wikilinks such as *[[Jean Dupont]] on frwp and filter the resulting HTML keeping only classes denoting a redlink. Unfortunately, a change made a few years ago means that we can no longer join tables from two databases (e.g. enwiki_p and frwiki_p) directly in a single query. Beware that iwl_title has spaces converted to underscores, but the initial is not automatically capitalised (because some wikis such as Wiktionary have distinct pages for apple and Apple). Certes (talk) 19:15, 19 January 2024 (UTC)

I think allowing red-colored links in ill's for pages that already exist on en-wiki but are circular redirects with possibilities would improve the experience for both casual readers and experienced editors, including editor-translators.

Pretty often, I run into a situation where we're missing an article at English Wikipedia we ought to have, and the likely title is found in unlinked, plain text in several articles but nobody will add an {{ill}} there in place of the plain text because the clear choice for the English article title is already a MOS:CIRCULAR redirect (sometimes tagged "{{R with possibilities}}") back to the same article. If we detect this case and permit a new param, say, |red=yes, we could display a no-redirect link in red font to the user. The reader loses nothing by having red text there, as he is already reading the article the redirect links to. For ambitious bilingual editors who click the red link expecting to land at a blank page and ending up at the redirect-with-possibilities page instead, there will be a brief moment of surprise, at which point the aha-reflex should kick in, and they'll realize that they need to simply usurp the redirect to start their new translation.

As a concrete example, I just added a couple of circular ill's to Savant syndrome, as we do not have an article on Autistic savants, but fr-wiki does, at Autisme savant (so does Arabic). But 'Autistic savant' is blue because it's a redirect, and I feel that blue is not helpful there, because it might encourage a casual reader to click it, leading to the confusing result of landing at the top of the same page they are reading due to the circular link; worse, it adds no additional knowledge or information, the whole purpose of following a wikilink. Seems like red would serve the reader much better by discouraging a click, as well as simultaneously serving the red link-savvy editor better as well, to encourage them to grow the encyclopedia.

What about the meaning of a red link; doesn't it specify that no page exists, period? Maybe not. Note that on the one hand, the first sentence of WP:Red link says that a red link "signifies that the linked-to page does not exist". However, the second sentence says, "Add red links to articles to indicate that a page will be created soon or that an article should be created for the topic because the subject is notable and verifiable. Red links help Wikipedia grow.", which is exactly the point of the red link in the proposal. Finally, the first sentence of WP:RED says, "Red links for subjects that should have articles but do not, are not only acceptable, but needed in the articles. They serve as a clear indication of which articles are in need of creation, and encourage it."—again, nothing there about the page existing in redirect form; rather, it talks about articles that should exist. Precisely the case here. So, WP:Red link is not categorical about the question of page existence, and in two out of the three quoted, top-of-page excerpts, they talk about subject and article existence. Seems to me there is plenty of wiggle room in the guideline, certainly enough for this edge case of a circular redirect in an {{ill}}, a tiny, tiny proportion of all links. I read that as not standing in the way of this proposal, if there is consensus for it otherwise, as it would be of benefit to both readers and editors. Mathglot (talk) 02:11, 19 January 2024 (UTC)

Ill redirects are already visible via the extra link to a foreign Wikipedia. I think this type of change is more suitable to do via user scripts like User:Anomie/linkclassifier. —Kusma (talk) 11:31, 19 January 2024 (UTC)

That would help only the miniscule number of people who don't need it: sophisticated editors who install scripts, use ill templates, and understand {{R with possibilities}}. It leaves out the 99.9% of people who would most benefit, and for whom the proposal is designed. Mathglot (talk) 21:06, 20 January 2024 (UTC)

Beware of links which redirect to a section of the current article. They can be a useful way to navigate the page. The subtopic's section on enwp may even be bigger and better than the stub articles covering the topic for non-English wikis. Certes (talk) 20:30, 20 January 2024 (UTC)

Indeed; but those should remain as on-page links ( [[#Useful section|thingamjig]], or {{section link}} ). There's no reason to use an ill template when our content is already best. If that is not already called out in a "when to use" section in the /doc, it definitely should be. Mathglot (talk) 21:06, 20 January 2024 (UTC)

I take exception to this. We should not presume to know which language version has the contest that's best for any particular user. We use the current language as the default, but each language wiki also provides the user with a list of other languages that the article is available in. It's a false premise (IMO) that we should be deciding for the user which language version has the best content ... we link to one (or maybe more), knowing that the other language versions will be exposed on the target page. Fabrickator (talk) 16:20, 1 April 2024 (UTC)t

User:Mathglot, you argue WP:Red link is not categorical about the question of page existence, and in two out of the three quoted, top-of-page excerpts, they talk about subject and article existence. Not sure how you arrive at this, so let me make an assertion and let you explain exactly where this assertion is false: WP:Red link discuss links of various sorts, but one thing remains constant: whenever a red link is discussed, it always presupposes that there is no page of any sort at the destination, i.e. you always get the "create new article" response. I realize YOU want to make an exception here (retaining the red color even though the destination exists), but first let's figure out what the actual WP:Red link guideline says. Cheers CapnZapp (talk) 19:31, 1 April 2024 (UTC)

Yes, that is indeed what it says now. That is why this is a proposal open for discussion, not a claim that red links point to active pages. The proposal was put forward to improve the experience of a segment of reader/editor/translators, and I still think carrying it out would do so without negative impact for anyone. However, it doesn't appear that there was any groundswell of support and it went quiet in January; not sure why we are talking about it now. Mathglot (talk) 20:04, 1 April 2024 (UTC)

Since the English content (albeit not its own article but a section of another with a redirect) is far more sourced and detailed, is this a proper application of this template? I've never seen it used like this. Thanks! — Fourthords | =Λ= | 06:20, 1 April 2024 (UTC)

It's a bit unusual, but the DE article has its merits. This kind of usage becomes problematic when the EN redirect at The Terror of War, flagged as "with possibilities", gets extended into an article. Also, I don't know how Cewbot, which converts {{ill}} links to local links, deals with these constructs. On balance, I would not use {{ill}} that way. -- Michael Bednarek (talk) 07:47, 1 April 2024 (UTC)

It's more that it's pointless than improper; The Terror of War is a redirect, so Fabrickator did not have to jump through so many hoops because the template will still show the ill. Primefac (talk) 08:32, 1 April 2024 (UTC)

Thanks for noticing! To review, there is a local link, but it is a redirect to a section of an article. There is also an interlanguage link to a "full" article. If only the local link going to the article section is provided, the user is not made aware of the existence of interlanguage link. So this makes the user aware of both the local and non-local links, which is what I would consider the right thing to do. Fabrickator (talk) 09:09, 1 April 2024 (UTC)

Primefac's remark about hoops refers to {{ill|Nick Ut#The Terror of War|lt=The Terror of War|display=yes|de|The Terror of War}} where
{{ill|The Terror of War|de}} -> The Terror of War [de] does the same thing. -- Michael Bednarek (talk) 11:44, 1 April 2024 (UTC)

You say the template will still show the "ill" since it's a redirect (and presumably the "ill" will not get deleted altogether) .... perhaps you are right, though if that's not right, then this effort get wiped. Hopefully it's also smart enough that there would not be a need for display= or preserve=. In either case, the explicit use of the section name alerts editors that the local link is a redirect to a section rather than being the name of an existing article, thereby saving some head-scratching. Fabrickator (talk) 16:04, 1 April 2024 (UTC)

Your "hoops" bypass the redirect The Terror of War, Fabrickator. Is there a reason for this? What I mean is, if the redirect is expanded into a proper article, your ill application would not see this (the ill would remain even though we now have an English-language article, normally something that would trigger Cewbot to replace the ill with a regular link). Unless you have such a reason, wouldn't it be better to supplement Primefac's removal of your hoops with |preserve=yes? At least, that's the only practical difference as I can see. Assuming you can argue why this particular ill would merit preservation, of course. Thanks CapnZapp (talk) 19:18, 1 April 2024 (UTC)

I actually can't follow you. In other words, I don't know whether you've decided that there's some justification for changing what I did. You did mention adding |preserve=yes but it already has |display=yes, so the '"preserve" parameter would be redundant.

We can't generally handle all possible future changes. That change could be adding an article that makes a section link irrelevant, or it could be the deletion of an article, resulting in the section link once again becoming relevant. Fabrickator (talk) 23:00, 1 April 2024 (UTC)

Looking this over again, I see I was being a little "dense" about your suggestion to add |preserve=yes to Primerfac's suggestion. So the proposed change from what I had done was to drop the piped link (along with the |lt=The Terror of War).

IMO, if you do that, you would want to include a comment to document the fact that the target was a redirect (and what it redirected to). I suppose that if you haven't previously run into this situation, it might be perceived as a head-scratcher, but my contention is that having this fact explicitly indicated, specifically including the piped link, will actually facilitate its maintainability. Fabrickator (talk) 03:32, 2 April 2024 (UTC)

You have edited the page after Primefac's edit so I'll assume you aren't contesting it. So the case is closed: we agree there is little value in bypassing redirects for ills, and in fact, that going through a redirect is valuable, since 1) it means the reader isn't denied learning about a full article should one be developed and 2) it carries the potential for the ill to disappear once a full article at the redirect title is created (as long as we avoid the use of |display= or |preserve=) CapnZapp (talk) 09:13, 2 April 2024 (UTC)

No, that's an erroneous inference. Fabrickator (talk) 15:34, 2 April 2024 (UTC)

Either the case is closed or it isn't. Your personal opinions only matter if you want us to adopt them - I'm interested in the consensus, nothing else. Feel free to replace "we agree" above with "you accept the consensus thinks" if that helps. Thanks CapnZapp (talk) 08:57, 3 April 2024 (UTC)

This edge case results in anomalous behavior: Article foo has a link to bar, which doesn't exist but is available on another language wiki, so you create an {{ill}} for it. Sometime later, it's decided to create bar as a redirect which happens to go to foo ... to make it more interesting, have it redirect either to foo or to a section of foo. There's nothing inherently wrong about doing this, but it will create a surprising result. My answer to this is that you either don't want to show a link that takes you to the same page, or you want it to be clear that it's taking you to a section of that page. And that's kind of the rub ... for this to work without surprising the user, you need to resolve the redirect without using the redirect feature. And there's the rub... if you take a "see no evil" position, you have bad results. It would be nice if redirects could behave in a transparent manner, but the redirect can result in an anomalous case.

By establishing the policy that a link which is actually a redirect should be manually resolved provides a uniform solution and minimizes the amount of head-scratching. Fabrickator (talk) 01:07, 5 April 2024 (UTC)

That {{ill}} should link to local redirects and to the interlanguage article was established after lengthy discussions in 2016. Circular redirects are not limited to those caused by {{ill}}, but are infrequent. That's where, for registered users, User:Anomie/linkclassifier.js and User:Anomie/linkclassifier.css are helpful. -- Michael Bednarek (talk) 02:49, 5 April 2024 (UTC)

Never mind the fact that we're not talking about circular redirects... Primefac (talk) 06:12, 5 April 2024 (UTC)

I used the term 'circular redirects' for the situation described by Fabrickator, as I understood it: a link in an article that points to a redirect which points back to the article where it's being used. -- Michael Bednarek (talk) 10:46, 5 April 2024 (UTC)

Oh, you used the term correctly, however the initial situation that is being discussed is not a circular link, so the segue into using them as an example was more what I was calling out. Primefac (talk) 10:51, 5 April 2024 (UTC)

Yes, Fab in their example with foo and bar set up a circular redirect, but in the case actually discussed the redirect isn't circular. It is a link on the Napalm Sticks to Kids page that redirects you to the The Terror of War section on the Nick Ut page. Had Fab said baz instead of foo when they wrote it's decided to create bar as a redirect which happens to go to foo ... to make it more interesting, have it redirect either to foo or to a section of foo. the example would better have represented the case discussed. CapnZapp (talk) 15:21, 5 April 2024 (UTC)

Nevertheless, the primary objection raised is that a redirect can change... so what is not circular today may be circular in the future (so perhaps we should consider which would be the more problematic... an updated redirect that we don't follow or an updated redirect that becomes circular). Notwithstanding that issue, I think this is best characterized as a "best practices" issue rather than a policy issue, and perhaps not subject to a decree that can be so readily imposed as it seems like you would have it. Fabrickator (talk) 16:58, 6 April 2024 (UTC)

This is the first time I have understood your objection to be related to the malleable nature of redirects. Firstly, does this mean we now agree the current way regular redirects are handled by the ill template is adequate? Secondly, sorry, honestly, I don't see the big issue. If the occasional redirect gets changed to point back to the page with the ill on it, so what? It certainly doesn't strike me as a problem big enough to warrant a preemptive solution. Meaning I would not change all redirects just because the potential exists some of them could become circular. CapnZapp (talk) 19:32, 7 April 2024 (UTC)

Any time you have a link that's a redirect, you don't a priori know where that link is going. But if you know it's a redirect, you have been warned. As an example, consider the 15 February 2024 version of Vazha-Pshavela. You will see a reference to "Boygar Razikashvili". You look this up on Wikidata. You will see that there's an English-language link and a Georgian-language link. Oh, btw, the English-language link is a redirect (to a section). You don't care, it's a valid working link, so you righteously add the link. So sorry, you just broke it.

If this section link had been redirected from any other page, it would have been "good", and if that link had redirected to any other page, it would also have been good, but that wasn't the case, so you've broken the page.

But let's consider that case. It's not a circular link ... today! Tomorrow, somebody changes the link, and it becomes circular.

When a naive user encounters this, it's vexing and perplexing. You worry the naive user is going to miss out on the newly-created English-language version of the named article.

My way, we avoid a potentially non-functional redirect. Somebody adds an English-language version of the article and this link doesn't pick it up. I won't lose sleep over that. It's a relative matter, keep it in perspective, because that problem will get fixed sooner or later, and with less frustration for the naive user community. Fabrickator (talk) 11:51, 14 April 2024 (UTC)

I don't understand why you say it's a valid working link, so you righteously add the link. So sorry, you just broke it. I do not follow your explanation of this (or even very clearly what it is you are proposing as an alternative). If I'm understanding correctly, you seem to want to have a hard-coded link to a section rather than using a redirect in the ill template. If your concern is that the redirect target might change -- using a hard-coded section link has very similar issue -- the section headings are often edited and even the content from a section of one article can be moved into a completely different article. I don't see how your approach is any improvement. older ≠ wiser 12:20, 14 April 2024 (UTC)

You would seem to be making the case that we should avoid using section names as a target. Notwithstanding that issue, it's going to be less perplexing when the section label is visible in the wikitext than when it's buried in a redirect link. FWIW, at least some editors follow the practice of using a piped link rather than relying on a redirect (perhaps depending on the nature of the redirect) ... our mental model of redirects is that they're "transparent" ... i.e. you don't care where the redirect goes as long as it specifies the intended target... but this is not the case when the redirect goes back to (a section that's on) the same page. Now if the target section name is no longer appropriate, it breaks but in a quite transparent manner ... whereas when the section is specified in a redirect, it works okay from every other page but breaks when it's used on just the one page that the target redirects to. So in principle, this could break one way or the other ... but when it breaks, the advantage is that it breaks in a transparent manner, e.g. the section name is no longer applicable. Now if you've got this section name in a redirect (which likely was updated by some other editor), it's less apparent because it's buried under a redirect, with nothing that really alerts you to the fact that it is a redirect, and why should you have to know that, because transparency is a primary point of a redirect. Fabrickator (talk) 14:18, 14 April 2024 (UTC)

IMO, it is always preferable to use a redirect rather than a hard-coded piped section link when there is a good likelihood that the topic might someday support a standalone article. In other cases, it is mostly a wash, although when there is a change affecting the target, it is far, far, far simpler to fix links by updating the redirect once rather than having to location all of the incorrect piped section links.

I do not understand this statement: when the section is specified in a redirect, it works okay from every other page but breaks when it's used on just the one page that the target redirects to. You seem to be assuming that editors frequently go around changing the target of redirects to some random topic. I'd argue that is far less likely than editors inadvertently altering a section heading. older ≠ wiser 16:16, 14 April 2024 (UTC)