Template talk:term

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
Archive Archives: 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)

{{term|sa|pos=demonstrative pronoun}} = sa (demonstrative pronoun) ("pos" for "part of speech").​—msh210 (talk) 05:33, 17 October 2010 (UTC)
Great, thanks. 4pq1injbok 00:35, 23 October 2010 (UTC)
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)

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)

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)
What are smart quotes? I don't see them mentioned in WP:MOS. Mglovesfun (talk) 14:56, 3 May 2011 (UTC)
The curly quotes. (“” instead of ".) —RuakhTALK 15:10, 3 May 2011 (UTC)
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)
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)
Me too. —CodeCat 12:34, 21 July 2012 (UTC)
  • Me too. I prefer straight quotes on Wikimedia projects. —Angr 13:46, 21 July 2012 (UTC)
  • 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)
  • 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)

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)

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)
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)
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)
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)
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)

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)

I suspect I'm misunderstanding something, as term already does this if you supply a language. Mglovesfun (talk) 20:48, 27 July 2011 (UTC)
For example, you recent edit to acquis: {{term|acquis|lang=fr}}. Mglovesfun (talk) 20:48, 27 July 2011 (UTC)
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)

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)

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)
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)
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)
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)
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)
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)
  • What is the scope of the orange links. Do they only appear for {{term}} or for any wikilink within a template to a headword for a page in N0 when there is a lang= parameter? DCDuring TALK 02:44, 28 July 2011 (UTC)
  • 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)
    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)
    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)
    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)
    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)

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)

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

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)

You can do that using {{term}} by putting the quotes in the template itself. Mglovesfun (talk) 10:59, 10 July 2012 (UTC)
You can also do it by writing the description after the template instead of inside it. —CodeCat 10:59, 10 July 2012 (UTC)
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)
An ersatz way of doing it is: bar (baz”, previously “bad). - -sche (discuss) 17:50, 12 November 2012 (UTC)

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)

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)

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)
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)

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)

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)

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)

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)
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)
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)
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)
New ideas: {{ph}}, {{phrase}} P.S. what about moving {{recons}} to {{*}}? --Z 15:36, 12 April 2013 (UTC)
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)
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)
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)
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)
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)
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)
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)
Of course, this is just a proposal. --Z 17:15, 12 April 2013 (UTC)
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)

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)

'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)

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)
I'm not 100% confident that the community will accept that migration strategy — many more people use 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)
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)
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)
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)
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-errorMichael 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)

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)
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)
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)
??? 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)
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)

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)

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)

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

??? 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)

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)
{{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)
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)
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)
Other options: ..., ?!?, !!!, #?&! (still better than that horrible message I think...) --Z 22:40, 30 July 2013 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)

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)

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

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)

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)
Fixed. --Z 16:35, 19 January 2014 (UTC)
Wow, that was quick! Thanks. — Äþelwulf (talk) 16:40, 19 January 2014 (UTC)

Automatic transcription appears to override manual transcription?[edit]

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