Template talk:link

Usage?

Is this template supposed to be used in running text (where {{term}} is used) or only in list sections? Should it allow specification of a transliteration and an alternate form? Rod (A. Smith) 21:35, 29 October 2007 (UTC)

{{term}} unfortunatelly italicizes it's parameter so it's not usable for the purpose this template is intended: language indices, Swadesh lists, list of descendats etc. - especially in situations when many of listed different-language terms share the same lemma. It makes no sense to add transliterations/alterante forms in these scenarios. I simply grew sick of wrting [[xxx#language|xxx]] all the time, so I (actually Dmcdevit after my whining on IRC) created this, both to reduce typing and minimize page size for long lists. If some other template provides this basic functionality, I'll be happy to use it instead. --Ivan Štambuk 21:53, 29 October 2007 (UTC)

Ah. I see. I didn't know that this template is just for listed terms. I'm surprised, though, that transliterations are not desired. I was under the impression that transliterations are to be used pretty much everywhere we show a non-Latin script term. It may make sense to merge together this template and {{onym}}. This seems like a good opportunity to collaborate about the appropriate scope, the best name, and the best set of parameters for such a template. Rod (A. Smith) 22:17, 29 October 2007 (UTC)

See WT:GP#Template:onym and Template:l. Rod (A. Smith) 07:54, 30 October 2007 (UTC)

Note: This discussion was archived at Wiktionary:Grease_pit_archive/2007/October#Template:onym_and_Template:l. --EncycloPetey 23:51, 27 August 2008 (UTC)

Links to words in head of phrase?

Should this template be used when linking the individual words of an (idiomatic) phrase, as in {{infl|xx|phrase|head=...}}?

It’s useful for this as one does not want to italicize the words – is this an “approved use”?

E.g., current version of de gustibus non est disputandum has as head:

{{infl|la|phrase|head={{l|la|de}} {{l|la|gustibus}} {{l|la|non}} {{l|la|est}} {{l|la|disputandum}}}}

…which generates correctly formatted links

I’ll mention it above, but wanted to discuss it.

Nils von Barth (nbarth) (talk) 14:14, 5 October 2008 (UTC)

I've been using it for that purpose for a very long time.. It might be worth mentioning, either here or on the documentation page for {infl}. --Ivan Štambuk 13:02, 6 October 2008 (UTC)

I've just been doing e.g.

{{infl|la|phrase|head=[[de#Latin|de]] [[gustibus]] [[non#Latin|non]] [[est#Latin|est]] [[disputandum]]}}

(i.e. "manually" linking). Personally, I've only been using {{onym}} (which is like {{l}}) when I need sc= and tr=; it seems pointless otherwise. Since sc= and tr= are handled by {{infl}}, I never use {{onym}} there. (In part this is because of the name “onym”, which suggests a specific class of purposes.)

—Ruakh_TALK 14:59, 6 October 2008 (UTC)

Spacing

Why is there extra spacing afterwards? It adds an unwanted space before punctuation: che, que. —Stephen 20:32, 21 December 2008 (UTC)

Oops! I accidentally introduced that when I added the (still undocumented) gloss parameter (e.g. che (“what”)), for use in indices, see also lists, etc. It's fixed now, right? Rod (A. Smith) 02:42, 22 December 2008 (UTC)

Looks good. Thanks. —Stephen 14:10, 22 December 2008 (UTC)

More optional names parameters

Some while ago Cirwin added a "tr" parameter to specify a transliteration as used in the "infl" and "term" templates. I have now also added the "g" parameter to specify a gender. Only the usual "m", "f", "n", and "c" values should be used - this is not checked by the template code. — hippietrail 06:28, 3 April 2010 (UTC)

Clickable on linked page

This template gives clickable links on the page it links to; see e.g. vår and the template used under "see also". --Harald Khan Ճ 08:01, 25 April 2010 (UTC)

id=

Would there be any problem with changing this line:

[[{{{2}}}#{{language|{{{1}}}}}|{{{3|{{{2}}}}}}]]

to this:

[[{{{2}}}#{{language|{{{1}}}}}{{#if:{{{id|}}}|-{{{id}}}}}|{{{3|{{{2}}}}}}]]

in order to allow linking to specific definitions with {{senseid}} using the id= parameter? (ex. {{l|en|peach|id=fruit}} would link here.) --Yair rand (talk) 22:15, 31 October 2010 (UTC)

I don't see why not, as this is exactly the kind of thing it was meant for. —CodeCat 22:53, 31 October 2010 (UTC)

Well, {{senseid}} doesn't really seem to be in use yet — see [[Special:WhatLinksHere/Template:senseid]] — and discussion at [[Template talk:senseid]] seems to have petered off without deciding whether the fragment should be #English-fruit or #en-fruit. So I'm not sure it's a good idea to modify {{l}} yet to support the specific way that {{senseid}} currently happens to work. But if {{senseid}} does come into use, and retains its current form, then definitely, that edit looks perfect. (Please correct me if my assumptions are wrong. Aside from WT:RFV, I think it's been more than a year since I've followed any discussion page really thoroughly, so I may well have missed something.) —Ruakh_TALK 23:06, 31 October 2010 (UTC)

{{senseid}} really can't be used until there's a template that can link to it. If the way senseid works is changed, couldn't {{l}} just be switched to work with the new format? --Yair rand (talk) 23:14, 31 October 2010 (UTC)

O.K., I see. But in that case, you're not really proposing that {{l}} be changed to support {{senseid}}; you're proposing that {{senseid}} be used, and that {{l}} be changed to support it. Right? Then, that doesn't seem like something that should be proposed at [[Template talk:l]], so much as something that should be proposed at [[Wiktionary:Beer parlour]] or something. (Maybe even voted on, since the idea seems to be that all entries would use it.)

You're right that if {{senseid}} changes to #en-fruit, specifically, then {{l}} can just be changed to match that. I guess my issue there is that it seems a bit premature to change {{l}}, which is a very widely transcluded template (used on about 5% of pages, I think), to support a template that's not really "settled" yet. (It also seems that id= is a very prominent parameter to reserve this way; if we're going to use {{senseid}} widely, then that makes sense to do, but if we're not, then it might not. And right now, it's not obvious to me that we are.)

—Ruakh_TALK 00:55, 1 November 2010 (UTC)

The discussions in the BP haven't had much response, and I'm pretty sure consensus isn't ordinarily required just to use a new template. I don't think consensus in the BP is really necessary to make this small change to {{l}}. --Yair rand (talk) 19:33, 23 March 2011 (UTC)

other discussions

I went looking for discussion of what {{l}} was for, and I link to the discussions from here, so they are more easily located in the future: [1], [2], [3], [4]; [5]. - -sche (discuss) 16:58, 25 August 2011 (UTC)

Too many brackets?

When there is a transliteration as well as a gloss the output IMHO is clumsy.

{{l}}

{{l|el|αγαθοσύνη|gloss=goodness|tr=agathosýni|g=f}}

gives:

αγαθοσύνη (agathosýni) f (“goodness”)

whereas {{onym}}

{{onym|el|sc=Grek|αγαθοσύνη|gloss=goodness|tr=agathosýni}}

gives:

αγαθοσύνη (agathosýni, “goodness”)

Although {{onym}} lacks the gender argument.

Could the gloss be moved inside the same brackets as the transliteration - leaving the gender outside - thus:

αγαθοσύνη (agathosýni, “goodness”) f

—Saltmarsh^{talk-συζήτηση} 15:10, 23 September 2011 (UTC)

I don't really understand why the gender is there, anyway — why is f more useful than Template:pos adv? — but if we're going to have it, I think it should probably go before the parenthetical part rather than after. Glosses are sometimes quite long. —Ruakh_TALK 18:56, 23 September 2011 (UTC)

In some cases there will be two noun forms under Related terms: differentiation is useful. But so would a POS argument! - non Greek speakers may confuse adjectives with masc nouns and adverbs with feminine ones - so I sometime put [{{pos}} > a POS indicator] at the end of a line. —Saltmarsh^{talk-συζήτηση} 05:50, 24 September 2011 (UTC)

Word-ending links and {{Latn}}

Is it possible to make this template work like the square-bracket links, so that {{l|en|gather}}ed gives the same as [[gather#English|gather]]ed? I think that the problem is that {{Latn}} gets in the way. Especially if this template replaces square brackets, do we really need <span class="Latn" lang="en" xml:lang="en"> everywhere? —Internoob 04:14, 13 December 2011 (UTC)

I think we need a new template, perhaps called {{b}}, to replace the previous use of square brackets in definitions and the like. -- Liliana • 05:28, 13 December 2011 (UTC)

diff. Works, without removing the script template. Any objections? --Yair rand 05:34, 13 December 2011 (UTC)

Is <span> an allowed element within <a> in XHTML? —CodeCat 11:58, 13 December 2011 (UTC)

Sure, it is. -- Liliana • 15:34, 13 December 2011 (UTC)

I don't like that at all. The end result is something like <a href=...><span class="Latn" lang="en" xml:lang="en">gather</span>ed</a>: the -ed ends up inside the link, but outside the <span>. It's bizarre. —Ruakh_TALK 16:42, 13 December 2011 (UTC)

Optimising the template for speed

This template is used a lot, and with the recent proposals for tabbed languages it's possible that this template will see even far wider use. That could cause it to become a very large performance bottleneck. So I would like to look at possible ways this template could be sped up. This template should ideally be just for creating links, and nothing more or less. So a good start would be to look at anything that doesn't have to do strictly with linking. Those are things that could be delegated to another template, such as {{term}}. For that reason I propose to remove transliterations, gender and glosses from this template. —CodeCat 19:40, 26 December 2011 (UTC)

I'd keep transliteration, but I'm ok with removing the other two if it's really all that beneficial. Mglovesfun (talk) 20:00, 26 December 2011 (UTC)

Calling language templates directly instead of using {{language}} would probably speed it up a bit. We could shrink the three #ifs down to one for simple uses if we wrapped the transliteration, gender, and glosses in one #if, though that would add an extra #if when the parameters are used. --Yair rand 20:08, 26 December 2011 (UTC)

lang attribute for transliteration

The transliteration is tagged with an empty lang="" attribute. I believe that should be tagged with the template’s inherited language code plus Latin script code. E.g., lang="el-Latn" for transliterated Greek. Can this work? —Michael Z. 2013-02-08 23:20 z

CodeCat added lang="el-Latn" on the 24th of January, but after a few minor issues surfaced, changed it to lang="" instead. But since you're already participating in the relevant discussions, I'm not sure why you're starting a new one here, without even linking to those. This question is obviously not specific to {{l}}. —Ruakh_TALK 09:00, 9 February 2013 (UTC)

I thought I’d flag this on the individual templates as I become aware of them, and work on solving any problems. Is there a list of templates that are relevant? —Michael Z. 2013-02-09 18:57 z

Lua-ising

What are some features that would be useful for this template to have after being converted to Lua? I can think of a few:

• Not breaking when there's {{l|en|a [[link]]}} in the template.
• Support for {{l|en|[[multiple]] [[links]]}} inside the template, with each of them being directed to the language section unless otherwise specified in the link.
• Automated transliterations for the relevant languages.
• Automated removal of macrons and such, for languages that could use it.
• Support for id= as proposed above.
• For certain languages, attempted automated detection of script based on contents?

--Yair rand (talk) 00:01, 20 March 2013 (UTC)

• All sounds good. The last bullet point really should be for all languages IMO. For languages like Serbo-Croatian it can be essential, but it's useful as well when somebody tries to link to a Yiddish or Hindi transliteration, as I've seen happen. In such a case, the entry could be placed in an attention category. —Μετάknowledge^{discuss/deeds} 00:10, 20 March 2013 (UTC)

  These are good ideas, but I think that it would be beneficial to look deeper. {{l}} and {{term}} are almost identical, and in general most linking templates share behaviour one way or another, but they all work subtly different. With Lua, it would become very easy to split this up into functions so that it's guaranteed that they all work the same. —CodeCat 00:36, 20 March 2013 (UTC)

• Another possibly useful feature: Support for linking to reconstructed language entries, like {{lx}}. --Yair rand (talk) 21:49, 20 March 2013 (UTC)

  That I definitely agree with, but we'd need a way to mark when a word is reconstructed. Putting * in front seems like the most obvious solution, and it's a solution that works for Lua because it can split strings. So... that would mean {{lr|gem-pro|hundaz}} would become {{l|gem-pro|*hundaz}} and {{recons|ǵéwstus|lang=ine-pro}} would become {{term|*ǵéwstus|lang=ine-pro}} (although I think {{term|ine-pro|*ǵéwstus}} would be even better). There is one disadvantage though... once we start using *, we can't link those names except with Lua-based templates, so the two link formats would be incompatible. —CodeCat 21:56, 20 March 2013 (UTC)

  Why would there need to be a * in the wikitext? --Yair rand (talk) 22:00, 20 March 2013 (UTC)

  I don't understand your question, sorry. —CodeCat 22:07, 20 March 2013 (UTC)

  Why couldn't {{lr|gem-pro|hundaz}} just become {{l|gem-pro|hundaz}}, with Lua adding the * afterwards? --Yair rand (talk) 22:09, 20 March 2013 (UTC)

  Because that wouldn't make it obvious (to Lua) that the term is reconstructed. The templates {{lx}} and {{termx}} figure that out from the language code (via {{langprefix}}) but that method is flawed: they don't work for reconstructed terms whose language is attested, like Vulgar Latin terms. We introduced {{lr}} and {{recons}} for just this reason, but they have their own limitations. Explicitly marking reconstructed terms with * when linking to them would remove a lot of those limitations, provided that module writers write or use *-enabled code. —CodeCat 22:15, 20 March 2013 (UTC)

  Are there any language codes for which there are both appendix-based entries and mainspace entries? --Yair rand (talk) 22:20, 20 March 2013 (UTC)

  Yes, currently Old Dutch has a number of reconstructed terms. But that isn't even relevant. What matters isn't whether we have any now, but whether we might have some in the future. —CodeCat 22:28, 20 March 2013 (UTC)

  Wouldn't using * to tell whether an word is reconstructed cause problems for entries like *nix? --Yair rand (talk) 23:01, 20 March 2013 (UTC)

  Yes, it would... but it's the best way I can think of, unless we think of some other format, like "escaping" the * of *nix with **nix or something else like that. There aren't many entries beginning with * and I don't think there ever will be, so it shouldn't pose too many problems. —CodeCat 23:14, 20 March 2013 (UTC)

• I've just created Module:l with the suggested features, it needs debugging though. --Z 17:58, 29 March 2013 (UTC)

Imagine something like this:

{{l|hy|
* ակնակռիւ
* անկռիւ
* անկռուելի
* ...
}}

in which words are automatically wikilinked and transliterated. It is possible with some simple text processing. This is very useful especially for long lists like this. Or even beyond that, we can have a template to wikilink (and transliterate) translations:

{{t|
* Armenian: պահարան
* Azeri: dolab, şkaf
* Bulgarian: стенен гардероб, килер
* Czech: skříň
* Persian: کمد (komod)
* ...
}}

module can automatically recognize the language, and wikilink (and transliterate) words. It is much easier to edit (especially for newbies) and probably faster especially for entries with big number of translations. --Z 18:16, 29 March 2013 (UTC)

I've made some changes, mostly to simplify the module so that the bare necessities are distilled out. Personally, I think the work you've done is a step that's too far forward, you've tried to mimic {{l}} too closely while adding other new features, without first working out all the features that could possibly be shared by other templates and modules. {{Xyzy}} in particular is a really bad thing IMO, and it shouldn't be used or recreated in Lua. —CodeCat 21:27, 29 March 2013 (UTC)

You forgot "dir" attribute. Directional information for scripts should be added to Module:languages, I can't edit it. --Z 22:16, 29 March 2013 (UTC)

Why is that information necessary? Unicode already contains that information... —CodeCat 22:55, 29 March 2013 (UTC)

Whoops, yeah. But wait, how are we going to specify classes like "ur-Arab" for a term? The code should automatically add appropriate classes, shouldn't it? --Z 23:36, 29 March 2013 (UTC)

Currently it doesn't, mostly because I'm not sure how to handle things like headword lines, which require a class in themselves as well. So I figured, why not just make the parameter the class, which could be just the script, but it could also include other things. —CodeCat 00:00, 30 March 2013 (UTC)

Ok I think module:links is ready to use. --Z 01:14, 1 April 2013 (UTC)

Adding automatic transliteration?

See Template_talk:t#Adding_automatic_transliteration?. Same question. Is it feasible for this template? --Anatoli ^{(обсудить}/^вклад) 05:25, 16 April 2013 (UTC)

I'm not sure if it would be. Not in the current state, anyway. For something like this to work:

• The template needs a way to discover which languages have this capability.
• It needs a way to use the capability for that language.

Checking whether a module named xx-translit exists isn't possible, or at least not within the constraints that this template is working under (it is too slow). That means that it would need a list of languages that are capable of automatic transliteration. That list could be hard coded into the template (or Module:links), but a better approach might be to add it to Module:languages so that it's automatically available as part of the language data. That is good, because anything we add there is essentially "for free", because pretty much all pages on Wiktionary will use that module. The second requirement means that either the template/module needs a way to figure out how to use the transliteration, or we decide to make all transliteration modules and functions exactly the same (name and signature wise) so that the same code works for all of them. The latter approach is probably easier, but we'd first have to decide on which signature to use. I suppose xx-translit is a good module name, but I'm not sure if "tr" is good as the name of the function, it's kind of short (short names have less of an advantage in modules than they do in templates). —CodeCat 12:35, 16 April 2013 (UTC)

I see. I thought about a manually maintained list of languages with translit capabilities, so that this template would use modules only for those. Perhaps there could be a way to create a shortcut or an alias for the modules and their functions? I still know little about Lua (but learning from working on the Russian verb functions), just sharing ideas. --Anatoli ^{(обсудить}/^вклад) 13:44, 16 April 2013 (UTC)

It's feasible, see Template:l-list. --Z 06:49, 17 April 2013 (UTC)

Thank you. I don't quite understand the implementation, though. Will have another look. --Anatoli ^{(обсудить}/^вклад) 10:19, 17 April 2013 (UTC)

So, whats problem? It is easy to discover which languages support this capability (by simply making unified module that will return an empty string if the language isn't applicable, and corresponding transliteration otherwise). It is also easy to tell the template what to do with transliteration, again by simply making a new template that will take all the args that {{l}} now takes and depending on whether tr identifier is missing try to construct it by aforementioned module and pass it to this template (of course, in this case we have to move it for example on {{lOld}}--user:Dixtosa 17:38, 1 June 2013 (UTC)

RTL issue

I have problems using this template with Hebrew. {{l|he|פֶּטֶל אָדֹם|פטל אדום|tr=pétel adóm}} results in פטל אדום (pétel adóm), where the alternate text appears as the name of the linked page and vice versa. Is there any trick to get the correct result? Thank you, -- Stf (talk) 18:51, 30 June 2013 (UTC)

That is really an issue with your browser. It thinks that both the word and the alternative display form are part of a single span of Hebrew text, so it puts the whole thing in RTL mode, which gives the appearance of swapping the two parameters. So if you swap them back again, then they should appear in the "actual" correct order. Something you can also try is to put an extra Latin letter next to the | that separates the two. This forces the text span to be broken up by an LTR section, which should revert the swapping, and make it clearer what the actual underlying order of the two parameters is in the source code (just don't forget to remove the extra letter before saving). —CodeCat 19:01, 30 June 2013 (UTC)

Yes, the pipe character is directionally neutral, which means when you put it between RTL characters such as those of Hebrew alphabet, it will behave as an RTL character. --Z 19:09, 30 June 2013 (UTC)

I've got this handled by writing {{l|he|פטל אדום
|
פֶּטֶל אָדֹם|tr=pétel adóm}}, i.e. using 
 as stop characters, but I could not remove the stop characters before saving, so I deleted them in a second step[6]. Nasty workaround, but it works. Thank you. -- Stf (talk) 20:02, 30 June 2013 (UTC)

The right fix is just to accept it, and write {{l|he|פטל אדום|פֶּטֶל אָדֹם|tr=pétel adóm}}. Or, if you prefer, you can write something like {{l|he|פטל אדום|<!--x-->פֶּטֶל אָדֹם|tr=pétel adóm}}. —Ruakh_TALK 21:28, 17 October 2013 (UTC)

broken

{{l|sh|ć}} generates:

<span class="Latn" lang="sh">[[c#Serbo-Croatian|ć]]</span>

instead of:

<span class="Latn" lang="sh">[[ć#Serbo-Croatian|ć]]</span></span>

--Ivan Štambuk (talk) 20:13, 5 July 2013 (UTC)

I think someone was a bit too eager with removing diacritics, but it does highlight an important false assumption. The module that Z wrote assumes that a diacritic should be removed from all letters, but in this case it certainly should not be. I will ask him/her for help. —CodeCat 20:19, 5 July 2013 (UTC)

(please update) Not every diacritic will be removed by the module. This case looks to be an exception, that is we have the same diacritic for both vowel and consonant letters. --Z 20:26, 5 July 2013 (UTC)

It's quite likely that there are other languages with cases like this. What we probably want to do is specify, separately, which characters to remove the diacritics from and which to leave alone. So there are two regexes/character classes. One to specify the set of base characters, and one to specify the set of diacritics. That way you can say that acute accents should only be removed from vowels, but not from consonants. This should be specified per language, of course. Even this approach has a limitation though: you can't specify that one diacritic should be removed from certain letters, but another diacritic should be removed from a different set of letters. I don't think that is very common, but it is something we should be very aware of, and perhaps program defensively in this case. The safest possible way to code this is, of course, to list each character+diacritic combination individually, so that only those are stripped and nothing else. —CodeCat 20:33, 5 July 2013 (UTC)

That's right, I'll work on it. --Z 20:42, 5 July 2013 (UTC)

I checked all alphabets of these languages, there are several other alphabets which have the same issue. The new code works safely now: I removed those particular diacritics from "strip" and tried to do removing through a new table, "replace". We can merge the latter in "replace"; but the resulting table and code will be too big and too time-consuming to create and maintain. IMO, the new version is in the best shape.

Here's the new code (tested; works fine). After the update, the corresponding five tests in Module talk:links/testcases are expected to pass. --Z 09:59, 6 July 2013 (UTC)

What about putting this information in Module:languages? —CodeCat 12:22, 6 July 2013 (UTC)

If everyone is agree with this new structure of data, let's do this. We can have a key named "page_title" and the value {strip = "[...]", replace = {...}} --Z 13:05, 6 July 2013 (UTC)

feature request: optional first parameter

Something like:

{{l|fa||tr=blahblah}}

not throwing a script error, and categorizing in Category:Persian entries which need Arabic script --Ivan Štambuk (talk) 12:19, 13 July 2013 (UTC)

diacritic removal is broken now

at least for Serbo-Croatian:

• {{l|sh|ùdārnica}} now links to [[ùdārnica]] instead of [[udarnica#Serbo-Croatian]]. --Ivan Štambuk (talk) 01:08, 21 July 2013 (UTC)

I think I see why. ZxxZxxZ changed the parameter of the prepare_title function to langinfo instead of lang, but there is a reference to lang a bit further down. —CodeCat 01:21, 21 July 2013 (UTC)

Ok, it's fixed. —CodeCat 01:52, 21 July 2013 (UTC)

script errors when too many usages

I was about to add a word on Appendix:List of Balkanisms but then I noticed script errors. This page worked fine one or two weeks ago. I suspect that the new Lua-enhanced {{l}} is a bit too resource-hungry. Is there any way to fix this or should this page be broken into subpages? --Ivan Štambuk (talk) 11:36, 23 July 2013 (UTC)

There is a discussion about this on the Grease Pit. I wouldn't fix it just yet. The slowdown is caused by invoking script templates as far as I can tell, but I'm working to remove that problem by merging them and moving any differences between them into the CSS. Once that's done, the script templates are no longer needed for anything, and we can remove the call from this template as well. (As a side note, this template is really a wrapper around Module:links, so it would be better to discuss things there because that's where all the code is) —CodeCat 11:46, 23 July 2013 (UTC)

I suggest redirecting talk pages of Luaized linking templates to Module talk:links to centralize discussions. --Z 12:22, 23 July 2013 (UTC)

1=twd

{{l|twd|on}} gives a script error. Please revert to a working version. --80.114.178.7 22:10, 12 October 2013 (UTC)

{{twd}} isn't a valid language code, so the error is correct. The code was merged with {{nds-nl}} almost a year ago. --Yair rand (talk) 03:52, 14 October 2013 (UTC)

I don't know about "correct"; it's actually pretty wrongheaded IMHO. Maybe we can agree on "intentional"? —Ruakh_TALK 06:34, 14 October 2013 (UTC)

Suggestion

Maybe this template should make a further distinction on which sense of the word to redirect to, if there are multiple? Or just manually putting in the correct etymology section to go to.

For example, in the page birth, one instance of using this template on "bear" has it redirect to the English section, but the first sense of the word listed on that page is the animal "bear". This causes confusion. The etymology that it should want to go to is the second listed, the verb "bear".

Of course, it results in nothing more than two seconds of scrolling down for people who know the first hit to be untrue, so I don't know if this is a significant enough issue to fix. It might cause misinformation for who don't know English very well, though. Or to people who don't have the habit of doubting at first. -99.235.235.81 08:59, 25 May 2015 (UTC)

This is not an insignificant issue, in big entries it is as important as linking to the correct language (section). We did create an ad hoc feature to link to a particular sense, the parameter |id=. This makes the code of entries uglier, and usually linking to one particular sense is not that important, linking to the PoS section is usually enough. On the other hand, the id's for sections in a given page are easilly altered by some simple changes in sections' order or title, and no one knows what pages have linked to that section (this is not the case if we use subpages -- we have Special:WhatLinksHere), so finding the links to fix them is not usually feasible. In short words, there is not a good solution for this issue (and some other issues) at the moment; we need some basic changes in the structure of our entries, in which data is classified mostly by (over)sectionizing a single page. --Z 12:31, 25 May 2015 (UTC)

If senseid is possible then posid is also possible. and etyid too. Dixtosa (talk) 07:36, 31 May 2015 (UTC)

link vs term

The documentation says: It should not be used for terms mentioned in running text

But I think there's an exception to this. When you link using term the resulting text is cursive, which is not desirable when you want to link an English word in an English description. — This unsigned comment was added by 82.139.82.82 (talk).

You're confusing "mention" with "use". --WikiTiki89 18:18, 3 December 2015 (UTC)

The documentation doesn't make clear that the technical definition of ‘mention’ is used; normally you cannot use a word without also mentioning it. Even if you use the technical definition, in dictionary lemmata there can be grey area where due to the general formatting and purpose of a dictionary both interpretations yield the same semantics. The documentation should be clearer on when to use this template, when not to use it, and if so, what to use instead. Arguing about the meaning of words on a talk page isn't going to improve the documentation one iota.

Recent Changes fix

This template is still categorizing Special:RecentChanges. "RecentChange" needs to be "RecentChanges" in the template. KarikaSlayer (talk) 15:08, 6 July 2016 (UTC)

Fixed --Daniel Carrero (talk) 16:28, 6 July 2016 (UTC)

The following discussion has been moved from the page user talk: msh210.

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.

---

Replacing l|en with square brackets

Hey, just curious about this diff. Why is it better to use square brackets than the {{l}} template? I understand why some people prefer to type it in square brackets initially, but once the template version is there to remove it seems like needlessly reducing the information density of the markup. Thanks. - TheDaveRoss 20:03, 27 September 2016 (UTC)

It simplifies the wiki markup so editors can read it more easily (and new editors are not as scared off by it). And there's minimal (usually no) information or user-interface loss: the word is marked as English anyway in the HTML (it inherits that from the page), and the link goes to the top of the page (which for most English words is the English section; even where it's not, people seeking the English word will often be interested in the ==Translingual== word also). Moreover, the edit is no skin off my back, since I have a script that does it for me automatically (though I don't edit only for the purpose of changing {{l}} to brackets; in the case you linked to, I was fixing no-language-parameter {{homophones}} templates).​—msh210℠ 13:28, 28 September 2016 (UTC)

I oppose these edits, you should stop and revert them. —CodeCat 13:34, 28 September 2016 (UTC)

I assume the second half of that sentence was an expression of your opinion (and therefore almost redundant to the first) and not an expression of what you consider to be policy/convention, right? By the way, Wiktionary:Votes/2016-07/Using template l to link to English entries opposes automatic conversion of brackets to {{l}}, though doing so in 'nyms lists only is still subject to Wiktionary:Votes/2016-08/Using template l to link to English entries from English entries; if the latter passes, I'll certainly stop changing from {{l}} to brackets in 'nyms lists (and will probably change my JS to change brackets to {{l}}).​—msh210℠ 13:59, 28 September 2016 (UTC)

The information which is removed is the language target of the link in the wikitext. Not all readers will render the page using the MediaWiki engine, so the way the HTML is rendered is not the only concern. I would rather the links be left as they are, or at very least converted to a language specific square bracket link. - TheDaveRoss 13:52, 28 September 2016 (UTC)

I'm not sure that third-party renderers' user interface needs to take priority over our own editors' editing interface. Maybe so. If you know of a past BP conversation on this topic, or start one, please let me know.​—msh210℠ 13:59, 28 September 2016 (UTC)

I know that there have been votes expressing the desire to convert links the other way. I am of the opinion that we need to work harder to make the content accessible, including - even especially - to third parties where the audience really is. - TheDaveRoss 14:06, 28 September 2016 (UTC)

I was assuming you realize already, but am writing to clarify in case that's not the case, that I do this only for English words, and only in the ==English== section.​—msh210℠ 14:03, 28 September 2016 (UTC)

I was not aware, but that does not change my opinion that the more specific link is better than the less specific link. - TheDaveRoss 14:06, 28 September 2016 (UTC)

I just want to point out that even if that vote fails (the vote is about whether a bot should replace plainlinks with templated links), there still seems to be a consensus that the templated links are preferable. --WikiTiki89 18:10, 5 October 2016 (UTC)

Depreciation of |4= in {{link}}

@Wikitiki89, CodeCat, ZxxZxxZ: Why is |4= marked as deprecated? It's widely in use and found in various documentations, including here with {{l|ru|ру́сский||Russian|g=m}}. Was there a discussion on its deprecation or is this a mistake? --Victar (talk) 22:15, 26 March 2017 (UTC)

@Victar Did you see the recent discussion in WT:Beer parlour? Benwing2 (talk) 03:36, 27 March 2017 (UTC)

@Benwing2: I didn't! Thanks for pointing me to it. --Victar (talk) 04:16, 27 March 2017 (UTC)

Template produces different text size than plain link

See Cryptomonada#Hyponyms. If you don't see a size difference, use OS or browser to reset default type size. I also have a clip of another example that I can e-mail or otherwise send. DCDuring (talk) 16:40, 6 January 2018 (UTC)

@DCDuring: I can only reproduce this with Firefox. Chrome and Safari don't show this behaviour. It looks like a browser bug, if you change the language code from "mul" to "en" (or any other valid language code) the font size is correct. My guess is that Firefox doesn't know about the "mul" code and treats it like a special / error case. – Jberkel 18:01, 6 January 2018 (UTC)

I see. Thanks for taking the time. I should have tested with another browser myself. I am surprised that Firefox might see "mul" or Translingual and use that to set type size. DCDuring (talk) 18:38, 6 January 2018 (UTC)

bold transliteration

If '''{{l|el|σοφία}}'''
then both link and transliteration become bold: σοφία (sofía) or σοφία2 (sofía2) or σοφία+tr (sofía+tr)
Is it my browser? Or, is there a way which i cannot see that makes the transliteration normal? I see at Template:head that transliterations always appear in normal font, which looks nice. It is not a serious thing, though. Thank you. ‑‑Sarri.greek ^♫ | 16:08, 17 February 2020 (UTC)

diacritics and punctuation and confusion

"The template will automatically remove diacritics and punctuation from the page title".
1. How do I make it not do that?
2. Why isn't it documented how to make it not do that?
3. If it's impossible, why is it impossible?
4. Why does it do this to begin with? If you need this, just enter an alternate text to display as the link title. Or have different parameters for "link from which diacritics and punctuation should be removed" and "I know what I'm doing just let me link some page title".
5. If an alternate link text is specified (which also signals the user knows what they're doing), why does it still remove diacritics and punctuation? That makes no sense whatsoever. Alexis Jazz (talk) 22:45, 27 February 2022 (UTC)

[kwk]

Please correct "Kwak'wala" to "Kwakʼwala". Thanks. kwami (talk) 18:49, 10 July 2023 (UTC)

Italics in parameter 1

This template seems ignores italicizing wikimarkup, which behavior I had been unaware of until recently. Long ago, I found that it was necessary to have a pipe to displayed italics for an linked item. The current behavior is useful to correctly format occurrences of taxonomic names in definitions, descendants listings, and possibly elsewhere.

1. Is it intended?
2. How long has this behavior existed?
3. Is it documented? (I couldn't find it on this template's documentation.)
4. Can I rely on this behavior continuing?
5. Does this behavior apply to all links?

@Benwing2, Theknightwho Who can give definitive answers to these questions, especially 4 and 5? DCDuring (talk) 00:46, 30 December 2023 (UTC)

@DCDuring

1. Yes. The same applies to bold.
2. About a year.
3. It should be, but there are a lot of templates and it probably isn’t on most of them.
4. Yes.
5. It should do.

Theknightwho (talk) 02:18, 30 December 2023 (UTC)

@User:Theknightwho Wonderful. Thanks.

When I said "all links" I meant all links managed by modules, not wikitext links. Is that also what you intended in answer to 5? DCDuring (talk) 22:31, 30 December 2023 (UTC)

@DCDuring Yes - it works with wikilinks which are nested inside (link) templates (e.g. {{l|en|some [['''ex'''ample]] text}}: some example text), but there's no way for us to change how wikilinks outside of templates work.

Hopefully this is intuitive, but if you use it like this you've got to be careful about whether the apostrophes are inside or outside the link:

• some [['''ex'''ample]] is fine: some example
• some '''[[example]]''' is fine: some some example
• ''some [[ex''ample]] is not: some example

Theknightwho (talk) 23:00, 30 December 2023 (UTC)

As to 3, I think {{link}} needs the documentation, at least if it is the most fundamental template with the behavior. Whatever the most fundamental template, you could get away with referencing its documentation in the documentation for each template that uses it or the underlying module code. That would probably be better than trying to document it everywhere, even by transclusion, because much documentation is getting so voluminous that its usability is impaired. I doubt that the documentation should be only at modules. DCDuring (talk) 22:31, 30 December 2023 (UTC)

@DCDuring Yes, you're right. We should probably have some kind of universal link documentation which gets shown on all link templates, alongside anything extra they might do. Theknightwho (talk) 23:01, 30 December 2023 (UTC)