Template talk:Interlanguage link/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Automating this template with WikiData?

I like how this template changes from a redlink to a bluelink when a page is created on EnWiki. It got me thinking: Is there a way to extend this functionality? So if I use {{ill}} and I specify only |ceb=, but then later an article is created at the Finnish wiki and connects it on Wikidata, could that be added to the link automatically somehow? Maybe by checking for other sitelinks on the wikidata entry? If the interwiki links update on every article's sidebar, couldn't that happen for this template? --Nessie (talk) 19:47, 6 November 2019 (UTC)

That would lead to a lot of clutter, if there are multiple other wikis that have an article. I think it makes more sense to pick one, possibly two but not many, where there is a decent article on the topic. Nikkimaria (talk) 01:55, 7 November 2019 (UTC)

Agreed; automatically linking to every language article could potentially lead to dozens of links being added, and I can see at most five links being useful; after that it's just clutter. Primefac (talk) 02:32, 7 November 2019 (UTC)

@Nikkimaria and Primefac: Are there many articles using {{Ill}} that have ‘dozens’ of interwiki links and no enwiki link? Also a cap could be put on, to limit it to say 4 links. --Nessie (talk) 03:28, 7 November 2019 (UTC)

Hmm, I'm wondering what kind of articles would not exist at English WP but exist at multiple other language wikis? I find in most cases that articles not existing here may be created at one or two other wikis, usually based on the subject's nationality, as in a French actress mostly notable in France. Enwiki is the most robust of the lot, I can't imagine there are many articles on books or people that have been created in more than two languages but not in English.— TAnthony^Talk 03:35, 7 November 2019 (UTC)

I will admit, I was being slightly hyperbolic, as by the time you got to more than 3-4 cross-language links it would be likely that one would exist in enwiki. We used to have a tracking category that listed how many outgoing links were listed, but it was removed. In truth, I don't think I've ever seen more than 5 links via this template.

In thinking it over, I agree that it would be fairly easy to set a cap on how many WD-provided links are used. My only question, though, is the usual one with regards to WD: how will these links be vetted? Goodness knows we get enough terrible articles on enwiki; maybe we don't want a link to the one-sentence BLP-violating article on Jeremy Hillary Boob PhD from the xyz-wiki. In other words, if an editor links it one can assume that it's a halfway-decent article; doing so automatically guarantees nothing. Primefac (talk) 11:32, 7 November 2019 (UTC)

@TAnthony and NessieVL: I'm getting timeouts when trying to expand or alter the query atm, but this sample shows over 1000 instances of a Canadian subject with sitelinks to at least 3 other wikis and none on English. I'd expect similar results, if not more since Canada is largely English-speaking, for subjects from other countries. Nikkimaria (talk) 12:46, 7 November 2019 (UTC)

• Oppose I am strongly against any automated links via Wikidata. Other language wikis do not have the same number of editors, and often do not succeed in upholding core policies, including BLP requirements. Futher, there are few editors at Wikidata, and little or no oversight of added links. In areas in which I edit, many Wikidata items have incorrect or inappropriate inter-wiki links. Editors adding links take responsibility for doing so. Automating via Wikidata means no-one takes responsibility. Peter coxhead (talk) 15:35, 7 November 2019 (UTC)
• Oppose as per Peter. Even the present system is confusing for casual readers, it's not clear intuitively what the red and cryptic blue letters mean. Would a Japanese student know that "[es]" is a link to the Spanish WP, or even more confusingly "[uk]" is Ukrainian? Martin of Sheffield (talk) 10:00, 14 November 2019 (UTC)
  • See List of ISO 639-1 codes. Tooltips showing the (English) name of the language may be helpful for people unwilling to familiarize themselves with these codes, but they would obscure the default tooltip of each page's article's foreign-language title (which may often differ from its future English-language title) if used. ―cobaltcigs 18:16, 29 February 2020 (UTC)
• Wholeheartedly support if technically feasible. This would save a lot of hunting and pecking, especially for pages in languages using non-Latin scripts (which tend to be under-represented in the current system, simply because they're harder to manually search for). ―cobaltcigs 18:16, 29 February 2020 (UTC)

Add hidden tracking categories for uses with multiple interlanguage links

This would allow prioritizing the creation of articles according to demand, e.g. Category:Pages using Template:Interlanguage link with 3 languages (pls adjust phrasing as appropriate). ―cobaltcigs 18:16, 29 February 2020 (UTC)

@Cobaltcigs: Category:Interlanguage link template link number was deleted in September 2019 on account of not serving a purpose. However, it would be possible to restore that category if you think this would be a worthwhile purpose. Jc86035 (talk) 19:01, 29 February 2020 (UTC)

Hmm… I suppose periodic database reports might be more useful, in that the list of titles would correspond to the missing pages, rather than to existing pages that refer to them. You know, because you can't populate a category with red links. The problem would lie in relying on someone to actually generate the reports. ―cobaltcigs 19:14, 29 February 2020 (UTC)

Topics like this:

• Military History Museum (Budapest)

This really does happen. ―cobaltcigs 22:28, 29 February 2020 (UTC)

Implement language code recognition?

It'd be helpful if the template recognized the language codes ("de", "fr", etc.) so it wouldn't matter in which order you type the code and the article's name -> then both {{ill|de|Charlie B. Brown|fr|Charlie B. Brown}} and {{ill|Charlie B. Brown|de|Charlie B. Brown|fr}} would produce the same result. 2001:999:71:4987:5D5B:A034:22F7:9E93 (talk) 20:53, 29 November 2019 (UTC)

I can imagine someone wanting to link to de:fr or fr:de :) —Kusma (t·c) 21:10, 29 November 2019 (UTC)

(OP) When wikilinking to other language, the language code comes first (like this: [[:de:Article]]), which is probably the reason why I always struggle remembering the correct order for this template. Seems I'm not the only one: [1] 85.76.150.65 (talk) 17:41, 30 November 2019 (UTC)

But that is the order the template uses if the English Wikipedia article name is different: For example, in List of members of the 19th Bundestag, there is {{ill|Bernhard Daldrup|de|Bernhard Daldrup (Politiker, 1956)|la|Bernhardus Daldrup}} to join Bernhard Daldrup with de:Bernhard Daldrup (Politiker, 1956) and la:Bernhardus Daldrup. The form {{ill|article name|de}} is just a shortcut if the article titles are the same on both Wikipedias. —Kusma (t·c) 17:53, 30 November 2019 (UTC)

That, I believe, is the reason why it was coded that way initially. The first param is the en-wiki value, followed by (essentially) <lang>|<name> on repeat, which is how we generally link things as mentioned above. Primefac (talk) 19:39, 30 November 2019 (UTC)

A far more robust syntax would be this:

1. Convert the language codes into named parameters.
2. Recognize only two numbered parameters—{{{1}}} the English page title, {{{2}}} the link text—to form the first link like [[{{{1}}}|{{{2|{{{1}}}}}}]].
   • Note: Keeping |lt= as an alias for {{{2}}} will not be feasible because lt means Lithuanian.
3. Use a Lua module to validate, and alphabetically sort, the language codes.
4. Display an error when any parameter name does not correspond to any language code.

Example

input	output
{{ill|Charlie B. Brown (actor)|Charlie B. Brown|de=Charlie B. Brown (Schauspieler)|fr=Charlie B. Brown (acteur)}}	Charlie B. Brown [de, fr]

I believe could write such an overhaul myself in a few hours, if there is sufficient interest. ―cobaltcigs 18:16, 29 February 2020 (UTC)

Please do not change the way parameters are used in this template again. The previous change was extremely disruptive – not again. The proposed syntax will make for extra typing if the subjects have the same name across Wikipedias, which is mostly true for organizations and buildings, and even for most people. Your example below can be written as

{{ill|Robert Ménégoz|ca||de||fr|}}: Robert Ménégoz.

If you feel the syntax you propose is worth having, please implement it in a different template. -- Michael Bednarek (talk) 01:40, 1 March 2020 (UTC)

Question

Hello,
I'm trying to link to the article of the TV show Nulle part ailleurs on French Wikipedia but it is redirected to a different article with the same name (an album) on English Wikipedia; is it possible to force a redlink or directly redirect to French Wikipedia? Thanks. - Myxomatosis57 (talk) 16:44, 18 March 2020 (UTC)

You should use the same approach that has been used at Alex Berger: {{ill|Nulle part ailleurs (TV program)|fr|Nulle part ailleurs|lt=Nulle part ailleurs}} which gives Nulle part ailleurs. In the long run, when such an article will be written on the English Wikipedia, that article should usurp the REDIRECT at Nulle part ailleurs because all incoming links there seem to be for the TV program. -- Michael Bednarek (talk) 01:21, 19 March 2020 (UTC)

Is Template talk:Interlanguage link/Old version/doc where it should be?

I'm finishing up a large cleanup on Category:Template documentation pages, and ran across Template talk:Interlanguage link/Old version/doc as one of only about a half dozen pages out of nearly 31k sitting in the template talk namespace instead of the template namespace. Looking at the page, it looks like there's some history involved, so I have several questions that someone here can answer: 1) does that page need to be saved for any reason? 2) is that the correct place for that page? 3) does it belong in Category:Template documentation pages any more? Thanks for your help in resolving this oddity. VanIsaac_WS^cont 23:11, 3 May 2020 (UTC)

It's the pre-merge /doc for this template; not sure why a) it was saved or b) it got moved to the template talk space. I've G6'd it. Thanks. Primefac (talk) 23:17, 3 May 2020 (UTC)

Does notability matter?

To me, a redlink implies that, sooner or later, an English wikipedia article should be created. What if the subject lacks notability in the Anglophone Wikisphere? Don't create a link at all? Use purple links? Vagabond nanoda (talk) 20:09, 6 April 2020 (UTC)

If a subject is mentioned in an article here, there is obviously some notability. It may not be enough to have an article here, but it may well be. In any case, a link to an article in another Wikipedia at least gives the interested reader a chance to deepen their understanding of the topic. I don't think it does any harm (except in cases where blatantly promotional articles have been created in those other Wikipedias). -- Michael Bednarek (talk) 02:02, 7 April 2020 (UTC)

For a period, on Swedish Wikipedia, there was a template which showed a black linkless text plus the interwiki super-scripted link, intended for things that does exist on a foreign wiki but not notable to have on Swedish wiki. It was removed later. On Swedish Wikipedia, there is a discussion on removing Template Interlanguage link since some find it visually disturbing to have such superscripts in the middle of sentences. For this reason a variant with smaller font for the interlanguage link was created, usable in literature and other areas where people are more sensitive to style. Red links to non-notable things also irritate people. Should English Wikipedia support such variations?--BIL (talk) 15:23, 8 May 2020 (UTC)

Not properly working?

Hello, https://en.wikipedia.org/wiki/Boise_Airport#Passenger has the template written as such : {{ill|Stanley Airport|ceb|Stanley Airport}} but the link given is wrong (refers to another Stanley airport in enwiki?!? whilst it should give https://ceb.wikipedia.org/wiki/Stanley_Airport). --Bouzinac (talk) 19:02, 16 July 2020 (UTC)

More info is at Template:Interlanguage link#Modifying the display, but basically you need to give a different link to trick the template into forcing the interwiki display. I've updated the link and it's working as intended. Primefac (talk) 21:23, 16 July 2020 (UTC)

Foreign WP-article as author-link parameter in citation

Is it possible? As example, at Günter Bechly there is a cite written by Ernst Probst, is it possible to author-link that somehow? The publisher also has a German WP-article. Gråbergs Gråa Sång (talk) 12:49, 30 July 2020 (UTC)

Not with standard citation templates. They disallow the use of {{ill}} in |authorlink=. A workaround is not to use them, and write the citation manually; then that template can of course be used. -- Michael Bednarek (talk) 13:21, 30 July 2020 (UTC)

Thank you, that was about what I was expecting. Gråbergs Gråa Sång (talk) 13:26, 30 July 2020 (UTC)

Why doesn't this work?

Why does this work

Hooglede town hall

and this not work, displaying "Trève" instead of "trèves"?

Trève

I'm sure it's simple, I just need another pair of eyes. Maproom (talk) 10:24, 6 August 2020 (UTC)

You might not be reading the documentation correctly. In the second case it is linking to Trève here and to fr:trèves at the French Wikipedia. Johnuniq (talk) 10:37, 6 August 2020 (UTC)

fr:Trèves is a disambiguation page; which Trèves do you want to link to? Or do you mean fr:Trève? -- Michael Bednarek (talk) 11:00, 6 August 2020 (UTC)

I want to link to fr:Trève, but to have the result appear lower-case and plural. I could do it like this: trèves. But I thought that the use of interlanguge links was encouraged, and the :fr: stuff deprecated. Maproom (talk) 11:22, 6 August 2020 (UTC)

It's simple, first parameter the name you want in English, second para the two-letter language code, third para name in that language (only needed if different from name in English), and then comes what you need when it should show differently from name in English, |lt= (short for link text, so here ill Trève fr lt=trèves, trèves.

Just insert "lt=" before the name to be shown. All this should be in he documentation. --Gerda Arendt (talk) 11:31, 6 August 2020 (UTC)

Ok, I see one of my mistakes now, I had "Trève" and "trèves" the wrong way round. Let's try these trèves, Trève, trèves. No, none of them works. I'll stick with trèves. Maproom (talk) 11:47, 6 August 2020 (UTC)

Don't know. First and most important question: what should the English article name be, Trèves (WHAT)? It needs some dab, somthing in brackets describing what this meaning is. Or an English word. I don't speak French, sorry. --Gerda Arendt (talk) 11:54, 6 August 2020 (UTC)

You can force the link with |display=1, so {{ill|trèves|fr|Trève|display=1}} becomes trèves. Primefac (talk) 12:29, 6 August 2020 (UTC)

Expensive parser function

Pages like List of villages in Rivne Oblast (as of 22:45, 25 September 2019 ) that call this many times may exceed Wikipedia's limit of 500 "expensive parser functions."

For example, the call to {{ill|Vychivka|uk|Вичівка}} will count as one "expensive parser function."

I don't know WHY this works, but I have determined that changing the lines to {{ill|Vychivka{{!}}Vychivka|uk|Вичівка}} by simply adding {{!}} followed by a repetition of the name of the English-language page will eliminate the expensive parser function.

However, there may be good reasons NOT to do this, besides the obvious one of it being confusing to editors, causing many to say "This looks redundant, let me take out the {{!}}..." and unintentionally "un-fixing" the problem.

Anyone have any ideas on ways to cut down on the number of expensive parser function calls? Anyone understand this template well enough to add "if you call this template this way ... you will cost one 'expensive parser function' call, consider doing it this way ... instead" to the documentation page?

I also added {{expensive}} to the template's documentation page. davidwr/(talk)/(contribs) 17:59, 14 August 2020 (UTC)

The correct way to handle this is by painfully fixing the links. Some links will now exist as articles at enwiki, so the {{ill}} can be replaced with a normal wikilink. Some links might not exist at enwiki or ukwiki, so {{ill}} could be replaced with no link. A gigantic example of the former is explained here. I asked why your trick works here. Johnuniq (talk) 00:17, 15 August 2020 (UTC)

For the record, I'll note that the answer from Jackmcbarn was that #ifexist starts by noting that its parameter contains a character ("|") that is not valid in a title, so it returns false without bothering to check if the page exists. Johnuniq (talk) 23:55, 15 August 2020 (UTC)

Edit request to reduce expensive parser function calls

Please review and add this Sandbox diff to the template.

The goal is to eliminate the expensive parser function calls to #ifexists and the expensive call within #invoke:redirect|isRedirect in situations where we know we don't care, namely, when |display= or |preserve= are set to any value.

Primary use case: In "list-type" articles, there is already an advantage to using |display=1 (or any non-blank value) to preserve the inter-wiki links for pages that have an article in the English Wikipedia. These same types of articles are the type that are likely to exceed Wikipedia's 500-limit for expensive parser function calls. The "driving example" is List of villages in Rivne Oblast (discussion).

I've updated the testcases for this template. Here is a version that shows that, with the change, there are no expensive parser function calls with |display=1 or |preserve=1.

Additional testing of the underlying change can be found at my sandbox as of 20:18 15 August 2020 and the testcases for it at my sandbox2 as of 17:20 15 August 2020.

Once this is done, please "ping" me and I will update List of villages in Rivne Oblast. davidwr/(talk)/(contribs) 20:53, 15 August 2020 (UTC)

@Jackmcbarn: Would you mind having a look at this request. Johnuniq (talk) 23:51, 15 August 2020 (UTC)

 Done Yep, that's exactly what was needed to properly fix this. (By the way, this template is crying to be converted to Lua. I might do that at some point now that I see what a mess it is.) Jackmcbarn (talk) 00:33, 16 August 2020 (UTC)

Thank you. I've updated List of villages in Rivne Oblast. It no longer "breaks the Wiki." davidwr/(talk)/(contribs) 01:18, 16 August 2020 (UTC)

Related user script

See also: Template talk:Interlanguage link/Archive 3 § Automating this template with WikiData?

I've developed a script which finds red link titles on the page the user is editing, searches for them on wikidata, prompts the user to choose the correct wikidata item (if any), then changes each red link to an instance of {{ill}}, populated with interlanguage prefixes/titles fetched from the selected wikidata item. Testing/feedback is welcome. ―cobaltcigs 09:41, 3 October 2020 (UTC)

How to initiate the script? I have just add it to my common.js and Bypassed my cache, but nothing happened.Jklamo (talk) 23:08, 5 October 2020 (UTC)

While editing a page you should see a new tab titled "ill", clicking on which should display a table of links in place of the editing textbox. If using the vector skin (never recommended), this may be hidden in the "more" menu. ―cobaltcigs 00:29, 9 October 2020 (UTC)

Cewbot cleaning out ill links

You might be interested in the following discussion:

User talk:Kanashimi#Task 1 Convert interlanguage link templates with local article to wikilinks

CapnZapp (talk) 11:32, 25 October 2020 (UTC)

Improve syntax

Could the syntax be improved so that the sitelinks on Wikidata are used to provide the correct links? In other words

{{Interlanguage link|WD=Q3588672|es|fr}}

would produce Émile Morlaix preferably with the link to Émile Morlaix (Q3588672) too? — Martin (MSGJ · talk) 13:03, 8 October 2020 (UTC)

Gotta look into the code for a second, but the coded text above gives es. With {{Interlanguage link|Émile Morlaix|es|fr|WD=Q3588672}} you get Émile Morlaix. Primefac (talk) 18:24, 8 October 2020 (UTC)

Okay, looked at the code, and the archives, and I feel like the primary purpose of the WD links was if there weren't other languages (which I somewhat mangle in this discussion but I can't find what I was looking for). Basically, I would think that if there are 1-2 links to other languages, we don't really need to have a link to WD in addition to that.

So... to answer the original question, yes it can be done. To ask a follow-up question, do we want this to be done? Primefac (talk) 18:50, 8 October 2020 (UTC)

Existing behavior should remain unchanged, but the new behavior would be desirable as well. I recommend adding a new parameter |WDget= with values of |WDget=basic which would be the same as no WDget parameter at all i.e. the current behavior, |WDget=wikipedias which would show all of the Wikipedia language links in the same order they are in WikiData, and |WDget=both which would do both.

The end result would look something like this: {{Interlanguage link|Émile Morlaix|WD=Q3588672|WDget=both}} -> Émile Morlaix [Wikidata; es; fr]. davidwr/(talk)/(contribs) 20:14, 8 October 2020 (UTC)

That was previously discussed (see the discussion I linked above), and it was decided not to import WikiData information directly. Primefac (talk) 20:31, 8 October 2020 (UTC)

Proposal - a separate, always-subst'd template that generated a list of parameters based on what is in WikiData at the moment it is used. For |1=Q3588672 this new template would generate es|Émile Morlaix|fr|Émile Morlaix. This way, I could just do

{{Interlanguage link |Émile Morlaix |{{subst:newtemplatenamegoeshere |Q3588672}}}}

and know that the current list from WikiData would be imported, but that it would be immune from being hijacked by future WikiData edits. As an alternative to the Q entry, this new template should allow the name of an English or other-language Wikipedia entry that actually exists, such as

{{Interlanguage link |Émile Morlaix |{{subst:newtemplatenamegoeshere |es:Émile Morlaix}}}}

davidwr/(talk)/(contribs) 20:55, 8 October 2020 (UTC)

This has the potential, which was discussed in the previous discussion, to result in a dozen different interwikis being linked. I'm not strictly opposed to this idea, but I feel like it's going to be way more hassle than it's worth, just for the minor benefit of catching random languages like vi or sr. Primefac (talk) 21:14, 8 October 2020 (UTC)

Back to the original proposal: How about if the template uses a "snapshot in time" version of WikiData, so

{{Interlanguage link|WD=Q3588672|es|fr|UseWD=1}}

self-substitutes and renders as

{{Interlanguage link|es|Émile Morlaix|fr|Émile Morlaix}}

This would make it much easier on all editors, as they wouldn't have to look up the page name, but it would not have the problems of "a bunch of language links" or the problem of the language link changing out from under them if someone vandalized WikiData. Editors would need to be reminded to check their edit though, just to be sure WikiData wasn't vandalized 0.1 seconds before the editor published the edit on the English Wikipedia.

If self-substitution is too hard, maybe a new template called {{interlanguage link2}} can be written which MUST be substituted, resulting in a conventional use of the current {{interlanguage link}}.

For situations where there is already an English-language page and the non-English version is desired as well (e.g. with redirects or when |display= or |preserve= are used), the |WD= parameter would be optional, if it is missing, the English page name would be used to get the WikiData entry. davidwr/(talk)/(contribs) 22:03, 8 October 2020 (UTC)

I'd like to see the above-described functionality added, but have no faith in that ever happening. That's why I created a user script to expedite the otherwise tedious process of searching wikidata.org for a title, identifying the correct wikidata item from potentially numerous choices, collecting the foreign-language prefixes and titles from that Q-number page, populating these into an {{ill}} template call, and inserting that code in place of a regular red link. All without opening a dozen tabs or displacing something important from your system clipboard. See previous section.

This is, of course, an imperfect workaround because unlike a "live" Q-number lookup, it will not update itself when new language entries are added. Such updates would be a suitable bot task, once the initial (and necessarily human) identification of the correct item has been done.

Note that "showing too many language links" after a red link isn't a problem in itself; it's just a rather embarrassing symptom of allowing enwiki to fall behind that many other-language wikis. In the credits of foreign film stubs, I commonly find red links on enwiki where 4–5 other wikis have a bio. Such omissions really should be made as glaring as possible, to encourage somebody fluent in one of these languages to translate at least a stub for us locally. That is, by far, the most constructive way to make a ghastly list of language codes go away.

De-linking to plain text is the absolute worst, but (frustratingly) some users do that too.

―cobaltcigs 20:21, 25 October 2020 (UTC)

Template:Wikidata red link

{{Wikidata red link}} is a fairly new template with similar functionality with respect to Wikidata. It doesn't have the inter-lanaguage linking that that {{interlanguage link}} has, but there is enough overlap that a merger should be considered.

If nothing else, when and if either template is rewritten as a module, that might be a good time to "do the merger." davidwr/(talk)/(contribs) 22:56, 25 October 2020 (UTC)

Category

It took me a while to find this template. I knew I had seen it in use bout could not find it. Should it be in Category:Language templates? --Error (talk) 13:13, 18 November 2020 (UTC)

Forcing redlink on redirect pages

Is there a way to add an option that makes the English link redlinked (and preferably wrapped in Template:No redirect) if the article on English Wikipedia is a redirect? The main use case for this when trying to avoid circular redirects. Jumpytoo Talk 03:13, 30 August 2020 (UTC)

• In a word, no. If it is a redlink, it will show as a redlink. If it's a redirect, it will show as a normal link (unless you have a link classifier, so for example mine shows up green). But, remember that if it is a redirect it will still show the interwiki links, indicating that it is a redirect. Primefac (talk) 12:09, 30 August 2020 (UTC)
  • @Primefac: I've also got a similar issue at Hololive Production#Talents. Where ILL is used, some are red and some are blue, but every blue link is a circular redirect. This makes it quite counterintuitive, especially when there is one list entry (Hoshimachi Suisei) where an article does exist in English. Is there any way to make this template surpress linking only when it's circular? ◢  Ganbaruby!  (Say hi!) 16:36, 25 October 2020 (UTC)
    • You can't force a literal red-link unless you add some sort of disambiguator. In other words, if you don't want Sakura Miko to be blue, then change it to something like Sakura Miko (note it's linking to Sakura Miko (VTuber)). The downside, of course, is that you end up with an unnecessary dab and thus won't know if/when the actual Sakura Miko page has been created. Primefac (talk) 17:03, 25 October 2020 (UTC)

• @Ganbaruby: As Primefac said, you can't make the link red, but you can do the next best thing - turn it black or suppress the redirect. I gave it a go and it's harder than it looks unless you want to have yet another expensive parser function call. Here are several approaches to take. Each involves having a new parameter |suppressredirects=. In each case, change the code so if "suppressredirects" is set, do the following:

• Rewrite it as a module or module-based template. This may be the best approach.
• Re-factor it so the check for {{#ifexist:{{{1|}}}|{{#invoke:redirect|isRedirect|{{{1|}}}}}|1}}}} happens earlier and it "wraps" the rest of the logic. Note that this code returns "1" if the page |1= does not exist, "yes" if it is redirect, and nothing if it is a non-redirect page. I looked at this option and it's pretty involved, more than I can do in an hour. I think it will also result in duplicate code, which makes maintenance a problem.
• Bite the "expensive parser function" bullet and do that check twice, once where it's currently being checked, and once earlier, before where the en-wiki link is printed. Something like this might work (NOT TESTED!): {{#if:{{{suppressredirects|}}}| code to check for a redirect and if it is one, make the link look like we want }} existing code to display the link {{#if:{{{suppressredirects|}}}| more code check for a redirect and if it is one, make the link look like we want }}. This would be at least two expensive parser functions. To save on an expensive parser function call, I recommend using this in conjunction with |display= and possibly modifying the code above.

In any of these cases, my recommendation would be to surround the en-wiki link with {{noredirect|...}} if - and only if - the file exists.

As I am writing this, I have an idea but I need to wait until later today to try it out. If it works, you will be able to do what you want without any additional expensive parser function calls or duplicate code. davidwr/(talk)/(contribs) 18:19, 25 October 2020 (UTC)

• @Ganbaruby: I put some alpha-state code in the sandbox, it implements |suppressredirect= which will wrap links with {{noredirect|{{{1}}}|{{{lt}}}}}. |lt= is optional. It's not "red" but at least it keeps the circular redirects at bay. I did notice that Module:redirect has a way of determining the target of the redirect. This means in principle, you could write a version that would check to see if the target was the current page and if so, do something special. Temporary documentation including a to-do list are in html comments at the top. Parser profile test results are in an older edit, clearly labeled in the edit history. I've also added half a dozen testcases.

TO DO LIST: (any volunteers?)

• Have someone who knows safesubst: go through and add it where needed and check it where it's already there.
• Have another experienced template editor review the new code closely, both for errors and opportunities to make it more efficient.

davidwr/(talk)/(contribs) 21:17, 25 October 2020 (UTC)

• @Jumpytoo: I changed the sandbox code so I think it meets your needs. I took out the just-added support for |suppressredirect= and replaced it with a new parameter, |useredirect=. If you use it, the target of the redirect will be the wikilink. You can still "mask" it with the existing parameter |lt=. I'm going to add another parameter called |maskredirect= which, if set, will cause |1= to be used as the "wikilink mask" if |lt= is not set. davidwr/(talk)/(contribs) 00:31, 26 October 2020 (UTC)

Thanks, I've played around with it and I'm not sure how to achieve the red/no redirect effect with the new params. Is there an example you can show? Jumpytoo Talk 01:34, 26 October 2020 (UTC)

• @Jumpytoo and Ganbaruby: Template:Interlanguage link/sandbox is "stable" (permalink) at least I don't PLAN on making changes to it for the next 10 hours at least, it's got preliminary documentation in html comments at the top. I made this test revision, since reverted, of Hololive Productions. You can see in the collapsed tables in the "Talents" section that redirects are in bold black, but still show the name used by the editor. This is done by a combination of the new |useredirect=1 and |maskredirect=1 parameters.

This change is not ready to be merged yet. Besides getting agreement if this functionality is wanted, there is a technical TO DO LIST:

• Make sure it can be safely substituted. I am not experienced in this area so I didn't try hard to get it right.
• Have a code review by someone experienced with templates. I've been mistake-prone today so to be blunt, I don't trust my own work today.
• Make sure when the new parameters are NOT used, the parser profiling usage is about the same as the existing version. In other words, no surprised with template post expansion include size, parser function count, etc. etc.

davidwr/(talk)/(contribs) 02:04, 26 October 2020 (UTC)

@Jumpytoo and Ganbaruby: Do either of you want this enough to go forward with adding |useredirect=1 and |maskredirect=1? If not, I'll drop it as "not needed now, let's keep things the way they are until there is a need."

@all: If either of them answer yes, I need one or more volunteers who knows how to make substitution safe to proofread this and fix it up. Once it's been fixed and checked, we can go live, but only if there is a current need for this. davidwr/(talk)/(contribs) 23:01, 26 October 2020 (UTC)

I am still supportive of this feature. While I am fine with the feature as is, looking into if it's possible to add CSS + no-redirect link would be appreciated. Also, is there a use case for only using one of the params and not the other? Jumpytoo Talk 01:27, 27 October 2020 (UTC)

@Davidwr: Thanks for the hard work. I like it! Couple things: in an instance of a circular redirect, is there any way for the link to not be bolded when useredirect is set? Also, is there any reason why someone would have useredirect but not maskredirect? ◢  Ganbaruby!  (Say hi!) 11:38, 27 October 2020 (UTC)

@Jumpytoo and Ganbaruby: Wikimedia software turns a link to the current page into a non-clickable bold link: [[Template talk:Interlanguage link|Template talk:ill]] renders as Template talk:ill. There is a "cheat" which is to replace the link with the URL version, something like [{{canonicalurl:Template talk:Interlanguage link}} Template talk:ill}}] renders as Template talk:ill. As for use cases, there are use cases for just useredirect without maskredirect but on reflection, they are probably uncommon. It might be worth "reversing the logic" so |maskredirect= is replaced with |exposeredirect=, so by default |1= is what the person sees by default when |useredirect= is used. Thoughts? davidwr/(talk)/(contribs) 12:57, 27 October 2020 (UTC)

@Davidwr: I read the above discussion and tried out the new parameters, but I am still confused.

In the specific case of Tokino Sora at Hololive Production#Talents, is there a way to make the display look exactly like Tokino Sora [ja] (with a non-clickable, non-bold display)? I think Tokino Sora [ja] is an undesirable result, and would like to avoid it unless there is a technical/intentional reason against it. — Goszei (talk) 22:02, 20 November 2020 (UTC)

@Goszei: The bold comes from the fact that the wikilink is actually to the current page. That is, Tokino Sora redirects to Hololive Production. If you want "no bold, no click, no color" behavior, the sandboxed version will need to be changed to specifically check to see if the redirect target is the current page, then NOT put in a wikilink. That could get complicated, but it's certainly do-able. davidwr/(talk)/(contribs) 22:12, 20 November 2020 (UTC)

@Davidwr: I personally support such a feature. — Goszei (talk) 22:16, 20 November 2020 (UTC)

If you don't want a link, don't put a link, just put a {{small|{{bracket|[[ja:ときのそら|ja]]}}}} after the name, which will give you your [ja]. Primefac (talk) 22:19, 20 November 2020 (UTC)

Courtesy ping to @Kanashimi: The changes being discussed above will not be "breaking changes" (well, not if done properly), so they should not affect Cewbot, but you might want to at least skim the discussion and see the html comments at the top of the sandbox. If you see any potential problems, please jump in so we don't break anything. davidwr/(talk)/(contribs) 22:47, 20 November 2020 (UTC)

Thank you for reminding. It is OK, the bot only parse the parameters and will not care the CSS or HTML codes. --Kanashimi (talk) 23:53, 20 November 2020 (UTC)

Use CSS?

You could give this template a TemplateStyle (CSS) subpage containing a.mw-redirect { color: WHATEVER; }. But this rule will actually "leak out" and affect other ("normal") redirects elsewhere on the page where the template is used (I just tested this on a localhost wiki). That can be avoided by wrapping the entire template output in something like <span class="ill">...</span> and using more specific CSS like span.ill a.mw-redirect { color: whatever; } to only affect redirect links inside such a span.

Note that any color selection here will probably annoy users who've added their own CSS and therefore expect all redirects to be the same color of their own choosing, regardless of whether they're formed [[Like this]] or {{ill|Like this|es|Como esto}}. Such users would need to opt out by adding another line in their CSS to override this new (more specific) rule to also use color they like, or by adding !important to their existing (less specific) rule. This should be explained in the docs if we do it.

The above caveats aside, perhaps some shade of purple would make the most sense? ―cobaltcigs 11:15, 26 October 2020 (UTC)

Suppressing the enwiki link

Am I mistaken, or is there currently no option to suppress the link on enwiki? This would be useful in cases like Flappy Bird: Dong Nguyen (see infobox) is ill'd to viwiki, but the enwiki link is a redirect that loops back to Flappy Bird, creating a WP:CIRCULAR. IceWelder [✉] 22:59, 12 December 2020 (UTC)

There 2 obvious solutions: write a proper article at Dong Nguyen, or invent a disambiguator, say "(game designer)": {{ill|Dong Nguyen (game designer)|vi|Nguyễn Hà Đông|lt=Dong Nguyen}} -> Dong Nguyen. Or it could be left as is because it still provides the link to vi WP. -- Michael Bednarek (talk) 01:42, 13 December 2020 (UTC)

@IceWelder: Look up above to #Forcing redlink on redirect pages. Here's what the sandbox with the new parameters |useredirect=1 |maskredirect=1 does for Flappy Bird: demo

I never finished the changes because 1) the discussion fizzled out and 2) I'm not well-versed in safesubst: so I'm not willing to stand behind this. Here's the diff of the sandbox and the template as of a minute or so ago: diff

If this does what you want, we can re-start the conversation from October and get this reviewed by someone familiar with safesubst: then implemented. davidwr/(talk)/(contribs) 🎄 06:07, 13 December 2020 (UTC)

• @Davidwr: That definitely goes in the right direction and is not so much a workaround. I tested the edit you made to Flappy Bird again, and I saw that the name was automatically bolded. I was unable to disable the bold with |nobold=, which might be a bug. However, I'm wondering whether it be easier to just have a param like {{{nolink}}} that disables the link altogether. This would be a quickfix for all cases like redirects and unwanted redlinks (for WP:RED violations). IceWelder [✉] 11:23, 13 December 2020 (UTC)

• @IceWelder: The "bold" is a feature. because the actual link is to the page in question, for example [[Template talk:Interlanguage link]] renders as Template talk:Interlanguage link, a bold un-clickable would-be-a-blue-link-if-this-page-is-ever-moved "link." On the other hand, {{plain text|[[Template talk:Interlanguage link]]}} renders as Template talk:Interlanguage link.

As for your proposed |nolink= parameter: That's another reason I didn't move forward, there wasn't any clarity on whether the code I wrote was the best way to meet the needs of those who had the issue that was raised in October.

Do you have the skills to fix up any safesubst: issues in the sandbox? If you do, it should be easy take a fixed-up version and add |nolink=, which could just add a {{plain text}} wrapper to the English link when |nolink=1 or even a |noboldselflink=1 parameter that would turn off bolding if it were a "self-link" but otherwise do leave it alone. This is starting to get complicated though, so it's best to decide what is really needed before "making improvements just for the sake of making improvements." This is after all a protected template, which implies a higher cost if things go south. It also suggests that for the sake of future maintenance, simpler is better.

Another thing I do want to be careful about is the effect on the template WP:PEIS limit. This template is used in some large lists of non-English geographical locations. I added {{display}} a few months ago to get around the 500 expensive parser limit issue that affects these articles, I don't want to create a new problem. davidwr/(talk)/(contribs) 🎄 15:05, 13 December 2020 (UTC)

I might look into it later. Maybe converting the template to a Lua module could also fix this. IceWelder [✉] 08:29, 14 December 2020 (UTC)

Equal sign

Does the equal sign in an article title break this template? I'm trying to do

{{ill|Konaka = Pehlwan|ja|小仲＝ペールワン}}

and I get this: ja. The article in question is Umemura PC Juku Copy & Paste Championship

If this is the case, what is the workaround? Or is there an error I made that I missed?

Thanks, Oiyarbepsy (talk) 09:47, 2 January 2021 (UTC)

@Oiyarbepsy: try Konaka = Pehlwan, which works, but where did you get the idea for an English Wikipedia article with an equal sign in it? That seems pretty non-standard. Mathglot (talk) 10:26, 2 January 2021 (UTC)

Not my article, but this is the wrestler's actual name (you'll see the equal sign is also in the Japanese name). Oiyarbepsy (talk) 22:25, 2 January 2021 (UTC)

For reference, Mathglot is using {{=}} in the template call instead of just =. Primefac (talk) 13:15, 2 January 2021 (UTC)

@Mathglot:@Primefac: Thank you very much. Oiyarbepsy (talk) 22:25, 2 January 2021 (UTC)

@Oiyarbepsy: I know this deviates from the question, but I don't think that full-width equals sign should be transliterated as an ASCII equals sign. The Japanese writing system already has the chōonpu, which looks like a hyphen, so traditionally a double hyphen is used to join two names. Unicode now has a code point for the Japanese double hyphen, but this is scarcely used or made compatible because pre-Unicode encodings for Japanese didn't encode a separate full-width equals signs and a double hyphen. This is why Japanese Wikipedia substitutes the full-width equals sign for the double hyphen, as recommended here, which gives the example クロード・レヴィ＝ストロース for "Claude Lévi-Strauss". So the correct way to spell 小仲＝ペールワン in Latin-based text is most likely "Konaka-Pehlwan". Nardog (talk) 08:44, 13 January 2021 (UTC)

Thank you, Nardog, I have revised the link accordingly. The Japanese writing system is certifiably insane. Oiyarbepsy (talk) 09:03, 13 January 2021 (UTC)

Um, Oiyarbepsy, I think I know what you meant, but can you strike your last sentence or tone it down, please? See WP:REDACT if you're not sure how to do this. Mathglot (talk) 21:16, 13 January 2021 (UTC)

Task 1 Convert interlanguage link templates with local article to wikilinks (again)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Apologies for any confusion, but the preceding talk section (now resolved) discussed a different matter than what I brought up at

User talk:Kanashimi/Archive 1#Task 1 Convert interlanguage link templates with local article to wikilinks

and then at

Wikipedia:Bots/Noticeboard#Should Cewbot remove interlanguage link templates once local articles exist?

Please respond either there or here. Cheers CapnZapp (talk) 14:55, 13 January 2021 (UTC)

(Inviting editors to splinter a discussion is bad practice.) I regularly edit articles with {{ill}} links and create them often. They can be sometimes elaborate in order to deal with foreign scripts or naming conventions (Hungarian), so the resulting Wikitext often looks frightening. Therefore, removing those constructs once local articles exists is a welcome cleanup task. Can anyone provide an example of an {{ill}}-linked article that was converted to a local link and the article was then deleted? -- Michael Bednarek (talk) 01:25, 14 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Redirect red link?

I'm using this template to link to sv:Aska, Motala kommun—that is, the town of Aska, in Motala Municipality. The corresponding article in English, however, would have a different name, something like Aska, Sweden. Is there a way to use the {{ill}} template to have an end result that displays as "Aska [sv]" (redlink goes to Aska, Sweden), rather than as "Aska [sv]" (redlink goes to Aska, Motala kommun)? Thanks, --Usernameunique (talk) 07:21, 23 January 2021 (UTC)

@Usernameunique: Your redlinks go to the opposite of what you say but I think you want Aska. See Template:Interlanguage link#Displaying different text. PrimeHunter (talk) 08:00, 23 January 2021 (UTC)

Thanks, PrimeHunter, that's exactly what I was hoping to do. I had seen that section, but not appreciated that it could be used to change the direction of the redlink in addition to its display (that is, I was currently stuck at Aska). And you're right about my redlinks going to the opposite of what I said—I've edited it above. --Usernameunique (talk) 08:22, 23 January 2021 (UTC)

Remove link parameter?

Can we add a parameter to de-link the page in en.wiki (keeping the foreign wiki link)? So something like "2018–19 [it]", instead of "2018–19". Nehme₁₄₉₉ (talk) 17:10, 19 February 2021 (UTC)

I feel like this has been discussed before, with "no" being the answer. If the page shouldn't be linked on Wikipedia, then we shouldn't be using this template. Primefac (talk) 23:18, 4 March 2021 (UTC)

There might be a technical reason for suppressing the enwiki link, such as it being a redirect to the same page. IceWelder [✉] 00:31, 5 March 2021 (UTC)

In that case it shows as a link with the interwikis, indicating that it's not "really" an article. Primefac (talk) 02:18, 5 March 2021 (UTC)

@Nehme1499:, there's a pretty good workaround that does what you want to do. You can just code this:

• 2018–19{{ill|2018–19|it|Campionato Primavera 1 2018-2019|lt={{thinspace}}}}, to get:
• 2018–19 

Does that work for you? Or maybe simpler, just roll your own:

• 2018-19{{thin space}}[[[:it:Campionato Primavera 1 2018-2019|it]]]
• 2018-19 [it]

Hope this helps. Mathglot (talk) 08:57, 26 March 2021 (UTC)

@Mathglot: Very nice workaround: thanks! Nehme₁₄₉₉ 14:34, 26 March 2021 (UTC)

Draft param

Looking for feedback. I was thinking of adding a yes/no "draft" parameter. If |draft=yes, then if a draft exists in English for the article named in arg 1, then add a bracketed draft indicator. This would entail one expensive parser function call. Also, if draft=yes, standard detection would be used to generate an error if used in mainspace, as we don't want links to drafts from there. This could be useful, especially in lists of articles being contemplated for creation, we'd want to know if a draft exists. Naturally, that should be checked anyway; but having the link would be a convenience. This would be backward-compatible, and shouldn't have any effect on existing invocations.

Proposed example:

• {{ill|French Research Centre of the Arabian Peninsula|fr|Centre français de recherche de la péninsule Arabique|draft=yes|valign=sup}}, would generate:
• French Research Centre of the Arabian Peninsula ^[draft][fr]

If no draft exists, it would not produce the link. Example of a page where this would be useful: this list of missing articles about women in en-wiki. Thanks, Mathglot (talk) 09:49, 26 March 2021 (UTC)

no change of code is needed for that:

• {{ill|French Research Centre of the Arabian Peninsula|fr|Centre français de recherche de la péninsule Arabique|draft}}

→ French Research Centre of the Arabian Peninsula

Or, if you like the "draft" link before the French Wikipedia one:

• {{ill|French Research Centre of the Arabian Peninsula|draft|French Research Centre of the Arabian Peninsula|fr|Centre français de recherche de la péninsule Arabique}}

→ French Research Centre of the Arabian Peninsula

But no, even though it is actually an existing feature, it should not generally be used (I mean: in mainspace): we'd try to avoid such links from mainspace to draftspace (also: when the draft would not, or no longer, exist, without there being an article, or with only a redirect, in mainspace that would leave a quite undesirable redlink in mainspace, e.g. French Research Centre of the Arabian Peninsula). --Francis Schonken (talk) 10:10, 26 March 2021 (UTC)

@Francis Schonken: Oh, it must be a while since I've read the code, or it's changed a great deal since then! Well, if it already exists, then we simply need to add the namespace check to exclude it linking from mainspace. And one expensive parser function call would eliminate the other undesirable effect. I'll get to it at some point (not soon) if no one gets there first. Thanks, Mathglot (talk) 21:40, 26 March 2021 (UTC)

(edit conflict) I personally have no issues whatsoever, but I have a vague notion you need to discuss the concept of linking into draft space from main (article) space more widely before going ahead. Cheers CapnZapp (talk) 10:13, 26 March 2021 (UTC)

Thanks, but if you reread the proposal, linking to draft from mainspace is specifically excluded by definition. Although the proposal is moot, given Francis's comments above. Mathglot (talk) 21:43, 26 March 2021 (UTC)

Well, I posted my comment at the same time Francis' posted his (as indicated by the {{ec}} template), so the mootness was unknown to me at the time. As for the draft>>mainspace links I would guess this should be discouraged rather than prevented, based on the fact this is how it is already implemented. In short: maybe you need to do nothing, and you're good to start using the template for your intended usage? Cheers :) CapnZapp (talk) 09:18, 27 March 2021 (UTC)

Suppressing Crewbot conversion

Resolved

 – The existing parameter |preserve=, alias |display=, deactivates the conversion bot. davidwr/(talk)/(contribs) 02:47, 13 January 2021 (UTC)

Unresolved

 – Seems like discussion is ongoing still. Mathglot (talk) 21:34, 13 January 2021 (UTC)

I want to continue this conversation from October, User talk:Kanashimi/Archive 1#Task 1 Convert interlanguage link templates with local article to wikilinks.

Since 2016, the bot Cewbot (talk · contribs) runs weekly and converts this template to a regular "blue link" if it exists (approval). In 2016 this was necessary since this template was always "expensive".

As of August 2020 this template is no longer expensive when |display= is set.

This means there is no computational benefit to automatically converting the links. In most but not all cases, there is still a clear editorial benefit.

There are pages where it is desirable to have both the English-language and the non-English link present if there is one, such as Template:Members of the First Legislative Yuan, recently created by Number 57. Why?

• The non-English-language page is likely to have more detail and more up-to-date information, both "right now" and "in the future," and
• If the topic is "marginally notable" on en-wiki, it's more vulnerable to deletion, particularly proposed deletion.

Other articles and templates about "non-English-language" topics are likely to fall into this category.

Proposal: Turn off the bot when |display= is set, and create a new parameter, |bot=on or off, to activate or suppress the bot's action. Why not just put {{nobots}} on the page? Well, we only want to turn off this bot for this situation, not necessarily all calls to {{Interlanguage link}} on the page and we certainly don't want to suppress other "nobot-compliant" bots on that page.

Due to possible post-expansion include size issues, it's probably best if the default for |bot= is "off" when |display= is set.

Courtesy ping to bot-operator Kanashimi so he can follow this discussion. davidwr/(talk)/(contribs) 14:27, 12 January 2021 (UTC)

There's been an (edit conflict) of sorts, so please also see Wikipedia:Bots/Noticeboard#Should Cewbot remove interlanguage link templates once local articles exist? CapnZapp (talk) 15:13, 12 January 2021 (UTC)

Thank you for inviting to participate in the discussion.

1. Still, the task will convert articles existing more than one week. A unqualified article should not persist after such period.
2. Even be deleted after one week, the label should exist in wikidata, there is a task to do this.
3. Everyone may use |preserve=((reason)) to avoid the template to be resolved.

--Kanashimi (talk) 23:28, 12 January 2021 (UTC)

Cewbot's removal of the template is a good thing for reasons outlined, i.a., here. There's already a solution: |preserve=. The Template:Members of the First Legislative Yuan is an abomination. -- Michael Bednarek (talk) 01:05, 13 January 2021 (UTC)

That navbox has been nominated for deletion. Primefac (talk) 11:22, 13 January 2021 (UTC)

@Kanashimi: in the template, |preserve= and |display= do the same thing. Will your bot only ignore if |preserve= is set, or does it also ignore if |display= is set? Either way, I think the "preserve" is the answer I was looking for. davidwr/(talk)/(contribs) 01:27, 13 January 2021 (UTC)

I am sorry that I mistake the parameter name, it should be |preserve=((reason)). And yes, whether the |preserve= or |display= parameter settled, the bot should ignore the template. --Kanashimi (talk) 02:25, 13 January 2021 (UTC)

Thank you. I have marked this "resolved" and updated the documentation. davidwr/(talk)/(contribs) 03:03, 13 January 2021 (UTC)

I'm sorry davidwr but how does this resolve the issue? First question, what problem are you thinking of when you mark it resolved? Perhaps we're discussing different issues? CapnZapp (talk) 12:08, 13 January 2021 (UTC)

My original issue, outlined in the "proposal" above Turn off the bot when |display= is set, and create a new parameter, |bot=on or off, to activate or suppress the bot's action., is not needed since the bot is already turned off when |display= or |preserve= is set to any value. I was not aware of this until I saw the message Kanashimi posted at 02:25, 13 January 2021 above. What problem were you thinking of? davidwr/(talk)/(contribs) 13:35, 13 January 2021 (UTC)

Well, no, you started this section with I want to continue this conversation from October. That section was started by me, with the problem This is highly problematic. If an article is created, but later deleted (perhaps a person article that's deemed not notable enough), the ill link is lost and we have a red link instead. You furthermore linked here from the section I started over at BOTN: Wikipedia:Bots/Noticeboard#Should Cewbot remove interlanguage link templates once local articles exist? Your actions create the impression this problem has been addressed and solved, when in actual fact I see nothing that changes my comment from BOTN: As far as I can see neither this specific proposal not the greater issue got a proper resolution (see that discussion for the proposal mentioned). Meaning I can't understand how the existence of |display= or |reason= helps my case. And of course, the answer is: because you were talking about something else. This time, I'll start a new talk section but please in the future think twice before co-opting existing discussion for your own purposes. Thank you CapnZapp (talk) 14:47, 13 January 2021 (UTC)

I echo CapnZapp's concerns, and I'm not okay with the "resolved" mark; I've added an "unresolved" mark below it. The burden should not be on editors who wish to preserve {{ill}}s to race around the encyclopedia, to prevent damage by the bot by either adding |display= or a bots-deny statement. This should be discussed further. While discussion is going on, I will revert any bot changes that I notice on my watchlist. Mathglot (talk) 21:34, 13 January 2021 (UTC)

Just to remind everyone, the discussion is ongoing over at BOTN: Wikipedia:Bots/Noticeboard#Should Cewbot remove interlanguage link templates once local articles exist? Thanks, CapnZapp (talk) 22:07, 17 January 2021 (UTC)

@Davidwr and Mathglot: This issue was effectively swept under the rug, by editors either outright ignoring the issue or attacking the procedural aspects ("this topic should be discussed elsewhere"). I tried my best (I'm serious: I tried in three different venues!) but could get no traction. Somebody else, better versed in Wikipedia internal politics (how to drag reluctant power editors to the discussion table; how to select which such table to use, and so on) will have to carry the torch. Or, actually, it's probably simpler than that. What's needed is an editor with template editing rights making an edit which editors happy with the illogical status quo would then have to actively revert, and thus present actual arguments for their position. To me, it all boils down to us regular editors being simply ignored; we don't have the editing rights, so nobody has to care what we think. CapnZapp (talk) 09:32, 27 March 2021 (UTC)

Thought

I think this template is a good idea, and used less than it should be. However, the link to the non-eng WP is quite small. Could we make it a little more prominent? Gråbergs Gråa Sång (talk) 13:26, 15 April 2021 (UTC)

The current font size for the link is 85%, the minimum allowed at MOS:FONTSIZE. The links are rather unusual, and some editors have complained that they are distracting, so a smaller size seems preferable for most, including me. -- Michael Bednarek (talk) 14:03, 15 April 2021 (UTC)

Yes, but those editors (probably mostly native en-speakers) are wrong and I am right ;-) Gråbergs Gråa Sång (talk) 14:40, 15 April 2021 (UTC)

SInce this template is actively disliked by a segment of the user base (it's actively hunted down by a bot!), I would avoid doing anything that puts a target on it. Why not instead zoom/enlarge your browser experience? CapnZapp (talk) 07:40, 16 April 2021 (UTC)

Interesting, what does the bot do with them? Or did you mean "Please be aware Cewbot converts [[{{{1}}}]] links to regular (blue) links when it detects the target article has been created on English Wikipedia." I don't see that as a problem. Gråbergs Gråa Sång (talk) 11:17, 16 April 2021 (UTC)

@Gråbergs Gråa Sång and Michael Bednarek: It wouldn't be difficult to add a class to the links so that any user who didn't like them could make them disappear with a simple addition to their common.css (which could be described at the template /doc to facilitate it), but I guess there'd need to be discussion/consensus before we did that. The same solution could make the links more prominent.

Mocked-up example: this is the code generated by an ill invocation as expanded by Special:ExpandTemplates, with the addition of a new class:

Hanning Schröder

This should look identical for you, to the first example here; namely, a red link with a bracketed, blue, de link. However, I cannot see the blue [de] link at all, only the red link, due to a recent change to my common.css. You can change how this example looks for you (bigger, smaller, disappeared) by a similar changes. (Refresh this page after you change your common.css.) Mathglot (talk) 19:27, 27 July 2021 (UTC)

It's a thought, but my understanding (I could be wrong) is that in general, ill-not-likers wants to use [[:de:Hanning Schröder|Hanning Schröder]] (Hanning Schröder) instead since it looks better. Gråbergs Gråa Sång (talk) 19:39, 27 July 2021 (UTC)

@Gråbergs Gråa Sång: That's a much bigger change. I'd be very surprised if people who don't like ill would want in-line blue links directly to a sister project with no warning; for one thing, it violates WP:ASTONISH, and for another, it removes the desirable WP:RED LINK, which has many advantages. I'm highly pro-foreign links, use them all the time, and even I wouldn't opt in for functionality like that. Perhaps you are right, and that's what other ill-not-likers would want; but you'd have to make a case for that separately, and garner some support for it. (Hint: start a new section.)

But it seems like you've switched gears, here: at the top, I thought you were talking solely about a change in font-size of the bracketed foreign links, which is something quite different. If you want to effect real change here, which I think is possible, can we stick to one proposal at a time? Are you still interested in the font-size change proposal, and have you tried the mock-up to see if it satisfies the condition you originally described, or have I perhaps misunderstood what you wanted? Mathglot (talk) 20:17, 27 July 2021 (UTC)

I have no opinion on introducing a class for {{ill}} links, other than it seems a solution to a not widely-perceived (IOW non-existing) problem.

The expansion of an interlanguage link as suggested above is a bad idea for all the reasons Mathglot pointed out. As for the original proposal to increase the font size: see my first comment. -- Michael Bednarek (talk) 01:48, 28 July 2021 (UTC)

Template use within infoboxes and other text-size reducing elements

The 85% size of the link is fine for standard text, but when used in infoboxes it combines to reduce text to below the recommended minimum for accessibility. As such the template seems unsuitable for use within infoboxes. Is there a way around this problem, or would it be possible to create a parameter such as infobox=yes which could be invoked to prevent the link from becoming too small. EdwardUK (talk) 21:14, 3 August 2021 (UTC)

This has been raised befor at Template talk:Interlanguage link/Archive 2#Font size. The problem could easily be avoided if the font size reduction is only applied when used as sup/sub. -- Michael Bednarek (talk) 05:33, 4 August 2021 (UTC)

The standard version should still have the font size reduction as default whether using baseline placement or sup/sub. Changing so that small font is only applied when altered vertical-align is specified would be problematic firstly because only a very small percentage of transclusions currently use it (meaning all other uses would be altered by any change), and secondly as many editors adding new uses of the template would neglect to specify sub/sup thereby not triggering the normal font size reduction. Ideally the change would need to be the other way so that a parameter needed to be intentionally marked to prevent size reduction rather than to cause it.

The earlier discussion suggested change to 100% for all uses, (by simply replacing one number) but to change only when used in infoboxes looked a lot more complicated. My coding knowledge is not great but I thought that in theory it could be possible using either of these methods: 1. My original idea would require adding a parameter and adjusting the code to include something like #if:{{infobox|}}… to override the font size change if triggered. 2. Your mention of the sup/sub led me to come up with an alternative method, adding another option to the Vertical Alignment parameter, such as vertical-align=ib or v=ib which could be used instead of sub or sup and could be coded to display baseline placement with 100% font size. (This appears to work in my sandbox test) style="{{#switch:{{{vertical-align|{{{valign|{{{v|}}}}}}}}}|ib|font-size:100%;|sup|super|sub=|font-size:85%;}} The documentation would also need changing specifically stating to only use the parameter for smalltext/infobox use and the reasons for this.

From looking at the code it looks like the second may be the more workable option, but any thoughts on this would be useful before going to the effort of trying to establish consensus for a change. If there is any problem with the coding (I think it looks ok, but technical editors may know better), or other editors have reason to oppose such a change then it may be worth considering adding a note to the documentation page to make editors aware of the MOS:FONTSIZE issue when using this template. EdwardUK (talk) 15:08, 4 August 2021 (UTC)

I added a test case at Template:Interlanguage link/testcases#Non-reduced font size, but |ib=yes doesn't seem to do anything:

{{Interlanguage link/sandbox|Constitutional law of 10 July 1940|fr|Loi constitutionnelle du 10 juillet 1940|ib=yes}} -> Constitutional law of 10 July 1940

-- Michael Bednarek (talk) 03:06, 5 August 2021 (UTC)

I've added a second testcase – rather than creating a ib= parameter it makes use of the existing parameter for vertical-align v=ib - I do not think this should cause a problem because where the link is formatted at 100% font-size it would not be desirable to have it displayed as sup/sub at the same time. EdwardUK (talk) 14:41, 5 August 2021 (UTC)

Edit request for parameter option to change infobox font size

A change to comply with MOS:SMALLTEXT. Special:Diff/1037185710 allows for a parameter to be set so that when the template is used within infoboxes it will prevent the font size from being too small. It has been tried out in sandbox and testcases without any evident problems. The accompanying change to documentation would be the addition of a section after 5.5 Vertical Alignment to state its purpose and specific usage:

Infobox font size

When this template is placed within elements that already use a smaller font size, such as infoboxes, the interlanguage link drops below 85% of the page's default font size. To prevent this and adhere to MOS:SMALLTEXT the value ib can be used with the vertical alignment parameter: vertical align=ib (or v=ib, etc.)

(Wikitable example - similar to vertical alignment examples)

This feature should only be used when the template is placed within infoboxes or other elements that use a smaller font size.

This edit would make no difference to existing transclusions, these would all remain at the current font size 85% (including those in infoboxes) until individually changed where needed. EdwardUK (talk) 03:41, 10 August 2021 (UTC)

I see no major issue with this, but I'll leave it open for a bit as I know some proposed changes to this template have required discussion on the matter. Primefac (talk) 13:17, 10 August 2021 (UTC)

Same here. -- Michael Bednarek (talk) 14:10, 10 August 2021 (UTC)

 Done Primefac (talk) 10:53, 15 August 2021 (UTC)

Protected edit request on 8 September 2021

Please add this sandbox change to the template and this change to the template's documentation. It adds a |short= parameter to optionally replace "Wikidata" link text with "d" (which is known prefix code shortcut for Wikidata). The reason: as in these testcases, "Wikidata" is sometimes longer word than the Red Link, produced by {{Interlanguage link}}, itself (and Red Link in the articles is already enough to draw attention). This change would have no impact on existing template's transclusions. Flipping Switches (talk) 23:30, 8 September 2021 (UTC)

 Done Elli (talk | contribs) 00:28, 9 September 2021 (UTC)

Thanks! I took the idea for this change from uk:Шаблон:Не перекладено. Flipping Switches (talk) 16:36, 9 September 2021 (UTC)

Proposed alternative to Template:Ill

As it is, {{Ill}} just isn't pretty.

The use case is that an English-language version of the article doesn't exist, you make a guess at what the English-language article would be called, then provide links to articles available in other languages. For your effort, you get an ugly-looking red link, and peculiar-looking links to the article in other languages.

If it happens that the English-language page gets created in the name you guessed, then the foreign-language links disappear, and before long, a bot comes along and deletes your {{Ill}}. However, if by chance the English-language page goes away, the bot will not revert this change.

There's just a much simpler way to handle this:

• Any article for which you would otherwise do {{Ill}}, just create a "manual redirect" page.
  • The "manual redirect" appears as an ordinary page in which there are links to foreign-language versions of the article in the header.
• If an English-language version of the article is subsequently written, the foreign-language links may be retained or not, depending on whether they are perceived to add value.

The fairly obvious issue is how "special" these manual redirect pages would be. If you make them special, links to those pages could display in a different color and it would be less of a surprise that there is not actually an English-language version of the article available. That's not exactly a showstopper. Fabrickator (talk) 05:38, 18 September 2021 (UTC)

You're basically talking about creating some weird hybrid form of disambiguation page, only using interlanguage links instead of "you might be looking for X page". I suspect such pages would be quickly deleted. Primefac (talk) 10:56, 18 September 2021 (UTC)

Hello, Fabrickator! Can I ask you to explain what you're suggesting? Are you talking about a new feature, changes to this existing template, or just doing something with the tools Wikipedia already offer? Perhaps you could whip up a sandbox example of what you mean by create a "manual redirect" page? Cheers CapnZapp (talk) 13:16, 18 September 2021 (UTC)

(I do agree to your analysis of the current situation. Yes, having to guess at a page -which might remain redlinked for a long time if your guess turns out to be wrong- is a problem. Yes, having a bot delete your helpful links without giving new pages time to "settle" is a problem and/or owning up to its deletions and undeleting them as needed.) CapnZapp (talk) 13:19, 18 September 2021 (UTC)

Your proposal takes away one of the main benefits of {{ill}}: it creates a beautiful red link to show that there is an opportunity to write about something. Alas, Wikipedia is so large now that good red links are hard to come by. —Kusma (talk) 13:21, 18 September 2021 (UTC)

Thanks for the feedback! The comparison to disambiguation pages is spot on, my only disagreement would be whether it's "weird"... It really is a disambiguation page, though it does not necessarily list multiple articles. And it's expected that other pages will link directly to such a page. Here's my example, so to speak:

User:Fabrickator/Cornelia Wilhelm is currently DAAD Professor in the Departments of History and Jewish Studies at Emory University.

Fabrickator (talk) 21:52, 18 September 2021 (UTC)

I think to make this a viable alternative to {{ill}}, you'd need to find a way to automatically have CSS styling applied to this type of links (like we do for disambiguation pages, which appear orange when certain preferences are set) so at least the people who choose to do so could see without clicking whether a link goes to an actual article or to one of your interwiki redirect/list pages. (I still maintain that {{ill}} is fine, especially if linking just to one or two languages. For pages with a dozen interwiki links it can get a bit clumsy). —Kusma (talk) 22:08, 18 September 2021 (UTC)

As Kusma observed above, {{ill}} has benefits. As for links to many interwiki articles: Often a particular language version is the obvious choice because it's the most comprehensive one. Once there, a reader can easily pick a different one. If the choice is not obvious, a single link to Wikidata will show them all. -- Michael Bednarek (talk) 01:36, 19 September 2021 (UTC)

I also agree that {{ill}} has useful benefits. However, while it's probably worth discussing if having a DAB-style page might be a useful option, we can't implement change that from here. Wikidata certainly gives us some options that weren't available years ago, so perhaps the OP should bring the subject up at a Village Pump page and see what happens. BilCat (talk) 02:42, 19 September 2021 (UTC)

Bilcat, thank you for your suggestion to bring this to Village Pump. I had some responses for which I would still appreciate feedback here...

I don't seem to fully appreciate the benefits of having red links, I view them as a distraction to the ordinary reader. As to identifying inter-language articles in need of English-language versions, tagging the redirect pages (e.g. {{disambiguation ill}}) would make it easy to quickly find all the interwiki articles we'd like to link to but for which we are missing English-language versions.

I view the major advantage of this proposed scheme as being that multiple articles referencing the same non-existent English-language article get fixed in a single place, i.e. on the redirect page when it is changed to a regular article. Additionally, creating links to these pages doesn't require any special syntax... it's just a normal link (once the redirect page has been created). If we can make it so these get highlighted in another color, that's nice and I assume feasible, but it's not what I would think would be a showstopper. Fabrickator (talk) 03:36, 19 September 2021 (UTC)

"I don't seem to fully appreciate the benefits of having red links... " Exactly. But instead of finding out why they're useful (they are very useful, in fact), you decry them as being ugly. Which is odd, as User:Fabrickator is a red link! Maybe you should start there? Just saying. BilCat (talk) 03:46, 19 September 2021 (UTC)

I need to point out that you're not addressing Fab's arguments, Bil. In fact you're changing the topic. Just because red links might not be something to avoid does not necessarily mean Fab's idea lacks merit. CapnZapp (talk) 08:42, 19 September 2021 (UTC)

No, you do not need to point it out. As I said above, "...while it's probably worth discussing if having a DAB-style page might be a useful option, we can't implement change that from here. Wikidata certainly gives us some options that weren't available years ago, so perhaps the OP should bring the subject up at a Village Pump page and see what happens." See my reply to you below for more on red links. BilCat (talk) 17:23, 19 September 2021 (UTC)

The only point I see mentioned for the red link is this idea of alerting editors to the possibility of an idea for a new article. The fact that an article not present in enwiki which already exists in another language is a separate class of missing articles, if only because there is at least an existing article model (i.e. in another language) to start from. As for seeing my own user page in red, well, that's only on talk or discussion pages anyway, but if it bugs other people, maybe someone will change the user creation process to pre-populate such pages. Red links on a regular page are a reminder that different people have different ideas about what articles are really justified to be created, but i have to admit, if that's the main thing we're going by, I'm not impressed. Fabrickator (talk) 04:20, 19 September 2021 (UTC)

There used to be a common saying on Wikipedia that "Redlinks grow the Wiki", and it's still true. They shouldn't be used haphazardly, but in most cases, if an article exists in another language Wikipedia, it's probably notable enough for an article on English Wikipedia. In the years I've been on Wikipedia I've been inspired on several occasions to write articles because of a redlink, and I've seen articles created by other because of redlinks, even by new users. Wikipedia has no deadline, and as such, good red links are a necessary part of Wikipedia's continued growth. That they are "ugly" to some people is totally irrelevant. BilCat (talk) 06:03, 19 September 2021 (UTC)

Okay so you're in favor of red links, BilCat. That much is clear. But you're not doing yourself any favors by seemingly ignore the actual fact that many many many Wikipedians consider them a problem, and tries to avoid or "correct" them. When push comes to shove, the color red is associated with "error" not just "missing". Now, this spot isn't the proper place to discuss rehash red links. But it is the place where I want to make a friendly reminder that your view is not the only one, and that you might have an easier time understanding where this proposal is coming from if you recognize that red links are far from as uncontroversial as you make them out to be. Best regards, CapnZapp (talk) 08:27, 19 September 2021 (UTC)

• Actually, I'm trying to remind the OP that their view is not the only one, as the replies below bear out. The crux of this entire proposal basically stems from the OP's dislike of red links. As I already pointed out above, which you apparently didn't read, his proposal has some merits, but we can't act on any proposal here. Yet they continued to rail against red links. I'm sorry, but you're comments aren't appreciated. BilCat (talk) 17:17, 19 September 2021 (UTC)

It's really sad that some people go around removing valid redlinks. In any case, the template here shows both that something is missing and where to find information about it, unlike a plain redlink. —Kusma (talk) 13:47, 19 September 2021 (UTC)

I don't think there's anything wrong with redlinks, and I hate it when new editors simply remove them. However, Fabrickator is right that the current way of managing interlanguage links has problems, and it would be a lot more efficient if we used new pages of the type proposed. The benefits of redlinks are confined to editors (unregistered users can also get inspired by a redlink to create an article, but we've erected so many barriers in the way of such creation that I won't be surprised if the effect on them is negligible), and can be reasonably retained by styling those new links in a different colour. – Uanfala (talk) 15:00, 19 September 2021 (UTC)

I find the existing template is fairly easy to understand and think it does its job well. An editor can add it if they think the subject is notable (as with any other redlink), with the language links being helpful for those who want them. The proposal seems to be to get rid of this template and replace it with different colored links that are not followed by language links. Then have this link to a separate article with a list of language links. I can understand why this may be seen as a positive as it makes it easier to read an article without the language links getting in the way. However, the manual redirect pages do not appear to remedy the other issues raised and appear to create new difficulties. Guessing which name to use for these pages is going to be exactly the same as it is when using the template or a standard redlink. Would the different color be set as standard or only for users who have set a preference for it? As a preference setting would the default become blue, if so it would mislead readers into thinking it was to a full standard article instead of a link repository, as a default setting having another color adds an extra level of complexity for casual users, and changing the color would not necessarily make it any less ugly. It also makes it so that users have to click through an additional page to reach the alternative language version of an article.

Why editors have an issue with the bot that removes the template is something I find hard to understand. A redlink, and therefore this template, should generally only be added if an editor thinks an article could be created on the linked subject. If the English language article is created and kept there is no problem removing the template. If the article is deleted, often because it is not judged to be notable, (with standards for notability varying between different wiki communities) then it is often the case that the resulting redlinks are removed too, so to me it would not seem desirable to restore the template for a non-notable subject.

A lot of redlinks are created using this template on the assumption that another language version shows some notability for an article here too. And as with most redlinks this is not put to the test until an article is actually created at which point someone then challenges it. The problem with creating tens of thousands of manual redirect pages to replace this template is in them failing to meet the same basic requirements of any other new article, that is passing the notability and referencing tests, which they would fail if the only content was: this subject exists, here are some links to other wikis. To prevent these from being deleted would basically require the creation of something equivalent to stub/start level, in which case they could become standard articles tagged with language expansion templates rather than being a manual redirect page as proposed. An alternative may be to establish a drive to create these articles, like a version of "women in red" editathons but for the redlinks displayed by this template. EdwardUK (talk) 15:44, 19 September 2021 (UTC)

Article links can turn red for a variety of reasons unrelated to notability. An article on a notable topic will get deleted if it's for example a copyvio or if it was created by a blocked user. This also happens when an article is draftified, whether the page is eventually improved and moved back to main, or it's ultimately deleted per G13. In all those cases, the end result will be the removal of the interlanguage links for a notable topic.

But more broadly, I don't think notability is that relevant here. A topic can lack notability for a standalone article but still be worthy of treatment within another page, and in those cases it will be appropriate to create links or redirects for that topic. – Uanfala (talk) 17:23, 19 September 2021 (UTC)

@EdwardUK: "Guessing which name to use for these pages is going to be exactly the same as it is when using the template or a standard redlink." In the current arrangement, each {{Ill}} stands alone. Once you've established that there's no existing article on the local wiki, the editor is most likely just going to insert the template using whatever English-language name seems most appropriate. Whereas with the proposed approach, the editor hopefully finds the existing redirect page before creating a new one. This is identical to the existing problem of avoiding the duplication of an existing article under a slightly different name.

What strikes me as most perverse about the existing implementation is the redundancy involved. I don't have any idea how many times there are multiple uses of inter-language links for same article, but it's simply the fact that the existing implementation isn't normalized, i.e. if multiple articles want to provide a link to a set of such links, the list is repeated in each place ... and if that list changes (whether because a new page has been found in another language, or because an enwiki article was created), then you need to go to each of the existing links and change them. That's just wrong! Fabrickator (talk) 18:07, 19 September 2021 (UTC)

Please continue this discussion at Wikipedia:Village pump (idea lab) § replacement for Interlanguage link template. Fabrickator (talk) 21:58, 19 September 2021 (UTC)

Thanks! I'll be watching it, and may participate at some point. BilCat (talk) 22:14, 19 September 2021 (UTC)

What use is this template?

OP has been indeffed as a sock, hatting this whole mess. Primefac (talk) 14:51, 23 October 2021 (UTC)

ill with an existing redirect

On the prosciutto page, I ran into the following problem: there are ill links to various specific kinds of prosciutto which have pages on the Italian WP. So far, so good. But two of them (Prosciutto di Parma and Prosciutto di San Daniele) have existing redirects in the English WP; but they are redirects to the prosciutto article, making them useless (circular) in this case, but the ill link is a bluelink, not a redlink. Is there anything I can do about this? I thought of inserting an invisible character (e.g. Zero-width space) in the article name, but that seems like a really bad idea.... --Macrakis (talk) 22:15, 22 October 2021 (UTC)

This behaviour of {{ill}} was introduced some time ago. The positive aspect is that interlanguage links still appear, so the interested reader can visit a more specific article at IT WP. The self-redirect will only disappear if e.g. Prosciutto di Parma gets restored as an article, which it once was (of insufficient quality, so the change to a REDIRECT was OK, but that doesn't mean someone might write a proper article on the subject). -- Michael Bednarek (talk) 02:19, 23 October 2021 (UTC)

Perhaps I can rephrase for clarity (still agreeing with MB): that ill sometimes displays a link that is not red, but blue, is not seen as a problem severe enough to trumph the general utility of offering redirects. In this case: a reader searching anywhere on Wikipedia for the specific term "Prosciutto di Parma" is helped by getting redirected to English Wikipedia's general prosciutto article. In this I hope we all agree. That the presence of this redirect happens to make an ill link change color in a way that at first glance might appear illogical (why offer an ill link if we do have a blue link?) should be seen as a minor issue. Previously the ill link disappeared as soon as any target appeared at the destination page. Checking to see if the target is "only" a redirect and if so not hiding the ill link seems to be an improvement despite it leaving us with a blue ill link. CapnZapp (talk) 07:43, 23 October 2021 (UTC)

Another approach, is to tag it. This is the approach taken by {{Further ill}} (see intro, and Example 1), but that's a pretty non-standard usage I think. On the other hand, consensus can change; if there were enough support for it here, it could conceivably be added. However, I'm not quite sure if that addresses your issue; does it? Mathglot (talk) 10:34, 23 October 2021 (UTC)

Comment: I find it interesting that {{Further ill}} marks any "link that is blue but really isn't" with ^(redirect) even though {{Ill}} doesn't. CapnZapp (talk) 13:32, 23 October 2021 (UTC)

Well, BKFIP might have stirred up a storm in the previous section, but one of their more valid points was that some view the language links as clutter. An extra ^(redirect) in a hatnote is one thing, putting that in prose is quite another. Primefac (talk) 14:53, 23 October 2021 (UTC)

Just as a heads-up, you might not want to advertise when long-time abusers happen to agree with your positions... ;) Cheers, CapnZapp (talk) 21:12, 23 October 2021 (UTC)

Intentional attack when you know that I fully support the use of this template? Bold of you. Primefac (talk) 08:06, 24 October 2021 (UTC)

I intended it as a playful suggestion to maybe avoid certain comrades in arms, no matter their utility for the matter at hand. Next time I will know a smiley is insufficient. CapnZapp (talk) 10:38, 24 October 2021 (UTC)

Further ill is close to what I'm looking for, but too wordy. I simply want to create an ill where the main link is red despite the existence of a page of that name (in particular, a redirect, especially a circular redirect) in the en WP. There doesn't seem to be a parameter for that. --Macrakis (talk) 15:27, 23 October 2021 (UTC)

This has been discussed before, and it's simply not technically possible. If you are linking to an existing page, it's going to be blue (or green, if you have it set that way). There is simply no reasonable way to show a redlink while linking to a redirect. Primefac (talk) 15:32, 23 October 2021 (UTC)

Also, it'd open a real can of worms to use red color for links that actually lead somewhere. But once more, before we have that discussion, the main question remains: is this really a problem? Regards, CapnZapp (talk) 21:17, 23 October 2021 (UTC)

Perhaps a better question is whether or not we should be using Ill at all in these situations. If Prosciutto di Parma and Prosciutto di San Daniele are adequately covered in the existing article, do we need to link to the Italian articles at all? BilCat (talk) 21:24, 23 October 2021 (UTC)

Prosciutto di Parma gets one sentence specifically about it in prosciutto.

On the other hand, it:Prosciutto di Parma is a 11.5k article, though admittedly about half of it applies to prosciutto crudo in general.

So no, I would not say that Prosciutto di Parma is "adequately" covered in the existing en article. --Macrakis (talk) 22:21, 23 October 2021 (UTC)

• Understood. BilCat (talk) 23:14, 23 October 2021 (UTC)

It might well be the case that an {{ill}} link isn't as useful as the editor thinks it is (or maybe the other-language Wikipedia article has been restructured since). But more generally, the message I think we want to send is: don't hesitate to use ill links just because the English language link doesn't turn red. Cheers CapnZapp (talk) 10:32, 24 October 2021 (UTC)

+1. Mathglot (talk) 20:46, 24 October 2021 (UTC)

There's a solution that would work for you I think, without affecting anyone else, involving css class. We'd modify the template to test for redirect (it already does this in another context) and generate, say, <span class="ill_redirect_link">Redirect link</span>, and then you'd add one line to your common.css to set the color (and other features if you wish) to whatever you want. This would involve a change to the template, but wouldn't affect anyone but those who opted in. Mathglot (talk) 22:59, 23 October 2021 (UTC)

As another solution, and an alternative to using User:Anomie/linkclassifier.js, one can add a specific code to change redirects to shades of green, as in my User:BilCat/common.css. I had to hunt for the coding, and found it at Wikipedia:Tip of the day/March 17, but if someone else wants to try it with my preferred colors, this will save some legwork. BilCat (talk) 23:21, 23 October 2021 (UTC)

Could this be what Primefac was talking about above? CapnZapp (talk) 10:34, 24 October 2021 (UTC)

He was talking about using User:Anomie/linkclassifier.js, which I mentioned. It add colors for lots of types of links, not just redirects. BilCat (talk) 19:12, 24 October 2021 (UTC)

Styling circular redirects

@Macrakis:, thanks for raising this, and wanted to respond to what I see as a key point. To provide context, I've copied and boxed your 15:27, 23 October comment above (and the direct replies to it):

copy of three comments above, 15:27 – 21:17, 23 Oct

This is a copy of three comments in the discussion above, to provide context for this subsection. Further ill is close to what I'm looking for, but too wordy. I simply want to create an ill where the main link is red despite the existence of a page of that name (in particular, a redirect, especially a circular redirect) in the en WP. There doesn't seem to be a parameter for that. --Macrakis (talk) 15:27, 23 October 2021 (UTC) This has been discussed before, and it's simply not technically possible. If you are linking to an existing page, it's going to be blue (or green, if you have it set that way). There is simply no reasonable way to show a redlink while linking to a redirect. Primefac (talk) 15:32, 23 October 2021 (UTC) Also, it'd open a real can of worms to use red color for links that actually lead somewhere. But once more, before we have that discussion, the main question remains: is this really a problem? Regards, CapnZapp (talk) 21:17, 23 October 2021 (UTC)

If I understand correctly, you want an ill link pointing to an en-wiki article that doesn't exist yet to remain red even if a redirect exists (esp. in the case something that should be a stand-alone article), and even more so if it's a permitted circular redirect "with possibilities". But as Primefac mentioned, that's impossible for technical reasons. However, there may be a workaround for you, if it doesn't bump up against a MOS:LINKS guideline prohibition. Here's the workaround:

• {{ill|Draft:Prosciutto di Parma|it|Prosciutto di Parma|lt=Prosciutto di Parma|v=sup}}

This generates the following: Prosciutto di Parma, that is, plain red text with a link to Draft space with the same {{PAGENAME}} as the existing redirect (as long as the Draft page does not exist). Because of param |lt=, it looks to a reader as a "normal" red link. If clicked, it does what a red link always does, only it targets draft space. There might be some WP:ASTONISHment upon a click, but not for viewers; only for editors; and editors prepared to create a brand new article are usually not newbies, and will figure out what happened; even just mousing over will do that. Finally, it solves CapnZapp's concern about a red link that leads somewhere.

This uses the |lt= (linktext) param to name the article you want to create in article space (let's say, 'Prosciutto di Parma') and keeps the link red by pointing the main link to draft space instead, where no article exists. (Given that the redirect already exists in article space, developing a new article under that name could take place either by taking over the redirect, *or* by developing it in Draft space, and moving it over the redirect when it's done; both methods are common.) If developed as a draft, the fact that a redirect exists at that name already would be flagged automatically in the Draft header, just as one would wish.

So now the question becomes, is this permissible per MOS:LINKS or not? Here's the gray area: normally, an article is not allowed to have a link to Draft space per MOS:DRAFTNOLINK which says this:

In articles, do not link to pages outside the article namespace, except in articles about Wikipedia itself (and even in that case with care – see Wikipedia:Manual of Style/Self-references to avoid).

Does that include non-existent pages in Draft space? Maybe it does, but it's doubtful when this prohibition was added in 2015 after this discussion whether anybody conceived of the situation we are talking about now. (That MOS sentence went through various changes here, here and here.)

Now, the fact is that that discussion, not surprisingly, never considered this edge case of a red link to Draft space (and why would they?). So, I think that if this method works for you, then the next step would be one of several: one would be to discuss it at WT:MOSLINK or at WT:Drafts, ping the participants from the 2015 discussion, and have a discussion there about it, or have it here and link it from there. Alternatively, since the MOS:LINK guideline is just that—a guideline—some real world cases are exceptions and this may be very well be one of them, where what serves the readers and editors best is an alternative to the letter of the guideline, so you could just WP:BEBOLD and go ahead and add the {{ill}} example above, and see if anyone objects. If you decided to pursue any of the alternatives mentioned here, I would support that effort. Hope this helps. Mathglot (talk) 23:08, 24 October 2021 (UTC)

As a corollary: to assuage any ASTONISHment for wikicode readers, you could add a hidden comment next to it, analogous to MOS:HIDDENLINKADVICE explaining that the ill targets draftspace because a circular redirect already exists. (adding forgotten ping @Primefac:) Mathglot (talk) 23:37, 24 October 2021 (UTC)

This approach might negate one of the main advantages of {{ill}}, turning an interlanguage link to a normal local link, if the current REDIRECT Prosciutto di Parma gets directly converted/usurped into an article. The editor doing that will not discover the link to draft space, nor will Cewbot. -- Michael Bednarek (talk) 01:07, 25 October 2021 (UTC)

Cewbot could easily be adjusted to discover it, if there were enough cases like this one for it to matter (doubtful). As far as an editor not discovering it, under current guidelines and info pages, that's true. But it's also true that just getting to a redirect in the first place in order to be able to edit it is not a newbie activity, and neither is creating a new article from scratch. There are already several paragraphs of instructions at How to edit a redirect or convert it into an article, and I don't think it's too much to ask, to add one statement to that section asking editors to "...check Draft space for pages that may match the redirect name, or the former target". That would be good advice, even absent any usage of this approach. Mathglot (talk) 02:19, 25 October 2021 (UTC)

Found an interesting angle involving the issue of undiscovered or unrepaired links from mainspace to non-existent drafts, and one that I did not expect. As it turns out, there are already around 40 non-existent Draft pagenames linked from main space. Compared to 6M+, that's a pretty small problem, and I doubt it's worth programmer time at Cewbot to fix it. (Probably would take less than a person-hour to fix it manually.) The reason I mention this issue at all, is because it's not likely that that number would increase much by editors taking advantage of the edge case method mentioned above, and equally unprofitable to fix it, imho. Although it could be mitigated by appropriate edits to WP:EDRED and fixed manually as needed. Mathglot (talk) 04:40, 26 October 2021 (UTC)

Notes

I was pinged, so let me thank you for spending time on this, Mathglot. However, we have kept solving this issue without first having a discussion if it is a problem. I mean, I understand the OP (Macrakis) perceives it to be a problem big enough to merit a solution, but is it generally? If not, then advising Macrakis on possible individual fixes (e.g. User:Anomie/linkclassifier.js et al) while determining that, no, this is not something that needs a fix or, indeed, should have one. But that's not for me to say. At this stage, I'm merely pointing out that several helpful editors have barged ahead and offered solutions without stopping to first consider if solutions are appropriate. Perhaps the simplest and best response to the original question Is there anything I can do about this? would be "no". Regards, CapnZapp (talk) 12:25, 25 October 2021 (UTC)

Hello Mathglot. I noticed you kept discussing a proposed solution (the one involving links into Draft space). I invite you to first take a stance on the overall question: is this a problem large enough to merit solving? before continuing that discussion. That is, we should not barge ahead and fix things just because we can. Please first lay out your arguments why this issue is problematic enough to justify the solutions you propose. Why? Because your continued contribution implicitly argues the problem deserves to be solved, and I would like to hear your thoughts on that. I'm not opposed or anything; I just wish we first agree the issue is a problem. (Please don't feel personally picked on, Mathglot. This goes for everybody; you just happened to be the first editor to not respond to my above post; which happens to be the fourth time I have tried to bring up this issue, so now I am resolving to make it the last time before it is actually discussed) CapnZapp (talk) 06:14, 26 October 2021 (UTC)

I don't feel at all picked on. In fact, you pose a very interesting meta-question about the prioritization of volunteer effort at a large, collaborative, worldwide, online, project and it would be very interested to discuss it and hear what others have to say. But as this is the interlanguage link template talk page meant for improvement of this template, this is the wrong venue in which to discuss such a broad question; for one thing, no one will find it here—it deserves broader and more varied participation than you'll ever find here. The fact that you've addressed it four times before kind of confirms that. If you would like to raise the question at a broader forum such as WP:VPM where plenty of people will see it, or another centralized discussion location, I'd be happy to engage there. Cheers, Mathglot (talk) 08:55, 26 October 2021 (UTC)

I believe there's a misunderstanding. I am not at all posing a general abstract question. I am posing a direct question specific to this very template: do we consider blue ill links to be acceptable? If so, the appropriate response is to avoid solving the OPs issue (except for them individually of course), and instead reply "works as intended" or perhaps terser: "no". Anyone wishing to pursue the issue is free to do so, but please first explain why you think this problem needs solving, and why simply answering "no" is unacceptable. Thank you CapnZapp (talk) 09:44, 26 October 2021 (UTC)

I see. That is indeed a narrower issue that belongs somewhere, probably WT:MOSLINKS or maybe here. I'd respond by saying that not everything is, or can be covered by guidelines, and most squirrely edge cases like this one aren't, and imho often shouldn't be. One cannot foresee every possible situation that could arise, and trying to codify everything would lead to instruction creep and guideline bloat. So I'm content not to have answers to every "should-we" question, including this one. A lot of rare situations should be left up to WP:BEBOLD and WP:LOCALCONSENSUS until, and if it ever rises up to the level where it's no longer a rare case anymore, and becomes deserving of community discussion of whether a guideline should cover it. Macrakis said: "I simply want to create an ill where the main link is red despite the existence of a... redirect, especially a circular redirect"—and it's possible to address that as a "how-to" question without having to consider the "should-we" question that you have outlined. In a volunteer project, we all get to contribute to the topics and discussions we wish to; I find Mackrakis's question a worthy and interesting one, and there's no talk page guideline that precludes discussion of it until after a "should-we" question is resolved first, so I'm discussing it. Your question is worthy too, and if that discussion happens then perhaps we'll end up with a guideline, or at least a local consensus about what to do in this situation, and I encourage you to pursue it if it interests you, but it's not the one that interests me as much, although I'll be attentive to the outcome, and of course follow any consensus that arises out of it. Mathglot (talk) 18:16, 26 October 2021 (UTC)

I really wish it didn't come to this, but in order to clarify the situation, let me officially oppose any changes to this template for reasons related to the OP's issues (avoiding blue-linked english Wikipedia pages). Let me start off with the argument: I believe things are good enough as-is. Even if my real aim here only is to invite you to win me over with your own arguments. This hopefully makes it clear that you should not proceed (boldly or otherwise) implementing any wiki-wide solution until after you have achieved consensus that this indeed is considered a problem in need of a solution by the community. Also, I assert that this page is precisely the right place to have this discussion. I specifically ask we don't have it anywhere else. Now then, I obviously cannot prevent you from discussing solutions (and indeed has no wish to do so); just as long as we are clear that, no, the strategy of postponing the "should we?" discussion until after you have implemented a solution is not available here. I am posting this in the interest of openness and clarity, and once more I hope and trust you see I am not targeting you personally. Sincerely yours, CapnZapp (talk) 09:19, 27 October 2021 (UTC)

Maybe this was just all a big misunderstanding. The proposed solution being discussed here does not require any changes to the template at all; you could have saved yourself the trouble if that's all that this was about.

That said, templates are changed all the time based on individual initiatives by editors, and BOLD moves are encouraged by stated guidelines. Any disagreements follow the normal editing guidelines, and that happens all the time, too. Which, I hope, makes it clear that any editor is free to implement bold solutions in templates in accordance with guidelines anytime they wish without waiting for a green light by an individual editor who asserts a non-existent right of prior constraint to declare when another editor may proceed with an edit. Mathglot (talk) 17:17, 27 October 2021 (UTC)

I don't think you should encourage Macrakis to start pointing ill links into Draft space without first discussing this idea. CapnZapp (talk) 18:58, 27 October 2021 (UTC)

Please do not associate bold edits with edits that go against stated opposition, that is just nonsense. If and when you wish to take an "initiative" opposed by others you need to discuss first, edit later. CapnZapp (talk) 18:58, 27 October 2021 (UTC)

Template-protected edit request on 7 November 2021

Change the present See also section to include the following linkage:

Help:Interlanguage links#Inline links (links in the text of the article)

This is the only Help or Template section I have found around here that fully explains the various interlanguage linkage that is possible when linking to show that an article on the subject exists in another language Wiki. I would also suggest that the ILL linkage be available at the related Help/Template pages. Thanks. Shearonink (talk) 18:32, 7 November 2021 (UTC)

 Not done: {{edit template-protected}} is usually not required for edits to the documentation or categories of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage. * Pppery * _{it has begun...} 19:44, 7 November 2021 (UTC)

Pppery - Ah ok... Could you take a look at my edit and make sure it's ok? Thanks, Shearonink (talk) 20:02, 7 November 2021 (UTC)

I did Special:Diff/1054054842 to tidy up some redundant-seeming wording, but otherwise it looks fine. * Pppery * _{it has begun...} 20:03, 7 November 2021 (UTC)