Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:V)
Jump to: navigation, search

Wiktionary > Votes

The page Wiktionary:Votes consolidates policy votes and procedural votes that take place on Wiktionary. It formalizes and documents the consensus building and voting policy. For an archive of previous votes, see Wiktionary:Votes/Timeline and Wiktionary:Votes/. This header is at Wiktionary:Votes/header.

Main sections of this page: #Current and new votes, #Recently ended votes and #Proposed votes. See also /Timeline.

Current and new votes

Migrating from Template:term to Template:m


  1. Symbol support vote.svg Support --Vahag (talk) 18:23, 29 August 2014 (UTC)
  2. Symbol support vote.svg SupportCodeCat 19:28, 2 September 2014 (UTC)
  3. Symbol support vote.svg Support Mulder1982 (talk) 19:45, 12 September 2014 (UTC)
  4. Symbol support vote.svg Support, but I would like the final result to be {{term}} redirecting to {{m}} (or vice versa). --WikiTiki89 19:46, 12 September 2014 (UTC)
    To do that, we would first need to orphan {{term}}, as the parameters are not compatible. And at that point there is no need for a redirect anyway, is there? —CodeCat 20:03, 12 September 2014 (UTC)
    Yeah there is: so that people can start using {{term}} instead of {{m}} if they feel like it suits them better. --WikiTiki89 20:05, 12 September 2014 (UTC)
    We should aim at there being one template in the mainspace. We should aim at at least a semblance of professionalism. Keeping term with old parameter order to make old revision legible is fine. --Dan Polansky (talk) 20:13, 12 September 2014 (UTC)
    Actually, that's also a good idea. --WikiTiki89 20:31, 12 September 2014 (UTC)
  5. Symbol support vote.svg Support — It's better to have one term (whichever) than two - since the newbie suspects there's a subtle difference between them. Since most will look for an example (like me) either would do, but m is shorter — Saltmarshαπάντηση 19:30, 5 November 2014 (UTC)
  6. Symbol support vote.svg Weak support — I can agree that "term" is more descriptive than "m", which can be confusing. On the other hand, not needing a named language parameter makes things a lot easier. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:14, 25 November 2014 (UTC)
  7. Support "term" does not mean what it says, and it's NOT more descriptive; it's misleading, beside being longer. "m" would force the newbies to read the docs, which is eventually a good thing, because by seeing "term" they probably think that they already know what the template does, while they usually don't. --Z 10:07, 1 December 2014 (UTC)
  8. Symbol support vote.svg Support per Z. --Fsojic (talk) 10:53, 1 December 2014 (UTC)
  9. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 02:05, 8 December 2014 (UTC)
  10. Support per Z. Keφr 08:02, 9 December 2014 (UTC)
  11. Symbol support vote.svg Support. {{m}} is much easier to use and should be the default. I agree with Wikitiki89, though, that it's best to leave {{term}} functional, since it's been in use for so long, and because we should go as easy as possible on casual editors. I think the best course of action is to swap out current uses of {{term}} to reduce confusion and encourage the use of {{m}}, but not to introduce any overt obstacles to use of {{term}} by those who want to use it (hidden tracking categories should be ok). I can understand the resentment of many here for the way the changes in behavior of some templates with respect to omitted language codes was handled, but, on balance, I think this is a better course of action. Chuck Entz (talk) 20:15, 3 January 2015 (UTC)
  12. Symbol support vote.svg Support embryomystic (talk) 05:25, 22 January 2015 (UTC)
  13. Symbol support vote.svg SupportUngoliant (falai) 05:29, 22 January 2015 (UTC)


  1. Symbol oppose vote.svg Oppose No user will ever guess what {{m}} means, while the meaning of {{term}} is rather obvious. We need to think about non-regulars and casual contributors too. -- Liliana 18:05, 29 August 2014 (UTC)
    At least the name of {{m}} is intriguing while term is misleading - one may take it for only a decorating template (like I did until recently xD).--Dixtosa (talk) 19:07, 29 August 2014 (UTC)
    Just to note, {{m}} is now a shortcut for the more descriptive name {{mention}}, while {{l}} is likewise a shortcut to {{link}}. —CodeCat 21:10, 5 November 2014 (UTC)
    I always thought {{l}} stood for "list-item", not just "link". Keφr 09:05, 8 December 2014 (UTC)
    I also thought that. --WikiTiki89 09:33, 8 December 2014 (UTC)
  2. Symbol oppose vote.svg Oppose. It's a cryptic and unhelpful name. But I think the parameter order of {{m}} is better. Perhaps it would be nice to migrate all existing uses of {{term}} to that parameter order. This, that and the other (talk) 07:37, 31 August 2014 (UTC)
  3. Symbol oppose vote.svg Oppose deleting Template:term. No opinion regarding any other action. —Mr. Granger (talkcontribs) 19:32, 2 September 2014 (UTC)
  4. Symbol oppose vote.svg Oppose. The name term is more comprehensible. The old revision histories will be clearer (not that that's a strong argument in my opinion, but it's worth something). And even if all were equal (m and term were equally good), there'd be no reason to specifically change from one to the other. I have no opposition, however, to reordering the parameters of either template to match those of the other, provided that that's done without introducing errors.​—msh210 (talk) 16:35, 18 September 2014 (UTC)
    Changing {{term}}'s parameters to match {{m}} would break the old revision histories anyway. --WikiTiki89 20:45, 18 September 2014 (UTC)
  5. Symbol oppose vote.svg Oppose. As above - term means what is says; m will always mean masculine to me. SemperBlotto (talk) 08:51, 13 October 2014 (UTC)
  6. Symbol oppose vote.svg Oppose Per others, especially Liliana's argument. User: PalkiaX50 talk to meh 09:19, 13 October 2014 (UTC)
  7. Symbol oppose vote.svg Oppose --Dijan (talk) 19:33, 14 October 2014 (UTC)
  8. Symbol oppose vote.svg Oppose strong. Another unnecessary merge. Purplebackpack89 14:14, 2 November 2014 (UTC)
  9. Symbol oppose vote.svg Oppose – I read the ‘rationale’ but can't see any explanation…does this new template do something different? If not, why can't we just change how {{term}} works? And why ‘m’?! Basically, no. Ƿidsiþ 08:15, 17 November 2014 (UTC)
    If we change term to work like m... that's basically what the support camp is arguing for. That's basically support but under another name. Renard Migrant (talk) 18:54, 7 December 2014 (UTC)
    @Renard Migrant: I don't think so. The disagreement seems to be about the template name. I don't see anyone insisting that term should be used like {{term|...|lang=en}} instead of {{term|en|...}}. --Dan Polansky (talk) 18:59, 7 December 2014 (UTC)
  10. Symbol oppose vote.svg Oppose This doesn't simplify anything. At all. --Neskaya sprecan? 05:02, 28 December 2014 (UTC)


  1. Symbol abstain vote.svg Abstain I can't decide between the pros and the cons. --Dan Polansky (talk) 17:18, 26 September 2014 (UTC)
  2. Symbol abstain vote.svg Abstain, I prefer {{m}} but I see no reason to 'ban' {{term}}. Renard Migrant (talk) 18:50, 7 December 2014 (UTC)
    @Renard Migrant: Would it be accurate to say you support "Replacing all uses of Template:term with Template:m" but not "subsequently discontinuing Template:term"? --Dan Polansky (talk) 18:56, 7 December 2014 (UTC)
    No it wouldn't. Renard Migrant (talk) 12:37, 21 January 2015 (UTC)


Templates context and label

  • Polling on: Clarifying which template to use to tag definition lines as "countable", "transitive", "colloquial", "geography" and the like. Currently available templates are {{context}}, {{cx}}, {{label}}, {{lb}}. The choice is about template name, not about syntax of its parameters. Two choices are presented: one between (context, cx) and (label, lb), and another one between long form (context, label) and short form (cx, lb).

    The syntaxes might look like this, assuming the language as the first parameter of the template:

    • {{context|es|colloquial}}
    • {{cx|es|colloquial}}
    • {{label|es|colloquial}}
    • {{lb|es|colloquial}}

I prefer label over context

  1. Symbol support vote.svg Support Because {{label}} takes the language as the first parameter, whereas {{context}} requires lang=. —CodeCat 19:25, 2 September 2014 (UTC)
    The vote text makes it clear this is about the template name, not about the parameter order and syntax. We can make {{context}} behave exactly like {{label}}, yielding syntax like {{context|es|colloquial}}. --Dan Polansky (talk) 17:28, 3 September 2014 (UTC)
  2. Symbol support vote.svg Support More accurate when dealing with grammatical categories like "transitive" or "passive", or "with accusative", and still fits the idea of a context semantically. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:20, 25 November 2014 (UTC)
  3. Symbol support vote.svg Support embryomystic (talk) 23:37, 6 December 2014 (UTC)

I prefer context over label

  1. Symbol support vote.svg Support We want to make it clear that you aren't supposed to write definitions like "(tree) oak", and context does a better job at that. -- Liliana 10:57, 30 August 2014 (UTC)
    That could be addressed by template documentation. And how often has this been a problem in practice? Keφr 15:28, 2 November 2014 (UTC)
  2. Symbol support vote.svg Support I prefer to make clear that register and other context information is the primary purpose of information so position on a definition line. DCDuring TALK 16:51, 25 October 2014 (UTC)
  3. Symbol support vote.svg Support, and in addition, I'd like to note that I prefer slang and certain other things being decoupled from context. Purplebackpack89 14:16, 2 November 2014 (UTC)
    Nonsensical. Of all things, "slang" is definitely a context label. Keφr 15:28, 2 November 2014 (UTC)
    @Kephir:: And? The main jist of my comment is I believe context covers too many things that would be better covered in other templates Purplebackpack89 22:55, 28 November 2014 (UTC)

I prefer short template name over long template name

  1. Symbol support vote.svg Support Dan Polansky (talk) 09:50, 30 August 2014 (UTC) I dislike the introduction of {{context}}, but if we need to have a template before "colloquial" and the like, let it be short. --Dan Polansky (talk) 09:50, 30 August 2014 (UTC)
    Symbol oppose vote.svg OpposeCodeCat 19:27, 2 September 2014 (UTC)
  2. Symbol support vote.svg Support I don't care whether the short name is botically changed afterward to a longer, more communicative name: I just like to save keystrokes. DCDuring TALK 16:47, 25 October 2014 (UTC)
  3. Symbol support vote.svg Support Ivan Štambuk (talk) 21:49, 26 October 2014 (UTC)
    Symbol abstain vote.svg Abstain Too amorphous, depends on what the short and long template names are Purplebackpack89 14:17, 2 November 2014 (UTC)
  4. Symbol support vote.svg Support, but also in agreement with This below. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:20, 25 November 2014 (UTC)
    Symbol oppose vote.svg Oppose --Neskaya sprecan? 16:50, 8 January 2015 (UTC)
    This poll was designed to be free from opposes in these "I prefer" sections; each preference has a heading under which a support can be filed, and a complementary heading. I won't be removing these "opposes", but they make the poll results a bit more confusing. --Dan Polansky (talk) 13:38, 10 January 2015 (UTC)
    I've indented non-supports to ease counting of supports. --Dan Polansky (talk) 13:54, 10 January 2015 (UTC)

I prefer long template name over short template name

  1. Symbol support vote.svg Support again, for clarity purposes. -- Liliana 10:57, 30 August 2014 (UTC)
    Symbol oppose vote.svg OpposeCodeCat 19:27, 2 September 2014 (UTC)
    I've indented non-supports to ease counting of supports. --Dan Polansky (talk) 13:54, 10 January 2015 (UTC)
  2. Symbol support vote.svg Support because clarity and readability, also accessibility to new users on the project. --Neskaya sprecan? 16:49, 8 January 2015 (UTC)

Oppose the poll

  1. Why can't we have them all, as redirects to the one central template? Or is this vote to choose a "canonical" name for the template? This, that and the other (talk) 07:39, 31 August 2014 (UTC)
    This is a poll about which template editors prefer. This poll does not propose any deletion of a template. A participant in the poll may clarify in their comment that they oppose deletion of any template. Right now, at least one editor is performing a particular conversion in the mainspace, and we do not know whether that conversion matches editor preferences. --Dan Polansky (talk) 15:55, 31 August 2014 (UTC)
  2. Moo. Keφr 14:05, 4 September 2014 (UTC)


  1. Symbol abstain vote.svg Abstain. Whateva. Renard Migrant (talk) 16:55, 8 January 2015 (UTC)

Migrating from Template:context to Template:cx

  • Voting on: Replacing all uses of {{context}} with {{cx}}. First making sure {{cx}} is unused, then changing {{cx}} to use "cx|en|colloquial" syntax instead of "cx|colloquial|lang=en" syntax, then furnishing {{cx}} with the fastest code currently available in Wiktionary templates and modules for the purpose, and then performing the replacement. No proposal is being made about whether {{context}} should be retained afterwards, e.g. to simplify reading of revision history.
  • Rationale: For a rationale, see Wiktionary talk:Votes/2014-08/Migrating from Template:context to Template:cx#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote starts: 00:01, 5 October 2014 (UTC) (delayed by one month)
  • Vote ends: 23:59, 5 November 2014 (UTC)
    • Vote extended to 23:59, 30 December 2014. (UTC) --Dan Polansky (talk) 22:51, 28 November 2014 (UTC)
    • Vote extended to 23:59, 30 January 2015 (UTC) --Dan Polansky (talk) 08:26, 30 December 2014 (UTC)


  1. Symbol support vote.svg Support Dan Polansky (talk) 08:40, 5 October 2014 (UTC)
  2. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 00:49, 3 December 2014 (UTC)


  1. Symbol oppose vote.svg Oppose due to the fact that it needlessly complicates things. Why are we moving templates away from things that can be remembered again? "context" is a lot clearer to newer editors to use than "cx", and always will be. --Neskaya sprecan? 17:50, 29 October 2014 (UTC)
  2. Symbol oppose vote.svg Oppose Whenever you migrate a template, you kill a kitten and drive an editor off the project. Purplebackpack89 19:43, 2 December 2014 (UTC)
    No, I actually read a study this the other day. There is no statistically significant correlation between template migration and kitten deaths. --WikiTiki89 00:44, 3 December 2014 (UTC)
    I think you missed the point. The point is template migration confuses the heck out of editors. IMO, it's in the top 5-10 of reasons editors throw up their hands and leave the project. So it should be avoided whenever possible. It's possible to avoid it here. Purplebackpack89 14:33, 3 December 2014 (UTC)
    I think you missed my point: I was joking. --WikiTiki89 15:52, 3 December 2014 (UTC)
    Not sure what to respond to that. This is formulated as a blanket opposition to any and all template migrations. I think this extreme position is generally harmful; there should be moderation in template migrations, but to do template migrations after careful deliberation, after a public discussion took place and editors agree is useful. I do not believe infrequent and carefully deliberated template migrations drive productive editors away.--Dan Polansky (talk) 09:59, 20 December 2014 (UTC)
    For one thing, Dan, it's not infrequent in this case. There are slang terms that used to have their own templates, and then (wrongfully, IMO) got merged into Template:context. Now, people are using Template:label instead, and proposing to move Template:context. So, a high-profile template has been migrated multiple times since I got here. And if it's happened multiple times, it means we weren't careful or deliberate the first time. The other problem is that a lot of editors seem to expect the learning curve on new or migrated templates to be quick and easy. From all the evidence I've seen, it isn't. Wiktionary is already hard to use as it is (with overuse of templates and arbitrary policy); migrating templates makes it worse. Purplebackpack89 14:58, 19 January 2015 (UTC)
    The migrations you mention happened and are happening without votes. They would not have so easily happened via a vote. Yes, we used to have {{slang}}, and yes, I would have opposed migrating away from it. --Dan Polansky (talk) 18:21, 19 January 2015 (UTC)
  3. Symbol oppose vote.svg Oppose If users don't become editors, one of the main reasons is that the internal page format frightens them. Everything making it still less readable is a bad thing. Lmaltier (talk) 18:29, 19 January 2015 (UTC)
    Any evidence? (They don't have these wikitext hurdles at OmegaWiki, but OmegaWiki does not fare better than the English Wiktionary.) --Dan Polansky (talk) 19:25, 19 January 2015 (UTC)
    Most Wiktionary editors come from Wikipedia, they are used to the wiki syntax. I was not referring to it, but to all these templates making the page difficult to understand. On fr.wikt, we already had a number of users telling us that they could not contribute to Wiktionary because of that. Lmaltier (talk) 21:23, 19 January 2015 (UTC)


  1. Moo. Keφr 09:21, 5 October 2014 (UTC)
    What an interesting self-disclosure. As per moo, are you (a) a cow, (b) a bull or (c) a foolish woman? --Dan Polansky (talk) 09:23, 5 October 2014 (UTC)
    I think he means mu#Etymology 2. —Aɴɢʀ (talk) 13:11, 5 October 2014 (UTC)
  2. Symbol abstain vote.svg Abstain There are too many options that are not accounted for in this vote. --WikiTiki89 00:54, 3 December 2014 (UTC)
  3. Symbol abstain vote.svg Abstain because polls are evil. —Aɴɢʀ (talk) 14:34, 3 December 2014 (UTC)
    Policy votes in English Wiktionary -- transparent, fair, open-to-discussion and timely collective decision making enabling broad editor participation since 2006. --Dan Polansky (talk) 17:10, 5 December 2014 (UTC)
    Policy votes in English Wiktionary — replacing discussion and consensus-seeking with divisiveness and the tyranny of the majority since probably earlier than 2006. —Aɴɢʀ (talk) 20:35, 5 December 2014 (UTC)
    I ask the reader to check English Wiktionary votes to verify the presence of plentiful open discussion (a) before the votes in locations referenced by the votes, (b) directly on the vote pages, and (c) on the talk pages of the votes. I also ask the reader to verify in the votes that plain majority does not get to decide in English Wiktionary votes as evidenced by the closure of the votes; we actually decide by supermajority, at the very least 2/3 of voters, although higher thresholds have been mentioned. I also submit to the reader that I saw no unjust or cruel rule imposed by the votes, so no case of "tyranny" can be confirmed. To the contrary, I point to my favorite vote Wiktionary:Votes/pl-2010-05/Names of specific entities, which relaxed stringent requirements on proper names required by a vocal minority; via that vote, a rule by a minority via inflexible application of unvoted-on policy in RFV process was removed. --Dan Polansky (talk) 21:58, 5 December 2014 (UTC)


Renaming rhyme pages

Support proposal 1

  1. Symbol support vote.svg Support Even if it wasn't a fait accompli I would still have supported it. This, that and the other (talk) 10:24, 23 September 2014 (UTC)
  2. Support Having a slash (/) after the language name is a natural extension of our appendix names like "Appendix:Frankish/kawa". Keφr 07:55, 9 December 2014 (UTC)
  3. Symbol support vote.svg Support, works better because of the subpage system and templates like {{subpages}}. Renard Migrant (talk) 14:05, 4 January 2015 (UTC)
  4. Symbol support vote.svg Support Lmaltier (talk) 16:35, 4 January 2015 (UTC)
  5. Symbol support vote.svg Support per Kephir. DCDuring TALK 16:41, 4 January 2015 (UTC)

Oppose proposal 1

  1. Symbol oppose vote.svg Oppose Having colon (:) after the language name is a natural extension of our category names like "Category:en:Physics". --Dan Polansky (talk) 19:58, 23 September 2014 (UTC)
    But we only do that with language codes, while the Rhymes pages currently use language names. --WikiTiki89 20:19, 23 September 2014 (UTC)

Abstain from proposal 1

  1. Symbol abstain vote.svg Abstain It really makes no difference to me. --WikiTiki89 14:50, 23 September 2014 (UTC)
  2. Symbol abstain vote.svg Abstain Me either. —Aɴɢʀ (talk) 13:25, 4 January 2015 (UTC)

Support proposal 2

  1. Support, though quite weakly, on the grounds that it makes some string processing simpler. The hyphen carries zero entropy; or in plain English, everyone already knows that we are dealing with suffixes, indicating that explicitly is unnecessary. If we ever find ourselves making pages in rhymes namespace which are not rhymes lists, I might change my mind. Keφr 07:55, 9 December 2014 (UTC)
    You mean that Lua code does not need to drop the leading "-"? That is very straightforward for Lua code to do. Is that the reason why we should not prioritize human ease of recognition of what is presented on the user interface? --Dan Polansky (talk) 12:28, 14 December 2014 (UTC)
    For Lua code this is easy, for plain templates less so. Keφr 14:20, 4 January 2015 (UTC)
    Plain templates can call Lua to drop the hyphen (or minus), right? --Dan Polansky (talk) 14:22, 4 January 2015 (UTC)
  2. Support. When you look for rhymes, you know what you mean. And it sometimes happens that the rhyme is the complete word pronunciation (e.g. it), which makes the - meaningless. Lmaltier (talk) 16:30, 4 January 2015 (UTC)
    I think of e.g. "-eɪm" as the regular expression ".*eɪm", where .* also matches an empty string (or think if "*eɪm" if you are used to file name patterns). --Dan Polansky (talk) 22:32, 7 January 2015 (UTC)
    This is not the usual meaning of - for suffixes. Therefore, this might be slightly misleading. But the important point is that it's not needed, it would not help anybody. Lmaltier (talk) 22:38, 7 January 2015 (UTC)
    You are right that the whole word matching the ending is something of an oddity, one which does not happen with morphological suffixes AFAIK. But again, it does not feel like a real problem to me. To your other point: hyphen does help me to immediately recognize what is going on, and I am missing it when I don't see it. So it is not accurate to say it would not help anybody, when it in fact helps at least me. In fact, hyphen is still used in the mainspace: check e.g. name where it says "Rhymes: -eɪm". (It says so now; I cannot rule out a non-consensual change to follow.) The person who originally designed the rhyme pages with hyphen must have felt and perceived the same way as I do. --Dan Polansky (talk) 22:48, 7 January 2015 (UTC)

Oppose proposal 2

  1. Symbol oppose vote.svg Oppose Makes it clear that we're talking about suffixes. This, that and the other (talk) 10:24, 23 September 2014 (UTC)
  2. Symbol oppose vote.svg Oppose What he^ said. --WikiTiki89 14:50, 23 September 2014 (UTC)
  3. Symbol oppose vote.svg Oppose The rhyme pages are organized by what is an auditory analogue of a suffix. Since suffixes are usually denoted with a leading dash (e.g. -ness), using dash in rhyme page names seems natural. --Dan Polansky (talk) 19:58, 23 September 2014 (UTC)
  4. Symbol oppose vote.svg Oppose What they↑ said.​—msh210 (talk) 12:09, 15 October 2014 (UTC)
  5. Symbol oppose vote.svg Oppose Per above. DCDuring TALK 16:43, 4 January 2015 (UTC)

Abstain from proposal 2

  1. Symbol abstain vote.svg Abstain We aren't talking about suffixes. The /eɪm/ of name isn't a suffix. It's a syllable rhyme. But I still don't really care whether that's indicated by a leading hyphen or not. —Aɴɢʀ (talk) 13:27, 4 January 2015 (UTC)
    We are talking about auditory analogue of a suffix, not a morphological suffix. --Dan Polansky (talk) 14:10, 4 January 2015 (UTC)
    But a hyphen is written, not oral. Renard Migrant (talk) 14:13, 4 January 2015 (UTC)
    Yes, hyphen is written, so is IPA. So what? Both the hyphen and IPA are written to indicate what is auditory. The hyphen before the IPA suggests that the IPA is not a complete IPA (of a complete word) but rather IPA missing something at the left. --Dan Polansky (talk) 14:17, 4 January 2015 (UTC)
    To write "The /eɪm/ of name" is misleading; one should write "the /eɪm/ of /neɪm/". --Dan Polansky (talk) 14:24, 4 January 2015 (UTC)
    OK, rather than "suffixes", say "endings". I'm no lexicographer. This, that and the other (talk) 11:34, 7 January 2015 (UTC)
  2. Symbol abstain vote.svg Abstain I agree 100% with Angr. Renard Migrant (talk) 13:51, 4 January 2015 (UTC)


Entries which do not meet CFI to be deleted even if there is a consensus to keep

  • Voting on: making it official policy to delete entries which do not meet WT:CFI to be deleted even if there is a consensus to keep.

Rationale: deletion debates have turned into a matter of personal opinion, whether certain editors like a certain entry, made it themselves, etc. This vote would meet that admins have an obligation to delete entries that do not satisfy the criteria laid out in WT:CFI even if there as a consensus (by which I mean a numerical consensus, by counting the number of votes) to keep the entries. Instead of simply counting up the number of votes, the closing admin should look at the arguments made to see if the entry meets CFI (rather than keep because I made this entry or keep because my mother used this word 20 years ago).

As a result, debates would become about whether an entry meets CFI rather than just about the number of votes an entry gets.

  • Vote starts: 00:01, 24 November 2014 (UTC)
  • Vote ends: 23:59, 23 December 2014 (UTC)
    • Vote extended to 23:59, 30 January 2015 (UTC) --Dan Polansky (talk) 09:50, 20 December 2014 (UTC)


  1. Symbol support vote.svg Support Consensus should reflect CFI. If not, then CFI itself is the problem and it should be modified, not just circumvented whenever people feel like it. —CodeCat 13:28, 24 November 2014 (UTC)
    Then why did User:CodeCat create {{hot word}} on 6 March 2014‎ to label and keep certain words not meeting current CFI, without first changing CFI? --Dan Polansky (talk) 11:23, 14 December 2014 (UTC)
    Why do you ask? —CodeCat 14:38, 14 December 2014 (UTC)
  2. Symbol support vote.svg Support Renard Migrant (talk) 18:04, 24 November 2014 (UTC)
  3. Symbol support vote.svg Support. — Ungoliant (falai) 21:37, 24 November 2014 (UTC)
  4. Symbol support vote.svg Support Agree with CodeCat. I also more or less agree with the opposing comment that it's impossible to implement, but still support in theory. Equinox 21:55, 24 November 2014 (UTC)
  5. Symbol support vote.svg Support It would be nice if arguments in favor of keeping were couched in terms of CFI. CFI can be changed. DCDuring TALK 18:19, 7 December 2014 (UTC)
  6. Symbol support vote.svg Support Consensus should reflect CFI. Leasnam (talk) 10:49, 11 December 2014 (UTC)
    It is the other way around: CFI should be updated to reflect consensus. Since we have not managed to make CFI reflect consensus so far, rigid application of CFI is undesirable. We have plentiful evidence about the history and origin of CFI, and we know that it did not originate by consensus. --Dan Polansky (talk) 09:31, 14 December 2014 (UTC)
    Right, CFI should reflect consensus. —Stephen (Talk) 20:37, 14 December 2014 (UTC)
  7. Symbol support vote.svg Support Votes are great and all, but if we base our entries on whether the beliefs of more individuals say we should keep, this dictionary will end up having lots of unwelcome content. If you know what I mean by that. I believe that entries should only be voted on if there is some way that CFI isn't working too well for the process. That being said, by the way, I still think cult film should be deleted. When I made this entry, I was not used to the site, so I didn't know what an SOP was. Rædi Stædi Yæti {-skriv til mig-} 20:42, 26 December 2014 (UTC)
    I think some of your recent entries come under the classification of "unwelcome content" - e.g. catfucker. And then you have the nerve to say that SoP entries should be removed. The mind boggles. Donnanz (talk) 12:42, 29 December 2014 (UTC)
Single words cannot be SOPs. And if you think this entry should be removed, challenge it in RFV. I never said you couldn't do that, and as this is a wiki, my contributions here are treated the same as everyone else's. Rædi Stædi Yæti {-skriv til mig-} 21:22, 29 December 2014 (UTC)


  1. Symbol oppose vote.svg Oppose Impossible to implement. Requires little or no ambiguity of CFI; CFI will likely forever remain ambiguous and will probably never satisfactorily address every possible case. I continue to believe that RfD discussions should be decided primarily on consensus of the participants, and am disheartened that this proposal could potentially lead to the deletion of a greater number of articles. Purplebackpack89 05:15, 24 November 2014 (UTC)
    I do agree. However, we should keep the CFI rule, but if CFI doesn't have a solution to the entry's specific problem, we should rely on consensus. That is my personal opinion. Rædi Stædi Yæti {-skriv til mig-} 05:26, 27 December 2014 (UTC)
    • Query:
    How often do we get situations where there is consensus to keep a term, but that consensus is in opposition to WT:CFI?
    If there is consensus to keep a roterm, there should presumably be a rationale, something based on Wiktionary norms and policies that backs up this consensus. If CFI does not describe these norms and policies sufficiently, then the error is in the CFI.
    Note: We do not need CFI to be explicit in all details and to cover all cases. That would be ideal, but that just ain't gonna happen in the real world: process documentation never exactly matches reality, that's just a given. That said, CFI can be updated to cover the broader majority of cases, and to leave wiggle room for those cases that it does not cover. The fact that CFI cannot be revised to describe everything is not a valid argument for ignoring it entirely. ‑‑ Eiríkr Útlendi │ Tala við mig 06:41, 24 November 2014 (UTC)
    @Renard Migrant:: How many? This is really a question for you, not I. I know you believe it to be a significant number, and a too-high one, but I don't know what that number. Purplebackpack89 21:24, 3 December 2014 (UTC)
    Of course it comes down to interpretation of CFI. The question I would ask myself is how many entries are kept where there's no interpretation of CFI to justify them. It would be very difficult to talk about numbers. Maybe a couple a week in recent weeks? Renard Migrant (talk) 21:45, 3 December 2014 (UTC)
  2. Symbol oppose vote.svg Oppose We should add various other rules to CFI, namely - translation target when an English term is a SoP but it is a single term in a few foreign languages, Lemming test - when a term is used in certain dictionaries (the list can be agreed on). It still won't cover all situation, like gas station, mobile phone, foreign language, nominative case, lung cancer, etc. where a vote would still be required. Translation target and Lemmings would heavily reduce valuable time spent on RFD's. --Anatoli T. (обсудить/вклад) 06:54, 24 November 2014 (UTC)
    • @Atitarev: It sounds like you're saying that CFI should be updated, in order to make CFI more useful in evaluating RFDs. This sounds like you don't oppose the underlying idea -- that CFI should be used for arbitration, rather than just group agreement without regard for CFI.
    Am I understanding you correctly here? If so, your vote would be support or abstain, no? ‑‑ Eiríkr Útlendi │ Tala við mig 07:59, 24 November 2014 (UTC)
    Yes, until CFI is updated to include the above two, I am opposing. I would change or reconsider, if there are changes to CFI. --Anatoli T. (обсудить/вклад) 08:02, 24 November 2014 (UTC)
    I've always supported the proposal of such a policy (allow words from other major dictionaries). I would oppose it but, I'm not convinced it would be massively unpopular. I'm surprised nobody's proposed it at all in vote form. Renard Migrant (talk) 18:09, 24 November 2014 (UTC)
    Yeah, I've been meaning to get around to it. But if I propose it, that'll automatically be 2-3 oppose votes right there. BTW, what's the answer to Eirikr's question about how often there is a consensus to ignore CFI? Purplebackpack89 19:00, 24 November 2014 (UTC)
  3. Symbol oppose vote.svg Oppose If there is a consensus to keep a word and CFI states that it should be deleted, then CFI must be changed accordingly, because CFI should reflect this consensus. Discussions are useful when intelligent arguments can be exchanged: if reflection is forbidden because CFI must be applied blindly, then discussions are useless. Lmaltier (talk) 21:01, 24 November 2014 (UTC) In other terms, the sequence should not be: 1. delete. 2. improve CFI. 3. restore (this is illogical). but rather: 1. take the keep decision. 2. discuss on how CFI should be improved to reflect this consensus. 3. improve CFI. Lmaltier (talk) 21:18, 24 November 2014 (UTC)
    CFI has a much stronger consensus than a single RFD discussion. So it's not illogical; it would be illogical if the consensus of the few people who participated in the RFD would trump the consensus of the dozens of people who were involved in shaping CFI over the years. —CodeCat 21:34, 24 November 2014 (UTC)
    • Similar to CodeCat's argument, I would caution strongly against assuming that consensus should be taken at face value just because it's consensus. Iff the consensus is based on reasoned argument, and that reasoned argument calls for an outcome in contravention of CFI, then yes, CFI probably needs changing. If, however, the consensus is not backed up by reasoned argument, then this consensus must be ignored in favor of CFI, which at least has been through an extensive vetting process that (presumably) involves reasoned argument and consensus. ‑‑ Eiríkr Útlendi │ Tala við mig 21:59, 24 November 2014 (UTC)
      • Of course, I fully agree with you. Lmaltier (talk) 17:50, 25 November 2014 (UTC)
        • I think that's more of an argument for deleting CFI all together and just going purely with consensus. I mean, how could you possibly update CFI after every deletion debate. And more importantly, why bother? Renard Migrant (talk) 12:02, 28 November 2014 (UTC)
          • There's a happy medium between the two poles you posit. It's called making CFI a guideline. Something that's generally accepted, but need not be followed to the letter. Purplebackpack89 22:29, 3 December 2014 (UTC)
        • Anyway, nothing is perfect, and certainly not CFI. CFI must be improved with time. Lmaltier (talk) 06:50, 8 December 2014 (UTC)
  4. Symbol oppose vote.svg Oppose We can create policies. We can't compel everyone to interpret said policies in precisely the same manner. There will always be cases in which it isn't clear-cut whether or not a term meets CFI because not everyone has the same interpretation of things like "sum of parts." Such cases require a subjective judgment about the term's fitness for inclusion to be made. The RfD process exists so that all Wiktionarians can partake in such determinations, sharing their individual thoughts on the inclusion-worthiness of nominated words, and thus help reach a consensus. Allowing for the outcome of RfD discussions to be overridden at the personal discretion of administrators would be completely contrary to the community-driven nature of this project. -Cloudcuckoolander (talk) 08:55, 26 November 2014 (UTC)
    Allowing for the outcome of RfD discussions to be overridden at the personal discretion of administrators” -- I don't follow you. Where does administrator whim come into the discussion? ‑‑ Eiríkr Útlendi │ Tala við mig 10:03, 26 November 2014 (UTC)
    When it's closed. Purplebackpack89 17:09, 26 November 2014 (UTC)
    "Instead of simply counting up the number of votes, the closing admin should look at the arguments made to see if the entry meets CFI."
    That means that, under this proposal, the closing admin would make a subjective judgment about which arguments hold the most merit, and thus decide whether the entry warrants keeping. But there is no single correct interpretation of CFI (particularly SOP). Two people can look at the same entry and reach differing conclusions about its inclusion-worthiness. And that's why the RfD process allows us to weigh different viewpoints and reach a consensus. Leaving it up to admin whim, in short, would be a disaster. It would be giving the closing admin license to favour arguments with which they agree over arguments with which they disagree, and thus give them the power to impose their own personal personal preferences over community consensus. -Cloudcuckoolander (talk) 22:47, 27 November 2014 (UTC)
    But if the result of RFD is consensus, then how do we know what that consensus is unless someone decides what it is? —CodeCat 23:03, 27 November 2014 (UTC)
    No one needs to decide that consensus exists. It will be objectively apparent. -Cloudcuckoolander (talk) 23:24, 27 November 2014 (UTC)
    Nothing will ever be apparent to Purple unless it is what he wanted. Equinox 02:51, 28 November 2014 (UTC)
    What's consensus is apparent to me, thank you very much. I see no reason why you needed to say it wasn't. This is about CFI, not about me. Purplebackpack89 14:19, 28 November 2014 (UTC)
    Symbol oppose vote.svg Oppose (This is Zeggazo btw). I believe the existing process is fine. There are some words which are very common in blogosphere but have unluckily not been picked up in permanently recorded media. If we allow some grey areas wiktionary will get more of these blogosphere type words. 10:23, 28 November 2014 (UTC)
    I don't think unregistered users are allowed to vote. If I knew the name of the vote I'd look it up. Renard Migrant (talk) 11:44, 28 November 2014 (UTC)
    Indeed they are not (the instructions cannot be understood any other way). Struck. Keφr 09:51, 29 November 2014 (UTC)
    See Wiktionary:Votes/2010-04/Voting policy. --Dan Polansky (talk) 11:47, 29 November 2014 (UTC)
  5. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 22:43, 28 November 2014 (UTC). It must be possible to override CFI on a case-by-case basis, as e.g. for olinguito. The long-standing tradition in RFD of keeping terms for which there is no consensus for deletion should be continued. Translation target should continue to be a consideration for those who feel this is a valid extra-CFI concern, as well as lemmings (keep a possibly sum-of-parts term when certain monolingual dictionaries, not WordNet, include the term; see also the Beer parlour discussion), and set phrase. The CFI as a whole as it is without modification is not supported by consensus, and the principle of consensus should prevail over any statutory document like CFI. That said, CFI should be used as a recommendation (rather than an inviolable rigid rule), with exceptions being justified, and thus should not be entirely ignored when deciding whether to keep an entry. Each argument for keeping should be based on CFI as far as possible. The non-rigid approach I have outlined seems to be implemented in WT:ELE as per WT:ELE#Flexibility, a section that is lacking from CFI: "While the information below may represent some kind of “standard” form, it is not a set of rigid rules." --Dan Polansky (talk) 22:43, 28 November 2014 (UTC)
    If this vote fails, what we oughta do is demote CFI from policy to guideline. I think you're correct that most of the major editors here are dissatisfied with CFI as written. Having the "what's in, what's out" page as policy and not guideline is unusual for a project anyway. If CFI was demoted to guideline, that would allow the overriding you want. Purplebackpack89 02:14, 29 November 2014 (UTC)
    What is a "guideline"? Keφr 19:13, 29 November 2014 (UTC)
    A guideline is one step down from policy. The main difference is that policy has to be followed 100% of the time, but guidelines don't. Purplebackpack89 19:38, 29 November 2014 (UTC)
    I don't think we'll need to 'demote' it. It'll become a lame duck. In fact I don't think any policies will have any weight any more. People will just say if there's no vote forcing me to apply this policy, why bother? Renard Migrant (talk) 22:16, 29 November 2014 (UTC)
    You seem to be taking the de facto, and I the de jure. Purplebackpack89 00:20, 30 November 2014 (UTC)
    Re: "I don't think any policies will have any weight any more.": I don't agree with this all-or-nothing view. CFI is a useful policy and is largely followed, with exceptions being argued on a case-by-case basis. The entries kept despite current CFI are fairly few and are mostly exceptions to WT:CFI#Idiomaticity rather than WT:CFI#Attestation; have a look e.g. at google:"translation target" site:en.wiktionary.org and google:"set phrase" site:en.wiktionary.org to see how many they are. "Sum of parts" is still a valid reason for nomination for RFD, just that multiple editors are in the habit of examining redeeming qualities of terms so nominated. CFI still does a useful service as a policy applied with a certain, fairly low, flexibility. --Dan Polansky (talk) 09:43, 30 November 2014 (UTC)
    There's a term for a policy with flexibility. It's called a guideline. And CFI should be one, preferably one with SOP stripped from it. The problem with CFI being policy is not only the lack of flexibility afforded, but the need for it to apply universally. I think it's clear there are blind spots in CFI. If CFI were a guideline, that wouldn't be as much of an issue, and we could address the blind spots as they come up with routine consensus. Purplebackpack89 21:51, 3 December 2014 (UTC)
    If there is truly "routine consensus" then you ought to have no problem getting it voted in as policy! Equinox 22:08, 3 December 2014 (UTC)
    You seem to be arguing that I posit that WP:IDIOMWT:IDIOM be merged into WP:CFIWT:CFI. There's no reason for CFI to mention every little thing that survived an RfD. Far better to have it be a guideline with gray areas that can just be addressed when they come up. Purplebackpack89 22:21, 3 December 2014 (UTC)
    What is "WP:IDIOM" and "WP:CFI"? Keφr 22:33, 3 December 2014 (UTC)
  6. Symbol oppose vote.svg Oppose The situation does not arise. If there's a consensus to keep, then there's a consensus that the entry does meet WT:CFI. CFI has more than one possible interpretation; it's not objective, nor should it be. —Aɴɢʀ (talk) 07:32, 29 November 2014 (UTC)
    Re: "If there's a consensus to keep, then there's a consensus that the entry does meet WT:CFI": Not really. If I vote based on translation target consideration and I know that it is not part of WT:CFI, then my vote does not indicate that I want to keep the entry via CFI. It is fair to say that translation target consideration is not part of current CFI. --Dan Polansky (talk) 08:25, 29 November 2014 (UTC)
    Yeah this is clearly false; I could vote to delete an entry based on a prejudice because of who created the entry; would you argue that that's part of CFI? If so where is it? Renard Migrant (talk) 13:17, 29 November 2014 (UTC)
    If you wanna talk about stuff like that, look up how often "redundant" and "redundancy" appear in CFI. Purplebackpack89 19:40, 29 November 2014 (UTC)
    Why? Renard Migrant (talk) 22:16, 29 November 2014 (UTC)
    Because neither word is used in CFI. There are a number of legitimate arguments that you, I, or anyone would agree to that are not explicitly spelled out in CFI Purplebackpack89 00:20, 30 November 2014 (UTC)
    Indeed. In fact CFI says nothing about content being correct. Renard Migrant (talk) 12:26, 30 November 2014 (UTC)
    Maybe I missed some sarcasm, but I think "correctness" is covered by WT:CFI#Attestation. Keφr 12:49, 30 November 2014 (UTC)
    I suppose it is. Renard Migrant (talk) 13:06, 30 November 2014 (UTC)
    Redundancy and correctness are different issues Purplebackpack89 16:01, 30 November 2014 (UTC)
    I fully agree (in case that wasn't clear). Accord to CFI, there's no reason not to have two identical meanings, because if one meets CFI, so does the other. Renard Migrant (talk) 16:49, 30 November 2014 (UTC)
  7. Symbol oppose vote.svg Oppose I can't think of any good reason to support this proposal. The main problem with CFI is that the rules are overinterpreted or misinterpreted by beady-eyed would-be deletionists. There is nothing in CFI which specifically says that SoP entries should be deleted. Yet birthday present was deleted and Christmas present survived for devious reasons. I know common sense should prevail, thus red dress doesn't qualify, but little black dress does, and little black number has been overlooked. One problem I find is with translation targets, especially from languages where compound words are commonplace: I was trying to find a home for barnesoldat (child soldier) on the English side, and had to settle for an entry under soldier and hope that it would be seen there. So I think provision should be made in CFI for translation targets. Donnanz (talk) 11:50, 8 December 2014 (UTC)
    Actually, [[Christmas present]] was deleted in the nominated sense. That another sense was considered idiomatic is a separate matter. Keφr 12:08, 8 December 2014 (UTC)
    I think that using soldier for the translation barnesoldat was the right place. I fully agree with you, except for using translation target as a criterion in CFI, which would make the objective of the project very confusing (e.g. thousands of little ... pages would be created). The only criterion should be does this belong to the vocabulary of the language?. This would be a clear and simple basic principle. Lmaltier (talk) 22:26, 10 December 2014 (UTC)
    I am happy for you agreeing with me, but why are you replying to me right here? Keφr 18:10, 11 December 2014 (UTC)
    I think Lmaltier's comment was directed at me. Donnanz (talk) 18:42, 11 December 2014 (UTC)
    I agree. That's what paper dictionaries use, limited by the amount of paper they have. Purplebackpack89 23:12, 10 December 2014 (UTC)
    Paper dictionaries are limited by what they can squeeze into one volume. The more comprehensive dictionaries are published in more than one volume, and are rather expensive I imagine. The Oxford Dictionary of English has 2088 pages; my Duden Deutsches Universalwörterbuch has 2016 pages and is falling apart due to poor binding. An online dictionary such as Wiktionary doesn't have this restriction with modern technology, and can be super-massive and cater for translation targets. It may not be as bad as you fear, Lmaltier. Donnanz (talk) 09:45, 11 December 2014 (UTC)
    Of course, it would be feasible, I agree. But it would be confusing: users of a dictionary don't look for translations targets, they look for a term of a language. For the same reason, I would group all phrasebook entries in topical appendices and remove them for the mainspace, but I would add attested words from fictional universes to the mainspace from appendices (with special rules for proper nouns, of course). Lmaltier (talk) 21:29, 11 December 2014 (UTC)
    Kindersoldat appears in Duden online, but not my copy; this may prove my point about online dictionaries, they can be updated more quickly than paper dictionaries anyway - in fact paper dictionaries may be phased out in the future, who knows?. Donnanz (talk) 10:15, 11 December 2014 (UTC)
    Paper dictionaries are likely to be used less and less, but they keep real advantages: 1. The pleasure of paper book pages. 2. They are available at any moment, no need to start a computer. 3. They must be bought once, but consulting them is 100% free. We are not bought, but users consulting us spend some money at each consultation (think to power they use). Lmaltier (talk) 21:36, 11 December 2014 (UTC)
    Paper dictionaries have a lease on life until we adopt the lemming principle. As long as there are words print dictionaries have that we don't, people will have to buy them rather than get those words here for free. Purplebackpack89 21:50, 11 December 2014 (UTC)
  8. Symbol oppose vote.svg Oppose —Stephen (Talk) 03:06, 9 December 2014 (UTC)
    Stephen: Any particular reasons? Keφr 11:29, 14 December 2014 (UTC)
    CFI has too many flaws. It was written and edited by inexperienced amateur lexicographers. If we start to attract editors with more experience in lexicography, I don’t think they should be hobbled by earlier editors with little knowledge of the field. CFI can be edited and rewritten, but it seems to be rather difficult to make any substantive changes to it. Perhaps if there is a consensus to keep some terms, it will be an incentive to improve CFI. —Stephen (Talk) 20:34, 14 December 2014 (UTC)
    Though a few users argued that habitually ignoring CFI at the whim of circumstance will disincentivise improving CFI (as in "why bother conducting bureaucracy over updating something that is ignored on a daily basis anyway?"). Your comment on that? Keφr 21:12, 14 December 2014 (UTC)
    I think it’s nonsense. The difficulty in getting enough agreement to improve CFI, coupled with the problem of inexperienced lexicographers trying to come up with improvements, is what disincentivizes improving CFI. —Stephen (Talk) 23:06, 14 December 2014 (UTC)
    How much incentive we have to fix CFI doesn't override my belief that CFI is broken beyond repair. There's no way it's ever going to be able to mention every reason we've used to keep an article. This is why it is foolish for CFI to be policy. Purplebackpack89 23:35, 14 December 2014 (UTC)
    Nonsense. It's true that WT:CFI can never specify every case, but it doesn't have to, as long as it doesn't claim to. Some things can be explicitly included by policy, and some things can be explicitly excluded by policy, and some things can be (either explicitly or implicitly) left open by policy. In fact, there are already some cases where WT:CFI explicitly doesn't specify whether or not they can be included: see Wiktionary:Criteria for inclusion#Names of specific entities. —RuakhTALK 05:08, 15 December 2014 (UTC)
    Word. Agree absolutely with Ruakh. --Dan Polansky (talk) 09:11, 20 December 2014 (UTC)
    Stephen G. Brown, if you think that users on this project are not competent enough to enact sensible criteria for inclusion, then you probably have no reason to believe they can make sensible decisions by "consensus" in individual deletion discussions either. You might as well give up on this project entirely. It is not just CFI that is written by amateurs: everything is written by amateurs, a fact that is not going to change very soon. Those "editors with more experience in lexicography" you speak of are not going to fall from the sky — but when they do come, I expect they will provide some input on how CFI should be changed, which surely will not be ignored. For the time being, I can stick to rules written by amateurs.
    And I even disagree on the "inexperienced" part: Category:Archived discussions contains over ten thousand pages of RFVs and RFDs. I assume at least some still-active regulars have witnessed or participated in a large part of these discussions. There is plenty of precedent on which to build something. If only someone cared enough. Keφr 18:23, 26 December 2014 (UTC)
    You make a lot of assumptions about what I think, and jump to a lot of bad conclusions about what I believe. As for what I should do, I think I am a better judge of what I should do than you, which may account for the fact that I have not sought your opinion in the matter. As for what you can do, I’m sure you know best and I wouldn’t have it any other way. And as to the "inexperienced" part, I was talking about a different kind of experience, not experience in RFVs and RFDs. —Stephen (Talk) 01:48, 27 December 2014 (UTC)
    Re: "...habitually ignoring CFI...": We are not ignoring CFI, since, in RFD, we are taking it into consideration, albeit not as the ultimate arbiter allowing no exceptions; in RFV, exceptions to CFI are very rare. Multiple of us override CFI in RFD not on a whim but rather in a reasoned manner, applying common sense and lexicographical sense of what is good for a multilingual dictionary with a broad range of international readership with various backgrounds, needs, and language skills. Furthermore, despite e.g. "translation target" being mentioned by RFD voters for past multiple years, that did not stop us from improving CFI. One of the latest substantive improvements even made CFI more strict, including less: Wiktionary:Votes/pl-2014-03/CFI: Removing usage in a well-known work 3. --Dan Polansky (talk) 09:11, 20 December 2014 (UTC)
  9. Symbol oppose vote.svg Oppose per Stephen's arguments, which I agree with. --Neskaya sprecan? 16:47, 8 January 2015 (UTC)


  1. I abstain for reasons I already stated in the linked BP discussion. Keφr 21:40, 24 November 2014 (UTC)
  2. Symbol abstain vote.svg Abstain --Romanophile (talk) 18:04, 26 November 2014 (UTC)
  3. Symbol abstain vote.svg Abstain We've already had enough problems with admins enforcing their unilateral interpretations of the CFI by listing words at WT:RFV and making up rules that the citations supposedly have to meet. The proposal here seems to be that even admins who would prefer to make decisions consensually, will instead be expected to make them unilaterally. I definitely recognize the problem that this proposal is trying to address, and I agree with most of the "support" voters' comments — if there is a consensus that something should be kept, then we should fix WT:CFI rather than flout it — but I just can't bring myself to support the proposal as written. —RuakhTALK 22:01, 14 December 2014 (UTC)
    @Ruakh: any specific case comes to your mind? Keφr 18:24, 26 December 2014 (UTC)
    One class of examples is sub-word morphemes. WT:CFI says only that they are acceptable, with no details, but that has not stopped people from crediting it with surprisingly detailed rules. (See Talk:-os for one example.) —RuakhTALK 04:29, 27 December 2014 (UTC)


Adding RFEs to all lemma entries where etymology is missing



  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 09:03, 14 December 2014 (UTC) I have never seen substantive numbers of etymologies added by people filling in RFE requests. The people whom I saw add larger numbers of etymologies did not go by requests; similarly, the people whom I saw add larger numbers of Latin lemma entries did not go by requests. The presence of RFE in every lemma entry may possibly slightly increase the rate of addition, but only at the cost of flooding Wiktionary mainspace with information-free etymology sections for many years.

    An editor mentioned that placing requests worked well for inflection. I do not know whether this is true, but even if it is true, we have to realize that, for native speakers, inflection is largely trivial and easy-to-fill, whereas etymology requires research in sources unless it is folk etymology.

    As for evidence, I have seen presented no evidence to support claims about efficacy of placing these sorts of request boxes to pages. Such evidence could be collected from dumps. --Dan Polansky (talk) 09:03, 14 December 2014 (UTC)

  2. Symbol oppose vote.svg Oppose I always try to add etymology where I can, but this info is not always available, or incomplete. Entering the etymology of compound words can be a lot easier. The mass addition of RFE to entries tends to make them look untidy. Donnanz (talk) 09:15, 14 December 2014 (UTC)
  3. Symbol oppose vote.svg Oppose, but I wouldn't be opposed to lemmata missing an etymology being placed in a hidden category (according to language, e.g. "Category:English lemmata with no etymology section"). This, that and the other (talk) 06:03, 18 December 2014 (UTC)
  4. Symbol oppose vote.svg Oppose, but I agree that a hidden category is fine. —Mr. Granger (talkcontribs) 15:17, 18 December 2014 (UTC)
  5. Symbol oppose vote.svg Oppose, some of the other language Wiktionaries have such requests for every section, but it hasn't (as far as I am aware) encouraged lots of editors to join and add the missing information. Kaixinguo (talk) 15:35, 10 January 2015 (UTC)



Making simplified Chinese soft-redirect to traditional Chinese


  1. Symbol support vote.svg Support. Altthough simplified is the standard in PRC and Singapore, I vote for centralization of Chinese entries. It can be one or the other, not both. --Anatoli T. (обсудить/вклад) 04:27, 26 December 2014 (UTC)
  2. Symbol support vote.svg Support Wyang (talk) 22:11, 27 December 2014 (UTC)
  3. Symbol support vote.svg Support Centralisation of data will greatly facilitate the work of editors and the parsing of chinese entries for reuse of wiktionary data.
    For the problem of readers only interested in simplified being invaded by traditionnal in examples, traditionnal will be dispalyed anyway in entries which are both simplified and traditionnal. Keeping Simplified and traditionnal separated don't solve this problem and will create inconsistency in the display of chinese entries.Meihouwang (talk) 09:17, 28 December 2014 (UTC)
    There is a lot of opposition on this vote. Maybe we should instead do a vote on centralising data in traditional page and displaying definitions in simplified page with a template. This way we will get most of the opposing people on our side. I read some people said that it is not technicaly possible but I have already parsed wiktionary data to use in a chinese dictionnary that I am programming. I was able to store definitions in my database sorted by Simplified/Traditionnal/Pinyin using {{zh-hanzi-box}} to know in which Simp/Trad pair the definitions should be stored. Character with several Simp/Trad pair have several {{zh-hanzi-box}} (At least in the entries I edited). I think displaying definitions from traditionnal page on simplified page should be less complicated than this. But I have no experience with Wiktionary scripting so I might be wrong. Meihouwang (talk) 16:09, 9 January 2015 (UTC)
  4. Symbol support vote.svg Support Avoids duplication of content, which is a scourge of this dictionary (especially for non-English languages). Ideally what we would do is automagically replicate the contents of the traditional entry at the simplified page, with all traditional forms converted to simplified. But that is not technically feasible right now. This, that and the other (talk) 11:32, 7 January 2015 (UTC)
  5. Symbol support vote.svg Support DTLHS (talk) 17:21, 8 January 2015 (UTC)
  6. Symbol support vote.svg Support Reducing duplication is good, and makes Wiktionary easier to manage. I call upon the opposers to be more constructive, and propose an alternative idea that would reduce the workload of managing Chinese entries in another way. Voting oppose to solutions doesn't make the problem go away. —CodeCat 17:24, 8 January 2015 (UTC)
    An alternative idea that would reduce the workload has been put forward and its is to make traditional Chinese make soft-redirect to simplified. Why are people to fast to dismiss that? It has been claimed that the other way is easier to maintain for contributors but how much more work is it really to make it the other way? Simplified is used far more than traditional so if we can make the simplified form the lemma that must be the right thing to do. Kinamand (talk) 18:40, 8 January 2015 (UTC)
  7. Symbol support vote.svg Support --Vahag (talk) 00:24, 12 January 2015 (UTC)
  8. Symbol support vote.svg Support --Ivan Štambuk (talk) 01:42, 12 January 2015 (UTC)
  9. Symbol support vote.svg Support I do not agree that a soft direct makes it look like an implicit claim that one of the two is more correct. Everyone knows that the traditional form came first. It is true that there is no one-to-one correspondence between simplified and traditional, but it is reasonably close. Simplified = Traditional (hòu, "after") and (hòu, "queen"). The Chinese and Japanese characters (and their categorization) are extremely complex, and it actually requires more knowledge to make use of the Wiktionary offerings of these languages. Splitting into and will be a relative minor hurdle for users. If we do not use redirects, simplified becomes doubly complex, since it has to define both meanings (and sometimes different pronunciations), as well as different etymologies. —Stephen (Talk) 03:48, 13 January 2015 (UTC)
    Good example, Stephen! I have just made a split of two etymologies for and . Maintaining in sync complicated entries like is quite complicated. Editors have been focussing on one or the other form. The unified approach allows to treat both forms equally, without making one form or the other better, literally. That's the approach taken by the majority of electronic or book dictionaries. It's impossible to centralise the contents while having duplicate entries. Entries get out of sync momentarily. Eventually, it may be possible to include the contents of the traditional entry in the simplified one. --Anatoli T. (обсудить/вклад) 04:40, 13 January 2015 (UTC)
    Stephen mentioned and because of their non-trivial simplified/traditional conversions. They needed attention, so I fixed them. For relative complexity I meant , which now has a list of derivations in both trad. and simpl. forms, previously only in simplified form in only. The traditional entry didn't have derivations. Now it has. Note that the entry has usage examples and derived forms IN BOTH TRADITIONAL AND SIMPLIFIED. This is how the Chinese entries are meant to look with the new structure. No discrimination, the only disadvantage is having to click through from to traditional to simplified. There is no problem with sound or many other English or Chinese entries with multiple etymologies. However, there are problems with various revisions of color and colour. One thing that commonly quickly makes them out of sync is translation tables or lack thereof. Template {{trans-see}} is used for that to avoid duplication of contents. Yes, one can copy/paste from one another but how long will it be before they get out of sync? {{zh-see}} is meant to link to the Chinese entry, which contains info in both character sets (unlike Serbo-Croatian, for example, which only display the other form in the header). We didn't create the rationale for this vote but the change is not meant to make one character set better than the other, no. It's all about centralising the contents. --Anatoli T. (обсудить/вклад) 21:48, 13 January 2015 (UTC)
    As the reader can see in this revision of 恶, section Mandarin, there were derived terms in simplied script before Atitarev removed them (diff); his solution is to have a mixed table of compounds as in 惡#Chinese, where the list now mixes both simplified and traditional. The first four items look like this:
    The reader who wants to only deal with simplified script will no longer have the option, and the same is true of the traditional script; both scripts will be presented at the same time in example sentences and derived term lists.
    The reason I do not undo those non-consensual changes by Atitarev and others is above all that I do not want to get into a revert war, and that I prefer the civilized methods of government exemplified by this vote. --Dan Polansky (talk) 22:12, 13 January 2015 (UTC)
    Symbol support vote.svg Support. Traditional characteristics contain more meaningful information for the words or terms of the culture. This is what our dictionary really needs.--Wildcursive (talk) 15:05, 18 January 2015 (UTC)
    Vote struck as invalid per policy. Keφr 21:07, 18 January 2015 (UTC)
  10. Symbol support vote.svg Support Whether it's a preference of one script over another is simply one's value judgment at work. To me, if it help improve editing, that's all that matters. JamesjiaoTC 22:47, 19 January 2015 (UTC)


Oppose. Bad idea! 04:09, 26 December 2014 (UTC)
Anonymous accounts can comment but they can't vote. --Anatoli T. (обсудить/вклад) 04:27, 26 December 2014 (UTC)
  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 10:01, 26 December 2014 (UTC) Making simplified Chinese entries mere soft redirects (featuring no definitions) would create a significant inconvenience for those readers who are interested in simplified Chinese writing and not in traditional Chinese writing. Simplified Chinese is currently the prevalent form in the mainland China as per W:Simplified Chinese characters. Having definitions in both simplified and traditional Chinese entries, as has been English Wiktionary practice for many years, creates duplication of definitions, which I admit to be a disadvantage for maintenance; it is a cost of making the dictionary easy to use for the readers. Those editors who want to focus e.g. only on traditional Chinese entries should be allowed to do so, without being chastised for not creating simplified Chinese entries at the same time. As an example of similar practice, we now have definitions in both Latin and Cyrillic Serbo-Croatian entries, which is a duplication (mačka, мачка). As a further inconvenience of soft-redirects as envisioned at Wiktionary:Beer_parlour/2014/December#New_changes_to_Chinese_entries in paragraph "The problem is not about having or not wanting to create ...", usage examples would newly feature both simplified and traditional Chinese (probably along with Pinyin), becoming even more busy with information that the reader is not interested in: the reader with the interest in simplified Chinese does not necessarily want to see traditional Chinese. --Dan Polansky (talk) 10:12, 26 December 2014 (UTC)
    Don't forget Malay entry versions in both Jawi and Rumi. (I'm not voting, though; but if I were forced to do so, I could abstain, right?) --Lo Ximiendo (talk) 10:26, 26 December 2014 (UTC)
    On the other hand, all those simplified Chinese edits are clogging up the Short pages. --Lo Ximiendo (talk) 17:20, 8 January 2015 (UTC)
    (Oppose vote retracted due to not having enough contributions here for it to be valid. I use Wiktionary very often, but apparently I don’t contribute enough…) A redirect, whether soft or hard, from simplified to traditional or vice versa, looks like an implicit claim that one of the two is more correct than the other. This happens regardless of whether making that claim is intentional or not. Since it is not the case that either of the two types of character is more correct than the other, it seems clear to me that redirecting from one to the other is a bad idea. In addition, as stated above, a soft redirect like this (as opposed to a hard redirect) causes significant inconvenience to anyone who commonly looks up words in simplified Chinese. The analogy to Latin vs. Cyrillic Serbo‐Croatian entries is an excellent point too. With regard to the point about maintaining separate entries being too much work, I have an alternative suggestion which, if properly thought through and implemented, could have the same effect of reducing the workload without the major disadvantages of a redirect: For the information that would otherwise be duplicated (which in some cases is an entire entry, in other cases only part of an entry), move that information to a template that is transcluded onto the pages that would otherwise duplicate that information. That way the relevant information is visible everywhere it should be, and only needs maintaining from one location. MTC (talk) 09:06, 2 January 2015 (UTC)
    I am afraid your vote is invalid per policy: not enough edits in content namespaces. Keφr 18:43, 12 January 2015 (UTC)
    Ah, that’s a shame. In that case, I have re‐indented it so that the comment is still there while the votes are counted correctly. MTC (talk) 13:40, 13 January 2015 (UTC)
  2. Symbol oppose vote.svg Oppose as far as I know there is no one-to-one correspondence between simplified and traditional Chinese, i. e. one simplified term may map to multiple traditional terms. This makes the proposal infeasible because readers won't be able to guess the correct form if they're unfamiliar with traditional Chinese, as residents of the PRC and Singapore tend to be. -- Liliana 12:36, 4 January 2015 (UTC)
  3. Symbol oppose vote.svg Oppose Since simplified is use far more often than traditional I believe that people using Wiktionary will find it odd and backward with redirects to traditional Chinese. The argument is that it is easier for people writing templates to use the traditional form as lemma but how much extra work is it really to do it with simplified as lemma? Kinamand (talk) 09:22, 8 January 2015 (UTC)
  4. Symbol oppose vote.svg Oppose, though not strongly. Each should have its own entry explaining the characteristics unique to it. bd2412 T 16:54, 8 January 2015 (UTC)
  5. Symbol oppose vote.svg Oppose (strongly) When a page is correct and helpful to readers, its contents should never be removed, even to avoid replication. This should be a strong principle of the project. One of the reasons is that most readers want to find what they look for immediately (statistics show that each additional click needed makes the probability of a donation to the Foundation 30% less). Another reason is neutrality: as both writing styles are used, they must be addressed the same way. A third reason is that it would tend to discourage editors preferring simplified characters, and fewer editors is something bad for the project. Soft redirects might be used as a first step, but it must be allowed to convert these soft redirects to full pages. @CodeCat: an alternative idea that would reduce the workload of managing Chinese entries: allow editors to contribute to the pages they wish. This way, there will be more editors, making it easier to make the project more complete. Anyway, strictly speaking, there is no workload, everybody contributes as much as they wish, not more, and we are not in a hurry. Lmaltier (talk) 22:40, 10 January 2015 (UTC) I see Splitting 后 into 後 and 后 will be a relative minor hurdle for users.. But priority must be given to users, not to editors. Slowly but surely, this dictionary could become the perfect dictionary for users. Lmaltier (talk) 19:20, 13 January 2015 (UTC)
    Symbol oppose vote.svg Oppose Although simplified Chinese is widely used, I don't think traditional Chinese should be redirected to it unconditionally, and the opposite direction of redirection is a little confusing. "Who-redirect-to-who" problem is always a controversial issue, and I think that it can be determined by who create the entry first. If it is created with the title in traditional Chinese, the later simplified Chinese version should redirect to the former entry (if the meaning of the word is same), and vice versa.--Snowkylin (talk) 14:34, 16 January 2015 (UTC)
    Unfortunately, your vote is invalid per the first two points of our voting policy. See at the top of WT:VOTE. --Vahag (talk) 14:52, 16 January 2015 (UTC)
    Oh, I just find that minutes ago, my fault. Edit count is not universal, what a pity :-( --Snowkylin (talk) 14:58, 16 January 2015 (UTC)
    You can't vote in China, you can't vote in Wiktionary. Poor disenfranchised fellow :-( --Vahag (talk) 15:10, 16 January 2015 (UTC)
    The opinion that citizen in China can't vote is quite incorrect, just like the opinion that users in English Wiktionary can vote. I do not know much about English Wiktionary, and maybe you do not know much about China either, seems that it's a tie game. :-)--Snowkylin (talk) 08:53, 17 January 2015 (UTC)
    I hear you, man. I too was born in a communist country. Western liberal media misrepresents our vibrant democracies. --Vahag (talk) 09:29, 17 January 2015 (UTC)
    Symbol oppose vote.svg Oppose, the same as above. --LNDDYL (talk) 06:44, 17 January 2015 (UTC)
    I'm afraid your vote doesn't count per voting policy #2 (you need at least 50 edits by the start time of the vote). --Vahag (talk) 09:29, 17 January 2015 (UTC)
  6. Oppose. Keφr 10:41, 18 January 2015 (UTC)
    @Kephir: Could you explain your reasons, please? As a programmer, how would make (a rather trivial - single etymology, no variant pronunciations) entry 笔#Chinese to have the same information as 筆#Chinese without duplicating the contents? --Anatoli T. (обсудить/вклад) 03:56, 19 January 2015 (UTC)
    I would duplicate the contents. I simply find this preferable to the alternative. Despite all reassurances to the contrary, this obviously will create a preference for one orthography over the other. In itself, it might not necessarily be a problem. But given that (as I am told) there is no one-to-one correspondence between the two, this will necessitate creating some kind of disambiguation cluttering up entries, which are cluttered enough already. Chinese entries are already very confusing to read with all their nonstandard L3s and content splits between Translingual, Chinese and topolect L2, and I believe this proposal will only add more to the confusion for little benefit. And never call me a programmer. Keφr 12:00, 19 January 2015 (UTC)
    I'm sorry if "programmer" was an offence to you. It wasn't meant to be. --Anatoli T. (обсудить/вклад) 13:19, 19 January 2015 (UTC)


  1. Symbol abstain vote.svg Abstain Byfserag (talk) 22:18, 18 January 2015 (UTC)
    You are not eligible to vote anyway. You might as well not bothered. Keφr 12:01, 19 January 2015 (UTC)
    Your vote has been struck out as invalid as you have not yet made a single contribution to this wiki. JamesjiaoTC 22:49, 19 January 2015 (UTC)
  2. Symbol abstain vote.svg Abstain until there is solution for some problems of this action. Firstly, characters who are both simplified and traditional need to have another format. Secondly, characters who are neither simplified nor traditional, but a varients of another character instead, would have to be considered also. Thirdly, some Japanese kanji actually use the simplified form of a character, making the derived terms section troubling. Fourthly, one simplified character may correspond to two traiditional character, and a short definitional would be required for them to be distinguishable. Including definition would make the entry almost same as before. --kc_kennylau (talk) 07:35, 21 January 2015 (UTC)


User:Type56bot for bot status

  • Vote started: 00:19, 28 December 2014 (UTC)
  • Vote ends: 23:59, 4 January 2015 (UTC)
  • Discussion:
    Wikt rei-artur3.svg [1] where someone explained they were blocking me
    Wikt rei-artur3.svg User talk:Type56op9 where I was told to slow down
    Wikt rei-artur3.svg [2] where people show their negative feelings about the bot.



  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk). Posting oppose to nominally have the vote running. If people post support, I can switch to abstain or even support. The nominator is a recent incarnation of User:Wonderfool, a noted mixture of a good editor and a troublemaker; I am not sure we want to grant bot flag to a user whose behavior shows occasional bouts of troublemaking. --Dan Polansky (talk) 11:45, 4 January 2015 (UTC)
  2. Symbol oppose vote.svg Oppose I'd be more comfortable if the user would simply work inside the usual rate limits rather than have a bot flag-- bots can make a lot of trouble to clean up. --Neskaya sprecan? 16:44, 8 January 2015 (UTC)
  3. Symbol oppose vote.svg Oppose, still loads of Dawnraybot entries that need fixing years after it ran. Renard Migrant (talk) 16:48, 8 January 2015 (UTC)



  • Fails: 0:3:0 (support:oppose:abstain). --Dan Polansky (talk) 16:20, 10 January 2015 (UTC)

Recently ended votes

Votes that have recently ended, to be ultimately moved to /Timeline:

Proposed votes

The following are proposals for new votes, excluding nominations, such that the proposer of the vote prefers that the vote is written collaboratively, or such that the vote appears to require substantial revision. If you have not created a passing vote yet, it is recommended that you use this section and actively solicit feedback by linking to your proposal in discussion; your vote may have a better chance of passing if it is first reviewed.

Votes may linger here indefinitely. If changes in policy make a proposal irrelevant, the voting page will be requested for deletion. On the other hand, you do not have to be the creator to initiate one of the votes below. Place any votes with a live start date in the section above at least a few days before that start date arrives.

Votes intended to be written collaboratively or substantially revised: