Template talk:term/archives/2008

Case, gender, and number

It would be useful in some cases to be able to mention the declined case, gender, and number of a term, when it is not the lemma. Example, for (deprecated template usage) Zaporizhia, I was thinking of constructing something like the following:

from за (za, “beyond”) + порогами (poróhamy, “rapids” instr pl)

A parameter could be added which allows any free-form notes, or it could use the same structured scheme as {{inflection of}}. Not sure what the best abbreviation scheme and text format would be. —Michael Z. 2008-05-16 00:55 z

The Norwegian word (deprecated template usage) tjern could also do well with the gender parameter implemented. The present hack makes the etymology a little confusing. __meco 20:41, 2 June 2008 (UTC)

How would you most expect to see that gender (or more general grammar) information? Inside the parentheses, presumably, but before or after the transliteration and gloss? Rod (A. Smith) 22:05, 2 June 2008 (UTC)

I would actually expect it before the parentheses, so as to match how {{t}} and {{infl}} do it. —Ruakh_TALK 22:54, 2 June 2008 (UTC)

Oh, yeah. That seems better, and is certainly more consistent. Does anyone have any reason to place it anywhere other than before the parentheses? Rod (A. Smith) 00:08, 3 June 2008 (UTC)

Generally, I don't expect to see it: it is rare that it is relevant to etymology. In no examples here do I see a practical reason for including it. Circeus 17:56, 3 June 2008 (UTC)

Edit request

replace <span class='ib-brac'><span class='mention-tr-paren'>(</span></span><span class='ib-content'><span class='mention-tr'>{{{tr}}}</span></span><span class='ib-brac'><span class='mention-tr-paren'>)</span></span>

with <span class='mention-tr-paren'>(</span><span class='mention-tr'>{{{tr}}}</span><span class='mention-tr-paren'>)</span>

Otherwise, a transcription without will receive the user-defined styles for context tags (class ib-brac), if any; in my case, I add a color to them to spot un-templated tags. I'm not sure if this is a feature or a bug (it might not affect many people...) introduced by the "Parentheses" section above. Circeus 18:08, 3 June 2008 (UTC)

I think some users (Connel, if I'm not mistaken) specifically want their user-defined styles for the CSS class ib-brac to apply here as well. Would it solve your problem if you override ib-brac by applying your own user-defined colors to the CSS class mention-tr-paren? Rod (A. Smith) 18:00, 6 June 2008 (UTC)

Well, it means that whatever the style from Help:Customizing your monobook#Qualifiers and italicized parentheses the user happens to use will be applied. This includes small-caps and small-fonts, which arguably would be entirely unexpected of transliterations. Circeus 19:23, 6 June 2008 (UTC)

Error when modifying link

{{term|mitto|mittō||I send, I put|lang=la}}

returns

, leaving out the definition section. Is there any way to fix this? Nadando 20:12, 20 June 2008 (UTC)

Sure. Just remove one of the pipes ({{term|mitto|mittō|I send, I put|lang=la}}), yielding mittō (“I send, I put”).  :-) Rod (A. Smith) 22:06, 20 June 2008 (UTC)

Oh that's all it is. Thanks. Nadando 22:10, 20 June 2008 (UTC)

Can we add automatic script request support?

Often somebody needs to add a term to an etymology but does not know the native script, only a transliteration. In these cases can we automatically call ((rfscript)). Here's a recent example:

Related to Sanskrit {{term|sc=Deva||tr=koṣṭha||intestine}} and possibly Greek {{term|sc=Grek||tr=kýstia||sack}}.

This should generate calls to ((rfscript|Devanagari)) and ((rfscript|Greek)). — hippietrail 04:50, 10 December 2008 (UTC)

The problem (well, one problem) is that we don't have any mapping from script codes to script names. Maybe this functionality should be in the various script templates themselves — if they're called with an empty parameter, they could add the right request category? (Though I'd be worried that there might currently be lots of cases where a template ends up calling a script template with an empty parameter, without any cleanup being necessary, and it's just not something we'd ever noticed. Well, we can always try it first on one script template, and see what comes of it before doing it for the others.) —Ruakh_TALK 03:21, 10 July 2009 (UTC)

Seems like that would be worth trying; I don't recall any places where script templates are called with empty parameters other than places where {rfscript} would probably be desirable. I certainly wouldn't have done it on purpose anywhere because it would generate a span (or i, b, etc element) with the class and no content. Try it on one and see; if it floods unwanted entries into the cat, we can look at the reason (;-) Robert Ullmann 12:14, 10 July 2009 (UTC)

The problem Ruakh notes (that there's no mapping from script codes to codes to script names) is no longer true: template:rfscript so maps now, though it's rather incomplete. (I suppose it should be completed, but the scripts most used on enwikt are there, including all scripts accounted for in category:Entries needing various scripts except Manchu, Shahmukhi, Sogdian, Tamazight, and Tocharian.) So adding what's sought by hippietrail (and now me) should be doable. Possible code is (at the appropriate place in the code, after the #if:{{{1|}}} is spent, wherever that might be) |<!--no {{{1}}}-->{{#if:{{{sc|}}}|{{rfscript|{{{sc}}}}}}}.​—msh210℠ 20:50, 13 January 2010 (UTC)

I too would like to see such functionality very much. Someone, do it :) --Vahagn Petrosyan 20:57, 13 January 2010 (UTC)

Done.​—msh210℠ (talk) 21:16, 19 July 2010 (UTC)

Okay, now can we replace {{#if:{{{sc|}}}|{{rfscript|lang={{{lang|}}}|{{{sc}}}}}}} with
{{#if:{{{sc|{{{lang|}}}}}}|{{rfscript|lang={{{lang|}}}|{{{sc|{{langscript|{{{lang}}}}}}}}}}}}, requesting the script even if the script is not specified, as long as the language is?​—msh210℠ (talk) 18:43, 19 January 2011 (UTC)

It looks good to me. Though I might suggest putting the {{langscript}} stuff in {{rfscript}} instead. The latter can also handle the case that sc=Xyzy (since various other templates call {{term}} with sc={{{sc|Xyzy}}}) by showing lang=... greater deference. —Ruakh_TALK 19:30, 19 January 2011 (UTC)

I've added that support to {{rfscript}} and {{term}} now.​—msh210℠ (talk) 17:27, 24 April 2013 (UTC)

Fixing the brackets and quotation marks output

As discussed on Wiktionary:Grease pit archive/2008/December#Misuse of markup and CSS, this templates output is wrong, including mis-nested brackets and redundant quotation marks. The problem is hidden from most readers by CSS, but this is the incorrect approach.

The simplest task is probably brackets, which are just wrong.

The quotation marks are problematic, because fixing them will probably disable the WT:PREFS customization. I don't know of any way for a template's output to respond to a browser cookie. The CSS quotes property isn't usable due to lack of support in MS products (is it possible to generate conditional comments for IE?—then there would be a solution: Quotations In The HTML Document).

The code looks complicated, so I'd rather someone familiar with it make the corrections. If there's no one available, then I'll take a crack at it myself. —Michael Z. 2008-12-18 21:29 z

Before being too radical: the parentheses problem can be circumvented by introducing another opening parenthesis, which is hidden along with the middle closing parenthesis. That should at least give semantically meaningful output if styles are turned off. I do agree that CSS is misused, but I would not like to see my customizations gone; instead, they should be implemented in JavaScript, since that’s what it is for (you know, the w3c policy, which says: html for content, css for style, js for behavior). H. (talk) 18:30, 4 January 2009 (UTC)

Do you mean we should create output like the following?

слово ((slóvo), “‘utterance’”)

No offence, but that's lipstick on a pig. The problem still remains that we have output which no self-respecting editor would allow past her desk. There's nothing semantic about double-nested brackets and two different sets of quotation marks. It also wouldn't work, because depending on the content, you will get instances with two opening brackets and only one closing.

I agree that using JS for content customization is probably the right way to go, but I'm no JS programmer, so I won't be able to work on that part of it.

I'm sorry that your customizations would be gone, but is it really that important? W3C policy is also to degrade gracefully. —Michael Z. 2009-01-12 06:52 z