Template talk:Interlanguage link/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

ill when content exists (better) on enwp?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cleanup template recommending the use of this needed

We need a cleanup template that could be used in cases were we have links in text to other language Wikipedias like here. _{Piotrus at Hanyang| reply here} 04:35, 10 June 2024 (UTC)

This might be reasonable, as the trend is definitely towards using {{ill}} over direct wikilinks (EGG etc), but it's not required so I'm not sure we should have a maintenance tag. At the moment there are about 114k pages that have direct interwikis, so that's another thing to consider. Primefac (talk) 14:07, 12 June 2024 (UTC)

Some of those are wiktionary/mediawiki links, though. I think the real question is whether there maybe should be a guideline on not using direct links to other language wikipedias. I think there is at least an argument that utilizing this template allows for consistent formatting and for metadata on usage to be gathered. I've done two AWB cleanups that ran into the 30k page range, but implementing this kind of change would probably be a good bot task both as an initial implementation as well as routine monitoring and cleanup. VanIsaac, GHTV ^cont_WpWS 19:24, 12 June 2024 (UTC)

@Vanisaac "there maybe should be a guideline on not using direct links to other language wikipedias" I thought there is, but I could not find it. At least, as in, I'd expect MoS to recommend ill template over simple links somewhere. If it is not, should have start a discussion or RfC somewhere on this? I'd expect it to be reasonably uncontroversial _{Piotrus at Hanyang| reply here} 04:21, 14 June 2024 (UTC)

it already says at H:FOREIGNLINK: "The best practice is to use the template {{interlanguage link}} …". -- Michael Bednarek (talk) 04:42, 14 June 2024 (UTC)

Since we've discussed this before, let's clarify to expressly state that all these nine options are feasible, which boils down to: both ill templates and direct interlanguage links are permitted. CapnZapp (talk) 13:31, 14 June 2024 (UTC)

Lots of things are permitted, but not best practice (ex. bare URLs). _{Piotrus at Hanyang| reply here} 02:51, 15 June 2024 (UTC)

Maybe you saw the notice at my talk page? Anyway, either something is permitted or it is not. There is no "shadow ban" on options here at Wikipedia - options that aren't outright discouraged/disallowed but where you still can reject them purely on procedural grounds. Either you have policy support for undoing an edit or you don't, and in this case policy permits all nine options. Regards CapnZapp (talk) 17:56, 15 June 2024 (UTC)

I don't see your point. Cleanup templates exist to direct editors to things that are better. We don't ban stubs, or many form of poor writemanship, but we have templates that tell editors they should try to do stuff better - de-orphan articles, add hyperlinks, format references, use infoboxes, whatever. _{Piotrus at Hanyang| reply here} 09:27, 17 June 2024 (UTC)

PS. And I have no idea what any talk page notice of yours has to do with this discussion. _{Piotrus at Hanyang| reply here} 09:28, 17 June 2024 (UTC)

The point was made by Primefac, edit dated 14:07, 12 June 2024. CapnZapp (talk) 20:49, 17 June 2024 (UTC)

Who said it is a reasonable idea, and was not opposed to it. _{Piotrus at Hanyang| reply here} 06:45, 18 June 2024 (UTC)

In any case, I am fine with your proposal below. _{Piotrus at Hanyang| reply here} 06:46, 18 June 2024 (UTC)

Let's make it a utility/convenience template and not formally a cleanup template. CapnZapp (talk) 18:12, 12 June 2024 (UTC)

When did the template stop requiring a version number?

It's been a couple of years since I used the template, but I swear it used to need a version number? Red Fiona (talk) 23:17, 2 August 2024 (UTC)

Version number? Primefac (talk) 11:07, 3 August 2024 (UTC)

Of the page you are linking to. Like French page for foo | 123456. Which I think was the old example. Red Fiona (talk) 13:47, 3 August 2024 (UTC)

Maybe you are thinking of Template:Translated page? -- Michael Bednarek (talk) 13:49, 3 August 2024 (UTC)

That would make sense. As far as I am aware {{ill}} has never had any sort of version number parameter. Primefac (talk) 18:48, 3 August 2024 (UTC)

Thank you, yes I was thinking about that. Sorry for any inconvenience. Red Fiona (talk) 12:19, 4 August 2024 (UTC)

No worries, glad we could get it sorted out! Primefac (talk) 12:24, 4 August 2024 (UTC)

Avoiding circular redirects

What do we do when the article on enwiki is a redirect to the article that template:ill is being called on (and redirecting to the article itself, not a section) In that case the blue link is a circular redirect with seemingly no way to get rid of it. RachelTensions (talk) 02:21, 21 October 2024 (UTC)

Edit the article? (Meaning that I think that better than to spend the resources to code this template to account for every weird corner case, we instead simply leave it up to editors to remove/fix such instances. You don't have to link to what you're displaying, after all. To further the discussion please provide an example, thanks) CapnZapp (talk) 14:30, 23 October 2024 (UTC)

"Edit the article?" is unhelpful - obviously I'm trying to edit the article to come up with a solution.

Nelly Furtado previously had a blind, WP:ASTONISHING interlanguage link in the lead to pt:Nelstar... I'm trying to fix it so it's clear that it's an interlanguage link but when I use {{ill}} it results in a circular blue link because Nelstar Entertainment on enwiki redirects back to Nelly Furtado.

Right now I've removed both versions of the link, to avoid either a blind interlanguage link to Portuguese wiki, or a circular redirect with the {{ill}} template.

I find it hard to believe this is an obscure fringe case; one would think that there are a lot of articles that may exist in other languages that only exist on enwiki as a redirect to a broader parent article. RachelTensions (talk) 14:42, 23 October 2024 (UTC)

Thanks for providing an example. You added "{{ill|Nelstar|lt=Nelstar Entertainment|pt}}" in a recent revision of the Nelly Furtado page. Do I understand you correctly in that the pt link is correct, but you dislike how the English link gets blue (because Nelstar is a redirect back to the article)? I had a hunch this had been discussed previously. First off, could you please read Template_talk:Interlanguage_link/Archive_3#Forcing_redlink_on_redirect_pages if you haven't already? (I'm not trying to derail you; only making an attempt at not rehashing already discussed issues) CapnZapp (talk) 15:32, 23 October 2024 (UTC)

Nelstar Entertainment and Nelstar both result in a circular redirect regardless of which one is used.

So it seems like the changes to allow suppression of link were made in sandbox but not moved to production; I'll just manually link it with the small brackets for now and avoid use of this template. RachelTensions (talk) 15:38, 23 October 2024 (UTC)

Update: The manual option suggested there ({{small|{{bracket|[[pt:Nelstar|pt]]}}}}) seems to just result in empty brackets for whatever reason so I'm not sure what the manual alternative is or what I'm messing up RachelTensions (talk) 15:46, 23 October 2024 (UTC)

[pt] But it seems to work here, but not in the article space... I'm confused to say the least. RachelTensions (talk) 15:47, 23 October 2024 (UTC)

I fixed a small error over at Nelly's page, User:RachelTensions (Note the extra colon) CapnZapp (talk) 15:58, 23 October 2024 (UTC)

oh duh, thank you RachelTensions (talk) 15:59, 23 October 2024 (UTC)

(edit conflict) I guess I should expand upon this: As you hopefully agree after reading that archived talk, having ill automatically detect this is hard. Easier is to investigate if Nelstar or Nelstar Entertainment is a seldomly used redirect and have it deleted (so ill once more displays a red English-language link). Or possibly, hacking the ill to use a third definitely-showing-as-red article target (that still editors can understand should lead to an eventual Nelstar article): something like Nelstar Entertainment. Note how I just made up Nelstar (company) in the hopes it will remain red until article creation (as opposed to some good-faith editor adding yet another redirect back to Nelly Furtado). I guess you could propose adding a parameter to the template that basically says "yes, the link exists but please pretend it doesn't if it's only a redirect... that redirects back to here" but I honestly think it's asking too much for a template that's already resource intensive... (but I'm not the expert) Cheers CapnZapp (talk) 15:44, 23 October 2024 (UTC)

I'll just manually link it with the small brackets for now and avoid use of this template One solution would, of course, be for you to actually create the Nelstar article. Maybe the pt version is good enough at least for a stub? CapnZapp (talk) 15:47, 23 October 2024 (UTC)

Vanity labels for one artist rarely meet WP:COMPANY and I doubt this one is any different, unless there are some plans to expand the label beyond just her (two?) albums. RachelTensions (talk) 15:50, 23 October 2024 (UTC)

Oh absolutely. I didn't check whether Nelstar perhaps was an article once, but was later folded into the main Nelly page. CapnZapp (talk) 16:00, 23 October 2024 (UTC)

Circular redirects and our documentation

I took a stab at alleviating this (apparently) recurring frustration by editing our documentation:

Template:Interlanguage_link/doc(edit talk links history)

Take a look and feel free to improve further. CapnZapp (talk) 16:26, 23 October 2024 (UTC)

Script request

See Wikipedia:User_scripts/Requests#Interlanguage_links_converted_from_common_bad_styles _{Piotrus at Hanyang| reply here} 00:54, 26 December 2024 (UTC)

possessive apostrophe s ("'s")

Not really an important problem, but:

It is common practice in Wikipedia not to include the possesive apostrophe s in the link, e.g., "[[Winston Churchill]]'s politics", not "[[Winston Churchill|Winston Churchill's]] politics", so the link appears blue and the "'s" black: "Winston Churchill's politics". However, when applied to an interlanguage link, "{{ill|Gregor Gog|de}}'s paintings" looks ugly: "Gregor Gog's paintings" – and in "{{ill|Gregor Gog|lt=Gregor Gog's|de}}" the "'s" appears blue, too: "Gregor Gog's paintings".

Any ideas about that?

--Cyfal (talk) 13:52, 15 February 2025 (UTC)

Either include the 's in the link as in your second example, or don't use the possessive. If it's an issue that regularly occurs and the non-possessive version won't cut it, I suppose I could sandbox some form of |ps= postscript parameter to put text between the link and the interlanguages. Primefac (talk) 13:55, 15 February 2025 (UTC)

Or be amazing and solve your problem by writing the red-linked article. – Jonesey95 (talk) 00:01, 16 February 2025 (UTC)

By far the easiest solution is to rephrase into "the paintings of Gregor Gog." I've edited the Asso page. Cheers CapnZapp (talk) 09:49, 9 March 2025 (UTC)

Thank you, indeed easy! --Cyfal (talk) 10:01, 9 March 2025 (UTC)

Extra spaces in parameter values are not stripped properly

I just added a test case that shows extra spaces in parameter values not being stripped properly, leading to undesirable display issues like "Foo bar [ de ]" instead of "Foo bar [de]". I don't have time to work on it right now, but if someone wants to fix it, it might be a fun task. – Jonesey95 (talk) 05:20, 25 February 2025 (UTC)

Ironically, I just came to this talk page after noticing the same thing, specifically the fact this template produces "NAME ^[LINK]" instead of "NAME^[LINK]". This needs to be resolved, but I don't have any time to figure it out at the moment either. Steel1943 (talk) 23:49, 8 March 2025 (UTC)

​ That's... an entirely different concern. Primefac (talk) 17:33, 9 March 2025 (UTC)

Thanks ... I guess? Is one worse and/or more controversial of a fix than the other? I mean, per the current state of Template:Interlanguage link/doc#Vertical alignment, it occurs, but probably shouldn't. Steel1943 (talk) 18:24, 9 March 2025 (UTC)

Generally it's a good idea to keep separate ideas in separate threads; an issue with white space in parameters is a different issue to white space in the template output, so if I were to mark this section as {{resolved}} because the parameter issue has been fixed, there's still the output spacing issue which might not yet have been addressed. It's not the end of the world, just probably not the best place to start a new discussion on an only-somewhat related question. Primefac (talk) 19:59, 9 March 2025 (UTC)

White spaces in output

Just to make sure I understand the issue, though, is the concern that there is white space before the interlanguage link when |valign=sup? Personally I'm not thrilled with having a sup option anyway, but I suppose we should sort out the issues with the template as it currently stands. To make up a completely arbitrary pair of examples:

• {{ill|This page does not exist either|fr}} → This page does not exist either is the default output
• {{tlc|ill|This page does not exist either|fr|valign{{=}}sup|_show_result=yes}} is the output when using a valign

I take it you would prefer to see the second example as This page does not exist either^[fr] without the space? Primefac (talk) 19:59, 9 March 2025 (UTC)

Standard parameter name for Wikidata IDs

At Wikipedia:Village pump (technical)#Standard parameter name for Wikidata IDs, I propose that we standardise on the most-used property name for Wikidata identifiers, |qid=, instead of |WD=, keeping the old name as a working alias, at least for the foreseeable future. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:42, 26 November 2024 (UTC)

Support. -- Michael Bednarek (talk) 01:05, 27 November 2024 (UTC)

Support, assuming that WD is kept as an alias for a long time, say five years. Would suggest adding 'q' as an additional alias. Mathglot (talk) 04:13, 27 November 2024 (UTC)

Just noting I have set up a tracking category to see how large of a task this would be to change existing param use. Primefac (talk) 16:59, 27 November 2024 (UTC)

Please respond at the original discussion, per WP:TALKFORK. – Jonesey95 (talk) 19:07, 28 November 2024 (UTC)

@Pigsonthewing: Would you post the archival link for the Village pump (technical) discussion? I just cannot seem to find it. Not that I mind switching from wd to qid going forward as I am already used to it on Commons, but I would like to see the discussion. Peaceray (talk) 18:42, 10 March 2025 (UTC)

Wikipedia:Village pump (technical)/Archive 216 § h-Standard parameter name for Wikidata IDs-20241126154400. It was about as well-attended as this discussion, but SILENCE is as good a motivator as any. Primefac (talk) 19:03, 10 March 2025 (UTC)

Can this now be enacted? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:28, 10 March 2025 (UTC)

Sure. Primefac (talk) 12:56, 10 March 2025 (UTC)

Circular redirects

They sure are annoying. I mean, I realize they're well-intentioned, but it really works against the editor trying to set up ill links when you must go through hoops to render the foreign-language link in the expected manner, link to something that looks like the English article while still keeping the link red (to make it clear clicking it won't do you any good: since it's a redirect back to the article, or a "circular" redirect from the perspective of the article anyway).

Previous talk discussions:

• Template_talk:Interlanguage_link/Archive_3#Styling_circular_redirects
• Template_talk:Interlanguage_link/Archive_5#Proposal:_allow_red_links_for_circular_redirects_with_possibilities
• Template_talk:Interlanguage_link/Archive_6#Avoiding_circular_redirects

I feel one intuitive but-maybe-not-ideal solution isn't covered by our documentation: setting up a "false" link that's deliberately kept red as a kind of quick-fix replacement for actually deleting the redirect. Because deleting the redirect isn't the solution - it's worse than useless from the perspective of the article in question (and the editor trying to set up the ill), but it does provide a search target from Wiki as a whole (even if Google seldom picks up on this).

Assume we're on the Painter's Collective article where painter Janie Smith was active. A well-meaning editor creates the Janie Smith page as a redirect to the Painter's Collective article.

Now if we want to use ill to indicate there's a French-language article on Janie Smith, we can't just say {{ill|Janie Smith|fr}} because the existing redirect prevents the ill link from being red (with the [fr] link correctly being blue). One intuitive option is then to change the ill to: {{ill|Janie Smith (painter)|fr}} which now breaks the French-language link and so further to {{ill|Janie Smith (painter)|lt=Janie Smith|fr|Janie Smith}} to both correctly link to the French wikipedia and give the impression we're still using the Janie Smith link, only it is intentionally red, as it should be (to signal to the reader the futility of clicking it).

Should we recommend this? CapnZapp (talk) 10:26, 9 March 2025 (UTC)

It's a kludge that would fix the appearances on a case-by-case basis, but requires follow-up when someone actually converts the original Janie Smith redirect into an article (that editor may be unaware of the ILLs using the Janie Smith (painter) formulation. And to extend the hypothetical, suppose Janie Smith worked in multiple media, and other editors might create ILLs using other parentheticals such as Janie Smith (sculptor) or Janie Smith (potter) or simply Janie Smith (artist). older ≠ wiser 12:52, 9 March 2025 (UTC)

Thank you for replying, and I do realize it isn't perfect, but I'm not sure this is any less desirable than the workarounds we do recommend (Template:Interlanguage link/doc#Circular redirects)? To me, your description would apply to them as well... and in some cases are less intuitive or easy to implement. Thanks, CapnZapp (talk) 09:52, 11 March 2025 (UTC)

Not quite. I'm no fan of the current recommendation, but that essentially results in a peculiarly formatted hard-coded link to the foreign language article. The current guidance says nothing about replacing the circular redirect with a nonce redlink that might remain an unassociated redlink after creation of an article at the title where it would more typically be expected. Some comparable maintenance would be required to remove the hard-coded link, unlike with how ILL link would more gracefully detect the newly existing article and not display the foreign language link. The presence of both a hard-coded link and a link to EN article seems somewhat less of an issue than creating a nonce redlink. older ≠ wiser 11:12, 11 March 2025 (UTC)

One solution I've always thought is that redirects with {{R with possibilities}} should always display pink by default on-wiki. That way those redirects would still work but editors and scripts would know not to remove the {{ill}} until the actual article is created. --Habst (talk) 18:52, 10 March 2025 (UTC)

This is a little bit more general problem, in that it can also occur when interlanguage links aren't involved. In particular, a local redirect (perhaps involving an anchor link) may wind up going back to the current page, with the "unexpected" behavior that it doesn't take you to a new page, with a result that is likely to be quite confusing to the user.

As long as we're not letting it just use what's in Wikidata rather than relying on having the list of available language in the wikitext, then I would advocate just to document the use cases, e.g. if there is an existing article with the same name but it's really a different topic, then just add an arbitrary qualifier, and use the "lt=" parameter to indicate the name to be displayed. OTOH, in the case of a local link that happens to be a redirect to a section or to an anchor link, then just "short circuit" the redirect. I understand the objection to this approach (e.g. we can't pick up changes to a redirect), but these are just examples of limitations of how things work. Fabrickator (talk) 21:24, 11 March 2025 (UTC)

Just to be clear, are you still discussing improvements to Template:Interlanguage link/doc#Circular redirects or something else? Thanks CapnZapp (talk) 16:49, 12 March 2025 (UTC)

I'm definitely talking about a "circular link" problem which occurs with {{ill}}, but the underlying problem applies to more than just interlanguage links. There's a rather more obscure instance of this issue on Soundgarden, which has links to [[Scott Sundquist]] (which redirects back to Soundgarden#Members ... I have used {{ill}} to override this to redirect to simple:Scott Sundquist, which provides a better experience for the user. That is the exceptional case, usually I'm simply dealing with an {{ill}} where it's necessary to use it in a "hacky" way to get the desired result. Fabrickator (talk) 19:24, 12 March 2025 (UTC)

Apologies if I misunderstand you, but I will take that as a "no," or rather, you're only tangentially touching the "hacky" ways to get around circular redirects, and more pertinently, documenting our recommended ways to accomplish that. As for the "underlying problem," I'm not sure this talk section is a productive venue for that discussion. Again, I could be wrong. Best regards, CapnZapp (talk) 21:10, 12 March 2025 (UTC)

Here's an example borne out of Fabrickator's issue that showcases what I'm proposing and why I think it is an improvement. It links to Simple Wikipedia for reasons not relevant to using this as an example; the idea is the same whether we link to French Wikipedia or any other.

If we are at the Soundgarden article, we realize linking to Scott Sundquist just creates a circular redirect. The current documentation suggests you manually construct your link to Simple Wikipedia, as in:

blah blah Scott Sundquist [simple] blah blah

using Scott Sundquist {{small|{{bracket|[[:simple:Scott Sundquist|simple]]}}}}

There is no attempt to create the appearance of a link to Sundquist. If Scott Sundquist is expanded from redirect into an article, us editors need to manually intervene.

The alternate approach I'm discussing would create an intentionally red link to be able to keep using {{ill}}:

blah blah Scott Sundquist blah blah

using {{ill|Scott Sundquist (Soundgarden drummer)|lt=Scott Sundquist|simple|Scott Sundquist}}

There is a link to Sundquist, and it is red as desired. If Scott Sundquist is expanded from redirect into an article, us editors need to manually intervene.

The primary concerns must be what we present to the reader. Any technical behind-the-scenes maintenance issues surely are secondary to this. In both cases, manual intervention is required. The amount of work needed to fix the link might differ slightly, but that feels like a very minor difference. I propose we add to our documentation the option to take this second approach. CapnZapp (talk) 12:49, 13 March 2025 (UTC)

A reader might object, arguing "what if an editor creates a redirect back to the article in good faith?" It is unlikely this would happen any other way than clicking through the link and failing to realize the presence of an {{ill}} template and a circular redirect problem. And even then, is this really more or less of a problem than the same well-intentioned editor "helpfully" adding brackets to the first example, turning Scott Sundquist into a linked Scott Sundquist, which then would astonish readers if used? To me, it would be unreasonable to only accept fool-proof solutions, and it's not as if the current recommendation is exactly more fool-proof than the proposed one. CapnZapp (talk) 12:57, 13 March 2025 (UTC)

I'm OK with adding this as an alternative approach. I'm not convinced there is any significant advantage or disadvantage to either approach. Some editors have something bordering on red-link phobia and either remove the redlinks or turn them into marginally (often barely) helpful redirects. Perhaps the real emphasis should be to re-iterate the value of redlinks (and ILLs) as marking potential articles. older ≠ wiser 13:48, 13 March 2025 (UTC)

Misleading tooltip; logo

If I create a link like

{{ill|William Richard Hughes|qid=Q117194259|lt=William R. Hughes}}

William R. Hughes

there is a tooltip on the Wikidata link saying "William Richard Hughes in other languages".

However, in this case there are no articles in other languages, simply a link to the Wikidata item (with links to useful external sources); which in turn links to Wikisource, in English. Can the tooltip be modified? "...in other Wikimedia projects" might do. Or if there is a |qid= value, we could say "Data about..."

In all cases, should the tooltip not use the |lt= value, instead of that of the first parameter??

It would also be good to have an option to replace the word "Wikidata" with a tiny, inline Wikidata logo, like those used elsewhere. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 15 March 2025 (UTC)

You can use |s=1 to shorten Wikidata to a d. I agree that the tooltip should be improved. —Kusma (talk) 19:48, 15 March 2025 (UTC)

But using the |lt= parameter can mean not using a helpful disambiguator in the tooltip, so I am not sure this is the way to go. —Kusma (talk) 21:03, 15 March 2025 (UTC)

What about the objection at User talk:Winged Blades of Godric § June 2018 RfC on Wikidata links, in which User:Fram stated

No: there is consensus that Wikidata links are not allowed in text, and there is no consensus to make an exception for interlanguage links.

Please clarify whether the stated prohibition is or is not in effect. If it is not in effect, then I would suggest (nearly) always using the wd=/qid= parameter ... generally speaking, it's not for me to dictate which language version will serve them best, and this also doesn't become outdated as the list of available languages changes. Fabrickator (talk) 21:06, 15 March 2025 (UTC)

I doubt readers would understand "d. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:01, 15 March 2025 (UTC)

@Pigsonthewing: I think a "d" is just as incomprehensible as a Wikidata logo to most readers. Anyway, to answer @Fabrickator's question: I am not aware of any formal re-evaluation of the consensus that there should be no links to Wikidata at least in the body of articles, but I do not think it is enforced very much. Personally, I prefer links to Wikipedias (if available) to Wikidata links, because I'd rather read an encyclopaedia article in a language I understand only moderately well than a database entry. —Kusma (talk) 07:22, 16 March 2025 (UTC)

@Kusma: It seems that your primary objection to the example wikidata link is that the article was not available in any language. This situation violates my expectations. If there's no available interlanguage link, we shouldn't be displaying a link that suggests that an interlanguage link exists. Of course, the situation can change ... maybe when it was coded, there was an interlanguage link that was subsequently discarded, or perhaps somebody created the Wikidata link speculatively. Ideally, the wikidata link would be displayed only if an interlanguage link actually exists.

Your other objection seems to be that you don't care for the formatting of the interlanguage links (as such) when using the Wikidata link. I will point out that some of the other language Wikis have customized the display (with some variation in how they've customized it), so that you're not taken to the page as displayed on the Wikidata site. Fabrickator (talk) 03:22, 17 March 2025 (UTC)

It is possible to retrieve a single wikidata link given the qid and lang code, and I believe it is possible to retrieve a list of all links given the qid. If that pans out, then we could suppress the wikidata link in the template by testing if 'en' is the only link in the set. Mathglot (talk) 08:49, 17 March 2025 (UTC)

That would be most unhelpful. When an editor comes to write an article about William Richard Hughes (to use the example already given), then the data in Wikidata and the material at Wikisource will both be useful resources to them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:13, 17 March 2025 (UTC)

If it is useful, then it should be linked in the article, either inline or floating it with {{wikisource}}. Mathglot (talk) 09:26, 17 March 2025 (UTC)

There is no case for doing so in an article which links to William Richard Hughes, but is not about him. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:34, 17 March 2025 (UTC)

It sounds like you are saying that even if English is the only Wikipedia that has an article on the topic, we should still display the Wikidata link anyway, as long as Wikisource (or any Wikimedia project) has it, is that right? If that is what you are advocating, then it does not belong here: this is Template talk:Interlanguage link not Template talk:Interproject link. If English is the only Wikipedia language project that has the topic, then there should be no Wikidata link and no {{ill}} template, as there is no other language to link to, and is just a frustrating time-waster for readers hoping to find something in another language. Mathglot (talk) 20:57, 17 March 2025 (UTC)

No, that is not what I said. I personally don't mind Wikidata links if that is the best information we have, but I prefer links to the Serbian Wikipedia to links to Wikidata. I do not read Serbian. If we use inline {{ill}}, we should only link to the best two or three articles and not link to Wikidata at all. Any reader will be served an encyclopaedia article that they can autotranslate in their browser; anyone wanting to write an article should be able to find the wikidata item from the Serbian or other Wikipedia if they expect it will help them. —Kusma (talk) 18:09, 17 March 2025 (UTC)

Fwiw, that is basically my preference as well. Mathglot (talk) 18:41, 17 March 2025 (UTC)

My opinion that wikidata is too long & that d is incomprehensibly short. While I prefer the latter to the former as it looks better, it would be useful to have something like data, just like we can use species in this template instead of wikispecies. Peaceray (talk) 06:12, 17 March 2025 (UTC)

A further thought: there is no assigned value for qid at ISO_639:q, so that is up for grabs. Also, there is no wd assigned at List of ISO 639 language codes#Table of all possible two-letter codes, but I would understand if we wanted to stay away from that value. Peaceray (talk) 06:21, 17 March 2025 (UTC)

While we try to refine small details attendant to the use of param |qid= and agonize over what identifier to use, what if we step back a second, start at the top again, and ask who actually uses this feature, and who benefits? My sense of the terrain is that few editors really understand and use the {{ill}} template, even fewer understand wikidata or what it is about, and the ones that understand both well enough to want to use the |qid= param is a sliver, being < 2% of all {{ill}} transclusions. So who exactly is all this for, and how much discussion is it worth to decide what form the link should take? To return to the question at hand: everybody in this discussion is entirely atypical, being in that small sliver, and I'm pretty sure just a d is good enough for everyone here. Who, exactly, gets helped by a longer identifier? Do we want to also add a little circle-i icon, linking to a help page explaining what wikidata is? (I think not.) If we are going to have this feature in {{ill}} at all, we might as well cater to the audience that uses it and understands it: the experts. Call it whatever you want, for as short as you want. Use a Greek lower case delta δ—or whatever you want. We'll read the doc once, and remember it the next time. Hardly any of the remaining 99.9% of active editors will notice nor care how it gets decided. Not trying to be ornery, just realistic. Mathglot (talk) 09:18, 17 March 2025 (UTC)

"d" is not good enough for me, as I already indicated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:36, 17 March 2025 (UTC)

I really disagree with the notion that Wikidata can be helpful to the average reader. Please pretty please accept that only technical folks gain anything useful out of a Wikidata link, and please confine such links in mainspace articles to the absolute minimum (ideally 0 links across the whole of Wikipedia). I wished the idea to code ill to accept wikidata links never occurred. From my perspective, we should not spend time friendlifying this unfortunate ability of our template - that can only normalize the habit of linking to wikidata, and we should definitely keep that to specialized usage only. I have therefore zero opinion on what letter or symbol to use. Regards, CapnZapp (talk) 17:45, 17 March 2025 (UTC)

@Kusma: So please clarify whether you're objecting to the way that {{ill}} displays links, the fact that there is a link to content on a different-language wiki, or something else? I'll point out that our article layout (perhaps depending on your skin) already includes a list of non-English versions for whatever article you're looking at. FWIW, the display of any given article already has lots of "marginal" content, much of which is probably ignored by a large majority of Wikipedia users. Anyway, once I understand what it is you find objectionable about {{ill}}, then I can respond appropriately. Fabrickator (talk) 19:29, 17 March 2025 (UTC) (whoops, this was intended to be directed to @CapnZapp:) ... Fabrickator (talk) 19:45, 17 March 2025 (UTC)

I love {{ill}} and use it all the time (just not to link to Wikidata). You seem to be misunderstanding me somehow. —Kusma (talk) 19:36, 17 March 2025 (UTC)

[ec] No, I don't accept that at all. But if the Wikidata interface is a concern, the answer is instead to link to the equivalent on Reasonator or Scholia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:16, 17 March 2025 (UTC)

Andy, I am not seeing a groundswell of support for your idea (but maybe we just need to wait a bit for more responses?). That said, maybe there is an easier way to get what you want without needing discussion, or altering the way the template works for everybody, namely, a WP:User script. There is an even easier way, if we are talking about just altering the d/wd/wikidata link, namely, put a class on it and then you make a change to your common.css to name it as you wish. I can make that change for you in a few minutes (I expect you could, too) and I doubt there would be any opposition to it, as it would affect only you and no one else. Would that work for you? (edit conflict) Mathglot (talk) 19:31, 17 March 2025 (UTC)

Andy, this is now updated in the sandbox, and testcases 1.19 → 1.22 now show '[myWD]' instead of '[Wikidata]' for me. (Have only briefly browsed unrelated test cases on that long test case page, but they should all be fine.) Mathglot (talk) 20:00, 17 March 2025 (UTC)

Thank you, but no; neither a user script nor local CSS hack meet my needs. I came here with two suggestions; the principle one of which was to avoid presenting our readers with the misleading "in other languages" tooltip (Wikisource, for example, is not "another language"). The very first comemnt below my initial post says "I agree that the tooltip should be improved."

My secondary suggestion was for an option to present readers with an icon which would take up less space than the current "Wikidata" link. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:31, 17 March 2025 (UTC)

It's still not clear to me who you are advocating for, as you mention "my needs" in the first sentence, but then switch to "our readers" in the second one. If you are saying that your proposal would be better generally for our readers, then I disagree for reasons stated previously, and I don't think you are anywhere close to getting consensus for it. If you are talking about your needs, then a partial solution is already sandboxed and tested (and you can have an icon instead of, or in addition to custom text, if you prefer). As far as the "misleading" tooltip, Jonesy already changed that (although truly, I think verrry few of our readers will notice) but if that was your principal concern, then are we done now? (edit conflict) Mathglot (talk) 20:43, 17 March 2025 (UTC)

No. Not least because the tooltip still refers to "other languages". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:17, 17 March 2025 (UTC)

As far as I can see, no actual change in language for the tooltip was settled on, so I tried to clarify. Since the original discussion thread has forked within this section to talk about multiple topics, perhaps a new thread or sub-thread can come to a consensus about what the tooltip text should say. I'm happy to implement any reasonable consensus. – Jonesey95 (talk) 21:59, 17 March 2025 (UTC)

Just to make clear my own preference, because so far I have been mostly trying to come up with possible solutions for you, I am opposed to changing the tooltip, and it should continue to say "other languages" (or words to that effect) because that is what this template {{Interlanguage link}} is about. To the extent that some readers understand what this template does at all, they get that it links to other language Wikipedias, and that's about it.

It seems to me the underlying locus of the problem we are discussing here is the merger from Template:Interlanguage link WikidataTemplate:Interlanguage link Wikidata, which perhaps overloaded too much functionality into one template, and now there is no good solution to your issue anymore, because you simply can't come up with links and tooltips that work in every situation for what are essentially different functions, so we are all barking at each other here unnecessarily. Perhaps the merge was a mistake, as it seems to have created a disputatious environment for little gain (other than the admittedly programmer-pleasing reduction of multiple templates into one) and maybe they should be separated out again, and then this will all go away. Afaic, you can have the ILL-Wikidata template say something different—and I am content to give you a blank check and to have it say whatever you want, as long as this one stays the same for its original purpose of displaying language links. Adding @Tamzin and Jc86035:. Given all the discussion and apparently fruitless effort here so far, I don't see a solution on the horizon that will please everybody in one template. Mathglot (talk) 22:28, 17 March 2025 (UTC)

Perhaps you can tell us in which situation "William Richard Hughes in other Wikimedia projects" does not work, and how "William Richard Hughes in other languages", which demonstrably does not work in every situation, is somehow better? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:46, 17 March 2025 (UTC)

Works great for experts; confuses everybody else. Take a poll of a thousand readers and ask them what "other Wikimedia projects" means, and get back to me. To the extent that you get anything other than blank stares, you might get a bare few, "Uhhh, you mean, um, like WikiProject Military history?" I think that you are trying to please thee and me too much, and are forgetting who the vast majority of our readers are. Mathglot (talk) 22:58, 17 March 2025 (UTC)

I use {{ill}} extensively, probably averaging a several times a day, & commonly link to Wikidata when no other project has an article.

I use Wikidata as a staging area for biographies & films that either do not yet warrant an article or for which I do not have time to create it. I use the Wikidata item to add references for properties & to add linked data identifiers. I think that is useful to both editors looking for links to help establish notability & to readers looking for more information. I will also point out that sometimes there are links to other projects, such as Commons categories, & that it is useful to go transverse Wikipedia→Wikidata→Commons for someone or something that has no article yet has a Commons category. Furthermore, I think it is useful to educate our readers that there are other projects in the Wikisphere other than Wikipedia.

Regarding the |qid= parameter being < 2% of all {{ill}} transclusions, I would be curious to see an actual count for all languages & projects. Peaceray (talk) 22:36, 17 March 2025 (UTC)

This is consistent with my understanding which is that the current guidance for using {{ill}} on enwiki is just to list each language which is to be linked. The obvious disadvantage of this is that it doesn't reflect any languages that get added.

Certainly there are some cases where this guidance is not adhered to, which is consistent with your "2%" statistic. As far as I am aware, this is the only language wiki that operates under this guidance, and assuming that's the case, it's dubious as to why we're even having a discussion of the best way to use this parameter that we're supposed to be avoiding. Fabrickator (talk) 22:54, 17 March 2025 (UTC)

Listing languages to be linked involves a human choice/judgment call about which ones have useful info (longer, better, different, more reliable, etc.) in the mind of the person who placed it—somewhat analogous to how placing ordinary wikilinks into an article is a human choice. Placing a wikidata link admittedly gets you a list of all of them (still one click away from an article), but they are not human-curated. Are you happy when it takes you to a list of 15 links, or 37, or 152? What do you do then? (Or for that matter, to a list of stubs all translated from en-wiki.) I'd rather have Kusma's chosen link set any day, including the Serbian link—which I don't understand either—but if he included it, that is one more reason that it might be worth grabbing and passing it through Google translate. (Something else we could automate, if we wanted.) I much prefer a handful of human-curated links, at the cost of maybe missing a great new article in Catalan, say, but then, once I am at the Dutch article, there it is, all shiny and linked in my sidebar. Mathglot (talk) 23:13, 17 March 2025 (UTC)

I typically do not link to Wikidata when there is a valid article in another language Wikipedia. The sole exception would be when that language Wikipedia is essentially only pulling its information from Wikidata.

I also do curate language links. If there several links, there are some that are bound to be better than others. My criteria as a non-speaker is a combination of the length of the article, the number of citations, the appearance of the article, & whether the article is marked as being generated rather than being created by a human.

BTW, we do not seem to be limited to just other languages (& Wikidata). I have linked to Wikispecies as well. Peaceray (talk) 00:01, 18 March 2025 (UTC)

I strongly believe each and every language featured in an ill link should be hand-picked and curated by a human editor. I strongly think what some other Wikis do (have the template list every other language) is a mistake. That the list of languages don't grow automatically simply because another Wiki adds the subject (and WikiData connects data points) is a good thing. Ill links aren't meant to say "this link exists", they're meant to say "in my capacity as an Wikipedia editor I've selected this truly useful article in Swahili for you while we await an English-language article". I would think easily 80% of other-language articles are trash and should not be linked just because they exist. And no, that's not something we should let readers decide for themselves. This is an encyclopedia, not a catalog. Regards, CapnZapp (talk) 01:09, 18 March 2025 (UTC)

Peaceray, likewise. As far as WikiSpecies, that ain't the half of it; example:

• Community roles

But let's not encourage that. Regards, Mathglot (talk) 01:23, 18 March 2025 (UTC)

I would advocate limiting it to the List of Wikipedias#Active editions & those at Help:Interwiki linking, minus the international chapters. I do not think we should be applying {{ill}} to everything at meta:Interwiki map.

Perhaps we should be splitting the functionality into two templates/modules:

• Template:Interlanguage link
• Template:Interproject link

I do think that there are valid reasons for linking from a non-existent articles to other projects, specifically Wikidata & Wikispecies. Peaceray (talk) 06:02, 18 March 2025 (UTC)

Couldn't agree more. Regarding split, it was originally two, see above. We could just unmerge. Mathglot (talk) 06:34, 18 March 2025 (UTC)

Regarding split: IMO it would be unfortunate to split because it would make its use more complicated. A better way would be to incorporate any desired change in behaviour/output into the existing template. -- Michael Bednarek (talk) 13:39, 18 March 2025 (UTC)

Michael, I see it the opposite way, that it would make it (them) simpler. Can you explain your view? Mathglot (talk) 18:43, 18 March 2025 (UTC)

First, splitting would necessitate changing existing usages of |qid= in {{ill}} to the new template. Second, after a split, editors have to remember the name of another template, {{Interlanguage link Wikidata}}, for Wikidata links. This is particularly cumbersome for articles with several handful of red links, often assisted by scripts like User:Cobaltcigs/IllWill.js (or my fork User:Michael Bednarek/IllWill.js). -- Michael Bednarek (talk) 01:34, 19 March 2025 (UTC)

To be fair, those two reasons doesn't appear to be particularly cumbersome. They're just variants of the basic "yes, of course if we split a template in two you need to switch over some usage to the new template" inconvenience, but if that was considered a show-stopper no template would ever be split. Plus, how did editors do back before the templates was joined together? (I really thought you'd have a use case where it was important you could both link to another language and wikidata at the same time in one and the same template?) Cheers CapnZapp (talk) 09:43, 19 March 2025 (UTC)

I'm thinking that there is a fair point of discussion about an unmerge here, but we are off on a tangent (of which I am guilty of promoting early on) and I think we should shelve it for the time being, in the interest of sticking to the main discussion, if there is indeed any more discussion to be had about it. My sense is that it is spinning its wheels, but perhaps it will regain traction. Mathglot (talk) 09:57, 19 March 2025 (UTC)

Arbitrary break

Start afresh? Or not... Mathglot (talk) 09:57, 19 March 2025 (UTC)

Purpose of this template

Fabrickator and Mathglot raised an interesting or even crucial topic, and I want my reply here for general consumption:

So the following is a reply to how the Polish project (and I think there are others) is using {{ill}}. Read the full context here: User talk:Fabrickator/interlanguage link discussions.

This Polish Wikipedia usage is a good example of what I would strongly argue against. The first ill on the Polish Brisbane page (unless I missed one) is centralną dzielnicą biznesową, or Brisbane central business district. Just listing every Wikipedia project with an article on the Brisbane central business district puts the onus squarely on the reader to find out which, if any, are actually any good or even helpful. But this is, in my experience, vanishingly rare. If there are articles in five languages, the reader should be lucky if even one is worth the visit (and that's assuming the translation is effortless). Of course, for some article subjects you could find a dozen high-quality articles, but I'm talking in general terms here, not anything specific to Brisbane.

I much prefer the approach where ill links are only encouraged when an editor is making a personal recommendation: yes that Swahili or whatever article on the Brisbane central business district really is a good and useful substitute until the time we can offer a Polish-language article (to the point where this Swahili article would make for a great starting point to translate into Polish). We should not clutter our articles with a complete link catalog to other projects just because there might be an article with the correct name, even if that's just a stub or start-class empty shell of an article. {{ill}} should only be used to help readers, not to satisfy completists or as a meta-tool for editors. Why? Because ill links are presented as integral parts of the running text, part of the encyclopedic project, as opposed to menus and sidebars and help pages and See Alsos and wikidata and other "meta" resources. CapnZapp (talk) 10:26, 19 March 2025 (UTC)

Short version: yes, I much prefer curated links, too. What I like about the Polish model is the presentation with the little pop-up table. If I could change that list to be instead the intersection of curated links with my fave languages so that regardless what was curated, I would always see the ones that are in my faves list, with the rest of them available via an extra click, that would be ideal. It may be possible to swap out the underlying foreign-wiki links rendered by the template, for a google-translate link instead, under user css control, but I would have to look into that. Mathglot (talk) 11:01, 19 March 2025 (UTC)

I've only been cursorily following this discussion, but I agree with CapnZapp and Mathglot that a curated selection is much better than leading readers into a mass of links to articles with highly variable quality. older ≠ wiser 11:14, 19 March 2025 (UTC)

I realize I should probably expand on my view: having some kind of functionality that tells me as a reader that there exists an article on the Brisbane CBD in these 7 or 28 other languages is fine, if it is presented away from, and implemented outside of, the actual article text. That is, the ill link should be used to present your personal choice of a foreign-language article as a Wikipedia editor, but if some computer thingamagog manages to detect this and present a "Did you know all these articles exist in other languages, covering subjects our Polish Wiki does not yet cover?" sidebar or subpage, that's fine by me. The difference is: we don't replace hand curated content with automatic linkage (because Wikipedia is an encyclopedia written by humans, not an automatically collated catalog). Rant alert: In this way this subject touches on the same issues as my intense dislike of Wikipedia surrendering movie "Reception" sections to merely parroting Metacritic and Rotten Tomatoes aggregate simply to avoid edit wars between editors liking and disliking some piece of pop culture. A hand curated selection of good critics' reviews of said movie is far FAR superior to garbage like "68% liked this". End rant. It's the same here: every single ill link should represent a recommendation from an editor to the readership, just like everything else that appears as mainspace article text. Regards, CapnZapp (talk) 13:05, 19 March 2025 (UTC)

I don't agree. If an article in the english Wikipedia does not exist, then I find it helpful to get a list of articles in other languages that I actually speak. Therefore, I prefer listing in the template at least the most common languages. Even if, e.g., the chinese version is much better than the german one, I would prefer reading the german article (I do speak German...) instead of using Google translate on the chinese version (I don't speak Chinese). --Cyfal (talk) 20:09, 19 March 2025 (UTC)

Just a sidebar, to note again the parallel discussion at User talk:Fabrickator/interlanguage link discussions (previously linked by CapnZapp). I would hope we can keep this discussion all on one page (this one). Mathglot (talk) 00:00, 20 March 2025 (UTC)

Responding to the title of this section, and to suggestions that we should have *only* a wikidata link and no other links at all, I would say this: the purpose of this template since its inception has always been about emitting a red link and tagging it with a few links to foreign Wikipedia articles. Removing this original, core functionality from the template would be a huge change, altering its basic DNA, and invalidating about 200,000 transclusions in mainspace. If you believe that Template:Interlanguage link should have one link only, targeting Wikidata, then you should propose that Template:Interlanguage link be deleted, resurrect template Template:Interlanguage link WikidataTemplate:Interlanguage link Wikidata, and rename it to 'Template:Interproject link Wikidata', and then redirect this template there. The likelihood of that gaining consensus seems infinitesimal to me, but that would be the proper procedure. You'll also need to request a bot to deal with the existing transclusions. Alternatively, you could unmerge, as previously mentioned, and then a bot would not be required. Mathglot (talk) 01:11, 20 March 2025 (UTC)

It is clear that editors used to the Polish Wiki considers that approach superior, and everybody is entitled to their opinion. Let me see if I can make you reconsider. What I don't like is how the merging of wikidata into this template creates an opening to usurp the intended functionality of this template. You (as in y'all, not Mathglot) could consider it reasonable to offer both functionalities (one template for curated links, one for autopopulated wikidata) but I don't agree. I think Wikipedia is much better off if we make it clear that automatically generated content has no place on Wikipedia. As part of the encyclopedic project, that is - as I have already stated, I have zero objections against quality of life improvements to the editor experience. Just don't conflate that with the actual content intended for readers. The reader should not be given "here's every other language" with the expectation he or she will sort out the bad articles from the good - that is decidedly unencyclopedic! The editor, on the other hand, might well benefit from easy access to such links, and that's fine as long as they are given outside of the text: in menus, sidebars, subpages or what have you. CapnZapp (talk) 10:04, 20 March 2025 (UTC)

Originally written as a reply to User:Cyfal, I decided to post it at the end of the section to minimize the risk of people skipping it, since I realize it's not just a direct response to their post. Thank you Cyfal for making me realize there are two distinct aspects we are discussing.

It's not a good thing if we offer five links and only one of them leads to an actual quality article, and the other four leads to sparse stub articles. In the best case all five links are good to decent, but I think that's rare. There are two distinctly different use cases here: you want a convenient link registry, I want hand-crafted recommendations. Polish Wikipedia has conflated the two, allowing your use case to overwrite mine. I think that is a mistake. I'm not opposed to your idea, but I oppose 1) the placement of your convenient link register and 2) that it would replace curated links.

Regarding the first point: Your convenience links are a meta resource, and should not be given right in the text. I urge you to implement your idea using another tool than the ill links, because they are part of the encyclopedic content, the actual text of the encyclopedia. We link to other Wikis for articles that exist, but we do so as a sidebar. Something similar should be done for articles that don't exist.

Regarding the second point: I urge you to find a way to implement your idea in a way that doesn't supersede the existing purpose of ill: namely providing curated links where an editor doesn't just say "btw this exists", but says "I found this article actually useful, hope it tides you over until an English-language article can be written".

There is no reason these functions must be pitted against each other, just because Polish Wikipedia did so. Again, I don't object to offering "here's every wiki with an article on X" as long as that functionality doesn't interfere with how (and where) ill works today. Best wishes CapnZapp (talk) 10:30, 20 March 2025 (UTC)

I should say I do understand that from a certain perspective it can feel unreasonable to object to just adding the catalog function to today's template. That is, if the template first listed the curated links and then automatically added one more choice "Complete list" (or similar). It would seem reasonable this would satisfy both camps: You could click the one or two languages recommended (and that would fulfil ill's purpose today) and you could click "complete list" and get a popup (or something) populated by wikidata that would fulfil the "Polish ill" template's purpose. However, this just opens a back door to leaving the list of curated languages empty and only relying on Wikidata to fill the list. This completely circumvents the purpose of the template, and that is why I want the two functions to be separate. There is no reason we should conflate the two functions just because that might be technically convenient, thus inviting editors to bypass its intended function just to get to the catalog function! At the very least there should be a big bright error message if you try to leave the list of curated suggestions empty, much like how certain other templates protest when you don't supply the right parameters (can't remember off hand but there's citation-related templates that violently protest if you forget one of the parameters) CapnZapp (talk) 10:47, 20 March 2025 (UTC)

Hi CapnZapp, is it true that "the existing purpose of ill [is]: namely providing curated links where an editor doesn't just say 'btw this exists', but says 'I found this article actually useful'"? I don't find anything like this in Template:Interlanguage link and always interpreted it otherwise. BTW, here and here are some older discussions related to the current one. --Cyfal (talk) 07:12, 21 March 2025 (UTC)

If it helps, I will readily clarify I am a regular user expressing personal preference. I am not speaking for Wikipedia. Cheers CapnZapp (talk) 10:14, 21 March 2025 (UTC)

I agree with CapnZapp's stance that editors ought to pick the most appropriate link(s) instead of offering a list of all existing languages; after all, those not picked are only 1 click away from the picked one(s). -- Michael Bednarek (talk) 11:02, 21 March 2025 (UTC)

Once upon a time (maybe about 3 years ago), I was engaged in a tangentially-related discussion. Tangentially, because the issue was about using the qid to obtain the list of available languages to be displayed. At the time, I was informed that this was not permitted on enwiki. Admittedly, the display of available languages was awkward, i.e. it wasn't displaying just a set of available links, it was displaying the Wikidata page for the specified qid.

Now I came here a couple of weeks ago, and the complaint seemed to be that there was a link labeled "wikidata", which the issue evidently was that it wouldn't be clear to novice users what that was for, and "wikidata" was too long and if you set the "short" (s) parameter, then "d" would be displayed instead of "wikidata", which was even less clear. But the greater surprise was, so it seemed, that the example use case for this was when the available languages consisted of the empty set. So if the "wikidata" link was unnecessarily confusing in the "expected" case (i.e. that there are in fact some usable links), to provide a link only when it offered no usable functionality, then surely the smoking caterpillar was somewhere nearby.

Setting aside the issue of using "wikidata" only when there's actually no wikidata to be found (and the irony would be that if someone were to add a non-English version of that article, then for that one interlanguage link, it would suddenly all be good, even as additional languages were added).

I don't hope to convince any of the advocates of the approach they have been promoting, but if they're intending to insist on this usage (e.g. that the editor is obliged to review the available languages and pick a very limited subset of those languages), then I'm going to urge that we should have a much broader audience discussing this proposal. Fabrickator (talk) 06:26, 22 March 2025 (UTC)

Not arguing for or against you, only to note that you might be crossing the streams here as it were. The initiative to act falls upon the parties that want to effect change, not the parties that support the status quo. Don't expect me, for instance, to act: I'm content with what you brought up earlier (Wikidata links are not allowed in text, and there is no consensus to make an exception for interlanguage links) and I don't have a problem with WikiData links being represented by "wikidata" or "d" mostly because it is functionality I don't use (or encourage anyone using) outside of the presumably specialist usages of the original template*. Regarding the number of languages in an ill link, that needs to remain up to editor discretion. As long as editors find it reasonable to be asked to prune their lists if they link to mostly useless stub articles (as Michael Bednarek says: the complete catalog will appear as a meta resource outside the text once you click the article in any one language), I don't need or want ill to have more specific advice. CapnZapp (talk) 11:37, 22 March 2025 (UTC)

The original template for WikiData ill links was {{Interlanguage link Wikidata}}. I can't find any "should we actually support this" discussion so I'm assuming the template mostly got created because of the classic "because we could"? 😉 The relevant merge discussion is here: Wikipedia:Templates_for_discussion/Log/2015_March_8#Interlanguage_link_templates. I can't find any discussion of "do we actually think is it actually good the main template now supports WikiData links" there either; the discussion appears to be focused on the good old "fewer but more complex resources is always better than more but simple ones" programmer's elegance fallacy (that has doomed so many projects... 🙄). CapnZapp (talk) 11:37, 22 March 2025 (UTC)

Question about other RFCs or discussions regarding the use of {{ill}} for linking to Wikidata

Has there been any other RFCs like Wikipedia talk:Manual of Style/Archive 204#New RFC on linking to Wikidata, which states As to the other proposed exception of linking to WD, by inline inter-language link, given that there is roughly a numerical tie and there's no clear-cut refutable argument(s) from either side, I am unable to see any consensus.? I just had a protracted discussion on using {{ill}} linking to Wikidata here. I would like to be better prepared on discussing content guidelines, template documentation, RFCs & related discussion in the future. Peaceray (talk) 13:03, 18 April 2025 (UTC)

Template-protected edit request on 19 April 2025

I request that a new parameter |post= be added to deal with the cases where puncutation or grammatical particles (e.g. 's) need to be placed between the main link and the bracketed interlanguage link, outlined in the section "Punctuation before language links".

below is a (very basic and also untested) method to do so. it is based off the method used in {{as of}}. hope that an actual coder takes this up!

−

<includeonly>{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#if:{{{italic|}}}{{{italics|}}}|''}}[[{{{1}}}{{safesubst:#if:{{{lt|}}}|{{safesubst:!}}{{{lt}}}}}]]{{safesubst:#if:{{{italic|}}}{{{italics|}}}| ''}}{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#ifeq:{{subst:Substcheck}}|SUBST||<!-- ... -->}}

+

<includeonly>{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#if:{{{italic|}}}{{{italics|}}}|''}}[[{{{1}}}{{safesubst:#if:{{{lt|}}}|{{safesubst:!}}{{{lt}}}}}]]{{safesubst:#if:{{{italic|}}}{{{italics|}}}| ''}}{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#if:{{{post|}}}|{{{post|}}}}}{{safesubst:#ifeq:{{subst:Substcheck}}|SUBST||<!-- ... -->}}

Juwan (talk) 15:25, 19 April 2025 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. – Jonesey95 (talk) 19:04, 19 April 2025 (UTC)

Discussion of at WP:VPR

There is currently a discussion at WP:VPR titled Propose to deprecate direct linking to non-English Wikipedia in articles. The discussion includes suggested improvements to this template. Wracking ^talk! 03:09, 2 September 2025 (UTC)

inconsistent use of parameters values

Why does |display= require specific values to convey "enabled" (i.e. 1, y, yes or force) while for |nobold= you can use any value?

Either make |nobold= only respond to the same four values as |display=, or make |display= respond to any value (so |display=scooby enables force-show too, for example) just like |nobold=. Thanks.

For italics and quotation marks, the documentation is vague. For example, it says: "... use |italic=y (or |italic=yes, etc.)" Does this mean "etc" stands for only 1 and force in addition to y and yes (as for |display=) or does "etc" mean you can use anything (as for |nobold=)?

CapnZapp (talk) 07:39, 13 October 2025 (UTC)

@CapnZapp It's just a documentation artifact. All of those parameters are enabled by using any value, and disabled by leaving them blank or omitting them. --Ahecht (TALK
PAGE) 17:00, 13 October 2025 (UTC)

Thank you. I've updated the doc page. CapnZapp (talk) 20:00, 13 October 2025 (UTC)

Post-expand include size

@Jonesey95: When you updated this template to add unknown parameter tracking, you increased the post-expand include size of the template enough that it broke List of German films of the 2000s, List of German films of the 2010s, and 2021 Hiroshima gubernatorial election. I was able to reduce the impact a bit by invoking Module:Separated entries directly, but that only fixed the Hiroshima page, not the other two. --Ahecht (TALK
PAGE) 16:52, 13 October 2025 (UTC)

The German films of the 2000s article is transcluding {{ill}} 2,720 times. The one for the 2010s contains 2,919 transclusions of {{ill}}. I'm going to go out on a limb and say that's too many. Nevertheless, I have removed the {{main other}} check from this template to see if it makes a difference, and the 2000s article is now at 1548379/2097152. The 2010s article is at 1675669/2097152. If our IP editor continues to expand these articles, they will eventually creep back up to PEIS-land and will need to become less template-intensive or be split.

Removing main other from the parameter check will cause more pages to join Category:Pages using interlanguage link with unknown parameters, which may be undesirable. The current population is 444 pages from article space. – Jonesey95 (talk) 18:59, 13 October 2025 (UTC)

@Jonesey95 I added links to the category description to namespace-specific searches. Looks like 408 from the article namespace, 5 from User, 5 from Wikipedia, 2 from Template, 4 from Template Talk, and 1 from Draft. --Ahecht (TALK
PAGE) 15:00, 14 October 2025 (UTC)

Nice. I was expecting more junk from User sandboxes and Draft pages. It looks like someone is working on cleaning up the invalid parameters as well, because there are only 119 pages in the category at this writing. – Jonesey95 (talk) 17:29, 14 October 2025 (UTC)

Redirects

@User:CapnZapp improved on an addition of mine. Redirects at present are discussed in the Link to multiple languages section. This is quite inappropriate (I had added it to the Usage section, also possibly inappropriate); the discussion applies to single-language redirects, and might be missed by a reader seeking this sort of information. I'd suggest a new section for redirects. I don't think I'm the best candidate to implement this (I missed the fictitious redlink solution that has now been added), but would strongly suggest that a new section should be created and relevant content moved there. While this could be called "advanced", it's a problem that does arise with no obvious solution (I had 2 such cases in one article), not just a clever tweak to improve basic functionality. I also think it's worth a mention in the introduction. Best wishes, Pol098 (talk) 21:51, 15 October 2025 (UTC)

Just to clarify - the "fictitious redlink solution" isn't some official standard or policy so there was nothing for you to miss. It's what I came up with for the circular redirect dilemma. Since that suggestion has remained undisputed for roughly six months I used it again here. If anyone got a better idea, by all means. CapnZapp (talk) 09:25, 17 October 2025 (UTC)

Specifying a variant of Chinese for the interlang?

Chinese Wikipedia has six visible variants, whose URLs only differ by replacing /wiki/ with /zh-cn/, /zh-hk/, etc. Is there a way to make an interlang link (to a page in ZH Wikipedia) explicitly specify any of these six variants without having to express it as an external link? ‐⁠‑🌀⁠SilSinn^AL982100⁠💬 20:22, 5 December 2025 (UTC)

I don't think it's currently possible to use {{ill}} that way. Some East-European Wikipedias, like Serbia and some of its neighbours, have the same problem. Serbia appends &variant=sh-latn and &variant=sh-cyrl to the URL for their variants. {{ill}} can't deal with that, either. Nor can ordinary plain interwiki links of the form [[:xx:lorem ipsum]] work. -- Michael Bednarek (talk) 01:55, 6 December 2025 (UTC)

SilSinn9821, not currently, no. Addition of a new parameter along with template changes would make it possible. The changes would involve converting wikilinks to external links and appending the correct variant value in the query string. It would be a natural extension of existing template features. It would have to await creation of a needed template (see here), after which it could be done, and imho ought to be done. In the meantime, you can think about what the parameter name ought to be called; is |variant= the best option? Mathglot (talk) 04:43, 6 December 2025 (UTC)

|variant= sounds fine to me. ‐⁠‑🌀⁠SilSinn^AL982100⁠💬 05:03, 6 December 2025 (UTC)

At first glance, there seem to be 2 different ways variants are represented in Wikipedia URLs: the Chinese way which replaces the \wiki\ bit with \zh-hk\ etc, and the Serbian was which uses a URL query. Constructing an external link seems suboptimal to me. Maybe {{Querylink}} or similar could profitably be used. -- Michael Bednarek (talk) 06:20, 6 December 2025 (UTC)

{{Querylink}} could be useful, but it also constructs an external link, which I think is fine; it just hides it in the template, as any change to {{ill}} would also do. As it exists, we may as well use it, that might save some effort. Mathglot (talk) 11:56, 6 December 2025 (UTC)

This template would likely require an overhaul in order to implement any sort of change of this type; it codes for wikilinks so if we are attempting to add variants that are really elinks in disguise, a whole new set of code would be needed. Primefac (talk) 11:58, 6 December 2025 (UTC) Just to address a minor point raised below, my comment should not be interpreted as "we can't do this because..." but rather a note about the fact that someone is going to have to do a lot of work if there is support. Primefac (talk) 12:10, 6 December 2025 (UTC)

(edit conflict)

First order of business: let's not get preoccupied with whether or not we could, without first stopping to think if we should.

As an outsider, isn't the purpose of how these Wikis were constructed precisely to not link directly into a specific variant, instead linking to generic concepts and then relying on user preferences to switch into specific regional varieties? I do understand the value of discussing a specific regional variant and linking to it for the wider audience (that otherwise wouldn't be able to access it without fiddling with their user preferences), but isn't the awkwardness of having to supply an external link kind of a good thing, so this isn't used to circumvent the purpose of not having several different wikis in the first place?

What would be an acceptable use case for a regional ill link? I see three cases: a) an ill link signaling that the generic article doesn't exist but a regional variety does. And b) an ill link signaling the regional info doesn't exist so it links to the generic article, and c) an ill link from, say, our English wiki directly into a regional page, bypassing the main one (as well as any user preferences).

An ill link for the regional variant where the main article is red, that is case a, isn't a real use case, right? If concepts without the generic article could still exist in regional variants that's a complicated way of saying "these are independent stand-alone wikis, just with a cumbersome access method." That is, wouldn't case a) "regional ill" links support the idea of separate stand-alone wikis, which I assume is an idea these wikis otherwise work against?

b: I'm assuming this is normal, and ill links aren't needed - this would happen automatically?

c: I have no idea if this is a notion we should support. Presumably this would be for Chinese-speaking (or Serbian-speaking) readers, but wouldn't linking into the generic page already send them to their preferred regional page?

Note: I'm not personally against any of this and if you get upset by this pushback, consider me only asking silly little devil's advocate questions that, when sufficiently answered, strengthens your case. Regards CapnZapp (talk) 12:01, 6 December 2025 (UTC)

For informational purposes, mw:Writing_systems/LanguageConverter appears to be the why, and mw:Writing_systems#LanguageConverter appears to be the what and the how. With all of the above in mind, could we state the proposed use case? TheFeds 04:22, 13 December 2025 (UTC)

Removal of superscript option

In the discussion above a tangential request to remove the |valign= option came about. Three editors (myself, Michael Bednarek, and Jonesey95) supported that change and it was implemented, but then contested (by Mathglot) and rolled back. Since the original issue was solved, I figured it would be worth breaking off this particular discussion to get a firm(er?) consensus (I do not think this needs an RFC, for the record). Personally I feel 3-1 is a good enough consensus, but I suppose CapnZapp never opined even though they were in the middle of that thread, so let's see how many other opinions we have. Primefac (talk) 11:38, 14 December 2025 (UTC)

If I understand correctly, the problem was that superscript bracketed language links like^[es] (and especially the wikidata^[d]) look like lowercase-alpha footnotes (efn's), so the proposed solution was to remove superscript alignment. But that's overkill, and not the only solution. Other, equally good solutions were never discussed. Implementing the links with parens (i.e., 'round brackets'^(BritEngl)) instead of square brackets like^(es) or this^(d) for example, removes the confusion, so we no longer need to remove the superscript param. Problem solved, as far as I can see, as there is no longer any confusion in the appearance of a ref note tag and an ill tag. Imho, we should not remove a param used thousands of times so cavalierly without additional input from the community, to see how they feel about it. Thanks, Mathglot (talk) 11:58, 14 December 2025 (UTC)

I can't see any good reason for the super/subscript positioning. It ought to be removed. -- Michael Bednarek (talk) 13:08, 14 December 2025 (UTC)

Extended content

My involvement was because I felt that changing the code from one hardcoded abbreviation to another was needlessly rigid. If some people prefer "d" and hate "wd", and others the reverse, why bicker? (Insert "why not both?" gif here ;)

We could instead of presenting a binary choice, essentially |short= on or off, present that same choice but also allow any value for the parameter, which would then replace the default abbreviation. So if we were to settle on, I don't know, "banana" as the agreed-upon default abbreviation, then |s=1 and |s=yes would yield "banana" but dissenting editors could still use, say, |s=apple to render "apple". The natural counter-argument to this, of course, would be "there's value in every ill template displaying the same abbreviation", but I can't recall anyone actually deploying it.

Other than this I have no opinion, feel free to proceed as you please. CapnZapp (talk) 13:23, 14 December 2025 (UTC)

Discussion of superscript and subscript only

Somehow, the thread above has forked into a variety of topics, despite Primefac's clear intention to start a single-issue thread. Let's keep this subthread focused on the superscript and subscript options. I continue to believe that they are unnecessary, and confusing to readers. Can one of the proponents of the superscript and/or subscript options provide a reason why they should stay? What style guide recommends superscript and/or subscript for items of this type? – Jonesey95 (talk) 15:53, 14 December 2025 (UTC)

The WP:Manual of Style/Superscripts and subscripts just became a guideline in June, and this should probably be discussed there. The Rfc establishing it as a guideline was primarily about use of tags like <sub> and <sup> versus native Unicode superscript characters; the page previously discussed mostly ordinals, math, and music. The page does not currently discuss the use of the {{ill}} template (or any template) so has nothing to say one way or the other about it. I'm kind of in the "needlessly rigid/why bicker" camp here, as well as more of a descriptivist than a prescriptivist: I have nothing against an article that wants to consistently use them at baseline, but I see advantages to the superscript location and so, apparently, do some other editors. Assuming I haven't erred, there are about 656^{[slow query]} of them. Some do it one way, some do it the other way. I don't see why one of the ways should be prohibited (kind of a MOS:VAR thing), but a broader discussion at the new guideline could sort it. Mathglot (talk) 09:58, 17 December 2025 (UTC)

Discussion at Help talk:Citation Style 1 § COinS pollution shouldn't be a problem

 You are invited to join the discussion at Help talk:Citation Style 1 § COinS pollution shouldn't be a problem. –CopperyMarrow15 (talk ⋅ edits) 04:42, 18 December 2025 (UTC)

recent change from square brackets to parentheses

I found this recent change surprising.

I see it was done because confusion between ill codes and ref numbers, but I can't quite see why there would be any such confusion given that language codes do not correspond to standard ref numbers, and the link size, position and color is different. It might be confusing if someone uses the superscript option, but that's very rare AFAICT. Why not just remove the latter?

Also, when the text is inline in normal parentheses, it doesn't stand out so much from other links. But it is pretty weird for the average reader by default - it's not in English - so the extra visual element of using the brackets should be helpful to indicate to readers that it's not just business as usual. --Joy (talk) 16:48, 24 December 2025 (UTC)

This also through me when looking at an article where an {{ill}} appeared next to a parenthetical, as in "some_redlink (parenthetical)". This introduces a stylistic issue where there previously was none. If the concern was about the specific edge case of superscript Wikidata links looking like lower-Latin footnotes, then the solution there, it would seem to me, is just change the ambiguous "d" (which isn't a common abbreviation for Wikidata anywhere other than Wikimedia internals) to "WD", a better-known abbreviation without the same issue. There is no ISO 639:wd, and as I understand it there are no plans to assign new ISO 639-1 codes, so it should be fine to use "WD" in that way. Then, we could return to the familiar and less stylistically troubling square brackets. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 17:12, 24 December 2025 (UTC)

Agreed. I don't think a single-letter link would be a clear enough link, ever. Besides, isn't this change already done? test test renders "wd" already.

On this note, the mouseover text is informative in that case, saying Wikidata list: "test test" articles in other languages. But test test just says de:test test. It should say something actually informative, like Article "test test" at the German (de) Wikipedia. --Joy (talk) 17:20, 24 December 2025 (UTC)

"wd" could in rare cases still be ambiguous with the 26*24+4=628th {{efn}} in an article, but that would also be solved by capitalizing as "WD"; technically an article could have 628 upper-Latin footnotes but I can't recall ever seeing that, let alone on one using the less common superscript {{ill}} style. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 17:31, 24 December 2025 (UTC)

The change from square brackets to parentheses was done by one editor without discussion; the change they reverted (without discussion) had removed superscripting and had been discussed and tested. As for (wd) or [wd] for Wikidata, that change was preserved (link to test case). I wish that there had been more discussion and editing of the sandbox, as there was with the initial changes, but that did not happen. I recommend reading through the multiple discussions above to understand the chain of events. – Jonesey95 (talk) 17:50, 24 December 2025 (UTC)

If you could be so kind and just revert the bold edit, I'd appreciate it. --Joy (talk) 21:28, 24 December 2025 (UTC)

I have been told in the past at ANI that BRD does not apply to templates, which I do not agree with, but I don't enjoy being told things at ANI. I have no interest in a slow-motion edit war with Mathglot, but maybe they will be receptive to your request. – Jonesey95 (talk) 21:31, 24 December 2025 (UTC)

I don't quite see the logic in not undoing changes without consensus in templates. Indeed, the overall spirit Wikipedia:Template editor is very much against unverified changes, and I don't see how the correctness of this change was verified. Hence, it should go back to the old status quo.

If I see correctly, the edit was this one? If I revert this now, would anything break? --Joy (talk) 21:56, 24 December 2025 (UTC)

I edit-conflicted with you, but it has already been done. Thanks, Mathglot (talk) 22:30, 24 December 2025 (UTC)

I do not like parentheses there, either, for all of the reasons stated. I added them for one reason only: to forestall a destructive change to the template involving removal of superscript option, the sole substantive reason for which appears to be possible confusion between an ill superscript bracketed 'd' standing for wikidata (thus:^[d]) which looks indistinguishable from a lower-alpha explanatory note where the fourth one looks identical. That is indeed a problem, and a decision (3–1) was made to remove superscript option to solve the problem, which it did. But it was a major change, little discussed, and most of all it was the wrong solution. Adding parentheses is not the right solution, either; it is another bad solution, but at least it obviated the need for immediate removal of superscript option, so this could be properly discussed.

It has been mentioned (for years, I think) that '[d]' meaning wikidata ought to be '[wd]' or '[wikidata]', and I agree with either of those. That is the proper solution, imho. Questions about whether we should or shouldn't have superscript option (or subscript, or italics, or any of the other options) should be discussed and decided on the merits, and independently of any conflation with unrelated issues, such as 'is-d-a-note-or-a-wikidata-tag'. I am happy (eager, even) to remove the parentheses and restore brackets returning it to long-time stable appearance. Thanks, (edit conflict) Mathglot (talk) 22:26, 24 December 2025 (UTC)

I have been told in the past at ANI that BRD does not apply to templates → As I recall, the idea behind WP:TPEBOLD and WP:TPEDISPUTE dates to something I added to the then-infopage 13 years ago; I was rather surprised when I returned to editing to learn that my 17-year-old self's idea (as refined by others) had become part of a guideline, but it does seem to have consensus, and still seems to be a good approach IMO. It's worth stressing that those provisions apply as much to the "B" part as the "R" part. The overriding point is that, on pages that most users cannot edit, it's important to have consensus before doing anything controversial, which also includes undoing things in ways that will only increase the controversy. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 07:14, 25 December 2025 (UTC)

Tamzin: I got wd at note 602; maybe I skipped something somewhere. I suspected with that many notes we might hit a template resource limit, but everything was well within bounds. Otoh, the bracket links don't wrap (which I never knew) causing a very wide page to appear. From a practical point of view, I don't think this will occur. Mathglot (talk) 02:56, 25 December 2025 (UTC)

tooltips for interlanguage links implementation issues

Per my earlier comment, I added {{tooltip}} usage to the interlanguage links in this edit that I had tested in the sandbox.

I don't know how to properly verify {{interlanguage link/testcases#Expensive parser function calls}}, though. I checked the parser profiling data before and after my changes, and there was this growth:

• CPU time usage 0.457 -> 0.78 s
• Real time usage 0.541 -> 0.892 s
• Preprocessor visited node count 9,860 -> 18,218

This seems suspect. At the same time, the "Expensive parser function count" was still at 34 in both cases.

I found references to this topic in /Archive 3#Expensive parser function, which said List of villages in Rivne Oblast was an example of the problem. In the edit preview, before my edit, parser profiling data said:

CPU time usage
5.491 seconds
Real time usage
5.572 seconds
Preprocessor visited node count
212,329/1,000,000
Revision size
78,228/2,097,152 bytes
Post-expand include size
898,913/2,097,152 bytes
Template argument size
159,798/2,097,152 bytes
Highest expansion depth
11/100
Expensive parser function count
0/500
Unstrip recursion depth
0/20
Unstrip post-expand size
8,334/5,000,000 bytes
Lua time usage
1.797/10.000 seconds
Lua memory usage
2,372,783/52,428,800 bytes
Number of Wikibase entities loaded
0/500

After the tooltip change, edit preview there reported:

Warning: Post-expand include size is too large. Some templates will not be included.

Parser profiling data said:

CPU time usage
6.837 seconds
Real time usage
6.899 seconds
Preprocessor visited node count
375,363/1,000,000
Revision size
78,228/2,097,152 bytes
Post-expand include size
2,097,152/2,097,152 bytes
Template argument size
449,486/2,097,152 bytes
Highest expansion depth
20/100
Expensive parser function count
0/500
Unstrip recursion depth
0/20
Unstrip post-expand size
217,603/5,000,000 bytes
Lua time usage
2.452/10.000 seconds
Lua memory usage
2,610,340/52,428,800 bytes
Number of Wikibase entities loaded
0/500

So I've reverted the edit. --Joy (talk) 00:42, 1 January 2026 (UTC)

I'm guessing all of those safesubst:'s and {{substcheck}} usage might be the trick, but it doesn't seem to be documented. --Joy (talk) 00:53, 1 January 2026 (UTC)

Please get consensus before implementing something this massive. Primefac (talk) 01:16, 1 January 2026 (UTC)

The feature itself is not massive for readers, it's fairly trivial, just to aid the occasional reader who hovers their mouse over the curious little bracketed string next to a red link. Since most readers aren't on desktop anyway these days, the impact can't be large.

The issue is technical, why is the seemingly mundane implementation so onerous. In the output it generally just adds a <span> with a title to the country code string. I've asked over there for help. --Joy (talk) 09:44, 1 January 2026 (UTC)

• You should gain consensus for massive changes, whether they are massive for readers or just massive for Wikimedia's servers...
• It is true that 2/3rds of readers are on mobile. However, it is also true the mobile interface sucks in comparison to desktop, especially for editors. I do not think 2/3rds of editors are on mobile. Thus please keep considering the desktop experience at least as important as mobile if not more so. CapnZapp (talk) 09:48, 3 January 2026 (UTC)

  Well, that's exactly who the change is for - it makes life a bit easier for the desktop users.

  I don't understand exactly what the purpose is of these two complaints, because I literally self-diagnosed and self-reverted the change within minutes.

  It would be very nice if you could appreciate the fact that someone else is making a genuine effort. It would be also very nice if you could help figure out the bug.

  Continuing to complain about a non-existent process issue is not helpful. --Joy (talk) 10:42, 3 January 2026 (UTC)

  My comment was mainly to imply (and I admit, I could have worded it better) that there is no point in debugging an issue if the proposed change does not have consensus. Primefac (talk) 13:23, 3 January 2026 (UTC)

  Nobody said anything to the contrary to the idea when I mentioned it in the previous discussion ten days ago, so there was no reason to assume it is against any sort of a consensus.

  BTW, in Template talk:Tooltip#use in interlanguage links I was told this is because of how the template output limits are counted, and the current template is already expensive in this regard (for each byte of output it seems to spend twice as much memory). I'll see if I can try to figure out a more streamlined implementation in the sandbox. --Joy (talk) 14:54, 3 January 2026 (UTC)

Reasonator param

Param |reasonator= appears to be undocumented. Mathglot (talk) 10:40, 11 February 2026 (UTC)

Correct. It has been deprecated and the only reason I haven't removed it from extant uses is because those uses also call |qid= or similar (i.e. nothing is "broken"). Every once in a while I'll go through and remove another half-dozen or so. Primefac (talk) 10:43, 11 February 2026 (UTC)

Behaviour when no language code is provided

I noticed that if you don't provide any language code argument, the template will just add a pair of empty square brackets. Would it be possible to suppress the brackets until there's at least one character in the arg?

If you encounter the below:

foobaz

...then go looking for the stray brackets - they're nowhere to be found in the wikicode:

{{ill|foobaz}}

It's a little confusing for editors who don't know what the template does. EditorInTheRye (talk) 11:32, 13 January 2026 (UTC)

I think strange behavior is fine when you use a template in wrong/unintended ways. The strange output alerts the editor to something is wrong, helping him or her to not think everything is in order, and maybe even providing that crucial clue there's an argument missing. Of course in an ideal world a perfectly clear error message would be preferable. Mostly saying this to point out that what we should not do is try to have the template "gracefully" accommodate the lack of a required parameter. We should not suppress the brackets since this makes it much easier for the error to go unnoticed. If {{ill|foosball}} resulted in foosball that would be worse - more confusing and even less informative. Not only do you now get no hint you forgot to specify a language code, new editors will likely not understand how or why the link is red when foosball is a perfectly working blue link (a redirect to Table football). CapnZapp (talk) 17:18, 13 January 2026 (UTC)

EditorInTheRye, thank you for raising this. I have mixed feelings about the missing lang code issue. On the one hand, in a professional software environment with a complete software dev cycle including full argument validation in the code, a documentation department, a release process, regression testing and QA department sign-off, and launch/cutover (all of it expensively paid), then yes, the template ought to be more robust and handle that case, and that is a worthy goal for template editors at Wikipedia to strive for.

On the other hand, we don't have any of that professional framework. What we have instead are volunteers wearing all of those hats, or trying to, as best they can and donating their time freely to help make it easier for other editors to complete complicated little tasks much more easily than they otherwise could. Sometimes corners are cut, with the hope that having something out there that actually works is better than nothing, even if there are corner cases that might sometimes bite you. A blunter restatement of that might be this: Why should a template editor spend their time coding a perfect template that covers every eventuality, merely to ensure that the user who won't bother to RTFM gets a beautiful error message whenever they use it incorrectly instead of just emitting gobbledy gook, when the template writer could instead be volunteering their time creating another cool template somewhere else for users who are willing to RTFM?

Where I do agree with you, is that the FM (i.e., the doc page) could be improved, maybe to the point where your case would disappear. In particular, there is no ==Parameters== section on the doc page, and there should be one. That function is currently served by section § TemplateData, which does state in the top row of the parameters table that the Article name (param 1) is required (bold in the original). But I think the template still needs a Parameters section. Would you like to volunteer to write one? Mathglot (talk) 02:36, 10 February 2026 (UTC)

Just to note - you're now talking about the article name parameter being required. This discussion is about the language code parameter, and, I guess, specifically the 1st language code. It is listed as "suggested" only.CapnZapp (talk) 20:10, 10 February 2026 (UTC)

I did a quick check and there are ~60 cases of no language for {{ill}} use (so probably ~100 when considering other valid name calls), but I've added a tracking category so that we can get a better idea of the scope of this issue (currently there are 3 transclusions but that number will be in flux for a bit as caches get updated). If that number stays low after we deal with all of the extant uses, I would probably make the argument that it's not worth doing anything more than keeping an eye on that cat (rather than going to the trouble for an already computing-power-heavy template to code more things in). Primefac (talk) 10:35, 10 February 2026 (UTC)

Good idea. I was going to fix some of them in the category (current tally: 4: (Absalon, Alfonso V of Aragon, 1997–98 Coupe de France, List of wars involving Spain). The first two are lacking a language parameter because they contains a |qid= instead; the third was legit and is now a blue link, so I replaced it,; and the fourth I'm not sure, because it has 114 {{ill}}s, including this one:

{{ill|Siege of Valencia (1092–1094)|lt=Siege of Valencia|ca|Setge de Balànsiya (1092–1094)}}

i.e., the lang code occurred later in the param list after a named param; I didn't see any other issues, but I might've missed something. Mathglot (talk) 11:36, 10 February 2026 (UTC)

Vandal war of 422 was improperly coded into the template (see Special:Diff/1337593686). The other three got "dealt with" by me coding qid into the param check. Primefac (talk) 11:41, 10 February 2026 (UTC)

Fixed most; was amazed how many of them were blue links on en-wiki. Mathglot (talk) 12:52, 10 February 2026 (UTC)

Yeah, there are almost 7k pages with bluelinked transclusions but the bot can only hit so many of them at one time (and quite a few that need human intervention). Primefac (talk) 13:00, 10 February 2026 (UTC)

Resolved some more. There may be another case to add to the category code, regarding param 'reasonator'. This appears to be an undocumented feature, and I'm not sure what the syntax is, or if article Chikyū#History is a violation of it or not; search-on-page for "began drilling the". Lots of 'reasonator' examples at Ibogaine. Mathglot (talk) 11:05, 11 February 2026 (UTC)

Re CapnZapp's observation "the 1st language code ... is listed as "suggested" only": Is it possible to document in TemplateData that at least 1 of 2 parameters is required? Given the subject of this discussion, this seems important. -- Michael Bednarek (talk) 11:58, 11 February 2026 (UTC)

Unfortunately not (this is from a technical perspective, as you only get "suggested" and "required" as options in TD), unless there is a consensus to not allow the WikiData parameter in the article space. Primefac (talk) 12:07, 11 February 2026 (UTC)

Pity. I would object to disallowing the Wikidata parameter, so the "at least on of" constraint ought to be documented. -- Michael Bednarek (talk) 12:41, 11 February 2026 (UTC)

Michael, and now it is. Have been meaning to revamp the doc for quite some time, so that was the impetus I needed. See if this clarifies it sufficiently. With the new § Parameters section, there will be some overlap with existing doc in other sections that will need consolidation, but this is at least a first step to fill a gap of long standing at the doc page. Mathglot (talk) 23:29, 11 February 2026 (UTC)

Impressive. Thank you. -- Michael Bednarek (talk) 23:50, 11 February 2026 (UTC)

The 60 cases are down to five two according to your search string, but I think four of those may actually be done and there's probably a delay in updating the index. The only one I'm sure still needs work is Modern system of ranked Shinto shrines (264 ill's, sigh). Do you feel like tackling that one? Hopefully with the updated doc, we won't have any more of these, but I did notice some of them creeping in in translations from Russian articles in 2025, but I noticed also that the same editor had corrected the issue in other translations several months later, so maybe content translation got better, or maybe they did. Mathglot (talk) 21:18, 14 February 2026 (UTC)

Tracking is better with categories, in this case Category:Pages using interlanguage link with no language parameter (3) though I'm not tracking templates so there might be a few navboxes that will be affecting the count. Primefac (talk) 11:27, 15 February 2026 (UTC)

Overuse of this template

Split from this section to maintain discreet values

List of wars involving Spain and Modern system of ranked Shinto shrines strikes me as pages that basically shouldn't use this template. Maybe our documentation (as well as H:FOREIGNLINK) should push harder the alternatives? When a page has many dozens of foreign-language links it often is a summary page of loads of concepts with loads of articles. It should be straight-forward to present the foreign-language articles using one of the alternatives to this template. To me, the main strength of this template is to avoid having to break up the flow of running text, and once you have many dozens of links, that's no longer an immediate concern. CapnZapp (talk) 13:29, 15 February 2026 (UTC)

I don't think I follow your logic; take for example Modern system of ranked Shinto shrines § Imperial shrines, 2nd rank: of the 25 rows, all but 2 have bluelinks, indicating that the information is valuable. The two redlinks point to extant articles on jaWiki, meaning that if someone wishes to write the article they have a jumping-off point. As far as caWiki goes there is clearly a bit of over-specification with their articles, and from a quick glance many of those redlinks could probably be condensed into a single article if someone were interested. As a minor point, this seems more like a different issue than the no-lang issue; might be worth splitting this off? Primefac (talk) 13:39, 15 February 2026 (UTC)

My logic is: whenever you're creating a page with dozens or hundreds of ill links, you probably could and should rearrange the page so that the foreign-language links are presented systematically, like in its own table column or whatever. Just piling on ill link after ill link as if each one is just temporary and the value is keeping the text flowing feels... as if that editor just hasn't truly grasped what ill is meant for. This is an aside for sure; you are free to move it if you wish. CapnZapp (talk) 18:10, 15 February 2026 (UTC)

Ah, fair point; a list/outline article that is entirely redlinks (regardless of other languages) does feel a bit problematic. It certainly has caused some major issues with PEIS (see e.g. List of German films of the 2000s discussed here). I'm not sure how we would be able to track the number of uses on a single page, but I'd be okay with discouraging mass-use in a single article. Primefac (talk) 18:34, 15 February 2026 (UTC)

Doc page refactoring

I've added a § Parameters section (previously missing, or handled solely at § TemplateData ) that resembles the Parameters sections of other templates. One difference in this Parameters section is that I've divided the params into three logical groups for the purposes of explanation. This is partly due to the fact that there are 33 parameters (actually, 41; more on that later), and grouping them makes it a bit easier to understand what's going on, and also makes it less intimidating for first-time users and imho even makes it easier for habitués to easily find a param description.

There was no brief statement about what the template is for at the top, as is usual; I have added one, and moved the long (2,500-byte), rambling paragraph previously at the top under the new heading § Introduction. It isn't really an introduction, more of a grab-bag of remarks that will probably end up being moved into different places in the doc where they will fit better. It isn't yet obvious whether anything will remain of the present introduction or whether we even need one at all, but I think that will become clearer as the refactoring progresses.

Have done some reorg of the section structure, and some moving content around to place it more logically. As a result, there is some duplication or overlap and jumpy seguës that need consolidation and smoothing out. I'm going to take a break from the doc page for a bit, but it could use more eyeballs and work. Mathglot (talk) 07:19, 12 February 2026 (UTC)

One missing bit is what to say about citations. I have seen plenty of citations with ill's, and plenty that use external links (e.g., for an author or title that have an article on Spanish Wikipedia, but we don't). May check over at CS1 talk. Mathglot (talk) 09:03, 12 February 2026 (UTC)

Here's something about citations and ill's, but it's just an assertion. Not sure if there is a guideline behind it or not or any consensus on what to say about it. Maybe we shouldn't say anything. Mathglot (talk) 09:34, 12 February 2026 (UTC)

There have been several discussions suggesting to allow {{ill}} in author and similar fields. The chief maintainer of the CS1|2 citation system, Trappist the monk, has explained why this is not feasible (pollution of metadata. I think) and AFAIK citation templates will reject {{ill}}. It'll work for non-author fields, e.g. |publisher=. However, the workaround is to link to the foreign author using |author-link= with the [[:xx:foreign article]] construct which will be indicated in the citation template' output. In handwritten citations, {{ill}} is of course possible.

• Jow Blow. A book title. {{cite book}}: Check |author= value (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
• Jow Blow [in French]. A book title. An invented French publisher.

In short: {{ill}} cannot be used for authors and such in CS1|2 citation templates. -- Michael Bednarek (talk) 10:27, 12 February 2026 (UTC)

I'm pretty sure it's the How To section that is bloating the text; this template is not that complicated, and I think that section does way too much hand-holding to really spell out a bunch of unnecessary detail. The Usage section describes how the template works, so e.g. the subsection for "Link to one foreign language" should be 1/3 as long. Primefac (talk) 11:27, 12 February 2026 (UTC)

Thank you for making our documentation better. Let me have a look to see if I can contribute further. CapnZapp (talk) 12:43, 12 February 2026 (UTC)

I was not involved with the How To section in its original conception, and would not be sad to see it removed, especially now that we have section § Parameters, which addresses much of the same information, albeit more briefly. But I did considerably expand How-to subsection § Link to Wikidata instead of specific Wikipedias, whose content I think needs to be kept in some form, even if the major section § How to is deleted. The good news there, is that the great majority of added content in that subsection is a brief intro to wikidata & qid (which I was surprised not to be able to find anywhere) which can and should be spun off into its own page, perhaps Help:Wikidata and qid (plain and simple), and then linked (or {{excerpt}}ed ) in that section. Mathglot (talk) 10:09, 13 February 2026 (UTC)

Just as a historical note, there is a deleted /doc/sandbox from a time when all of the various interlanguage link templates were being merged together, and I believe this is the reason for the size of the current /doc (which essentially became a "throw all of the use cases into one place" scenario). Primefac (talk) 11:59, 14 February 2026 (UTC)

The documentation was substantially rewritten on 00:52, 23 February 2026. CapnZapp (talk) 09:53, 23 February 2026 (UTC)

"Note d"? - No, it's a link to Wikidata!

For the benefit of unsophisticated users, could something be done to prevent the -qid -short -superscript version of this link from looking like an ordinary "Note  d"?

My suggestion is simply to make it read "wd" instead of "d". (I am using the Wikipedia app on a tablet and there are no pop-ups or mouse-overs.)  180.150.38.244 (talk) 13:06, 8 October 2025 (UTC)

To me, a far better solution would be for |short=/|s= to display.... the value of the parameter! You could still have |s=1, |s=yes and similar display ^[d] not to break compatibility with the current instructions, but this way, an editor wanting ^[wd] could simply enter |s=wd 👍 That way we avoid a back and forth where the parameter is hardcoded to some single value different people can't agree on. CapnZapp (talk) 13:34, 8 October 2025 (UTC)

@CapnZapp But it's the poor unsophisticated *readers* (me) I'm worried about. Can't the Wikipedia community settle on something (please, only *one* thing) that is short and suggests "this will take you to somewhere else" and doesn't look like a note at the bottom of the page. 180.150.38.244 (talk) 14:30, 8 October 2025 (UTC)

I can't be the only one who got/will get fooled. 180.150.38.244 (talk) 14:33, 8 October 2025 (UTC)

Could the "d" be replaced with some extended character that looks like the "little box that represents an URL"? 180.150.38.244 (talk) 14:41, 8 October 2025 (UTC)

Or we get rid of the superscript, which is 99.99% used as footnotes/explanatory notes, and is thus confusing regardless of whether it's ^[d] or ^[fr]. Primefac (talk) 22:56, 8 October 2025 (UTC)

The vertical alignment option was a bit controversial when it was discussed in May 2015. I would support removing it. -- Michael Bednarek (talk) 00:45, 9 October 2025 (UTC)

Yes, |v=sup makes it look just like a footnote, which is a terrible idea. We should get rid of |v=. [Note: it is apparently used 16,128 times, out of about 640,000 transclusions, so we might want to examine its usage a bit before summarily removing it.] Also, I think it would not be difficult to change "[d]" to "[wd]". – Jonesey95 (talk) 00:04, 10 October 2025 (UTC)

I would also like to see usage patterns. I am fine with prohibiting/limiting use of interwiki superscripts in running text in mainspace, but can imagine specialised applications exist. —Kusma (talk) 08:58, 13 October 2025 (UTC)

I've removed the usage of |v= from the Wikidata example of the documentation. Not primarily because of this discussion, but because it's not pedagogical to mix parameters in documentation. Still, I agree any short form for [Wikidata] needs its own visual identity. CapnZapp (talk) 11:06, 16 October 2025 (UTC)

So... nothing came of this and nothing was changed? Am I summarizing this correctly? CapnZapp (talk) 10:47, 8 December 2025 (UTC)

I have adjusted the sandbox to:

• get rid of vertical alignment entirely

• I kept |v=ib for use in infoboxes, where reducing the font-size to 85% is not permissible for accessibility

• change "[d]" to the (nonstandard but much more understandable) "[wd]" for Wikidata links (the hover text remains the same)
• trim whitespace from the language code parameters (see Template:Interlanguage link/testcases#Test with extra spaces in parameter values)

This removes some existing functionality, standardizing the display of this template to reduce confusion for readers. It may break some usages that are not in evidence on the testcases page. Let me know if you see any problems. – Jonesey95 (talk) 19:57, 9 December 2025 (UTC)

Note that this formatting change will modify the appearance of something like 3,500 pages that use |vertical-align=sup. Here's a typical example, which shows the link looking just like a footnote marker. That's exactly what we are trying to avoid by implementing this change. Category:Pages using interlanguage link with unknown parameters will load up with pages. If this change sticks, we can have a bot go through and remove the no-longer-supported parameters. – Jonesey95 (talk) 20:11, 9 December 2025 (UTC)

Thank you for those changes. I can see no reason not to implement them. -- Michael Bednarek (talk) 00:15, 10 December 2025 (UTC)

 Done. As I said, this will cause a ton of pages to flow into Category:Pages using interlanguage link with unknown parameters. – Jonesey95 (talk) 06:24, 10 December 2025 (UTC)

I'll get my bot to go through everything once the cat populates. Primefac (talk) 09:40, 11 December 2025 (UTC)

No consensus for this. Rolled back. Please run an Rfc or something. Mathglot (talk) 10:33, 14 December 2025 (UTC)

Changed square brackets to parens; now there can no longer be any confusion between ill codes and ref numbers. Mathglot (talk) 10:47, 14 December 2025 (UTC)

You also reverted a bunch of useful changes like the trim and infobox support, which I've restored; straight rollback wasn't appropriate here. Primefac (talk) 10:53, 14 December 2025 (UTC)

Grumble; why are multiple changes being made in a single release then, if that's what happened? So I have to figure out how to reimplement a param that has been there forever? If I have to, I will do that, but procedurally that seems back-asswards. Mathglot (talk) 10:58, 14 December 2025 (UTC)

Because one edit is better than four; I will also note Special:Diff/1327255949 was also reverted. And yes, as a template editor you should absolutely take the time to figure out how to reimplement the code without rolling everything back. In this case it was a simple matter of re-adding the parameters, instead we have a multiple-edit war with you trying to bodge everything back and me trying to fix it in the meantime. Does Special:Diff/1318409996/1327448629 look sufficient to you? Because it does to me. Primefac (talk) 11:05, 14 December 2025 (UTC)

Sounds like a philosophical difference to me, about who has the responsibility to reimplement, where there isn't consensus about which version is "last good version", and there's no clear answer to that. I was prepared to do it, grudgingly, because it didn't seem right to reimplement a consensus version that's been around for ages, but I get that you saw consensus lying elsewhere, so viewed it differently. In the end, your willingness (or perhaps, frustration and just wanting to get on with it) resolved the logjam, so thanks very much for that; much appreciated. Now we can get on with the Rfc, if one is needed, though I think the problem is resolved now, so don't think we need one. Thanks again for the latest version. Cheers, Mathglot (talk) 11:20, 14 December 2025 (UTC)

Or... one or both of you could edit the sandbox like I did until you have your preferred version, then show the differences in the testcases page and continue this two-month-long discussion. There was no emergency here. I fixed multiple things that were broken by editing the sandbox carefully and then deploying after waiting two months for objections. – Jonesey95 (talk) 15:47, 14 December 2025 (UTC)

The template currently has {{ill|Basil of Luni|qid=Q3635819|short=yes}} yield Basil of Luni (at the time of this writing rendering as Basil of Luni [wd]), so apparently a consensus did form, even though you wouldn't know it from reading this talk. CapnZapp (talk) 12:31, 25 February 2026 (UTC)