Template talk:Interlanguage link/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Support lang tag

I made a sandbox edit that allows wrapping the link text in a {{lang}} template using a new |lt-lang= parameter (and an accompanying |lt-rtl= corresponding to {{lang}}'s right-to-left parameter). Currently the only alternative would be wrapping the entire {{ill}} template in a {{lang}} template, which would be semantically not entirely correct. ―Jochem van Hees (talk) 01:37, 12 February 2022 (UTC)

Is this theoretical, or do you have some actual examples where you would need this feature? Mathglot (talk) 02:01, 12 February 2022 (UTC)

Further, some testcases are needed. -- Michael Bednarek (talk) 04:00, 12 February 2022 (UTC)

Yeah, I was a bit intimidated by the complexity of that page so I just tested it on my own sandbox, but I'll look into actually adding some proper testcases now.

@Mathglot: seems quite logical to me that links to foreign languages are often foreign-language text. Just looking through the 'what links here' page, it seems most links are people's names, but there's also a lot of foreign-langauge names of organisations which should be tagged with {{lang}}. Examples I just found: Andorra (Castellers d'Andorra), Athens (Athinais Kypselis), Austria-Hungary (Landesausschuss ). I actually made this edit request after Matthiaspaul made an edit to Template:Lang/doc explaining the problem of not being able to combine this template with {{lang}}. ―Jochem van Hees (talk) 10:57, 13 February 2022 (UTC)

Actually, I very much support adding a |lang[uage]= parameter to {{ill}} for the very reasons given. In fact, I thought about making a similar proposal, but just didn't have the time to write it down. {{ill}} is very often combined with {{lang}} for obvious reasons, but not all combinations work. It would be much more convenient (and also semantically more correct), if {{ill}} would support the functionality of {{lang}} right out of the box.

In many cases, the language would be the same as the language of the foreign wiki link, so in all cases where the same foreign language word would be used as our local article title, the language could be derived from the already given prefix. Of course, this would not be valid in all cases and this assumption would be invalid to make in most cases where the foreign and local link names differ.

Either way, for a start I would be happy with a separate language parameter already. To keep it simple, I would call the parameter |language/lang/l= rather than |lt-lang=, also for consistency with other templates using a language template (CS1/CS2 support |language= and |lang=, {{r}}/{{rp}}/ {{ran}} additionally support |l=).

--Matthiaspaul (talk) 15:40, 13 February 2022 (UTC)

I would call it |lt-lang= as originally proposed. This template is already busy with the concept of languages and foreign wikipedias, and is already complex—by which I mean not the code, but the large number of parameters available and the explanation of them in the doc—and it can all be a bit overwhelming for someone not used to it. I think clarity trumps any consistency of param naming, and my first question if I saw |lang= would be confusion: "what lang? isn't practically everything here a language?" By linking |lt-lang= through its name to |lt=, I feel that it's pointing me in the right direction, and I wouldn't feel so unmoored. Don't get me wrong—I'm a big believer in consistency, including in param names: I'm active at Welcome Templates, and lack of consistency in param naming is one of my pet peeves there—however I'm a bigger believer in clarity and ease of use for the user, and in this case, I believe clarity trumps consistency and the user would not be well served by a param name similar to other templates which might be more likely to be confusing than helpful to the user of this one. Mathglot (talk) 18:02, 13 February 2022 (UTC)

I'm a believer in consistency and clarity as well ;-)

I also see your point, having asked myself too the question if we'd need more than one language parameter.

However, I came to the conclusion that the only thing than could actually need to be tagged with a language tag is the label text displayed by the template, not the (possibly different) underlying local link target and not the inter-wiki link symbolized by that "[??]" thing, which, at least for me, is something conceptually so different that I would hardly confuse the two parameters.

However, speaking about the current parameter interface and clarity, I consider it rather unintuitive - probably as a result of its merging history. While I'm not against keeping the unnamed parameter interface, I think, we should have at least the option to provide all parameters as named (and optionally enumerated) parameters as well. If they were available I would immediately switch to use only named parameters. Something like {{ill|wiki-link/link/wl=Athinais Kypselis|label-text/label/lt=Athinais Kypselis|label-language/label-lang/language/lang/ll=el|inter-wiki-link/iwl=:el:Αθηναΐς Κυψέλης}}. |lt= would be needed only to override the default label text (of |wl=). The label text would be language-tagged only if |ll= is given. If |iwl= would only specify the prefix, the contents of |wl= should be assumed for the foreign link as well. And if |iwl= is given without a prefix, the prefix would be taken from the |ll= parameter. If |iwl= isn't given at all, the prefix should be derived from |ll= as well, and the link from the |wl= parameter. |iwl= could be an enumerated parameter to support multiple iwls. If only |iwl= would be supplied, the |wl= link could be derived from this as well, so that no information needs to be doubled and the user would not have to specify more parameters than necessary. Something along this line.

--Matthiaspaul (talk) 22:04, 13 February 2022 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Mathglot (talk) 21:19, 12 February 2022 (UTC)

Housekeeping note: I've reset the edit request to |answered=no, as there seems to be lively discussion going on now, and it's too early to preclude the possibility of consensus arising out of it. Mathglot (talk) 08:56, 14 February 2022 (UTC)

In reply to your housekeeping, I have re-set it; wait for the consensus to appear, then reactivate the TPER. If there is lively discussion then there is not yet consensus. Primefac (talk) 10:08, 14 February 2022 (UTC)

So uh, about that "lively discussion": nobody has disagreed with this request other than some initial objections. Testcases have been added and they work. The only discussion was about renaming all parameters, which is not per se related to this edit request. When exactly does consensus for this appear? ―Jochem van Hees (talk) 09:54, 16 February 2022 (UTC)

The request to add language tagging capabililities has been brought up several times in the past already, and as far as I can see there never was any opposition to it, just that the discussions moved sideways (like they did here as well, me being "guilty" for that ;-). So, I think, there is consensus to add this capability. It just makes sense to have it.

Speaking of consensus, while any breaking changes need consensus, the template at present is still crude enough in both its implementation and parameter interface that I consider it to be still in its active development phase, not having reached the final form. While it is already actively used, it is also none of the really high-risk templates. So, IMO we do not need to discuss every little non-breaking change down to the smallest bits for as long as the changes are obvious feature or usability enhancements carried out by experienced (template) editors. Moving forward and providing enhanced functionality is beneficial to the project.

I have reviewed your implementation and found it okay to be rolled out but I have spotted some areas for improvement, therefore I changed the code somewhat and added a few more features:

• I have changed your |lt-rtl=yes parameter to |dir=rtl, so that the interface logic remains language-agnostic. This makes it easier to port it to other languages. (I proposed the same change for the {{lang}} template, but that one already uses the non-portable |rtl=yes, whereas in our case we are introducing a new parameter, so we should implement it in the most portable fashion right from the start.) There is no risk of confusion for directionality, so the lt- prefix can be dropped from that parameter.
• Your code did apply italics only when the |italic=yes parameter would be used. To better comply with the MOS, I have changed this so that, if a language is given (and only then), the template will automatically choose the most suitable italics style depending on the actual language and script given, as {{lang}} does. It is still possible to override this using |italic=, which now supports all the arguments supported by {{lang}}: yes, no, unset, invert, default (and their aliases). This is not exactly how our (crude) implemention of |italic= worked before, but since it is very unlikely that someone will have used one of the pre-defined argument values (other than yes and its aliases) to mean something different than to enable italics, it is reasonably safe to implement this somewhat stricter interface - also, the new arguments are only evaluated when a language is given as well, so it would not cause any problems for existing invocations (and if we change the documentation accordingly the previous more lax usage will fade out over time).
• I have added a number of alias parameters: The somewhat cryptic |lt= parameter now has a |text= alias (another alternative would be |label= or even |label-text=). The parameters |italic= and |quote= now have single letter aliases |i= and |q= because some other templates use these names for this purpose and HTML has similarly named tags as well, so it's intuitive. Although I am not really convinced that we need the lt- disambiguator here, I have kept your |lt-lang= but added |language= and |lang=, which I continue to find more intuitive and easier to remember despite the remote possibility of confusing them with the inter-wiki prefixes. Let's see what gets used by the people. [Later dropped the |lt-lang= alias for the reasons given further below. With the new further enhanced user interface logic, the 'lt-' thing would be even misleading, as the parameter value will internally also be used as prefix if no prefix is given deliberately.]
• While unnamed parameters are short, their usage order is (logical from the template logic but) IMO not very intuitive in this template. Therefore, I have added named aliases: |link= for |1=, |prefix/pre= for |2=, and |external/ext= for |3=. For cases, where there are multiple inter-wiki targets, the latter two parameters also have enumerated forms. (At a later stage, I think we should combine |prefix= and |external= into one parameter for an even more intuitive parameter interface, as I proposed in another comment above, but this would require some more changes in the internal template logic, so I didn't do it at this stage.)
• There are quite many cases where the inter-wiki prefix of a foreign wiki would be the same as the language of the locally displayed text, so editors would have to provide both |prefix= and |language= with the same value. Therefore, in order to eliminate the redundancy, it is enough to specify |language=, which's value will also be taken as prefix for as long as |prefix= isn't specified. So, if the local link's text is in English (or shouldn't be specified), the editor would only specify |prefix= for the inter-wiki link prefix. If it is the same as the prefix, the editor would only specify |language=, and if they differ s/he had to specify both.
• I also changed the spacing between multiple inter-wiki links from a space to a hair-space so that it occupies less room in an article (see other talk). For consistency with citations, if super- or subscripts vertical aligment of {{ill}} is selected, the initial space is suppressed as well, so that they appear in the same style as citations - this does not happen for the default baseline style.

This has been tested, and I've added some testcases (more could be added). In my opinion this is ready to be rolled out.

--Matthiaspaul (talk) 10:56, 19 February 2022 (UTC) (updated 15:01, 20 February 2022 (UTC))

I trust Matthiaspaul's judgement and coding. No objections here. -- Michael Bednarek (talk) 11:24, 19 February 2022 (UTC)

Done. --Matthiaspaul (talk) 22:32, 19 February 2022 (UTC)

I have reverted this purely because there is zero reason to have four named parameter options if we're creating the parameters. Pick one and stick with it. I wholesale reverted because I did not implement the original change and do not want to impose any unintentional restrictions on the intended functionality.

My personal thought is that if you're concerned about the clarity of unnamed parameters, then use the full name (|prefixX=). Also, I'm not sure |external= is a good name for the other-language-name (though I do realise I was not involved in the above conversation I also notice no one has commented on that aspect); "external" doesn't immediately make me think "interwiki link", it makes me think more of an external link to another website entirely. If that's just me then that's fine. Primefac (talk) 06:50, 20 February 2022 (UTC)

I agree with Primefac that, without an exceptional reason requiring otherwise, templates should have one parameter for each option and should not add aliases. If someone has to type "quote" instead of "q", so be it. Having alternatives confuses onlookers who want to know what the options mean (is there a difference between "quote" and "q"?) and which option should they use. Aliases waste time. Johnuniq (talk) 08:31, 20 February 2022 (UTC)

Actually, I think, the opposite is true. Aliases can safe time, because editors can memorize the scheme best suiting their brains instead of having to try out multiple forms before they find the one that works when editing articles.

Personally, I prefer self-explanatory fully spelled out parameter names, but experience has shown that some people prefer abbreviated parameter names as well and some even one or two letter names. This template so far supports a strange mix of all of this, some parameters are only available in their long form, some only as abbreviations (and some even only as unnamed parameters). That's difficult to remember. That's why I think that in moving forward it is a good idea to harmonize the styles as much as possible by providing a full set of options for each style.

If I had to choose I would first do away with the one and two letter parameters but that's not easily done because of their legacy use.

Regarding |prefixX= I basically agree, but we would still need at least the two forms |prefix= and |prefixX=, because in most cases there will be only one inter-wiki link, and having to always enumerate it |prefix1= just because there could be more of them is odd, but using |prefix= for the first one and |prefix2=, |prefix3=, ... for the others is likewise odd as well.

Same for |externalX=. The name was kind of a compromise. IMO, the proper name would be |inter-wiki-link= or |inter-language-link=, abbreviatable as |iwl= or |ill=, but this is either unnecessarily long or too cryptic (and also not entirely correct as iwls/ills include the prefix - above I proposed to combine prefix and external into one parameter because it would be more natural from a user's perspective, but it would require more coding to split the value into its two pieces internally - I considered this to be a task to be performed in the future). Thinking about alternatives to these long names and scanning the help pages of several other-language Wikipedias for potentially suitable terms and parameter names, I came up with |inter-wiki=, |inter-link=, |external-link= or |foreign-link=, or shorter |inter=, |external= or |foreign=, also trying to choose parameter names starting on a different letter (so that single-letter abbreviations could be added later, if necessary, |external= could be abbreviated as |e= or |x=, |foreign= as |f=, and |inter= as |i=; the letter 'l' cannot be used as it could mean link, label, or language, and 'i' looks identical to 'l' in many fonts, so it would not be a good one-letter abbreviation as well). That's also why I chosed |text= over |label= which are both established parameter names for the displayed label text of piped links in other contexts.

--Matthiaspaul (talk) 09:33, 20 February 2022 (UTC)

I don't care whether the template uses aliases or not, but retaining the current scheme of 3 unnamed parameters and |lt= is crucial because thousands of uses depend on that. We've been through a somewhat traumatic change of this template before, and it would be terrible to lose the current behaviour. If a radical change is desired, a new template should be created for that. -- Michael Bednarek (talk) 11:36, 20 February 2022 (UTC)

I mostly agree. Keeping support for the unnamed parameters is essential, and, don't worry, I never considered to abandon them. Keeping support for the cryptic |lt= name is important as well - we could, however, discourage its use so that editors would start to use a new better parameter in the future - and we could also have a non-priority bot task replacing the old by the new parameter when they would have to edit the article anyway, so that the usage of the old parameter would be slowly faded out over the years. I haven't check the usage statistics of parameters |v= and |s= yet - their numbers might be low enough so they could be edited manually.

However, keeping the old interface should not hinder us to improve the interface and make it more consistent in itself and with what is used in other templates.

{{iwl}} would be free to use for a new template properly designed from the ground up, but going this route would defeat the idea of why we merged the various templates a couple of years back. So, the solution, as I see it, is to tweak and "smooth out" the existing interface as much as possible, that's why I also added aliases like |i= and |q= so that it looks more consistent. However, I would be just as happy with fading out |v= and |s=.

Do you have a good alternative suggestion for |external=?

--Matthiaspaul (talk) 12:38, 20 February 2022 (UTC)

To reduce the number of aliases I have meanwhile removed the new |pre(n)= and |ext(n)= variants, as well as the |lt-lang= alias. By the very purpose of this template, we will have to specify at least one prefix (through named or unnamed parameters), and the language of the local label text is optional. However, in many cases the language would be the same as the specified prefix. The interface logic has now been enhanced so that, if the definition of a prefix was omitted, the prefix will be assumed to be the same as the label language, if this is specified, thereby avoiding the redundancy of having to specify the same value twice. Thereby, all combinations are possible to specify with the minimum of parameters. --Matthiaspaul (talk) 15:01, 20 February 2022 (UTC)

Arbitrary break

The name of param |lt= was once cryptic to me, too, until someone pointed out that it stood for "link text", which makes sense. Other templates unrelated to this one that need a param that serves the same function tend to call it |disp= or |display= which is less cryptic, but then so is "link-text". And I'm fine with aliasing any of those to it. One can push for clearer, less cryptic invocations in the future simply by appropriate changes to the doc page naming the clearer name as the param name, and relegating 'lt' to a parenthetical description as an alias. Mathglot (talk) 20:29, 20 February 2022 (UTC)

I thought |lt= would have been derived from "label text" rather than "link text". The documentation for piped links uses [link|label], [link|text] or [L|D]. Unfortunately, our template already uses |display= as an alias for |preserve=. Going through existing uses, I also found typos like |text=, |label=, |name=, |Lt=, |tl=, |t=, |lit= and |l= being used in {{ill}} templates in the wild instead of the correct |lt= one, that's why I added |text=.

--Matthiaspaul (talk) 22:29, 20 February 2022 (UTC)

I actually call that field a 'source anchor' (or just 'anchor' for short) and not any of those terms because that's what W3C does, but WP has a somewhat different conception of 'anchor', so we can't use that. If you do "fade out" any existing params, I assume you mean removing them from the doc page but not the template itself, unless you are planning a bot to adjust existing transclusions. Mathglot (talk) 22:55, 20 February 2022 (UTC)

Incidentally, your point about bots is exactly the reason why I am generally opposed to having more than one named parameter for any given function - not only are there more options for people to screw up the parameter anyway, if ever we get to the point where a parameter needs changing or other alteration, we have to code in that many exceptions for the various potential alternate names that we've created. I'll try to remember where it was, but a year or so back we had a really productive discussion (somewhere) about the pros and (mostly) cons of multiple parameter names. Primefac (talk) 08:20, 21 February 2022 (UTC)

I see your point, but on the other hand, adding aliases to a list of supported parameters in a bot is really trivial (it just needs to be done, so, if there would be dozens of bots involved, it still creates unnecessary maintenance overhead - ideally the interface would be mostly static in order to avoid frequent changes).

If the alternative names "catch" at least the most frequent unsupported parameter names people enter anyway (because for some reason it's in their mind model about the template), it can also help to save their time and improve the usability ("do what I mean"). I can see pros and cons for both, having alternative parameters and not having them. I think, an "ideal" parameter name would be self-explanatory, easy to remember and matching what users would come up with by themselves, not being too specific but also not too unspecific, and as short as reasonably possible. Often enough, this cannot all be had in a single parameter name. Some people are very good at memorizing abbreviations (mnemonics), some are very bad at this, so to serve them both, it's good to offer alternatives for both of them for as long as they nicely integrate into the interface as a whole.

--Matthiaspaul (talk) 13:00, 21 February 2022 (UTC)

Whatever you do, please don't remove or change existing parameter names, as that breaks old revisions. Removal of parameters or aliases is harmful. Not adding them unless really needed helps avoid this harm. —Kusma (talk) 08:33, 21 February 2022 (UTC)

Don't worry, by "fading out" I didn't mean to remove them, just deemphazing those which don't fit well into the interface as a whole. Since we are developing an existing template rather designing one from scratch, we have to live with its legacy. But at the same time it shouldn't keep us from improving the template, and if there would a small hill to climb to reach the green meadows, it might be worth it. There could be low-priority "clean up" tasks, so that when an article gets edited anyway deprecated parameters could be replaced by the better ones. But I'm not into the bot business, so that would probably be a slow process over the years, nothing abrupt.

--Matthiaspaul (talk) 13:00, 21 February 2022 (UTC)

Just as a point of interest, I will always support unnamed parameters over named parameters if there is a clear and obvious use-case for them. This template is a perfect example of that: {{ill|link|lang}} is fast and easy to type out, and I shouldn't need to remember parameter names. Again, I have zero issue if the consensus here is that we need to have named parameters (though I personally think they are unnecessary), but I will oppose any attempt to deprecate the unnamed params. Primefac (talk) 13:14, 21 February 2022 (UTC)

I mostly agree with you. They can be nicely short and are often even intuitive if there is some underlying "natural" order of parameters so that you would add more parameters only when you'd have to deviate from the "natural" defaults otherwise assumed. Your example {{ill|link|prefix}} is still nicely short, but it also starts to shows the dilemma: From the way how interwiki-links look like, some people would find {{ill|prefix|link}} more natural (as per past discussions), and it becomes somewhat arbitrary when a 3rd argument is being added. Is it to override the local label text (as in a piped link), or to override the foreign article title, or even for the next prefix in the row? Different people will assume different things here (as past discussions have shown), so this is where it stops being intuitive and where named parameters are easier to use. And, as Mathglot has pointed out in another thread, in the case of this template, in extreme cases we could have rows of 25 unnamed parameters - that's nightmarish to maintain ("Why doesn't it work? Did I miss a pipe somewhere? And which parameter is for what?"). So, yes, unnamed parameters are great sometimes, but named parameters are great as well. I guess, that's why we have them both (and should continue to support them both).

And for fast and easy to type out, that's why some people like to have one-letter parameter names, whereas others do not find them intuitive. I take that as different editors having different needs/preferences and think that's perfectly okay.

--Matthiaspaul (talk) 14:59, 21 February 2022 (UTC)

To me, a big part of template usage is how intuitive the documentation is, and it just looks pretty unintuitive now and I'm worried we'll scare away new users. And to me, prefix is part of that, when it's a language code in almost all cases. Mathglot (talk) 08:56, 22 February 2022 (UTC)

The documentation is a mess, and it's been a mess since before we even merged everything together. For a template that is as (relatively) straight-forward as this template is, the documentation is hella convoluted. I think the primary issue is that we try to explain in prose what we should just do in examples (which is what almost every other template does that I watch/edit). Primefac (talk) 09:08, 22 February 2022 (UTC)

I've created a sandbox for the /doc so that I can make major changes without disruption and to get more feedback. I'll start a new thread for feedback discussion. Primefac (talk) 19:54, 22 February 2022 (UTC)

I think that the term |prefix= is quite accurate to describe the colon-separated prefix (or prefixes, as there can be several of them, i.e. wikt:de) in front of a wikilink. (Prefixes are also used for pseudo-protocols.) It is important to distinguish these link prefixes from codes to specify the language of the label text, because they are different concepts following different rules.

In contrast to prefixes, actual language codes can have additional specifiers to distinguish between language variants (i.e. "he-LA" describes Latin jargon in Hebrew) or scripts ("ru-Latn" specifies Russian written in Latin script), etc.

It is true that many prefixes specifying foreign-language entities of Wikipedia were assigned based on existing language codes at that time so that, in simple cases, many of the codes are identical (for example, the German Wikipedia uses a prefix "de", and "de" is also the (default) language code for German). But not all foreign Wikipedias use a prefix identical to the language code of the corresponding language (as an example, the Alemannic variant of Swiss-German Wikipedia uses a prefix "als", which is the official language code for an Albanian dialect (quite a difference!), whereas the actual language code for Alemannic is "gsw").

What might confuse readers is that, in the current template documentation, we incorrectly use the term "language code" also for the prefix codes. Instead we should start to properly distinguish between them.

--Matthiaspaul (talk) 22:32, 22 February 2022 (UTC)

The term prefix is a terrible choice, even if it is accurate in some sense. I don't agree with the last statement about "language code" vs. "prefix code". This is true only very narrowly: yes, there are non-language prefix codes such as wmf:, m:, wikt:, mw:; even phab:, wikia:, meatball:, and others. How many people come here for that? Not one in a thousand, or ten thousand. This template is the Interlanguage link template, and nobody comes here to link to any of those non-language prefix destinations, they come here to link to natural languages like French, Spanish, or Russian. Even though the geekiest of Wikinerds and template writers (like us) know that we can actually use it as a non-language prefix and perhaps take great delight in linking to meatball wiki. The addition of the named parameters |prefix= is not an improvement for anybody who has used this template in the past, and it will only confuse new and occasional users who come here in the future, to a template called "interlanguage link", to find no language parameters at all but a whole pile of strangely-named parameters of uncertain purpose.

We could always create a new FAQ:

• Q1: "Where are the language codes?"
• A1: "They are actually called prefix-."
• Q2: "Oh? Why aren't they called lang or something?"
• A2: "Well, you see, you might be wanting to go to mediawiki, or meatball, or wikia or phabricator."
• Q3: "Um, what?"

Finally, your claim about the language codes used not being "actual language code" is a red herring. Your assertion about the "als" code being incorrect, or not "the actual code" isn't true at all, unless by "actual" you mean the ISO-639-2 code—which we do not use—as opposed to the code that wikimedia uses across all platforms, which for Allemanic is, in fact, als. This is completely self-consistent, and whether our lang-code set is identical to ISO-639, differs slightly, or is wholly different from ISO-639 is entirely immaterial and irrelevant for anything concerning this discussion.

There is no advantage to any real-word editor in using the word prefix in a parameter name at this template, unless our goal is to confuse existing users, and drive away new ones. I see a couple of approaches: undo all of the recent changes to add |prefix= parameter aliases to the positional parameters (not my choice, and not needed), or, since adding named parameters seem to be consensus and I'm fine with that, add a reasonably named parameter, like |lang=, or |lang-code=, or |code=, or |xx=, as another alias, on top of the prefix aliases. Since I don't wish to undo what has been done so far (and I happen to be in the aliases-are-good camp), I plan to add one of those aliases, or some other alias if someone knows a better one. But the current situation is completely untenable. In order not to whipsaw users who might notice changes to the doc and begin to use new parameters, only to see them disappear again in days, weeks, or months, I've removed all mentions of "prefix" from the doc page for now, until this is settled. Mathglot (talk) 05:34, 28 February 2022 (UTC)

I'm afraid, I disagree, and some of your statements are demonstratable untrue - basically all our templates dealing with languages will interpret language codes as I specified above (and you claimed to be incorrect, which it isn't) - see for yourself:

• {{lang|als|Language als}} → Language als (tooltip indicates this as Albanian)
• {{lang|gsw|Language gsw}} → Language gsw (tooltip indicates this as Alemannian)
• {{citation |title=Language als|language=als}} → Language als (in Tosk Albanian)
• {{citation |title=Language gsw|language=gsw}} → Language gsw (in Swiss German)
• {{rp|page=3|quote=Language als|language=als}} → (tooltip indicates this as Albanian)
• {{rp|page=3|quote=Language gsw|language=gsw}} → (tooltip indicates this as Alemannian)

These codes are not, in general, the same codes as those used (only) by Mediawiki for their interwiki prefixes (although, in some cases, they match): The Mediawiki prefix of the Albanian Wikipedia is "sq" (not "als"), and for the Alemannian Wikipedia it is "als" (not "gsw").

As your argumentation shows it will only confuse users to lump them together as if they were the same, in particular as in the case of {{ill}} we have to distinguish between both of them in a single template: The language of the label text (as specified by |language= or |lang=) and the prefixes of the various foreign-language Wikipedias (by |prefix=/|prefixN= or unnamed parameters).

|language=/|lang= accepts ISO language codes, IETF language tags and language names, whereas |prefix=/|prefixN= accepts only interwiki prefixes, which are arbitrary assignments of codes which just happen to follow ISO language codes in many cases but also deviate from them in many cases for various reasons. |language=/|lang= has proper range-checking so that no invalid codes will be accepted, and language names (like "German") will be converted into the proper language codes internally - as demonstrated above, this works exactly like with CS1/CS2, rp, r, lang and many other templates which take a |language=/|lang= parameter to specify a language of some kind of text. It is important, that we pass down those standardized language codes (and not some Mediawiki prefixes in disguise) because they are also used for the HTML lang= attribute, and web browsers only accept the officially defined codes. (If we would pass down the prefix codes instead, screen readers would incorrectly switch to "Albanian" pronunciation when refering to the Swiss-German Wikipedia).

Unfortunately, we cannot do this for prefixes for the very reason that they do not follow language codes exactly. Therefore, we should not use a parameter name for them which would suggest that they are identical to actual language codes. As they take different arguments, they should also have distinguishably different names.

To still make it as easy as possible for users to use actual language codes, the template implements a special case so that if a |prefix= is not defined (it normally should), a given |language=/|lang= will be used as a fallback. This works on the assumption that |language=/|lang= is conceptually optional whereas |prefix= is not, so that it is in the responsibility of the user to ensure that a |prefix= is specified in all cases where the evaluation of |language=/|lang= would result in (a correct language code, but) not the prefix of the corresponding foreign Wikipedia. So, for as long as only one foreign Wikipedia is linked to, and the label text is for a term in that foreign language, and the prefix of the foreign Wikipedia happens to be the same as that language code, it is possible to use |language=/|lang= instead of |prefix=/|prefix1=. This gives what you are looking for, but it only works in this specific case because in the general case it is not possible to derive prefix codes from language codes or vice versa.

If we would introduce |languageN=/|langN= (not |language=/|lang=) as aliases to |prefixN=, users would wonder why |language=/|lang= would take language codes, tags and names, whereas |languageN=/|langN= would take only prefixes, therefore I don't think this would be a good idea at all.

--Matthiaspaul (talk) 08:00, 28 February 2022 (UTC)

Then either let's revisit the decision to add named parameters at all, or else hold an Rfc about what the names should be. The old system with no named params was working fine; this just makes it worse. I am opposed to it because I am convinced it would dissuade users, especially new ones, from ever setting foot here, thus not an improvement to the template, and since a core value of the encyclopedia is that every edit must in some way improve things and this does not, it should not remain. To be clear, my objection is to the documentation mentioning it, I don't really care if you keep the new parameter names in the template, as long as it is not documented. Mathglot (talk) 08:27, 28 February 2022 (UTC)

I'm unconvinced and don't think users will have any problems to understand that they can use |prefix=/|prefixN= at all, because they are prefixes and are so called also in other documentation (searching for other terms I also found "interwiki prefix", "WP code", "wiki code", "language prefix", "language code prefix", "subdomain" and "subdomain prefix" being used for them). (If users would actually have problems with |prefix=/|prefixN=, they can also use the unnamed parameters - so this is in no way a step back as you put it trying to make a point.)

We cannot use |language=/|lang= (without an enumerator) for a prefix, because this parameter name is used for the language code of the text label and is basically the first choice of name for a parameter taking HTML-compatible language codes, as is established in millions of citations. IMO, it would considerably confuse (rather than help to clarify it for) users if this parameter name would be used for something different than HTML-compatible language codes in this template, and even more so, if the actual codes are similar enough to "somehow" work in some cases, but not in others (to users this looks as if the implementation would be unreliable or bugish, which it isn't).

Therefore, whatever parameter name we choose for interwiki prefixes, it should be considerably different from |language=/|lang= so that users don't mix them up in their mind model. In theory, the enumerated forms |languageN=/|langN= would be free to use, but it would confuse users if |language1=/|lang1= would not take the same types of codes and work identical to the unenumerated |language=/|lang=, and it would likewise confuse them, if we would tell them that they will always have to specify an enumerator (1) with the parameter even if they want to deal with a single foreign Wikipedia link only (the most common case). It may not be perfect, but among the potential parameter names found and suggested I find |prefix=/|prefixN= to be by far the best one, it is spot-on, semantically correct, specific enough (but not too specific so the name works for all kinds of prefixes instead of only for language prefixes) and (in the context of this template) difficult to confuse with something else, easy to grasp and short enough to remember easily.

However, if it would help to settle the case I could agree to add aliases to |prefix=/|prefixN= named |code=/|codeN= as you suggested. |subdomain=/|subdomainN= would be another option, but is even more technical than prefix and already too specific (because a prefix can be more than only a subdomain). I find the |code=/|codeN= parameter name meaningless and highly ambiguous, but at least it is part of "WP code". The documentation should then document both and list |code=/|codeN= as an alias of |prefix=/|prefixN=, not the other way around.

In general, I think, your (IMO only) anticipated "user confusion" can be more easily addressed by explaining the different types of codes in the documentation, something I already started to work on, but can't continue until the topic is settled and the already much improved documentation restored.

--Matthiaspaul (talk) 21:47, 28 February 2022 (UTC)

I think that wall of text is confusing even for template writers, and looks like something that should be part of a template writer hack-a-thon. As for real-world new users, who are struggling to get on board with WP:Verifiability, and the five- and ten-year editors who still can't quite get the point of WP:DUE and WP:CHERRYPICKING, they will never get a clue with any of this. Unless you can get a clear consensus of users (non-template writers) here that support your argument, I'm afraid we are headed for an Rfc. There's no way this is going to make sense to anybody that isn't a member of our little club. If you want to continue with the doc, go ahead, but I'd prefer it if you did it in the sandbox, because I don't see the current form of the template lasting for any significant amount of time, and I don't want to whipsaw the users with ephemeral documentation. Mathglot (talk) 08:13, 1 March 2022 (UTC)

I think you have just removed the pointless aliases. Thanks! This template is a kludge understood by a handful of editors. It needs to be comprehensible for others who need to understand wikitext and do not need to be baffled by wacky variations in parameter spelling. Johnuniq (talk) 23:35, 1 March 2022 (UTC)

Back to lang tag

Just in case it got lost in the reams of discussion about other things, this section began 12 February, and is entitled Support lang tag, and is about using "a new |lt-lang= parameter (and an accompanying |lt-rtl= corresponding to {{lang}}'s right-to-left parameter)". It's not clear to me whether there is consensus for this, although maybe there is. In any case, it seems like a good idea and should probably go ahead.

An important sidebar to this, is the fact that there is definitely not consensus for anything else in the discussion above, in particular for any other parameter other than the two originally proposed. The very first template edit following the initial 12 Feb proposal was made, is rev. 1072875044 of 22:27, 19 February 2022 which added |lt-lang= as well as two dozen other new parameters to the template. As there is no consensus for this, it is subject to being removed, until it does achieve consensus.

In my opinion, we should start by deciding yes-or-no whether the OP's initial proposal of lt-lang/lt-rtl has consensus or not; and if so, implement it, and adjust the documentation accordingly based on rev. 1058306609 of the /doc page of 18:53, 2 December 2021, which is the last revision of the /doc prior to the lt-lang proposal at the top of this section. Once that is decided one way or another, we can then move on to the question of adding other parameters, which really should start in a new section. Mathglot (talk) 23:08, 1 March 2022 (UTC)

Survey: implement lt-lang/lt-rtl

• Support – I'm fine with the OP's proposal of these two new params. I have some concerns about not overburdening the /doc page with detail that will make it harder for naive users to find the core functionality of the template, but if handled properly (likely further down, and with a link to {{lang}}) then I'm fine with it. Mathglot (talk) 23:09, 1 March 2022 (UTC)

Yes. You can't "overburden" documentation with detail; or rather - that point of view risks coming across as elitist ("let's not tell the population what they can't handle"). What you can do, is (to avoid) writing poor documentation that doesn't properly differentiate between the forest on one hand, and the trees on the other. My point is: if "naive users" can't find "core functionality" the problem is seldom the inclusion of interesting detail, only shoddy presentation. CapnZapp (talk) 10:17, 2 May 2022 (UTC)

• Support both changes, especially the addition of |text=: I happened to use this template for the first time in a while before the recent changes were reverted, I found |text= worked a lot more intuitively than |lt=. Flatly replacing |text= with |lt= resulted in this abomination: KATOTTH instead of the intended KATOTTH. Hecseur (talk) 13:52, 2 March 2022 (UTC)

  Hecseur, your first code is broken, it should be KATOTTH

  {{ill|Codifier of administrative-territorial units and territories of hromadas|lt=KATOTTH|uk|Кодифікатор адміністративно-територіальних одиниць та територій територіальних громад}} (yours) vs

  {{ill|Codifier of administrative-territorial units and territories of hromadas|lt=KATOTTH|uk|Кодифікатор адміністративно-територіальних одиниць та територій територіальних громад}} (mine)

  In other words, you have a blank parameter and it's breaking things. Primefac (talk) 16:02, 2 March 2022 (UTC)

  Oh, I completely missed it. Regardless, the label "text" is a lot more intuitive to me than an unfamiliar accronym like "lt". Hecseur (talk) 03:01, 3 March 2022 (UTC)

• Support. Although I was the one who originally proposed it I didn't really participate in the discussion because of other things that got in the way, sorry. But it seems there is some agreement now at least for this addition. ―Jochem van Hees (talk) 10:38, 25 April 2022 (UTC)

Edit request

There seems to be consensus for the addition of the |lt-lang= and |lt-rlt= parameters, with as far as I can tell no one having a problem with it (most of the discussion above was about something else). An implementation has been ready and tested for months on this sandbox revision. ―Jochem van Hees (talk) 21:38, 1 May 2022 (UTC)

In the spirit of how the edit template states "This template must be followed by a complete and specific description of the request", can I ask you to summarize what these parameters are meant to do (what problems are the edit supposed to fix?) so "an editor unfamiliar with the subject matter" does not have to hunt for those details above? (Please don't take the programmer's view that code is self-documenting :) Cheers CapnZapp (talk) 10:19, 2 May 2022 (UTC)

Oh, yeah. So, for accessibility reasons, foreign-language text should be put in a {{lang}} tag per MOS:LANG (see its documentation about what it is used for). However, {{ill}} currently doesn't really work well with that template, which is a problem if you have foreign-language text in an interlanguage link (e.g. on the page Austria-Hungary there is Landesausschuss , which is a German word so it should have a lang tag). To make this possible I proposed two parameters, |lt-lang= and |lt-rtl=, which correspond to {{lang}}'s |1= and |rtl= parameters. Specifying them puts a {{lang}} tag around the link text for you. So in the example above you'd add |lt-lang=de to indicate that the link text is in German. ―Jochem van Hees (talk) 20:22, 2 May 2022 (UTC)

Hmm. This makes it considerably more involved to post a proper ill link. Not sure I like it. (I'm not against the voluntary usage, and I certainly do not oppose making it possible to make life easier for disabled people. However, I feel the next suggestion is only a step behind, that is, to make it mandatory - since, after all, all links to foreign-language Wikipedias contain foreign language (duh!).

Thus I suggest we encase the foreign-language link in lang tags per default (no need to specify BOTH |de and |lt-lang=de), so in many cases no "lt-lang" malarkey is needed. Note: you are still free to implement them as far as I am concerned; if they are supplied they should of course override the default. But in your example case, the worst that could happen (=if the user forgets or can't be bothered to supply lt-lang parameters) is that the entire "Landesausschuss (Österreich)" is encased within lang tags instead of what you desire, just ""Landesausschuss". Making this the default would go a long way in deflecting future complications from adding what you propose to add. Thanks! CapnZapp (talk) 06:19, 3 May 2022 (UTC)

The default is that the link text is written in English. If several interwiki links are given, there is no way to guess the language. —Kusma (talk) 06:37, 3 May 2022 (UTC)

Hm that's a good point. However, there are currently also a lot of interlanguage links that have English-language link text; for example on Eurovision Song Contest 2021 there is the link Rotterdam City Hall. And there's also a lot of links that are people's names which I think don't have to be tagged with {{lang}}. So making it on by default would mean we'd still need to do a lot of edits to turn it off on all those pages. ―Jochem van Hees (talk) 11:41, 3 May 2022 (UTC)

I would strongly oppose any changes to the default behaviour. I think your suggestion of optional parameters to incorporate {{lang}} if and only if necessary is much better. —Kusma (talk) 11:48, 3 May 2022 (UTC)

I was led to believe we were discussing the article title of the foreign-language wikipedia page, but whatever. Looking at Austria-Hungary I far prefer the solution district (Bezirk) where any usage of lang tags would be restricted to an "inert" term (a black not-a-link): if the article didn't already exist you'd have District (Austria). I now understand it isn't the foreign-language link you want lang'd. It is the English-language link (normally red), except here the article title is translated into English so no lang is needed. CapnZapp (talk) 14:36, 3 May 2022 (UTC)

 Already done. The sandbox version linked above made by editor Mathglot has already been implemented. That sandbox version was copy/pasted to the live version and previewed (actually clicked on "Show changes") and there was "no difference". There may still be a need for more discussion if any other edits are wanted. P.I. Ellsworth - ed. ^put'r there 14:41, 22 May 2022 (UTC)

@Paine Ellsworth: whoops, it seems I linked the wrong revision, sorry. I updated the link. ―Jochem van Hees (talk) 23:05, 22 May 2022 (UTC)

Okay, "already done" has been struck. All test cases are green; can more be added to show diffs between the sandbox and live template? (I've placed that version in the present sandbox.) Also, will this be a significant enough edit to inform the bot operators? P.I. Ellsworth - ed. ^put'r there 23:36, 22 May 2022 (UTC)

article name conflicts on local Wiki

Arguably, this overlaps with #Option to remove enwiki link, but I'll both indicate the needed enhancement as well as suggest the "best available alternative" given the existing template.

The limitation of the existing template is that there's no provision to have a displayed name for the link, separate from the putative name of the article on enwiki. Of course, given that it's a putative name, the first thought would be to just specify displayed name in the first field. This works as long as there isn't a pre-existing article on enwiki with that name.

The workaround for this is to use a standard inter-wiki link, but then the link which is normally red will appear in blue, and the language code needs to be explicitly added. This has the limitation of working for a single language for the interwiki link. This also will not be subject to the feature of being automatically removed when the article becomes available on enwiki. Fabrickator (talk) 19:41, 30 September 2022 (UTC)

As usual, an example would be helpful. The template does have a parameter for "displayed name", |lt=, so it's not clear to me what the problem might be. -- Michael Bednarek (talk) 02:01, 1 October 2022 (UTC)

I understand why some template editors feel that aliases are not ideal (see previous discussions) but I believe we should place the needs of template users ahead of those of template editors, and this is an example of why. Imho, if we aliased |disp= or |display= to |lt=, we would not be having this conversation, and I'd support adding such an alias. Mathglot (talk) 10:21, 1 October 2022 (UTC)

First off, thanks to User:Michael Bednarek for pointing out |lt=. I had actually tried to use that at some point, but (trying to reconstruct what may have happened that caused me to avoid it) I apparently ran into some difficulty with it, and perhaps had some uncertainty as to what this was really supposed to be used for. One thing I note is that in the example, the article name includes a parenthesized description, and given that the use case is specifically that the article doesn't exist on the local Wiki, it kinda sorta doesn't make sense. Then trying it anyway, without being confident about what the intended use case was, I might have run into the problem that by omitting the article name for the target wiki, it might have seemed non-obvious what this would default to, so I just decided to use the workaround of a standard interwiki link.

So thanks to your reply, I had greater confidence that this was in fact appropriate to my use case, and went back and fixed things up for each of the relevant links that I added on Academy Award for Best Documentary Feature Film. Fabrickator (talk) 04:22, 2 October 2022 (UTC)

Order of parameters

I find it hard to use this template when the orders of parameters here and in c:Template:Interlanguage link differ. Perhaps something should be done about this - to make it easier for users. I hope a central repository will soon be available for template messages.[1] --TadejM ^{my talk} 06:30, 8 January 2023 (UTC)

Given that this template is actively maintained (and used more than 261 times) the onus is probably on Commons to update their template to match, should it be that large of an inconvenience (which, given the aforementioned lack of use, is probably not the case anyway). We have had multiple discussions here about the parameter order, and so I highly doubt we'll be changing it here again (never mind then having to update 143k+ uses). Primefac (talk) 07:06, 8 January 2023 (UTC)

Ok, thanks for the clarification. In view of the numbers and the existing discussions, I agree that this would be easier to fix in Commons. On the other hand, perhaps there will be objections too, so the best chance may be to wait for a central repository. However, it should be done. --TadejM ^{my talk} 07:25, 8 January 2023 (UTC)

There is an already existing proposal on Commons and I've added my support for it.[2] I'm going to fix this on Commons if there is no objection. --TadejM ^{my talk} 07:33, 8 January 2023 (UTC)

On the other hand, I wonder why there is inconsistency in the order of parameters between {{Interlanguage link}} and {{Translated page}}. In the first case, the language code comes first, while in the second case, it comes second. The template on Commons is better in this regard. 🤔 --TadejM ^{my talk} 08:39, 10 January 2023 (UTC)

I have no trouble seeing how inconsistencies might crop up in any sufficiently large organization, but that's maybe just me. CapnZapp (talk) 13:37, 10 January 2023 (UTC)

I agree, but we should strive to remove such inconsistencies when noticed to make the work as easy as possible. --TadejM ^{my talk} 10:01, 13 January 2023 (UTC)

I did not comment on whether these circumstances merit being called "inconsistencies" or whether they need to be "fixed". I was commenting on you wondering why the "inconsistency" exists - I find that to be completely natural in circumstances where significant number of people make unrelated improvements and in no way necessarily implying wrongdoing or negligence on anybody's part. CapnZapp (talk) 18:22, 13 January 2023 (UTC)

The order is the same, just {{ill}} has an additional parameter in front, the page title on the English Wikipedia. This is followed by language code and page title on a foreign Wikipedia. It only looks inconsistent in cases where the titles are identical (common for biographies), because the foreign language title defaults to the English language one and so the template can be used with what looks like reverse ordering. —Kusma (talk) 10:14, 13 January 2023 (UTC)

Well, yes. It would be more tidy and simple if these templates looked more consistent. It is much easier to remember the rule that the language code always comes at the beginning than a number of exceptions where this is not the case. I have found some other similar templates using a 'language code' parameter (e.g. {{lang}}, {{wikt-lang}}, {{verse translation}}, {{expand language}}, etc.}}; I may create a category. They all seem to place the language code parameter at the beginning. --TadejM ^{my talk} 12:58, 13 January 2023 (UTC)

TadejM, there may be an issue here of how you are viewing what goes on with this template wrt the order of the elements. I would argue that the language code parameter *is already* at the beginning, just as in those other templates you mentioned, and just as the language code is at the beginning in a sister link to a foreign wikipedia, such as in [[:fr:Tour Eiffel]] ⟶ fr:Tour Eiffel.

Kusma pretty much already said this, but here is another way to look at what (I think) he was saying. Here is what I mean: how would you code an {{ill}} link for the French article fr:Tour Voltaire, which does not yet exist in English? I think it would be like this:

{{ill|Voltaire Tower|fr|Tour Voltaire}} ⟶ Voltaire Tower

                     ^^ ^^^^^^^^^^^^^

                  [[:fr:Tour Voltaire]]

So the way I see it, it *is* in the same order. What's different, is when the French and English titles are identical, then the template allows you to save typing by dropping duplicate names. If we write the canonical {{ill}} template for the Poet "Touria Ikbal", then it would look like this:

{{ill|Touria Ikbal|fr|Touria Ikbal}} ⟶ Touria Ikbal

But, if you write it using the "shorthand method", then it looks like this:

{{ill|Touria Ikbal|fr}} ⟶ Touria Ikbal

Notice that the generated link on the right is the same both ways, the template recognizes them as identical. So, even in the second case, the language prefix is still "first", it's just that it's "first" in front of an object removed because it's a duplicate. Maybe you can think of this in the same way that English allows us to eliminate duplicate pronouns:

"He went upstairs and he went to bed" ⟶ "He went upstairs and went to bed".

That sentence consists of two independent clauses joined by and, but in the second one, "Went to bed" cannot be a standalone sentence all by itself, but in a compound sentence joined by the conjunction and, the rule (linguistic transformation, if you prefer) says that you can drop the subject pronoun in the second (and subsequent) independent clauses if it is (they are) the same as the subject pronoun in the first clause ("He went upstairs"). So what we have in English, is a shortening rule when two things are the same. Do you see where I'm going with this?

If you can rejigger the way you look at {{ill}} parameters, and think about it as "the language prefix always comes first", and that there's a transformation rule that drops the language prefix when it's the same as the one in the "first clause", then maybe you won't have a problem any more remembering "which one comes first". One more example, to cement this new way of looking at it: consider Italian violinist Luigi Madonis, who has an article in several other language Wikipedias, but not English. The canonical form (without "duplicate-drop transformation") would be:

{{ill|Luigi Madonis|ca|Luigi Madonis|de|Luigi Madonis|ru|Мадонис, Луиджи}} ⟶ Luigi Madonis

and the "shorthand" version with the transformation that drops duplicates looks like this:

{{ill|Luigi Madonis|ca||de||ru|Мадонис, Луиджи}} ⟶ Luigi Madonis

Note that the two results, with or without duplicate-dropping, are identical; in coding the parameters, only the Russian one must be kept, because it's not a duplicate of Luigi Madonis, but all the other ones are dropped. Even so, you can still see the trace of where they used to be, due to the double vertical bar characters highlighting the dropped params.

Finally, Commons is international, with no particular language having priority (at least in theory) so if it's English, then the "en" code has to go first. But this is English Wikipedia, so you can drop the "en", since English always goes first here, so why bother including it? The redlinked article to be created *always* has an implied "en" prefix, which is not necessary to include, so you can consider it "there, but dropped" if it helps you to think about it that way. So if you want, you can think of "every" {{ill}} on English Wikipedia as starting with

{{ill|en|ArticleName|fr|FrenchTitle|it|ItalianTitle...}}

with the |en dropped because this is English Wikipedia. I hope this explanation helps you view the {{ill}} template on English Wikipedia as not really having a different order than in other templates on sister projects, there are just some shorthand rules that apply here, and are taken advantage of to save typing. Mathglot (talk) 09:35, 14 January 2023 (UTC)

Hello, Mathglot. Thank you for the detailed explanation. Yes, this makes sense and it helps thinking about it this way. On the other hand, it takes quite some mental gimnastics and is not the most intuitive to think a parameter is there when it is actually not. It reminds me of learning a new language. --TadejM ^{my talk} 11:44, 14 January 2023 (UTC)

Lol; I like your analogy, TadejM. In a way, using templates can be like learning a new language (some templates more than others). And then there's writing templates, which is *definitely* like learning a new language, but I digress... Mathglot (talk) 11:52, 14 January 2023 (UTC)

"Template:Nt" listed at Redirects for discussion

The redirect Template:Nt has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 June 1 § Template:Nt until a consensus is reached. Primefac (talk) 06:44, 1 June 2023 (UTC)

Let's fix this common param-mixup trap

Here's a case of broken template results due to misuse of parameters which is very easy to fall into, which would be conceptually easy to fix, and I think we should fix it.

In a previous section, a user illustrated his "support" vote with an example, which promptly broke, as pointed out by another user, because of a misplaced parameter. Here's an excerpt from that discussion:

see excerpt       (Note: poor overflow wrapping may extend horizontal window width.)

Support both changes, especially the addition of |text=: I happened to use this template for the first time in a while before the recent changes were reverted, I found |text= worked a lot more intuitively than |lt=. Flatly replacing |text= with |lt= resulted in this abomination: KATOTTH instead of the intended KATOTTH. [[User:Hecseur|Hecseur]] ([[User talk:Hecseur|talk]]) 13:52, 2 March 2022 (UTC) Hecseur, your first code is broken, it should be KATOTTH {{ill|Codifier of administrative-territorial units and territories of hromadas||lt=KATOTTH|uk|Кодифікатор адміністративно-територіальних одиниць та територій територіальних громад}} (yours) vs {{ill|Codifier of administrative-territorial units and territories of hromadas|lt=KATOTTH|uk|Кодифікатор адміністративно-територіальних одиниць та територій територіальних громад}} (mine) In other words, you have a blank parameter and it's breaking things. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 16:02, 2 March 2022 (UTC) Note: for the purposes of this example, I have altered Primefac's response above, which in their original, did not actually show any difference between the faulty and and the corrected version, because the {{tlc}} template swallowed the double vertical bar in the faulty one, emitting only one bar, and thus hiding the fault. The correction is marked with WP:HIDDEN tags in the code above.

I know I have fallen into this trap many times. I usually find it in Preview before publishing, but not always, as sometimes the mistakenly linked text isn't as long and I might miss it. Anyone *not* seen this problem before? Anyway, we can fix it with param validation, and I think we should. The easy/lazy way is to print a bold, red error message embedded in a malformed ill at the point where we recognize it, highlighting the "bad lang code" or whatever. Better is to check first, and render the error message *instead* of any part of an incorrect ill. Adding users Hecseur and Primefac. Mathglot (talk) 22:52, 14 January 2023 (UTC)

Lang-code validation would also alert users to related problems such as the one raised by TadejM in the previous section on param ordering. Mathglot (talk)

Prima facie, all templates should perform parameter validation, but I'm not aware of simple tools for template writers to achieve that. OTOH, I habitually use |reason= when I add maintenance templates, whether they support it or not. -- Michael Bednarek (talk) 01:41, 15 January 2023 (UTC)

Likewise, re: param 'reason'. As far as param validation, could've sworn I've seen some many-param templates invoking another one to validate their param list, but can't find it now. Mathglot (talk) 21:45, 9 August 2023 (UTC)

Glyph collision on quoted italics

When we have both |quote=y and |italic=y, a collision can occur between the last quoted letter, and the ending quote mark:

• {{ill|loi Rivet|fr|quote=y|italic=y|v=sup}} → "loi Rivet "

We should insert a {{hairspace}} to mitigate this:

• (after fix) → "loi Rivet " ^[fr]

(Or, if we wanted to get really picky, only for final letters with wide ascenders, like, yes for t, but no for e; but that's overkill.) Mathglot (talk) 21:56, 9 August 2023 (UTC)

 Done. Primefac (talk) 08:18, 10 August 2023 (UTC)

Pl wiki wikidata link looks nicer?

Our template just produce a lenghty [wikidata] text. Pl wiki at pl:Szablon:Link-interwiki instead generates a smaller symbol then when hovered on expands into a list of available languages. Can we implement this?

Compare: Our article, CTRL+F for Doŭhaje, to a pl article - CTRL+F for claim jumping to see how an entry with four languages is handled. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 09:52, 22 September 2023 (UTC)

This has been discussed in passing a few times but never to the point where a consensus was reached. I do not have any super-strong opinions, but generally hover somewhere between thinking they should be removed entirely or kept as-is (as I feel [WD] is too vague). Primefac (talk) 10:41, 22 September 2023 (UTC)

I am not sure I understand what you mean by "they should be removed entirely"? (What is they). I find the pl wiki implementation much more elegant and useful than anything we offer. Since we don't seem to have a MoS preference of which format of ill to use, I think we should implement that Polish one too so people can chose to use it if they want to (in particular, I use ills and I want to se the Polish style on en wiki as giving people the choice if which language to use is superior and more neutral to the editorial decision to use only one language). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:19, 23 September 2023 (UTC)

I partly agree with Piotrus; it is an elegant solution. BTW, that link in your original message doesn't help me to inspect how pl:Szablon:Link-interwiki works on PL Wiki, but the documentation of that template seems to indicate that the template only considers Wikidata items and doesn't provide a clickable link to a single interlanguage version. While I'm capable of hovering of the (slightly mysterious) icon and then click on one of the offered languages, or the only one, readers on mobile devices and some people with disabilities might have problems with that. I have no idea how to overcome this limitation; I would accept that, but I suspect it won't find sufficient general support. Further, our current solution here only needs the name of an article in a different language (and if other languages exist, readers can find them there), but the Polish solution requires the editor to find the Wikidata QID. -- Michael Bednarek (talk) 04:17, 23 September 2023 (UTC)

I think the link in question should be pl:Skalny_nurek; in the §Fabuła section you get a popup with four other language links. Primefac (talk) 06:56, 23 September 2023 (UTC)

This is pretty, but not very accessible, and I prefer linking to the most suitable languages only (the other language links will then be visible at the pages in other languages). —Kusma (talk) 16:41, 23 September 2023 (UTC)

@Kusma Sometimes it is hard to know what is the most suitable language. Think the cases where a topic is connected to multiple countries/ethnicities/etc. and folks edit war about it. Wikidata offers a neutral solution to potential npov issues here. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:59, 24 September 2023 (UTC)

As for the editor workload, I'll note that editors can chose which variant to use (one language or QID). Unless we have a MoS preference, which I am not aware of. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:58, 24 September 2023 (UTC)

"They" was referring to "links to WD in the article space". Primefac (talk) 06:57, 23 September 2023 (UTC)

My recollection is that the prohibition specifically regards WD links from the article text, as distinguished from, for instance, WD links from an infobox. The rationale for prohibiting WD is that some articles on non-English wikipedias might be in contravention of English Wikipedia standards. This is discussed at Wikipedia talk:Manual of Style/Archive 202#When (and how) SHOULD we link to Wikidata?]]. Fabrickator (talk) 07:36, 23 September 2023 (UTC)

I don't see any "prohibition" in that sub-thread nor in the closer's comments. Rarely, I have added {{ill}} links to Wikidata only because they were the only ones with some information. Normally, I chose a suitable language to link to, based on context and the prima facie quality of the foreign article; sometimes, I link to more than one. -- Michael Bednarek (talk) 08:04, 23 September 2023 (UTC)

First off, the discussion revolves around a (for me) newly implemented usage of the template, as exemplified by {{ill|Doŭhaje|WD=Q13133293|reasonator=1}}. Personally, I don't like this. I consider it a strength that people choose one and only interwiki link. Why? Because the point of this template is not to provide a complete menu of other languages covering the subject. The point of this template is for an editor to say "while we don't have an article on this subject, we recommend this other language that does". Any time a reader wants the answer to the different question "which languages cover subject X?" it's not the job of this template, instead we help them using other resources (including the two-stepper: visiting the one language linked to by this template and then listing which languages cover that subject). Regards, CapnZapp (talk) 09:09, 23 September 2023 (UTC)

To be specific: offering a menu of every wiki with an article on the subject is perhaps well-intentioned, but not a good idea. Readers are not served by getting a long list of wikis only to find out that most of them are stubs in bad condition (which is a very likely scenario). Editors are much better off by hand-picking ONE (or at most, two) languages for their ill links. I would recommend Polish wikipedia to roll back their functionality, forcing editors to again manually specify which language they link to. CapnZapp (talk) 09:14, 23 September 2023 (UTC)

I see your point, but if there are 2+ similar choices in competing languages, then wikidata seems to be the logical solution, pending the development of some smart script which would always chose the longer / more highly assessed article. Consider the case of Doŭhaje - a village now in Belarus, historically part of Russia and Poland. I think here pl:Dołhe (sielsowiet Linowo) article is better than ru:Долгое (Линовский сельсовет) or be:Доўгае (Лінаўскі сельсавет), but I can imagine some folks being offended at "Polish imperialismn" (Polish POV pushing, etc.) if we were to link to pl wiki over be. Letting the reader chose languages seems pretty neutral. Now, it might be even better if the script, without being smart, displayed the size of the article in bytes (probably easier than words) next to the language, giving the reader information on which article is likely most comprehensive. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:05, 24 September 2023 (UTC)

It seems to me that there are (at least) two separate issues being discussed here:

1. Source of links – wikidata, template coder's choice, or something else (I consider "number of links" as a corollary of this, but maybe it should be broken out as a third one);
2. Presentation – list of bracketed ISO-639 codes; a single, recognizable icon with pop-up of a list; other.

If this discussion gets much longer, maybe those could define separate subsections for further, targeted discussion.

Regarding source: personally, I'm with those who disfavor the wikidata approach, partly for the reasons stated; in particular, it shouldn't just be a menu of all languages involved. I'm actually in the #1-c group, that is, "something else". It seems the mediawiki software already knows something about my languages of interest, because it usually presents interlanguage links in the left sidebar corresponding to "my" languages. (Although, it also seems to throw in some links to languages of Wikipedias I've looked at recently, even if not one of "mine", so I'm not quite sure what the algorithm is.) In any case, if I could have my blue-sky choice, then I'd have a pop-up similar to pl-wiki, which contained a bullet list of articles in just those languages I'm comfortable reading, followed by a "27 more" link at the bottom, just like the language sidebar does. And since we're talking blue sky, I'd sort them (at my choice, configurable in prefs) by article size descending, or by my level of competence in the language. I'd be generally opposed to limiting to a single language; I edit some historical articles about European history and wars, where I'd hate to have to choose between only French or only German (and sometimes others) for the single foreign language link on an inter-linked item; so I hope we don't go there. Mathglot (talk) 05:47, 24 September 2023 (UTC)

Piotrus My position boils down to: I want the editor, not the reader, to make the choice. More accurately, I want Wikipedia to spare the reader having to make a choice. Again, a reader wanting a complete list of languages with an article on subject X is a great and natural use case, but it is a different and separate one from "here is a recommended language covering topic X until we at English Wikipedia do". This template should not attempt to be useful in both use cases. Ideally, this template should actively discourage editors from leaving the choice up to the reader. CapnZapp (talk) 07:10, 24 September 2023 (UTC)

To add: I'm a programmer myself - I am fully aware I often want to use a nifty feature just because it exists. That thingamagog over at Polish Wikipedia looks and works great! I just believe it is not in the best interest of our project to offer this functionality in this context. Best regards, CapnZapp (talk) 07:26, 24 September 2023 (UTC)

Mathglot Your distinction appears reasonable; if you want to restructure these discussions - go ahead! CapnZapp (talk) 07:10, 24 September 2023 (UTC)

More generally, "leaving the choice up to" always comes across as the more neutral and user-friendly choice... at first. It is when you consider our job as editors you realize it means abandoning our job as curators. Wikipedia is not meant to be an indiscriminate collection of stuff. This is true at every level... including here. Every time a human like you, the editor reading this, make an editorial choice, Wikipedia is better off. Do not let the specter of edit wars cloud your judgement, by which I mean, that "leaving the choice open means less editor warring" is an exceptionally weak argument. The whole point of coming to Wikipedia is to have the work done for you! An encyclopedia is a catalog... with the choices already made for you. We're meant to handle and contain edit wars, and not give up (which is what not being able to choose for the reader really amounts to). And oh; just because something is technically possible does not mean it is a good idea.

I am sure it is possible to construe a corner-case where it is indeed better to offer a list of 27 languages, but that should not obscure the basic fact that in 99% of cases, I am certain the best solution is for a reader to be recommended a single language, with that choice being made by YOU. Best regards, CapnZapp (talk) 07:22, 24 September 2023 (UTC)

First, I want to point out that the WD parameter has been part of {{ill}} since this template was introduced in 2013. FWIW, there's a small percentage of existing {{ill}} templates that use WD. Second, unless somebody identifies the place where the consensus to prohhibit including wikidata in article text was overturned or there is a successful effort to overturn that consensus, this discussion will become moot.

Nevertheless, I want to explain my strong preference on using WD as compared to having the editor make the decision of which language version(s) to offer.

• Every enwiki user has their own level of familiarity with other languages. For instance, while I am not actually fluent in any other languages, I'm likely to prefer Spanish because I have some familiarity with that. OTOH, I'm going to avoid languages that are written in a non-Latin script. Sure, we have convenient in-browser translation, but it has its limitations, and at some level, it can't really be trusted.
• Each reader who clicks on a wikilink will have their own unique interests regarding a given topic. It's presumptuous to try to make an educated guess about what their interests are, so we can't judge which version will best address those interests.
• Expecting the editor to look over various language versions of the article is simply burdensome. We generally encourage addition of wikilinks; the fact that an article is only on a different language wiki makes the wikilink that much more helpful to the reader, due to the extra effort that would otherwise be required for the reader to find it. Trying to put this decision on the editor is simply counter-productive.

Fabrickator (talk) 18:23, 24 September 2023 (UTC)

Second, unless somebody identifies the place where the consensus to prohhibit including wikidata in article text was overturned or there is a successful effort to overturn that consensus, this discussion will become moot. Nobody is arguing to prohibit wikidata or overturn anything. You're setting up a straw man. Please don't attempt to dismiss discussion as being "moot". CapnZapp (talk) 21:11, 24 September 2023 (UTC)

This discussion is partially moot, since it is going on off tangents with people saying why they like or dislike linking to wikidata, which is an issue for MoS RfC to consider if someone really cares to create an enforceable rule. All I wanted to do was to point out that pl wiki codes seems elegant to me and ask if we can copy it here. Extra props for making it even more functional (particulary some ideas by Mathglot above, tied to ordering languages by the same code as current algorithm for interlanguage links for article does, seem very nice and codeable, and I think my idea of adding article size also could be implemented without too much trouble). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 00:26, 25 September 2023 (UTC)

Nobody is trying to create an "enforceable rule". You are free to ignore any tangents but you don't need to make statements such as "This discussion is partially moot" to do so. The tangents can be ignored; the discussion remains relevant. CapnZapp (talk) 12:53, 25 September 2023 (UTC)

The pl wiki codes are indeed elegant, but I want to question whether they are actually helpful. We should not do something just because we can, or because it looks elegant. If a reader is better helped by you (yes you, Piotrus) hand-picking the most relevant interlanguage link, then you should do that instead. That does not mean I want to remove the functionality, just that we should not uncritically adopt new functionality. Regards CapnZapp (talk) 12:53, 25 September 2023 (UTC)

• Regarding topics for which there are articles in multiple languages of roughly equivalent quality -- the template does currently allow you to link to multiple language. This likely would be preferable to presenting an undifferentiated list of all languages with an article. older ≠ wiser 18:39, 24 September 2023 (UTC)

It does kind of feel like that the discussion has become unfocused due to the second topic, which probably should have had at least its own subsection header, and perhaps a whole new discussion; but I guess we are where we are, at this point. As far as the second issue involving adding text to the template about recommended languages, I think it's just a solution in search of a problem; why not just let users use it the way they wish to, and let consensus at each article work out what's best for their topic? I don't see why it needs us to add doc verbiage to restrict the usage to the particular intent in the mind of the user who placed it. And why should a recommendation of one editor trump the dozens or hundreds of editors who volunteered their time contributing to some homologous foreign article—isn't that an implicit recommendation by many? Personally, I don't like the Reasonator option so I never use it, but I'm not going to tell someone else not to, and I don't really need anyone to tell me not to. Back to the OP: I think using the pl code does look elegant, and if there's interest in that, plus maybe some of the other ideas, then it's worth a wider discussion. Maybe at the idea lab? Mathglot (talk) 09:19, 30 September 2023 (UTC)

a solution to a problem indeed. Can those who propose a stricter wording in the documentation point to cases that would warrant that? Even if, wouldn't it be more in the collegial spirit of Wikipedia to discuss it where it happens? -- Michael Bednarek (talk) 10:29, 30 September 2023 (UTC)

Red link option

Per discussion at WP:WikiProject Templates, I was asked to leave my comment here: The usual Template:Ill for David Alpert looks like this: David J. Alpert ({{ill|David J. Alpert|de|David Alpert}}) but would it be possible to add an extra argument to the template so that no red link appears for the English Wikipedia link. Something like {{ill|David J. Alpert|de|David Alpert|redlink=none}} so that it looks kind of like "David J. Alpert ." (without the period). I came up with this need after a debate we are having at WP:WikiProject Physics. Even if it enforced to show the red link it would be a nice option to have. ReyHahn (talk) 20:58, 12 October 2023 (UTC)

A related discussion was at Template talk:Interlanguage link/Archive 4#Option to remove enwiki link. I oppose such an option because it would negate every positive function of this template. If editors elsewhere (Electron diffraction?) form a consensus to use a different method, they are of course free to do that, although it's not clear to me that all discussants at Wikipedia talk:WikiProject Physics#Links to people are aware how {{Interlanguage link}} works. Further, future editors might be baffled by non-standard links and change them to more familiar constructs. -- Michael Bednarek (talk) 02:13, 13 October 2023 (UTC)

Oppose. H:FOREIGNLINK has a clear "best practice" which should be used unless there's a very good reason not to. Wikipedia is full of WP:REDLINKS and current policy is not against them (indeed they're encouraged in many situations). Making this change because a user finds red links "distracting" seems crazy to me. Perhaps there could be a user preference to hide them but that's a global issue for Wikipedia, not a specific template issue. Nigej (talk) 06:00, 13 October 2023 (UTC)

Thanks for the response I did not know that discussion. The thing is that H:FOREIGNLINK leaves to much room to wiggle. It provides about 9 options on how to deal with red links. I was trying to find a compromise between using links like David J. Alpert (hidden link) and the red link in David J. Alpert. I still think the option could be helpful when users insist on color preferences. Otherwise I think that H:FOREIGNLINK should be more strict, if we are all going to be enforcers of Template:ILL better make it a straightforward guideline and not a 9 option menu.--ReyHahn (talk) 08:41, 13 October 2023 (UTC)

I have submitted my concerns on H:FOREIGNLINK in the current discussion at Help talk:Interlanguage links.--ReyHahn (talk) 09:03, 13 October 2023 (UTC)

I will add a comment here that I have also made elsewhere -- browser translation is moving fast, so conclusions from as little as a year ago may already be obsolete. I routinely look at foreign pages, both inside and outside Wikipedia; a few days ago I used a ChatBot to get help on a Korean page. The lines between different language Wikis is probably already blurred, and will get more so within a few years. While redlining non-English was appropriate in the past, my crystal ball says it is Gen X/Y. Ldm1954 (talk) 09:45, 13 October 2023 (UTC)

But why obscure the fact that no English language article exists? Using ill with the redlink provides access to non-English wiki articles AND also clearly indicates there is no English language article. older ≠ wiser 10:50, 13 October 2023 (UTC)

Note to User:Ldm1954 regarding "While redlining non-English was...": it isn't the foreign-language link that displays in red, and the purpose isn't to warn against surfing there. The red link is for the English Wikipedia destination, and the red color is to alert you to the fact the destination does not exist; the article isn't created. Please view {{ill}} as a very helpful template that makes it clear a) the article subject is worthy of an article, b) that English Wikipedia has no such article (yet) c) that you are welcome to create it, and of course d) here's a recommended foreign-language article (or two) on the subject to help out until an English-language article can be written. CapnZapp (talk) 19:45, 15 October 2023 (UTC)

While your point above is valid in terms of building Wikipedia, it is not for providing useful information to a reader. Providing useful information to a non-expert reader has to come first, I don't think you or others will disagree. The little "[de]" (or similar) that is a link to an existing article will be ignored or confuse. Normal html/Wikipedia conventions indicate that the de will open a page on Deutsche or similar.

I don't think it can be defended as viably telling the reader to click on it for information on the person/topic that happens to be in another language. Other options are all much more reader friendly. Ldm1954 (talk) 21:20, 15 October 2023 (UTC)

Which option is more reader friendly? Red links are generally a Good Thing because they show the reader that Wikipedia is not complete. Readers have successfully ignored them (or filled them) for the past 20 years. The {{ill}} is a bit of a compromise that displays additional information to the curious reader, who may or may not read other languages that may or may not have good machine translation available. —Kusma (talk) 21:54, 15 October 2023 (UTC)

Sorry, you misread my response, the red is not central. It is the de which is completely unconventional and not useful to the non-expert. Ldm1954 (talk) 22:14, 15 October 2023 (UTC)

Addendum: this discussion has fragmented far from the points I originally raised in WT:Physics#Links to people, which was not about the red, which ReyHahn raised here. My original focus then (and now) is how to provide best information for readers, WP:RF, when there is no good English Wikipedia article but one elsewhere. I think {{ill}} is not good for readers, it is good for editors. Somehow the discussion has evolved to there now being a proposal in Help talk:interlanguage links to remove every alternative except {{ill}}. I disagree with this, but currently I am outvoted.

Separate, but related, in all such discussions I think it is important the recognize that, for better or worse, browser language demarcations are starting to vanish. This effects this template, but also has wider implications. Ldm1954 (talk) 22:41, 15 October 2023 (UTC)

I am sorry if I have misread your intentiions. I was trying to offer a solution, but even if an {{ill}} wihout red links does not work for you then I do not know what else can be done? Maybe work on an alternative template? If not I am mostly agains the other solutions. See my vote in H:FOREIGNLINK talk.--ReyHahn (talk) 07:10, 16 October 2023 (UTC)

User:Ldm1954 regarding Normal html/Wikipedia conventions indicate that the de will open a page on Deutsche or similar. It does open a page on the German Wikipedia?! I'm not sure what the problem is. If, for instance, your problem is you don't think the template is useful at all (to a non-expert reader) then please frame the discussion that way! Currently, people are believing you are arguing constructively to improve the template, and agree on its basic usefulness. If something else is the case then you have chosen a very ill-advised starting point. CapnZapp (talk) 14:03, 16 October 2023 (UTC)

In response to CapnZapp, as I mentioned above, this discussion has fragmented way beyond what it originally was, and my original question and argument has been somewhat misrepresented. I made no original post here on this template, and I never suggested a change to the template or removal of the redlink. What I objected to (in Help talk:Interlanguage links) was a proposal to remove all alternatives to {{ill}}. I still disagree with that.

Let me try and repeat just my main issue with {{ill}}, and why I prefer the alternatives in H:FOREIGNLINK. Standard html (that predates Wikipedia I believe) is that a blue Einstein is a link to a page on that topic. Being quite extreme, German physicist with crazy hair is OK for Jeopardy! but non standard. We should always be making life as easy as possible for readers. The standard {{ill}} David J. Alpert is not standard html because the de does not obviously link to the person. My preference would be to use Daniel J. Alpert (in German) or German: Daniel J. Alpert.

If the proposal in Help talk:Interlanguage links is implemented both of these would forbidden. (If you change the template to show "in German" rather than "de" that would work, a new suggestion. You can make it an alternative if you want.)

Changing topic completely, I am not enthusiastic about the use of red to encourage readers to start creating pages when a good one already exists in another language. We have all seen laughable translations. However, these are a thing of the past, and at a deeper level I personally think the concept of {{ill}} needs rethinking in the age of ever smarter AI browsers. Ldm1954 (talk) 15:14, 16 October 2023 (UTC)

We have all seen laughable translations. However, these are a thing of the past - no, no they very much aren't. Start reviewing drafts at WP:AFC and you will see tons of poorly-translated pages. Just because you have a good translator does not mean everyone does, or have the language skills to know when a translation is poor. Primefac (talk) 09:03, 17 October 2023 (UTC)

You make assertions with the air that they are simple facts, when they are not. Saying that "David J. Alpert is not standard html" is confused at best: for starters, it isn't Html at all, it is wikicode. I hesitate to read your mind, but perhaps what you meant was, you don't like the little blue [de] links, or that you don't think that's the best way to do it, or that people won't understand what the '[de]' is for. That deserves a study, perhaps, but hypertext-based web browsing has been around for three decades, and people are used to clicking things to see what they do, or just mousing over, to get a preview, so I don't think the little, blue '[de]' is too problematic for people, especially those who have a semester of secondary school German under their belt, and definitely know what it means, and are well-placed to learn something by clicking it. Those that don't know what it means, only have to skip over that brief token in order to resume the flow of the sentence, rather than more characters for '(in German)'.

Elsewhere you said, "I am not enthusiastic about the use of red to encourage readers to start creating pages when a good one already exists in another language. I couldn't disagree more. Red links are a prime source for creating new articles, and I wouldn't want English Wikipedia to stagnate, just because a supposedly better article exists in some other language. Also, the English Wikipiedia audience is different; just because an article exists in German and not in English about some topic, does not mean that we should necessarily translate the German one; it may be sourced poorly or not at all, or be written poorly, or not in a way that would engage readers at Wikipedia. The red link demonstrates the gaps in English Wikipedia, and encourages editors to fill them; I do it all the time, sometimes translating, sometimes not. The blue link tells me what's out there now, and if there are good references at the foreign article, then that is a huge timesaver, as I can just steal them and rewrite, instead of translating.

Finally, to your OP question, "would it be possible to add an extra argument to the template so that no red link appears, I sure hope not, because it defeats the raison d'être of the template. If you don't want a red link, then just don't use the template. If are hell-bent against having a red link, then grab the foreign article, translate the first paragraph of the lead into English, create an English article out of it, and now blue-link the previously red link to your new article. Mathglot (talk) 10:50, 17 October 2023 (UTC)

Yet again: I have nothing to do with the "would it be possible to add an extra argument to the template so that no red link appears". You are merging the suggestion from ReyHahn and my comments.

In terms of links, little has changed in terms of general guidelines since I wrote the first page for my students/postdocs around 1987. Quoting from this guide

"How to make the best links

1.Make the link self-descriptive

2.Make sure it can stand on its own

3.Fit it within the surrounding writing of the paragraph

4.Describe and/or include most of the page it links to

..

Make your visitor confident that the link they're following will take them where they want to go."

Sorry, but I do not see de following 1, and it is marginal for the others.

In terms of whether the article to link to is good, that has to be a decision of the editor(s). I am sure we have all decided not to include a link when we thought it was too weak to be useful.

A general point that you do not have to agree with. I view many aspects of writing Wikipedia pages as similar to writing documentation or notes for undergraduates. Documentation is really hard, you have to think of all the not so smart questions. They are not quite as hard as writing informative error messages within code for everything that unwashed users can do, but close. You have to lean over backwards, WP:RF. Some of the guidelines for WP:AfC and WP:GA try and guide reviewers in that direction, but of course are not infallible.

N.B., I must confess surprise at some of the responses. Is Wikipedia a contract sport? Ldm1954 (talk) 11:25, 17 October 2023 (UTC)

If you are dissatisfied with the responses, please reexamine the way you entered this discussion. This discussion is very hard to follow (are we having it at three places at the same time?), many different aspects are discussed in the same talk topic, etc. If I were you I would start one or more new topics, clearly outline your concern in each one, provide a clear suggestion to act upon, and only discuss one thing in each section. CapnZapp (talk) 13:58, 17 October 2023 (UTC)

The alternative to using {{ill}} is to just put an unadorned red link. The red link is the most important part to preserve, in the case English Wikipedia has no article. Encyclopedic subjects about which we should have an article should almost always be red-linked when they arise in some context where a page about one would be helpful context to readers of another page. Hopefully over time these red links turn blue. Replacing red link with red link (in French) is not an acceptable substitute.

The presence of affixed inter-language links to a red link [‍ar, fr, zh] is supposed to be an unobtrusive marker that there exist foreign-language alternatives to the non-existent English Wikipedia page. This serves two purposes: it (a) gives readers who can read the language in question or use machine translation (or even just skim the pictures) a way to learn about the subject even though we don't have an English page, and (b) it encourages readers to try translating the foreign language page(s) into English, or at least comparing them when trying to write an English article about the subject. –jacobolus (t) 19:32, 30 October 2023 (UTC)

Possible solution

@ReyHahn:, based on the above, I think it's unlikely that you'll get consensus for the exact solution you wanted based on an added parameter. However, I have a proposed solution for you which I believe will get you the behavior you want, without adding new parameters or changing the behavior for anyone else. It is this: I propose that we add a css class to the foreign-link elements, and then you can add an optional css declaration in your your common.css which will hide them, so you will never see the foreign links, but you will see the red link. Behavior would remain the same as it is now for everyone else. Would that work for you, and does anyone else object to this?

Note that a finer-grained solution is also feasible, where you could opt out of specific languages you didn't want. That's workable, albeit a bit clunky, as you might have to opt out of a dozen commonly used languages, although you'd only have to do it once. An opt-in solution would be more logical, (e.g., "only show me fr, de, and es links") which, if feasible, would require a display:none on the main foreign-link element, and display:inline *after* it on the specific languages in your common.css, but I don't know if the css priority sequencing supports this. It sounds like it might work, because "if multiple declarations have the same specificity, then the last CSS rule declaration is evaluated and applied," (link) but testing would be required. Mathglot (talk) 22:27, 30 October 2023 (UTC)

I see no reason to object to a solution where nothing changes unless you actively make a change to your setup. CapnZapp (talk) 12:54, 31 October 2023 (UTC)

ReyHahn, the sandbox now has a working version for you, but I haven't documented it yet; if you know how to use common.css, add a line .ill-group {display:none} and try it with the sandbox. Will get back to you later with details on how to try it out. Mathglot (talk) 17:57, 31 October 2023 (UTC)

@ReyHahn:, to see how this would look, edit your common.css, and add this line:

.ill-group {display:none}

After saving, be sure to reload the page per instructions in the Note at the top (under the pink box). You can then run a test comparing {{ill}} live, vs. the sandbox version, in your sandbox, at Special:ExpandTemplates, or elsewhere. Try pasting the following into your test page:

* '''live:''' {{Interlanguage link|North face of the Eiger|fr|Face nord de l'Eiger|ca|Cara nord de l'Eiger|de|Eiger-Nordwand}}

* '''sandbox:''' {{Interlanguage link/sandbox|North face of the Eiger|fr|Face nord de l'Eiger|ca|Cara nord de l'Eiger|de|Eiger-Nordwand}}

and examining the output, and you should see the top (live) example generating the links you don't want to see, and the bottom one (sandbox) generating just the red link, which is what I presume you want. Alternatively, to run this test without having to create a test page for it, just click here to run it immediately in Special:ExpandTemplates.

Let me know if this is what you were asking for. Mathglot (talk) 00:56, 1 November 2023 (UTC)

Thanks for this effort. I tried to respond earlier to this issue but my IP was banned due to a proxy issue. It is certainly a solution but I think is not what I was looking for initially and also not what the conversation has evolved into. I was against any change and I was trying to find a solution for a user that wanted some alternative (without any red links). However the user was against any modification of the template. You may check the discussion at Help talk:Interlanguage links--ReyHahn (talk) 10:53, 1 November 2023 (UTC)

@ReyHahn:, thanks for the link. I responded over there, but it seems to be about a different topic. If the user simply wants to color all the non-ill (i.e., "regular") red links black, that can be done without any modification of the template. If they want to color all ill red links black, that can be done using the same method as described above (with an appropriate line of code in common.css). What doesn't make sense to me, is why someone would make a request for some change in behavior, but at the same time be 'against any modification of the template'. Why would they care whether the template got modified, if the behavior they are seeking comes to fruition? Also, I'm a bit confused by the overlapping discussions at the two threads, and I'm happy to help find a solution if there's a problem that needs one, but I'm not sure if there is a concrete problem or not, and if there is, I certainly don't know what it is. You don't have to respond here with an explanation if you don't wish to, as I'm happy to let this drop if that's where it's heading, but if there's a specific problem (here, or there) that might yield to a technical solution of some sort (template or not), please ping me and I'd be happy to provide an opinion on it. Mathglot (talk) 01:55, 2 November 2023 (UTC)

I feel slightly obligated to respond given the effort you made, thanks again. Indeed the conversation is confusing as it was (is?) being held in parallel in three threads at once (here, in WP:PHYSICS and in Help:ILL). I contributed to that mess by adding my request here. Maybe what is missing is how my position evolved. I have always supported {{ill}}, I like to know which other Wikipedias have articles when there is none. However, I sincerely think that Ldm1954 is right in the sense that in the way that Help:ILL is currently written, there are alternatives to {{ill}} and editors can choose in between at will. I thought that Ldm1954 did not like {{ill}} because of the red link, so I was asking if we could add an option to remove the red link here (I think I was wrong, Ldm1954 does not like the sidelinks in {{ill}} either). This proposal (optional red link removal) seemed ok to me, it seems in accordance with the other unfavored alternatives in Help:ILL. After my request, we received enormous amount of feedback which seem to indicate the current version of {{ill}} not only is the preferred option but that it should be enforced against all other alternatives in Help:ILL. Now I have taken the position that if so many users agree on this, and changes to template {{ill}} are a no-go, then it is Help:ILL that should be modified to mirror the consensus.--ReyHahn (talk) 10:48, 2 November 2023 (UTC)

It is always exciting to be horribly misquoted.

For the record, this is what happened. ReyHahn make a polite and good suggestion that I add first names to people in a fairly large (140kb) article. I added many, including a Wikidata link to a very famous scientist who did not have one. Someone else, who had never previously contributed to the article barged in and (in my opinion rudely) removed the link.

I politely raised the question of ways to link to people on WP:PHYSICS, including one to a different scientist who had an external PDF orbit. ReyHahn politely pointed to the TEMPLATE:ILL approach, so I used option 5 in H:FOREIGNLINK.

Then the ¥$* hit the fan. My version was (again, IMHO rudely) changed, and I was informed, in effect, "thou shalt not use anything except TEMPLATE:ILL. Naughty boy."

So I unsubscribed from these discussions until I was mentioned by name here and, unfortunately, again misquoted.

My opinion is, and remains that TEMPLATE:ILL was a great idea until a year or two ago. Until recently every language was an island. Not now. The AI translation in browsers (and I noticed recently Gmail) is getting good, and will get better very rapidly. Just like everyone else, Wikipedia has to be able to adapt. You don't have to agree with me. Ldm1954 (talk) 13:33, 2 November 2023 (UTC)

Links to people from within the prose of Wikipedia articles should be English language Wikipedia links (possibly red links), not Wikidata links or inter-language links or external links. This is a well established consensus policy, and enforcing it is not inherently "rude". –jacobolus (t) 13:38, 2 November 2023 (UTC)

@Ldm1954: I am sorry if I have misquoted you or oversimplified your side of the story. Could you please be more explicit on where does my version disagrees with yours? As of now, I think both are compatible. Mathglot was implementing a solution but did not have all the context, I had to raise your name again because it is not possible for me to summarize the situation without quoting you (I tried to use "user" above, but that seems more impolite). I am sorry that I have involved you in this talk page I really was hoping to find a better alternative when all of this started.--ReyHahn (talk) 13:54, 2 November 2023 (UTC)

ReyHahn, I have no problem with your initial suggestion about names etc, but the statement about "not liking redlinks" that has somehow become attributed to me is incorrect. My opinion is now, and always has been that 1) Daniel J Alpert or 2) Daniel J. Alpert (in German) are easier for the unwashed user than 3) Daniel J. Alpert. Reasons:

1) Is a universal language approach assuming AI translation. AI was not so viable when many of the consensus discussions took place. Consensuses change.

2) Mentions the language, as some wanted to know this. I included this to follow the "user first" principle.

3) To me both the Daniel J Alpert and the [de] are not self-evident. User first. How are they supposed to know that they should click on the de to open up a German language version? Standard html conventions indicate it will open a page called "de".

I don't agree with arguments of the type "users will learn". It is the job of coders to make life easy for users, not the other way around. This is something all programmers learn early (or should), just like adding comments so you and others can work out what you did 10 years later.

Hopefully others will understand my polite emphasis on user first rather than editor first. Ldm1954 (talk) 14:47, 2 November 2023 (UTC)

Thanks for clarification I will refrain from continuing saying that you disliked red links, it was just the impression I had at the beginning of these debates.--ReyHahn (talk) 15:49, 2 November 2023 (UTC)

This is a longstanding community policy which was established by widespread consensus and which has been repeatedly discussed going back to the beginnings of the project. If you want to change it, this is not the best place for it. You are welcome to start a petition at Wikipedia:Village pump (policy) but I wouldn't get your hopes up. For what it's worth I strongly dislike your alternatives (1) and (2), and under current consensus would not hesitate to remove them from the prose of English Wikipedia articles. –jacobolus (t) 15:01, 2 November 2023 (UTC)

Please note, I was responding to a request for clarification about misquoting me. I am not proposing anything beyond stating an opinion. Ldm1954 (talk) 15:15, 2 November 2023 (UTC)

Ldm1954, regarding the statement about "not liking redlinks" that has somehow become attributed to me is incorrect -- you did say in an edit summary: I am not a fan of the red links. older ≠ wiser 16:11, 2 November 2023 (UTC)

Ldm1954, your "opinion is now, and always has been" stated above fails to recognize the benefits of {{ill}}: a) a red link to a subject that's covered in another Wikipedia is (almost always) a good thing – EN Wikipedia needs that article; b) if such an article is created here, the link will turn blue. Your proposals fail on both counts. -- Michael Bednarek (talk) 00:39, 3 November 2023 (UTC)

FWIW, re: Now I have taken the position that if so many users agree on this, and changes to template ill are a no-go, then it is Help:ILL that should be modified to mirror the consensus. I disagree that HELP:ILL (specifically: H:FOREIGNLINK) doesn't mirror the consensus. That text already states The best practice is to use the template interlanguage link which gives both a redlinked English link and a German blue link, but hides the German link if the English redlink turns blue when the article is created. which I wholeheartedly agree with. I also specifically think it is good that this choice (number 1 on the list) isn't enforced (i.e. that other alternatives exist) and that it is "only" recommended. It clearly states which option is "best practice". 3) Daniel J. Alpert (at the time of writing, Daniel J. Alpert doesn't exist at English Wikipedia but does at German Wikipedia) is far far preferable to 1) Daniel J Alpert or 2) Daniel J. Alpert (in German): I think users can handle ill links just fine, and even if you think the alternatives are slightly better UX-wise, there are other benefits to {{ill}}: a) it is clear the link is special (which means the user isn't astonished to find themselves somewhere else) and after the first time, will understand the ill format tells them the link leaves English Wikipedia, b) the red link stares us editors in the face "daring" us to write a new article, and c) the foreign-language link disappears once that has happened. I don't see that translation is reaching Star Trek levels of universality at all, and besides, we shan't assume all our readers is using a particular browser or plug-in anyway. Finally, please understand that if you want change, discussing multiple issues at multiple venues is a horrible practice - as we can see here, it is much more likely to result in people wasting their time chasing imaginary proposals than actual change. PLEASE assume responsibility for your choice of discussion method, Ldm1954 and ReyHahn, and think about how to improve it in the future. Thank you CapnZapp (talk) 11:44, 4 November 2023 (UTC)