Template talk:Interlanguage link#Lots of wikidata links for non-notable people

{{Permanently protected}}

{{Copied|from=Template talk:Interlanguage link/Old version/Talk|to=Template talk:Interlanguage link|from_oldid=750047563|to_diff=750048413}}

{{Old TfD|date=2015 March 8|merge=Template:Interlanguage link|result=merge|Template:Interlanguage link multi}}

{{Old move

| date = 7 November 2016

| from = Template:Interlanguage link multi

| destination = Template:Interlanguage link

| result = Moved

| link = Template talk:Interlanguage link/Archive 2#Requested move 17 November 2016

}}

{{WikiProject banner shell |1=

{{WikiProject Languages}}

{{WikiProject Translation studies}}

}}

{{User:MiszaBot/config

|archiveheader = {{talkarchivenav}}

|maxarchivesize = 150K

|counter = 6

|minthreadsleft = 4

|minthreadstoarchive = 1

|algo = old(90d)

|archive = Template talk:Interlanguage link/Archive %(counter)d

}}

{{archives}}

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, {{para|qid}}, instead of {{para|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)

:{{ping|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)

::{{slink|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)

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'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: "{{ill|Gregor Gog|de}}'s paintings" – and in "{{ill|Gregor Gog|lt=Gregor Gog's|de}}" the "'s" appears blue, too: "{{ill|Gregor Gog|lt=Gregor Gog's|de}} 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 {{para|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 {{ill|Gregor Gog|de}}." 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)

::{{bcc|Steel1943}} 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 {{t|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 {{para|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:

  • {{tlc|ill|This page does not exist either|fr|_show_result=yes}} 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)

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:

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). olderwiser 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. olderwiser 11:12, 11 March 2025 (UTC)

:One solution I've always thought is that redirects with {{tl|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 {{tl|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)

{{od}}

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 {{small|{{bracket|simple}}}} blah blah

using Scott Sundquist {{small|{{bracket|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 {{tl|ill}}:

: blah blah {{ill|Scott Sundquist (Soundgarden drummer)|lt=Scott Sundquist|simple|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 {{tl|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. olderwiser 13:48, 13 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 {{tl|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. {{pb}} 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. {{tl|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. olderwiser 11:14, 19 March 2025 (UTC)

{{od}}

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 {{no redirect|Template: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)

{{od}} 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, [https://en.wikipedia.org/wiki/Template_talk:Interlanguage_link/Archive_3#What_use_is_this_template? here] and [https://en.wikipedia.org/wiki/Template_talk:Interlanguage_link/Archive_4#Proposal:_reduce_the_number_of_foreign_links 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 ({{tq|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)

{{od}}

The original template for WikiData ill links was {{tl|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 {{tnull|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 {{tq|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 {{tnull|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

{{edit template-protected|Template:Interlanguage link|answered=yes}}

I request that a new parameter {{para|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 {{tl|as of}}. hope that an actual coder takes this up!

{{text diff

|{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#if:{{{italic|}}}{{{italics|}}}|}}{{{1}}}{{safesubst:#if:{{{lt{{safesubst:#if:{{{italic|}}}{{{italics|}}}| }}{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#ifeq:{{subst:Substcheck}}|SUBST||}}

|{{safesubst:#if:{{{quote|}}}{{{quotes|}}}|"}}{{safesubst:#if:{{{italic|}}}{{{italics|}}}|}}{{{1}}}{{safesubst:#if:{{{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)