Template talk:senseid

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

initial tweaks[edit]

Wouldn't it make sense to have it as {{senseid|_lang_|_gloss_}} rather than {{{senseid|lang=_lang_|_gloss_}}? It's not like there are going to be any senseids without languages, are there? --Yair rand (talk) 22:41, 12 July 2010 (UTC)

Fair point. Done. -Atelaes λάλει ἐμοί 22:44, 12 July 2010 (UTC)

Note that MW substitutes an underscore wherever a space appears in the id, and browsers won't find the anchor by searching for the id with the space in it ([1]). Just something to bear in mind.​—msh210 (talk) 16:06, 13 July 2010 (UTC)

Is this a bug? I can't seem to link to senses that have spaces. Craig Baker 01:45, 26 October 2011 (UTC)
It seems to work for me. Do you have any examples of where it doesn't work? --Yair rand 09:40, 26 October 2011 (UTC)
My apologies, I seem to have misunderstood. I read the Grease Pit discussion of translation glosses becoming senseids, and assumed that this was the normal mechanism for choosing a senseid in English entries. I didn't realize that the peach#English-fruit example actually has an explicit senseid template (which happens to match the translation gloss), and misattributed the failure of links like this example#English-something serving to explain or illustrate a rule to the presence of spaces. (As you said, ids with spaces like 夫#Mandarin-is it not seem to work fine.) Should editors start adding explicit senseid templates, or are there still plans to implement the automatic use of the translation glosses as ids? Craig Baker 21:43, 26 October 2011 (UTC)

Is there any reason to call {{language}}? Why not just use the language code? Seems like a waste of a template call, multiplied by, well, millions of uses of this template.​—msh210 (talk) 16:06, 13 July 2010 (UTC)

I added </span>, but of course that will ruin the current implementation of User talk:Atelaes/highlightSense.js. But note that MW displays

#<span id="g">foo
#bar

as

<li><span id="g">foo</span> <span id="g"></span></li>
<li><span id="g">bar</span><span id="g"></span></li>

So I think we need to have </span> and then to have the JS dye the span's parent element.​—msh210 (talk) 19:37, 13 July 2010 (UTC)

Ish, so it does. Highlighting the parent sense should be easy enough. Yes, I wonder if you're right about {{language}}. Part of the reasoning behind expanding the codes to full language names was that it would be easier for any scripts which handle the id's, such as my tabbed language bit, to handle the full names than the codes. However, as I think about it, just about anything is faster than template calls, so such scripts should just do the conversion internally, as we've recently discovered tabbed languages will have to do anyway. Yair may have other issues with this that I'm not aware of. -Atelaes λάλει ἐμοί 22:17, 13 July 2010 (UTC)
Just to clarify, are you suggesting that {{language|_code_}} be replaced with _code_, or {{_code_|l=}}? --Yair rand (talk) 22:25, 13 July 2010 (UTC)
With code, avoiding template calls altogether.​—msh210 (talk) 16:21, 14 July 2010 (UTC)
Hm, using language codes without translating them into language names for the user generally sounds like a bad idea, and having anchors identify languages by full names except where an id is used seems more complicated than it needs to be... On the other hand, we're talking about millions of template calls, and the only place anyone will ever see it is in the URL. Also, using the code gives a simple way for scripts to access a language name's code... I have no idea which way is better. --Yair rand (talk) 20:25, 14 July 2010 (UTC)