Template talk:term

From Wiktionary, the free dictionary
Jump to navigation Jump to search
ArchiveArchives: 2007, 2008, 2009, 2010

describing, rather than glossing[edit]

(Apologies if there's a better place for this, I'm new here.) Consider the English etymology section of soon. As one who takes the use-mention distinction seriously, I find it descends into flagrant nonsense in the middle of the Proto-Germanic part: I'm supposed to think that *sa was PG for "demonstrative pronoun"? Of course not; it was a demonstrative pronoun. So I'd like to be able to suppress the quotes in templates of the {{term}} family. Is there any way to? 4pq1injbok 04:56, 13 October 2010 (UTC)[reply]

{{term|sa|pos=demonstrative pronoun}} = (deprecated template usage) sa (demonstrative pronoun) ("pos" for "part of speech").​—msh210℠ (talk) 05:33, 17 October 2010 (UTC)[reply]
Great, thanks. 4pq1injbok 00:35, 23 October 2010 (UTC)[reply]
Now I've added the same function to {{proto}}, which is what's used for the PG etyma there.​—msh210℠ (talk) 07:24, 24 October 2010 (UTC)[reply]

Smart quotes[edit]

Currently this template uses smart quotes. Smart quotes are against Wikipedia's Manual of Style. Does this matter? --Bxj 13:25, 3 May 2011 (UTC)[reply]

No. Wiktionary's style is completely different from Wikipedia's. (Personally I dislike the smart quotes, but w:WP:MOS has no relevance here.) —RuakhTALK 14:16, 3 May 2011 (UTC)[reply]
What are smart quotes? I don't see them mentioned in WP:MOS. Mglovesfun (talk) 14:56, 3 May 2011 (UTC)[reply]
The curly quotes. (“” instead of ".) —RuakhTALK 15:10, 3 May 2011 (UTC)[reply]
I dislike them, I prefer 'straight' quotes. You almost never see smart quotes used manually, only in term and perhaps other templates (I can't think of one right now). Mglovesfun (talk) 15:35, 3 May 2011 (UTC)[reply]
Quoting below "I'll also second or third the motion to use straight quotes. — LlywelynII (talk) 10:54, 10 July 2012 (UTC)". Mglovesfun (talk) 12:32, 21 July 2012 (UTC)[reply]
Me too. —CodeCat 12:34, 21 July 2012 (UTC)[reply]
  • Me too. I prefer straight quotes on Wikimedia projects. —Angr 13:46, 21 July 2012 (UTC)[reply]
  • I prefer straight quotes for input ease. The format advantage within {{term}} is the most visible location. The modest advantage in appearance of 'smart quotes' could probably be achieved eventually by user-side re-presentation, though I'm basically just talking through my hat about that. DCDuring TALK
  • I prefer smart quotes. There’s no reason we in 2012 need to be bound to the typographic limitations of ASCII. It’s not as though we’re mandating everyone adopt them. People who find them inconvenient to type can use straight quotes as they wish, and leave the job of inserting smart quotes to those of us who care about them. Especially in a template like this, I don’t see how ease of input makes a difference. Someone spends an extra couple of seconds inserting them once, and typography is improved thousands of time throughout Wiktionary. —Caesura(t) 19:09, 25 July 2012 (UTC)[reply]
  • Smart quotes cause display problems on several operating systems still in use at major universities and libraries, even in the US. It would be nice if we could fund an update to schools and educational institutions worldwide, but we can't. For that reason (and others I won't bother with), I like straight quotes and abhor "smart" ones. --EncycloPetey (talk) 01:37, 26 July 2012 (UTC)[reply]

I must say, I am appalled at the direction this discussion seems to be taking has taken. When it comes down to it, “smart quotes” are not really smart or advanced, they are simply normal quotes. The same goes for the apostrophe. The straight quote was invented for typewriters and deliberately made to slant neither way so it could be passed off as either left or right quote. It is a bastard, created partly for ease of use and partly to make cheaper typewriters. These characters should generally not appear in any published material; they are merely shorthands for the full-fledged characters, and should only be used in chat, SMS, on typewriters and in other quick-and-dirty, unformatted text media. Frankly, I see no reason not to use “smart quotes” and proper apostrophes on Wiktionary, as the reasons for the creation of the straight quote do not really apply to us. In any case, ease of input is certainly not an issue for templates; and, as Caesura also points out, although many users will insert straight quotes due to the limitations of common keyboard layouts, users who care about typography can then update the quotation marks in true wiki spirit. As for outdated systems still in use, I find it hard to believe that there are many systems out there that can render Wikimedia sites properly (Unicode, anyone? not to mention all the CSS and JavaScript we use), yet don’t display smart quotes!? These have been well supported on Windows at least since Windows 95 (probably also Windows 3.x) and on the Mac since its beginning in 1984. This is not exactly groundbreaking technology. – Krun (talk) 23:44, 3 November 2012 (UTC)[reply]

IMO the input and output should be separate, i.e. an editor can use either "straight" or "smart" quotes, and a reader can (per browser configuration) see either straight or smart quotes. I know that's not easy to implement, but it's like the serial comma (which I think we do have an option for): just personal taste. Equinox ◑ 23:48, 3 November 2012 (UTC)[reply]
Krun, It may not be "ground-breaking" technology, but the fact of the matter is that MAJOR universities like UC Berkeley do not have browser software in their campus library that can support smart quotes or IPA characters. I have it on authority from one colleague that LSU is even further behind, and know that a similar situation exists for another colleague in Cairo, Egypt (at a university there). So, wishing for some golden age of world-wide up-to-the-minute software will not enable our readers to use the site. But eliminating unnecessary frivolous twiddly bits will. The "full-fledged" characters are the result of copper plate engravers and antiquated moveable type. It is the fancy forms that are outdated, to be replaced by a more modern, progressive, and unbiased straight quote. :) --EncycloPetey (talk) 08:23, 4 November 2012 (UTC)[reply]
You say that these library computers lack support for IPA characters as well as smart quotes, which is exactly the point I was making above: that Wiktionary is pretty much unusable on those systems anyway. Assuming they can parse UTF-8 at all, they still obviously lack even basic multilingual support, which means that many English spellings will be garbled, let alone all the other stuff we have with extended Latin alphabets and other writing systems. Presumably, these systems are also too old to be able to implement all of our CSS and JavaScript, as I also alluded to above. I don’t imagine very many of the students seriously use these computers for much browsing; they will prefer their own laptops and tablets, devices which most of them have anyway and are not older than the students themselves. I’m very sorry you feel the way you do, but I do not find your arguments at all compelling and I cannot agree with you that the straight quote represents any sort of progress or improvement; as I see it, all it does is make type look inconsistent and badly designed, and introduce unnecessary ambiguity. – Krun (talk) 19:46, 5 November 2012 (UTC)[reply]
Incorrect; your assumption is unwarranted. I myself made use of Wiktionary on those computers, and (with careful preparation) was able to edit Wiktionary from those computers. Your "imaginings" are also just that... purely imaginary. Please do not base an argument about the future of Wiktionary on unfounded imaginings and baseless personal opinions, rather than facts. The library computers were all made use of heavily, and that was only one such locality on campus where students could use computers. What students might prefer to use doesn't enter into it when they can't afford it with skyrocketing tuition costs. And you need not feel sorry just because my opinions differ from yours. Although I disagree with your opinon about the smart quotes themselves, I do understand the meagre reasoning you have made on the opinon of looks. However, my brand new computer (less than a month old) also disagrees with you. As I have already noted: on older PCs, the curly quotes look like empty boxes, while the straight quotes render properly. But my brand-new system displays almost no discernible difference between smart quotes and straight quotes; they all look straight to me (for which I am grateful). --EncycloPetey (talk) 03:30, 8 November 2012 (UTC)[reply]
Personally, I prefer the smart quotes (for mere aesthetic reasons, even in sans-serif typefaces), and agree with Krun's argument, but now that the change has been implemented, the template Template:recons (and other possibly relevant templates I'm forgetting right now) should follow for consistency – having one template use straight and the other smart quotes is even uglier. --Florian Blaschke (talk) 19:36, 24 March 2013 (UTC)[reply]

So-called straight quotes ("like this") are ugly and unprofessional.

Many, including many professionals, disagree. Equinox ◑ 17:00, 14 September 2016 (UTC)[reply]

Section linking for same-page wikilink[edit]

In the fairly common situation in which an English Etymology section contains {{term}} pointing to another language section on the same page, it would be desirable for there to be a blue link that linked to the appropriate language section. Could this be done somehow using {{term}} or would a special-purpose template ("{{term-below}}" ?) be better? BTW, other use cases might be for CJKV (with respect to Chinese) and Romance languages (with respect to Latin). DCDuring TALK 20:42, 27 July 2011 (UTC)[reply]

I suspect I'm misunderstanding something, as term already does this if you supply a language. Mglovesfun (talk) 20:48, 27 July 2011 (UTC)[reply]
For example, you recent edit to acquis: {{term|acquis|lang=fr}}. Mglovesfun (talk) 20:48, 27 July 2011 (UTC)[reply]
Sometimes you get "From Old French and Middle French foo" where you can't link to both at once, is this what you mean? Mglovesfun (talk) 17:35, 21 July 2012 (UTC)[reply]

Non-blue, non-black link for missing L2 section[edit]

It has long seemed desirable to me that {{term}} not show a blue or black link if the language section for the term being linked to did not exist. Many the time I have clicked on the link only to find nothing relevant after the usual link and download delays. Perhaps a color like green would do if red is unsatisfactory. DCDuring TALK 20:46, 27 July 2011 (UTC)[reply]

There is a preference that does this- "Color links to language sections that don't exist orange where they would otherwise be blue". Nadando 21:09, 27 July 2011 (UTC)[reply]
I never got that to work for me. I'll try it for the fourth time, give it a day for caches to clear etc., and report back. DCDuring TALK 22:25, 27 July 2011 (UTC)[reply]
No need to wait for the answer. I've had it checked for at least weeks now. It doesn't work for me for translation tables, ordinary wikilinks, or {{term}}-linked items. DCDuring TALK 22:29, 27 July 2011 (UTC)[reply]
It works for me. Before we start trying to debug, let's make sure . . . there are two preferences with very similar names and functionality. The one that Nadando mentions, "Color links to language sections that don't exist orange where they would otherwise be blue", does work for me; the other one, "Color translation links orange instead of blue if the target language is missing on an existing page", does not work for me. Which one do you have turned on? —RuakhTALK 00:24, 28 July 2011 (UTC)[reply]
Evidently the wrong one is the one that has been turned on. I thought I had them both turned on at some point, but not lately. IOW, another false alarm. Sorry. At least it'll save me a bit of time from now on.
Does anyone think that anons and those, like me, who haven't mastered the gadgets and preferences should have this kind of capability built into templates or available by default? DCDuring TALK 02:33, 28 July 2011 (UTC)[reply]
Those two preferences sound like they ought to do the same thing. Does the one that doesn't work for Ruakh and DCDuring work for anyone for whom the other does not work (or to a greater extent than the other)? If not, we should remove it from the list.​—msh210℠ (talk) 18:32, 2 August 2011 (UTC)[reply]
  • What it does, more or less, is when you're at a main-namespace entry, it finds all bluelinks in the page content that point to specific targets within other main-namespace entries. It then downloads the wikitext of those main-namespace entries, and sees whether those entries have sections corresponding to the specific targets. If not, it turns the bluelinks orange. It does not depend on any sort of template; it will work even if you manually type [[foo#French|foo]] in an entry. —RuakhTALK 03:02, 28 July 2011 (UTC)[reply]
    Wow. That's a lot of work. It would seem that making that available for all users be a big server load, at least for really big entries. It works for any section link then, too. That would be advantageous for finding entries with missing PoS sections by means of having section links in en-verb and en-noun for inflected forms like plurals and 3rd personal singular etc verb forms. Generally, it increases the benefit of using section links for Language and PoS. I could see use for links to other sections too. I should have asked about this sooner or properly checked all the gadgetry and preferences. DCDuring TALK 03:14, 28 July 2011 (UTC)[reply]
    I think it would be better to use one entry for each language, but this would completely change how Wiktionary works so it would take a while to do. —CodeCat 18:40, 2 August 2011 (UTC)[reply]
    Wiktionary:Beer parlour archive/2011/April#Restructuration of foreign languages made it pretty clear that that's not going to happen. There are a number of ways that the orange links system could work. The script in prefs would probably cause too big a server load (at least that's the response I got when I asked about it in #wikimedia-tech, though I'm not really sure why that is; the total amount of bytes sent is generally only about a 20% increase or so...), but a bot could go around updating links, much like how Tbot used to update the t/t-/t+ templates. Or perhaps a template containing an invisible redlink to a nonexistent namespace could function as a hackish data storage method, allowing a script to easily retrieve which language sections exist through the API without it being too heavy. Or maybe something in the PHP could fix bugzilla:16561. --Yair rand 21:37, 2 August 2011 (UTC)[reply]
    Or it could work by checking the categories in the target page and seeing if any of them match the language name target. --Yair rand 01:15, 4 August 2011 (UTC)[reply]

Treatment of Translingual[edit]

At [[agrostis]], I deployed {{term}} in the Etymology and expected a blue link. Instead I got an orange one. What gives? DCDuring TALK 16:10, 1 February 2012 (UTC)[reply]

The target entry was uncategorized, causing it to be not recognized by the orangelinks script. --Yair rand 16:24, 1 February 2012 (UTC)[reply]
Thanks. But I thought that all uncategorized entries were in Special:UncategorizedPages. Is that not true? DCDuring TALK 16:58, 1 February 2012 (UTC)[reply]
I see. You mean not categorized as a mul:Proper noun. DCDuring TALK 22:30, 1 February 2012 (UTC)[reply]

New field or {{term2}} needed[edit]

As at ethnic, this template fails to take into account that sometimes more information will need to go into the translation than the quoted words by themselves. There needs to be some mechanism to mark text that should and should not be quoted and even inclusion of links. E.g., currently at ethnic, this template's output is (ethnos, “a company, later a people or nation, heathens”) but what's appropriate is (ethnos, “a company”, later “a people or nation, heathens”) or even (ethnos, “a company”, later “a people or nation”, eccles. “heathens”).

I'll also second or third the motion to use straight quotes. — LlywelynII (talk) 10:54, 10 July 2012 (UTC)[reply]

You can do that using {{term}} by putting the quotes in the template itself. Mglovesfun (talk) 10:59, 10 July 2012 (UTC)[reply]
You can also do it by writing the description after the template instead of inside it. —CodeCat 10:59, 10 July 2012 (UTC)[reply]
We do have a lit parameter: {{term|foo||bar|lit=baz}} yields foo (“bar”, literally “baz”). I suppose one (AFAICT cheap) thing we can do to accommodate the above would be to add a littitle parameter to change literally to whatever's chosen (literally by default). Then {{term|foo||bar|lit=baz|littitle=[[formerly]]}} would yield foo (“bar”, formerly “baz”). (I suspect one such suffices usually despite your …later…eccles.… example above.) Thoughts?​—msh210℠ (talk) 17:25, 11 July 2012 (UTC)[reply]
An ersatz way of doing it is: (deprecated template usage) bar. - -sche (discuss) 17:50, 12 November 2012 (UTC)[reply]

mention-tr-gloss-paren[edit]

What is that class for? As far as I can tell, there is no code anywhere on Wiktionary that references it. -- Liliana • 13:32, 27 October 2012 (UTC)[reply]

YIddish[edit]

I thought I'd point out that yiddish, when imputing the language code (yi) turns the example into a serif font.Curb Chain (talk) 12:02, 29 November 2012 (UTC)[reply]

I have no idea what you're referring to, sorry. Can you try to rephrase? :-/   Thanks in advance, —RuakhTALK 20:38, 29 November 2012 (UTC)[reply]
I think they were trying to add a Yiddish word in Latin script, but since Yiddish uses Hebrew script, it caused it to appear in a Hebrew font which looks different. —CodeCat 21:29, 29 November 2012 (UTC)[reply]

Quotes class[edit]

Can I change it so the span before the gloss is class='mention-gloss-double-quote-left' and the one after is class='mention-gloss-double-quote-right'? (Currently both are class='mention-gloss-double-quote'). Line 125 of Mediawiki:common.css would need to be updated. — Ungoliant (Falai) 18:44, 3 February 2013 (UTC)[reply]

I think a better solution would be to remove those spans and their contents entirely. CSS can be used to put the desired quotes around the class="mention-gloss" itself. —CodeCat 19:38, 24 March 2013 (UTC)[reply]

lang[edit]

Language code should always be specified, then why should it have a named parameter? It is also inconsistent, Template:l takes language code as first parameter. --Z 07:43, 12 April 2013 (UTC)[reply]

I know, I have wanted this to be changed as well. But this template is used on so many pages, and thousands of them are missing the language code. It would not be easy to change it. —CodeCat 13:27, 12 April 2013 (UTC)[reply]
IMO we should mark this as deprecated and create a new one then. It's really ridiculous that we have to type so many "lang="s without any good reason, which also causes inconsistency. --Z 13:38, 12 April 2013 (UTC)[reply]
But what about the name of the new template? Wouldn't we want to keep it as "term"? —CodeCat 14:50, 12 April 2013 (UTC)[reply]
The template is highly used, so it's important to keep the title as short as possible, ideally one letter, like {{t}}, {{l}} (would you please update it?), etc. {{a}} (edit: already exists) may be a good name, stands for the <a> tag, or {{h}} ("hyperlink"), or {{p}} ("phrase") (edit: damn, it's already blue. We can delete it though after Lua-izing... everything). {{z}} is the best title if you ask me though. --Z 15:21, 12 April 2013 (UTC)[reply]
New ideas: {{ph}}, {{phrase}} P.S. what about moving {{recons}} to {{*}}? --Z 15:36, 12 April 2013 (UTC)[reply]
People are familiar with {{term}} so it's probably better to use something similar, unless there is a consensus that another name would be preferable. {{t}} is already in use, so we can't use that, although I do think using {{t}} for this and something like {{trans}} for a translation would make more sense, since the short name isn't needed anymore now that we have a script to add translations. —CodeCat 15:48, 12 April 2013 (UTC)[reply]
If we are going to change the title, then I don't think there's really any difference between choosing a similar or non-similar one. Using 't' is actually worse - it will cause confusion. --Z 15:58, 12 April 2013 (UTC)[reply]
None of those describe what the template represents, which is a mentioned term. It is not a general-purpose link, nor a phrase.
We could call it {{term-new}} until all occurrences have a lang parameter added, but something tells me that might be an open-ended project. I suggest that every occurrence with empty lang be converted to lang=en and categorized as Category:Mentioned terms with lang to be checked, since they inherit lang=en from the root html element anyway. This would only make explicit what is implied, and launch the project of correcting the errors. —Michael Z. 2013-04-12 15:59 z
We could also make it categorise entries when the lang= parameter is missing. I did that once and ended up with a category of ten thousand entries. So I don't know if that is really feasible in the short term. The language parameter does more than just set the lang= attribute, it also applies the correct script template and adds a link to the correct section (which is especially important for tabbed languages). —CodeCat 16:19, 12 April 2013 (UTC)[reply]
Lets add lang with empty value ("|lang=") to all of the pages which haven't use lang (the parameter should be eventually filled, so there's nothing wrong with this), this may list the pages in the mentioned category as well, so that people would fix them. Then we Lua-ize the template and make it in a way that if lang is given (including empty string), then the template behave as the current code of {{term}}, otherwise like {{l}} but italicized or whatever the new code is supposed to behave. --Z 16:34, 12 April 2013 (UTC)[reply]
I see an empty lang parameter in the template already yields an empty lang attribute, which “indicates that the primary language is unknown,” equivalent to lang="und". However, I can’t find any way to get CSS to match on the empty lang attribute, so let’s make this explicitly set lang="und". And we should categorize this situation anyway.
By the way, do we use lang=mul for links to translingual sections? —Michael Z. 2013-04-12 16:49 z
We should... —CodeCat 16:50, 12 April 2013 (UTC)[reply]
Apparently we do: Template:mul. Test: ∞. —Michael Z. 2013-04-12 17:29 z
So: add "lang=und" to those which doesn't have lang, and put the pages in the corresponding category, update Template:term's code to take language code as the first parameter, beside keeping it backward-compatible, and finally move the language code from lang to the first parameter. --Z 17:00, 12 April 2013 (UTC)[reply]
I would prefer to have input from other editors on this issue before making such a widespread change. —CodeCat 17:08, 12 April 2013 (UTC)[reply]
Of course, this is just a proposal. --Z 17:15, 12 April 2013 (UTC)[reply]
It sounds about right. I don’t see adding the category requiring any further discussion. Using lang=und shouldn’t be controversial either, but someone might complain that their Netscape 4 uses Comic Sans font – I say let’s try it and see if there’s a problem. It’s easily reversible.
Changing the template’s default parameters is probably worthy of putting in front of the BP. I don’t foresee opposition. —Michael Z. 2013-04-12 17:16 z
See also Wiktionary:BP#Template_term_and_lang_parameter I have just started. --Dan Polansky (talk) 08:37, 20 April 2013 (UTC)[reply]

Adding automatic transliteration?[edit]

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

'lang=und' should not be treated as "OMG someone messed up".[edit]

Recently, the template was modified to treat lang=und as an error. (This was done at the same time as modifications to call attention to cases where lang= is missing or blank.)

This change does not seem to have been discussed — in particular, it is not mentioned in the above discussion about lang='s mandatoriness and und — and anyway, it's clearly a mistake.

I think we probably want lang= to be mandatory, but firstly, I think it's O.K. for it to be explicitly blank (the XML and HTML specs give that a sensible meaning, so I think it makes sense to pass that through), and secondly, I'm certain that it's O.K. for it to be und ("undetermined"). Note that we actually include some terms in undetermined languages, such as the members of Category:Phaistos Disc symbols, and even for terms that we don't include, something like {{term||foo|lang=und}} is perfectly valid.

Is there any reason I shouldn't simply roll back this change? Like, has someone already started running an unapproved bot that wrongly adds lang=und all over the place?

—RuakhTALK 00:24, 21 April 2013 (UTC)[reply]

Do you have any other ideas for a placeholder for an "empty" language? The aim of the discussion was to find a value for lang= that we could safely set it to whenever lang= was absent. The result of that would be that all current invocations of {{term}} have lang= set. From that point, we could add code that checks whether lang= is present and if not, it treats the first parameter as the language code instead. I have used this kind of backwards compatibility in {{prefixcat}} and it works very well, but the requirement is that there is some way for the template to determine whether the language was provided in the "old" style or the new. For {{prefixcat}} that was easy, because it assumed an empty language meant English, so it was just a case of adding lang=en to everything. But for this template it's not so easy because there is this special mysterious "not specified" language that is currently still present in many entries. Z suggested using "und" to represent that, but if that doesn't work, what would? Lang=* or something like that maybe? —CodeCat 00:32, 21 April 2013 (UTC)[reply]
I'm not 100% confident that the community will accept that migration strategy — many more people use (deprecated template usage) term, and much more often than {{prefixcat}}, so you'll need more than just "all current invocations of {{term}} have lang= set" before you pull the switch — but to answer your question . . . I think an explicit blank value would be fine for that purpose. It should be perfectly safe to convert {{term|foo}} to {{term|foo|lang=}}, since the template has always treated the former as equivalent to the latter. —RuakhTALK 01:05, 21 April 2013 (UTC)[reply]
I don't know if it's the best strategy. I know it's not the only possibility, we could also just create a whole new template. But that would also entail a new name, and are we really prepared to have two {{term}}s around? I kind of think even the one is a bit excessive when we have {{l}} which has almost the same purpose. I would support merging {{term}} and {{l}}, if we could find out a way to allow the latter to italicise the text easily. —CodeCat 01:15, 21 April 2013 (UTC)[reply]
My understanding is that lang="" and lang="und" are semantically equivalent. But I haven’t found a way to select for the empty attribute in CSS, so I would prefer the explicit value. The other problem with the empty attribute is that new templates may continue to be created that leave the attribute blank due to innocent programming or placement errors.– in an open wiki, across all templates, we can never be sure that the empty attribute is always correct. —Michael Z. 2013-04-21 17:41 z
I suggested using lang=* as the parameter above. That should never appear in the HTML, so when it does it can be caught quite easily. Something like :lang(*) { font-size: 500% } would do it. :) —CodeCat 17:44, 21 April 2013 (UTC)[reply]
That would be invalid HTML, and we can’t depend on browsers supporting an illegal character in the CSS selector. But ISO 639-2 has special codes mis = missing language and zxx = absence of linguistic information. The first seems perfect. —Michael Z. 2013-04-22 14:45 z
I think "mis" means "there is no existing code for this language". —CodeCat 14:50, 22 April 2013 (UTC)[reply]
Oops. I see the standard calls it “uncoded languages,” whereas the Wikipedia list calls it “missing language.” Copywriting is important even in the shortest texts.
We could put our own error message in a private-use subtag, like und-x-error. —Michael Z. 2013-04-22 15:08 z

Extra space when no first parameter is provided[edit]

This template generates an extra space when no first parameter is provided. It's annoying to see it.. --Ivan Štambuk (talk) 20:45, 11 July 2013 (UTC)[reply]

But in that case the output is already ugly and non-standard: "From (translit) ..." if we don't know the spelling, we should not use this template only for transliteration IMO. --Z 21:06, 11 July 2013 (UTC)[reply]
Well, if you use the second unnamed parameter for transliteration it's even uglier because the transliteration then becomes rendered in whatever font is preferred for the specified language. If you drop lang= altogether you miss categorization in proper "Entries which need Xxx script" category. By using tr= you simplify maintenance for whomever will specify the proper script in the future. --Ivan Štambuk (talk) 21:40, 11 July 2013 (UTC)[reply]
The template should probably show something if a transliteration was specified, but the main spelling was not. Something like "???" that makes it obvious something goes there. The template already categorises, but you don't see that in the entry so it looks odd. —CodeCat 21:42, 11 July 2013 (UTC)[reply]
??? make me think I'm missing some fonts. I think that the visually most appealing solution would be to display transliteration or the second unnamed parameter (whatever is provided, if both then throw an error) in lieu of the main spelling, but rendered in Latin-script font. Similar behavior should be enabled in {{l}} which doesn't even allow empty first parameter, which forces many editors that are unable to provide native script to use transliteration/transcription in its place, causing them to be both wrong wikilinked and horridly rendered. (or worse, they don't use {{l}} at all). --Ivan Štambuk (talk) 23:12, 11 July 2013 (UTC)[reply]
That was just an example. I think that the template should display something to indicate the main word is missing, but it can be anything that works, not necessarily question marks. I do agree with changing {{l}} to allow the word to be missing as long as a transliteration is present. If there is neither a word nor a transliteration, that should be an error for all linking templates. —CodeCat 23:21, 11 July 2013 (UTC)[reply]

feature request: diacritic removal for specific languages[edit]

Just like {{l}} does it, i.e. {{term|trȁč|lang=sh}} behaving as if {{term|trač|trȁč|lang=sh}}. --Ivan Štambuk (talk) 22:07, 13 July 2013 (UTC)[reply]

broken when only transliteration is provided[edit]

E.g. {{term|tr=baγa-|lang=ae}} generates an ugly message. Embedded comment seems to be the problem. --Ivan Štambuk (talk) 15:19, 30 July 2013 (UTC)[reply]

Fixed. --Z 17:05, 30 July 2013 (UTC)[reply]

??? Xxx script needed[edit]

It's too verbose, you need to cut it to something shorter. --Ivan Štambuk (talk) 21:32, 30 July 2013 (UTC)[reply]

I don't really know how to cut it down without making it so concise nobody knows that it means. In any case, the message is generated in Module:script utilities in the request_script function. —CodeCat 21:41, 30 July 2013 (UTC)[reply]
{{rfscript}} should not display anything because it's usually arbitrarily inserted to double-check spellings. Look how absurd շպետ#Etymology now looks. As for {{term}} - well why not just display question marks, and when you hover over them with mouse display "Xxx script needed" as a tooltip? --Ivan Štambuk (talk) 22:07, 30 July 2013 (UTC)[reply]
Let's use something like [???] to make it less ugly, readers don't need to know "Xxxx spelling needed", that's for editors, so I agree to show it as a tooltip. --Z 22:16, 30 July 2013 (UTC)[reply]
I recall that someone said that question marks alone made it look like there were fonts missing. I don't remember where but it was very recently. —CodeCat 22:22, 30 July 2013 (UTC)[reply]
Other options: ..., ?!?, !!!, #?&! (still better than that horrible message I think...) --Z 22:40, 30 July 2013 (UTC)[reply]
It was I, but considering the alternative it's lesser of two evils. Alternatively, the transliteration itself could be used, unlinked, which would then not appear in (), i.e. as if tr= was not provided. --Ivan Štambuk (talk) 01:42, 31 July 2013 (UTC)[reply]
The error message is VERY intrusive and scary. Please make it show just the transliteration in parentheses and no error message whatsoever. --Vahag (talk) 03:10, 31 July 2013 (UTC)[reply]
If advisory text is really for editors only, give it a class and make it invisible by default. Editors can edit their common.css to make it visible and add formatting, dingbat icons, or an error message of their choice. —Michael Z. 2013-10-27 16:27 z
It is for very experienced niche editors. No casual reader is going to stumble upon [script?] and say "Hey, why don't I fulfill this Avestan, Pahlavi or Sanskrit request, it's so easy". I would hide the advisory text altogether. Script requests are fulfilled by old-time editors, who know how to find the respective categories. --Vahag (talk) 17:00, 27 October 2013 (UTC)[reply]
I agree. All of those "please add blah blah" are never fulfilled by IPs or casual readers, but by established editors who know very well how to find those entries. --Ivan Štambuk (talk) 17:04, 27 October 2013 (UTC)[reply]
Would it be feasible for any languages to have reverse transliteration modules back to the original language (obviously the reconstructed terms shouldn't be linked without review)? DTLHS (talk) 20:53, 31 July 2013 (UTC)[reply]
That's a lot less feasible than doing the transliteration. Transliteration schemes are often ambiguous with respect to the original form, meaning that more than one form can give the same transliteration. Russian is one example, but there are others as well. But furthermore, there are a lot more implications to this. Making a transliteration just serves as a supporting role for those who can't read the script. But generating the original form not only increases liability (people will have higher standards for the original form than for a transliteration), but this word will also become a link to a possibly incorrect entry name. So even if it's possible, I'd prefer not to do it. —CodeCat 21:07, 31 July 2013 (UTC)[reply]
It's not feasible with the majority of complex scripts, even those that can be transliterated automatically, Russian is the smallest problem. If the Russian scheme seems confusing, then you haven't seen complex transliteration schemes. --Anatoli (обсудить/вклад) 00:09, 24 January 2014 (UTC)[reply]
It’s certainly possible, and there are transliteration schemes that are designed to be reliably reversible. One problem is that for a transliteration in the wild it is often difficult or impossible to determine which standard transliteration scheme is used, if any, or whether it is applied with discipline. Some schemes are employed in a relaxed or easier-to-read version in popular writing, for example, which might not be reversible.
Maybe better to rely on editors’ judgment than a soulless machine for the job of reversing random transliterations.
On the other hand, if we find a large vocabulary or glossary rendered in transliteration with consistency, we could probably patch something together or use some other online tool to mass-reverse transliterations. —Michael Z. 2014-01-19 17:31 z
Somehow the scripts that are really easy to learn, such as Cyrillic get constant criticism and some people want to make graphical transliteration for them because people easily see, which letters are used to write "его" or "что" = е+г+о and ч+т+о (see Russian alphabet if you want to know the letters) but when it comes to Thai, Japanese, Korean, Arabic, Hebrew or Hindi people seem to agree to have a phonetic transliteration, rather than useless graphical or use some other excuses. No commercial dictionary uses transliteration to transcribe Russian or Greek. Russian is lucky to have less irregular pronunciations than English or French (less than 5%) (current irregular Russian pronunciations at Wiktionary) to make graphical transliteration totally useless and unlucky to have them at all, unlike Ukrainian, Bulgarian, Georgian, Armenian, etc., 100% of which can be transliterated automatically. If entries in Category:Russian terms with irregular pronunciations cause so much hatred, let's remove the transliteration for irregular words altogether and this topic won't need to be brought up again. --Anatoli (обсудить/вклад) 23:45, 23 January 2014 (UTC)[reply]

Ancient Greek examples[edit]

Would it be terribly controversial to conform the Ancient Greek examples to practice and prescription by removing the accents from the transliteration? -Atelaes λάλει ἐμοί 04:17, 27 October 2013 (UTC)[reply]

Removed. --Ivan Štambuk (talk) 17:11, 27 October 2013 (UTC)[reply]

Combining characters?[edit]

I've been working on adding Klamath words, many of which have ejective consonants. I decided, provisionally, to spell those sounds with a combining comma above the consonant in question. This is the convention used by M. A. R. Barker in his books on the language.

It works beautifully in entries. But unfortunately, I discovered the combining character somehow prevents italicization when I use this template:

Using the character's HTML entity instead results in expected behavior:

Any idea what's going on? And whether it can be fixed? — Äþelwulf (talk) 14:43, 19 January 2014 (UTC)[reply]

For some reason, the first version is being marked as polytonic Greek script, and that's preventing the italics. I have no idea why that happens though. Maybe someone on the Grease Pit might know. —CodeCat 14:50, 19 January 2014 (UTC)[reply]
Fixed. --Z 16:35, 19 January 2014 (UTC)[reply]
Wow, that was quick! Thanks. — Äþelwulf (talk) 16:40, 19 January 2014 (UTC)[reply]

Automatic transcription appears to override manual transcription?[edit]

Discussion moved to Wiktionary:Grease pit/2014/June#Automatic transcription appears to override manual transcription?.

Ancient Greek transcription[edit]

(a) should reinclude the accents where they are provided (my 2 p.) but in any case (reaction to comment above, but this was already fixed. good.)
(b) cannot give ⟨ks⟩ for ⟨ξ⟩, which is universally transcribed as ⟨x⟩. I see that User:Gilgamesh~enwiktionary created the error in 2007 on this page but you can visit the sources at Wiki's Romanization of Greek: there is absolutely no system that transcribes it that way. It was a personal affectation of one of our editors and should not be the default of this template, let alone a default that overrides attempts to correct it using the |tr= term. — LlywelynII 21:52, 27 July 2015 (UTC)[reply]

RFM discussion: August 2014–June 2015[edit]

The following discussion has been moved from Wiktionary:Requests for moves, mergers and splits (permalink).

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.

We still have both of these templates that does the same thing, but the parameters are named differently. I propose to merge them into {{m}}. The only difficulty is that there are still thousands of instances with {{term}} without a language specified, which can't be converted unless we use "und" as the code. So I will leave those alone for now, unless everyone is ok with converting them to {{m|und|...}}. —CodeCat 12:10, 2 August 2014 (UTC)[reply]

What actual good is accomplished, apart from tidying? DCDuring TALK 12:44, 2 August 2014 (UTC)[reply]
Exactly. —CodeCat 12:46, 2 August 2014 (UTC)[reply]
What you call inertia, others might call backward compatibility. For most, {{m}} is an improvement over {{term}}, but the cumulative effect of all the recent changes is bound to have an impact on a lot of users just from the sheer number of new things to keep in mind. People develop habits and "boilerplate" to streamline their workflow, and forcing changes just makes routine tasks harder. This reminds me of a scene in Monty Python's Jabberwocky, where Michael Palin's character tries to help out a blind cooper by rearranging his workshop: it's set up for a far more efficient workflow, but nothing is where the blind man thinks it is, and everything goes horribly, horribly wrong.
It's one thing to deprecate a heavily-used template like term and to replace uses of it with the new one. It's another entirely to delete it and cause problems for intermittent editors who haven't gotten the message yet and have to learn how to edit all over again. Chuck Entz (talk) 22:21, 2 August 2014 (UTC)[reply]
So would you be ok with bot-replacing the template now, and re-nominating it at some later date? —CodeCat 22:27, 2 August 2014 (UTC)[reply]
Is this really the most interesting thing you can find to do? DCDuring TALK 23:18, 2 August 2014 (UTC)[reply]
Why does it matter to you what I find interesting? —CodeCat 23:23, 2 August 2014 (UTC)[reply]
Because I would like to be able to trust you not to do things that cause me personally inconvenience and seem to put the aspects of the project at risk. DCDuring TALK 01:25, 3 August 2014 (UTC)[reply]
We both want to improve Wiktionary. We just have different ideas on how that would be achieved. My view is that reducing the number of templates also reduces the mental load of new users trying to learn how to make entries. Making sure that similar templates share the same parameters also helps, because it makes their use more intuitive. This is why {{m}} was created and why it has the same parameters as {{l}}, why I merged the category boilerplate templates, why I made this merge proposal, and why I hope that we will merge {{context}} into {{label}} one day. —CodeCat 01:47, 3 August 2014 (UTC)[reply]
I have no problem with the creation of new improved templates, just with the elimination of old ones. Can you provide any information on the number of edits made by new users vs the number of old users? DCDuring TALK 07:33, 3 August 2014 (UTC)[reply]
Even for established users, having multiple templates that do the same thing but with different parameters is confusing. When {{term/t}} was first introduced, I thought that it was only to be used with reconstructed terms (because it was primarily being used as a replacement for {{recons}}), while {{term}} was to be used with attested terms. It was a long time before I either figured out or someone told me that the two have the exact same function, just with different parameters, and it didn't matter which one you used. So then I always used {{term/t}} (and now {{m}}) so I didn't have to keep typing "lang=" all the time. —Aɴɢʀ (talk) 15:35, 4 August 2014 (UTC)[reply]
I'm with CodeCat on this one. Mulder1982 (talk) 19:58, 12 September 2014 (UTC)[reply]
  • Of the 33 million total edits ever made to Wiktionary only 6.5 million are made by registered non-bot users, also excluding AF, IW, and Keenebot2. The 67 non-bot contributors at Special:Statistics made about 4.2 million of them, about 65%.
    • Most systems (of many types) show an 80/20 effect. (80% of the work done by 20% of the people) SemperBlotto (talk) 12:52, 4 August 2014 (UTC)[reply]
      I didn't know how many people are or were contributing. That addresses one of the premises of the argument justifying the merger. But there are no statistics that justify eliminating a template that folks are accustomed to. That is simply the product of an urge-to-merge. DCDuring TALK 14:05, 4 August 2014 (UTC)[reply]
      That's a chicken-and-egg argument of course. —CodeCat 15:20, 4 August 2014 (UTC)[reply]
      You never make explicit arguments, let alone coherent ones. Others have to guess what arguments you must be trying to make. In this case do you have any evidence that deleting old templates, rather than simply deprecating them, has any favorable effect on broadening our contributor base. In particular, any evidence that one-letter template names are better for that purpose than whole-word template names? DCDuring TALK 15:37, 4 August 2014 (UTC)[reply]
      Templates will be used as long as they exist and are already present in many entries. So they have a kind of inertia behind them. If that alone is a sufficient argument against deleting them, then we would be stuck with (possibly bad) design decisions made a decade ago when Wiktionary was first created. Things need to change if Wiktionary is to improve, you can't keep things the same and improve at the same time. This is the same for all software; some changes will break things that people are used to, and they will need to adapt.
      As for arguments, Angr already gave some arguments above. And you never suggested at any point that deprecating {{term}} would be a good intermediate step, you just opposed altogether, so you shouldn't be surprised if people understand your position to be "we should keep both {{term}} and {{m}} side-by-side indefinitely". And there is no reason to do that of course, other than "we're used to it", which is hardly an argument because it doesn't improve anything as I noted above.
      And just to point out this move proposal is not about the name at all, I don't know where you got that idea from. —CodeCat 15:47, 4 August 2014 (UTC)[reply]
      Yes, we are cursed with history, users, and their habits. A successful project can never offer a tabula rasa; that's what new projects and revolutions are for. The biggest improvements to Wiktionary will always be better content to attract more users, some of whom may become registered users, contributors, etc. If I could trust that you cared in the slightest about habits and could change things without breaking them or causing loss of functionality which you often seem to not recognize or not understand, I could accept the conventional wisdom above about change and contribute some of the same: "You can't make an omelette without breaking eggs", etc. But I just don't, based on experience to date.
      YOU were the one proposing a change. I expect YOU to make more cogent arguments than someone who seemed to come to conclusions different from what he was supposed to about the other reforms you have pushed. Presumably Angr was misled by the BP and GP discussions in which you adumbrated your proposal in your customary style. In any event, he expressed only his preference for having template parameters work in a particular way for the templates he uses. Perhaps an increasing number of users will use {{m}} and competing templates will cease being added. At close to that point, and not before, it would make sense to replace all instances of {{term}} with {{m}}, unless something better comes along.
      Deprecation is simply the standard practice for pushing something into decline when the advantages of the "new way" are insufficient to win full user support. At least it was before you apparently decided more draconian measures are necessary for tidyness.
      It may not be "about" the name, but it has appropriated this name. If you think the functionality should be transferred to something with a better name for users, make the proposal. DCDuring TALK 17:47, 4 August 2014 (UTC)[reply]
      More likely, Angr simply glossed over the BP and GP discussions as being tl;dr on everyone's part, not just CodeCat's. —Aɴɢʀ (talk) 18:56, 4 August 2014 (UTC)[reply]
      It can't have been CodeCat if it was TL. CodeCat post are terse, to the point of being uncommunicative. TL is usually my department. DCDuring TALK 19:07, 4 August 2014 (UTC)[reply]
    • That bot vs. non-bot statistics is rather misleading. Since inflected forms are typically entered by bots, they easily get their "points" there. Furthermore, interwiki bots easily collect editing "points", since they iteratively add interwikis, thereby adding nothing of lexicographical value. Ditto for autoformat. Bots are useful, but they do not create the lexicographical content. --Dan Polansky (talk) 23:21, 22 August 2014 (UTC)[reply]
My experience with {{term/t}} exactly matches Angr's, lol.
Testing I undertook in investigation of a problem reported in the Grease Pit reveals that Template:term eats more resources and fails more quickly than either Template:m or Template:l. See Wiktionary:Grease pit/2014/August#Pages_Running_Out_Of_Time_and_Memory. It also requires more typing.
I oppose the notion that decisions about template usage should be made by WT:VOTE. (Der Amtsschimmel wiehert!)
If other people want to keep Template:term around, I don't have any strong feeling that it should be deleted. (Replacing it with Template:m on pages that make extensive use of it, so as to gain the time- and resource-savings mentioned in the Grease Pit, is straightforward.) - -sche (discuss) 20:26, 4 August 2014 (UTC)[reply]
I think the best course of action is to deprecate {{term}} and replace it in entries when it's used so that people who learn by copying existing entries don't have examples to learn from. My main concern is with people who've always used {{term}} and will have difficulty editing if it suddenly disappears, not with those who just like it because they're used to it. I think we're better off eventually deleting it, but only after it ceases to be widely used. I agree that DCD has some real reasons to distrust and resent CodeCat's methods in general, but in this case, the new template is actually easier to use once one becomes familiar with it- and that's even comparing it with {{term}} as it was back when one wasn't expected to always type "lang=en" for English terms. Chuck Entz (talk) 01:59, 5 August 2014 (UTC)[reply]


Contradiction ?[edit]

In the doc, we have :

To customize the wikilinks, omit the first parameter and write the wikilink markup in the second parameter.

{{term|[[cor|Cor]] [[Carolī]]||Charles' heart|lang=la}}
Cor Carolī (“Charles' heart”)

It seems to me that the first parm is not omitted, and the second one is. Am i missing something ? --Jerome Potts (talk) 05:21, 7 November 2015 (UTC)[reply]

You're right. Probably, the sentence "To customize the wikilinks, omit the first parameter and write the wikilink markup in the second parameter." was true at some point pre-Lua. I assume there was a time when writing wikilinks in the 1st parameter would break the template, though I did not check if that would really happen.
In any event, I fixed that piece of text and expanded it a bit, it should have updated/correct information now. --Daniel Carrero (talk) 05:55, 7 November 2015 (UTC)[reply]

RFDO discussion: January–August 2016[edit]

The following discussion has been moved from Wiktionary:Requests for deletion/Others (permalink).

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.

While a vote has passed to replace this with {{m}}, this hasn't been nominated at any point for deletion, though you'd've had thought it had failed a deletion request the way people are talking about it. I think it's pretty darn important that we debate this before we delete it.

So I'll start. I have no preference. I personally use {{m}} but with the advent of module it would be perfectly possibly to have them run off the same module with the same parameters except {{{lang}}} and {{{1}}}, so them becoming out of synch is not inevitable. Renard Migrant (talk) 16:38, 26 January 2016 (UTC)[reply]

Too soon. Can I be the only user who takes time to adjust from one template to another? I've typed cx etc. so many times that it's hard to stop. Equinox ◑ 17:21, 26 January 2016 (UTC)[reply]
No, you are not the only user who has muscle memory that interferes with adopting changes in common templates. That is one reason why such changes should have really compelling advantages, not just tidiness. If voting were in proportion to (the log of) the number of times the voter had used the template in the last three months, many templates would not be deleted. DCDuring TALK 18:21, 26 January 2016 (UTC)[reply]
For statistical (?) purposes, I'd like to say: I believe that I was able to adjust immediately from {{term}} to {{m}}, {{context}} to {{lb}}, {{usex}} to {{ux}}. --Daniel Carrero (talk) 10:05, 30 January 2016 (UTC)[reply]
  • Delete after a grace period, during which use of {{term}} is still bot-converted to {{m}}, and any use without lang triggers an error. —Μετάknowledgediscuss/deeds 04:06, 27 January 2016 (UTC)[reply]
    • This is only possible if we convert uses that are still lacking a language (there's still ten thousand) to another template that accepts this. Otherwise we'll get heaps of module errors. —CodeCat 18:17, 29 January 2016 (UTC)[reply]
      • There was an informal vote about this somewhere, right? I fully support moving them over to another template for the interim. Also, I guess I shouldn't be surprised there are ~10,000 instances without a language specified. —JohnC5 19:07, 29 January 2016 (UTC)[reply]
  • Keep: Purplebackpack89 20:53, 29 January 2016 (UTC)[reply]
  • Keep this before short hugely widespread template and deprecate it; use AbuseFilter to deprecate it on the technical level by preventing saving pages that contain the template if possible or explain why it is not possible. Point: make page histories legible. --Dan Polansky (talk) 13:28, 30 January 2016 (UTC)[reply]
  • Keep - Rather than breaking millions of historical revisions with no justification. We can create an editfilter which prevents future usage if that is a concern. - TheDaveRoss 17:13, 8 February 2016 (UTC)[reply]
  • Delete - Of course we should keep it and it shouldn't have been depreciated at all but, if TPTB are going to go around b*tching and moaning about perfectly good templates and keeping people from using them, go ahead and keep people from using them. Historical revisions are no reason to keep it if it's really found unfit to keep using going forward. — LlywelynII 03:12, 7 May 2016 (UTC)[reply]
  • Keep In most cases, I would have no problem deleting a deprecated template, but this was added to so many entries that it seems to me a special case- especially since there are no plans to use the name for anything else.
I can't help but think of the huge push to convert everything with italics that didn't move to use this template, which is now being abandoned so we can pick up the next shiny object, which will no doubt itself disappear one day. But who needs to view edit histories, since "we've always been at war with Eastasia"... Chuck Entz (talk) 04:44, 7 May 2016 (UTC)[reply]

Kept. Renard Migrant (talk) 17:40, 18 August 2016 (UTC)[reply]

Retrieved from "https://en.wiktionary.org/w/index.php?title=Template_talk:term&oldid=56148666"