In the options below the editing window (below the 'save page' button), could we add templates for citations? "quote-book" and such. Currently, we have 'Templates' for things like "en-noun" and 'Headers'; below that it would be nice to have 'Citations', where choosing "quote-book" would insert the following blank citation template:

#* {{quote-book |year= |author= |title= |page= |passage= }}

I don't know where I would go to do this myself, and I probably don't have authorization to mess with such things. kwami (talk) 13:29, 1 March 2012 (UTC)

The downside of that is, it might promote the use of those templates. —Ruakh_TALK 17:54, 1 March 2012 (UTC)

I didn't realize they were deprecated. Don't we want to use them, to keep a uniform appearance across Wk? kwami (talk) 07:04, 2 March 2012 (UTC)

They're not deprecated, but they're also not endorsed: there are some editors who like them and use them, and some editors (such as myself) who think they're a huge broken mess that should never be used. —Ruakh_TALK 13:25, 2 March 2012 (UTC)

Is there a discussion on this somewhere? I've been trying to use them because I thought that was wanted, but they aren't always ideal. kwami (talk) 05:44, 3 March 2012 (UTC)

Discussion moved to Wiktionary:Beer_parlour#including_gender_.28definite_articles.29_and_verb_principal_parts.

• See Template talk:overline

Jcwf (talk) 03:26, 2 March 2012 (UTC)

I'd like to create a category for Asturian reflexive verbs, for example matase (kill oneself). I tried copying something from {{es-verb}}, but that template is far more complicated than {{ast-verb}}. I'm looking to add something like ref=y to add a verb as reflexive, like I put in matase. Can someone help me with this, please --Cova (talk) 12:09, 2 March 2012 (UTC)

 Done; see Category:Asturian reflexive verbs. Note that I went with ref=y, as in your comment here, and as in {{es-verb}}, rather than with refl=yes as you had used at ]. —Ruakh_TALK 13:33, 2 March 2012 (UTC)

Why not use {{#if:{{{refl|}}} instead of {{#ifeq:{{{refl|}}}|y ? It's faster and it means it doesn't even matter what you use as the parameter. —CodeCat 16:48, 2 March 2012 (UTC)

Agreed, the other possibility is a switch like type, such as type=reflexive or type=defective. {{fr-verb}} uses this, I think anyway. Mglovesfun (talk) 17:33, 2 March 2012 (UTC)

@CodeCat: I had originally thought to write {{#if:{{{ref|}}} (which I think is what you mean), but then I saw that {{es-verb}} has the equivalent of {{#ifeq:{{{ref|n}}}|y, and I figured it was better to be consistent with that, since anyone working on Asturian is likely to be writing and/or copying from Spanish entries. —Ruakh_TALK 18:28, 2 March 2012 (UTC)

I would recommend changing the Spanish template too in that case. —CodeCat 18:49, 2 March 2012 (UTC)

Does anyone object to automatically performing, using MglovesfunBot, edits such as diff? That is, to remove brackets and anchors created by the hash symbol and replace with simple text inside form-of templates? The reasons are discussed further up this page; the form of template automatically links to the section of the language in question, such lang=es links to Spanish. Mglovesfun (talk) 12:56, 2 March 2012 (UTC)

• Go for it. (there are lots in old Italian verb forms) SemperBlotto (talk) 13:00, 2 March 2012 (UTC)

My principle is to always remove redundant code, code that does literally nothing. For example I replaced a load of {{en-noun|s}} with {{en-noun}}, as -s is the default for plurals. Mglovesfun (talk) 13:04, 2 March 2012 (UTC)

PS the code is designed to format only entries with a space before the hash, this is because accelerated entries use {{subst:♯}} which adds ' #' to the page to work round a bug. So it should only affect accelerated entries. Am gonna start off with the relatively small Category:Middle French plurals, mainly because I suspect all of those entries were originally by me. Mglovesfun (talk) 22:12, 2 March 2012 (UTC)

Regional whois to America doesn't link well for me. Seems that ws.arin.net was moved to whois.arin.net. --BiblbroX дискашн 07:48, 4 March 2012 (UTC)

Thanks for the notice! I've now edited MediaWiki:Anontalkpagetext to use a URL format that, while slightly hackish, appears to work. —Ruakh_TALK 16:58, 4 March 2012 (UTC)

ska probljem for the notice. But I think Template:anontools should also be revised in order to also fix the Contributions page of anons. --BiblbroX дискашн 15:57, 5 March 2012 (UTC)

Right you are. Thanks again. —Ruakh_TALK 18:02, 5 March 2012 (UTC)

It serves us all, and me along... so thank you for fixing it for all of us. --BiblbroX дискашн 22:23, 5 March 2012 (UTC)

I would like to have added a filter that helps to identify the pattern spam that is currently operating. I have it in place at other wikis and it just identifies possible accounts that fit a criteria with no further action. I am seeking permission to have it added here. If someone could contact me, that would be great. Thanks. — billinghurst sDrewth 16:11, 5 March 2012 (UTC)

Could you post a link to the filter on one of those wikis? —Ruakh_TALK 18:05, 5 March 2012 (UTC)

Left you a note. Generally your checkuser will be able get these and it is the preference note have filters floating around. — billinghurst sDrewth 14:13, 6 March 2012 (UTC)

Note to admins: you can view the aforementioned filter at ]. Most recently, it would have flagged BebimaVekoxe (talk • contribs) (now indef-blocked by Equinox), NaitikThakur (talk • contribs) (no contributions), and XesezuXuvena (talk • contribs) (now indef-blocked by SemperBlotto). —Ruakh_TALK 15:03, 6 March 2012 (UTC)

Update: I decided to go ahead and implement it, since as billinghurst says, it just identifies possible issues, it doesn't take any actual actions. So you can view it more comfortably at ]. —Ruakh_TALK 15:11, 6 March 2012 (UTC)

Thanks for implementing. The vandal bot is prolific, and usually hits four or five wikis at a time, though not every time will it spam, usually through the English language wikis, which as stewards we generally won't chase due to your having your own checkusers. We are generally hoping to identify the source of the spam and your CU may share the detail available, or work out how to share that with other wikis. — billinghurst sDrewth 11:09, 7 March 2012 (UTC)

While for some languages WT:ACCEL seems to work perfectly, for others it works fine but includes unneeded code. For example for Spanish =={{subst:es|l=}}==, the l= no longer does anything. Also instead of {{plural of|nocat=1|]|lang=es}}, can be just {{plural of|nocat=1|{{PAGENAME}}|lang=es}}. Does the same thing, just more efficiently. Mglovesfun (talk) 19:41, 5 March 2012 (UTC)

The |l= has been removed. --Yair rand (talk) 23:40, 5 March 2012 (UTC)

I keep having trouble making citations. The book citation (Template:cite-book) doesn't allow for situations like anthologies, where the title of the short story is not the title of the book. Just now, I tried a magazine citation template (Template:cite), and it puts a bullet next to it so it doesn't match the format of the book citations (see the 1984 citation at Citations:pasta). The magazine citation also doesn't allow the page number to be entered. Another problem with the magazine template is that there is no place for volume and number. Is there a way to deal with situations like this? BenjaminBarrett12 (talk) 20:27, 6 March 2012 (UTC)

Yes: you can just format the quotation by hand. That works 100% of the time, unlike quotations templates, which work roughly 30% of the time. ;-)   —Ruakh_TALK 21:48, 6 March 2012 (UTC)

Thank you for that suggestion. That seems reasonable. I can create a non-template template to provide the formatting. Is there a preferred citation format? BenjaminBarrett12 (talk) 22:11, 6 March 2012 (UTC)

See Wiktionary:Quotations. —Ruakh_TALK 23:08, 6 March 2012 (UTC)

Okay, thank you. It seems for some items within citations, nothing has been established, so I will create something that seems reasonable. BenjaminBarrett12 (talk) 23:30, 6 March 2012 (UTC)

I want to make an inflection table that looks nice and inflect the verb base according to the provided affix (which could be an affix,a suffix ,or an infix). The rules for each affix can be found here: http://en.wikipedia.orghttps://dictious.com/en/Tagalog_grammar#Verbs_.28Pandiwa.29 And another table with an example can be found here: http://salitablog.blogspot.com/2007/03/tagalog-verbs.html

A verb base will usually have more then one affix as in kain (This entry also shows the obsolete {{tl-infl}}that is used).

I don't know it is need to make a template for each affix (e.g {{tl-decl-in}},{{tl-decl-i}},{{tl-decl-an}},{{tl-decl-um}},{{tl-decl-mag}} etc) with code that unites the tables when two or more affixes are applicable in a single base form.

I just need an template for one of the affixes and I probably could take it from there. Thanks, Jobnikon (talk)

Okay, so here's what I came up with. Tell me if it's not what you want. You need a bunch of templates like {{tl-decl-in}} (rename it to whatever you want). {{{C}}} is the consonant, {{{V}}} is the vowel and {{{R}}} is the rest of the rootword. I'm not sure how the N thing works in Tagalog. Then you need to change {{tl-infl}} to be like this and use it like this. You can then either delete {{tl-infl-row}} or use it in {{tl-decl-in}}. —Internoob 05:06, 8 March 2012 (UTC)

If you click on the plus sign near Italian words prefixed with extra- in extra-, you'll get "no pages or subcategories". The problem goes away if you format the template as {{prefixsee|Italian}}, instead of {{prefixsee|it}}. Can someone fix this, so that the template behaves correctly when you use the language code? --Vahag (talk) 09:23, 10 March 2012 (UTC)

The problem in extra- disappeared for some reason, but you can still see it in տ-. --Vahag (talk) 09:29, 10 March 2012 (UTC)

It works there for me too. —CodeCat 16:09, 10 March 2012 (UTC)

Indeed. Must have been a temporary thing. Never mind. --Vahag (talk) 17:51, 10 March 2012 (UTC)

I've found that the IPA tie bar over the top does not seem to render properly on Wiktionary. Example: -- the tie bar should start over the left edge of the "T" and continue until the right edge of the "S", but my Firefox 10.0.2 on Win 7 is showing the tie bar starting over the colon and continuing until the middle of the "T".

By way of comparison, tie bars appear correctly over at w:IPA#Affricates_and_double_articulated_consonants, and mostly correctly when not using {{IPA}}, as in . This would seem to suggest that there's something potentially screwy with the CSS used for <span class="IPA">, rather than just in my browser/OS combo.

Anyone know what's going on? And better yet, can anyone fix this? -- Cheers, Eiríkr Útlendi │ Tala við mig 19:18, 12 March 2012 (UTC)

It looks ok for me, using Firefox 10 on Linux Mint 11. —CodeCat 19:38, 12 March 2012 (UTC)

I see the same thing Eirikr describes; has the tie bar begin over the : and end over the t; displays the bar properly over the ts. This is true in Firefox 10, Internet Explorer 9 and Opera 11 on Windows 7. - -sche (discuss) 19:42, 12 March 2012 (UTC)

I just tried changing Firefox's sans serif font to Dejavu Sans -- this changes the display of most text in WT, but it does not change the display of the text in the IPA template above. This suggests that the site's CSS for <span class="IPA"> specifies a different font. -- Eiríkr Útlendi │ Tala við mig 19:53, 12 March 2012 (UTC)

The CSS contains this specification for IPA:

font-family: Arial Unicode MS,Gentium,GentiumAlt,DejaVu Sans,Segoe UI,Lucida Grande,Charis SIL,Doulos SIL,TITUS Cyberbit Basic,Code2000,Lucida Sans Unicode,sans-serif;

font-size: 110%;

—CodeCat 20:16, 12 March 2012 (UTC)

Thank you, CodeCat -- it looks like the issue is Arial Unicode MS, as described in the note over at w:IPA#Affricates_and_double_articulated_consonants. Seems there's a bug in the font that screws up how the tie bar displays. I just confirmed it in my browser by setting the sans serif font to Arial Unicode MS, instead of the default of Arial, and the tie bars look broken for both IPA and regular text samples. Setting the sans serif font back to Arial makes regular text appear correctly, but IPA text is still goofy.

Perhaps we could change the text specified in this CSS to whatever WP uses, since that seems to work better? -- Eiríkr Útlendi │ Tala við mig 20:37, 12 March 2012 (UTC)

• Additional info over at w:Arial_Unicode_MS#Bugs. -- Eiríkr Útlendi │ Tala við mig 20:41, 12 March 2012 (UTC)

Alternatively, use invalid IPA characters (︠︡). -- Liliana • 20:58, 12 March 2012 (UTC)

FWIW, that displays for me as a t, followed by half a tie bar, followed by s, followed by the other half of a tie bar, followed by ura. - -sche (discuss) 21:16, 12 March 2012 (UTC)

Same here. I think what -sche and I are seeing is another aspect of the Arial Unicode MS bug.

Examples:

1. invalid IPA characters (︠︡)

1. above uses {{IPA}} (and thus the Arial Unicode MS font, at least at present), while 2. above just uses WT's bog-standard font, which I can change in my browser settings (currently using the default Arial font). The IPA version shows up as -sche describes, while the Arial standard shows up properly -- but then again, the regular tie bar also shows up properly in the plain Arial font.

It really looks like we should ban Arial Unicode MS from any CSS use that might cover IPA (and any other fancy diacritics). -- Eiríkr Útlendi │ Tala við mig 21:43, 12 March 2012 (UTC)

Banning it may be excessive, but the list of fonts is ordered, so if Arial is moved further to the end of the list, available fonts that come before it will be selected preferentially. Another possibility is to embed a suitable font inside the page with w:Web Open Font Format. —CodeCat 22:41, 12 March 2012 (UTC)

I agree, we should just re-order the list. - -sche (discuss) 22:58, 12 March 2012 (UTC)

My point about "banning" is that Arial Unicode MS is demonstrably broken, and thus shouldn't be listed at all in the CSS for rendering IPA. Even if I didn't have any of the other fonts installed on my system, my browser's default fallback font for sans-serif would do a better job rendering IPA than AUM does -- and I can easily change that setting in my browser. If the CSS specifies to use AUM, I can't change the font (at least nowhere near so easily), and I'm stuck with ugly and broken IPA display. Why use something that clearly doesn't work, and that the end user cannot easily change? -- Eiríkr Útlendi │ Tala við mig 23:20, 12 March 2012 (UTC)

FWIW, Apple's OSX version 10.6 comes with the Arial Unicode font, which seems to be the same thing as Arial Unicode MS -- and I see the same broken IPA display in Firefox 10.0.2 on my Mac. Safari shows the single tie bar correctly in both IPA and regular text, but the split tie bar proposed by Liliana looks slightly odd in IPA text (the second half of the bar is at a different height than the first, but both display over their corresponding letters), and appears broken in regular text just as -sche describes (letter, then half the bar, then letter, then the other half of the bar). Comparing the glyphs side-by-side, it looks like Safari is actually using Arial Unicode for the IPA text, with the only difference I can see being that the tie bar displays correctly in Safari but not Firefox -- which suggests that Safari and Firefox somehow handle the fonts differently, which is confusing. -- Eiríkr Útlendi │ Tala við mig 04:59, 13 March 2012 (UTC)

In OS X 10.7 I see the Arial Unicode error in Firefox, but not in Safari, and not when I paste the text into TextEdit. Same thing goes for Chrysanthi Unicode, seen here: w: Wikipedia:IPA#Affricates_and_double_articulation. Perhaps the OS X text rendering engine has a hard-coded fix that keeps these tie bars from straying too far to the left. I believe Firefox has its own text-rendering engine, which would explain its lapse. —Michael Z. 2012-03-17 04:34 z

Separate issue: the diacritics below the u and a in are not aligned (the letters themselves are not at the same height; u is higher); in , they align. I wonder if font-size: 110%; is doing us in? - -sche (discuss) 20:26, 12 March 2012 (UTC)

I'm seeing the "u" and the "a" displayed on the same level, both in the IPA span class and when not. The diacritic under the "a" looks lower than the diacritic under the "u" when in the IPA span class, but at the same level when in regular text. Zooming in once in the browser shows the diacritics on the same level for both text samples. -- Eiríkr Útlendi │ Tala við mig 20:32, 12 March 2012 (UTC)

Here are screenshots showing both issues: misplaced tie bar and slightly raised u. Note that the text displays correctly in the editing window in Opera, but the u is raised in the displayed text; in Firefox, each character is separate in the editing window, but the u is at the right height in the displayed text. In both cases, the tie bar is misplaced. - -sche (discuss) 20:36, 12 March 2012 (UTC)

In the editor window, the default monospace font in Firefox is Courier New, which shows the tie bar between the "T" and the "S" as if it were a separate glyph -- but if you try to select the tie bar, you'll find that it's actually a combined glyph with the "T", which is as it should be, even though it displays a little funny. I'm not sure what the default monospace font is for Opera (I don't have it installed), but you might try changing the setting to see how it affects things. -- Eiríkr Útlendi │ Tala við mig 20:50, 12 March 2012 (UTC)

Could this template be made subst:able? I'd like it so that {{subst:theplural|noun}} is replaced with just nouns. —CodeCat 15:28, 13 March 2012 (UTC)

Yes; you can change {{#switch:{{{1}}} to {{<includeonly>safesubst:</includeonly>#switch:{{{1}}}. (Also, wow . . . that template is just hilariously bad.) —Ruakh_TALK 20:26, 13 March 2012 (UTC)

I know... I'm trying to change the category boilerplate templates so that their parameter is already pluralised. That makes more sense (to me) and it means not having to add a new plural with each new category. You can help too if you like. —CodeCat 20:44, 13 March 2012 (UTC)

I can see what the purpose of the template is, not sure it's "hilariously bad". Mglovesfun (talk) 12:43, 14 March 2012 (UTC)

Thank you Ruakh it works now. I'm not sure if the template is hilariously bad, but like many other templates that use such large switches, they become slower the more words are added, and the default case (which is the most common here) slows down the most. So maybe the individual pluralisations could be moved to subtemplates, in the same way as {{langrev}} does it. —CodeCat 13:07, 14 March 2012 (UTC)

You're welcome. Re: "hilariously bad": Well, if you can read through Template:theplural?action=edit without breaking out laughing, then maybe that means it's not hilariously bad, but I think it's more likely to mean that you have no sense of humor. I mean, c'mon, it even has a case to map abbreviation, acronym and initialism to abbreviations, acronyms and initialisms. How is that not hilarious? :-)   (By the way, I think the underlying design was less-than-ideal to begin with, but I see how it could have come about. But by the time that more than half a dozen phrases ending in slang all got added as special cases, I think it should have been abundantly obvious to all comers that this was absurd.) —Ruakh_TALK 14:57, 14 March 2012 (UTC)

The changes are now done. This means a lot of the pluralisations in this template aren't needed anymore. But how do we find out which are still used and which aren't? —CodeCat 01:22, 15 March 2012 (UTC)

Thanks for your work. And I've eliminated the occurrences that affected actual entries; the remaining uses only show up on template pages. (Most are via {{headtempdocboiler}}; some are via {{catboiler doc}}; hopefully that's all.) I think we can just delete {{theplural}} now, and gradually fix the broken template-pages over time, as we notice them; there's no rush. —Ruakh_TALK 17:29, 16 March 2012 (UTC)

If you click a word that's shown in the category "English pronominal adverbs" and then click on "what links here", the links page doesn't show the category page. Shouldn't it show the category page? Pine^talk 05:22, 14 March 2012 (UTC)

No. Categories are not considered to "link to" to the terms they include. If the little introductory blurb at the top of a category includes a link, though, that word should presumably show that the category links to it. —Angr 11:07, 14 March 2012 (UTC)

Hi, could someone who's less intimidated by template syntax than I am please edit Template:gv-noun to add a correctly working sort parameter? The effect should be that when the term is placed in Category:Manx nouns, it is sorted according to what's specified in the sort parameter rather than by the page name. For example, the template in the entry line of çheer is marked with |sort=cheer but in the category it's still alphabetized under Ç rather than under C. Thanks! —Angr 11:04, 14 March 2012 (UTC)

P.S. The original creator also made some requests on the template's talk page for functions he wasn't able to figure out, so if someone could add those too, it would be great. Thanks! —Angr 11:05, 14 March 2012 (UTC)

I've added the sort key. Mglovesfun (talk) 13:21, 14 March 2012 (UTC)

Thanks! —Angr 13:31, 14 March 2012 (UTC)

I've uploaded this file to Commons to show how IPA fonts have somehow become emboldened (literally) with recent changes. And though this file doesn't show it, the spacing has gone a bit weird, too. Mglovesfun (talk) 12:42, 14 March 2012 (UTC)

IPA is rendered at 110% size so that may be why. But it seems more of an issue with how Windows renders fonts than Firefox or Wiktionary. On Linux Mint I see it like this:

—CodeCat 13:19, 14 March 2012 (UTC)

It's not Windows or Firefox per se; I'm using Firefox on Windows 7 and for me it looks like the image on the left. No bold face, no weird spacing. And I was logged out when I made the screenshot, so it's not my user settings. I suspect that somewhere <span class="IPA"> is defined as taking some selection of fonts in a certain order, depending on what the user has installed. For me it uses Gentium, while for you (Mglovesfun) it seems to be using Lucida Sans Unicode, which has by nature a rather bold appearance. If you do not have Gentium installed on your computer but you do have LSU installed, then your system is going to pick LSU. The easiest solution is for you to download Gentium (it's open-source and free). —Angr 17:08, 14 March 2012 (UTC)

This edit, this discussion. I wonder if we can remove the font specification altogether, because this is a workaround for a bug in old versions of MSIE.17:29, 14 March 2012 (UTC)

I certainly agree with demoting Arial Unicode, which is a considerably less useful font now than it was 10 or 12 years ago. Whether we can completely dispense with defining IPA in CSS, I don't feel qualified to say. —Angr 17:38, 14 March 2012 (UTC)

We shouldn't demote Arial Unicode, which would only impose broken text rendering on fewer readers. We should stop using that buggy typeface for IPA at all.

It looks like en.Wikipedia has replaced this CSS with a Javascript for Windows browsers only, in w:MediaWiki:Common.js. Latest discussion at w: MediaWiki_talk:Common.js/Archive_18#IPA_font_changes (Their use of Arial Unicode MS is probably screwing up a lot of IPA for Win users.) I'd like to try the same thing here. My Mac browsers render IPA at least as well, and without a jarring font mismatch, without this declaration. —Michael Z. 2012-03-14 17:45 z

More:

• Wikipedia's font choice: w: MediaWiki_talk:Common.js#Arial_Unicode_MS_for_IPA
• New IPA Fonts in Windows 7
• Test page: w: Wikipedia:IPA#Affricates_and_double_articulation

 —Michael Z. 2012-03-16 15:54 z

How do I override the default, what I'd really like is my own font back, which I found to be very good! Mglovesfun (talk) 09:50, 19 March 2012 (UTC)

Put CSS declarations into User:Mglovesfun/vector.css (assuming you see the default vector skin, and a reasonably modern browser).

• To just style the IPA, put in a font list like this, where “lucida grande” is your first-choice font, and “sans-serif” is a generic fallback:

.IPA { font-family: lucida grande, arial, sans-serif; font-size: 100%; }

• To make IPA use the same font as the rest of the page:

.IPA { font-family: inherit; font-size: inherit; }

 —Michael Z. 2012-03-19 14:41 z

Just... I'm not sure what the previous font was. Mglovesfun (talk) 14:58, 19 March 2012 (UTC)

Probably Arial Unicode MS (since the changes to the font ranking were to remove that font). Try it and see if that's it. - -sche (discuss) 20:32, 19 March 2012 (UTC)

Ah. w: Arial Unicode MS was recently removed from the .IPA declaration. Try the following to restore the previous look:

.IPA { font-family: Arial Unicode MS, sans-serif; }

But you may have problems with the display of double-wide combining marks, as described in w: Arial Unicode MS#Bugs. Depending on your OS, a good alternative may be just plain Arial, or you could download a free IPA font like DejaVu Sans. —Michael Z. 2012-03-19 20:31 z

Fixed, thanks. Mglovesfun (talk) 20:36, 19 March 2012 (UTC)

(deprecated template usage) chested is an adjective used only in combination (e.g. (deprecated template usage) flat-chested, (deprecated template usage) barrel-chested). At present the comparative and superlative forms are shown as "more (something) chested" and "most (something) chested" respectively. Is there a better way than that? Obviously we don't want entries at those titles. Thryduulf (talk) 14:54, 16 March 2012 (UTC)

I'm guessing that there aren't too many who would object to the combined-from headwords, as there is this, admittedly weak, reason to have them. But perhaps someone has another idea. (BTW, why not flatter-chested, flattest-chested?) DCDuring TALK 20:05, 16 March 2012 (UTC)

I didn't actually think to look before your comment, but a quick look at bgc shows that both flatter-chested and more flat-chested are used. Unsurprisingly *barreler-chested and *barrelest-chested are not evidenced, so it seems that the comparative and superlative forms of "-chested" depends on the forms of the word it is used in combination with. Given this, does "-chested" therefore even have such forms, even though it is comparable? Thryduulf (talk) 00:30, 17 March 2012 (UTC)

Not convinced. It's rare to see it without combination, but it happens: "Dionysus, like Adonis, was a chested God — that is to say, he was placed in a chest"; "Lennon chipped a short pass to Keane, who took his goal brilliantly with a chested control then a volley into the net"; "unaltered records of your christening / Like a chested treasure". Equinox ◑ 00:43, 17 March 2012 (UTC)

What do you think of my changes to the entry? Feel free to make the usage notes shorter, or to revert. - -sche (discuss) 00:54, 17 March 2012 (UTC)

@Equinox --

While your examples show chested used on its own, they are also examples of different senses from what is currently given on the entry page. #1 and #3 are past participles of chest as in "to put or be put into a chest"; #2 refers to catching a football / soccer pass with the chest, similar to the verb " to head (a ball)". Neither of these senses match the current def of "having a chest" (anatomically speaking). -- Eiríkr Útlendi │ Tala við mig 02:00, 17 March 2012 (UTC)

Right, those are entirely different senses (from "flat-chested" and the like). - -sche (discuss) 02:51, 17 March 2012 (UTC)

I've noticed a few categories below interwiki links. Isn't the standard to place them at the end of the language section and thus, in entries with only one language section, at the bottom of the entry but above the interwikis? If so, is there a bot like AutoFormat (KassadBot, Mg's bot) that spots and fixes the placement? - -sche (discuss) 22:16, 18 March 2012 (UTC)

It's beyond what I can do, I'm in favor of it though. Interwikis should always be dead last, expect outside the main namespace. Mglovesfun (talk) 09:40, 19 March 2012 (UTC)

Have only just noticed (d'oh) that this displays Old South Arabian whilst the header used by Caphthor (talk • contribs) is Old South Arabic. Which way do we fix this? By that, I mean both should be the same. Mglovesfun (talk) 20:24, 19 March 2012 (UTC)

Wikipedia calls it Old South Arabian, and I think that's preferable, because it isn't a dialect or variety of Arabic (a language to which it is only very distantly related). Calling it "South Arabic" would confuse it with the Southern dialects of Arabic. —Angr 21:59, 19 March 2012 (UTC)

Anyone else? It's a very simple job to update the headers, I'll leave a bit more time before doing it though. Mglovesfun (talk) 22:01, 19 March 2012 (UTC)

Hold on, why are we treating Old South Arabian as a single language anyway? ISO breaks it up into four languages: Sabaean, Minaean, Qatabanian, and Hadramautic, each with its own ISO 639-3 code. —Angr 22:03, 19 March 2012 (UTC)

Done for the headers. For the rest, I have no useful input (though some might say that doesn't usually stop me). Mglovesfun (talk) 13:18, 21 March 2012 (UTC)

Angr, we do this because most academic sources treat OSA as one single language. -- Liliana • 13:46, 24 March 2012 (UTC)

At the moment, if I search for a word but there is no entry for it, I might get a nessage say "try this Wikipedia article". Actually if I don't find a Russian word here, I usually go straight to the Russian Wiktionary and try there. Would it be possible to search other Wiktionaries automatically? YokeyDokey (talk) 12:46, 21 March 2012 (UTC)

Yes, it will be fine to get results from the Wiktionary.

Now you can ask Google:

site:wiktionary.org lead

and you will see several Wiktionaries which describe or mention the word "lead" (e.g. English Wiktionary, Russian Wiktionary, Simple English Wiktionary). -- Andrew Krizhanovsky (talk) 13:07, 21 March 2012 (UTC)

I'm no expert, but, I imagine having the search process check every other Wiktionary would slow the search down A LOT. Mglovesfun (talk) 13:15, 21 March 2012 (UTC)

Perhaps just a "click here to search other Wiktionaries" link? I should clarify that I'm probably looking for a foreign word e.g. мясистый, so even if it's not here there's a good chance it has an entry in its own language (at least if that language is Russian). The Google suggestion above works for мясистый but involves extra typing, LOL YokeyDokey (talk) 19:55, 21 March 2012 (UTC)

That would seem reasonable. Mglovesfun (talk) 15:15, 24 March 2012 (UTC)

No bots have been running here for several hours. Mine gets "Pausing 500 seconds due to database server lag." (repeatedly). They seem to be running on other wikis. Any ideas? SemperBlotto (talk) 16:35, 21 March 2012 (UTC)

Mine works, but mine doesn't use a script directly, it uses AWB. Mglovesfun (talk) 16:59, 21 March 2012 (UTC)

Started running again a few hours later. None the wiser. SemperBlotto (talk) 08:17, 24 March 2012 (UTC)

In etymology sections, how do you show words with two suffixes added simultaneously? For example, (deprecated template usage) Discordianism is from (deprecated template usage) discord + (deprecated template usage) -ian + (deprecated template usage) -ism ((deprecated template usage) Discordian being a backformation from (deprecated template usage) Discordianism).

{{suffix}} only works with a single suffix. {{confix}} is for 1 prefix + 1 suffix. {{compound}} is for independent words according tot he documentation. Thryduulf (talk) 02:49, 22 March 2012 (UTC)

You don't want to use {{back-form|Discordianism}}? DCDuring TALK 03:02, 22 March 2012 (UTC)

Claim ] as a suffix. ;) (see -icity, Talk:-icity)

If that is undesirable... write the etymology out and manually add the relevant categories. - -sche (discuss) 03:04, 22 March 2012 (UTC)

You can use this: {{suffix|discord|ian}} {{suffix||ism}} —CodeCat 12:53, 25 March 2012 (UTC)

Just wanted to inform you of my intention to remove p as a legal first unnamed parameter for templates such as {{cmn-noun}}. To clarify, you will no longer be able to choose p (for pinyin), but you will be able to link to pinyin as usual. This stems from Wiktionary:Votes/2011-07/Pinyin entries. Mglovesfun (talk) 12:06, 25 March 2012 (UTC)

I've added threads to my talk page, but all the old discussions still show as they did before. Is it possible to convert them into threads as well? —CodeCat 12:51, 25 March 2012 (UTC)

For WT:TODO, I would like a list of all the context labels which categorize which have the wrong language parameter, bearing in mind that no language parameter means defaulting to English. Something like {{biology}} in a French section or {{physics|lang=fr}} in an English section. Thank you, Mglovesfun (talk) 11:45, 26 March 2012 (UTC)

And please, please, please, can a bot fix these? Preferably in real time? And add lang to {{rfp}}, {{rfe}}, and {{homophones}} also?​—msh210℠ (talk) 19:57, 28 March 2012 (UTC)

I would like to simplify this template so that it's as fast and small as possible. I've created a new version at User:CodeCat/l. It's the same but I've removed the gender, gloss and transliteration. My rationale:

• It's good to have a template that creates links and does nothing else, especially so that other templates such as {{term}} can use it as a base. It might as well be {{l}}.
• It removes the duplication between this template and {{onym}}.

I have left in the script, so it still adds the appropriate script for the specified language. I'm not sure if that is a good thing, because there are some cases where this template would be used where no script template is needed; mostly in the head= parameter of headword-line templates, which already enclose the parameter in a script template themselves. On the other hand, having the script in this template means it can be used elsewhere in entries without too much trouble.

I'm not sure which template is best suited to replace this one in cases where the gloss, gender or transliteration are used. {{onym}} is a good candidate, but I do think it needs a better name... —CodeCat 12:54, 28 March 2012 (UTC)

Editors of Japanese entries have been making extensive use of {{l}} to provide language-specific links *with transliterations*. I have zero qualms about taking {{l}} and creating a separate leaner template. However, I would be strongly opposed to any move to strip out functionality from {{l}} that many many many Japanese entries currently make use of—unless you also have a bot ready to go that can replace all instances of {{l}} that use the features you're proposing to remove with some other template that provides identical features (such as {{onym}}, as best I can tell). -- Eiríkr Útlendi │ Tala við mig 15:15, 28 March 2012 (UTC)

I don't think three extra #ifs really makes much of a difference... We could lower it to one #if by wrapping the transliteration, gender, and gloss bits in a single #if, if necessary. --Yair rand (talk) 15:16, 28 March 2012 (UTC)

Indeed... we really have bigger fish to fry. -- Liliana • 09:23, 29 March 2012 (UTC)

I'm opposed for the same reason as everyone else, but also for the converse reason: I don't see any advantage of {{l|la|edo|edō}} over ] in an environment where the language and script markup has already been handled by a containing template. Rather than stripping {{l}} down so it's lighter-weight in those cases, I think we just shouldn't use it in those cases. —Ruakh_TALK 16:07, 1 April 2012 (UTC)

I added a link to the French Wiktionary to the Ditidaht page and the history shows that it is a (bad-iw), which I think means bad interwiki link. I've looked at other pages but cannot figure out what is wrong. Can someone show me what I'm doing incorrectly? BenjaminBarrett12 (talk) 07:07, 29 March 2012 (UTC)

• Interwiki links must be exactly the same as the entry title. That means have the same spelling and the same case. SemperBlotto (talk) 07:10, 29 March 2012 (UTC)

  Thank you! BenjaminBarrett12 (talk) 07:21, 29 March 2012 (UTC)

I'm trying to find a way to use <onlyinclude> tags only when a certain condition is met. However, apparently due to the order in which the MW parser evaluates the code, things don't work the way I was hoping.

Sample code:

If this is really it,
  {{#ifeq:{{{ts}}}
  |T1
  |<onlyinclude>I have no objection.</onlyinclude>
  |I have no objection,
  }} so let's proceed.

The idea is that when this is transcluded as {{template|ts=T1}}, then we would only see I have no objection. on the calling page; and if this is transcluded as {{template|ts=}}, then we would see If this is really it, I have no objection, so let's proceed.

However, it seems that the <onlyinclude> tags are evaluated before the #ifeq: parser extension function, such that *any* transclusion of this content only shows I have no objection.

Does anyone have any advice on how to proceed? -- TIA, Eiríkr Útlendi │ Tala við mig 18:08, 29 March 2012 (UTC)

Would it be possible to make one template with the content <onlyinclude> and another with the content </onlyinclude>, and use them in place of the tags themselves in your example above? Would that make it work? I have no idea... - -sche (discuss) 18:15, 29 March 2012 (UTC)

I should have mentioned that I've already tried that -- the tags then appear in the final transcluded page as plain text, which isn't very useful.

I also tried putting <onlyinclude>{{{1}}}</onlyinclude> in a separate template and transcluded that into the template I'm trying to transclude selectively, but substing on the final target page to inspect shows that the tags apply on the page they appear on first, so they <onlyinclude> the {{{1}}} param correctly, and then vanish further up the transclusion tree.

I've also tried using <noinclude> around the <onlyinclude> tags, in different combinations (opening and closing tags separately noinclude-ed, and the whole <onlyinclude>...</onlyinclude> shebang noinclude-ed), but to no avail -- the onlyinclude and noinclude tags are evaluated at the same time, so things don't work out quite as one might like.  :-/

In one moment of misguided cleverness, I even tried using &lt;onlyinclude> in various locations in the transclusion tree, but this always output as text. -- Cheers, Eiríkr Útlendi │ Tala við mig 18:59, 29 March 2012 (UTC)

As I think you've gathered, this is expected behavior. The purpose of <noinclude> and <onlyinclude> (and <includeonly>) is to indicate which parts of a page in the Template namespace are actually part of the template vs. which parts are only part of the template-page (vs. which parts aren't part of the template-page), so they're processed before almost anything else. In fact, I believe that when you modify parts of a template page that are inside <noinclude> or outside <onlyinclude>, that the software is smart enough not to add transcluding pages to the job queue, since those changes don't affect the template itself. (I'm not sure about that, though.)
That said, this restriction doesn't matter at all for <noinclude> and <includeonly>, since you can do something like {{#if:<noinclude>x</noinclude>|--this-text-is-not-transcluded--|--this-text-is-only-transcluded--}}; and therefore, it doesn't really matter for <onlyinclude>, since it's just syntactic sugar for <noinclude>. Your example, as I'm sure you know, could be written as {{#ifeq:{{{ts}}}|T1|I have no objection.|If this is really it, I have no objection, so let's proceed.}}, since the only way that {{{ts}}} can be T1 is if it's being transcluded.
—Ruakh_TALK 21:33, 29 March 2012 (UTC)

Thanks Ruakh, that confirms my understanding.

Here's the core of the problem I'm trying to solve, in (hopefully) better detail.

• For a given page with elements ABC, how does one mark B to be:

1. transcluded *on it's own* when a param is set to a specific value, excluding all other page content, and
2. transcluded *together with everything else* when a param is either not set, or set to some other value, and also
3. allow the passing of parameters for customizing the content of B.

I think I know already how to do this using specialized #if: and/or #ifeq:statements, but this requires that the entire page be bracketed by a conditional that defines the case(s) for including everything. What I was hoping to do with the current effort is to find a way of doing this that does not require the whole-page-bracketing conditional. Labeled section transclusion as described at WT:ES presents one way of doing this, but LST does not allow the passing of parameters. Some way of conditionally inserting or activating a <onlyinclude> statement surrounding B would be another way of doing this that would allow for parameter passing -- but due to the order of evaluation, this doesn't work.

I don't suppose you have any insights? -- Eiríkr Útlendi │ Tala við mig 22:10, 29 March 2012 (UTC)

I don't know. Maybe I'd feel differently if I knew your use-case, but it seems to me that if the presence or absence of A and C in the template is intended to be controlled by the value of a certain parameter, then A and C really should be wrapped in #ifeq: expressions, because, well, you want to conditionally include them. You apparently view the presence or absence of A and C to be a property of B, rather than of A and C, but that seems very counterintuitive to me. (But again, maybe I'd feel differently if I knew your use-case.) So I'd write either this:

{{#ifeq:{{{param}}}|value||A}}B{{#ifeq:{{{param}}}|value||C}}

or this:

{{#ifeq:{{{param}}}|value|B|ABC}}

depending on the relative sizes and complexities of A, B, C, and the conditional test — and perhaps depending on how hard it would be to factor stuff out (especially B) into a helper template.
—Ruakh_TALK 23:52, 29 March 2012 (UTC)

Apologies for not being more explicit about the use case, I've had my head stuck in several things today and haven't been at my clearest. This is mostly about investigating the possibility of building cascading etyl trees, so my avoidance of changing A or C is based on the question of "how do we mark an etyl (or portion of an etyl) for selective transclusion, in a way that includes params for specifying target language for etyl cats, and without having to add anything to the rest of the page?" C.f. the thread at Wiktionary:Beer_parlour#Etyls_for_borrowed_words_--_how_far_back_to_track.3F. This is partly to reduce the amount of work if etyl trees function as desired and folks decide to try to implement them. In part too, I thought I remembered reading somewhere that it was considered very bad form to have anything on the page before the first ===header=== line, but maybe I misunderstood.

Using onlyinclude is pretty handy, but with no way of conditionally turning off onlyinclude, it also means that the rest of the page is never transcluded, which I can envision as causing no end of confusion. -- Thanks for casting an eye over this, and for helping stir my sluggish brain.  :) Eiríkr Útlendi │ Tala við mig 01:04, 30 March 2012 (UTC)

Can anyone help please? — Category:Greek adjective inflection-table templates should contain all those templates - but it doesn't, although the "cat" statement is contained in their "Documentation" pages. To take two examples with identical(?) formatting: Template:el-decl-adj-ος-ια-η-ο and Template:el-decl-adj-ός-ιά-ή-ό both show the "Catalogue" link at the bottom of their page - but only the latter is listed on the category page. — Saltmarsh^{απάντηση} 05:07, 31 March 2012 (UTC)

That sort of inconsistency happens sometimes temporarily. If you don't want to wait for it to resolve itself, you can make a null edit to the page that isn't listed; for example, just now I visited Template:el-decl-adj-ος-ια-η-ο?action=edit and clicked "Save page", so now Category:Greek adjective inflection-table templates lists it. —Ruakh_TALK 19:34, 31 March 2012 (UTC)

Thanks - done - some of these were last edited in January and hadnt worked their way through. — Saltmarsh^{απάντηση} 05:08, 1 April 2012 (UTC)

Oh. It used to be that they resolved themselves — or I thought they did — but maybe that's not true anymore, then? :-/   —Ruakh_TALK 13:39, 1 April 2012 (UTC)

Many of our entries have etymologies containing variants of "c." ("c." / "c" / "c." / "c" / "C" / "C." / "C."), short for "circa". Many also contain variants of "cf." (add an f to all the variants of c, above), for "confer#Latin". Because Wiktionary is not paper, it doesn't have to use potentially-confusing abbreviations, so I wonder if someone with a bot could replace the various occurrences with "circa" (or, even more clearly, "attested circa", which is almost always what is meant) and "compare". Here's a partial list for anyone would wants to edit the entries with AWB, although methinks telling a bot to edit things as it naturally skimmed over all our entries would be easier:

• c : discord gangster donate authoritarian disability numinous adaptitude heliostat virescent sycomore sycamore disbelieve iridescent acetification heteronym inalienable anonymous indigent guzzle confection burger legion availability hieroglyph centenarian immanent humanitarian anonym equalitarian putrescent centenary beautification rubescent astronomical lickety-split reification prose offing notability dollar scissors realize anthroponym opalescent squeeze split dwarf arborescent
• cf : el nana celo civet baste mope squander brou actionable winkel Wallachia boira gibe glans gebied (Equinox has fixed these)

- -sche (discuss) 05:07, 31 March 2012 (UTC)

Here are some more: Wiktionary:Todo/unhelpful abbreviations.

--MaEr (talk) 05:18, 31 March 2012 (UTC)

Oh! Your list is more complete than mine. I just removed the "L" section from it, though; all those instances of L were initials. - -sche (discuss) 05:46, 31 March 2012 (UTC)

The Web hasn't made abbreviations obsolete. Please think before expansion-botting everything in Wiktionary. And who are these semiliterate readers that we are always mollycoddling? Who exactly is the audience that understands the latinism circa 2012 but not its abbreviation c. 2012?

Which of the following is easier for you to read? Let's show our readers some respect with good writing, in favour of baby-talk.

C. 1895, gang +‎ -ster.

Attested about the year one thousand, eight hundred and ninety-five, from (deprecated template usage) gang compounded with (deprecated template usage) -ster.

 —Michael Z. 2012-04-01 00:49 z

Expanding opaque Latin abbreviations does not slippery-slide into expanding year-numbers into spelt-out words. And expanding abbreviations in entries is a longstanding, wiki-wide (de.wikt, en.WP, ...) practice. - -sche (discuss) 01:34, 1 April 2012 (UTC) - -sche (discuss) 01:41, 1 April 2012 (UTC)

Don't you mean German.Wiktionary and English.Wikipedia? :) —CodeCat 01:39, 1 April 2012 (UTC)

touché! :-P - -sche (discuss) 01:41, 1 April 2012 (UTC)

• FWIW, I think the attested would be a good addition. Without it, a bald c. or circa would suggest to me that the term was *coined* then, not that it was first attested then. Perhaps a fine point, but one that feels important to me.  :) So for my money, it looks like a comparison between these two:

C. 1895, gang +‎ -ster.

Attested circa 1895, gang +‎ -ster.

Now, if folks are worried about the on-screen presentation, I can sympathize to some extent -- tighter certainly looks cleaner. However, *discoverability* is an important aspect of good usability. If a user indeed doesn't know what c. means, we should make it as easy as possible for them to find out. Perhaps there's some way of keeping the shorter on-screen look while still providing useful discoverability, maybe some variation on the following:

C. 1895, gang +‎ -ster.

-- Cheers, Eiríkr Útlendi │ Tala við mig 19:28, 1 April 2012 (UTC)

“Attested” applies to every single date in an etymology, including the few that say “coined.” Better to clarify this in WT:ELE#Etymology than to enter it in 1,000,000 etymology sections.

Is there any evidence at all that readers are frustrated by the use of c., that we have to clutter etymologies with written-out abbreviations or more techno-junk?

Clutter and redundant long-form writing can harm the usability of a reference work. —Michael Z. 2012-04-01 19:54 z

I fail to see how either spelling out "attested circa" or using <abbr> tags constitute clutter or usability impediments (though I happily grant that the tagged version could be better served in the wikitext by a simple template); clarity of meaning seems to me to be tantamount. Perhaps we'll just have to agree to disagree. -- Eiríkr Útlendi │ Tala við mig 20:09, 1 April 2012 (UTC)

Agree with.....everyone but Mzajac on this. This is such a small amount of additional text that it can hardly be considered significant bloat. "c." is such an opaque reference that we have to assume plenty of our readers won't understand it (I for one forget what it means all the time). I absolutely fucking hate trying to read paper dictionaries, because they're forced to use all of those bizarre Latin abbreviations like c. and s.q. and so on. I understand why they did it, but since we don't there's absolutely no justification for doing so. I imagine our readers' self-esteem can suffer the disrespect we're showing them by spelling out words. -Atelaes λάλει ἐμοί 20:48, 1 April 2012 (UTC)

I prefer the full forms too. I don't mind us using symbols (like arrows) to show the progression of a term's development, but I don't like abbreviations much. I'm more opposed to words that are wholly redundant, like "From" at the start of some etys. Equinox ◑ 20:50, 1 April 2012 (UTC)

EncycloPetey twice blocked a user for removing 'from' as the first word of many etymologies. This despite the fact there's no rule promoting 'from' in etymologies. So I'd strongly suggest he would disagree with you. Mglovesfun (talk) 20:59, 1 April 2012 (UTC)

I would also disagree. 'From' is perhaps not entirely necessary, but it takes such little space, is helpful in orienting the user as to what information is being presented, and generally just makes for a better flowing etymology. I always start my etymologies with 'from', when appropriate. -Atelaes λάλει ἐμοί 21:09, 1 April 2012 (UTC)

I always start my etymologies with 'not from'. - -sche (discuss) 21:20, 1 April 2012 (UTC)

Nice. —Michael Z. 2012-04-02 00:02 z

Right, we're not paper. Then be specific and precise, and cite dates with “First attested.” Use plain English, and write “about 2012” instead of the elitist Latin “circa.” And why don't we also expand usage labels for clarity? (US, UK) should be (United States of America, United Kingdom of Britain and Northern Ireland). And all this grammarian's n f pl business in {{term}} should clearly be written out noun, feminine gender, plural number. There isn't even a common form for BC/BCE and AD/CE, so nobody can be expected to know what they mean – make the entry say “First attested in the year 50 Before Common Era.”

It's all going to be such a breeze to read when we're done. —Michael Z. 2012-04-02 00:02 z

As commented above, "Expanding opaque Latin abbreviations does not slippery-slide into expanding year-numbers into spelt-out words". Your slippery-slope examples are disingenuous. Equinox ◑ 00:07, 2 April 2012 (UTC)

Uh-huh. Seriously, you think changing c. 1200 to circa 1200 will prevent all those needless misunderstandings, but an isolated letter n after a term is perfectly clear to the same misunderstanders? —Michael Z. 2012-04-02 00:30 z

Fair point... but even though avoiding any misunderstandings would be best, it's still better to avoid some misunderstands than to avoid none, right? - -sche (discuss) 01:45, 2 April 2012 (UTC)

Yes, but in a balanced and consistent way, and with some actual justification. I believe I have illustrated the point that “Wiktionary isn't paper” doesn't mean that every abbreviation is to be expanded without any thought, or that abbreviations don't belong on websites. C. 1500 is one case where a date expression has a clear shape, and is easier to recognize and read at a glance than its long form or its plain-English equivalent. I have been seeing etymologies gradually evolve from a terse, symbolic and easily readable at-a-glance form, to blocks of running text. There has been no policy or consensus for this change, just every few months somebody shouts “not paper!” and starts wiping out another very useful shorthand expression. —Michael Z. 2012-04-02 03:27 z

Actually, most of these changes have followed discussions. I know that a discussion has taken place concerning circa before (one which, as I recall, achieved consensus in favor of expanding the abbreviation). I believe the transition from less than signs to 'from' was actually given a formal vote. I could be mistaken on some of the specifics, and I've no idea where these discussions are, and I'm simply too lazy to try and find them. In any case, I'm quite confident that the situation is not as you paint it. -Atelaes λάλει ἐμοί 04:00, 2 April 2012 (UTC)

• Replacing "c." (or "circa") with "about" -- sounds fine to me. In running speech, "circa" is seldom used, and saying just "cee" never really happens.
• Replacing "US/UK" with "United States of America / United Kingdom of Britain and Northern Ireland" -- ridiculous. The countries are called "the Yo͞o Ess" and "the Yo͞o Kay" in everyday speech, so these hold no ambiguity.
• Replacing grammatical initialisms with full words -- also sounds fine to me. In fact, we don't use such initialisms in any of the JA entries that I've worked on, preferring instead to spell things out as "noun" or "transitive", etc. The initialisms *are* used in the wikitext code for templates and the like, but if someone is digging into the wikitext, I believe we can safely assume a certain level of technical knowledge (or at the bare minimum, enough curiosity to learn). -- Eiríkr Útlendi │ Tala við mig 03:01, 2 April 2012 (UTC)

What has everyday running speech got to do with this? This is a written reference work. It is used to look things up, and terse symbolic expressions help a competent reader do this quickly. (And my proposals were rhetorical, although some may have merit.)

The tersely abbreviated grammatical labels are used in the entry core (e.g., горілки), inflections (canadien) and in definitions (українська). They also appear in some etymologies thanks to {{term}} (varenyky). It also makes sense to use them in lists, as in горілка#Synonyms.

Even less self-explanatorily, we use an asterisk to indicate reconstructed words. —Michael Z. 2012-04-02 06:05 z

• My mention of running speech was an allusion to what the non-Wiktionary community might be most familiar with. Some of my less-educated acquaintances and less-English-fluent acquaintances would read "about 1905" and understand, but see "c. 1905" or even "circa 1905" and not necessarily know what that meant exactly.
• "terse symbolic expressions help a competent reader do this quickly" -- sure. And spelling out things like "f" and "pl" to "feminine" and "plural" 1) don't slow me down one jot, so long as things are consistent; and 2) help less-competent readers. Bear in mind that WT in any language is also used by language learners.
• The asterisk strikes me as less of an issue, largely because these are all words in appendices, and anyone clicking through will see either that the entry doesn't exist (which seems to be most of them), or that the entry is for a reconstructed language. This is qualitatively different from the "f" and "pl" initialisms that have a direct bearing on how a word is used, and that may be opaque to potential users. We could at least link them through to the respective entries, and even do that at the template level for a minimum of work; but whereas pl does give "plural" as a meaning, the entry at f does not give "feminine" anywhere in the entry except, confusingly, for a translation table header. -- Eiríkr Útlendi │ Tala við mig 06:27, 2 April 2012 (UTC)

Can someone add script functionality to {{hyphenation}}, so I can use sc=Armn please? --Vahag (talk) 18:45, 31 March 2012 (UTC)

I've added lang= and sc= parameters to the template, so you can use {{hyphenation|...|lang=hy}} now. —CodeCat 19:22, 31 March 2012 (UTC)

Something's wrong. See հպարտ. --Vahag (talk) 19:27, 31 March 2012 (UTC)

Sorry I made a typo, it's fixed now... (But I *really* think we need a better usage example on that page!) —CodeCat 19:28, 31 March 2012 (UTC)

Thanks for adding the functionality. PS Children like my usage examples. --Vahag (talk) 19:30, 31 March 2012 (UTC)

Currently, this template defaults to 'no language' so it links to the top of the page. However, unless there is a translingual section on that page, it will link to the English section this way. Is it desirable to always make it link to English if no language is specified? —CodeCat 19:25, 31 March 2012 (UTC)

Slight correction: If no language is specified, it links to the top of the page which, on pages with a table of contents, is the ToC, not the English section. I think the current behavior is fine, but better yet would be to link to the first L2, whether that be English or Translingual. I can't, however, think of a way to do that (without JavaScript).​—msh210℠ (talk) 15:56, 1 April 2012 (UTC)

Well, assuming that every usage of {{term}} was intended to point to a term in a specific language (I can't imagine a term with no language?), there are three different cases where no language was specified. Either it was meant to link to English, to translingual, or to another language. The third case is simply a mistake and should be corrected by adding the lang= parameter. It's harder to say what should happen to the first and second cases. If it was meant to link to English and there is no translingual section, then it's fine. If it was meant to link to translingual, it's fine too. It only goes wrong if the link was intended to point to English, but there is a translingual section on the page so that it links to that instead. If English is made the default, then it will instead go wrong whenever the intended target was translingual but there is also an English section. So no matter what we do, the link can only lead to the wrong section if both English and translingual appear on the same page. Luckily such pages are fairly rare... so I don't think there is really much harm in changing it. It also makes the intent of the template more clear and brings it in line with most other templates, which also default to English. And it may also help make mistakes more obvious (especially with tabbed languages) so that they can be more easily fixed. —CodeCat 22:08, 1 April 2012 (UTC)

The fourth case is that it links, as intended, to the page and not to a section at all. (If we only wanted links to entries by language, then we would have them at term/English or en/term or something. Possibly a good idea.)

Changing links doesn't solve the real problem, which is that thousands of pages have zero visible content, until the reader thinks to scroll. what kind of website purposely creates this terrible situation? The solution is to put the T.O.C. on the right in your user prefs, and to set that as the default for all readers. —Michael Z. 2012-04-01 23:34 z

I still think that every entry should have a different page for each language, but that will probably not happen soon, so for now tabbed languages solves the problem for me. I use it all the time. Unfortunately though, with tabbed languages links don't work right if {{term}} is not given the right parameter, because it defaults to the last-selected language. That is a good default I think, but it fails in the case when people assume that specifying no language is the same as English. Intentionally not linking to any language with {{term}} is so rare that it should be treated suspiciously whenever it does happen. Especially because with tabbed languages there is no such thing as 'top of the page' or 'no language'. —CodeCat 23:56, 1 April 2012 (UTC)

Ah, is that what this is abou? Tabbed languages is too stupid to deal with ordinary links, so we're going to eliminate them now? You're welcome to use whatever interface you want, but please don't complicate the rest of Wiktionary to support it.

There's about a bajillion pages on the web that link to pages on Wiktionary. Let's keep operating as if the rest of the Web still existed. —Michael Z. 2012-04-02 00:16 z

diff. Mglovesfun (talk) 09:24, 4 April 2012 (UTC)

I would have written it this way... —CodeCat 12:48, 4 April 2012 (UTC)

What proportion of the time, when {{term}} is missing a lang=, is it supposed to be lang=en? (It's unfortunate that {{term}} was designed with lang= being optional — or at least seeming optional — but I don't think it'll be easy to fix that.) —Ruakh_TALK 14:31, 4 April 2012 (UTC)

I know I've been using {{term|sc=Hani|}} for Japanese etyls deriving from older Chinese variants, since linking to modern Mandarin or Cantonese etc. would be a mistake. Should I be adding lang=zho instead, even though such language headings don't exist? -- Eiríkr Útlendi │ Tala við mig 15:20, 4 April 2012 (UTC)

Why can't it just be from whatever language it comes from? ({{och}}, {{ltc}}, etc.) --Yair rand (talk) 15:34, 4 April 2012 (UTC)

Often because that information isn't available anywhere I can get my hands on it -- in many cases, all I can find is that it entered Japanese 700-1,600 years ago. If I'm lucky, I can nail down details like region or dynasty, in which case a more detailed lang code would make sense, but for many terms, {{zho}} is as specific as I can get at the moment. -- Eiríkr Útlendi │ Tala við mig 15:47, 4 April 2012 (UTC)

Are you saying those old terms are not actually attested anywhere? If that's the case, they shouldn't even really be linked to at all... —CodeCat 19:59, 4 April 2012 (UTC)

• No, they're certainly attested. It's just not always clear if the origin was Tang Chinese, Song Chinese, Wu Chinese, what-have-you. This is partly because Chinese characters used in Japanese were imported at different times, sometimes multiple times, and from different (and sometimes multiple) places, so a given character might have readings from different Chinese dialects and time periods. Japanese-language source materials for single Chinese characters might give the categories for the readings, which points (usually) to which Chinese dynasty/dialect was the source, but words of more than one Chinese character are seldom indicated as to when they were imported. One can infer from the categories of the readings of the individual characters, but that's assuming that the reading categories are even given for the individual characters. Plus, there's one not-uncommon reading category (kan'yōon) that is pretty well divorced from the source Chinese dialect -- these are readings that might have originally been misreadings in Japanese contexts that became normalized, or they might even be idiosyncratic Chinese readings that came into Japanese when the word/character was first borrowed.

Consequently, sometimes the best we can say is that a given word was borrowed into Japanese from pre-modern Chinese, but we might not be able to say precisely which variety.

Does that all make sense? And in such cases, is the {{zho}} lang code acceptable for term links? It's already been used quite a bit as the source lang code in {{etyl}}, and I think by more than just by me... -- Eiríkr Útlendi │ Tala við mig 20:24, 4 April 2012 (UTC)

• I don't agree with setting the default to English. Currently, leaving out the lang parameter just means that the language isn't specified. Changing this would introduce inaccuracies. Can't we just have a cleanup list for unknown and unspecified langs? --Yair rand (talk) 20:03, 15 April 2012 (UTC)