Wiktionary:Beer parlour/2014/November

I've been working on clearing up some missing entries and I've noticed that many of the entries that are redlinked are, in fact, present, but under a capital letter. For instance admiraless is redlinked, but Admiraless is not. This is the case for a good number of nouns and probably ought to be corrected. The list of capital letter English nouns should be culled of all non-proper nouns. —Yellowhen (talk) 18:34, 1 November 2014 (UTC)

Look at the citations listed at Admiraless. It really is spelled with a capital letter. — Ungoliant ^(falai) 18:38, 1 November 2014 (UTC)

"Admiraless" seems to be a truly exceptional case. Equinox ◑ 18:45, 1 November 2014 (UTC)

The citations page does give one example of lower-case admiraless. Examples of lower-case usage are hard to come by since it's almost always as a title or part of a title. However, culling the list of capital letter English nouns of all non-proper nouns would be a bad idea since there are plenty of common nouns that are always capitalized in English, first and foremost demonyms like Englishman and Spaniard. —Aɴɢʀ (talk) 19:00, 1 November 2014 (UTC)

All those capitalized admiralesses are so because they are honorifics, or proper nouns (usually in an archaic writing style), or in in one case in an article title. This is absolutely clear where several of them accompany the term admiral, likewise with initial cap.

There are now three l.c. citations (although one is a reference to the word). This entry should be moved. See Wiktionary:Requests for moves, mergers and splits#Admiraless. —Michael Z. 2014-11-24 02:27 z

I'm getting a bit annoyed that entries that don't meet WT:CFI keep passing a vote at WT:RFD. Is there any way to force WT:CFI to be applied? Renard Migrant (talk) 16:50, 3 November 2014 (UTC)

I think one thing we need to stress is that RFD/RFV discussions are supposed to be about whether the entry meets CFI and not whether we personally want to keep the entry. This is easier to apply when there needs to be a unanimous decision because people are compelled to convince others of their reasons, as I have experienced when serving in a criminal jury. However I'm not sure how it should work when there is a vote and thus less of an obligation to think critically, since I have not experienced a civil jury. (Pardon me if my jury analogy does not hold outside the US.) --WikiTiki89 17:08, 3 November 2014 (UTC)

Whether an entry meets WT:CFI is often a matter of subjective interpretation, not objective fact. While it's true that sometimes people say "keep in spite of the fact that it doesn't meet WT:CFI", much more frequently it's a matter of one side saying "this entry does meet WT:CFI" and the other side saying "no it doesn't". When I vote "keep" at RFD for a term some people consider to be SOP, it's because I disagree with them that it's SOP, not because I think that its SOPness should be ignored. —Aɴɢʀ (talk) 18:17, 3 November 2014 (UTC)

A valid concern. It could be addressed by creating more objective criteria of what makes a term idiomatic, like we did with WT:COALMINE. — Keφr 19:33, 3 November 2014 (UTC)

• Oppose: If people want to keep an entry, it should be kept. This proposal would essentially give deletionists a supervote, and it would damn near make CFI a criteria for speedy deletion. Purplebackpack89 18:52, 3 November 2014 (UTC)
  • It already is a de facto criterium for speedy deletion. —CodeCat 19:01, 3 November 2014 (UTC)
    • And it shouldn't be. CFI is too subjective for that. Speedy deletion should be for junk or vandalism entries. Most entries with RfD votes aren't junk or vandalism entries. Renard wants any entry that doesn't pass CFI to be automatically deleted. The problem is the only way CFI is determined is for somebody to say "this passes CFI" or "this fails CFI", with certain permuations such as "this passes SOP" or "this passes SOP". Therefore, if Renard got his way on this proposal, if any ONE editor said "this fails CFI", the article would have to be deleted. That's regardless of whether or not he's in the minority, or whether or not somebody gives a good reason as to why it doesn't. That seems patently ridiculous to me. Purplebackpack89 19:06, 3 November 2014 (UTC)
      • That's not what I want. The problem is that entries that nobody thinks meet CFI get kept because they win the vote. Right now the vote is everything and policy is nothing. It wouldn't be a 'supervote' for deletions any more than it would be for inclusionists. Interpretation of CFI would matter if we applied it at all. We don't. Like I said, 100% voting, 0% policy. Renard Migrant (talk) 12:30, 6 November 2014 (UTC)
  • You misspelled "support". — Keφr 19:38, 3 November 2014 (UTC)
    • @Kephir, I didn't though. I don't like the ramifications of the enacting of what Renard wants, so I opposed the proposal. Since this is a discussion about interpreting or changing policy, I am fully entitled to oppose it for any reasons I see fit. Purplebackpack89 21:14, 3 November 2014 (UTC)
• Could someone list a few examples of what this would affect, perhaps even recent RFD listings? It sounds like we have two camps:
  1. Delete anything that doesn't meet CFI.
     • Frankly, that sounds reasonable to me, and seems to have been our MO for quite some time.
     • Angr brings up concerns about subjectivity and how CFI is applied. These strike me as reasonable concerns, and also as the underlying issue in many of the CFI disputes I have witnessed over the past few years. An effort to further clarify CFI could be warranted.
  2. Include anything just because someone wants it included.
     • I must admit that this sounds terrible. I understand that WT is intended to be prescriptive and not proscriptive, but part of that descriptivism necessitates some evidence that a given term is actually in use in the language. Including an entry for fleemkaboddinal just because I happen to like the way it rolls off the tongue doesn't strike me as a sound basis for building a dictionary (pun not intended).

     @Purplebackpack89 could you clarify your statement? Are you arguing that any entry should be kept whenever any single editor wants to keep it? Or is your argument intended to be narrower in scope -- do you instead intend to state a position more specifically about entries deemed to be SOP, or some other more limited area? ‑‑ Eiríkr Útlendi │ Tala við mig 19:26, 3 November 2014 (UTC)

     No, @Eirikr, I'm arguing we should keep any entry that at least 50% of RfD participants want kept. Also, the problem with your first camp is "who determines it"? Purplebackpack89 19:32, 3 November 2014 (UTC)

     • When you say "who determines it", what is the it? CFI itself? SOP-ness? Some other aspect? ‑‑ Eiríkr Útlendi │ Tala við mig 20:14, 3 November 2014 (UTC)

     The 50% of participants is a bad idea because not everyone will be around to participate in every RFD. 86.136.110.109 20:16, 3 November 2014 (UTC)

     When I said 50% of participants, I meant 50% of the people who participated in a given RfD... Purplebackpack89 21:14, 3 November 2014 (UTC)

     So did I! (Sorry, not logged in.) Having rules like CFI allows the consensus opinion (as established by policy votes) to be applied without every user having to repeat their opinions on every vote. Equinox ◑ 22:07, 3 November 2014 (UTC)

     So you'd be OK with an article being deleted after four users vote keep and Renard votes "Delete. Fails CFI"? Deleting something even if 70-80% of people in that particular discussion said keep? That seems to be what Renard wants. I think that would be a bad idea. Purplebackpack89 22:14, 3 November 2014 (UTC)

     I would be okay with deletion for things that fail CFI. Renard has nothing to do with that. Equinox ◑ 22:37, 3 November 2014 (UTC)

     Even in the circumstance I outlined? Purplebackpack89 22:46, 3 November 2014 (UTC)

     Renard does not have a supervote, so your outlined circumstance is not really relevant. Only the failing of CFI is relevant. Renard might point out that something fails CFI but he does not decide whether it fails. Equinox ◑ 19:43, 4 November 2014 (UTC)

     I honestly can't see how you can divorce Renard's premise from supervoting. Renard is upset that votes are being closed based on consensus. If you don't close on consensus, the closer is giving weight to some opinions (perhaps his own) than others. The people whose opinions get undue weight hold supervotes. BTW, where is Renard anyway? He started this thread and hasn't been heard from since yesterday. Purplebackpack89 20:04, 4 November 2014 (UTC)

     It shouldn't take much thought to not that there are many possible procedures to help enforce CFI. All votes could be required to present a reasoned argument or consent to someone else's reasoned argument and be invalidated if the argument were shown to be wrong. This would only require some more explicit rules for inclusion and exclusion. People who vote without reasons could be allowed only a fixed number of votes per month (proportional to their contributions?) before being disenfranchised or blocked or whatever. We could have votes to disenfranchise contributors for a time or indefinitely. The franchise to delete could be limited based on some explicit criteria, to those with a degree in linguistics, employment in language teaching or professional lexicography, veteran status, Or those could be deemed to disqualify. We could simply formalize the lemming criterion. I'm sure you could think of others. DCDuring TALK 21:15, 4 November 2014 (UTC)

     I don't really want to think of any others, because I honestly believe that the whole premise isn't really a problem, and certainly not one worth solving. And each of the counter-solutions you propose are solutions I cannot stomach. People should be entitled to participate in as many discussions as they see fit without any penalty whatsoever or the need to present bona fides. That's how a Wiki project works. Your counter-solutions are pretty clearly designed to prevent people from participating, which I find wrong and in violation of the "anyone can edit" ethos of Wiki projects. It's even worse because the proposal seems to be singling out people who Renard/you disagree with. Purplebackpack89 21:26, 4 November 2014 (UTC)

     • You note, “People should be entitled to participate in as many discussions as they see fit without any penalty whatsoever or the need to present bona fides. That's how a Wiki project works.” I must disagree -- that's how some Wiki projects work. In my entire time participating in Wiktionary, that is not how Wiktionary works.

     Anyone is welcome to edit. Anyone is welcome to participate in discussions. But when it comes to the outcome of discussions, bona fides of some sort are very much part of how the community consensus comes together. Bona fides could be something as simple as being a community member (i.e. editor) in good standing. In fact, that's probably the most important bona fide here.

     But suggesting that anyone and everyone can and should have equal weight in the outcome of any discussion is in error, and is decidedly *not* how Wiktionary operates. Moreover, I cannot support any move to make Wiktionary operate that way. ‑‑ Eiríkr Útlendi │ Tala við mig 21:53, 4 November 2014 (UTC)

     @Eirikr, "anyone can edit" is a pillar of all Wiki projects. I dislike the term "good standing" because who the hell determines "good standing". I'm sorry, but the things that have been written here smack of disenfranchisement of Wiktionary editors, including potentially myself and Dan for at least the next few weeks. And the problem is that the people who are pushing this proposal happen to fall on the deletionist side of things. If this was being pushed equally by keepist and deletionist editors, I wouldn't have any problem with it. If it was being pushed primarily by people who didn't participate in RfDs, I wouldn't have a problem with it. This is a proposal started by a deletionist who's upset that articles aren't being deleted, trying to make an end run around the consensus of RfD discussions to get more articles deleted. Purplebackpack89 22:02, 4 November 2014 (UTC)

     I, for one, would be happy with any reasonable explicit inclusionist criteria that reduced the total amount of blather on this page. DCDuring TALK 22:34, 4 November 2014 (UTC)

     @Eirikr, "it" is whether or not it is CFI Purplebackpack89 22:48, 3 November 2014 (UTC)

• I formerly thought that we just needed to make explicit more criteria for inclusion and exclusion by having them voted on so as to reduce the scope for debate. The apparent lack of any desire to adhere to any such criteria as well as the miserable experience of most votes makes me think that this is no solution. No one seems to feel the need to make principled arguments (whether or not based on CFI), let alone develop explicit criteria. Even something as simple as criteria for differentiating and adjective from a noun used attributively was never made a policy. Actually applying to all the cases where it should be applied would probably generate a firestorm of opposition whining. DCDuring TALK 19:45, 3 November 2014 (UTC)
• My point of view as a frequent participant in discussions, and as a frequent closer of discussions, is that RfD is a very heavily trafficked page, and every editor has ample opportunity to participate in every discussion on the page. Therefore, if there are twenty editors participating in discussions on the page, and only five of them weigh in on a given point, then fifteen don't have a strong or certain enough opinion to bother expressing it in the discussion. The obvious cases generally come out with overwhelming support for the obvious position. In other words, if four editors say "keep", and one editor says "delete" on the grounds that the word doesn't (in their view) meet the CFI, the fact that fifteen other editors participating in other CFI discussions above and below didn't think it important to agree with the proposed deletion speaks volumes about whether the presence of the word is seen as a serious breach of our standards. bd2412 T 01:37, 4 November 2014 (UTC)

  I completely disagree. People tend to ignore RFD discussions about words outside of their field of interest. If many editors ignore a particular RFD discussion, it may not be because they have no strong opinion on whether it should be kept, but because they have no interest in that word at all. --WikiTiki89 02:39, 4 November 2014 (UTC)

  • I agree with Wikitiki89. I generally only weigh in on RFD discussions pertaining to Japanese terms. I may put in my 2p on the stray English term, but as far as monitoring the RFD page as a whole, I often skim through for Japanese and move on if nothing presents itself. — This unsigned comment was added by Eirikr (talk • contribs) at 08:09, 4 November 2014 (UTC).
  • I am somewhere in between those two. For some terms I do not care, and for others I simply do not feel competent to judge. But I also have other reasons: one of the things that really discourage me from participating in RFfoos is the sheer volume of these pages: having to wait sometimes half a minute every time I post anything on those pages is just too frustrating. It would help if there were fewer discussions, shorter discussions (both in terms of duration and amount of text) and the discussions were promptly archived and removed. Right now we only have a solution for the last problem. — Keφr 12:32, 4 November 2014 (UTC)

    One thing we can do to reduce page size is to split WT:RFD into two separate pages, one for English entries and one for foreign entries. --WikiTiki89 16:08, 4 November 2014 (UTC)

    Yes! And the same for RfV too, please. I've actually been holding off nominating a few entries 'cuz they're foreign and might make it hard for most people around here to find the relevant, i. e. English terms. -- Liliana • 00:18, 7 November 2014 (UTC)

    Please don't create a separate page for RFD or RFV for non-English terms. Let us keep processes simple. The non-English RFV nominations are a fraction anyway. Let those who post nominations to RFD or RFV in larger volumes also help 1) close and 2) archive the nominations. --Dan Polansky (talk) 09:54, 30 November 2014 (UTC)

  • I formerly cared more. I often disagree with keep decisions, but have come to be resigned to the fact that many contributors find multiword terms easier to wrap their heads around than single-word terms. Adding silly entries is less destructive than definitions omitted because of insufficient breadth of participation from contributors with special domain knowledge, excessive reliance on MW 1913, poor organization of definitions for highly polysemous words, and incorporation of polysyllabic, rare, obsolete, and archaic words in definitions and glosses when better words are available. DCDuring TALK 13:33, 4 November 2014 (UTC)

    In my experience, the words that tend to draw the sharpest divisions of policy interpretation are common, everyday things, like fat as a pig, have an affair, and devalueing. I grant that when it comes to truly esoteric stuff like arfer dda, there are likely fewer editors who feel qualified to offer an opinion. bd2412 T 14:01, 4 November 2014 (UTC)

  • I'd say I participate about as much as Kephir does. I certainly don't weigh in on every RfD; I seldom if ever weigh in on foreign words and there are plenty of English words I take a pass on as well. I don't think the solution is fewer discussions; I think we have the right number of discussions and I would oppose the suggestion that discussions be replaced with speedy deletions. I say the problem is discussions (particularly those trending keep) are dragged on for months and months and months, even if consensus is clear. All RfD discussions should be closed within a month, and if there's no consensus, that means there's not enough support for deleting them. It's also flummoxed me that we don't break up RfDs by month the way we break up this page. Purplebackpack89 14:14, 4 November 2014 (UTC)

Can someone please add "via" parameters to Template:quote-news as is used at en.wikipedia for w:Template:Cite news ?

This way, we can specify what database archive may be used to verify the material, for example: NewsBank, LexisNexis, Westlaw, InfoTrac, etc.

Thank you,

-- Cirt (talk) 20:17, 3 November 2014 (UTC)

Aren't some of those sources behind paywalls?

You can include the url now. DCDuring TALK 22:30, 4 November 2014 (UTC)

Previous discussions:

• Wiktionary:Beer parlour/2013/January#The RFD and RFV pages are getting too large
• Wiktionary:Beer parlour/2013/October#Converting WT:RFV, WT:RFD, and WT:RFDO to monthly subpages

User:BD2412 has expressed a wish for splitting WT:RFD into monthly subpages. It seems like a good idea, but probably requires change to {{rfd}}, {{rfd-sense}}, and {{rfd-redundant}} . I don't think it will need a vote, but it certainly needs an opportunity for discussion to make sure. DCDuring TALK 18:09, 4 November 2014 (UTC)

I wouldn't object. When we've done this to other pages, it seems that any newly created month page gets automatically added to my watchlist, if I am already watching the parent page. I would want that to happen here too. Equinox ◑ 19:45, 4 November 2014 (UTC)

No such thing. — Keφr 19:55, 4 November 2014 (UTC)

While I might dislike it, the current single-page set-up has one advantage — it makes sure no discussion slips through unresolved (even though it sometimes takes ridiculously long to close some of them). Which is what often happens to Tea Room discussions now. Anyone remembers why succumb was tagged with {{rft}} and whether the issue was resolved? I do not. Sure, I can check backlinks in the appropriate namespace and find out, but it is quite tedious. — Keφr 19:53, 4 November 2014 (UTC)

@Kephir How does the use of subpages lead to items falling between the cracks? Is that a big contributor beyond the other contributors to requests being neglected?

Requests of all kinds fall between the cracks for several reasons. We have items that are tagged, but not added to the appropriate page for rfc, rfd, rft, and rfv. The absence of any time limits or dramatic consequences of rft and rfc mean that such items are not closed, let alone archived (at least for rft) to the appropriate page. Tags are not removed from many of the above requests and also rfi, rfp, and rfe. DCDuring TALK 20:59, 4 November 2014 (UTC)

Because the main pages of discussion rooms using the monthly subpages system display only discussions from last three months, and there is no good way to view all unresolved discussions in order to assess and properly close them. RFI, RFP and RFE are irrelevant — no debate is usually started for those, because none is needed; those requests are considered resolved simply when someone fulfils them. — Keφr 21:36, 4 November 2014 (UTC)

Can the discussion room main page structure be changed to include more time periods/subpages? How about three months per page? And more for the oldest? What about templates to categorize items as "open", "closed", "look"? It is possible to have tables that present the newest or oldest X members of such categories. DCDuring TALK 22:20, 4 November 2014 (UTC)

• Support: Shoulda been done ages ago. Purplebackpack89 21:39, 4 November 2014 (UTC)
• Support, but, as always, the devil is in the details. --WikiTiki89 11:38, 5 November 2014 (UTC)

• Oppose, would just lead to nominations getting forgotten. DTLHS (talk) 19:39, 5 November 2014 (UTC)
• Oppose. The risk of rubbish being kept because a discussion disappears from the page before it is closed is not worth it IMO. — Ungoliant ^(falai) 01:07, 6 November 2014 (UTC)
• Support, of course. We can always have a single transcluded page where editors can go if they feel like having a long wait while the page loads, and keep the discussions on shorter pages for those who prefer faster loading. Better yet, we could go to the system used by Wikipedia and Wikiquote, where each discussion is a subpage transcluded into the page for the month. bd2412 T 14:13, 7 November 2014 (UTC)
• We've been doing this on the French Wiktionary for years, but it's different because those pages don't get archived to talk pages, and ours do. Probably oppose for that reason. Renard Migrant (talk) 16:25, 11 November 2014 (UTC)
• I oppose splitting RFD to monthly pages. RFD can get shorter if editors who make most nominations also help close old nominations. Closing old nominations includes providing a boldfaced disposition, deleting the nominated page if appropriate, and striking out the heading. Splitting the page to months will not make it any less stale, and will remove the long-page-displeasure incentive to start closing old discussions or start posting fewer new ones. --Dan Polansky (talk) 23:07, 28 November 2014 (UTC)

The entry on Wikipedia is titled "Spam (food)," not "SPAM (food)," so which one should be the main (as opposed to the alternative form of) listing? Right now, it is "SPAM." WikiWinters (talk) 20:48, 4 November 2014 (UTC)

Hormel Foods calls it The SPAM® family of products, SPAM® brand, SPAM Classic, Great American SPAM® Championship, SPAM® Musubi, SPAM® Tocino, The SPAM Museum, and #SPAMCAN. Apparently the all-caps style is part of the logo. —Stephen ^(Talk) 23:04, 5 November 2014 (UTC)

It looks like the company is trying to protect their brand name from w:Trademark erosion by using a spelling that's less likely to show up in non-brand usage. If you think about it, we shouldn't be interested in how the company decides the brand name should be spelled, but in how the term is spelled when used for non-brand senses. I think the main entry should be at spam (as it is now), and I have my doubts as to whether we should even have an entry for SPAM. Chuck Entz (talk) 02:32, 6 November 2014 (UTC)

• As editors of a descriptive dictionary, should we not include an entry for SPAM if the term is indeed used with that capitalization?  :) ‑‑ Eiríkr Útlendi │ Tala við mig 06:26, 6 November 2014 (UTC)

@Chuck Entz The main entry currently is SPAM, not spam. Do you suggest changing this? WikiWinters (talk) 23:56, 6 November 2014 (UTC)

For future reference WT:TR is the discussion room for individual entries where there are no policy issues. Google Ngram Viewer gives a slight edge to spam even before the Internet meaning appears so I'd go with that. Renard Migrant (talk) 16:34, 7 November 2014 (UTC)

 Done (Got it. Also, I corrected the entries.) WikiWinters (talk) 20:02, 7 November 2014 (UTC)

I recently created a pair of very simple templates {{col-top}} and {{col-bottom}} that create auto-balancing columns of text (for an example, see WT:Wanted entries). If we integrate these templates into pairs like {{trans-top}}/{{trans-bottom}}, {{rel-top}}/{{rel-bottom}}, etc. we will no longer need to manually balance their columns with {{trans-mid}}, {{rel-mid}}, etc. Assuming we test this for browser compatibility, is this something we would want to do? --WikiTiki89 17:11, 5 November 2014 (UTC)

• It seems like a worthwhile goal. Can you tell anything about resource consumption before testing? Assuming it is not a resource hog and passes on all major browsers, it would seem that it could be initially deployed by having the existing templates call it. Is that right? DCDuring TALK 18:15, 5 November 2014 (UTC)

  It's CSS-based, so it's all on the client side, so no effect on server load. Even on the client side, I would think all the browser needs to do is a simple division of the number of lines by the number of columns, which should be completely insignificant. The only potential issue (as with all CSS features) is browser compliance. As far as deploying it, yes, we just need to have the existing templates call it and have the mid-templates do nothing. --WikiTiki89 19:22, 5 November 2014 (UTC)

  Which browsers will have trouble with it? DTLHS (talk) 19:27, 5 November 2014 (UTC)

  I'm not expecting that any will, but we still have to test it. Maybe some outdated browsers or versions of browsers will not support it. Just to be clear, it work perfectly in the latest Chrome, Firefox, and IE. --WikiTiki89 19:29, 5 November 2014 (UTC)

  Are there sites for testing using older browser versions? Does MW have copies or a testing suite or insight? DCDuring TALK 20:16, 5 November 2014 (UTC)

  CSS columns are not supported by Internet Explorer 9 and lower and Opera 11 and lower. --Yair rand (talk) 22:17, 5 November 2014 (UTC)

  Sigh. Are higher versions part of automatic updates for IE 9 and Opera 11? What share of users have the old versions? I suppose it's too much to expect that it fails gracefully. DCDuring TALK 23:07, 5 November 2014 (UTC)

  Re browser share: The most recent Wikimedia Traffic Analysis Report shows the following usage share: IE9 - 2.25%, IE8 - 2.20%, IE7 - 0.89%, IE6 - 1.53%, IE5.5 - 0.22%, Opera<11 - 0.3%. Browsers that don't support CSS columns will display the content all in one column. --Yair rand (talk) 00:56, 6 November 2014 (UTC)

  Thanks. That doesn't seem fatal. Also, isn't it possible to change template/CSS/etc behavior based on the browser? That would at least dramatically diminish the importance of balancing that tables as 90% of users would see the table as balanced even if the various "mid" templates were misplaced. Isn't such balancing done by a bot? (Autoformat did it.) DCDuring TALK 01:07, 6 November 2014 (UTC)

• (After e/c) This sounds brilliant. It always puzzled me that we had no auto-balancing, given how simple the math is. ‑‑ Eiríkr Útlendi │ Tala við mig 20:17, 5 November 2014 (UTC)
• I would recommend to use a column width as parameter (with a set default, like 20em) instead of a number of columns, so that the number of columns would adapt to the screen width. Dakdada (talk) 10:12, 6 November 2014 (UTC)

  @Darkdadaah Would that work with more browsers? DCDuring TALK 13:52, 6 November 2014 (UTC)

  No more, no less: same support (see here and here). Dakdada (talk) 15:00, 6 November 2014 (UTC)

  But that would be a drastic layout change for our translation tables. I'm not against it, but we would probably need to vote on it. --WikiTiki89 15:50, 6 November 2014 (UTC)

• One thing that occurs to me. In some cases, JA editors (and probably others) have been using the {{mid}} family of templates in semantic ways -- in my case, specifically by splitting up derived term tables to have derived terms starting with the headword on one side, and derived terms ending with the headword on the other side. (This is common and useful for Japanese entries.)

Is this proposal intended to entirely scrap the {{mid}} family of templates? Or is this proposal more limited in scope, and targets only some of the {{mid}} templates? ‑‑ Eiríkr Útlendi │ Tala við mig 18:28, 6 November 2014 (UTC)

For that kind of situation I would suggest using something other than {{mid}} to delineate the split. That way it's clear that the split is not just there for balancing purposes. —CodeCat 18:45, 6 November 2014 (UTC)

What would you suggest? A sample usage is here on the 刀 entry. I added column headers here to try to clarify the table organization. In either layout, though, I have no idea what to use to split the columns other than the various {{mid}} templates. ‑‑ Eiríkr Útlendi │ Tala við mig 19:02, 6 November 2014 (UTC)

I don't know. We probably don't have templates specifically for this kind of thing, but it would be a good idea. I am a proponent of using templates in a way that signifies intent/meaning, rather than just using whatever template "looks right". —CodeCat 19:08, 6 November 2014 (UTC)

One thing to think about is whether that is actually better than just having two separate tables as in this edit. --WikiTiki89 20:06, 6 November 2014 (UTC)

• Having just the one collapsible div seems like less clutter and better usability. Perhaps some other template tweaking would do the trick? We could create something like {{der-col-top}} etc, or even just {{der-head|header text}}, which would fit between {{der-top}} and {{der-bottom}}. ‑‑ Eiríkr Útlendi │ Tala við mig 20:12, 6 November 2014 (UTC)

  But having two separate collapsible tables makes it easier for readers to expand only what they want to see. It's not really a lot of clutter to have two tables. --WikiTiki89 20:27, 6 November 2014 (UTC)

So what's the verdict? Can we do this? --WikiTiki89 20:53, 14 November 2014 (UTC)

I'd think it needed a vote, because it is a bit rough on those with older browsers. DCDuring TALK 04:02, 15 November 2014 (UTC)

In what way is it rough? Manual column breaks are rough on all browsers, for all readers with very narrow or wide viewports ( which is a large proportion these days). —Michael Z. 2014-11-28 15:50 z

The use of the whole etymological chain of a word is necessary? For example see the entry for the French word "démocratie", which derives from the Latin "democratia". The origin of the latter is Greek, but should this be presented in the etymology of the French word or only for the Latin one? And why is this exhaustive etymological analysis through the Proto-Indo-European roots presented, which applies only to the Greek word? In the categorization, the French world is presented as deriving from all these languages, Latin, Greek and Proto-Indo-European, while it's only a loanword from Latin. Actually, the Latin comes from the Greek word, and the Greek comes from the PIE. In this way (which isn't used for the most part of the words in the wiktionary), all loanwords come from a very first proto-something language, but the point is to present the language from which a word derived, e.g. the French word derived from Latin and that's all. If anybody wants to see the origin of the Latin word should go to its entry and so on.--Ymaea (talk) 16:48, 6 November 2014 (UTC)

Does it really make sense to only go back one step? If you put borrowed from Latin, then you click on the Latin it says borrowed from Ancient Greek. You click on the Ancient Greek it says from PIE. That's a lot of clicking. If you get a chain of seven languages in an etymology you're going to have to click 7 times to get all the etyma. Renard Migrant (talk) 17:11, 6 November 2014 (UTC)

Another issue is that sometimes the intermediate etyma don’t exist. From example, there are 1809 words listed at Category:Portuguese terms derived from Old Portuguese but we only have 460 Old Portuguese entries. And sometimes the etymon immediately preceding the word is not the most important; people who want to know the origin of French words are more likely to want to know the Latin or even Old French etymon than the Middle French one. — Ungoliant ^(falai) 17:21, 6 November 2014 (UTC)

Without a proper etymology backend this is all just pissing in the wind. DTLHS (talk) 18:17, 6 November 2014 (UTC)

The problem here is mainly the automatic categorization according to the etymologies used. The French word "démocratie" is listed in three categories: a) "French terms derived from PIE", b) "French terms derived from Ancient Greek" c)"French terms derived from Medieval Latin". My objections:

1. What is this word? It cannot be PIE, Greek and Latin simultaneously.
2. Especially the first category (PIE) is totally weird, as it indicates a straight connection between the French and the PIE words. But originally only the Greek word was formed from PIE.
3. The mess becomes more chaotic when we want to describe the origin of the French "démocratie". We should say that it has a Greek origin, it's a Greek influence, which was passed in French through Latin. This "through" doesn't indicate the etymology, but the route of the word. So, categories which indicate that this word derives from PIE and from Greek and from Latin, are obviously wrong.

To sum up, imagine a category "French terms derived from Ancient Greek through Medieval Latin". It's much more accurate and totally different from this coexistence of the three categories above.--Ymaea (talk) 18:53, 6 November 2014 (UTC)

Being in three categories does not imply that the etymon existed in three different languages. French démocratie is derived from both Medieval Latin and Ancient Greek, though I would say it is not derived from PIE since the compound was coined in Ancient Greek and didn't exist yet in PIE. Even the Greek word is not derived from PIE; it was coined within Greek from two words that were themselves independently derived from PIE. Categories like "French terms derived from Ancient Greek through Medieval Latin" sound like a good idea in principle, but in practice I think they would quickly become unmanageable. —Aɴɢʀ (talk) 21:31, 6 November 2014 (UTC)

"It cannot be PIE, Greek and Latin simultaneously." No and we're not claiming it is. It's a bit like saying a word can't be a verb and a noun simultaneously. Not simultaneously no, but separately, yes! Renard Migrant (talk) 22:55, 6 November 2014 (UTC)

"So, categories which indicate that this word derives from PIE and from Greek and from Latin, are obviously wrong."

"So, genealogies which indicate that I am descended from my father, my great-grandfather, and my grandfather, are obviously wrong."

--Catsidhe ^{(verba, facta)} 22:59, 6 November 2014 (UTC)

• I'm not really seeing the need for a determination on this. a) I'm generally OK with long etymologies, and b) how long an etymology should be should be dictated by common sense. Purplebackpack89 22:17, 6 November 2014 (UTC)

Regarding this genealogy case, yes you are descended from these three persons, but it would be weird to put you in the category of each one without giving this vertical kinship ties. So, when the Latin and the French word are both categorized as deriving from Greek, one could assume that we talk about two separate formations with a common ancestor, the Greek one. When a dictionary says "100 French words derive from Latin and 100 more from Greek", this word is double-counted? I don't think so. But in wiktionary yes, it's double-counted, you can see it in both categories. My point is very clear when we compare the present situation with a category like that I proposed, "French terms derived from Ancient Greek through Medieval Latin". On the other hand even this solution would sound weird in other cases and I have some in my mind. Indeed it would be very complicated and possibly we couldn't handle a situation like this. But, I just wanted to point out that there is a strong lack of clarity with the categories in the way they are constructed. Thank you all!--Ymaea (talk) 01:47, 7 November 2014 (UTC)

"... derived from ..." ≠ "... directly derived from...". I certainly belong in a category of "people descended from {my grandfather}", and in "people descended from {my great-grandfather}", but not in "children of {my grandfather}". Similarly, démocratie is derived from δημοκρατία, but is not directly derived from it. --Catsidhe ^{(verba, facta)} 02:08, 7 November 2014 (UTC)

Category:French terms derived from Ancient Greek through Medieval Latin would fail the utility test, i.e. not useful to anyone. It has no advantages whatsoever; it's not more useful and it's not more accurate. And there isn't a lack of clarity, quite the opposite. We include all relevant truthful etymological categories. So if something's derived from Latin, we include that. If something's derived from Ancient Greek, we include that. We don't pick one or the other. With something like mock you end up with Category:English terms derived from Proto-Indo-European via Proto-Germanic, Old Saxon, Middle Low German, Middle Dutch, Middle French and Middle English. If that's your idea of clarity, I'll take obscurity thanks! Renard Migrant (talk) 16:28, 7 November 2014 (UTC)

Yes, with Wanderwörter the chains can get quite complicated. It wouldn't be difficult to list e.g. a dozen of words in Inari Sami whose etymology is roughly "from Finnish < from Swedish < from Low German < from French < from Latin < from Greek < from Persian". To keep this in hand, the useful stages to indicate would seem to be

1. Direct loan origin.
2. Ultimate loan origin.

Both indicate an action: the loaning by French (or by Inari Sami, etc), and the word's derivation in Greek (or Persian, etc). Anything else is not that necessary.

Note that by "derivation" I do not only mean the morphological composition, though. Sometimes a specific semantic or phonological mutation may have occurred in a specific language (say, between Greek and Persian), and this is also relevant info for the etymology of a word.

On the other hand, indicating the reconstructed proto-roots from which a word was derived in some other language entirely is largely superfluous IMO; while for inherited words, though, these clearly ought to be mentioned. Pretty much everything in English comes in some way from PIE (sometimes thru quite a few detours) — the purpose of a category like "English terms derived from PIE" would be mainly for indicating what exactly has been inherited from that far back.

I suppose this gets more difficult with French vs. Latin, or Hindi vs. Sanskrit, where one might want to distinguish inherited vs. learned vocab. But maybe things like "French terms derived from Medieval Latin" versus "French terms derived from Vulgar Latin" suffice for the job?

Worth mentioning here as well BTW: we currently have a somewhat inconsistent system where e.g. some Germanic words' etymology is discussed right under the modern words (as is proper), while others' is discussed under the corresponding Old Norse or Old English or Old High German words. --Tropylium (talk) 01:08, 9 November 2014 (UTC)

User:Ready Steady Yeti found out the hard way that we don't include this in our in our data modules as a language. We do have Guernésiais and Jèrriais, which are lects spoke nearby, and likewise often considered to be dialects of Norman. According to w:Sercquiais, the island was settled in the 16th century by speakers of Jèrriais, and has archaic features that have been lost in that language, along with considerable Guernésiais influence. Should we create a language code for this, or treat it as a dialect of Jèrriais/Norman? Chuck Entz (talk) 00:12, 9 November 2014 (UTC)

Why do we have separate codes for Guernésiais and Jèrriais to begin with? I'd say all three should be dialects of Norman. —Aɴɢʀ (talk) 13:51, 9 November 2014 (UTC)

I, too, am not convinced Jèrriais and Guernésiais are languages distinct from Norman. — Ungoliant ^(falai) 15:42, 9 November 2014 (UTC)

Many English multi-syllable words that are used in different functions, especially as a noun and a verb, have the stress on different syllable according to which part of speech they occour as. Examples include increase, reject, excerpt, defect. The meanings and etymologies of such a word are usually related and the pronunciations are all grouped under the Pronunciation header. Many pages use various templates, some of which are clearly wrong, to indicate the part of speech a pronunciation pertains to. WT:ELE doesn't prescribe any template, instead hinting that parts of speech should be separated under multiple Pronunciation headers. Sound files often lack part of speech information. They may be indented under the relevant IPA description, but that requires a knowledgeable linguist, and to my knowledge isn't suggested on any policy page. The template {{qualifier}} seems to be the closest to what is intended. Is there a preferred way? Kumiponi (talk) 18:55, 11 November 2014 (UTC)

I'd use {{sense}} myself, I don't know about other editors. —Aɴɢʀ (talk) 19:12, 11 November 2014 (UTC)

That template's documentation doesn't allow such usage. Kumiponi (talk) 19:29, 11 November 2014 (UTC)

We've discussed this before (does anyone remember when/where?). Some people say that if a word has different pronunciations, then the two pronunciations actually have different etymologies. --WikiTiki89 22:07, 11 November 2014 (UTC)

At the very least, they're distinct words, so maybe something like this? Etymology at the top, in level 3, followed by Pronunciation 1 at level 4, then the words with that pronunciation, then Pronunciation 2 at level 4, etc. Of course this should only be done if we're really sure the words have the exact same etymology and came into existence at the same time from the same origin. —CodeCat 23:12, 11 November 2014 (UTC)

But how do you explain the different pronunciations? It should be part of the etymology. --WikiTiki89 23:20, 11 November 2014 (UTC)

You could say that the etymologies are different, but that sets up an inconsistency with the way we divide terms without pronunciation differences: we currently show the verb perfect as derived from the adjective perfect, but we don't show the verb mouse as derived from the noun, nor do we show the computer mouse as derived from the rodent mouse. Chuck Entz (talk) 00:03, 12 November 2014 (UTC)

Could someone please show me where the renaming of Module:template utilities to Module:ugly hacks was discussed at WT:RFM and where the deletion of Module:template utilities was discussed at WT:RFDO? As far as I can tell, the first was only mentioned in passing while discussing the fate of other templates, and the second wasn't discussed at all.

I can understand why User:Kephir might want to discourage people from using the module, but I can't understand why he didn't discuss it in the appropriate places first. At the very least it would have given people a chance to point out any potential problems, and to get people thinking about alternatives (this reminds me of a line in w:Dr. Strangelove about keeping deterrents secret, but I can't remember it offhand).

I'm sure he was very diligent in orphaning template utilities from everything that links to it. He wasn't so diligent, however, in checking Category:Templates that must be substituted. This is analogous to demolishing a bridge without closing the roads on either end. I've updated my own templates to use the other module, but there may be others. Chuck Entz (talk) 01:09, 12 November 2014 (UTC)

Yup. DCDuring TALK 02:33, 12 November 2014 (UTC)

How incredibly self-serving (or what a sign of youth?) it is to be able to say "I won't bother writing documentation for this module because you shouldn't use it: you should use Lua instead (and to hell with you if you don't and I won't answer your questions on my talk page if I don't feel like it). DCDuring TALK 02:41, 12 November 2014 (UTC)

I'm looking to be granted rights to use AWB on this project. I noticed that Category:English simple past forms was supposed to be empty and I was going to correct the pages to point to Category:English verb simple past forms as prescribed. If granting AWB rights is not advisable because I'm an infrequent editor on this project, I'd ask that someone else please perform this task. Thanks, Ost316 (talk) 18:26, 13 November 2014 (UTC)

On it. bd2412 T 19:51, 13 November 2014 (UTC)

Done. Cheers! bd2412 T 20:01, 13 November 2014 (UTC)

Not that I object but, was this perhaps done unilaterally by CodeCat with no prior discussion? I don't think verb is really needed as other parts of speech don't have simple past forms. We don't have Category:English verb past participles for the same reason, 'verb' is implied by 'past participle'. Renard Migrant (talk) 13:30, 15 November 2014 (UTC)

That may be so, but we had two categories with duplicated intent, one containing about 75 entries and the other containing about 20,000. I have no problem recategorizing the 20,000, but it is definitely an easier task to recat the 75 with AWB. If we go the other way, it will be a bot task. bd2412 T 17:43, 15 November 2014 (UTC)

• Let us fill Category:English simple past forms, and discontinue Category:English verb simple past forms. --Dan Polansky (talk) 18:37, 5 December 2014 (UTC)
  • If that is what consensus favors, I am up to the task (or a bot could do it in a day). bd2412 T 15:38, 6 December 2014 (UTC)
    • I don't agree with it. —CodeCat 17:51, 6 December 2014 (UTC)
      • @CodeCat You could take the trouble to give reasons, instead of forcing us to beg you for them. Your opinion is one that I would recommend be ignored if you fail to participate usefully in discussions. DCDuring TALK 19:32, 6 December 2014 (UTC)
      • Well ok, you can ignore me and Dan. I'm just giving a counterweight to Dan because BD2412 suggested that might be the consensus. —CodeCat 19:33, 6 December 2014 (UTC)
        • I did not intend to suggest that there was a consensus for anything. I am volunteering to carry out the task if there is a consensus. bd2412 T 23:24, 6 December 2014 (UTC)
        • My main argument is Renard's: "I don't think verb is really needed as other parts of speech don't have simple past forms." My secondary argument is that status quo ante should prevail unless a performer of mass undiscussed changes can explain their reasoning and demonstrate consensus for their change. --Dan Polansky (talk) 12:23, 7 December 2014 (UTC)
• I agree with Renard about the apparent redundancy of "verb" in the category name. Is there any language where a word class other than 'verb' has a past tense? DCDuring TALK 00:45, 7 December 2014 (UTC)

There are many languages where adjectives act like verbs, but one could quibble whether they're verbs or adjectives in such cases. There are similar issues with participles. There are also a number of agglutinative languages which have verb affixes on nouns. Given that the latter group are mostly not Indo-European, and tenses are rare outside of the Indo-European languages, I'm not sure whether there are any that have tense as opposed to aspect.

At any rate, I suspect that the main reason for "verb past tense forms" would be to maintain a uniform naming scheme between parts of speech and between languages. Given that many assumptions we make about what kinds of things are limited to which part of speech are wrong somewhere in the world (Modern Hebrew verbs, for instance, can have gender as well as person and number), it would make things easier in general to be explicit about such assumptions. I'm still trying to figure out where I come down on this particular case, though. Chuck Entz (talk) 01:32, 7 December 2014 (UTC)

WT:RFM I guess. Renard Migrant (talk) 13:20, 7 December 2014 (UTC)

I came across a recent edit which replaced a use of the non-existent Template:Bibleref with a direct wikilink to the relevant Biblical book, which is certainly of no use. There used to be on WP a template Bibleverse, which used "mediatools", when that went belly up, it failed for a while, and now it has been replaced with a same named template that works again. It is absolutely magnificent: the template creates an external link to any of a dozen off-site Bibles.

I assume such a template existed, and was deleted when mediatools disappeared. Either way, a Template:Bibleref that works like the WP template would be quite useful. That's certainly much better than "fixing" the Templates to something hard-coded. Choor monster (talk) 15:36, 14 November 2014 (UTC)

What does the WP template do? Does it link to one or multiple translations? Does it 'find' the citation? DCDuring TALK 16:15, 14 November 2014 (UTC)

On a partially-related issue, I find quotes that just say 'Bible' and not which edition a bit irritating. Modern English Bibles span at least 500 years, so which edition really does it matter. Renard Migrant (talk) 13:24, 15 November 2014 (UTC)

• Good grief, it worked on Friday—linking to the asked-for particular Bible translation—and now it doesn't work at all, trying to link to tools.wmflabs.org and coming up empty. Well, it half-way works, creating a properly formatted Biblical reference. As an example, in Shuah, there are numerous instances of the template, with the parameter HE added, that originally and last Friday when I checked, provided a link to this stable line-by-line English/Hebrew Bible. This was particularly useful for this article, since there are four distinct Hebrew spellings that KJV transliterated into "Shuah". In contrast, the template did not provide links for any on-line LXX, so the relevant links had to be hand-coded, which is, of course, a nuisance. And in theory, this is less robust, but in practice, it has turned out to be more robust. Choor monster (talk) 16:39, 17 November 2014 (UTC)

Some Latin words have one or more vowels with variable length (for example, agrimensor/agrīmensor, Galilaea/Galīlaea, Lūcipor/Lūcipōr, Moȳsēs/Mōȳsēs, patruus/pātruus, Pharisaeus/Pharīsaeus, -por/-pōr, Publipor/Pūblipor/Pūblīpōr, redux/rēdux, succisīvus/succīsīvus, etc.). Allowing only macra, and no breves, accurate presentation requires something like this. To me, that seems like a crazy amount of duplication to account for variation in the length of one vowel; far better, in my opinion, would be presentation like this. Right now, however, such presentation is problematic, because the links generated point to page titles with ĭ in them, but this is easily fixed by automatically stripping macra–breves from Latin links in the same way that standalone macra are currently stripped from Latin links; to achieve this, the following change would need to be made to Module:languages/data2:

This sort of double-diacriticking is standard practice, and can be seen in Lewis & Short's Latin Dictionary and Félix Gaffiot’s Dictionnaire Illustré Latin-Français. L&S and Gaffiot both use standalone breves to mark short vowels anyway, but the Oxford Latin Dictionary, which only uses macra and never breves to mark fixed-length vowels, also uses macron–breve double-diacriticking to mark vowels with variable length, as in the case of “sibī̆¹, sibe” (p. 1,753/1 in the 1st ed.), its headword for sibi, the dative of the reflexive pronoun sē.

Does allowing the use of breves on Latin words in these exceptional cases seem like a good idea to everyone? — I.S.M.E.T.A. 18:15, 14 November 2014 (UTC)

Regardless of whether we should use them, the module should definitely strip them. I will make the change (and your particular suggested edit will not work). --WikiTiki89 18:21, 14 November 2014 (UTC)

@Wikitiki89: Thanks for that. And I'm sorry that I was wrong with my suggested edit. Could you explain what the u(0x0304), u(0x0306), u(0x0308) in the text you added does, please? — I.S.M.E.T.A. 21:05, 14 November 2014 (UTC)

@I'm so meta even this acronym First of all, the reason your suggestion would not have worked is that the combining breve is treated as a separate character, thus "Pharī̆saeus" would have become "Phariasaeus" rather than the intended "Pharisaeus". u(0x0304), u(0x0306), and u(0x0308) are respectively the combining macron, combining breve, and the combining diaereses, which are replaced by nothing. The u(...) function converts a number representing a Unicode codepoint into the character itself (if you look at the top of the module, you will notice that u is just a shortcut for mw.ustring.char), the 0x indicates that the following number is in hexadecimal notation, and the number is the Unicode codepoint of each respective character. --WikiTiki89 21:27, 14 November 2014 (UTC)

@Wikitiki89: Hugely illuminating. Thank you very much. :-)  — I.S.M.E.T.A. 21:55, 14 November 2014 (UTC)

Do we have a written template usage policy? I thought FL-specific templates were allowed whenever there was a need, and the use of generic templates were encouraged when it was possible, especially when no special FL functionality was needed. But the opposite is happening in two cases and it's confusing.

1. {{hu-proper noun}} is linked to {{head|hu|proper noun}}. It does not have any extra functionality. I was planning to manually move every entry that is using {{hu-proper noun}} to {{head|hu|proper noun}}, and eventually delete the template. So I try to change {{hu-proper noun}} to {{head|hu|proper noun}} whenever I see it, but there are other non-Hungarian editors who do the exact opposite: they change {{head|hu|proper noun}} back to {{hu-proper noun}}.
2. {{hu-suffix}} was developed to provide functionality specific to Hungarian entries. The template was changed to point to {{suffix}} which does not provide the same functionality. Requests for adding back the unique original functionality are treated with resistance.

What is the policy that should be followed? --Panda10 (talk) 17:42, 15 November 2014 (UTC)

Now that many templates simply call on {{head}}, we should only use the ones that have additional functions or have a realistic prospect to have added functions in the future. For example {{fr-noun}} has a few extra functions, such as the automatic plural and the gender. {{fr-adv}} has no added functions (when compared to {{head|fr|adverb}}) and no realistic prospect of them, which is why I've nominated it for deletion. Renard Migrant (talk) 18:30, 15 November 2014 (UTC)

Previous discussions: Wiktionary:Beer parlour/2014/January#Parameter to use for alternative display of links, Thread:User talk:CodeCat/Why the rush?

Now that we have Lua to automatically strip diacritics, we don't need the third parameter of {{l}}, {{m}} and similar templates nearly as often as before. Some people have brought this up before and suggested that we could rename this parameter to alt= and "shift" the gloss parameter (the fourth) downwards to take its place. But it's far from clear whether more entries use the fourth parameter than use the third. So before we make this change, I would like to add some tracking to these templates so that we can more easily judge which of the two parameters gets used more, and make a decision based on that. Is this ok? —CodeCat 20:56, 16 November 2014 (UTC)

I still think we should add |text= instead. — Keφr 21:51, 16 November 2014 (UTC)

…by which I meant that instead of having {{m|en|A|alt=B}} we would write {{m|]}}. And instead of {{m|en||X}}, {{m|en|text=X}} (I preferred {{m|en|=X}} initially, though). — Keφr 22:14, 16 November 2014 (UTC)

Yes it's a good idea, and I prefer |alt= because it's more established here. Renard Migrant (talk) 21:54, 16 November 2014 (UTC)

• I support doing this, and I support naming the parameter |alt=. —Aɴɢʀ (talk) 22:06, 16 November 2014 (UTC)
  • I actually wanted to do this before deciding on whether to rename it. To see if it's needed. Keep in mind that there are many instances where {{m}} is used with only the alt display and no linked term. These cases turn up often in etymologies where you might want to show an intermediate reconstructed form without linking to it. Renaming the parameter would make such cases longer to type. —CodeCat 22:16, 16 November 2014 (UTC)

    Maybe we could create two more templates, such as {{l*|en|foo}} and {{m*|en|foo}} that would not automatically link the parameters (we don't have to actually go with my scheme-influenced asterisk usage)? --WikiTiki89 00:56, 17 November 2014 (UTC)

    Your suggested {{l*}} seems almost the same as {{lang}}. —CodeCat 01:13, 17 November 2014 (UTC)

    Except that {{lang}} doesn't support transliterations or language linking. --WikiTiki89 02:10, 17 November 2014 (UTC)

    It should probably support the latter. And maybe the former too. —CodeCat 02:29, 17 November 2014 (UTC)

    But regardless, we'd need a mention version of it as well. --WikiTiki89 03:31, 17 November 2014 (UTC)

    {{l*}} makes me rather think of reconstructed/unattested terms than Scheme. — Keφr 12:18, 18 November 2014 (UTC)

    Then maybe you haven't used Scheme enough. The asterisk is used similarly to the way the prime symbol is used in mathematics. Compare functions such as let*, list*/cons*, and map*, and see this question. --WikiTiki89 16:55, 18 November 2014 (UTC)

    Quite probably so. Though why not {{l'}} if you just meant to use a prime? Or hell, even {{l′}}? (That is U+2032 PRIME.) — Keφr 18:05, 18 November 2014 (UTC)

    The apostrophe is a special character in LISP-derived languages; the asterisk is not. The Unicode prime symbol would only work in some implementations and would be inconvenient to input anyway. As for why I didn't use an apostrophe here, I didn't actually connect the Scheme asterisk with the mathematical prime symbol until I was righting that response. --WikiTiki89 20:14, 18 November 2014 (UTC)

I don’t think the tracking is necessary. Even if it shows that there are more uses of {{m}} with an alternative display than with a gloss (which would not correspond to my personal experience), all that proves is that we need to start adding more glosses. But if that’s what it takes for people to support the parameter change, I see no harm in it. — Ungoliant ^(falai) 05:41, 17 November 2014 (UTC)

Let's start applying our own rules! Otherwise I will be nominating Wiktionary:Criteria for inclusion for deletion as de facto it isn't being used anyway. Let's go one way or the other; apply our own rules or get rid of them all together. Renard Migrant (talk) 18:49, 17 November 2014 (UTC)

Oh, you know I'm voting oppose! Purplebackpack89 20:32, 17 November 2014 (UTC)

I don't know how useful this vote is. It just means we'd be squabbling over "interpretations" of CFI. It has to come down to common sense in the end. To paraphrase Renard under another name, if the lunatics take over the asylum (single-issue propagandists, fringe kooks, etc.) we are not going to defeat them with rule-mongering. Equinox ◑ 22:32, 17 November 2014 (UTC)

Oh, it's not useful at all. There is an enormous crisis of implementation if this vote passes. Which it shouldn't, because entries should be kept or deleted because of consensus. I'm also worried about the motivations of this vote: it and the discussion above grew out of Renard's complaint about not enough articles getting deleted. I'd feel much more comfortable if this was coming from a neutral third-party rather than an ardent deletionist. Purplebackpack89 22:52, 17 November 2014 (UTC)

CFI is consensus in itself. It consists of the rules that all of Wiktionary has agreed to work with. If the rules don't suffice that doesn't mean we should just override them when we feel it's necessary. It means we need better rules. I'm also rather surprised that you, as a proponent of applying Wikipedia practices here, do not agree with the suggestion that we apply the common Wikipedia practice of using policies as rationales. Personally I think this is a problem here and if policies were enforced more strictly then they'd actually mean something. In particular I would love to see Wikipedia-style deletion messages used here, in which the name and a link for the relevant policy stating rationale for deletion is always included. —CodeCat 23:09, 17 November 2014 (UTC)

Since you brought up Wikipedia, my experience is that admins there don't tend to close an AfD against consensus, even if consensus is in one direction and policy is another. The exception to that is AfDs that have a lot of IPs or new editors, who are usually discounted. Purplebackpack89 23:32, 17 November 2014 (UTC)

That may be true, but I don't know what you're interpreting as "consensus" in this case. I've seen administrators close discussions with option 1 even though the majority of votes was for option 2. The rationale given for this was that the people who wanted option 1 gave better rationales, in particular rationales that had more merit with respect to Wikipedia policy. That consensus depends on the quality of arguments over numerical superiority is a Wikipedia policy in itself, as can be read at w:WP:Consensus. And I would definitely favour a similar approach on Wiktionary. The only problem is that with our much smaller number of users and administrators, it's harder to find someone who is not involved and who can therefore be trusted to view the given arguments impartially. So we have the problem of "no consensus over the consensus"... —CodeCat 00:03, 18 November 2014 (UTC)

I am interpreting "consensus" as the preponderance of opinions on the matter. I honestly don't think it occurs as often as you do. The decisions you cite where that's true almost always fall in the 60-40 range. Admins almost never close a discussion one way when more than 65% of the votes are the other. Purplebackpack89 00:05, 18 November 2014 (UTC)

It's not common, no. But the fact that it can and does happen does mean something. The fact that Wikipedia even has an official policy saying it must be done that way is even more telling. While Wiktionary is certainly not Wikipedia, there are some things we can learn from and I think this is one case. —CodeCat 00:08, 18 November 2014 (UTC)

Purple, that's absurd: claiming that Renard operates on how many entries get deleted. He only wants to delete the ones that are actual SoPs. I know you don't understand SoP, as you have often made evident. Equinox ◑ 00:23, 18 November 2014 (UTC)

I stand 100% by that. Prior to the beer parlour discussion above, Renard had expressed dismay that a number of entries were closed as keep despite he believing them to fail CFI. He mentions this dismay in the beer parlour discussion above. Purplebackpack89 00:30, 18 November 2014 (UTC)

If anyone is operating purely "by the numbers" and not by thought or logic, it is you, Purple, who want to decide everything with a transient "keep" or "delete" vote, rather than deciding why, and formulating rules based on the reasoning. Equinox ◑ 00:24, 18 November 2014 (UTC)

I object vociferously to what you've just said. I give reasons for every vote I make. And I'm nowhere near the most voting person here. I also understand what SOP is; I believe it to be a ridiculously restrictive policy that should be eliminated to allow us to have worthy entries that many other dictionaries have. It's not that I have no reasons, it's mostly that you and Renard don't like me reasons. Purplebackpack89 00:28, 18 November 2014 (UTC)

There won't be any point in making any entries (of more than one word) at all if this is passed. Migrant's policy would ruin the dictionary and it would be in danger of stagnation, IMO. There are more receptive dictionaries around on the Internet. Donnanz (talk) 23:29, 17 November 2014 (UTC)

Yep, what Donnanz said. Purplebackpack89 23:32, 17 November 2014 (UTC)

I'm not given to the expression of strong opinions around here, but, frankly, this proposal seems like an absolutely terrible idea to me. It isn't always clear-cut whether a term meets CFI or not. Sometimes the determination of CFI compliance depends upon making a subjective/qualitative judgment (SOPness) rather than simply ensuring that certain objective criteria are being met (three non-mention citations spanning a year). The RfD process exists to resolve such cases. We discuss the matter and reach a consensus. If we're not going to respect the outcome of these discussions — if we're going to allow admins to become judge, jury, and executioner, deleting entries at their sole discretion based on their own personal interpretations of CFI - then the RfD process will become nothing more than a meaningless song and dance. Discouraging discussion and disrespecting consensus in such a manner would be contrary to the collaborative spirit of this project. -Cloudcuckoolander (talk) 00:01, 18 November 2014 (UTC)

On Wikipedia, as I noted above, AfD (article for deletion) discussions are not the same kind of back-and-forth that is often seen here. Instead, each person gives arguments and then a third party will judge those arguments based on policy and decide which view has more merit. The fact that a third party is involved means that powers are somewhat separated. Perhaps we should do something similar here, by requiring that whoever closes an RFD discussion must not have taken part in it. —CodeCat 00:06, 18 November 2014 (UTC)

We absolutely should do that! Purplebackpack89 00:09, 18 November 2014 (UTC)

This looks like something that should be obviously desirable and nice in theory, but I do not think the CFI as it is written right now is a good policy to enforce to the letter. For starters, I would like WT:CFI amended to accommodate "hot word"/"hot sense", {{translation only}} and phrasebook entries first. But even if we do that, there will still be too much room for subjectivity in interpreting CFI, which at best means that RFDs will keep being votes — or worse: as one person on TOW put it, "AfD is not a vote" means "AfD is a vote that administrators are allowed to count any way they like.". — Keφr 08:22, 18 November 2014 (UTC)

This is a joke proposal, right? It’s honestly difficult for me to tell. --Romanophile (talk) 16:03, 18 November 2014 (UTC)

Your comment is a joke, right? You think applying rules we already have is a joke? Renard Migrant (talk) 20:08, 19 November 2014 (UTC)

Maybe the joke is that we need to vote to approve rules that have been already formally enacted. — Keφr 20:22, 19 November 2014 (UTC)

No, I believe Renard is solid in his convictions. Solid enough that the vote starts on Monday. Purplebackpack89 16:42, 18 November 2014 (UTC)

Purplebackpack89 is wrong about what he says about me, for the reasons he gives. It's nothing to do with the number of entries being deleted, but which ones. Also, Purplebackpack89 if with what CodeCat says about deletion debates not being about counting votes but about the overall arguments made, why would you oppose this vote? It's what I'm proposing, after all. Renard Migrant (talk) 18:16, 18 November 2014 (UTC)

"Which ones". The ones I've seen you complain about the most vociferously are those where you voted delete, others voted keep, the discussion was closed as keep, and you claim the entry should be deleted on CFI grounds. What you're essentially proposing is to shut out a line of argument, which coincidentally tends to be one you don't agree with. Purplebackpack89 18:46, 18 November 2014 (UTC)

But if Renard's argument is rooted in CFI whereas nobody else's are, why should we ignore CFI? I support this vote because it means people will be forced to come up with better arguments - specifically, arguments that follow consensus-established Wiktionary policy - if they want their views to be taken into account. I think that's a good thing. —CodeCat 19:54, 18 November 2014 (UTC)

More than that, any problems that are in CFI, currently we've no reason to fix them because editors are free to ignore CFI as much as they choose. Forcing CFI to be applied will put in under much greater scrutiny and therefore it will get amended. What's the reason to improve it right now? Renard Migrant (talk) 22:05, 18 November 2014 (UTC)

Because participating in RfD is easy and changing CFI is hard. And CFI can never cover everything. Sometimes, you just have to use the Potter Stewart test. Purplebackpack89 22:08, 18 November 2014 (UTC)

Starting one week from today, there is going to be a vote on whether RfD and RfV discussions must be closed by uninvolved editors. Purplebackpack89 00:37, 18 November 2014 (UTC)

We generally do this anyway, no need to vote on it. --WikiTiki89 00:39, 18 November 2014 (UTC)

There's no policy that says we have to, though. Purplebackpack89 00:41, 18 November 2014 (UTC)

We don't need a vote to enforce something that we already do. --WikiTiki89 00:42, 18 November 2014 (UTC)

We need a policy to make sure we keep doing it. —CodeCat 00:52, 18 November 2014 (UTC)

It is not that clear that we should. It is naïve to think that requiring "uninvolved editors" to close discussions will eliminate biased closures — maybe even the opposite. Also, this requirement is especially superfluous on RfVs, where the existence of citations is usually not a matter of any interpretation. — Keφr 08:30, 18 November 2014 (UTC)

I have removed RfVs from the vote, though I still harbor reservations that there's nothing stopping the same editor from starting and closing an RfV. Purplebackpack89 16:49, 18 November 2014 (UTC)

I think as it's worded, no, because it excludes anyone who voted. If it excluded just the original nominator and the entry creator, I could go with that. Excluding anyone who votes (though I note, not anyone who comments) could rule out practically everyone for really well discussed entries. Also why would someone who hasn't voted necessarily be 'unbiased'? Also, you could abstain from voting in order to be able to close, which means if you had a bias you'd be free to impose it onto the entry, because you hadn't voted. Renard Migrant (talk) 18:20, 18 November 2014 (UTC)

This. — Keφr 18:33, 18 November 2014 (UTC)

I have closed dozens of deletion discussions that I have participated in - mostly because it seems (to me at least) that discussions tend to languish on the page long after they have run their course. If I hadn't closed those discussions, someone else would have had to pick up the ball, which wasn't happening. If consensus differs from my views, then I go with the consensus. The closed discussion remains on the page for a week following the closure, so if there are objections to the closure they can be raised. bd2412 T 17:07, 19 November 2014 (UTC)

Another admin, Kephir, is harassing me. He removed comments I made on another user's talk page, here and here. When I asked him not to do that, he deleted the message on my talk page, claiming it was vandalism here (commenting on another person's talk page is clearly not vandalism nor graffiti, as he labeled one of my edits). There are many other instances of harassment of me by this editor in months past, including a number of unwarranted personal attacks on talk pages and in edit summaries (this is a good example). Could someone PLEASE get him to stop? Purplebackpack89 22:56, 18 November 2014 (UTC)

If the abuse is long-term I recommend starting User:Purplebackpack89/Kephir. Subsequently write all the instances you can think of where he has misused his tools so that everything is in one place. That way you could remember every negative interaction that has occurred between you and if others agree with you then they may chime in where Kephir could possibly eventually get his admin tools revoked. Zigguzoo (talk) 23:05, 18 November 2014 (UTC)

Kephir has been an admin for 10 months only. Maybe he;s experiencing powertrips of some sort but I get the feeling that if he continues on his current projection of misleading edit summaries and misuse of the tools he may face desysopping soon. Zigguzoo (talk) 01:12, 19 November 2014 (UTC)

Oh, he oughta. The deletion of talk page threads and hiding of edits he did was just seeing what he could get away with with the tools he's proving he shouldn't have. While it's acceptable to clear one's talk page, user warnings should not be tagged as vandalism or graffiti. What compelled him to remove good-faith edits from your talk page, I do not know. Purplebackpack89 03:30, 19 November 2014 (UTC)

I think he's making legitimate criticisms, and I also think you're happy to make legitimate criticisms yourself, but when someone does it to you, you accuse them of harassment. Why do you think it's ok for you to act that way, but when other people do it to you, it's awful and horrendous? Renard Migrant (talk) 18:02, 24 November 2014 (UTC)

@Renard Migrant, because I don't delete the criticisms with the summary "vandalism", nor do I remove other people's comments on talk pages other than my own. It's not so much what he says to me, it's the misleading edit summaries. Purplebackpack89 17:31, 28 November 2014 (UTC)

When I expressed concern about his deletion of two templates, User:Kephir deleted my comment with the summary "Incomprehensible, meaningless or empty: please use the Sandbox". The sandbox is not the appropriate place for user issues. When I told him that, he just deleted that with the edit summary "No usuable content given", which is a CSD for articles, not user comments. Can somebody please tell him to stop the misleading edit summaries? Purplebackpack89 19:04, 28 November 2014 (UTC)

I propose we start WT:Courthouse, a page to discuss user conduct, blocks, reverts, etc. without disrupting the WT:BP. --WikiTiki89 16:09, 19 November 2014 (UTC)

Definitely support. But I wonder if it wouldn't be clearer if we just named the page after its function. —CodeCat 16:11, 19 November 2014 (UTC)

Support the page Not a big fan of the name, though. Purplebackpack89 16:13, 19 November 2014 (UTC)

Is "courthouse" not indicative of its function? --WikiTiki89 16:17, 19 November 2014 (UTC)

Not in the same way that WT:Vandalism in progress is. —CodeCat 16:29, 19 November 2014 (UTC)

Courthouse may actually be a little too indicative. I'd just call it Wiktionary:User conduct Purplebackpack89 16:31, 19 November 2014 (UTC)

Yes that's a good idea, although that might be mistaken for a page describing how users should behave. —CodeCat 16:35, 19 November 2014 (UTC)

WT:Vandalism in progress is a different story, since it's for emergencies. I chose the name WT:Courthouse by analogy to pages such as WT:Beer parlour, WT:Tea room, etc., except that it is actually more indicative of what the page is about. I'd put it at the same level of self-explanatory-ness as WT:Information desk. --WikiTiki89 16:47, 19 November 2014 (UTC)

I realise that. I'm not really that fussed about the names, I'm just wondering if the fancy names like "Beer parlour" and "Grease pit" aren't too confusing to new people who don't already know what they are. —CodeCat 16:50, 19 November 2014 (UTC)

Of course they're confusing, but only for the minute before they read the description on the page. But "Information desk" is not confusing, and I don't think "Courthouse" would be either. --WikiTiki89 17:09, 19 November 2014 (UTC)

What about Wiktionary:Dispute resolution? —CodeCat 17:19, 19 November 2014 (UTC)

That is currently a redirect to Help:Dispute resolution, which says, among other things, that if you have a dispute with a user, come here. That page will have to be reworded when the user conduct page is created. FWIW, I think the user conduct page would be more expansive than just dispute resolution. Purplebackpack89 17:37, 19 November 2014 (UTC)

"Dispute resolution" is something that can be done on userpages. This new page would be for when the dispute resolution fails. --WikiTiki89 18:17, 19 November 2014 (UTC)

...like above, when another editor arbitrarily decides any attempt to communicate with him is vandalism and immediately deletes it. Purplebackpack89 18:26, 19 November 2014 (UTC)

How about Court of last resort? —Stephen ^(Talk) 19:40, 19 November 2014 (UTC)

As a five-time administrator, I put my name forward for being the judge in the courthouse. --Type56op9 (talk) 14:36, 20 November 2014 (UTC)

In my experience the accusations of harassment and evidence gathering and posse forming which go along with it often result in more abuse that the instigating incident. I don't think adding a venue for tong wars will do anybody any favors. I would go so far as to say that disputes between users are better settled off of the site. - TheDaveRoss 23:09, 19 November 2014 (UTC)

I would have agreed, except that some users are always going to complain and giving them a place for it will prevent the Beer parlour from being disrupted by the complaints. It's like creating designated smoking areas versus banning smoking altogether. --WikiTiki89 23:16, 19 November 2014 (UTC)

I support the creation of Wiktionary:Courthouse, and with that name (and, consequently, with the shortcut WT:CH), if only to get all the recent whining off my watchlist via WT:BP and WT:RFD. — I.S.M.E.T.A. 21:52, 20 November 2014 (UTC)

I suspect this will become some sort of sensationalistic, exhibitionistic bullshit like Judge Judy. Let's do it. Equinox ◑ 02:58, 21 November 2014 (UTC)

I support this idea. It will be a place for just average block discussions, rather than for just emergency vandal reports. WT:VANDAL has in the past also been used for regular block discussions, which gives another advantage to WT:Courthouse. Rædi Stædi Yæti {-skriv til mig-} 03:36, 21 November 2014 (UTC)

• How about calling it WT:Theater since it will be for nothing but drama? —Aɴɢʀ (talk) 21:18, 24 November 2014 (UTC)

  That could be a redirect. --WikiTiki89 15:26, 25 November 2014 (UTC)

• I oppose this proliferation of discussion forums. User conduct is only hardly ever discussed in public forums; user talk pages are usually enough for that. We already have too many forums. --Dan Polansky (talk) 01:23, 29 November 2014 (UTC)
  • Dan, what do you do if somebody refuses to engage? Or if you're at an impasse that can only be solved by a third set of eyes? Purplebackpack89 02:02, 29 November 2014 (UTC)

• I oppose per What Wiktionary is not. --Neskaya _sprecan? 04:14, 15 December 2014 (UTC)

Hi,

According to Wiktionary:Criteria for inclusion#Inflections, entries like keeps one's options open are to delete? (cf. keep one's options open).

Regards, — Automatik (talk) 20:23, 20 November 2014 (UTC)

I've added a feature to this template (in its module Module:form of) that automatically links to the glossary definition of a given grammar tag, if it exists. For example:

• {{inflection of|test||1|s|pres|subj|lang=nl}} → (dated or formal) first-person singular present subjunctive of test
• {{inflection of|test||genitive|plural|lang=nl}} → (archaic) genitive plural of test

Not all of the recognised grammar tags have glossary entries yet. I hope this is useful in any case. This feature would make it more desirable to use this template instead of {{form of}}, at least as long as it's possible. I will probably also add this feature to the "shortcut" templates like {{plural of}}, {{accusative of}} and so on. —CodeCat 18:12, 21 November 2014 (UTC)

(Not sure if this is BP or GP material...)

I was just adding context labels to two Chinese entries (traditional spelling 庫納 / 库纳 (kùnà) and simplified 库纳 (kùnà)) to clarify that the meanings here are about a currency. I added {{context|lang=zh|currency}}. Confusingly, and incorrectly, this adds (numismatics) to the visible page, although it does add the page to Category:zh:Currency as expected.

I've left the context labels in place on those two entries. Could someone more familiar with the context infrastructure see about changing this behavior? Numismatics is specific to coinage, whereas currency is about more than just coins. TIA, ‑‑ Eiríkr Útlendi │ Tala við mig 19:30, 21 November 2014 (UTC)

This is all handled in Module:labels/data. You can remove the following lines, if you think that is the right thing to do:

aliases = "numismatics"
deprecated = true

--WikiTiki89 19:50, 21 November 2014 (UTC)

Some unelected person made the unsanctioned decision to deprecate the currency topical tag. Is it clear to anyone what the logic of these labels is? Is this deprecated because some believe topic categories are not a good idea or because this one is not to their taste? Is it explained anywhere accessible? It certainly doesn't fit the documentation of {{context}}.

In the absence of any particular sanction for such, I guess you can do whatever makes sense to you. Even if something ends up broken, it wouldn't be all bad: it might create some pressure to make some actual community decisions about this kind of thing. DCDuring TALK 19:55, 21 November 2014 (UTC)

Actually, the label only adds to the "Money" category. This is because the "numismatics" label is defined twice:

labels = {
	display = "numismatics",
	topical_categories = {"Currency"} }
-- ...
labels = {
	topical_categories = {"Money"} }

The following entries use the "currency" label as of now:

Use that list as you please. — Keφr 21:15, 21 November 2014 (UTC)

Note that the {{context}} and {{label}} tags aren't supposed to be about clarifying which meaning of a word is being referenced. That's what {{gloss}} is for. The context tags are for labeling technical terms within a certain field. Numismatics is a field that has technical terms, but currency isn't. —Aɴɢʀ (talk) 21:19, 21 November 2014 (UTC)

We have many other labels like that, including "cardinal", "ordinal", "personal" and so on. We should probably get rid of those. —CodeCat 22:50, 21 November 2014 (UTC)

Those seem less clear cut than the more purely topical labels. Like other dictionaries we use beginning-of-the-line labels to convey grammatical information that qualifies and clarifies the definition. The labels mentioned above sometimes convey grammatical information. For example, in English, ordinals normally fit only in certain slots relative to determiners and adjectives in NPs. DCDuring TALK 15:56, 22 November 2014 (UTC)

But does that mean they should be a context label? "Ordinal" is not a context, it's a description of the semantic function of the word. —CodeCat 16:00, 22 November 2014 (UTC)

So are the labels about transitivity and countability. The convention among dictionaries is generally placement at the beginning of the line. (We rejected the other convention of having a separate header for transitive and intransitive.) Dictionaries that have information on complements (eg, head of following PP), semantic restrictions of what is modified, and orthography also place that at the beginning of the definition line. DCDuring TALK 16:27, 22 November 2014 (UTC)

Transitivity is contextual though. Verbs can have different meanings depending on the presence of an object. —CodeCat 18:38, 22 November 2014 (UTC)

Why should we care about what you or I think is or is not 'contextual' or 'grammatical'? We are discussing a user interface. The sole question of importance is what and where would users expect certain classes of information. I was simply arguing against another case of jumping to - and acting on - premature conclusions.

I like the idea of putting topical information after the definition, if we have it at all. Are you saying that this is information that belongs after the definition or on the inflection line or in a usage note or that it doesn't belong in the entry at all? DCDuring TALK 19:34, 22 November 2014 (UTC)

"cardinal" and "ordinal" don't need to be displayed because that should already be obvious from the definition and the part of speech. "personal" could just be a gloss after the definition, but only if it's needed to qualify it (for example who alone could be both a personal and relative pronoun). —CodeCat 20:37, 22 November 2014 (UTC)

I might agree with this conclusion, in most applications, but the evidence of how you reach it scares me. "Obvious" to whom?

Is it obvious from the PoS header "Adjective" or from the PoS header "Numeral"? Both of them are applied to English ordinal numbers. BTW, do we still have runs of entries with unusual or no-longer-conforming headers? DCDuring TALK 23:18, 22 November 2014 (UTC)

@CodeCat At the very least next and last are ordinals that depart from the numeral pattern. Presumably, next to last, ultimate, penultimate, antepenultimate are also ordinals. My imagination and memory both fail to provide me with others, but I suspect there are more, some probably used only in special contexts. I think all of these have common characteristics in terms of order in noun phrases: ' s ' (much less often ' s '), not *' s ', nor *' s s ', etc. Ie, 'the last six red cars' (or ?'the six last red cars'). I think this kind of characteristic suggests that we need to keep the 'ordinal' label. I have the strong suspicion that it is only by ignoring some of the fine-grained features of syntax that we can feel free to ignore this kind of essentially lexical information. I wonder whether we shouldn't actually apply an RfD process to any deletions of data from the modules. DCDuring TALK 01:25, 25 November 2014 (UTC)

I don't see why the meanings of those terms can't be expressed without putting {{lb|en|ordinal}} in front. —CodeCat 01:50, 25 November 2014 (UTC)

It is a question of SYNTAX, not semantics. That is exactly the sort of thing that we put in front-of-definition labels. By labeling them properly we can help folks use them properly without having to have a common usage note in every English entry that has an ordinal sense. Wiping out content that you don't seem to understand does not engender trust in your decisions. DCDuring TALK 04:46, 25 November 2014 (UTC)

What Angr said (at 21:19, 21 November 2014 UTC). "Currency" is a gloss, not a context. - -sche (discuss) 02:01, 25 November 2014 (UTC)

Hello all. I'm just posting this here to notify everyone that the vote to confer administratorship on User:ObsequiousNewt began twenty-five minutes ago; the vote will end at 24:00, 10 December 2014 (UTC). — I.S.M.E.T.A. 00:31, 25 November 2014 (UTC)

We often get feedback about things that are incorrect or missing in our entries. This is very useful, but having it on the feedback page puts it out of view of some of the editors who might fix it. Furthermore, the feedback is only for anonymous users, registered editors can't use it (the link simply doesn't show up). So I believe it would be beneficial to have a single page, somewhat like a discussion page but without any real "discussion", where IPs and logged-in users alike can report mistakes in entries. This would primarily be used by people who don't have the linguistic (might not be fluent enough to be sure) or technical (might not understand our code) knowledge to fix it themselves. —CodeCat 22:41, 25 November 2014 (UTC)

Maybe... though to me this feels slightly redundant to individual entries' talk pages (though I know they can be overlooked) and the Tea Room. Equinox ◑ 22:52, 25 November 2014 (UTC)

My intent was to create a page that is focused more on reporting errors and less on discussing them, which the Tea Room is more about. It's definitely not obvious to me (or to many anonymous users, I imagine) that the TR should be used to report mistakes. —CodeCat 22:59, 25 November 2014 (UTC)

But it could be made obvious, e.g. by having a link on every mainspace entry, visible to both registered and unregistered users, saying "Find an error or omission? Please report it to the Tea Room." —Aɴɢʀ (talk) 23:02, 25 November 2014 (UTC)

I like the idea. Putting the items in TR could overwhelm the place.

Could we do something to really encourage timid or uncertain users to report errors and omissions. For example, imagine a tab or something on the entry page with an invitation to report an error, with the report either on the talk with a link thereto on the proposed page or directly on the proposed page. DCDuring TALK 01:05, 26 November 2014 (UTC)

I definitely like the idea of the "report" button, I was thinking of something like that as well. It would streamline the process for the user and make it more likely that they will report things, which helps us in turn. —CodeCat 01:10, 26 November 2014 (UTC)

I agree, let's use the tea room and talk pages rather than an entirely new page. WT:FEED not ideal but still better than nothing. Remember a lot of these corrections will turn out to be wrong or unprovable. Renard Migrant (talk) 18:20, 26 November 2014 (UTC)

I agree with the RM about the likely low yield (less than 50%, possibly much lower) of usable 'reports'. That seems to me to be a reason not to put such items on WT:TR. I do think we need a single page that has all the instances of such reports. Whether it would be populated with the 'reports' and links to the entry or with links to the section of the entry talk pages that contained the 'report' is worth discussion. I suppose leading users to the talk page has some advantages, especially as the issue may have been discussed before.

Is there any benefit to a limited test or is the best test full implementation with attentiveness to user response to the new invitation to 'report'? DCDuring TALK 15:32, 29 November 2014 (UTC)

As an Ancient Greek editor, many words that I have come across have dialectical or alternative forms. For verbs, this can mean that different tenses have different alternative forms. Policy only states that the alternative lemma should not have a full entry, and what I have found is not clear as to which headers should be included. Therefore I ask: should inflection tables of alternative forms go only on the lemma entry, only on the alternative form entry, or on both?

I'd hold that they should at least appear on the lemma entry, if only for the reason that, in the case of GRC verbs, most alternative forms will be for non-present tenses. In fact, I would favor including nothing in an alternative form's entry but the Alternative forms, Pronunciation, and POS headers; the lemma should hold all of the verb's information, while alternative forms should be only a soft redirect. The argument against this, with regards to inflection at least, would be that the inflection of the alternative form is relevant to the alternative form and not the lemma- e.g. that the inflection of δᾶμος (dâmos) is relevant only to the alternative lemma δᾶμος (dâmos) and not the standard form δῆμος (dêmos). ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 16:04, 28 November 2014 (UTC)

Inflections can be added to alternative forms. — Ungoliant ^(falai) 16:11, 28 November 2014 (UTC)

@Ungoliant MMDCCLXIV: Do you mean that this is the practice, or that you think it should be? And if so, should they be added to the lemma entry as well? ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 16:43, 28 November 2014 (UTC)

It’s the common practice, at least for the languages that I read and edit (an also what I think it should be).

I don’t recall ever seeing the inflection of an alternative form displayed in the lemma. If the peculiarities of Ancient Greek mean it is better to list all the inflections in one place, you should convene the Ancient Greek contributors to see what they think, and write something in WT:AGRC if they agree it requires special treatment. — Ungoliant ^(falai) 16:54, 28 November 2014 (UTC)

I always include full inflection in alternative forms. —CodeCat 16:55, 28 November 2014 (UTC)

On Wiktionary Talk:Requested entries (English)#Reordering the years was a brief discussion of the benefits of having the year appear in descending order for each letter. The principal benefit would be the likely elimination of the need to move items to the current year from the first year listed when a requester accidentally places it in the wring year. Users who click on the letter will find a list in which to place their request and will from time to time fail to notice the year section heading. Even users who do find the right year heading need extra pagedowns or scrolls to do so. Other than the work to do it and the modest change for habituated users of such pages I can't think of significant reasons not to do this. (The option of having separate sections for each year with alphabetical ordering thereunder would make it harder to find requests in different years that were duplicates or near duplicates.) DCDuring TALK 15:12, 29 November 2014 (UTC)

@DCDuring: Seems sensible. Go for it. — I.S.M.E.T.A. 22:57, 29 November 2014 (UTC)

Ordering by year before letter might make even more sense, so that people can focus on the oldest ones first. —CodeCat 23:13, 29 November 2014 (UTC)

@CodeCat I assume you mean ascending order by year. Did you think the whole alphabet of requests for 2011 should appear before, say, those for 2015?

I am not concerned so much about what experienced contributors do, though I would not want to inconvenience them, as much as I am concerned about reducing needless user error, especially, but not limited to, newbies. Our veteran contributors can make decisions about the kind of requests they would like to fill (or delete) by whatever criteria they have, probably little influenced by how the page is presented. DCDuring TALK 00:02, 30 November 2014 (UTC)

@DCDuring As a frequent editor of the page, I think CodeCat's idea is the most efficient. Year should be given priority over letter, as even the most experienced users would be much more likely to refocus their efforts on the older entries simply because they are further up the page, and they would thereby be completed more quickly. If they are being completed more quickly, the inexperienced users would be less likely to even stumble upon the entries from the older years as they would already be completed. I support the replacement of the year and letter sections with each other. WikiWinters (talk) 22:39, 30 November 2014 (UTC)

I am not entirely certain what you mean by priority. Are you saying that all 2011 items should precede all 2012 items etc, down to the present? I contrast your view with that of another frequent user of the page, Equinox, who seems to think that almost anything more than a year old is not worthwhile. I would have thought that new additions are most worthy of consideration. Consideration leads to entry creation, removal from the list, or kicking the can down the road. After a few contributors have given an item such consideration, presumably the item is too specialized for any current contributor. Why would we want to force folks who have already looked at the item to keep on looking at it or to expend keystrokes to avoid looking at it? DCDuring TALK 22:59, 30 November 2014 (UTC)

@DCDuring I mean that, rather than having sections for each letter and sorting each letter's entries by year, I propose that there be sections for each year (only the years that contain entries currently) and that within the year sections there be smaller sections for each letter, so it would be the opposite of what it is now. Many of the older entries easily meet the CFI requirements, and, while standard protocol is for the entries to be open to discussion and for the community to leave entries as they are, their theoretical placement above all of the newer entries would make it easier for all users, regardless of level of experience, to notice them. It's obviously expected that people not immediately delete entries because they don't think they meet CFI, but with this new system, experienced users would not have to scroll down as much and would notice the entries that do not meet CFI more easily, and new users would be more likely to attempt to create the first entries they see, which would be the ones from the oldest year, at the top. Newer entries tend to meet CFI more easily, simply because the older entries generally stay only after users see that they are older and are therefore probably "there for a reason," while the newer ones are generally treated more at face value and less by seniority, so as to be dealt with accordingly at a more rapid and efficient rate. WikiWinters (talk) 23:32, 30 November 2014 (UTC)

SemperBlotto used to wipe the 12-month-old requests every year (around Christmas, in fact; I like to imagine he thrust them into a cheerful Dickensian fire). I felt this was a good idea, since important words would keep coming up again and again, while dross (like much of the WT:REE page) would be lost. But someone objected to this, which is why the page is now full of crap nobody will create, but nobody dares to delete. Equinox ◑ 02:59, 30 November 2014 (UTC)

Pushing the old year sections to the bottom of each letter section is somewhat in that direction, but I was mostly trying to reduce keystrokes without a lot of controversy. DCDuring TALK 03:39, 30 November 2014 (UTC)

@Equinox, SemperBlotto Would SB now delete everything from 2011 and 2012? So, most of the time, except December, we would have two years of requests? DCDuring TALK 22:59, 30 November 2014 (UTC)

@Equinox How about moving all requests from the calendar year before last to subpages (e.g., WT:RE:en/2012 and previous)? — I.S.M.E.T.A. 09:33, 30 November 2014 (UTC)

A possibility that would mean that duplicates would be harder to discover. I suppose one could argue that it is the more recent addition that better indicates degree of interest. DCDuring TALK 13:16, 30 November 2014 (UTC)

@DCDuring: My thinking was that such consignment to subpages would have the decluttering effect of SemperBlotto's Dickensian fire, but without the actual loss / deletion that some have objected to. The presence of duplicates is pretty unimportant; they can be cleared out as blue links every few months. — I.S.M.E.T.A. 14:58, 30 November 2014 (UTC)

I sometimes sign requests <small>~~~~</small>. It shows who made the request and when. Maybe get rid of the years all together as it isn't when the request was made that matters. Renard Migrant (talk) 16:40, 1 December 2014 (UTC)

Signatures make the page larger and might force us to a subpage structure.

In the absence of signatures, the year conveys something: that none those who fill requests have been able or willing to fill the specific request over a time period, nor have they felt free to delete it. It is obvious to me that fresh requests are more actionable (whether the action be fulfillment, deletion, or comment) than stale ones.

Perhaps we need some kind of workflow-related organization of requests: automatic linking to component terms (as in {{head}}?) and a timestamp would be the best initial presentation, possibly together with determination whether the item was a duplicate of a previous request. This would be a better base for subsequent decisions, such as fulfillment or deletion. Items not rapidly fulfilled or deleted could be manually labelled with "issue" tags like "attestable?", "SoP?", "spelling?", "language?", or tagged as topically specialized. Thus subsequent reviewers of the items would not be starting over and could pick items based on the issues or topical specialty involved. DCDuring TALK 17:17, 1 December 2014 (UTC)

If we absolutely must keep every addition to the page, then I think we need a somewhat "intelligent" script or database that can track all additions, and boost the popularity of a word when a second (third, fourth...) person requests it, etc.; and this will at least give us a numerical justification for deleting very old and unpopular requests. But it seems like massive overkill. I still prefer the idea of wiping the page every couple of years. Equinox ◑ 06:08, 17 December 2014 (UTC)

Hello everyone!I had a idea for a new button:A HTML button.It can completely allow html and gives people the ability to make entries better.

Supersonic414-On Wikia 00:09, 30 November 2014 (UTC)

And what would it be used for exactly? —CodeCat 00:38, 30 November 2014 (UTC)

The only button that makes things better is the secret red one that nukes everybody on the planet. Allowing free HTML on here would just encourage stupid exploits like JavaScript. Equinox ◑ 03:10, 30 November 2014 (UTC)

Please comment I went to categorize Grauniad as under Category:English misspellings but the category's introduction says that it is for unintentional misspellings. Do we have or should we have some scheme for navigating deliberate misspellings? cf. eye spellings like da and tha for "the". —Justin (koavf)❤T☮C☺M☯ 20:08, 30 November 2014 (UTC)

We have {{eye dialect|...|lang=xx}}. But for deliberate misspellings, well, if you deliberately misspell something, you spell it a way that is not in the dictionary; so I don't see why we should expect to include these until/unless they become mainstream spellings. See the recent discussion on rediculous (which CodeCat spells that way on purpose). Equinox ◑ 20:18, 30 November 2014 (UTC)

Not all deliberate misspellings are eye dialect, though; Grauniad isn't. Category:English misspellings does already contain some terms labeled "deliberate misspellings", though, e.g. enuf. In fact, in that entry I see that {{deliberate misspelling of}} automatically categorizes into the Misspellings category. —Aɴɢʀ (talk) 21:04, 30 November 2014 (UTC)

What about "fictional" misspellings? I'm thinking of Jane Austen Persuasion, end of chapter VI: ‘... mentioning him in strong, though not perfectly well-spelt praise, as "a fine dashing felow, only two perticular about the school-master," ...’ (bolding added) . Do these get automatic entries? They are fictional eye-dialect, but of course, deliberate by Austen. Choor monster (talk) 21:12, 30 November 2014 (UTC)

Perticular would probably be attestable as eye-dialect. I hear that pronunciation sometimes. DCDuring TALK 23:06, 30 November 2014 (UTC)

It's already an entry perticular, where it's marked as "obsolete". Choor monster (talk) 23:25, 30 November 2014 (UTC)

Change the category description. Renard Migrant (talk) 16:47, 1 December 2014 (UTC)

To what? The OED makes it clear that it's obsolete. I gave the Austen cite is a prominent example of a deliberate fictional misspelling, not eye-dialect, a distinct kind of misspelling from something like "rediculous" or "nucular". Usually these are one-offs, but because Austen is Austen, maybe it rates an entry. Similar, but not rating an entry would be from the end of Miss MacIntosh, My Darling: "She would hang a sign in the restaurant window. Owt to luntsch. Bee bak in a whale. For she could not spell either." Choor monster (talk) 17:21, 1 December 2014 (UTC)

No, change the category description, the written statement at the top of the CATEGORY. Renard Migrant (talk) 23:12, 2 December 2014 (UTC)

Eye spellings Don't go too off the rails about eye spellings: this isn't one. I only mentioned them as another type of misspelling which is not accidental. —Justin (koavf)❤T☮C☺M☯ 10:52, 2 December 2014 (UTC)

Koavf's change to the description is pretty good. But what do you think of making the wording even more compact, like:

• "Common accidental (or sometimes deliberate) misspellings of {{{langname}}} terms."

? - -sche (discuss) 18:26, 9 December 2014 (UTC)