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:
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)[reply]
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. —RuakhTALK13:25, 2 March 2012 (UTC)[reply]
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)[reply]
including gender (definite articles) and verb principal parts
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)[reply]
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. —CodeCat16:48, 2 March 2012 (UTC)[reply]
@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. —RuakhTALK18:28, 2 March 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. — billinghurstsDrewth16:11, 5 March 2012 (UTC)[reply]
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 [[Special:AbuseFilter/16]]. —RuakhTALK15:11, 6 March 2012 (UTC)[reply]
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. — billinghurstsDrewth11:09, 7 March 2012 (UTC)[reply]
Some ACCEL entries still adding unneeded code
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|[[{{PAGENAME}}{{subst:♯}}Spanish|{{PAGENAME}}]]|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)[reply]
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)[reply]
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. ;-) —RuakhTALK21:48, 6 March 2012 (UTC)[reply]
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)[reply]
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}}. —Internoob05:06, 8 March 2012 (UTC)[reply]
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)[reply]
I've found that the IPA tie bar over the top does not seem to render properly on Wiktionary. Example: [t͡su͍ɽa̠] -- 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 [t͡su͍ɽa̠]. 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.
I see the same thing Eirikr describes; [t͡su͍ɽa̠] has the tie bar begin over the : and end over the t; [t͡su͍ɽa̠] 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)[reply]
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ð mig19:53, 12 March 2012 (UTC)[reply]
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.
Same here. I think what -sche and I are seeing is another aspect of the Arial Unicode MS bug.
Examples:
[t︠s︡u͍ɽa̠] invalid IPA characters (︠︡)
[t︠s︡u͍ɽa̠]
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.
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. —CodeCat22:41, 12 March 2012 (UTC)[reply]
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ð mig23:20, 12 March 2012 (UTC)[reply]
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ð mig04:59, 13 March 2012 (UTC)[reply]
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. —MichaelZ. 2012-03-17 04:34 z
Letters being raised or lowered
FirefoxOpera
Separate issue: the diacritics below the u and a in [t͡su͍ɽa̠] are not aligned (the letters themselves are not at the same height; u is higher); in [t͡su͍ɽa̠], they align. I wonder if font-size: 110%; is doing us in? - -sche(discuss)20:26, 12 March 2012 (UTC)[reply]
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ð mig20:32, 12 March 2012 (UTC)[reply]
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)[reply]
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ð mig20:50, 12 March 2012 (UTC)[reply]
Could this template be made subst:able? I'd like it so that {{subst:theplural|noun}} is replaced with just nouns. —CodeCat15:28, 13 March 2012 (UTC)[reply]
Yes; you can change {{#switch:{{{1}}} to {{<includeonly>safesubst:</includeonly>#switch:{{{1}}}. (Also, wow . . . that template is just hilariously bad.) —RuakhTALK20:26, 13 March 2012 (UTC)[reply]
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. —CodeCat20:44, 13 March 2012 (UTC)[reply]
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. —CodeCat13:07, 14 March 2012 (UTC)[reply]
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.) —RuakhTALK14:57, 14 March 2012 (UTC)[reply]
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? —CodeCat01:22, 15 March 2012 (UTC)[reply]
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. —RuakhTALK17:29, 16 March 2012 (UTC)[reply]
Category pages and "What links here"
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? Pinetalk05:22, 14 March 2012 (UTC)[reply]
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. —Angr11:07, 14 March 2012 (UTC)[reply]
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! —Angr11:04, 14 March 2012 (UTC)[reply]
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! —Angr11:05, 14 March 2012 (UTC)[reply]
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)[reply]
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: On Mint —CodeCat13:19, 14 March 2012 (UTC)[reply]
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). —Angr17:08, 14 March 2012 (UTC)[reply]
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. —Angr17:38, 14 March 2012 (UTC)[reply]
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. —MichaelZ. 2012-03-14 17:45 z
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. —MichaelZ. 2012-03-19 20:31 z
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?) DCDuringTALK20:05, 16 March 2012 (UTC)[reply]
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)[reply]
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)[reply]
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ð mig02:00, 17 March 2012 (UTC)[reply]
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)[reply]
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. —Angr22:03, 19 March 2012 (UTC)[reply]
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)[reply]
Yes, it will be fine to get results from the Wiktionary.
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)[reply]
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)[reply]
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? —CodeCat12:51, 25 March 2012 (UTC)[reply]
List request: context labels without lang
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)[reply]
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... —CodeCat12:54, 28 March 2012 (UTC)[reply]
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ð mig15:15, 28 March 2012 (UTC)[reply]
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)[reply]
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 [[edo#Latin|edō]] 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. —RuakhTALK16:07, 1 April 2012 (UTC)[reply]
bad-iw
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)[reply]
How to code selective application of <onlyinclude>?
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=[anything else, even missing]}}, 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.
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)[reply]
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. :-/
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. —RuakhTALK21:33, 29 March 2012 (UTC)[reply]
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:
transcluded *on it's own* when a param is set to a specific value, excluding all other page content, and
transcluded *together with everything else* when a param is either not set, or set to some other value, and also
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 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:
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. —RuakhTALK23:52, 29 March 2012 (UTC)[reply]
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ð mig01:04, 30 March 2012 (UTC)[reply]
Oh. It used to be that they resolved themselves — or I thought they did — but maybe that's not true anymore, then? :-/ —RuakhTALK13:39, 1 April 2012 (UTC)[reply]
c. and cf. in etymologies
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:
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.
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)[reply]
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:
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:
“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. —MichaelZ. 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ð mig20:09, 1 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. —MichaelZ. 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)[reply]
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? —MichaelZ. 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)[reply]
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. —MichaelZ. 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)[reply]
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ð mig03:01, 2 April 2012 (UTC)[reply]
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. —MichaelZ. 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ð mig06:27, 2 April 2012 (UTC)[reply]
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? —CodeCat19:25, 31 March 2012 (UTC)[reply]
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)[reply]
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. —CodeCat22:08, 1 April 2012 (UTC)[reply]
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. —MichaelZ. 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'. —CodeCat23:56, 1 April 2012 (UTC)[reply]
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. —MichaelZ. 2012-04-02 00:16 z
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.) —RuakhTALK14:31, 4 April 2012 (UTC)[reply]
I know I've been using {{term|sc=Hani|[some Chinese character(s)]}} 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ð mig15:20, 4 April 2012 (UTC)[reply]
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ð mig15:47, 4 April 2012 (UTC)[reply]
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... —CodeCat19:59, 4 April 2012 (UTC)[reply]
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ð mig20:24, 4 April 2012 (UTC)[reply]
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)[reply]
Done; see Category:Asturian reflexive verbs. Note that I went with ref=y, as in your comment here, and as in 
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.
