Template talk:link

Definition from Wiktionary, the free dictionary
(Redirected from Template talk:l)
Jump to navigation Jump to search


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?[edit]

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.)
RuakhTALK 14:59, 6 October 2008 (UTC)


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[edit]

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[edit]

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)


Would there be any problem with changing this line:


to this:


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.) —RuakhTALK 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.)
RuakhTALK 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[edit]

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?[edit]

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

αγαθοσύνη (agathosýni) f (“goodness”)
whereas {{onym}}
αγαθοσύνη (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

Saltmarshtalk-συζήτηση 15:10, 23 September 2011 (UTC)

I don't really understand why the gender is there, anyway — why is f more useful than 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. —RuakhTALK 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. —Saltmarshtalk-συζήτηση 05:50, 24 September 2011 (UTC)

Word-ending links and {{Latn}}[edit]

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. —RuakhTALK 16:42, 13 December 2011 (UTC)

Optimising the template for speed[edit]

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[edit]

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}}. —RuakhTALK 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


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. —Μετάknowledgediscuss/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:

* ակնակռիւ
* անկռիւ
* անկռուելի
* ...

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:

* 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?[edit]

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[edit]

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|פטל אדום&#x2028;|&#x2028;פֶּטֶל אָדֹם|tr=pétel adóm}}, i.e. using &#x2028; 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}}. —RuakhTALK 21:28, 17 October 2013 (UTC)


{{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[edit]

Something like:


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[edit]

at least for Serbo-Croatian:

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[edit]

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)


{{l|twd|on}} gives a script error. Please revert to a working version. -- 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"? —RuakhTALK 06:34, 14 October 2013 (UTC)


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. - 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[edit]

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 (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[edit]

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)

Depreciation of |4= in {{link}}[edit]

@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[edit]

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)