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)

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)

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)

Per this RfC, Wikidata links shouldn't be included in the body of an article. Nikkimaria (talk) 23:45, 31 March 2026 (UTC)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)\]

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)

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)

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)

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)

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)