Article · Wikipedia archive · Last revised Jul 2, 2026

Template talk:Interlanguage link

Last revised
Jul 2, 2026
Read time
≈ 106 min
Length
24.4k w
Citations
—
Source
Wikipedia ↗

I noticed that the number of supported linked Wikipedia articles was increased from 12 to 16 in October. A page with that many links would look like this:

Underwater basket weaving[az][bg][ca][de][es][fa][gu][hi][id][ja][km][lv][mad][nl][or][pl] is the most popular course at Wikipedia University.

I rather thought we should be moving down from twelve to maybe six max. When are more than that ever needed? Mathglot (talk) 06:39, 18 February 2026 (UTC)[reply]

I agree that a use case for 16 languages seems unlikely. I support reducing them to six. If I can't decide for the most suitable language version, I pick either the language most related to the subject or the Wikidata link and let readers follow their own preference. -- Michael Bednarek (talk) 09:25, 18 February 2026 (UTC)[reply]
You suggested a reduction to four links max three years ago: Template_talk:Interlanguage_link/Archive_4#Proposal: reduce the number of foreign links CapnZapp (talk) 16:11, 18 February 2026 (UTC)[reply]
The general view at that time seemed to be that 12 was too many for use in mainspace, but this number could potentially be useful in project space – there was no discussion for the increase to 16. I have no problem with the number being restored to 12 as looking at the template parameters usage report I found only one example of with 16 links – added in 2025 for something there has been a page for in English since 2008, I have removed the template. I also found examples where some of the other language versions have been deleted so the links to them could be removed. If changing the template to support only six links, I would suggest first checking through the about 150 uses with more than that to select which links to keep instead of just editing the main template which would cut off anything after the first six listed – some have the links arranged alphabetically rather than in order of usefulness. EdwardUK (talk) 17:34, 18 February 2026 (UTC)[reply]
If there is a legitimate use for 16 in project space then I don't object. I admit I was imagining articles only, and how it would look disruptive or confusing to users to see such a string. Maybe it would be enough to change the doc page, and not the code, then. How do people feel about recommending six (or four?) as a max in mainspace? And Capn, thanks for the reminder, I forgot about that. Mathglot (talk) 18:37, 18 February 2026 (UTC)[reply]
I would be inclined to not focus on any specific number, and instead urge the user (of the template) to only include foreign-language articles that actually add value. Without examining examples in detail my hunch is that the vast majority of 6 or 12 language ill links are created by completionists and "I don't want to be the one choosing one language over another"-ists. But I would say ill isn't intended to be a catalogue of every Wikipedia with an article on a given subject. As a Wikipedia editor it is absolutely my job to choose one language over another (when warranted of course). What is ill intended for? Currently we only say 1) to add links to foreign-language Wikipedias where English Wikipedia does not yet have an article 2) to provide readers options to research further and 3) to signal the topic should have an article on English Wikipedia (i.e. the red link). I would prefer if we strengthen this to state outright something to the effect of "add an ill link only if you believe the link adds value" - that is, that ill links should be a curated selection of foreign-language articles, and that 1) above should not be read as an invitation to add every language with an article on X. Once that is in place, any concern over numbers should fade away. Or rather, when and if a 12 link ill template is created, and we agree all twelve are warranted (presumably because they complement each other in some way), then I guess it's good the template supports 12 links...? CapnZapp (talk) 20:24, 18 February 2026 (UTC)[reply]
While I support having the technical ability in the template to have many languages (seems fine in user or project space), I would suggest that people only add more than one or two links if each new one leads to nontrivial additional content that is not in the first one or two language links present. But this requires manual curation, not hard rules. Perhaps there should be a maintenance project for ill's that link too many languages, and perhaps we should encourage users of multiple languages in a single ill to make a hidden comment explaining why they need more than one language. —Kusma (talk) 10:45, 19 February 2026 (UTC)[reply]
I think we can all agree that with 1 or 2 links, the usage is entirely non-objectionable (as regards the number of links, that is). Probably we can all agree that 3 links is also too few to spend energy investigating. If there's more than three links, however, I would certainly not object to justify the number if asked to. I would avoid having that discussion in hidden comments though, and would much prefer discussing such things on the talk page in question. If anything, the hidden comment should refer to the talk page (for example a short and simple "<!--5 foreign languages, as discussed on talk-->" would be good). Regards, CapnZapp (talk) 13:55, 19 February 2026 (UTC)[reply]
I thought that something like <!--de has most complete biography, fr has list of works, es has content about family--> might be appropriate to explain why you use three interwikis, but I tend to agree that the talk page is the place to go if the issue requires nontrivial discussion or explanation. —Kusma (talk) 14:57, 19 February 2026 (UTC)[reply]
<Tangent alert>I am generally against hidden comments that discourage editing of the page. Stuff like <!--don't change, there's consensus for this phrasing--> serves no other purpose than claim ownership of anything from sentence fragments to entire pages. Hidden comments should IMHO only be used as a kind of FAQ - when something is frequently changed you might suspect people erroneously think your intentional edit is a mistake and there hidden comments can help: <!--yes, this looks wonky but it really is intentional, ask on talk before correcting--> for instance. In your case, I would prefer this justification to be on talk, not in the hidden comment itself, since if I (for whatever reason) want to change or replace the ill links, I feel like I'm now arguing against that comment. It to me comes across as needlessly conflict-prone is all I'm saying. I should never feel I have to justify making a change to a page. I should be able to justify my edit, sure, but hidden comments that imply value to the status quo go against the ethos of Wikipedia I feel.
I will clearly say I fully understand the good faith place you come from and am in no way accusing you of any of this here, just that to me, hidden comments should be used as little as possible, and be kept as neutral and generic as possible. CapnZapp (talk) 15:25, 19 February 2026 (UTC)[reply]
I really doubt that there is any valid reason to have more than 3. I wanted to say more than one, but Kusma gave a good, albeit very strange example. Not sure why those pages would be that different that each had a unique fragment. But I really doubt anymore is needed. We aren't a link repository, and once you click on any of those language links, the others should appear on the sidebar. Gonnym (talk) 11:59, 20 February 2026 (UTC)[reply]
I can easily see two or three foreign languages ending up covering different aspects of a topic, and thus, an editor not wanting to have to choose between them for the "while you wait for English-language coverage, here are..." suggestions. As for more than three, you really need to explore the talk archive. Use cases were presented, that's about all I can really say, since I haven't looked into them myself. They were sufficiently persuasive back in 2023, is my impression. Regards, CapnZapp (talk) 19:49, 20 February 2026 (UTC)[reply]
Just noting that there are currently 37 pages with 6-9 wikilinks in the article space (though the cat still seems to be populating, a few hours later it's up to 49, so it might fluctuate), with ~1200 pages using 5. Primefac (talk) 22:49, 20 February 2026 (UTC)[reply]
The idea that there is some "limit" on the number of interlanguage versions beyond which one more additional version would be detrimental is highly arbitrary. Though enwiki has the largest number of articles by a longshot, there's no reason to establish an arbitrary limit on the number of other languages, as though there's some kind of special entitlement for English.. Even though enwiki has the greatest number of articles, it's still just one more language, and you never know when that's going to be in the language that got skipped over in the interlanguage link. I understand you probably don't want to read them all, but that's a decision for the reader to be making, not one that should be arbitrarily imposed. You never know when that "n+1"th language will have just what someone was looking for, perhaps it includes some detail missing from all the other versions. As for those who find the extra versions to be extraneous, they have the complete freedom to ignore them. Fabrickator (talk) 05:21, 21 February 2026 (UTC)[reply]
Are you talking about project space, such as a bot-created table, say? Or do you think there should be no limit in mainspa○e as well? How do you feel about the example sentence that opened this section—are you okay seeing a sentence like that in an article? I think it would be disruptive and very confusing to readers, don't you? And I do not understand the special entitlement point. Mathglot (talk) 05:51, 21 February 2026 (UTC)[reply]
My premise is rather simple: every language is useful. We don't know which non-English languages the reader is familiar with, and establishing an arbitrary limit is, well, arbitrary! Why should it be okay to create a limit only on enwiki, when every other language wiki is fine with just listing all the available languages? Even though enwiki has the greatest number of articles, it's still just one more language, and you never know when the one language that's skipped over is the language that the reader is familiar with. I understand you may not want to read all those different language versions, but that's a decision for the reader to be making rather than having it be arbitrarily imposed. For those who find the extra versions to be extraneous, it's hardly a lot of extra effort for the reader to just skip over them. Fabrickator (talk) 07:09, 21 February 2026 (UTC)[reply]
I am not talking about not reading all those those different language versions, I am talking about having two words [az][bg][ca][de][es][fa][gu][hi][id][ja][km][lv][mad][nl][or][pl] in a sentence or two sentences separated by a lot of stuff your eyes have to skip over while reading. Don't you find it kind of annoying reading that sentence? I do. Imagine an article with lots of those; I think I would stop reading it. Mathglot (talk) 07:23, 21 February 2026 (UTC)[reply]
You've placed this list of links withoout any context, so that there's not much clue why this list of links should be there. But Wikipedia pages are loaded with all kinds of "cruft" to which wikipedia users learn to filter as needed. Of course, this is only cruft if you have no interest in the target of the link. The more such links we have throughout wikipedia, the quicker that people will treat this as just how certain content appears in WIkipedia. Fabrickator (talk) 10:17, 21 February 2026 (UTC)[reply]

Discussing a hard limit seems moot - I don't think there is or will be consensus for one.

Other than what the template supports, of course. I have zero opinion on whether that number should be 12 or 16 - except that anyone implementing a reduction should feel responsible for cleanup, making sure there are no errors or incorrect usages hanging.

As for everyday use, if our documentation focuses on making sure "yet another" link actually adds value, and isn't just added "because" (for completionist purposes, for nationalist purposes), we should avoid giving a specific number. We should discourage listing all languages - as someone commented, the "this article in other languages" functionality already exists. We should also discourage listing every non-stub language. The "I don't want to choose between language X and Y so I'm including both" is a weak argument: as Wikipedia editors, we are asked to make editorial decisions all the time. Including both X and Y should be done when there's actual reasons for having both. And of course, "not everybody knows language X, so I'm adding language Y" is definitely a bad argument: we're not showing preference for "popular" languages, or languages English Wikipedia visitors are more likely to know.

What we could say is "typically no more than 2-3 links should be needed" or somesuch. This would not be a hard limit at all - just that whenever you consider adding another language over the two or three preexisting ones, you should be prepared to argue for why you think more are needed on talk: What value does your fourth link add to readers? Assuming a cogent argument is successfully presented, adding that link should be no problem. Obviously I'm not saying the 4th link is problematic while the 2nd isn't. I'm mostly saying it isn't worth it to be procedural about it when someone adds a 2nd or even a 3rd language. If we narrow our scrutiny to the 4th addition (and beyond) we simply save ourselves a lot of work.

Likewise, if someone reduces the number of links, and presents a compelling reason (such as "when Norwegian and Russian were added back in 2018, they complemented the Dutch and Spanish articles. Now in 2026 both the Dutch and Spanish articles have been considerably expanded, so I'm removing Norwegian and Russian, since they no longer bring any additional value over and beyond what the reader can learn from Dutch and Spanish") that should also be fine.

CapnZapp (talk) 10:57, 21 February 2026 (UTC)[reply]

Regarding the following text in the earlier discussion:

What we could say is "typically no more than 2-3 links should be needed,"

I don't think a failure to obtain a response to this statement constitutes a consensus to incorporate it as a directive as you have done (see Template:Interlanguage link/doc). This becomes an invitation to challenge every instance where more than 3 languages are specified. Setting aside your arbitrary limit, what is the point at which an extra language does more harm than good? A lengthy list of languages might be surprising or distracting to some users, but the more it's used, the more it's visible, the more we can expect people will learn to be pleased that these non-English versions have been made available to them. You find this objectionable, while at the same time, you prefer to impose your personal preferences, while dismissing the viability of implementing a proven solution that addresses your objection to having a list consisting of 4 or more languages. Fabrickator (talk) 21:31, 26 February 2026 (UTC)[reply]
I'm offering the following link as an example of how the Polish interlanguage link looks: pl:Revolut. Look for red links which have the icon following the link. Clicking on the icon displays the available languages (albeit in Polish, of course). FWIW, I'm doubtful that there's any special changes required on Wikidata tat specifically supports the Polish language implementation. Fabrickator (talk) 06:50, 27 February 2026 (UTC)[reply]
As for the language, I think I have been fairly open with my thought process. On the other hand, awaiting feedback that might never come is a losing strategy when it comes to Wikipedia editing, so... ¯\_(ツ)_/¯ What I mean to say is, if you genuinely think the language currently comes off as too strong, then I welcome your suggestions (either here on talk or as bold edits to the doc itself). I certainly did not have as my chief intention to make readers start challenging existing usage (though I have a genuinely hard time envisioning when a 4th or 7th language represents a meaningful contribution). More to the point, I intended my language to not come across as an "arbitrary" or hard limit, that's why I phrased it as "very rarely more than 1-2" and not "do not use more than N" where N is a single definitive number. In short, the intention definitely was not to make a four-link ill come off as "illegal". The chief intent is to discourage using this template as a replacement for the existing functionality that tells you "here are ALL of the languages with an article on this subject." If you can suggest a softer way to say "just because this template supports 16 links doesn't mean it is a good idea to use 12 or 7 of them" please do. After all, linking to half-empty sub articles provides very little less than zero extra value over the first one or two (or three) quality article links. Now, I realize you are probably arguing from an "what if ill used the superior Polish code?" perspective, so let me just remind you that until such time such functionality is implemented here on English Wikipedia, I'm assuming our template works as is, and that is what I'm basing my argumentation on. Cheers CapnZapp (talk) 12:05, 27 February 2026 (UTC)[reply]
I apologize for the delay in responding to you. What's been rolling around in my head is how many problems there are with your proposal, which is essentially to curate the selection of foreign language articles associated with a given topic. So for instance, I could raise the issue of simply how to select this subset of one or a few articles on a given topic. The "enlightenment" is that I don't need to elaborate on all the problems, I only need one.
After we have selected the various versions of the article to include in the interlanguage list, the articles (in all available languages) will remain subject to change, and the selection that was made some number of months earlier may cease to be appropriate. Thus we are creating an ongoing commitment to go through the curation process whenever any of the available language versions are edited (or when new versions are added as well as when any selected versions are deleted).
Listing all available languages (which we're already doing for any English-language article listed in Wikidata) is trivial, but curating an order of preference among all articles for a particular topic, essentially which needs to be done whenever any articles for a given topic is edited, and doing so within some reasonable period of time, I believe would be seriously out of the question. Fabrickator (talk) 07:24, 28 February 2026 (UTC)[reply]
First off: I apologize for the delay in responding to you. Discussions going a couple of days between replies is, I believe, still considered perfectly active and thus, no need to apologize.
Regarding your main argument, not sure where you're going with this. The alternative to having some links is having all of them. I find that a clearly worse solution. What is the point of this template? To signal to readers that just because English Wikipedia isn't all-knowing and all-powerful doesn't mean a subject isn't covered anywhere. Specifically, ill links are red links, meaning they send the signal "I believe this topic should exist on English Wikipedia but currently does not." They don't just carry a purely neutral technical meaning ("this link doesn't exist"), but quite specifically include "...but it should." (If the topic should not exist, the link shouldn't be red, it should be unlinked entirely.)
To me, that means that ill links should point towards resources that help other editors develop red link articles. Not every foreign-language article is going to be helpful. I don't see any point of including poor or sparse links. The basic notion of "this exists" is already much better covered by existing functionality (not the raw WikiData interface but WP:ILLSIDEBAR).
Please note - I'm not asking any editor adding ill links to commit to perpetual maintenance. I'm not arguing ill links must be perfect. If a foreign-language article deteriorates in quality or gets removed, so be it. If articles in other languages gets added or gets substantially improvements, so be it. Editors should not be compelled to add every language simply because their hand-picked selection might not stay relevant. All an ill link is saying is: "this topic should be covered by English Wikipedia, but isn't. It is, however, covered by other languages. Here are a hand-curated selection of such articles, the ones a human has found truly useful." And of course, nothing forces you to vouch for the quality of the language you select. I'm sure many ill links focus mostly on the "this topic should be covered but isn't" part, with a random foreign-language the editor found but haven't read thrown in (because otherwise the editor would simply make a red link).
What I'm asking you, therefore, is: what's the alternative to picking a few languages? If you have another reply than "all of them" please share. Otherwise, the key would be: can this list be populated automatically and should it? Because just providing every language with zero indication of quality will just replicate WikiData. Listing every language could be useful if the automation could also retrieve the articles' assessment data and thus emphazise the quality articles. But now we're (once more) entering the future. In the meanwhile, my arguments are predicated on the template as it exists today. I would ask that you do not take any future enhancements (such as the Polish template) into account when engaging in this particular talk section. You are entirely free to start new talk sections to suggest major overhauls to the template, after all!
So. If you are chiefly concerned about the language making editors think there exists rules or limitations that I have now told you never were intended, feel free to suggest tweaks. But if you're arguing that since anything else than just a machine-generated list of every language (with no differentiation) cannot be perfect, we should avoid that, I don't know what to say. That argument could be made for the entire Wikipedia - and still, we persist in crafting our articles despite knowing everything we enter could become obsolete one minute later. I don't see why ill links should be exempted. I don't see why people should stop trying to help budding article writers just because their suggestions might not hold up a year from now. The key here is: if you encounter a red link to Overwater basket weaving but it is in the form of Overwater basket weaving because I made the judgement call that the Madurese article was the most comprehensive seven years ago, you aren't meaningfully hindered in your efforts if that article has deteriorated and/or another language's article has significantly improved. You will probably still click WP:ILLSIDEBAR languages to get an overview of the information all Wikis combined could give you. However, the general reader would definitely be hampered if the ill link read Overwater basket weaving. Chances are the Madurese article still holds up, and thus Overwater basket weaving is infinitely more helpful. And of course, if you think that the Odia article contains significant amounts of information not covered by the Madurese article, you will amend the ill link to read Overwater basket weaving, or maybe even just Overwater basket weaving. CapnZapp (talk) 08:53, 28 February 2026 (UTC)[reply]
@Fabrickator, the ideal result is that given one or two links to a quality article in other languages that someone will take the opportunity to create an article in English and negate the need for using {{ill}}. Once there is even a stub in English, all the other languages are readily accessible (assuming there has not been a mix-up with the QIDs). IMO, it is an abdication of editorial responsibility to make a reader choose an arbitrary language with absolutely ZERO indications about whether that article in the other language is a one-line stub or some very bad machine translation of something or something someone managed to spam a pile of crap into. older ≠ wiser 12:35, 28 February 2026 (UTC)[reply]
older ≠ wiser Ha ha ha! Now you've defined away the problem. We just go ahead and create the stub, allowing for the existing mechanism to display the whole list of other languages to be displayed in the "languages" section in the left margin. Arguably somewhat annoying, though I will note that if this solution were to be implemented for other languages, we would wind up with a list consisting of bona fide articles with these stubs mixed in, which of course would easily become quite annoying. Hey, listen, ask and ye shall receive! Fabrickator (talk) 15:38, 28 February 2026 (UTC)[reply]
Just to note: you don't need to create an article in English to get access to all the other languages - you can find the same WP:ILLSIDEBAR list by following any of the supplied ill links, assuming that function works across all editions. Editors are of course free to start English language articles. Just observing that doing so chiefly to gain access to the language list does not make sense to me. CapnZapp (talk) 18:53, 28 February 2026 (UTC)[reply]
I'm not sure I have any reason to care for what you're saying ... perhaps it's something so obvious that I don't consider it perplexing. There is a "languages" section in the sidebar, there's a link that will take me to the available languages for the article being viewed. At least, that's how it works on enwiki. I suspect you want to make the point that this shows all the languages that the target of a given link is available in, that somehow would make moot the objections to listing one or two of the available languages ... because that's the point, we shouldn't be preventing users from (easily) viewing all the available languages for a given target. But I'm not grasping how that is the case. Fabrickator (talk) 22:54, 28 February 2026 (UTC)[reply]
If you want to reach a consensus over how to phrase our documentation, I expect you to make an effort understanding your fellow editors. Do ask if you feel I have been unclear. I will withhold other comments at this time. CapnZapp (talk) 09:27, 1 March 2026 (UTC)[reply]
The sidebar show the interlanguage links for the article I'm viewing ... so I suppose one could first go to a foreign language page that they don't necessarily understand, and see if that page has a link to the term of interest which makes no sense. Another possibility is to view one of the ill links for the linked article, oh, and then look at the sidebar there. I'll pick French. Whooops, sorry, no sidebar. Try some other, I might find one. Okay, there is a sidebar on the Turkish language. I'm lost, what was I looking for? Is there some kind third party who can help to clarify this? Fabrickator (talk) 21:21, 1 March 2026 (UTC)[reply]
"Whooops, sorry, no sidebar" – that's probably because you're looking in the wrong place. Afaik, every Wikipedia has a list of corresponding articles in other languages—French most certainly does—but not always in the same place. The default location for the language list for most (all?) Wikipedias and default skin is at the top of the page, not in the sidebar. Mine are in the left sidebar, but that is due to my choice of skin in Preferences. Mathglot (talk) 21:40, 1 March 2026 (UTC)[reply]
No, it's not ("an abdication of editorial responsibility to make a reader choose an arbitrary language with absolutely ZERO indications about whether that article in the other language is a one-line stub... or something someone managed to spam a pile of crap into" ). If you think it is, then at least be consistent and demand that wikilinks must also have an indication of whether the linked article is a one-line stub or a pile of crap. I see no reason why interlanguage links should be held to a higher standard. Mathglot (talk) 21:40, 1 March 2026 (UTC)[reply]
@CapnZapp: So as I understand your proposal, the "sidebar" is not necessarily the list of available languages that appears in the left margin on certain language wikis, but it also includes the pull-down list of available languages usually on the upper-right-hand side, so that as long as there is a link to any one language, the rest of the languages become visible, which "works" because the premise is that there's at least one {{ill}} by definition. Presumably, we're concerned that the user interface should be, shall we say, comparatively straightforward. You have expressrf concern about being presented with a lengthy list of language codes, while at the same time, you ignore the existing plwiki implementation (which I will continue to assert requires no changes on the part of the Wikidata project). You content that a lengthy list of language codes will be distracting. It's certainly true that the first time a user encoutners these language codes (even if there's only one), it's distracting. It may be a little surprising the first time a user sees any of these interlanguage lists, even if it's only one. People either click on these lists and decide for themselves whether they're useful or not. Maybe it's a little harder to ignore a list that has 15 items (with codes that are likely to be more obscure) compared to a list that with a smaller number. Many novice users may just ignore these lists, that is not cause for concern.
However, you would cut the list down to (for instance) two links from the available languages, and then navigate the pages from these two other language Wikis in order to view the full list of available languages, meaning that they're presented with a page that's in one of numerous languages. IMO, for the more novice users, this will surely be more perplexing, simply because the "pattern" of these pages can be quite obscure, and rather than being pleased that they have access to numerous versions, they will be perplexed when they click on a link which takes them to one of these pages. Fabrickator (talk) 07:13, 2 March 2026 (UTC)[reply]

I can't say I am certain about this, Fabrickator, but my best guess is that you come from the perspective "why doesn't we just implement the Polish template, where every language is pulled out of a WikiData identifier, and shown to users in a reasonably accessible manner?" (Feel free to correct me if I'm wrong). Okay so here goes:

a) this template functionality isn't (yet) part of the English interlanguage link template, and since you are (so far) the only editor even talking about it, I am not taking it into consideration. Also I'm not a template editor (I specifically mean I am not a Wikipedia:Template editor and thus couldn't edit this template even if I wanted to). I am having a discussion about improving the documentation of the template predicated on the template's current functionality. Please don't accuse me of "ignoring" functionality of other Wikipedias. There are hundreds of Wikipedias in other languages, with wildly different customs, traditions, and implementations. Before you or others port over the code into English Wikipedia it might well as not exist at all, as far as the scope of this discussion is concerned.
b) even if the template did change to the best of worlds, I personally don't like any solution that drops the human element, where an editor selects quality links. No matter how WikiData is presented, it will still present a quality article equally to an empty stub. Just like how the present functionality (WP:ILLSIDEBAR) presents every language equally. Giving readers dozens or hundreds of links is no better than giving them no links. Also keep in mind the possibility (risk?) that a more automated ill template leads to a backlash.
c) Theoretically, code could look at assessment templates and display A class listed articles differently from C class articles, but I don't take that into consideration for this discussion, about how to best document the present template.

So given what we have now, I'm improving the documentation in the direction I believe I have clearly outlined at various places on this talk page. Again, as best I can judge, you appear to have a completely different discussion. Nothing wrong with that, except your inability or unwillingness to split the discussions - after all, we CAN talk about two things at once. It would just help and avoid frustration if the topic of "improving the current template's documentation" and the topic of "drawing up plans for this template's future" could become separated talk sections (in my opinion).

I'm telling you this because my perception is that you aren't responding to anything I want to discuss, and don't even seem interested in my discussion. Likewise, my guess is that you are frustrated because I appear to not see what you're seeing. The logical thing would then be to... have two discussions! I could start a new talk section if you asked me, I'm just concerned other editors might still respond in the existing sections. I honestly think everybody would best served by you starting a separate talk section titled "should we import the Polish WP template?" (or whatever title you prefer).

Also, just so we're clear. I'm not Mathglot. I am not proposing any reductions to the number of language links supported. (In fact, the only change to the template I could currently see is the unmerging of {{Interlanguage link Wikidata}}. I suspect that merge was made for no better reason that "hey, fewer templates is better", and so far I have not heard a single argument to say otherwise. In fact I even suspect not a single second has been spent on considering any benefits to keeping {{Interlanguage link Wikidata}} separate.... But this is off-topic for this talk section.) I'm arguing we should encourage editors to only supply as many languages as needed to provide a) readers with a good overview of the subject and b) fellow editors with a comprehensive list of what resources other Wikipedias can offer to help with developing a red link. This is a documentation issue, not an implementation issue.

Best regards, CapnZapp (talk) 09:06, 2 March 2026 (UTC)[reply]

What I'll say is that I am opposed to attempts to mandate that an editor should select a subset of the available languages. Interlanguage links are a "surprise bonus" to the reader. There are comparatively few articles that don't have an enwiki version yet for which there are large numbers of other languages in which it is available. This demand to provide a curated list of non-English articles is quite counter-productive.
Of course, the list of language codes can come as a bit of a surprise to novice Wikipedia users (and to emphasize, I'm referring to the most typical set of users, who may have never edited a single article). There's going to be a first time they encounter such a list, whether it's a lengthy list or more commonly a fairly short list. I wouldn't claim that these foreign language links are self-explanatory, but it really doesn't take too much head-scratching to realize that clicking on one of those links, results in an article in which the words displayed are not in English. Those who are unaware of any way to translate the text may be prone to dismiss these links as useless. (I don't care ... interlanguage links are a free bonus, if you don't like them, then ignore them... this is just not asking too much.)
For the rest of the user community, that list of language codes (short or long) is an unmitigated bonus. We have all these "regular" red links, and for the most typical Wikipedia user (i.e. those who have never made a single edit), those red links are a pointless distraction. Attempting to curate the list of available languages is a really bad idea; a policy that requires an editor to justify language links (i.e. the implication that any more than some set number of languages is subject to challenge) is counter-productive. Having such a policy in place does not serve the broader community. Fabrickator (talk) 19:33, 3 March 2026 (UTC)[reply]
Matter of perspective I guess. Your unmitigated bonus looks to me like editorial laziness and in effect amounts to telling the reader we don't care about you and here are a bunch of links to languages you likely don't understand and we're not going to give any hint as to which articles are good quality and which are not. older ≠ wiser 19:39, 3 March 2026 (UTC)[reply]
And just to be clear, I don't think anyone is talking about mandating anything. Only that the documentation should recommend best practices. I mean no one can force anyone to do anything around here so long as it is not disruptive. There are lots of experienced editors (myself included) who routinely ignore some minor aspects of style guidelines (perhaps because the 'rule' is obscure and can't be bothered to look up; or because it makes very little practical difference). In the long run, bots and gnomes will eventually update it to align with whatever the relevant guidance is. older ≠ wiser 19:59, 3 March 2026 (UTC)[reply]
The proposer (who added the pertinent text to the interlanguage link "doc" page wrote "... you should be prepared to argue for why you think more are needed ..." This would authorize any editor to place a challenge on the article talk page to justify a need for the current list of languages, and in the absence of a timely response, to revert the edit which resulted in the violation of the recommendation or to use their own discretion to modify the link to conform to the guideline on the interlanguage link doc page that "more than 2 or 3 links are very rarely recommended." Now you say there are "bots and gnomes" that will somehow alter this rule. Sounds pretty fuzzy to me. Fabrickator (talk) 06:35, 4 March 2026 (UTC)[reply]
While you are obviously free to oppose recent changes to the documentation, I am not trying to "mandate" anything - I am trying to make the documentation go from saying absolutely nothing on the number of links (or WikiData) to saying, well, what it says now. I don't consider that a mandate, I consider that a recommendation. Recommendations can be easily overruled - but you are encouraged to then justify your exception. And yes, if you think that's "fuzzy" I take that as a compliment - since this isn't a Wikipedia policy or guideline page, every usage advice is "fuzzy" in that it can be adhered to or ignored at will. I don't think this will have a huge impact on usage, mostly because I choose to believe most editors don't add seven or twelve links where three (or even one) would suffice, but to me it's nice to encourage users to justify whenever they add more than two or three links, in the hopes most editors see the point and spend at least a little effort selecting fewer links of higher quality.
As for WikiData, it appears to be solved - that 2018 RFC hid in plain sight, I just added it here on the template's documentation subpage and not just over at Wikipedia:Wikidata#Appropriate usage in articles.
That said, what do you want, Fabrickator? It would help constructively moving forward if you could give us an indication of what would satisfy you. I am still very unclear on what exactly you feel is wrong and/or how to rectify it. Remember what I said earlier: If you are chiefly concerned about the language making editors think there exists rules or limitations that I have now told you never were intended, feel free to suggest tweaks. Either way, I do want to thank you for addressing the issues I'm concerned about.
Regards, CapnZapp (talk) 08:39, 4 March 2026 (UTC)[reply]
To be clear, if you or another reader is concerned about an existing four (or seven) link {{ill}} usage, I certainly won't come hunting you down. In my mind, the "worst" thing that can happen (full disclosure: I really think it's the best) is for some random editor to stumble across that ill link, and decide to pare it down to only quality links. Whether that leaves 1, 3, or all 7 depends on the links of course, and every such outcome is perfectly acceptable (including leaving the ill link with all 7). Then, the editor that added the original ill might object to the removal of one or more links, but that to me sounds like regular editing and resolving any conflict sounds like completely ordinary consensus forming. If that helps?
If you believe the current language will make overzealous editors ruthlessly remove every instance of a 4+ link ill, even where all four links meaningfully contribute (perhaps akin to how plot summaries sometimes are ruined because sizes outside 400-700 words are not tolerated) then I would encourage you to suggest tweaks to ensure the language comes off as a recommendation and not a mandate. Myself, I have a hard time envisioning that to be a problem in practice. Firstly, I genuinely believe there are very very few instances of a topic where 2-3 languages won't comprehensively cover it and where more are justified (but note I'm not ruling it out and am not trying to prohibit using all 16 of them), and secondly I honestly don't see the current language evoking that kind of overzealous (Occasionally. Mostly entirely justified) policing that our various WP:PLOTSIZEs do... and here I think it's important to note that WP:FILMPLOT, WP:NOVELPLOT etc actually are binding MOS pages, which this documentation page most definitely is not. CapnZapp (talk) 08:47, 4 March 2026 (UTC)[reply]
The doc page should reflect the fact that there is no consensus about how the set of languages should be chosen, indicating that some Wikipedia users will find a lengthy list of possibly obscure language codes to be distracting, while those who believe that attempting to curate a list which best meets the needs of the user community is ultimately futile due to the varying requirements of the Wikipedia user community, including but not limited to the varying levels of language expertise as well as accessibility to and limitations of translation tools available to the end user. There is no way to just wave away this problem. If you're going to make the case why there should be only a small handful of languages, then we should also have the argument that such an effort is counter-productive. If you're going to object to that, then you should not be making the opposite case, that limiting it to a small handful of languages is preferable. Fabrickator (talk) 23:23, 4 March 2026 (UTC)[reply]
It used to say that, in section § When to use, but that subsection was removed in the last couple of weeks. I find rev. 1339781589 of 22 Feb. altogether better than the current one. I understand the motivations behind the subsequent removal of the entire § How to section from the doc, but I think it might have been useful to some editors and am on the fence about its removal. Otoh, the usage subsections should not have been removed, imho, and you just bumped into one of the reasons why. Mathglot (talk) 00:16, 5 March 2026 (UTC)[reply]
First off, I don't believe I personally have removed much if anything - looking at the history for 2026, my edits have added plenty but rarely removed anything. I could be wrong, in which case I would appreciate the specific diff or diffs y'all object to.
As for your arguments Fabrickator, at this point you really need to present your alternative. So far you seem to be arguing that recommending fewer language links has no consensus (i.e. that you and - so far - you alone oppose it). But why are you actually opposing it? So far you have done nothing to argue why your alternative is better. Sure, you're arguing curating a list is "ultimately futile", but how do you see that as any different from the tireless work by the multitudes of human editors to improve Wikipedia in general... and also: what does that mean in practice?? That you prefer automation? That you prefer displaying every language (no matter its quality)? What do you want? Constructively speaking, that is? Above and beyond just a removal of any usage guidance? You need to present your alternative so we can start discussing its pros and cons, and decide whether we prefer one or the other. Just returning to the bad old times when our documentation had nothing to say on how to use the template, resulting in some users thinking it's okay to add all 16 languages (which I vaguely assume is Mathglot's initial impetus for starting this series of talk discussions) and/or using the WikiData link in article space "so I don't have to choose", makes me go "why?" - what possible upside would that have? Please start actually arguing for your alternative - why you find [your alternative, whatever that is] advantageous - and not just argue against my good-faith attempt at improvement.
And please also explain how exactly you can find a soft recommendation to choose quality over (what I presume) quantity to be "counter-productive", Fabrickator? You say it's futile, but to me that's a very poor argument for not even trying, and I'm having a really hard time seeing your perspective here. (I mean, it would make sense if you wanted to pave the way for the Polish implementation, but I acknowledge how you are quite specifically not talking about that here) CapnZapp (talk) 10:09, 6 March 2026 (UTC)[reply]
I don't think you did, either, but this point, I also don't care, as this discussion has gone on way too long, and is going nowhere. We should just let it die a merciful death. Mathglot (talk) 10:19, 6 March 2026 (UTC)[reply]
If it helps closing the discussion, I can note I have no objections to adding (re-adding?) "There is no general consensus when this template should be used, or what languages should be linked when an article missing in English is present in several other language Wikipedias." which is what I assume your first link was referring to. Cheers CapnZapp (talk) 14:39, 6 March 2026 (UTC)[reply]
I have gone ahead and boldly removed the claim that had been added to the effect that listing "more than 2 or 3" languages was objectionable or otherwise undesirable. Fabrickator (talk) 17:21, 6 March 2026 (UTC)[reply]
Whoops, I had overlooked a second instance of the suggested limit of "2 or 3 languages" within the "doc" file. That has now been removed. Fabrickator (talk) 03:14, 7 March 2026 (UTC)[reply]
I am going to assume good faith and consider that you misunderstood the latest exchange between me and Mathglot. A bad faith interpretation would be that you can't argue for your position: your "bold" edits completely undercut this entire lengthy discussion, and I cannot believe you don't understand that the "bold" part of the WP:BRD cycle is at the beginning of a discussion, and not a means to cut it short and stop listening to others.
In the GF vein, I have further edited the doc. I will remind you, Fabrickator; I really implore you to bring a more convincing argument (for removing any notion of a curated quality list) than "it's futile". So far you have not engaged on this topic at all, and I ask you once more to to lay out your arguments why us Wikipedia editors should abandon our usual drive for (manual) excellence. Note that other editors have chimed in to this discussion, none of them have objected to my idea and at least one have supported it. In particular: if (and I do say "if") you have plans for the Polish implementation, and oppose any recommendations that would go counter to an eventual future where every language is auto-populated, start a separate discussion about implementing the Polish code. If and when you gain consensus for that approach, this discussion becomes obsolete and you are free to remove any notion that a hand-curated quality list is better than mindlessly spamming 7 or 16 languages. I have stated multiple times, I am only taking the current template in mind. CapnZapp (talk) 08:50, 7 March 2026 (UTC)[reply]

I need to challenge your specific claims, Fabrickator, so here are a few comments to your initial posts (please text search the timestamp, I don't know if you can link directly to an arbitrary spot on the page):

  • 05:21, 21 February 2026 (UTC): We told you a recommendation is not a limit. Anytime an editor can justify 4 or 7 links, that's alright. Most of the time, though, we expect 1, 2 or perhaps 3 links to provide the comprehensive overview that is the purpose of this template. And in those cases, where the 4th or 7th link doesn't add more than "yes, this language also has an article", our argument is that this functionality already exists (WP:ILLSIDEBAR).
    • "You never know when that "n+1"th language will have just what someone was looking for, perhaps it includes some detail missing from all the other versions."
      No, it's not that you never know. Wikipedia editors can absolutely know. Don't add a language just because it exists. Add it because you personally recommend it.
    • "As for those who find the extra versions to be extraneous, they have the complete freedom to ignore them."
      Not as long as the list doesn't distinguish between quality articles and useless cruft (stubs and whatnot).
07:09, 21 February 2026 (UTC): Again, this is not a limit.
    • "My premise is rather simple: every language is useful. We don't know which non-English languages the reader is familiar with, and establishing an arbitrary limit is, well, arbitrary!"
      Every language may be useful, but many articles sure aren't. (That includes English Wikipedia by the way!) Please only link to actually useful articles, regardless of which language they're written in. Including or excluding a particular language does NOT mean Wikipedia or individual editors have anything for or against that language, it just happened that the topic was either covered more comprehensively in another language or that the language had poor coverage for this particular topic.
    • " For those who find the extra versions to be extraneous, it's hardly a lot of extra effort for the reader to just skip over them."
      I dispute this. And this is precisely the reason Mathglot started the entire discussion. And once more, if you want to find out the complete list of languages for which a topic is covered, you already have ILLSIDEBAR and you already have WikiData - I believe the value of this template is improved by not replicating that existing functionality.
    • "But Wikipedia pages are loaded with all kinds of "cruft" to which wikipedia users learn to filter as needed." As someone who has worked with user interfaces, I find this notion uninformed and unacceptable. Enough said.

If you have any questions, or are unsure about my logic, please consider straightening this out with me before continuing any further. Regards, CapnZapp (talk) 09:12, 7 March 2026 (UTC)[reply]

@CapnZapp: I'm under the impression that we have "agreed to disagree", though, assuming we're each in the habit of adding or updating interlanguage links, we could wind up working at cross-purposes, e.g. you create a link in which you intentionally omit one or more of the available languages. I see the link, realize that additional languages are available. I'm unaware how they came to be "missing", i.e. whether their omission is due to an oversight, was intentional, or if the omitted languages that were added subsequent to the addition of the interlanguage link template. (I will dismiss the idea of trying to research the history.) It occurs to me that a possible solution would be to have some indicator that a language is intentionally omitted. This could either be a hidden comment or it could be a feature of the template, i.e. list all languages in which the article exists, but have a flag indicating that a language is intentionally "hidden". I will note that there are so many instances where we are missing possible "ill"s that this may be more of a theoretical issue than a real one, but it could be quite irksome if we created a situation in which editors were working at cross-purposes with each other. Fabrickator (talk) 10:04, 7 March 2026 (UTC)[reply]
I will continue to defend your right to add an additional language to an existing ill link, but I will also trust your judgement - that the link you added actually contributes to the overall pool of foreign-language resources the ill link provides to the reader. Myself, I have never seen it as a problem adding or removing specific languages from ill links, because to me it is just part of editing articles: just as I sometimes add or remove or reword article text, I sometimes add or remove or replace ill languages. If the ill link has few languages, I seldom question the judgement of previous editors - if the ill link has many languages, I nearly always can very easily prune the list.
And with that, now that you have started an RfC, I don't anticipate further posting in this thread. Do continue to ping me if you post further comments or queries in this talk section directed at me, however! Regards, CapnZapp (talk) 11:59, 8 March 2026 (UTC)[reply]
3 articles is an appropriate max recommendation. Curating and making editorial decisions is what editors do and should do.  Mr.choppers | ✎  14:44, 7 April 2026 (UTC)[reply]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.
A summary of the debate may be found at the bottom of the discussion.

Should the documentation for {{ill}} be revised to either remove the statement that "more than 2 or 3 links are very rarely recommended" or to indicate that while some editors believe this to be the case, other editors believe that attempting to "curate" the list of languages in this manner is counter-productive? Fabrickator (talk) 02:10, 8 March 2026 (UTC)[reply]

Geneally speaking, every "language version" of an article is unique in its own way, and every user of English wikipedia has their own unique set of abilities with non-English languages as well as their unique needs for information from any particular article. While most people probably rely on machine translation, this will always have its imperfections. Users should have the choice to do what works best for them. Telling users they have to navigate on non-English Wikipedia pages (with each language having layouts which are unique for that variant of Wikipedia) because some people want to establish an arbitrary limit on the number of language links is highly offensive. Fabrickator (talk) 02:10, 8 March 2026 (UTC)[reply]

Why does an article need to use {{ill}} at all? Usually, it's because we would like to have a link to an article about a related topic, but English Wikipedia doesn't yet have one although one exists in another language. Say we're editing an article about an orchestra based in Germany, and in a paragraph about one of their performances there's a mention of a soloist. This soloist isn't well known outside Germany, so there are insufficient English sources to establish notability, so the soloist doesn't have an article here. But they are well-known (and even very highly regarded) in Germany, so there is an article at German Wikipedia. This is where {{ill}} comes in. Now, given a decent article on German Wikipedia to which we can link, would we also want links to their French, Danish and Italian articles (assuming those exist)? Probably not. One is sufficient. --Redrose64 🌹 (talk) 09:20, 8 March 2026 (UTC)[reply]
  • First off, I agree with Redrose64. In the vast majority of cases, one language's article will be the definitive one, and linking to more would only provide duplication, and more importantly: obscure which language link the reader should click to go directly to the quality article. Linking to a bunch of stub articles (which every language Wikipedia has plenty of, including English Wikipedia!) actively does the reader a disservice!
    Second, I can only speak for myself, but I have never proposed limits, only recommendations. And not enforceable policies and guidelines, but soft usage guidance only. And I don't consider my recommendations to be arbitrary. Recommending editors to constrain themselves to 2 or 3 links is not a limit. Any time an editor can justify having more, its fine to have more. I have specifically told the RfC starter that anytime they find a fourth (or seventh!) links can be justified, because they all bring something worthwhile to the pool of resources we give our readers, they should feel entirely free to go ahead and link to all of them, however uncommon that might be.
    Third, hand curating is what Wikipedia is all about. Every article is written using words and sentences some human came up with, as opposed to selecting predefined sentences from elsewhere (or relying on automation, LLMs and such; obvious links are obvious: WP:COPYPASTE and WP:LLM). Why should the selection of interlanguage links not follow the same principle - being selected by hand by human editors? Why would it be "counter-productive" to recommend the exact same approach here?!? {{Ill}} links are part of the running text and should thus in my opinion be part of the exact same editorial process as every other core part of articles, as opposed to the surrounding user interface.
    Fourth, the notion that not selecting a particular language is an offense against that language is emphatically untrue, and several attempts to communicate this to the RfC starter has already been made. If one language is selected over another, that is (should be) done purely on the grounds of editorial discretion as part of writing the best encyclopedia we are able to. That is, if a link to the article about RedRose64's example musician in language A is present while a link to the article about the same musician in language B is absent, this should be taken as nothing more and nothing else than that a human editor found the language A article informative and of quality, while the language B article was found to add nothing of note, perhaps because it's just a stub. In particular, nobody has offended language B. No reader should be outraged by the absence of their favorite language. Nationalist sentiments has no place on Wikipedia!
    Fifth: The functionality "give me every language about a particular topic" is already covered by WP:ILLSIDEBAR & WP:WIKIDATA and I believe it would be a mistake for this template to be reduced to merely another, if more convenient and/or user-friendly, way to access the same functionality. {{ill}} to me represents an opportunity for human editorial and curation, especially since it is, as a reminder, part of the running text. Do note: I have more than once told the RfC starter I would welcome a specific discussion about the Polish implementation of {{ill}}; just not in this way, where an attempt is first made to give way to "ill links should be able to include every language" and only then suggest "there's already an implementation that automates what we have now agreed on for all ill links".
    Finally, curating the list of ill links in no way prevents readers from accessing all of them, since every Wikipedia offers access to WP:ILLSIDEBAR & WP:WIKIDATA. The argument "Telling users they have to navigate on non-English Wikipedia pages" I find especially hard to digest considering we are discussing a template whose entire purpose is allowing users to navigate to non-English Wikipedia pages.
    All in all, I find that this RfC is started on faulty assumptions, and would like to clarify that multiple attempts have been made to engage the RfC starter in discussing them, with no avail.CapnZapp (talk) 11:42, 8 March 2026 (UTC)[reply]
No. On the one hand, nothing about this prohibits including more links. It is a recommended and quite sensible practice. In most cases, one or at most a few select languages is ideal. Perhaps there may be exceptional cases where links to more languages might be appropriate (although I cannot think of any cases in article space). older ≠ wiser 12:07, 8 March 2026 (UTC)[reply]
I consider various of the objections raised are faulty. As an example, not all Wikipedia users are as experienced as the people in this discussion. Even though I consider myself moderately experienced, I'm put off by having to navigate a screen in a language I'm not especially familiar with and a presentation of languages in words that I simply don't know. So first, I have to think about the fact that to see if there are other available languages, I first need to go to some non-English screen, figure out where on the screen the "sidebar" is, presumably have the browser translate the display. The procedure entails realizing that I need to think ahead why I'm even clicking on a language I'm not necessarily interested in, on the new page, I will need to look around to find the "sidebar", and then deal with options that are both words and scripts that I'm not necessarily familiar with, though this may be lessened if I take the extra step of translating the page. If this comes naturally to all of you, then you might consider whether you're capable of putting yourself in the position of being a considerably less experienced user than you actually are. Maybe I'm too inexperienced to realize there's a much simpler way to do this, which would only go to show this is not quite the trivial effort you would claim it to be. Fabrickator (talk) 03:53, 9 March 2026 (UTC)[reply]
First off, you keep ignoring the fact we think you start this RfC with faulty assumptions. My advice to you is to start addressing the concerns about your perspective raised. Let me follow my own advice by responding to your post: you appear to think that one of the main purposes of {{ill}} is to let regular readers access the ILLSIDEBAR/WIKIDATA functionality (a complete list of Wikipedias/languages covering a particular topic) of topics not covered by English Wikipedia, and if that was correct, you'd be right - asking people to click any random language just to access that Wiki's implementation of ILLSIDEBAR would indeed be... poor. But it isn't. A far more prominent purpose is to add links to foreign-language Wikipedias for articles where English Wikipedia does not yet have one. The intent is to provide readers with options to research further into topics not yet covered by English Wikipedia. While providing readers with ILLSIDEBAR functionality "of the second degree" would absolutely be useful, it must be considered of marginal utility. And more importantly: this function should not, in my opinion, hijack this template's current purpose. There. I addressed your concerns to, I believe, a satisfactory degree. Now please do me the favor of responding to at least one of the concerns about your own perspective, as raised multiple times on this talk. Let me suggest the obvious one: why do you keep insisting our usage guidance constitutes hard limits to the point where you even title this RfC "requirement to justify more than 3 interlanguage links" (my emphasis) as if people would start reverting you on sight any time you happen to add a fourth language without immediately supplying a justification? You have been told multiple times the template's documentation isn't policy or guidelines, but you keep ignoring or otherwise not responding to these statements. Thank you. CapnZapp (talk) 09:09, 9 March 2026 (UTC)[reply]
Either I am misconstruing this bit about the ILLSIDEBAR as any part of a viable solution or I am highly confused. Quoting you, The intent is to provide readers with options to research further into topics not yet covered by English Wikipedia. My objection is not to this intent, but to the use of an implementation that is highly user-unfriendly, if I understand correctly. To wit, if I am not satisfied with the specific interlanguage links which are offered, I select any one of those interlanguage links, and use the ILLSIDEBAR, which of course means that I'm on a non-English wiki page, where I'm faced with an ILLSIDEBAR in a non-English language. And this is how you want to proffer as something that's somehow supposed to be tolerable to demand that the "average" non-editor should use this, which strikes me as highly counter-intuitive. If I want to see an article in an unspecified "4th language", after viewing it in one of the 3 languages that it's offered in (not that I'm familiar with that language or necessarily interested in viewing it in that particular language, and then access the ILLSIDEBAR that applies to that language Wiki (because the sidebar presentation is different on each wiki language). This strikes me as highly disorienting. Am I missing something? Are you claiming that the presentation of the ILLSIDEBAR is actually and factually the same for each one of the Wikipedia implementations? Fabrickator (talk) 12:12, 10 March 2026 (UTC)[reply]
Most usages of the {{ill}} template offer just one language. In many cases, more exist, but add nothing significant of value. So they're not added. If you want to change the mission of this template to focus more on replicating the ILLSIDEBAR functionality, please pretty please start a separate discussion for that purpose where you clearly describe your end goal. The core question I really wish you'd stop dancing around is: Since the current mission of this template really isn't compatible with an aim to offer the ILLSIDEBAR functionality in a more friendly fashion, what's more important? Regards, CapnZapp (talk) 15:17, 10 March 2026 (UTC)[reply]
@CapnZapp: It's sort of ironic that after taking the position that having more than "2 or 3" language versions of an article is counter-productive, you make the point that most of the time, an {{ill}} template offers just one language. But what's ironic about this is, given your observation that the great bulk of the time, there are only a small handful of languages provided, why you have spent so much effort to focus on the small number of instances in which such links offer more languages? Setting that aside for the moment, I remain utterly perplexed about the focus on the ILLSIDEBAR. My perspective is that I'm viewing an article on the English wikipedia, and it uses some term for which it provides a link to an article, but since there is no corresponding article on enwiki, it provides me with a link to a German version of the article. But although there is only a link provided to a German language version, there may be additional articles about this same topic in various other languages. How do I find these?
Your answer is evidently that I go to the German-language version of the article and check the ILLTOOLBAR there. While I'm familiar with the location of ILLOTOOLBAR on enwiki, I have very little familiarity with the German wikipedia, and I'm not sure where I find the ILLTOOLBAR. When I do find it, it's "greek to me" and given the relatively low frequency of encountering this, my learning curve will be very slow. Somebody has made this particularly difficult, which explains why I'm not a very happy camper. It sure does feel like you're just dismissing my needs. Fabrickator (talk) 05:03, 11 March 2026 (UTC)[reply]
Agree with @Redrose64. I don't think I've ever seen an example where more than 3 ill links were warranted. Alaexis¿question? 20:56, 11 March 2026 (UTC)[reply]
From what I have seen, when you get to six or more languages they tend to be on disambiguation pages (e.g. D. tropica or Hawksbeard) with links to places like Commons, WikiSpecies, and WikiData along with the usual foreign language options. Primefac (talk) 23:57, 11 March 2026 (UTC)[reply]
@Primefac: When I am working on interlanguage links (which is what I spend the vast majority of my Wikipedia editing time on), I am almost never working on disambiguation pages. So if we have a particular rule that applies specifically to disambiguation pages, I am not going to argue the point. Fabrickator (talk) 03:21, 12 March 2026 (UTC)[reply]
I don't think we have any rules at the moment, I'm just replying to a comment about where I've seen many-link uses. Primefac (talk) 22:33, 13 March 2026 (UTC)[reply]
@Primefac: Your point is pertinent nevertheless. If the majority of the "user community" isn't particularly noticing the occurrences of interlanguage links that have "more than a couple" of such links, it rather sounds like the concerns about seeing lengthy lists of language codes are "much ado about nothing". But I think there is another aspect about this which has been overlooked, which is that if you look at articles which are available in numerous languages, the percentage of such articles which don't exist in English tends to fall rather dramatically. In other words, the more translations that have been created in various languages, the less likely it is that English won't be among those translations which are available. Fabrickator (talk) 08:25, 14 March 2026 (UTC)[reply]
Fair points. Primefac (talk) 09:24, 14 March 2026 (UTC)[reply]
Here's a real example from List of castles in Armenia#Castles in Tavush Province:
  • Tavush Fortress
I don't think this is helpful. Pick the one or two best ones, and omit the rest.
I had a quick look. Several of the articles appeared longer than mere stubs, and the Russian-language article included a picture gallery, so I ended up removing just two, both clearly stubs only. That leaves no less than six, and I agree further pruning would probably more help than hinder the reader. CapnZapp (talk) 11:22, 21 March 2026 (UTC)[reply]
Editors who find themselves navigating non-English wikis may wish to go to Special:GlobalPreferences and set a preferred interface language in the "Internationalisation" section. WhatamIdoing (talk) 00:11, 21 March 2026 (UTC)[reply]
To the OP question, I would like to know how we would reconcile providing parameters to support sixteen links, and at the same time say, "But don't use more than two or three of them". It's schizo, and makes it seem like we can't decide in a unified voice what the template is about. Mathglot (talk) 10:33, 14 March 2026 (UTC)[reply]
Hasn't that already been covered? You discussed the sixteen links here: § Number of language links supported and previously here Template talk:Interlanguage link/Archive 4 § Proposal: reduce the number of foreign links, where Kusma said: But that's not a good reason to cripple the template for use in red link lists in user or project space. Just because a template can do something, doesn't mean anyone must or should use it to its full capability. I really can't see it as a problem, especially if our documentation provides practical usage guidance. CapnZapp (talk) 12:08, 14 March 2026 (UTC)[reply]
I had been looking around for some statistics to support my conjecture that the proportion of articles which exist on numerous language Wikis, but for which there is no English-language version, is quite small. This is pertinent, because the premise of this "rule of 2 or 3" is that the Wikipedia user community (which I will suggest consists primarily of people who do few if any areticle edits) are flummoxed when presented with numerous language versions of an article. After much messing around, I found something that provides an approximation to the data I was looking for, and the sole deficiency is that it's restricted to "featured articles" .... but this still can be used to evaluate my conjecture. The page is WP:Featured articles in other languages.
For an example of how we can interpret this data to ascertain the validity of this suggestion, I'm going to start with the topmost language, which is German (de). At the moment, the referenced page shows there are 2,963 featured articles in German, and of those 2,816 are available in English ("with en"), for a difference of 147, being featured articles which aren't available in English wikipedia. Now if we click on the language label ("German"), we'll see the "count of languages". This shows that there is an article which is present on 399 different language versons of Wikipedia. (Whew!) If we scroll down, the number of different languages declines, and (if I didn't miss anything) for the first 2154 rows, the articles are all blue-linked, meaning they're already available in English, so that we don't care about them, because we wouldn't be creating interlanguage links for them. At row 2155, there is a red link for "Wallfahrtskirche Birnau", which exists in 11 different languages. We see another red link for "Das Eine" at row 2267 with 7 languages, and then at rows 2394 and 2395, there are two articles with 6 languages each. There are another two articles with 6 languages, for a total of 8 German-languages articles which are not available in English but but for which there are 6 or more languages. This is out of 147 articles that aren't available.
So we have a total of 8 articles out of 147 that have "more than 5" languages. Essentially, 5% of the German articles which are not available in English that are offered in more than 5 languages, and I will suggest that asking the motivated reader to look over 5 articles is not an unreasonable expectation.
That was for German. For the 147 Portuguese articles not available in English, only 1 has more than 5 languages. I'm counting 4 out of 79 Polish articles which have more than 5 languages. For Dutch, it's 1 out of 67 articles with more than 5 languages that are not available in English. Bear in mind that these are only for featured articles, so we would have to extrapolate how this would apply to the full set of featured and non-featured articles. I'm more or less contending that this issue that we need to be concerned that some articles might have an onerous number of languages for the reader to deal with is an unjustified distraction, because the number of such articles is vanishingly small.
OTOH, I consider that providing interlanguage links is probably the most productive use of an editor's time. With just a few minutes of their time, an editor can provide an interlanguage link (i.e. from one linking article) which has the practical effect which is comparable to creating a new article, albeit only from the place that it's linked from. I don't want to see that effort be burdened by some very subjective and potentially very time-consuming and contentious effort to decide which will be the "top 3" articles, notwithstanding the fact that which version is best depends on the reader's needs, and bearing in mind that every reader's needs are different. Fabrickator (talk) 03:45, 20 March 2026 (UTC)[reply]
At this time, I feel you're coming close to needing an intervention, Fabrickator. How many times have you been told 2-3 languages is not a "rule"? How many times have you been told that any time you feel justified in providing 4 or 7 links, people will likely trust your judgement? Why do you insist on only arguing the general case, when the time you must have spent researching would easily have been sufficient arguing for a whole year's worth of editing...? Any time you can find 5 foreign-language articles that have the "featured" stamp of excellence, OF COURSE, you're welcome to link to all five. But that's a very poor argument for including five piss-poor stub articles in another case. How is that not completely obvious to you? These talk discussions are getting ridiculously long. What you are doing here is trying to tire people out so you stop getting any responses. It is not going to work.
Over several talk sections spread years apart, I would personally characterize the consensus to be overwhelmingly clear: use just one link when that suffices, fewer is better than more, and don't use the template as if its purpose was to provide the entire catalog. If you can agree with that consensus, then we're into the details, and I for one is entirely open to further tweaking the wording of what our documentation recommends. But if you want to challenge what at least I consider a rock solid consensus, this kind of argumentation where you try to undermine individual assumptions ain't gonna cut it. Start an RfC. Invite every participant of the relevant talk sections. Ask a direct question. Not like this RfC where you dislike something (for unclear reasons) and refuse to provide an alternative solution, but an RfC where you envision what you want (not what you don't want) and make a constructive suggestion. Finally get an outcome and be done with it. Please stop it with this sniping. What are you trying to accomplish and for what purpose? Until and unless you explain yourself, you will have a hard time persuading folks. Sincerely yours, CapnZapp (talk) 09:47, 20 March 2026 (UTC)[reply]
You seem to have been bothered enough by the length of my responses regarding the small fraction of articles which exist in several languages yet for which there is no English-language version, that you would suggest that would be a basis for sanctions. That is highly offensive. It's a real thing .... that with your proposal, the great bulk of the curation effort would be spent on articles (not available in English) yet which actually have fewer than six language versions.
Additional objections to this scheme revolve around the lack of a centralized authority store for the ranking of non-English articles. A given article (in its various available languages) is cited by other articles but there's nothing to keep them in sync with each other (e.g. whether the French or German language version ought to be listed first), raising the question as to whether such differences are an oversight or are intentional. Fabrickator (talk) 04:25, 22 March 2026 (UTC)[reply]
I am not threatening you and I am not discussing sanctions, full stop, end of story. You would be well advised to stay clear of interpreting arguments as personal insults if you want your discussions here on Wikipedia to remain constructive.
I don't think your findings re: featured articles are in any way representative of articles in general, and I am not persuaded by the argument "since there are (supposedly) relatively few topics with no English article, we should abandon any curation efforts and just link to every language, quality be damned." For the umpteenth time: if you want to suggest us adopting the Polish implementation of ill, Fabrickator, just say so.
the lack of a centralized authority store for the ranking of non-English articles This is a worthy topic. Can we hope you bringing this up means you finally realize that nearly every editor participating in these discussions over the years clearly indicate a dislike for presenting a full catalogue of every language link regardless of quality or content? If so that'd be great. However, the talk page of this template, which was NOT built to accomplish this goal, is decidedly the wrong venue in my opinion. (And, I can't say I think a global solution, such as every Wikipedia adopting our WP:PIQA, is particularly close at hand.) CapnZapp (talk) 08:24, 22 March 2026 (UTC)[reply]
  • Not broken, don't fix it. The documentation sets a reasonable expectation while allowing case-by-case exceptions and will not be improved by extra wordiness or hedging. Those who are interested in the history and background can always read the talk page. —Kusma (talk) 10:30, 22 March 2026 (UTC)[reply]
@CapnZapp: Two or three days ago, I provided Tavush Fortress, as an example/challenge. You have been the only one to respond. In summary, you identified two of the eight language versions as "stubs" that should be removed. But you suggested that there were probably other versions that should also be removed. Presumably, if you had actually been editing the article, you would have pruned the list further.
There is a name for this approach: "The perfect is the enemy of the good". That applies in spades here, if only because editors' time is 'precious'. Even though the time is neither tracked nor is it billed for, it is limited. Time spent on activities of limited value should be spent on more productive activities.
If you wanted to propose something that would provide a ranking of the available versions without impacting editors' time, that would be great. Then we would have a "best of both worlds" solution. Fabrickator (talk) 20:47, 23 March 2026 (UTC)[reply]
Time spent on activities of limited value should be spent on more productive activities. Regardless of how you value your various editing activities here, it is pretty obvious that many or perhaps even most will have a very different estimation. IMO, any time that an editor spends making the information provided more useful for readers is highly valuable. (As opposed to pointing them to a slew of links to articles of varying quality in random foreign languages, and in effect saying, "you sort it out"). older ≠ wiser 21:09, 23 March 2026 (UTC)[reply]
If you wanted to propose something... I do not want to propose anything - I'm happy with current consensus. I talked in the context of how your proposal could be made palatable to me - if (and only if) there first was a way to automatically extract the quality assessment of wiki articles, and that this system worked world wide, then the automatic system could show a popup with only quality links per default, say only show articles of C class or better. And such a wondrous system could very well be acceptable to me and others. But we are very far from such a solution. This leaves you with two options as I see it - either just let the issue rest, or attempt to convince the community to adopt the Polish ill link, where every language is automatically displayed (regardless of article quality). Either way, please consider ending this RfC. CapnZapp (talk) 21:27, 23 March 2026 (UTC)[reply]
@CapnZapp: You wrote:

... any time that an editor spends making the information provided more useful for readers is ... valuable.

I pointed you at a link for which there were eight versions of the article (in different languages), you identified two of them as stubs; although you suggested that further pruning would be desirable, it seems that going that extra step was too onerous to bother with. Let's keep in mind that this is your current plan, which is to go through this process for every {{ill}} which has links for multiple languages. The fact that you felt it was too much trouble for this single demo does not bode well.
Setting that aside for the moment, what's your real plan? Because the same non-enwiki article is likely to be linked from numerous other articles. Is there any plan to keep them in sync, or is each such {{ill}} (i.e. for the same target article)) going to be treated as a separate case? This creates some doubt in my mind as to the efficient and effective use of editor time under your proposal. Fabrickator (talk) 04:49, 24 March 2026 (UTC)[reply]
You are setting aside all the things you need to focus on, and instead obsess over my "plans"...? I have no plan. My only plan was to have our documentation and usage guidance match consensus, which it now does, because it recommends editors to focus on quality over quantity when it comes to which languages to include in any given ill link.
Instead of trying to make my editorial discretion appear as problematic, I urge you to focus on yourself: what are you trying to accomplish, how well is that going, and could it be that you are just wasting everybody's time...? CapnZapp (talk) 18:57, 24 March 2026 (UTC)[reply]
source ↗

Opened over two weeks ago, this Rfc has had no support or oppose votes, and switched almost immediately into a discussion among two editors who seem to be at odds over a number of things. It is not clear to me how any of this is forwarding the goal of improving the encyclopedia. I grant everyone here with good faith and good intentions, but things are starting to get testy, and I wonder if you guys can agree on one thing, namely that further discussion along the same lines as above is unlikely to lead to a resolution of your differences. Maybe we can just disengage amicably and move on to other things where we know we can be productive instead of locking horns? I hope so. Wishing everyone an excellent day! Cheers, Mathglot (talk) 20:49, 24 March 2026 (UTC)[reply]

This edit from October 2013 has virtually identical verbiage ("more than 2 or 3 links are rarely needed") about the number of language versions to display Does that mean it was right then and it's right now? I think the flaw that is exposed is that, on average, the enwiki userbase (meaning both those who regularly edit articles and those who are mostly read-only users) is considerably more experienced today than it was 13 years ago. Nevertheless, the way the interface is designed, you have to recognize differences in the interface, which is actually displayed differently depending on the language of the interface. There's an underlying premise of "We say so", meaning these other editors know best which language versions of the article will be the best ones for you to read. Fabrickator (talk) 07:15, 29 March 2026 (UTC)[reply]
The text is the same because it is transcluded to the template – the old version of the template shows the current documentation rather than the matching documentation from 2013 which notes the template to support 10 language links, had an example using four, and gave no guidance on how many to include. EdwardUK (talk) 09:38, 29 March 2026 (UTC)[reply]
That would seem to be incompatible with the fact that the text is not identical; additionally, you would need to further explain the specific details of this alleged transclusion. Fabrickator (talk) 05:56, 30 March 2026 (UTC)[reply]
Fabrickator, this is a technical limitation of using the history page to view old versions of an article. What you retrieve from the history, is the wikicode as it was then, not the HTML (i.e., not what a user saw back then). When you render a ten-year old page from history, what happens is that first you have to first expand all the templates (and template-like magic words, and grab images and other things) on the page, then translate the expanded wikicode into Html, and then send the Html to a browser for display. So what you end up with is mostly the ten-year old text, but also here and there, 2026 versions of templates (and images, etc.).
You can see this in action, if you look at revision 289086216 of the article 'English Wikipedia' from 10 May 2009. If you look at the last sentence of the lead, you will see that it says this:

There are currently 7,204,213 articles on the site.

That's true now, but it wasn't true in 2009, when Wikipedia was about to reach 3M articles. Why is this? Because if you look at the wikicode of that 2009 revision, it looks like this:
There are currently [[Special:Statistics|{{NUMBEROFARTICLES}}]] on the site.
When you click that revision on the history page, it interprets {{NUMBEROFARTICLES}} now, the very second you are reading this (and it will change again in a second or two) and sticks that number into the expanded wikicode in its internal buffer, and only then does the conversion to Html, using the 7.16M value. So your 2009 page shows today's article count.
Pretty much the same thing when you view old versions of this template—it shows the old template with the latest doc. The documentation for this template is in a separate location, at Template:Interlanguage link/doc. When you pull up an old version of the template out of the history, it transcludes the doc page as it is right now, not some old revision of the doc page. If you want to see an old version of the template doc, you have to go to the /doc page, and pull up its history; then you can see the doc as it was. I hope this helps. Mathglot (talk) 07:44, 30 March 2026 (UTC)[reply]
I'm going to make what I expect to be my final point. I don't expect it to change anybody's mind, because it seems like a majority of participants have bought into the idea that Wikipedia editors can effectively curate a multi-language selection of versions of any given article, to find those versions which will be suitable for the bulk of users notwithstanding the challenges implicit in this approach.
My point is there are a huge number of opportunities for linking that could be fulfilled by interlanguage links. This represents a huge "technical debt" which substantially impacts the usability of Wikipedia. Certainly, the ideal is to provide exactly the right link that a user needs, but even if this were practical to do, the alternatives of "too many" links is far superior to "too few".
What is being overlooked with this is how it impacts the links we are able to offer. In respect to the value it provies, identifying a suitable interlanguage link (and the corresponding set of articles) is virtually a de minimis effort. The counter-argument would be that, over time, too many links waste the time of readers, so that an effective culling of links would seem to be more economical. There is a flaw in this, because editors have a much greater responsibility if they're going to cull the set of articles as compared to when a reader decides they have found a version that is "good enough" to meet their own needs. (If there's enough value to such preferences, it would certainly be possible to implement a voting protocol, allowing the different versions of an article to be ranked, without using the time of editors.)
What happens is that the requirement to curate the list, in principle, hampers progress on the existing backlog. In practice, I think it's worse, because of the substantially greater effort this requires, as well as a reasonable lack of certainty that you have found the most appropriate "top 3" versions ... never mind that we get back to the problem that these rankings would change as the various language versions of the articles are edited.
Interlanguage links represent the biggest, best and most under-utilized opportunity to resolve terms for which there is no approriate English-language article, and it is a great loss when we have a resource that can help us to manage this technical debt, yet we choose to cripple our ability to make the most effective use of it. Fabrickator (talk) 03:38, 6 April 2026 (UTC)[reply]
You really need to present a concrete vision for what you want instead of just vaguely lamenting how things are. By now it is clear nobody is going to abandon a very minimal and soft recommendation (again, not a requirement despite the title of this talk section) to choose fewer quality links over many quantity links for no particular reason, and by that I mean that you keep your arguments vague and subjective. Just dropping the very soft guidance surely is not your end goal. I won't tell you what to do, but I wonder if you wouldn't get the closure you need by finally taking the step of suggesting something concrete. How, exactly, should we avoid crippling our ability to "make the most of it"? If that is the Polish implementation of ill or something else - only you can know, but I'm thinking you need to get it out of your system. Propose something, and no matter whether it succeeds or fails, you can then finally move on. Move on to other areas of Wikipedia, I mean, where you can be productive and feel enthusiasm. You are clearly not enjoying yourself here at Template Talk:Interlanguage link. (If your post truly is your final point, and you plan on voluntarily ending this RfC by removing the tag* (per WP:RFCEND), please ignore everything I just said, and instead have a nice day.) Take care, CapnZapp (talk) 08:08, 6 April 2026 (UTC)[reply]
*) Or just wait until, I believe, April 12 without extending the RfC and the bot will close the RfC after the standard duration. Either way works. Cheers CapnZapp (talk) 08:18, 6 April 2026 (UTC) [reply]
Ok, here goes. One of the highest "return on investment" activities a Wikipedia editor can do is to create interlanguage links to facilitate access to article content not directly available on English wikipedia. The value to the user community is comparable to that of creating a new article on that subject. The typical Wikipedia user isn't going to go poking around on non-English wikipedias to find content for which an article doesn't exist on enwiki. In effect, adding such links provides value that's comparable to creating a new article on enwiki.
The numerical reality is that there is a huge benefit to the Wikipedia user community when Wikipedia editors add these links, and therefore, we should be encouraging the creation of such links. Unnecessarily burdeninng this process in the hope of removing links of marginal value is a bad trade-off if it materially burdens this process. So I am specifically referring to the mandate to restrict the set of links to the top "two or three" versions.
While you call it "soft guidance", a requirement to filter out language versions of articles because they're not in the top "two or three" changes what is primarily a mechanical process that might be done in 3 or 4 minutes to one which requires evaluating the relative merits of each of several articles (i.e. in different languages), which is a considerably more complicated process. It is not trivial, and in fact is highly subjective. Such an expectation will deter the creation of links that provide a high benefit to the user community. If somebody thinks it's worth their time to follow up this effort on the basis that the presence of some of the links is counter-productive and that the article would be improved by selectively removing certain links, I don't have any objection in principle to that (not withstanding my concern that it's a dubious use of their time), I am just objecting to establishing that the editor who is adding these links has responsibility for selecting which versions are not worthy and should be omitted. Fabrickator (talk) 08:32, 7 April 2026 (UTC)[reply]
You keep stating your objections, but your objections have been noted several times already. You appear to think the issue is that we do not understand your objections, and that rephrasing them will make us see your point and agree with you. But we do already understand your objections. You don't need to explain them any more times. It should be clear by now that the consensus is unmoved by your arguments. Editor after editor have chimed in saying variations of "one ill link is sufficient" and "more than 2-3 ill links are practically never justifiable". (That's not me trying to warp the response; I am genuinely trying to neutrally paraphrase the consensus). But you never respond to any of this. You never acknowledge that merely removing the soft usage guidance is considered to be problematic. You clearly do not see any issues with this, and that's fine, but others do. You never addressing the concerns others have expressed is, I believe, why you are not gaining any traction. Regards, CapnZapp (talk) 10:07, 7 April 2026 (UTC)[reply]
I had actually intended that my "then prior message" (of 03:38, 6 April 2026 (UTC)) was to be my final response, but then you actually encouraged me to provide a "concrete vision". My "concrete vision" is that there is an apparent deficiency that had not been taken into account by this policy, i.e. the loss of functionality (that being, the impact on the number of interlanguage links that editors would be able to create for a given amount of effort). This is materially different from the presumed convenience of having some "optimum" number of links specified by a given ill template. It did not appear that you had acknowledged this, you just stated that nobody had been agreeing with me when I had in fact made a materially different claim, which still has yet to be acknowledged. Fabrickator (talk) 11:28, 7 April 2026 (UTC)o[reply]
More than two or three ill links are practically never usable, with rare exceptions like the fortress above. Most topics that have several worthwhile articles would typically be notable enough to also have an English-language entry. Not wanting to clutter the text with links to Abkhazian- or Faeroese-language stubs does not mean we are denigrating those languages. Fabrickator, what is the purpose of providing links to every single language? Making the reader go stop at Wikidata first is not in any way helpful. We are editors, we are here to edit.  Mr.choppers | ✎  14:58, 7 April 2026 (UTC)[reply]
"Practically never usable"? You pose the question in a fairly absurd way. You want to discriminate based on which language is used, even though translation tools can translate to your preferred language. Of course, instances in which there are numerous languages in which a particular article is provided but more familiar languages are not available is comparatively rarte. But this is s "false dichotomy". Sure, there are cases where an article is available in 9 or 10 languages, but none of them is English. Such cases are generally quite rare. By choosing to reject particular languages, we would be establishing this as an acceptable bias. We accept that if it's in English, it's okay (but in which case, the full set is available via wikidata), but to extend to this idea that if there are other less familiar languages, we're going to be more restrictive. The decision about which languages are "interesting" should be entirely at the discretion of the Wikipedia reader rather than about somee Wikipedia editor, who has no knowledge about the reader other than that presumably that their preferred language is English. Notwithstanding that, these issues are comparatively few and far between, yet there's generally no reason to be imposing such restrictions on the Wikipedia reader community, based on what a particular Wikipedia editors feels would be the most suitable languages. Fabrickator (talk) 23:04, 7 April 2026 (UTC)[reply]
For me having fewer links is not discriminating against a language, it is making a choice based on which have the most comprehensive content, and as translation tools make the original language increasingly irrelevant then linking all of them seems equivalent to WP:OVERKILL when they either duplicate the same content of provide inferior versions it. As a reader, I find lots of links to be clutter that is less beneficial than two or three goods links. As an editor adding the template, I would usually have in mind which languages are going to be most relevant to a subject and check these first, and only add other links in addition, or instead, if they provide significantly more information. EdwardUK (talk) 00:34, 8 April 2026 (UTC)[reply]
No one is suggesting that we reject or suggest any particular language, that is a straw man argument. The {{ill}} is there to direct users to the best or sometimes couple of best articles. It is not picking between languages, it is picking between articles.  Mr.choppers | ✎  13:08, 8 April 2026 (UTC)[reply]

Closing this RfC?

I would like to draw everybody's attention to the fact that LegoBot has removed the RfC template (after the standard 30 days). Neither the starter nor anyone has made any moves towards extending the RfC (WP:RFCEXTEND). In fact, to me it appears as if the discussion just continues with no awareness the RfC tag is gone. (I would also say I find recent comments just going in circles, and that the consensus is crystal clear, but you are free to dismiss that as subjective.)

I am an involved editor, so I won't close this. But I am willing to ask for closure at WP:CR, meaning getting an uninvolved editor to assess the consensus and post a formal close. Unless someone objects (see WP:RFCRESTART)? Regards, CapnZapp (talk) 12:19, 8 April 2026 (UTC)[reply]

I support requesting closure. Best,  Mr.choppers | ✎  02:20, 10 April 2026 (UTC)[reply]
I believe this disagreement about the appropriate attitude towards handling of interlanguage links comes from a different attitude about the priorities that should apply to interlanguage links, and we can observe this from the mere difference in attitude about "redlinks". Specifically, redlinks represent an opportunity to grow the encyclopedia. When that article gets created, then that's one less article available to create. But from the point of view of the 98% of users who do not take on the role of editor, it is the opposite. A redlink is a dead end.
My attitude is that this should be made into a working link, and an interlanguage link is the quickest way to do that, and we should not burden that effort any more than truly necessary. I believe that the majority of non-editor users pick this whole thing up pretty quickly, and rather than curse the absence of an English language link, I prefer to believe that they are motivated enough that they're not bothered by being presented with a selection of languages. Having encountered some of these links with multiple languages listed, these users will not find this a mystery nor a great distraction, even if the list is sometimes a little longer than usual, and will realize that each version provides at least the possibility of getting a little more information than if that version had been omitted.
The overriding concern I have is the quantity of these "missing links" that provide no resolution. When we don't provide a working link (i.e. we just have a standard redlink), then the reader may reasonably assume that the information is not available on Wikipedia doesn't have the information at all. And that's far too common. Rather than providing a "path" for the reader to get information that's actually available, we just provide them with a dead end. That is the tragedy of the situation in which we have left our user community. Fabrickator (talk) 08:41, 10 April 2026 (UTC)[reply]
Fabrickator, please confine your comments to answering the question: "should we close this RfC?". Let's furthermore agree that any further general comments within this RfC (like the one you just posted) means you are okay with closing the RfC. CapnZapp (talk) 10:50, 10 April 2026 (UTC)[reply]
CapnZapp I apologize for the mis-positioningt of my previous comment. That said, insofar as I am able to determine, it is not the case that once somebody calls the question as to whether the RfC should be closed, that any further that discussion of the original question must be terminated. On that basis, I suggest that your demand to the contrary is "out of order". Fabrickator (talk) 12:19, 10 April 2026 (UTC)[reply]
You appear to labor under the misconception the RfC is open and on-going. It is not. The RfC has ended - the RfC tag has been removed. The option to just let you keep repeating your viewpoints with no end in sight is not available; that's not what an RfC is for: you have requested comments on a subject matter, and now you have gotten them. The state of the RfC needs addressing. Had there been any doubts whatsoever as to the outcome of this RfC and/or continuously new viewpoints being added, the proper response could be to extend the RfC to let the debate run its course. But I cannot in good conscience suggest or recommend that. Not a single editor in this RfC is agreeing with you, not one. Please heed the advice given above by User:Mathglot: Opened over two weeks ago, this Rfc has had no support or oppose votes, and [...] further discussion along the same lines as above is unlikely to lead to a resolution of your differences. Maybe we can just disengage amicably and move on to other things where we know we can be productive. Please choose to agree to have the RfC closed. CapnZapp (talk) 12:51, 10 April 2026 (UTC)[reply]
@CapnZapp: the RfC tag has been removed - true, but all that this means is that Legobot has noticed that the first timestamp after the erstwhile {{rfc}} tag is more than thirty days ago, and so it has replaced the {{rfc}} tag with an {{anchor}} tag, and removed the entry from WP:RFC/STYLE. That's all. It's not ended, and nowhere is it stated to have ended. Discussion may continue, but with potentially fewer new participants because of the reduced publicity. If you really want discussion to cease, enclose the whole section (except for the "RFC on requirement to justify more than 3 interlanguage links" heading) between {{closed rfc top}}/{{closed rfc bottom}} tags. --Redrose64 🌹 (talk) 22:25, 10 April 2026 (UTC)[reply]
The standard 30 day duration has come and gone, and now it's been over a week since. I see zero signs this RfC is going anywhere. Soon I will take Redrose64's advice and alert readers that the RfC has ended. I would welcome a summary from an uninvolved editor. CapnZapp (talk) 10:59, 14 April 2026 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

calling WikiData and other wikimedia projects

please see below for a clear presentation of the issue

This template affords two separate ways in which to link into WikiData:

Using lesser pocketmoss as an example:

  1. {{ill|Fissidens bryoides|qid=Q11093368}} → Fissidens bryoides
  2. {{ill|Fissidens bryoides|commons||species||pl|Skrzydlik prątnikowy|sv|Listfickmossa|wikidata|Q11093368}} → Fissidens bryoides

Only the first is documented.

Let me clearly state I personally don't consider any of these usages to be wrong, and I'm not here with an agenda to outlaw anything. I'm chiefly interested to have an open-ended discussion of best practices, and more to the point, if anything should be better documented at our page specifically for that, which currently doesn't mention usage #2 at all.

Note how the second usage enables you to link to both a number of languages and WikiData, which the first usage specifically cannot do.

How much should we discuss/encourage/discourage using ill to link into non-language projects such as the ones illustrated in the example above? Chiefly having usage in running text in article mainspace in mind. Cheers CapnZapp (talk) 12:50, 27 March 2026 (UTC)[reply]

The very short answer from me is that I don't think we should mention it. The fact that people have found this workaround is fine, but as much as I don't want to encourage it I don't think we need to be discouraging it either; the only examples I have seen of this phenomena are on disambiguation pages, which for better or worse will give one more avenue to allow a page to be written. We're not truly in BEANS territory but saying "do/don't do this" will just encourage more of it. Primefac (talk) 19:20, 27 March 2026 (UTC)[reply]
Per this RfC, Wikidata links shouldn't be included in the body of an article. Nikkimaria (talk) 23:45, 31 March 2026 (UTC)[reply]
Thank you for your reply Nikkimaria. {{ill}} already mentions this, since it documents the |qid= parameter. It stands to reason this would apply to this other way of linking to WikiData as well.
But what about other projects, such as the links to commons and species in the example? Regards, CapnZapp (talk) 08:06, 1 April 2026 (UTC)[reply]
I'd like to point out my use of the first type of these links in list articles. Take list of herbicides as an example. This is a comprehensive list based on reliable sources, not just a list of current articles. Most of the redlinks have Wikidata entries, which are used, inter alia, to make it easier for editors to create the missing articles, as User:RustyOldShip and others have done. There is a bot, Cewbot, which subsequently removes the redlink and Wikidata |qid and replaces them with a conventional link. See this example. I consider this as useful both to readers and article creators. Mike Turnbull (talk) 10:04, 1 April 2026 (UTC)[reply]
CapnZapp's excellent summary of this issue is wrong in one point; where he says that the documentation currently doesn't mention it at all. To the contrary, it appears in the third paragraph of the documentation which reads, Alternatively, the template provides a link to WikiData, with a footnote directing readers to the qid parameter.
The RfC telling people not to do this is also mentioned, but it's buried much deeper in the doc.
I think the use of qid=Qnnnnnnn for this purpose is an abuse of {{ill}} and a disservice to our users and it should be prohibited, but failing this, I'd be a lot happier if the extremely visible note about it in the documentation was removed.
It's also worth noting that |qid= isn't even suited to task. It doesn't create a link to the top of the WikiData page, but to a table near the bottom of that page (see Fissidens bryoides), making it even more confusing to readers. Oddly, the "wikidata|Qnnnnnn" form, which I don't believe is documented, doesn't have this issue (see Fissidens bryoides).
Mike Turnbull's example is interesting and yes, genuinely useful, but it may well be unique and can get by with WP:IAR to the extent that any change is required. Danbloch (talk) 06:26, 2 April 2026 (UTC)[reply]
Actually the doc has a WikiData section which seems to be recommending strewing |qid= links all over. Danbloch (talk) 06:38, 2 April 2026 (UTC)[reply]
Perhaps a quibble, but re: CapnZapp's excellent summary of this issue is wrong in one point; where he says that the documentation currently doesn't mention it at all. I am thinking about the second illustrated usage, where wikidata is just another project link in the same way commons, species, pl and sv are. Admittedly I took for granted everybody would know |qid= existed and that I was discussing the to me new usage: to not use {{ill|ill|qid=Q227554}} → ill but instead use {{ill|ill|wikidata|Q227554}} → ill. Fixed and thank you.
Regarding I think the use of qid=Qnnnnnnn for this purpose is an abuse of {{ill}} and a disservice to our users and it should be prohibited let me remind everybody that {{Interlanguage link Wikidata}} used to be its own, completely separate, template. The merge discussion was almost wholly focused on perceived consolidation advantages: Wikipedia:Templates_for_discussion/Log/2015_March_8#Template:Interlanguage_link_multi. (Two comments were made hesitating to include WikiData and Commons, but apparently these fell between the chairs or were ignored) If this is an issue maybe we start a new talk section and hash out the general issues before continuing with the issues brought up here by me, since I have assumed consensus agrees with this merge) CapnZapp (talk) 11:42, 2 April 2026 (UTC)[reply]

Listed at: WT:WikiProject Templates, WT:Templates, and WP:Village pump (miscellaneous). CapnZapp (talk) 21:33, 5 April 2026 (UTC)[reply]

So the questions I wish to discuss are:

  • should we allow/document/discourage/continue to ignore life usage, not using |qid=?
  • should we allow/document/discourage/continue to ignore combining this usage with regular life usage (this isn't possible with the |qid= usage that is already documented and approved outside running text)
  • should we allow/document/discourage/continue to ignore the use of {{ill}} to access any project in general (here's a list): life ...or possibly link to an existing page explaining policies regarding such links

In all cases I have usage in article space, in running text, in mind. Obviously many specialized usages are fine elsewhere.

Thanks for allowing me to clear things up, CapnZapp (talk) 11:28, 2 April 2026 (UTC)[reply]

Arbitrary break

For me, the main advantage of using Wikidata would be stable links. If articles get moved in foreign language wikis, then currently our links will not point to the right place. (Hopefully a redirect would get them there, but this is not guaranteed.) If we could use syntax like {{ill|Fissidens bryoides|qid=Q11093368|commons|sv|pl}} to get the links to commons, sv and pl then I think this would be the easiest for everyone. — Martin (MSGJ · talk) 07:56, 3 June 2026 (UTC)[reply]

Cheers. You do realize the template already supports {{ill|Fissidens bryoides|wikidata|Q11093368|commons||sv||pl|}} → Fissidens bryoides?. Compared to your code, every entry is extended to a project|name pair (per the template's usual workings); it's just that the "name" for the Wikidata project happens to be its Q code. CapnZapp (talk) 08:15, 3 June 2026 (UTC)[reply]
Yes I saw that above, but the empty parameters are not ideal. Also can the Wikidata link be suppressed? — Martin (MSGJ · talk) 08:17, 3 June 2026 (UTC)[reply]
Those aren't intended to be viewed as "empty" or a bad thing. They are supposed to be looked at as a convenience, and a good thing: you don't have to repeat the name if identical to the English target. What do you mean by suppressing the Wikidata link? If I didn't suspect I would be misunderstanding you I would answer "You can just not include Wikidata as a project." The main limitation is that you can't use the |qid= approach in the same {{ill}} call you want to use for various project (because |qid= originated in a separate template later merged) - this discussion section is supposed to discuss whether the way you can avoid that by using "wikidata" as a regular project name is a good thing (that should be documented), a bad thing (that should be prevented in code), or a tolerable but not recommended thing (keeping everything as is). Maybe the second option is what you meant by suppression... CapnZapp (talk) 08:35, 3 June 2026 (UTC)[reply]
What I am suggesting is that the sitelinks could be drawn from Wikidata, instead of having to manually specifying them. That would seem to me a clear and logical improvement to the template, but it might confuse the syntax. — Martin (MSGJ · talk) 08:59, 3 June 2026 (UTC)[reply]
That is the same suggestion made by Fabrickator (first mention here) which would mirror the Polish Wikipedia's version of this template. Primefac (talk) 09:06, 3 June 2026 (UTC)[reply]
That template is actually pretty nice. But we could still choose to curate the language links ourselves by specifying the languages as we do now. — Martin (MSGJ · talk) 09:13, 3 June 2026 (UTC)[reply]
I will assume you up to speed with that discussion, User:MSGJ so let's hear your thinking assuming you make this suggestion because you do not agree that a) presenting every possible interlanguage article would not be a good thing since most articles would be stubs or worse, and b) that the way you need to (not just can, but must) manually supply projects leads to human curation and thus higher quality? CapnZapp (talk) 09:25, 3 June 2026 (UTC)[reply]
Reminding everybody you can have a look at Category:Pages calling interlanguage link with many languages (the Fs, Gs and currently, a single H) and judge the quality yourselves. Regards, CapnZapp (talk) 09:29, 3 June 2026 (UTC)[reply]

Unless others chime in I will take it the community consensus is for our template to keep supporting all three bullet points I listed (11:28, 2 April 2026 above), while our help should continue to ignore/not document all three. CapnZapp (talk) 07:02, 9 June 2026 (UTC)[reply]

Ill with redirect present

Could we add an option of keeping the english-language link black when the entry is a redirect? I wanted to add Mitsuoka Ryugi, but it now redirects to Mitsuoka. It should eventually become a standalone, but I want to keep the link to the ja entry and a) not send people to the redirect and b) not have the bot remove the {{ill}}. Thanks,  Mr.choppers | ✎  15:04, 7 April 2026 (UTC)[reply]

Keep the english-language "link" black? You mean not have it as a link? No. This template's core function is to present a red link so interested editors know what page destination to develop.
You created the Mitsuoka Ryugi redirect recently. The best solution would be to develop it into an article right now (possibly using Japanese language information) or at least add the bare-bones amount of info about this subject at the Mitsuoka page. I don't think asking at RfD for the redirect to be deleted so soon after creating it would be useful (though it would probably be granted, given how Mitsuoka does not even mention Mitsuoka Ryugi). As for the bot, use |preserve= to keep it from converting a blue ill link into a regular link. CapnZapp (talk) 16:36, 7 April 2026 (UTC)[reply]
Sadly I don't have the time to create every article which deserves to exist. I do not suggest deleting the redirect, I just wanted to be able to use {{ill}} until Mitsuoka Ryugi is no longer a redirect; |preserve= does exactly what I needed. Thanks,  Mr.choppers | ✎  17:18, 7 April 2026 (UTC)[reply]
I thought that as Mitsuoka Ryugi and the redirect target Mitsuoka have different wikidata identifiers (Q18457409 and Q1544189) cewbot should not remove the template until the redirect is converted to an article, and preserve will stop the template being automatically removed even after the article is created. EdwardUK (talk) 17:27, 7 April 2026 (UTC)[reply]
Ah - however, in the Automated removal section I read Cewbot will also not convert this template into a regular link if the English Wikipedia page exists but is a redirect back to the same page where the template appears; i.e. #Circular redirects. which suggests that it will only remove the template if it's a circular redirect. I will await confirmation before editing further.  Mr.choppers | ✎  20:00, 7 April 2026 (UTC)[reply]
EdwardUK, you see that "not" in the part you quoted from Cewbot? It will *not* convert a circular redirect, according to your quote (which you quoted correctly). How do you get from that, to it *will* remove it if it's circular? Seems to me you flipped what it says 180° so you're saying the exact opposite of what the template doc actually does. Or have I misunderstood you? Mathglot (talk) 05:46, 8 April 2026 (UTC)[reply]
Fix ping: Mr.choppers. (Edward: apologies for the unnecessary ping.) Mathglot (talk) 05:50, 8 April 2026 (UTC)[reply]
Ah, thanks, my bad. I guess my question remains: will cewbot remove the {{ill}} template if a redirect exists or will it not? Edward says no, CapnZapp suggested yes, the template page instructions are not entirely clear. Perhaps we should revise the relevant section:
You can remove the template when a red link turns blue, and it is no longer needed. However, there is no need to remember to do so, because Cewbot does this automatically for you, replacing the template with a plain wikilink... Please be aware Cewbot removes this template when it detects the target article has been created on English Wikipedia, converting {{ill}} links to regular (blue) links.  Mr.choppers | ✎  13:01, 8 April 2026 (UTC)[reply]
Iff the bot checks the wikidata entities between English and foreign-language links and leaves those not matching, we should certainly say so in the documentation.
Since it is a fairly obscure point, best would be to use a {{efn}} note and point to the documentation of the bot. Unfortunately the bot appears to be undocumented. Unless you count the source code. In that case, the source code link is broken, and since the bot owner is Japanese I couldn't make heads or tails of a cursory look at the github. Perhaps easier would be to... just test it. CapnZapp (talk) 13:43, 8 April 2026 (UTC)[reply]

On the "Interlanguage link templates need to fix" report it currently has an ill template for Alexandre Singh on 2025 Seattle International Film Festival which is not a circular redirect (it redirects to an article about a film rather than the festival), but has not been converted by cewbot, so I expect that Mitsuoka Ryugi could also appear the next time the report is updated (although the number of problematic pages is so large that the report only shows 39% of them).

I agree that it could be helpful to add something about this to the documentation, though I also am uncertain of exactly how the bot functions, so I am unsure how best to word it – possibly following the automated removal footnote it could have something like "If cewbot detects an problem with conversion of a link it is added to a database report to be reviewed manually". EdwardUK (talk) 16:18, 8 April 2026 (UTC)[reply]

Lua module?

This template is presently implemented by using a large number of conditional statements. Would it not be possible to reduce this be re-implementing the template via a Lua module? Or has this been considered and ruled out already?

I searched the archives here but didn't find anything relevant (though I may have missed it). I did find a few mentions where others have suggested converting the template to Lua before, but it doesn't look like those brief suggestions went anywhere (I think because those suggestions were made in passing within larger discussions regarding other issues so attention was centered elsewhere.). – Scyrme (talk/solidarity) 21:35, 5 June 2026 (UTC)[reply]

From a parsing standpoint, I'm not really sure it would make much difference, the various conditionals are just simple #if statements; if they were #switch statements or had some more complex programming I might agree with you. That being said I'm not necessarily opposed to it, I just don't know what purpose it would serve. Primefac (talk) 22:15, 5 June 2026 (UTC)[reply]
@Primefac: While most of the conditional statements are #if statements, which on their own aren't costly, my understanding is that nesting the conditional statements in the way this template does makes them much more costly.
There are enough nested conditional statements here that it causes problems for articles which either use a large number of interlanguage links (eg. List of German films of the 1990s) or which are close to or exceed the limit for other reasons (eg. FC Dynamo Kyiv, where several of the redlinks could be converted into interlanguage links but doing so would worsen the problem).
I'm fairly sure if the template just invoked a module it would be less costly to use. Even if it only makes each individual use only a little less costly, for articles with lots of uses the efficiency savings add up. – Scyrme (talk/solidarity) 10:46, 6 June 2026 (UTC)[reply]
You probably are correct, I'll be honest I don't remember the exact "savings" when it comes to running a Lua module, but I do suppose if you had even a 5% savings, over 10 or 100 invocations you'd end up saving a bunch. Primefac (talk) 11:20, 6 June 2026 (UTC)[reply]
As a former programmer myself, I would say templates are inaccessible to the general Wikipedia community either way (even ignoring how many of the consequential ones are locked behind template editor privileges). While help pages such as (H:TEMPLATES) might try to present templates as just Wikipedia pages. They are created, deleted, and edited in much the same way as any other page as soon as any form of complexity is introduced, template code becomes utterly opaque fairly quickly. While I can fully understand how a LUA module can come off as much much easier to comprehend for a programmer used to imperative/procedural programming than chunks of mediawiki, I don't think either is especially helpful to most users of Wikipedia. (I generally feel that any move away from straight-forward wikitext is counter to Wikipedia's goals of inclusivity, including locking data inside WikiData or behind template code, where regular users simply can't understand how to edit things. In other words: that the core contributors amass a level of technical proficiency that makes them lose track of how complex Wikipedia have become. In yet other words: unless a rationalization in the form of databases and code is absolutely essential to the project's survival, we should have stuck with plain wikitext even when programmers can see efficiency gains in other solutions). All this to say that while I don't think it is especially needed work, User:Scyrme, if you volunteer to create and test a LUA version of this template, I'm neutral to that. Forcing the editors of List of German films of the 1990s, FC Dynamo Kyiv and similar pages to consider not spamming this template and instead adopt Template:Interlanguage link#Alternatives would probably be the much easier solution though... CapnZapp (talk) 07:25, 9 June 2026 (UTC)[reply]
@CapnZapp: Template:Interlanguage link § Alternatives simply links to Help:Interlanguage links § Inline links (links in the text of the article). That list opens by stating explicitly that using this template is the best practice. Using the template has multiple advantages over the other methods listed, such as displaying the title as a redlink which encourages article creation (perhaps via translation), as well as allowing a bot to automatically substitute the use when an article is created, saving the effort of manually going around looking for places to insert a link to the new article. Unlike the other methods, this template also allows for multiple language versions to be linked, which gives readers more choice and provides editors who translate articles with more material to work with.
I strongly disagree with characterising following the best practice as "spamming" and forcing editors to avoid the best practice and its benefits in topic areas where the creation of new articles is most desirable (there already exists articles in other languages, implying these topics are notable, yet the English Wikipedia is lacking in this topic area).
I could understand your response if this were just about minor optimisations which only benefit technically-skilled editors, but this is not the case here. Less technically proficient editors benefit from the use of this template, as do readers when this template encourages article creation and translation. Some templates (like {{lang}}) use Lua modules for good reason, and I am not the first to notice that this template would benefit from being one of them.
Regarding writing a module myself, I'm not proficient enough in Lua to do so. My knowledge of programming suffices for editing templates, but not writing new Lua modules. I know enough to know why this template has problems, but I can't fix it on my own. I didn't start this discussion from the perspective of a very technically proficient editor who wants to maximally optimise the code. I started this discussion from the perspective of a less proficient editor who's frustrated that this template is so expensive to use because it works against best practices and limits where and how it can be used, doing so apparently entirely unnecessarily ({{lang}} is far more complicated than this template, yet I can add far more uses of it to an article without breaking anything or even coming close to breaking anything). My hope is that by starting this discussion I can draw attention to the issue and encourage more proficient editors to do something about this. – Scyrme (talk/solidarity) 14:28, 9 June 2026 (UTC)[reply]
Additionally, this is a template where there's little reason for less proficient editors to need to frequently edit the code. This isn't like an infobox or sidebar, where editors may need to periodically add new parameters, add links, change headings, etc. With the way it works, the template doesn't even need to be updated when new language versions of Wikipedia are created. It's the perfect candidate for the sort of template that should just invoke a module. The level of protection on this template already limits access to proficient editors. While less proficient editors can still submit edit requests, the existing code with it's nested conditional statements and vague unnamed parameters isn't exactly transparent as it is; the template is probably opaque to most editors already, and I wouldn't be surprised if converting it to Lua actually made the code easier to read. – Scyrme (talk/solidarity) 14:42, 9 June 2026 (UTC)[reply]
From my experience, creating/modifying templates/modules is something I barely understand (I usually work from existing templates and copy/experiment with them for what I need). However, if the change would be an improvement, it would not matter too much to me that I could not technically understand it as long as it did not make any notable difference to how to use the template. Also, for the large articles the solution could be to split them (into films by year: "List of German films of 199X", and "History of FC Dynamo Kyiv"). EdwardUK (talk) 14:51, 9 June 2026 (UTC)[reply]
Splitting is a much better solution than limiting the use of the template, but we shouldn't need to split them because of avoidable technical limitations, as opposed to the split actually being an improvement for readers in some way. The rationale for splits should, ideally, be based on what's best for content of the articles in these cases, not on {{interlanguage link}} being disproportionately resource intensive for its purpose. – Scyrme (talk/solidarity) 15:03, 9 June 2026 (UTC)[reply]
(edit conflict) You argue so forcefully I wonder if I failed to make clear I'm not opposing your efforts, User:Scyrme. If that is the case: I am not opposing your efforts, Scyrme.
I do wonder if making it easier to place large amounts of this template on a single page might encourage the kind of inferior page that basically acts only as a linkfarm to other Wikis. To be direct: could it be that any page mostly consisting of ill links should be reorganized or even deleted..?
My take on this template is that it was created for the express purpose of improving red links. A red link is not simply a broken link. A red link is specifically for topics that should have articles but do not. That is, links to topics that aren't likely to become English language articles should not be red links. Therefore they should not be ill links either - they should be unlinked altogether. Ill is meant to provide material for English article creation. And to that end, I believe ill links should ideally link only to well-developed quality articles in foreign languages, not to stubs and similar: they are not very valuable to readers and editors alike. In summary, that ill links should be relatively rare for the biggest Wikipedia given how unusual you would think other Wikipedias beating us to the punch for topics we actually want to cover. Seems many editors have lost sight over the years of the basic fact that ill links are red links, treating this template instead as a way to indiscriminately link out of English Wikipedia. Again, this has nothing to do with you Scyrme and this is not me telling you to stop. After all, using technical limitations as a form of de-facto policy is inferior to, well, having that policy spelled out. CapnZapp (talk) 15:50, 9 June 2026 (UTC)[reply]
The examples given are areas where it makes sense that non-English Wikipedias would have an advantage. It makes sense that the German-language encyclopedia would have a head start on coverage of German cinema, for example.
The argument that links to topics that aren't likely to become English language articles should not be red links ... they should not be ill links either assumes the standards and overall quality of other language Wikipedias is inferior to that of the English Wikipedia, such that they permit content that would never survive here if translated. I don't believe that's necessarily true and, regardless, whether a particular non-English article is of sufficient quality to justify linking to it something to be judged on a case-by-case basis, not something to be discouraged by universally making it disproportionately costly to use {{ill}} in general (something you seem to acknowledge, so why you make this argument if not as an objection to using a module, I don't know).
I don't object to making it explicitly clear that this template shouldn't be used to link to poor quality articles just because they exist. In-fact, I'd support adding a subsection to the "Usage" section of the documentation about when to use and not use the template, which would elaborate on "The intent is not to catalogue every foreign-language article" by clarifying that the issue isn't just listing too many non-English links. However, this is all entirely irrelevant to the issue of whether it would be helpful to implement the template using a Lua module. If you want, we can start a new section to discuss amending the documentation (or related guidelines) further. Going on a tangent about it here is not helpful; it will only result in this issue being neglected again after being raised because the focus was on some other, unrelated thing. – Scyrme (talk/solidarity) 16:26, 9 June 2026 (UTC)[reply]
Your very last point is taken; see separate section. CapnZapp (talk) 18:11, 9 June 2026 (UTC)[reply]
(cont'd from § Lua module?)

The argument that [links to topics that aren't likely to become English language articles should not be red links ... they should not be ill links either] assumes the standards and overall quality of other language Wikipedias is inferior to that of the English Wikipedia No it doesn't, or at least, I had no such characterization in mind. Plenty of stuff should exist at other Wikipedias but possibly not at English Wikipedia. Take a random Ukrainian footballer. If this person has no international presence and isn't notable in English language media, there is an argument to be made to not feature him on English Wikipedia. A page on a local football club might have a slightly stronger case of existing here, and in that case, it's questionable to use ill to link to that player's page in Ukrainian (or Polish or whatever). The case I'm trying to make is to not use ill just because stuff exists at other Wikipedias - to use ill, the red link needs to be justifiable, not just the foreign-language link(s). Either way, I am not saying these foreign-language pages are less worthy than English articles, just that some stuff covered by French or Icelandic Wikipedia does not merit an English language article, and thus does not pass the "red link test". Cheers CapnZapp (talk) 18:11, 9 June 2026 (UTC)[reply]

If the consensus is to not equate {{ill}} with red links = have them no longer be governed by WP:REDLINK that is, that's fair. However, in that case we should at the very least rewrite the documentation to make this clear. And perhaps even start a discussion on "should {{interlanguage link}}s be red at all? CapnZapp (talk) 18:14, 9 June 2026 (UTC)[reply]
Notability is not language-dependent and, per WP:NONENG, non-English language sources are acceptable for use here (though English-language sources are preferred if they exist for the reason that they are more accessible). A topic doesn't fail WP:GNG just because the sources aren't in English (in-fact WP:GNG explicity states "Sources do not have to be ... written in English"), and the sources aren't considered unverifiable or less reliable because they're not in English. There is absolutely no reason why a topic would be eligible for inclusion on another language's Wikipedia but not on the English language Wikipedia except if the community consensus of that Wikipedia applies lower standards of notability, verifiability, and/or reliability. An article which passes the same criteria of notability, verifiability, and reliability has already passed the "red link test" regardless of the language. – Scyrme (talk/solidarity) 18:31, 9 June 2026 (UTC)[reply]
I'm not saying the "red link test" isn't relevant to determining whether an interlanguage link is appropriate. It would be appropriate to apply it if you look at that article and see that it wouldn't pass the criteria for inclusion, since this implies that a link wouldn't actually be helpful (and may actually be unhelpful if the information is unreliable, which is very likely if there are insufficient sources to establish notability), but the Wikipedia's language isn't a relevant factor at all in that judgement.
To put it another way, why would it be relevant? How you make the assessment that a topic covered by, eg, the German Wikipedia shouldn't be included if it, hypothetically, passes all the typical criteria (WP:GNG, WP:RS, etc) used here? On what grounds should that topic not be covered here? Non-English sources are explicitly fine to use per policy. There's significant coverage. The sources are reliable. The sources are verifiable by anyone. There are plenty of them. Why wouldn't it warrant inclusion? Why would you exclude it from the English Wikipedia? – Scyrme (talk/solidarity) 18:54, 9 June 2026 (UTC)[reply]
I would like to refer people back to my comment from some weeks ago, primarily the bit about the soloist. --Redrose64 🌹 (talk) 07:46, 10 June 2026 (UTC)[reply]
The straightforward answer to this question is "yes". We should not redlink to a topic that is unlikely to be notable, and {{ill}}s are a subset of redlinks. If there's coverage on another edition of Wikipedia for a topic unlikely to be notable here, that could be for a few reasons. Most editions have somewhat broader notability guidelines than we do. And some may have de jure or de facto rules of lower notability standards for topics closely related to their language. Alternately, the article may fail their own notability rules but not have been brought up for deletion yet. There could be some rare cases where linking to one of these articles is useful for the encyclopedia, much like there are some rare cases where it's useful to link to a sister project other than Wiktionary, Wikisource, or Commons. In such cases, though, {{ill}} wouldn't be the way to do it, because we don't want a redlink; you would just link directly to the foreign article. Personally I can't picture a case where I would do this, but I'm sure there's some context where it could get local consensus. -- Tamzin[cetacean needed] (they|xe|🤷) 08:05, 10 June 2026 (UTC)[reply]
User:Redrose64, while I thank you for participating, your reply appears to simultaneously argue for and against my position. At the time, at least I focused mostly on the separate issue discussed back then; the number of ill links and not the basic existence of them. On one hand you agree with how I thought it worked: This soloist isn't well known outside Germany, so there are insufficient English sources to establish notability, so the soloist doesn't have an article here. On the other, you appear to take the stand that ill links should not be judged as red links, unless I misread you of course. Did I miss something here? Cheers, CapnZapp (talk) 08:48, 10 June 2026 (UTC)[reply]

Overlinking

If we do as I suggested earlier and add a section to the documentation elaborating on when not to use the template, one thing that would be worth mentioning, in addition to these considerations on article quality/inclusion, would be something about overlinking. Even if a good quality article exists in another language, it might still not be an appropriate context in which to include a link.

For example, the Chinese Wikipedia might have an article about a particular town in China which is mentioned in an article here on the English Wikipedia. Unless in context it's especially relevant to the topic of the article, links to places mentioned in passing are usually unnecessary even if an article exists (regardless on what Wiki), and adding an {{ill}} would effectively be overlinking. – Scyrme (talk/solidarity) 19:48, 9 June 2026 (UTC)[reply]

Wd or d?

Did you just change the template with no prior discussion and no documentation change, User:Chaotic Enby...? CapnZapp (talk) 19:10, 19 June 2026 (UTC)[reply]

Had a request from @Juwan to do it. I presumed it was small enough of a stylistic change (using the usual interwiki code for Wikidata) to not need a full discussion, although I've self-reverted as this apparently was less uncontroversial than I thought.
Regarding the documentation, the specific use case is only present in the table at Template:Interlanguage link § Stylistic parameters where the template is directly called, therefore there was nothing to change in that regards as the code wasn't in the documentation outside of template calls. Chaotic Enby (in solidarity · talk · contribs) 19:32, 19 June 2026 (UTC)[reply]
Out of curiosity, where was this request made? I would also note that half of the (recent) discussions about this template have involved WD (most recently in Archive 6 regarding this exact issue). Primefac (talk) 11:59, 20 June 2026 (UTC)[reply]
Apparently there is (or was) consensus for "wd". Don't get your hopes up you'll find it in the linked talk discussion though. CapnZapp (talk) 15:04, 20 June 2026 (UTC)[reply]
Juwan asked me about it through Discord, which I'll admit wasn't the ideal way to go at it either. I've been trying to get folks sending me Discord requests to ask them on-wiki as often as possible for transparency, although I thought this one was just a small aesthetic change and wouldn't be too big of a deal. Really my fault here, I'll admit it. Chaotic Enby (in solidarity · talk · contribs) 18:25, 20 June 2026 (UTC)\][reply]
Sure, no worries about the edit itself, just wanted to make sure I wasn't missing anything (figured it was a Discord ask). Glad to hear you request these to go on-wiki. Primefac (talk) 20:38, 20 June 2026 (UTC)[reply]
I've self-reverted Thank you. I should add I don't have a particularly strong opinion either way, but I know this specific issue has generated talk discussions in the past. CapnZapp (talk) 12:44, 20 June 2026 (UTC)[reply]
Didn't see it had been so widely discussed before, I should've certainly checked the talk page archives before doing it! Chaotic Enby (in solidarity · talk · contribs) 18:24, 20 June 2026 (UTC)[reply]

ill-lang?

Much like how we have the ever-so-useful {{wikt-lang}} to facilitate {{lang}} with wikt links, maybe we could have an ill-lang to facilitate {{lang}} with {{ill}} links (as mentioned in Template:Lang#Links)? Or perhaps this could be done automatically by {{ill}} given it already has the language codes? Dingolover6969 (talk) 01:45, 2 July 2026 (UTC)[reply]

As far as I can see, {{wikt-lang}} concerns itself mainly with italics. {{ill}} mainly links to names that don't need italics; if it links to titles of works that require italics, {{ill}} provides |italics=. No further functionality is required. -- Michael Bednarek (talk) 02:02, 2 July 2026 (UTC)[reply]
@Michael Bednarek There's a little bit more to language tagging than italics. In particular, there is metadata in the HTML so that screenreaders can read the text out in the correct language, and on hover the text is identified as X-language text. See MOS:NON-ENG and MOS:LANG for, uh, basically 0 additional information. Dingolover6969 (talk) 06:57, 2 July 2026 (UTC)[reply]