Template talk:Interlanguage link

  1. Home
  2. Wiki

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

[edit]

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)[reply]

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)[reply]
@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)[reply]
I can't be the only one who got/will get fooled. 180.150.38.244 (talk) 14:33, 8 October 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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
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)[reply]
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)[reply]
Thank you for those changes. I can see no reason not to implement them. -- Michael Bednarek (talk) 00:15, 10 December 2025 (UTC)[reply]
 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)[reply]
I'll get my bot to go through everything once the cat populates. Primefac (talk) 09:40, 11 December 2025 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

inconsistent use of parameters values

[edit]

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)[reply]

@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)[reply]
Thank you. I've updated the doc page. CapnZapp (talk) 20:00, 13 October 2025 (UTC)[reply]

Post-expand include size

[edit]

@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)[reply]

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)[reply]
@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)[reply]
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)[reply]

Redirects

[edit]

@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)[reply]

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)[reply]

Specifying a variant of Chinese for the interlang?

[edit]

Chinese Wikipedia (zh) 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? ‐⁠‑🌀⁠SilSinnAL982100⁠💬 20:22, 5 December 2025 (UTC)[reply]

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)[reply]
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)[reply]
|variant= sounds fine to me. ‐⁠‑🌀⁠SilSinnAL982100⁠💬 05:03, 6 December 2025 (UTC)[reply]
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)[reply]
{{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)[reply]
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)[reply]

(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)[reply]

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)[reply]

Removal of superscript option

[edit]

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)[reply]

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)[reply]
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)[reply]

Discussion of superscript and subscript only

[edit]

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)[reply]