Template talk:Interlanguage link

Documentation containing examples of interlanguage link usage

The documentation for the following pages contain one or more {{ill}} calls. Anytime a well-intentioned editor creates an article this can break one of the examples; specifically because what was intended to be a red link with one or more foreign language links will now instead show as a blue link, making the example hard to understand if it isn't made entire incomprehensible.

Here's an example of former and current example:

• {{ill|Hooglede town hall|nl|Gemeentehuis van Hooglede}} → Hooglede town hall.
• {{ill|Tielt town hall|nl|Stadhuis van Tielt}} → Tielt town hall.

Note how the first example no longer showcases the template, because the Hooglede town hall article has been created, but that the second does because Tielt town hall remains a red link (at the time of this writing).

The list of pages to keep track of:

• Template:Interlanguage link
• Template:Lang
• Help:Interlanguage links
• Help:Interwiki linking
• Help:Red link

Wikipedia:Manual of Style/Linking mentions this template but currently without giving examples. Wikipedia:Wikimedia sister projects does not mention interlanguage links but probably should. CapnZapp (talk) 18:33, 19 July 2026 (UTC)

Oh the irony. Hooglede town hall was deleted (draftified) and so now even our reminder list to help maintaining the documentation broke... CapnZapp (talk) 18:14, 8 September 2026 (UTC)

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)

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)

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

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)

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)

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

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)

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)

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)

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

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)

Your very last point is taken; see separate section. CapnZapp (talk) 18:11, 9 June 2026 (UTC)

Another argument for doing this is at § ill-lang? below. CapnZapp (talk) 17:58, 5 July 2026 (UTC)

are interlanguage links governed by our guideline on red links?

(cont'd from § Lua module?)

the premise I hope for this new section to discuss

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.

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)

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)

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)

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)

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)

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)

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)

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)

Draft to clarify appropriate usage in documentation

Here's a draft, reworking the "alternatives" subsection of the "usage" section:

Before using

Before using {{interlanguage link}} please consider alternatives and whether the addition of an interlanguage is constructive and contributes meaningfully to improving an article.

Avoid excessive or unhelpful links

Interlanguage links should not be provided indiscriminately simply because an article in another language exists. Be mindful of overlinking; if a blue link would not be helpful in that context then an interlanguage link would not be needed either. Likewise, do not include every non-English version simply because they exist. Often one or two languages are usually enough and adding more is redundant. Remember, all available languages will be listed in the languages menu when visitng the linked non-English article.

Interlanguage links are often included to encourage article translation, but, like the English Wikipedia, other-language Wikipedias sometimes fall short of basic guidelines for inclusion. Before linking, review the non-English article to assess whether the topic would pass the general notability guidelines and whether the article provides substantial content which is supported by reliable sources. If the article would not survive the articles for deletion process if nominated it should neither be translated nor linked. A link to an article in another language which is stub about an obscure, non-notable topic including misinformation citing insufficient or unreliable sources is not constructive and is more likely to misinform readers than to be helpful.

Consider alternatives

{{Interlanguage link}} is generally the recommended method of providing an interlanguage link, however other methods may be more appropriate in some cases. Please see Help:Interlanguage links § Inline links for several alternative methods for including interlanguage links.

For use at the top of a section in the role where a {{Further}} link might normally be used, the template {{Further ill}} is available with similar functionality to this template for linking foreign Wikipedia articles.

Thoughts? Anything missing? Anything to cut or make more concise? – Scyrme (talk/solidarity) 22:52, 7 September 2026 (UTC)

@CapnZapp: What do you think? – Scyrme (talk/solidarity) 22:54, 7 September 2026 (UTC)

Starting from the end, the Consider alternatives (renamed from Alternatives) section seems fine. As for the Avoid excessive or unhelpful links (new section) isn't your first and third sentences saying the same thing? (If so, the topic of overlinking, which is not the same thing, should probably be moved either before or after) I also want to ask you to check so we aren't repeating ourselves from the lead section of the doc. CapnZapp (talk) 23:27, 7 September 2026 (UTC)

No, the first sentence is about using ill indiscriminately a link to every topic that that has an article somewhere other than here. The third sentence is about adding eg. 50 different languages to a single link. If you think it's unclear, how would you prefer to word it? – Scyrme (talk/solidarity) 17:34, 8 September 2026 (UTC)

The documentation is already huge, I don't think we need to be adding an additional two (sub)sections to it. A single sentence to the lead, and maybe a short paragraph in #Alternatives would be more than enough. Primefac (talk) 09:25, 8 September 2026 (UTC)

I don't know how to condense this further without losing information. I'm open to suggestions for how to phrase it better.

If the problem isn't actually with the draft but simply that there's already a lot in the doc, perhaps the doc can be pruned elsewhere to accommodate this guidance? Like the "When and where not to supply a Wikidata link?" seems to state the obvious and could easily be made more concise. The "Automated removal" could also be made more concise. The "Circular redirects" section probably doesn't need the redundant "In other words..." paragraph and probably doesn't need to state "Attempts have been made..." either as that's not really helpful to anyone trying to understand when/how to use the template. – Scyrme (talk/solidarity) 18:00, 8 September 2026 (UTC)

I got to confess, when I first read that Avoid excessive or unhelpful links section I did go "isn't this just rehashing policy from elsewhere?" so I do see Primefac's desire to prune. Can't we just remind readers ill links are subject to the same MOS:LINK as every other link? (Is there another case of linking "wrong" that is specific to this template other than not replicating the languages menu catalogue?) If we establish that this template creates links in general and red links specifically, and that these are not exempt from the general usage rules for those, doesn't this cover everything else in the do's and don't department? CapnZapp (talk) 19:02, 8 September 2026 (UTC)

I don't think it's immediately obvious how the general guidelines for normal links apply to {{ill}}, so at least some further clarification beyond just saying the equivalent of "also MOS:LINK still applies" seems warranted. – Scyrme (talk/solidarity) 19:50, 8 September 2026 (UTC)

What CapnZapp said. I don't see why the general advice on linking is not obviously applicable here. -- Michael Bednarek (talk) 02:41, 9 September 2026 (UTC)

This is neither made like a typical link (it's a template and the process of using it resembles using something like {{lang}} more so than simply putting square brackets around some text to make a standard link) nor is it formatted like a standard link (linking a non-English article using standard link syntax, eg. [[fr:Poisson]], doesn't produce a bracketed list of abbreviate language names in subscript). The purpose is also a step removed from that of a normal link, since it is usually used as a substitute or fallback for the absence of a working link, rather than it in itself being the intended link.

Speaking for myself, it didn't click for me that WP:OL, for example, applied to {{ill}} until my earlier discussion with CapnZapp prompted me to think about which existing guidelines {{ill}} is covered by and when not to use this template. In retrospect, it's clear now that something like listing five different languages in a single {{ill}} would constitute a form of WP:OL, but since the guidance at WP:OL almost entirely focuses on standard blue links, with only a brief note about red links in navboxes and no mention of {{ill}} or any other link-making templates, it was not instantly obvious that this template, with its distinct format and purpose, is even relevant.

That's not to say I did not think listing too many languages was a problem; only that I didn't instantly think to categorise that problem as a type of overlinking. I only thought of it in terms of it just being a bit awkward to have a long list of subscripts interrupting main text; superficially it resembles a style problem more than an overlinking problem (though it is in fact both).

Of-course it's possible that this is just a me problem and the exact connections between {{ill}} and MOS:LINK are very obvious to everyone else. If you're all in agreement that it's actually obvious, I'll concede to the consensus, though I personally have doubts that I'm alone in this. – Scyrme (talk/solidarity) 05:16, 9 September 2026 (UTC)

Speaking for myself, I absolutely agree a reminder that ill links are beholden to the usual rules for links is warranted - you are entirely right we shouldn't take for granted people will see how this template needs to be treated just like any other red link or link. However, I don't think we should summarize or paraphrase what the MoS is actually saying - just a reminder and a link should be sufficient, because our aim here is to have something to point to when an editor gets... overenthusiastic, let's say. More words isn't going to stop any such editor, but is going to make this help document even longer. Plus: if and when the MoS changes, our document would start to obsolete. What we should spend time on, however, is where the MoS has nothing to say, because of the unique features to ill links specifically. Is there any other such feature than the "don't use ill to catalogue the entire roster of languages, that's what the languages sidebar is for"? CapnZapp (talk) 10:06, 9 September 2026 (UTC)

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)

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)

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

In my experience, {{ill}} is mainly used to link to people or things in other Wikipedias; I've never seen a link to a term, word, gloss etc. Foreign names are never marked with language tags, and such tags for Wikidata items would be difficult to determine. -- Michael Bednarek (talk) 01:03, 3 July 2026 (UTC)

Just the other day I was trying to ill it:Discorso di Quarto.

Foreign names also are supposed to be marked with lang according to MOS:I!EPR. (Presumably so that the screenreaders work.) Dingolover6969 (talk) 05:56, 3 July 2026 (UTC)

I'm not sure you're going to get anything any simpler than the Lang#Links example; it looks like you'd need at least one extra parameter per language (and we're already at 32...) if we wanted to fold the lang option into this template to avoid adding the extra lang template into the text. Primefac (talk) 06:17, 3 July 2026 (UTC)

@Primefac Not sure why you think we would need more than about 1-ish extra parameters (or maybe 0), given that we only display one actual piece of possibly-foreign text. Dingolover6969 (talk) 09:04, 3 July 2026 (UTC)

Wasn't fully awake when I wrote that, I think; for some reason I was thinking each of the [lang] links was getting a tag, not the display text... we would, however, require an extra parameter for the lang itself; just because I link to an article in Japanese does not mean the term itself is in Japanese (I've seen this a surprisingly large number of times for de- and sv-Wiki pages). From a technical aspect I am now seeing fewer issues. Primefac (talk) 09:09, 3 July 2026 (UTC)

Thanks, I was thinking along the same lines are you are now, I think. Either some kind of lang= parameter thrown on this template for the main text or (as I initially thought but am starting to shy away from) a new template ill-lang where the fact that you want to reuse the first language tag is inferred (I guess maybe it would implicitly make all of them -Latn due to the rules of enwiki article titles?). I'm not married to any particular idea. Dingolover6969 (talk) 09:15, 3 July 2026 (UTC)

I guess the template documentation thinks the primary article link should always be in English, which is contrary to my imagined use case... the current documentation might just be speaking loosely, though (en wiki is not always titled with English titles) Dingolover6969 (talk) 09:11, 3 July 2026 (UTC)

Indeed, {{ill|Maman ne le sait pas|fr|quote=y}} is one of the examples that would probably fall into your proposed use-case for the lang expansion. Primefac (talk) 09:23, 3 July 2026 (UTC)

We definitely have here on English Wikipedia article titles in foreign languages. You mentioned one that isn't (yet) existing; another one (that does already exist) is Loin de moi. I don't think MOS:NON-ENG is particularly well known (and definitely not widely adhered to), but that doesn't mean I think it was a good idea by Michael Bednarek to confidently state No further functionality is required when it is clear manual italicization is not sufficient. Question: would it be a good idea to add support for |italic=unset (which would be the same as leaving |italic= out entirely) to not force {{lang}} users to relearn (though they might all be using {{langr}}?) CapnZapp (talk) 12:25, 3 July 2026 (UTC)

{{ill}} can produce italics, either by explicit use of '' or through parameter |italics=y. Nothing else is needed. -- Michael Bednarek (talk) 13:33, 3 July 2026 (UTC)

Why are you so confidently proclaiming only italics is needed when you have been politely told additional HTML metadata is prescribed by the Manual of Style, User:Michael Bednarek? CapnZapp (talk) 14:11, 3 July 2026 (UTC)

Specifying e.g. lang=fr as an attribute on a HTML element isn't HTML metadata as such; it's one of the global attributes (like class= id= and style=) that is permitted on all HTML elements. It exists in order to satisfy WCAG 2.0 Guideline 3.1.2 Language of Parts. This is Level AA, which puts it equivalent to "we SHOULD do this", where the word "SHOULD" is as per rfc:2119. Think of it as being equally important as having a text/background contrast ratio of 4.5:1 or better. --Redrose64 🌹 (talk) 23:15, 3 July 2026 (UTC)

SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Are there valid reasons to choose a different course here? As far as I can tell, the only reason given so far is essentially "{{ill}} can put the link in italics, so why bother?" which isn't really a valid reason not to apply language-related html attributes to interlanguage links if doing so is possible and there are editors willing to create the proposed template to do it. – Scyrme (talk/solidarity) 00:25, 4 July 2026 (UTC)

Judging by some other posts here, there seems to be confusion about what the lang= attribute is for. It's to identify the language of the text that is enclosed by the element that carries the lang= attribute. It is not to indicate the language of a page reached by clicking a link. --Redrose64 🌹 (talk) 13:03, 4 July 2026 (UTC)

@Dingolover6969: Or perhaps this could be done automatically by given it already has the language codes?

The language code applies to the title on the other language Wikipedia, not the English title (red) linked here on the English Wikipedia. An editor has to make the judgement whether the title linked here would need to be tagged as being in another language. There other practical issue is that {{ill}} often has more than one language code, so there's no way for the template to know which one is the relevant one, which again means an editor has to make the judgement.

The cleanest way to handle both judgements would probably be to use a single parameter which accepts the language code of the linked text, applying relevant html attributes like {{langlink}}, but defaulting to just working as {{ill}} presently already does if the parameter is unused or left empty. Ideally it would also set the appropriate italic formatting and it would also need an override to unset the italics, as {{langlink}}. The latter could be done by allowing |italics=n to be set instead of |italics=y; using a single italics parameter ensures that overriding italics is mutually exclusive with applying them. – Scyrme (talk/solidarity) 00:45, 4 July 2026 (UTC)

Another practical factor to consider is how the bot will replace the link. Otherwise the bot will strip the language formatting when it replaces {{ill}} with links to existing articles after they're created. Regardless of how this is implemented (as a new template or by modifying {{ill}}), it will need to be coordinated with the bot maintainer so they can have the bot replace {{ill}} with {{langlink}} instead if the other language is written in Latin script. If it's not in Latin script, then it should be formatted as a {{transliteration}}, though I think that template, like {{lang}}, doesn't work well with links so I'm unsure what the best course is there (something like {{langlink}} probably needs to be made for {{tlit}} as well). – Scyrme (talk/solidarity) 00:54, 4 July 2026 (UTC)

Probably best to complement |italics=n with |italics=unset, which is the custom {{lang}} users will be used to CapnZapp (talk) 07:43, 4 July 2026 (UTC)

Would it be a terrible thing to make the change to {{ill}} even if the bot maintainer (who I believe is Japanese) isn't (yet) on board? The benefits will still apply to all the {{ill}} links, even if these benefits are wiped by the (current) bot. In other words, making this a two step process where step one isn't held back by having to wait for an outside entity. It's not that anything gets worse during a time where only step one is implemented. CapnZapp (talk) 07:48, 4 July 2026 (UTC)

In the few cases where a term linked with {{ill}} should be marked in a foreign language and in italics, the obvious solution is to use use {{lang}}: {{lang|fr|{{ill|Envoyer|de}}}} -> Envoyer (a German magazine with a French name). This is unnecessary for links to names of people or places in other Wikipedias. Why burden {{ill}} with such mostly unneeded functionality? Further, links to other Wikipedias, even if they are not names, are not necessarily foreign words, e.g. IFPI Austria. -- Michael Bednarek (talk) 11:15, 4 July 2026 (UTC)

@Michael Bednarek: {{lang|fr|{{ill|Envoyer|de}}}} produces the following html:

<span title="French-language text"><i lang="fr">[[Envoyer]]<span class="noprint" style="font-size:85%; font-style: normal; ">&nbsp;&#91;[[:de:Envoyer|de]]&#93;</span></i></span>

As the [[Envoyer]] link inherently produces its own tooltip, the one provided by <span> doesn't work. Additionally, if this were used in an article it would produce a category link, as {{lang}} also categorises articles which use non-English text. Links cannot be nested within other links, so attempting what you suggest in an article would not work at all.

To make it work, the link must be formatted as [[Envoyer|{{lang|fr|Envoyer|cat=no}}]] which produces:

[[Envoyer|<span title="French-language text"><i lang="fr">Envoyer</i></span>]]

{{langlink}} exists to make doing this properly more intuitive, because it's not obvious to all editors why neither [[Envoyer|{{lang|fr|Envoyer}}]] nor {{lang|fr|[[Envoyer]]}} work as intended in articles or what they need to do to fix it.

I understand the concern about burdening {{ill}} as it's already disproportionately resource intensive to use for what it does, but that swings me back around to the issue that brought me to this talk page, namely that the template should be implemented using a module not using nested conditional statements (§ Lua module?).

Regarding your final "further" point, that's true and it adds a third judgement editors need to make to the two I listed earlier. {{ill}} (or a fork of it) definitely should not attempt to automatically format links as non-English. An editor's judgement is necessary regardless of how this is done. – Scyrme (talk/solidarity) 12:08, 4 July 2026 (UTC)

would not work at all – my example works here, no? Why would it not work in an article? Why should such an article not be in Category:Articles containing French-language text? I admit that the construction is unwieldy, but I maintain that it wouldn't be needed for the vast majority of use case for {{ill}}. It took me quite a while to find an example apart from Discorso di Quarto. I would like to see more before embarking on a major new development. -- Michael Bednarek (talk) 12:32, 4 July 2026 (UTC)

Why would it not work in an article?

{{lang}} automatically detects the namespace where it's used and behaves differently.

[[Envoyer|{{lang|fr|Envoyer}}]] produces:

[[Envoyer|<span title="French-language text"><i lang="fr">Envoyer</i></span>[[Category:Articles containing French-language text]]]]

That appears on the page as: [[Envoyer|Envoyer]] (I've simulated the output to avoid putting this Talk page into the category.)

This problem doesn't occur on Talk pages because the template doesn't include a category, since non-articles don't need to be put into the language tracking categories. – Scyrme (talk/solidarity) 14:05, 4 July 2026 (UTC)

User:Michael Bednarek, regarding the obvious solution is to use, the documentation for {{lang}} says to use the |lt= parameter: :{{ill|Ehōmaki|ja|恵方巻|lt={{lang|ja-Latn|ehōmaki|nocat=yes}}}} Cheers CapnZapp (talk) 13:27, 4 July 2026 (UTC)

Thank you; that's much clearer and less convoluted. -- Michael Bednarek (talk) 13:36, 4 July 2026 (UTC)

That workaround works but it's not exactly intuitive. I doubt most editors would know that this is the way to do it. A template like {{langlink}} that formats an interlanguage link properly in this way would be simpler and could be more concise when editing articles in the source editor. You could just have something like:

{{ill-lang|ja-Latn|ehōmaki|ja|恵方巻}}. – Scyrme (talk/solidarity) 14:12, 4 July 2026 (UTC)

If we decide this isn't worth the effort, at the very least the documentation for {{ill}} should explain how to format it correctly using |lt= and why it has to be done that way. – Scyrme (talk/solidarity) 14:28, 4 July 2026 (UTC)

Took an initial stab at this. Do brutally improve if you can! Note 1: I am certainly no expert, and know only what I can read over at {{lang}}'s documentation. Note 2: We should probably replace the example given for |italics=. Any good suggestion for a link term that is italicized for stylistic reasons rather than because it is a foreign-language term? CapnZapp (talk) 17:49, 4 July 2026 (UTC)

Note: Just to be clear, by engaging with the documentation does not necessarily mean I think this isn't worth the effort. It just means I think it is worthwhile to touch-up the documentation while we await a long-term better solution, should one ever materialize. If someone decides to implement {{ill-lang}} either in the current mediawiki code or as part of a new LUA module, you are very welcome! CapnZapp (talk) 12:25, 5 July 2026 (UTC)

why it has to be done that way: I feel the technical details (what the lang attribute does and why it needs to be placed correctly in the HTML code) is best kept out of the running text. That is, "do this and it'll work" - what I added - is all people need to know. Why it has to be encoded this way can perhaps be explained in a {{efn}} note... CapnZapp (talk) 12:32, 5 July 2026 (UTC)

@CapnZapp: Thanks for amending the doc.

By "why" I meant why |lt= has to be used in the manner described rather than just doing the perhaps more intuitive thing of wrapping {{ill}} with {{lang}} in the way Bednarek attempted. Something like the brief explanation provided by {{langlink}}'s documentation:

This is necessary because, if the language tag is placed outside the link, both WP:PAGEPREVIEWS and WP:POPUPS will prevent display of the language tooltip created by lang and langr.

I didn't mean explaining anything about why language-related html attributes should be used with non-English text. (Though I've added a link to MOS:IETF to elaborate on "accessibility reasons" for any editors who do want clarification regarding that.) – Scyrme (talk/solidarity) 17:09, 5 July 2026 (UTC)

italics example

After the recent "discovery" that |italics=yes is probably nearly always used the wrong way, I have tried to come up with a replacement example that should be italicized, but not because it is in another language. I struggled to find a term that a) requires an italicized term b) is in the English language, but still c) does not already have an article here on English Wikipedia, while having d) an article in a foreign-language Wikipedia.

In other words, some English-language term used by a foreign language (to merit inclusion in their wiki) but for some reason not relevant in the English speaking world.

I have replaced the example with "Cap Vilano", which is a ship's name; just guessing it is pronounced close to the same as in English, as if it was an English-language term. Do feel free to replace. Good luck! CapnZapp (talk) 18:37, 10 July 2026 (UTC)

The quote example also needs to be replaced, but I stopped here CapnZapp (talk) 18:40, 10 July 2026 (UTC)

If y'all can't come up with good examples, it might be time to consider retiring the italics parameter. If this parameter is only used to italicize words and phrases from non-English languages written using the Latin script, then it should either be removed, or it should be extended to use {{lang}}-like functionality ≈ what is requested above. (How many "live" {{ill}} calls with |italic(s)=y(es) are there currently...?) CapnZapp (talk) 18:45, 10 July 2026 (UTC)

Uh... Un papillon sur l'épauleUn papillon sur l'épaule is a drama, and thus should be italicised. It has nothing to do with the language. In other words... perfectly fine example. Primefac (talk) 20:59, 11 July 2026 (UTC)

This discussion isn't saying it should not be italicized. I was led to believe screen readers need to know that phrase is in French and so should not be simply italicized, but have its HTML properly marked; i.e. by using the "lang in lt=" method discussed at length by the main talk section this discussion is a subsection of. Your reply confuses me. Am I missing something? Are you claiming that phrase is okay to be read aloud as if it was in the English language?CapnZapp (talk) 22:18, 11 July 2026 (UTC)

I'm not approaching this from a language perspective, I'm approaching it from a "what type of text is it" perspective. A drama should be italics, so it's a perfectly fine example for italics use. Now, it does appear that we have been potentially ignoring/not using language codes in this template for over a decade (and that's what is being discussed above), but we need to be careful not to conflate issues; the italics in general is not the issue, the issue is that some of the uses of this template might actually need to have the lang templates implemented. I've set up a tracking category to see if italics is even used, let alone misused, so I'll hold off on further comment until that populates. Primefac (talk) 09:13, 12 July 2026 (UTC)

I still am unsure we understand each other, so excuse me for possibly overexplaining: the old examples showcasing italics (and quotes) were (as I understand it) directly wrong (or at least not aware of the accessibility issues raised here, and thus bad examples): they used italics to italicize terms written in a foreign language using Latin script, exactly the error this discussion is all about. I therefore started an attempt to replace these examples with what turned out to be something of a unicorn - the case where the italics isn't due to FOREIGNITALIC (in itself commonplace) but still relevant for an interlanguage link. You appear to directly work against this aim, so excuse me for asking: are we on the same page, Primefac, and if not, could you explain why and where you believe I'm going wrong? Thx CapnZapp (talk) 09:46, 12 July 2026 (UTC)

And just to avoid one possible misunderstanding - please don't revert the work of another user and then immediately declare you will hold off on further comment. I am sure you understand that if you choose to not engage I will in good faith assume you do understand my point, concede you were mistaken, and that you don't mind being reverted at least while we await further developments. Have a good day CapnZapp (talk) 09:51, 12 July 2026 (UTC)

I believe we frequently misunderstand each other, which is something that I am trying to work on. I cannot make any comment on whether the italics parameter is justified in keeping (re: if you can't come up with good examples...) until I know how often, where, and why the italics parameters are being used (this is why I said I would hold off on further comment). The /doc should be used to demonstrate the available options, not necessarily be a paragon of accuracy when it comes to the actual language HTML display. I would argue your quotes example is also "wrong" since the name of the ship should be in italics as well, but the point is to show "this is how you add quotes to the text". Primefac (talk) 10:23, 12 July 2026 (UTC)

Thank you. As I understand it, any time you would pronounce a term in a foreign language, you need to tell screen readers which language that is, or they would awkwardly read the term as if it was in English (cue Brad Pitt's dodgy Italian in Unglorious Basterds). That the term is a play or a ship means it should be italicized yes absolutely but for this reason, "Un papillon sur l'épaule" should probably not merely be italicized in any regular manner such as |italics=, but italicized in the specific manner that enables this accessibility, i.e. through the newly added advice at Template:Interlanguage link § Links for words and phrases in foreign languages. I take "Un papillon..." to be a term in a foreign language and not a loan term that should be read in English. If this is wrong, please correct me and revert my changes. If this is right, we should probably illustrate our parameters using examples that follow good practices, meaning that any time we showcase {{ill}} using a foreign-language term, we should ensure screen readers get the language information. How |italics= is used in reality does not seem relevant to our choices of documentation examples, and in fact, probably 99% of existing usage is wrong - I certainly had no idea regular means of italicization are insufficient for words and phrases in non-English languages written using the Latin script before Dingolover6969 educated us all. What I am asking is: Could it be that the entire addition of |italics= was done, while in good faith, by clueless editors that did not realize that basically every time an ill term needs to be italicized, it probably is because the term is in a foreign-language and thus "simple" italicization is insufficient? I sincerely hope we now understand each other. Furthermore, I now hope you (and everybody else) see why I found it so hard to come up with an |italics= example at all, and why I wondered if perhaps every example of |italics= is also an example that needs to follow Template:Interlanguage link § Links for words and phrases in foreign languages, leaving essentially no good-practice uses for |italics= unless, of course, we fix the implementation to use {{lang}} as discussed by the main section.... Regards CapnZapp (talk) 12:03, 12 July 2026 (UTC)

At the risk of belaboring the section, let's use the example of quotes. When we add an example where the point is to show "this is how you add quotes to the text" we hopefully agree we should not as our example use something that MOS:QUOTE tells us is a bad usage. Yes the point is how to enable quotes but I see no point in doing this in a wrong way. Similar with italics. Let's not tell readers how to enable italics using |italics= when the example should not use |italics= because the example needs to use |lt={{lang}}. Apologies if this was bleedingly obvious. Cheers CapnZapp (talk) 12:18, 12 July 2026 (UTC)

Thanks to your tracking categories User:Primefac I have found an example that apparently should be italicized the |italics= way. At least MOS:SCIENTIFIC does not use {{lang}} for Latin scientific names (though I cannot rule out it too was written by people unaware of MOS:FOREIGNITALIC I will simply follow the MOS). CapnZapp (talk) 15:19, 12 July 2026 (UTC)

And again for |quotes= ​ Regards CapnZapp (talk) 15:33, 12 July 2026 (UTC)

Scientific taxonomic nomenclature uses names formed in a Latinate style, but are not strictly Latin. The names are often a variation on a person's name or sometimes a place name. Even the ones named when Latin was a scientific lingua franca, the names were often artificial constructs rather than anything a native Latin speaker would have recognized. Species and genus names should be italicized, but not because they are 'Latin' language. Other Latinate elements in the taxonomic hierarchy (e.g., family, order, class, etc.) are not italicized. older ≠ wiser 15:36, 12 July 2026 (UTC)

What you've written seems to be the current Wikipedia MOS consensus position, as documented in MOS:SCIENTIFIC, but I'd like to add that, as best I can tell, the reason that scientific taxonomic nomenclature is italicized is because it's written in the non-English language of Scientific Latin (a type of Modern Latin). It's thus completely ordinary typesetting practice. The typographical quirk without underlying reason is the fact that [o]ther Latinate elements in the taxonomic hierarchy (e.g., family, order, class, etc.) are not [usually] italicized. There's not a lot of info about this available online but there is a scientific paper that claims this, at least: https://pmc.ncbi.nlm.nih.gov/articles/PMC7670697/ Dingolover6969 (talk) 19:31, 12 July 2026 (UTC)

Yes, I was only speaking in reference to Wikipedia MOS as that is what matters when it comes to formatting content. If and when the proposal suggested in the linked paper is more widely accepted, the convention may change. Although it is debatable whether scientific Latin is an actual language or some sort of technical syllabary. older ≠ wiser 19:42, 12 July 2026 (UTC)

Agreed. Dingolover6969 (talk) 19:52, 12 July 2026 (UTC)

Then again, Linnaeus seems to have set parts of taxonomical names in italics, and he was writing entirely in Latin, so who knows. Dingolover6969 (talk) 19:51, 12 July 2026 (UTC)

For future reference, User:Dingolover6969 and User:Bkonrad, can we conclude we are correctly choosing examples of "italics but not for language/accessibility reasons", that is, examples where |italics= is sufficient and |lt={{lang|}} thus unnecessary/unwanted? (This discussion appears to have ended without any clear conclusions) CapnZapp (talk) 15:48, 18 July 2026 (UTC)

Yep, this scientific Latin example seems great to me given the current MOS. Dingolover6969 (talk) 06:58, 27 July 2026 (UTC)

nonstandard wikidata link

I understand the sentiment this isn't strictly needed, but when I revert additions it feels helpful if I can point to the exact thing the editor did, as opposed to merely hoping they understand that doing it one way is the same as doing it the other. (Edit conflict) Cheers CapnZapp (talk) 16:30, 12 July 2026 (UTC)

Supposedly a comment directed at User:Primefac CapnZapp (talk) 16:30, 12 July 2026 (UTC) I will of course abide by any consensus. The addition was made out of a genuine wish to improve the documentation. CapnZapp (talk) 16:32, 12 July 2026 (UTC)

demo parameter?

As briefly touched upon in past discussions (now archived), is there an appetite for a |demo=yes parameter? This should only be used for documentation examples; never in "live" usage.

The issue is for us maintaining the documentation (note: examples of {{ill}} usage is not limited to Template:Interlanguage link/doc) - most (all?) of our examples showcase red links; so if a well-intentioned editor goes ahead and create those articles this will effectively break the documentation.

Normally the template's behavior to silently show a now-blue link as a regular (non-template) blue link (and later for the bot to remove the template call altogether) is desirable. For documentation purposes, not so much.

Would there be interest in creating a parameter for use by documentation examples, such as |demo=?

When set to |demo=yes if and when an article on the red-linked topic is created the template would not silently regress to a blue link as usual, but instead display an error message, perhaps Documentation needs updating, please ask at Template talk:Interlanguage link for assistance. (The bolded text is a link to here. This suggestion assumes this talk page will remain active. If y'all suspect it will not, perhaps a more centralized link destination would be preferable.)

This should greatly decrease the risk an example that no longer serves its purpose will remain undetected for any length of time.

CapnZapp (talk) 15:38, 18 July 2026 (UTC)

No. As was demonstrated by the now-archived posts (which were short enough they probably didn't need to be immediately archived) it is a trivial matter to either fix them directly or post here to get them updated. The /doc is the only page I can think of that has this sort of issue and adding in additional #if statements just for this page seems rather unnecessary. Primefac (talk) 15:43, 18 July 2026 (UTC)

Please note the presumption this page is alone in needing this is not correct. I could try hunting down all the pages with {{ill}} examples but I feel confident you are much better at regex searches etc than me. Also please note I fully agree fixing the examples are mostly very easy, but the point here isn't that we need help in fixing them, but help in detecting them. I certainly don't have full overview of every ill example, and this suggestion is based on the presumption it could easily be months before somebody identifies an example gone "wrong". Remember, just because you look at an example you do not necessarily understand the result is unintended, as evidenced by the earlier discussions. Btw, the reason I archived them is I wasn't proud either of my conduct, and felt everybody would benefit from getting them off the main talk. Cheers CapnZapp (talk) 15:54, 18 July 2026 (UTC)

I agree with Primefac that hacking the template for nicer documentation is not the way to go. Perhaps we can make the example page emit a warning if it is in Category:Interlanguage link template existing link? —Kusma (talk) 19:32, 18 July 2026 (UTC)

User:Kusma: Again, be aware there are more pages than our documentation page. Examples of ill (thus vulnerable to project improvements) can be found at Template:Lang's documentation, Help:Interlanguage links, Help:Interwiki linking, and probably others. Wikipedia:Manual of Style/Linking mentions this template but currently without giving examples. Wikipedia:Wikimedia sister projects does not mention interlanguage links but probably should. And so on. (Just saying that any solution needs to work at more places than here) Cheers CapnZapp (talk) 09:07, 19 July 2026 (UTC)

I just discovered Wikipedia:Red link/History of the example red link which is a curious little piece of historical information, which indicates that it is perfectly possible to have valid redlinks for ages without any issue. Wikipedia is a living document, and the /doc pages are no exception; I just had a different template /doc discussion where it hadn't been updated in six years and someone was asking why X rule wasn't being followed (it was enacted only three years ago). Occasionally fixing things is the whole point. But I think we now have said our respective pieces and I'll see what others think about the matter. Primefac (talk) 09:13, 19 July 2026 (UTC)

Thank you for that. I'm not trying to say this must be done or that failing to update our examples is a huge disaster. I am merely highlighting that ill examples are vulnerable to project improvements and will become incomprehensible very subtly. Thus the idea to have the software help making them stand out more. Unlike that particular high-profile example, ill examples are spread over several pages with, I presume, far fewer watchers monitoring the state of the examples, ready to step in whenever the red link goes blue. Cheers CapnZapp (talk) 09:50, 19 July 2026 (UTC)

An example could be contrived like {{ill|like this one|de|Büroklammer|lt=Chief staple puller}}: Chief staple puller. -- Michael Bednarek (talk) 01:08, 19 July 2026 (UTC)

I'm not a huge fan of faking links quite like that, but if people are seriously concerned about having to occasionally update the /doc then we might as well just use Red link example for every example and hope that people don't get too confused seeing variants of the same thing over and over throughout the page. Primefac (talk) 09:13, 19 July 2026 (UTC)

The idea here is to intentionally construct a red link that likely will stay red; i.e. a link less vulnerable to good-faith improvements of the project. While I don't think this is a particularly good idea as a general solution for this documentation-facing issue - I would much rather be told I have to update the documentation with a new example; I *have* used the idea for what is discussed at Template:Interlanguage link § Circular redirects: Helen Reef (atoll) is a new link that is intentionally red, because {{ill}} functionality works best when the link remains red. Cheers CapnZapp (talk) 09:58, 19 July 2026 (UTC)

Out of curiosity I ran a petscan, and after removing all archives, WikiProjects, talk pages, and sandboxes, came up with a couple dozen pages (which I haven't checked) that are in that cat.

• Help:Interlanguage links
• Template:Bologna–Ancona railway diagram
• Template:Brazilian criminal law
• Template:Campaignbox Qara Yusuf
• Template:Costeño (train)
• Template:Deputy Prime Ministers of South Korea
• Template:Diplomatic missions of Switzerland
• Template:Federal electoral districts of Puebla
• Template:France Télévisions
• Template:French criminal law
• Template:Further interlanguage link
• Template:Further interlanguage link/doc
• Template:Interlanguage link
• Template:Interlanguage link/doc
• Template:Officers of the Guangzhou Military Region
• Template:Reflib/French criminal law
• Template:Russo-Ukrainian war (2022–present)
• Template:Russo-Ukrainian war (2022–present)/doc
• Template:Talsi Municipality
• Wikipedia:Help desk
• Wikipedia:Red link
• Wikipedia:VIAF/errors
• Wikipedia talk:Red link

Without looking I'd say probably 3/4 of those are just using ill as intended, but I'll do that later on to get a better idea of where this template is being used as an example-that-needs-updating rather than just as a template (I'm guessing this isn't going to be the best method of finding these pages). Primefac (talk) 10:09, 19 July 2026 (UTC)

Thank you for adding Wikipedia:Red link to my earlier list. That appears to be the sole relevant addition. CapnZapp (talk) 10:52, 19 July 2026 (UTC)

Okay, so I thought about a way to use something like a |demo= param purely for tracking purposes: on this template (or any other location) where we specifically want to have our {{ill}} calls be redlinks, a |demo=yes parameter would put the page into e.g. Category:Pages calling interwiki link with intentional redlinks. There probably won't be many pages that meet this criteria, but it would allow us to occasionally run through the list and see if the red links provided by the template are still redlinks. If anything needs updating then that can happen. Additionally, if we try to use the same example(s) across all pages, if we find one redlink then the other pages will be known and can be updated as well. Does that seem like a reasonable solution that doesn't overly tax the system (i.e. by simply adding a tracking category and not forcing anything else)? Primefac (talk) 12:03, 19 July 2026 (UTC)

I'm not entirely sure what you envision here. Three possibilities:

1. The tracking category is populated by the ill calls that need attention, i.e. ill calls with |demo=yes where the link is detected to be blue. These would be the ill calls that no longer look like template calls, and these would be the ill calls that the bot would replace (unless we can get the bot maintainer to treat |demo= as |preserve= or if |demo= implements {{bots|deny=Cewbot}})
2. The opposite - every ill call with |demo=yes populates your tracking category except those where the link becomes blue - these are silently removed from the category. This is what your words say, at least as far as I can tell, but I am not 100% certain this is your intended meaning, simply because if you can achieve #2 you probably can achieve #1 as well, which seems so much more direct and natural.
3. Or merely all ill calls with |demo=yes

Personally I think #1 would be my choice. Perhaps simpler than either #2 or #3 might be to just create a pinned talk section where we list every relevant page, and tell future editors which pages to check on occasion. (I would add such a pinned talk section even if you add #1, as a simple reminder to check this tracking category, and what to do if a page appears in it)

Apologies if I appear to be rambling. As for your general question Does that seem like a reasonable solution I'm open to anything that might help us keep track of ill example usage and I thank you for your efforts. CapnZapp (talk) 15:10, 19 July 2026 (UTC)

Your concern is having "demonstration" uses of {ill} where we do care about maintaining a redlink (e.g. on this template's /doc). My proposal is to add a param to track those pages so that we can occasionally look through them and make sure the redlinks are still red. It would not check if they are still red, just tracking on which pages we want to always have redlinks. So basically your #3 option, but at that point I agree it's probably just easier to have a pinned list here. Primefac (talk) 15:57, 19 July 2026 (UTC)

Pinned talk section added awaiting programmatic support. Regards, CapnZapp (talk) 18:36, 19 July 2026 (UTC)

@CapnZapp, Primefac, and Kusma:, Sorry I'm late to the party, but there is an easy, low-tech solution that avoids a demo parameter, but requires some cleverness as well as a bit of consensus and some admin help, and it is this: find some red link examples that are unlikely ever to be turned blue, and create-protect them. We had one already for many years, namely, the example {{ill|jokery|...}}, but this got repurposed at some point into {{ill|joke|...}} in the doc, which is blue. The jokery example was very clever because it was unlikely ever to be needed as a wiki article or redirect and thus turn blue, but at the same time, jokery is not a made-up word. Furthermore, if you look at the history of jokery, you will see that this ill doc issue has come up before for this very word, and as a result, the term jokery was "anointed", so to speak, for precisely this role of remaining red at the doc page. So it's rather ironic that we had the solution in hand already, and then abandoned it.

I suggest that we return the jokery example to what it was before, as it will eternally remain red. In addition, we should add a hidden text message nearby to prevent the {{jokery|...}} example from being undone again. To the extent that we need more eternally red examples on the doc page, I suggest we follow the simpler route of finding more "clever" red terms and nominate them for creation protection as well for the purpose of this template's talk page. This is much easier than creating a demo param, imho, and for all I love templating and adding params when there is a real reader benefit, I am even more in favor of a low-tech, elegant solution when there is one. I think that this is one of those cases. We just need to reapply it. Mathglot (talk) 18:06, 8 September 2026 (UTC)

missed a ping: Michael Bednarek; sorry! Mathglot (talk) 18:08, 8 September 2026 (UTC)

Before reading Mathglot's post, a heads-up: the reminder note (pinned above) itself broke... Maybe what's needed here is a bot that actively checks a specified list of documentation pages and makes sure each link is in the desired state, or it posts about it here (so having this page on watchlist actually informs us something broke and needs repairing). As a parameter |demo= works I guess, though |demobot= would more clearly clue in the reader that a bot is involved. If this parameter has either of the values |demobot=blue or |demobot=red the bot checks it. In the usual case, the documentation would set |demobot=red and whenever one of our example links gets created we are alerted to the example needing replacing. In the specific case above, the documentation would set |demobot=blue and whenever a link we claim is blue gets removed/draftified we are alerted. The default, of course, would be |demobot=none so leaving it out entirely means the bot won't interfere. CapnZapp (talk) 18:24, 8 September 2026 (UTC)

As my comment, I honestly prefer us using real live examples (that can differ, and make sense in context), such as {{ill|Hooglede town hall|nl|Gemeentehuis van Hooglede}} → Hooglede town hall or {{ill|Grünbein (Argentine town)|es|Grünbein|lt=Grünbein}} → Grünbein. They appreciably aid understanding. I would prefer it if we could keep using them and just solve the maintenance issue. CapnZapp (talk) 18:31, 8 September 2026 (UTC)

is there a way to preserve an ill call from bot removal without visually preserving the foreign language links?

Over at Wikipedia:Red link § Red links and interlanguage links the documentation attempts to illustrate how an ill call looks when the linked article exists. I removed the |preserve=yes parameter because that defeats the purpose - with this, the ill call visibly remains an ill link, not a regular blue link.

Is there a way to achieve this while still telling the bot not to convert the ill call to a regular blue link?

Perhaps the bot is told to not operate in the Wikipedia namespace?

If the answer is "no", that example probably needs to be rethinked. Regards CapnZapp (talk) 11:02, 19 July 2026 (UTC)

We do that in the /doc here already; we say "Joke already exists so {{ill|Joke|de}} → Joke without the lang text". In the redlink example ("{{ill|Hanning Schröder|de}} links to the existing English page: Hanning Schröder.") it doesn't really matter if we're using {ill} or a bluelink because the output/bluelink is the point of the display (clearly we've just given the example of what the code looks like). If we want to refactor it to use the |_show_result= format like I did in this comment, though, that might make it slightly more clear that the code is directly giving the output, but I'm not entirely convinced that it's necessary (willing to be convinced otherwise). Primefac (talk) 12:08, 19 July 2026 (UTC)

You're probably right - even if the bot converts the example, the reader will still get it. But thanks for reminding me about the {{tlc}} construction. CapnZapp (talk) 14:48, 19 July 2026 (UTC)

{{bots|deny=Cewbot}}? —Kusma (talk) 14:56, 19 July 2026 (UTC)

That works too. Primefac (talk) 15:57, 19 July 2026 (UTC)

bot replacement

Moved to User talk:Kanashimi § bot replacement

Question moved to bot operator's talk page. Primefac (talk) 22:22, 4 August 2026 (UTC)

In citation templates

I know that this can't be used in citation templates because it messes up COINs data. Does that extend to manually replicating this template, e.g., I can put this ill to a publisher in the body but not in the citation template, {{Interlanguage link|Daigaku Syorin|ja|大学書林|italic=yes}}, and it generates Daigaku Syorin . But I can't put that in citation text. Could I do [[Daigaku Syorin]] <small>''[[[ja:大学書林|ja]]]''</small>, which generates Daigaku Syorin [ja] when placed in the template? And this is less desirable, since it would just take readers to a different language wiki without warning, but could I do [[ja:大学書林|Daigaku Syorin]] which generates Daigaku Syorin 1brianm7 (talk) 03:41, 15 August 2026 (UTC)

Either one would work. The third option is to just not link them since it's currently a redlink. Primefac (talk) 11:31, 15 August 2026 (UTC)

Honestly, I think we should stop caring about "messing up" CoinS metadata. As WP:COinS says, "Use of COinS outside of Wikipedia is fairly rare. Since some time between 2017 and 2025, the specification website is no longer live, and needs to be accessed through the Wayback Machine". We should do things that help users now, not prioritise some undermaintained standard. But that is probably a discussion to be had elsewhere. —Kusma (talk) 12:33, 15 August 2026 (UTC)

Interestingly, a discussion from a few months ago that proposed a way to make ill's work in citation templates was met with the response to depreciate COINS or to explicitly endorse polluting it to add ill's and whatnot. I'd suspect that proposing we stop care about messing it up would gain consensus if someone proposed it. 1brianm7 (talk) 02:11, 17 August 2026 (UTC)

@1brianm7: Regarding your original question, I know that this can't be used in citation templates because it messes up COINs data. Does that extend to manually replicating this template. The emission of COinS metadata is a feature of the citation templates themselves, so if you don't use the templates, it's perfectly OK since there won't be any COinS metadata to mess with. --Redrose64 🌹 (talk) 09:26, 16 August 2026 (UTC)

That's a good idea. I don't think I'm (ever going to be) ready to ditch citation templates for references, but my current situation is just a list of works. Is there a way to subst citation templates or would I have to manually replicate the output? 1brianm7 (talk) 09:39, 16 August 2026 (UTC)

The cite X family of templates cannot be subst. Primefac (talk) 10:48, 16 August 2026 (UTC)

Contradictory Wikidata example

While I was looking closer at the doc I noticed the "Altering link text" section includes an example which contradicts the advice to not link to Wikidata via {{ill}} in the main body, doing exactly that with its "David Cannon McConnel" case. That Wikidata link is also totally useless because it links to the section on Wikidata for other language versions but that section is completely empty. I don't know if that example ever was useful, but it certainly isn't now. According to the remark in the "Stylistic parameters" section, it was decided at an RfC that Wikidata should not be linked in main text, so I'm unsure why the link at Bulimba House still exists. The remark about the RfC should probably be moved to the main Wikidata section as I doubt someone would think to look for that info under the "Stylistic parameters" heading.

I've not made any changes yet as I'm not read up on the prior discussions regarding the use of the template with Wikidata, though I'm aware long discussions took place, and honestly I don't even really understand why anyone would ever want to use it to link Wikidata to begin with. {{ill}} links to Wikidata seems entirely irrelevant to the purpose of both {{ill}} and of Infoboxes where it would supposedly be appropriate to do this. I assume I'm missing something, so I'm not rushing into making changes here. – Scyrme (talk/solidarity) 18:11, 8 September 2026 (UTC)

If it helps I added the note about that RfC after it was pointed out to me in a talk discussion, but I didn't think to clean out old example usages. So thank you for finding this. Once linking to wikidata in mainspace was apparently deemed uncontroversial or even helpful - the documentation on wikidata links certainly suggest so, as well as the initial introduction of this functionality itself (and I maintain that merging the separate {{Interlanguage link Wikidata}} template into this already-huge template was a mistake) - and several editors spend time diligently linking to wikidata in running text (using both methods). CapnZapp (talk) 18:46, 8 September 2026 (UTC)

several editors spend time diligently linking to wikidata in running text - Still? Even after an RfC which established a consensus to not do this? Wikidata isn't an encyclopedia and should be not be linked as though it hosts articles intended for readers. Am I missing something? – Scyrme (talk/solidarity) 19:27, 8 September 2026 (UTC)

That link at Wikidata to the creator of Bulimba House, David Cannon McConnel, husband of Mary, is a) desirable as a red link because of the number of incoming links; b) for the information about his DoB/DoD, relatives, links to biographies and external databases. IAR. -- Michael Bednarek (talk) 02:33, 9 September 2026 (UTC)

There really aren't that many incoming link to David Cannon McConnel relative to many other red linked topics, so I don't see why McConnel is exceptional. The link to Wikidata skips past the personal info and external database links, linking instead to a bunch of empty boxes. Regardless, Wikipedia is an encyclopedia, not a repository for any and all information; just because information exists somewhere doesn't mean it should be linked. Wikidata is a machine-readable database organised using a formal ontology and its pages aren't intended for casual readers.

Consensus isn't a rule, it's the process by which the community makes decisions including about when/how to apply (or ignore) the rules; WP:IAR exists to prevent consensus-making from being restricted by lawyering not as an excuse to circumvent consensus. – Scyrme (talk/solidarity) 05:57, 9 September 2026 (UTC)

Scyrme, before somebody pointed that RfC out to me I had no idea (going back to the talk archives it seems I found it myself, but I have the distinct impression that was through a discussion with somebody). And before I included it in the help documentation, back in February I don't think it is fair to expect anyone else to know about it either. Hopefully the practice of linking to wd is petering out since then. CapnZapp (talk) 09:52, 9 September 2026 (UTC)