Open main menu

Wiktionary β


(Redirected from Wiktionary:VOTE)

Wiktionary > Votes

Votes formalize and document the consensus-building process and the decisions that the community makes. This page displays the full contents of recent, current and planned votes. Edit Wiktionary:Votes/Active to add new votes and remove old ones. Finished votes are added to Wiktionary:Votes/Timeline, an organized archive of previous votes and their results, sorted by the vote end date.

Policy and help pages, respectively: Wiktionary:Voting policy (including who is eligible to vote) and Help:Creating a vote.

See also Wiktionary:Votes/ for an automatically generated, less organized list of votes.

{{Wiktionary:Votes/2017-11/Title of vote}}

{{Wiktionary:Votes/pl-2017-11/Title of vote}}

Note: add to this page and WT:A.
{{Wiktionary:Votes/sy-2017-11/User: for admin}}

Note: add to this page and WT:B.
{{Wiktionary:Votes/bc-2017-11/User: for bureaucrat}}

Note: add to this page and WT:C.
{{Wiktionary:Votes/cu-2017-11/User: for checkuser}}

{{Wiktionary:Votes/bt-2017-11/User: for bot status}}


Admins, please periodically check for orphan votes at Wiktionary:Votes/

Look for votes and voting templates, including templates for creation of new votes:

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

Current and new votes

Planned, running, and recent votes [edit this list]
(see also: timeline, policy)
Ends Title Status/Votes
Oct 19 Rename categories no consensus
Nov 1 User:Chuck Entz for checkuser passed
Nov 28 Templatizing topical categories in the mainspace 2 24 (13 people)
Dec 11 Desysopping CodeCat aka Rua  3  12  5
Dec 18 Placing Wikidata ID in sense ID of proper nouns starts: Nov 19
Jan 20 Restricting Thesaurus to English starts: Nov 22
(=6) [Wiktionary:Table of votes] (=99)

Rename categories

Voting on:

  1. Editing a portion of Wiktionary:Categorization with revised rules as described below.
  2. Renaming all categories that are managed by {{topic cat}}, by using names that follow the revised rules.
  3. Disallowing any categories whose names use language codes (such as Category:map-pro:Dogs).

This is a large project, so this vote will start in two four weeks and then it will end in two months.

Labels and categories affected by this project as of July 24, 2017:

Remove this text from the introduction of Wiktionary:Categorization:

All topical categories begin with a capital letter: there is "Category:Foods" rather than "Category:foods". However, the language-specific prefix such as "fr" in "Category:fr:Foods" is in lowercase.

Remove this whole section from Wiktionary:Categorization:


Where useful, words are categorized by topic such as "Animals" or "Chemistry". The root of topical categories is Category:All topics. This root category contains only some major subcategories, such as Category:Communication or Category:Sciences; further categories on a more fine-grained level such as Category:Horses are located somewhere else, deeper in the subcategory tree. There is also Category:List of topics, which lists all topics alphabetically no matter where in the category tree they are located.

Each name of a topical category refers to the objects or meanings referred to by words that are members of the category; the name does not refer to the member words themselves. Thus, there is "Category:Chemistry" rather than "Category:Chemical terminology" or "Category:Chemical terms", or there is "Category:Animals" rather than "Category:Animal names". In other words, the names of topical categories denote what the terms are about, not what they are.

Each name of a topical category has a prefix that indicates the language of the terms belonging to the category. Thus, the English category for horses is Category:en:Horses, while the Japanese one is Category:ja:Horses. The prefix consists of the language code followed by a colon.

Names and subcategory structures of categories should be matched between languages. Thus, if Category:Horses is a subcategory of Category:Equids, then also Category:en:Horses should be a subcategory of Category:en:Equids. If there exists the category Category:fr:Cryptozoology, there should also exists the category Category:Cryptozoology.

The subcategory structure of topical categories is technically maintained in "topic cat parents", such as Template:topic cat parents/Social sciences. This subpage tells the template {{topic cat}} what the parents of the topical category are, regardless of the language. This technique ensures consistent categorization across languages, guaranteeing the matching mentioned in the previous paragraph.

"Names" are proper nouns, and are categorized by part of speech: Category:Japanese proper nouns

Add this section in Wiktionary:Categorization and rename categories accordingly:

Semantic categories

Semantic categories are about the terms' referents rather than the terms themselves. Their names must describe exactly what the categories contain, as normal English text. Use any of these five types of category names:

Don't add etymological derivations in the "[language] terms relating to [...]" categories, unless their meaning also relates to the thing in question. Examples:

Regulations concerning place name categories:

  • Use this naming format for place names: [language] names of [...] [in/of] [...]. Use "towns", "cities", "counties" or another type of place name as applicable.
    (Category:English names of counties in Kansas, USA, Category:English names of municipalities in São Paulo, Brazil...)
  • Always mention the country name where applicable.
  • When the country is "United States of America", use "USA".
  • The use of "in" or "of" before the country name should reflect existing consensus.
  • Always mention the name of major subdivisions ("Kansas, USA" instead of just "USA"), where applicable.

All semantic categories start with the language name, and are placed in a category with same title, except without the language and with "by language" included at the end. This way, all different-language versions of the same category are kept together. Examples:

(Note: The new policy text ends here. All content below is just for voting purposes, including a comparison between old and new category names, and the voting rationale below.)

Comparison between old and new names:

  1. [language] [...]s
  2. [language] names of [...]
  3. [language] terms for [...]
  4. [language] terms relating to [...]
  5. [language] technical terms of [...]

Comparison between old and new names (place names):

Rationale 1 (clarity of the name):

A language code followed by a single word (like Category:ja:Dogs) may be short, but short text may not always be the most helpful. In etymologies, there seems to be a consensus not to use abbreviations like q.v., L., Gr., esp., cf., &c., which are short but obscure. Some people have opposed using template abbreviations like {{der}} instead of {{derived}}, arguing that the latter is easier to read.

Rationale 2 (ambiguity between different types of categories):

Our current categories with language codes are often ambiguous.
Sometimes, people attempt to use the category description to clear the ambiguity, but descriptions are often ignored. They are often repetitive and not very inviting to read. It's normal to add an entry to multiple categories at once, and maybe the descriptions of all categories are not always read.

Rationale 3 (barrier of use):

Not everyone in the world knows how our language codes work. It shouldn't be necessary to learn it to navigate categories.
Quick summary: We use two-letter ISO 639-1 codes when possible (en, fr, it...), or else we use three-letter ISO 639-3 codes when possible (gsw, frk, ang...) or else we create made-up non-ISO compliant language codes that start with ISO 639-5 family codes (roa-oca, gmw-tsx, ine-pro...). In the categories managed by {{topic cat}}, we ignore etymology language codes, which sometimes resemble the normal codes previously mentioned (xno, frc, sco-uls, sem-jar...) and sometimes don't (NL., LL., pregrc...). Source: Wiktionary:Languages, a "think tank" non-policy.

Rationale 4 (barrier of reuse):

Wiktionary can be reused. Anyone can create mirrors, books, CDS with our material, so we should make it as generic as possible. If we keep categories with language codes such as Category:map-pro:Dogs, the creators of derivative works will have to choose between (1) using the language codes despite the fact that only Wiktionarians are aware of how they work or (2) converting the codes to something that makes sense in real life, such as Category:Proto-Austronesian terms for dogs. ("Proto-Austronesian terms for dogs." currently is the exact description of Category:map-pro:Dogs). If this vote passes, we ourselves will be able to have category names that make sense in real life, and people who reuse our content will benefit as well.

A note about prefixes:

For clarity as mentioned above, it's best not to create prefixes for categories like "Category:list:(something)", "Category:set:(something)" or "Category:topic:(something)". which have been proposed before. If you get all terms relating to linguistics, this is equally a list, a set and the topic of linguistics-related terms, unless we define these words in a way specific to the English Wiktionary, which again harms both use and reuse because it would not be how these words work in real life. If we used these prefixes, there's some chance we will have to constantly inform new users and anons how the prefixes work, because it would not be obvious.

Past votes:

Procedural notes:

  • This vote is only about the category naming system. Specific categories are mentioned here as examples only. Voting here says nothing about whether we should have any of the mentioned categories in the first place.
  • If this vote passes, it may supersede a number of ongoing WT:RFM discussions concerning the affected categories.


  • Vote starts: 00:00, 21 August 2017 (UTC)
  • Vote ends: 23:59, 19 October 2017 (UTC)
  • Vote created: --Daniel Carrero (talk) 13:33, 24 July 2017 (UTC)



  1.   Support --Daniel Carrero (talk) 13:39, 22 August 2017 (UTC)
  2.   SupportCodeCat 14:11, 22 August 2017 (UTC)
  3.   Support DTLHS (talk) 18:51, 22 August 2017 (UTC)
  4.   Support -Xbony2 (talk) 21:21, 22 August 2017 (UTC)
  5.   Support Pariah24 (talk) 14:21, 23 August 2017 (UTC)
  6.   Support (though see my comments in the "Abstain" section below for a suggested compromise). — SGconlaw (talk) 10:28, 30 August 2017 (UTC)
  7.   Support I don't like the length of the new names but the rationale is sensible and it can't be helped. —suzukaze (tc) 23:19, 5 September 2017 (UTC)
  8.   Support I see the use of language codes in visible category names as good for editors (unambiguous), but bad for users (unclear), and in my opinion it's more important to be inclusive for users than editors. The use of templates to categorise pages, where the language code is an argument to the template, would be good. Sure, categorising via templates may mess with HotCat, but I think we should develop tools that support the best implementation of policies, rather than write policies to fit the current tools we have available. -Stelio (talk) 11:11, 28 September 2017 (UTC)
  9.   Support per Suzukaze and Stelio. DCDuring (talk) 15:53, 3 October 2017 (UTC)


  1.   Oppose. I see no reason for this enormous task and disagree with the four rationales given. --WikiTiki89 18:50, 22 August 2017 (UTC)
    While you are completely free to disagree with the rationales, I'd like to point out that they include some statements that seem to be objectively true and thus are above agreement or disagreement. They include: "Our current categories with language codes are often ambiguous.", "Not everyone in the world knows how our language codes work." and most or all of the rationale 4. They illustrate some of the current problems that this vote was designed to solve, as per recent discussion. --Daniel Carrero (talk) 19:23, 22 August 2017 (UTC)
    I should hope they contain objectively true statements, otherwise I or someone else would have removed them from the page before the vote even started. I disagree with them as rationales. "The sky is blue" is objectively true, but that doesn't make it a good rationale. --WikiTiki89 19:33, 22 August 2017 (UTC)
    So, is it accurate to say you're OK with keeping a categorization system where (to repeat what I quoted above) our current categories with language codes are often ambiguous, not everyone in the world knows how our language codes work and creators of derivative works have to choose between using an obscure system or changing it themselves? Isn't this bad for the project? --Daniel Carrero (talk) 19:39, 22 August 2017 (UTC)
    Isn't that what I just said? --WikiTiki89 21:36, 22 August 2017 (UTC)
    That does not really answer my second question. ("Isn't this bad for the project?") The rationales given are not comparable to "The sky is blue.", but to "The house is on fire." They are not random examples of objectively true sentences, they are objectively true summaries of existing problems, and how to fix them. --Daniel Carrero (talk) 00:13, 24 August 2017 (UTC)
    Now you're asking a more reasonable question. So when I say I disagree with the rationales, I mean that each problem either is not really much of a problem, or that it would not really be fixed by this proposal, or both. --WikiTiki89 20:56, 24 August 2017 (UTC)
  2.   Oppose. I see no reason at all to lengthen the names of categories, and make the task of editors more difficult. Some names are already far too long, such as Category:en:Georgia (United States of America), which was a recent ill-judged renaming. DonnanZ (talk) 21:03, 22 August 2017 (UTC)
    In fact, each category already does this, e.g. Category:en:Stars says it should contain "English names of individual stars, not including the Sun." DonnanZ (talk) 22:14, 22 August 2017 (UTC)
    How do you suggest we name a category for terms related to stars, or a category for types of stars? —CodeCat 22:19, 22 August 2017 (UTC)
    I'm not even sure how many types of star there are. "Category:en:Types of star" (or stars) and "Category:en:Individual stars" I suppose. Category titles should be as brief as possible without being ambiguous. Terms relating to stars, hmm, would that include anything else? Stardust? DonnanZ (talk) 22:39, 22 August 2017 (UTC)
    I sometimes think we are guilty of overcategorisation, especially in relation to animals, birds etc. DonnanZ (talk) 23:01, 22 August 2017 (UTC)
    Terms relating to stars may include: corona, photosphere, starspot, stellar wind, starry, stellar, stellar nursery, astroseismology, chromosphere, nova remnant, main sequence, LRN, star system, star cluster, starhood, starcraft, starquake, starscape, starman, circumstellar, constellation, interstellar, intersidereal, initial mass function, Hertzsprung-Russell diagram, Bayer system, Bayer designation, stellarly, protostellar, astropause, astrosheath, astrotail, termination shock, interstellar space, nonstellar, photoprocessing, stellary, astral, interstellary, astrally, stellarcentric, quasistellar, helmet streamer, pseudostreamer, coronal hole, panstellar, superstellar, starly, periastral, planetary system, sidereal, starlight, gravitational collapse, radiometric magnitude, radial velocity, interstellar extinction, hydrogen burning, helium burning, carbon burning, silicon burning, s-process, solar mass, Olbers' paradox, photometry, photovisual, starlit, periastron, spectral type, star cloud, star tracker, starburst galaxy, starburst, starless, stargaze, stargazer, starscape, star-studded, planisphere, starward, star stream, proplanetary disk, starquake, stellate, bolometric correction, bolometric magnitude, visual magnitude, astrophotographer, astrophotography, gamma-ray burst, gravitational lensing, stellated, collapsar, star visitor, stellocentric, Cl*, gyrochronology, gyrochronological, stelliform, habitable zone, continuously habitable zone, Goldilocks zone, starlike, binary star, trinary star, quadruple star, binary star system, trinary star system, quadruple star system, multiple star system, antistar, double star system, double star, single star system, prestellar, asterseismology, apogalacticon, apogalactic, perigalacticon, perigalactic, neutronization, superflare, coronal mass ejection, starshine, photoevaporation, solar apex, astrocompass, subluminous, cuspiness, overluminous, undermassive, star-forming, clustercore, starshade, electrosphere, circumprimary, gravothermal, circumsecondary, hypercompact, unstarlike, neutrinosphere, stelliferous, siderostat, subplanetary, symbiotic star, starfaring, astrometrized, exosystem, starwards, uranometry, starproof, astromantic, astroscopy, metrochrome, star seed, chromatoscope, astrolatry, astriferous, astrogeny, astrography, cosmosphere, catasterism, synastry, substellate, starstuff, starmatter, starlore, starn, super star cluster, open cluster, globular cluster, spheroscope, Venus zone, startracker, Alderson disk, molecular core, photochronograph, astrophotometer, astrophotometry, paranatellon, Sagan's number, proto-neutron star, astrolatrous, birthline, violent relaxation, velocity dispersion, velocity curve, starfilled, nocturnal arc, starbirth, stardrift, photogravitational, photoeccentric, protobulge and starrish.
    As per this vote, all these entries would be found in Category:English terms relating to stars. Alternatively, we could have one or more additional categories like Category:English terms for groups of stars.
    In practice, currently we have only Category:en:Stars for everything (names of stars, types of stars, terms relating to stars) which seems like a bad idea -- the purpose of the category is unclear, and it is increasingly difficult to find the terms I listed above among names of stars. While we do have the option of using alternate category names like maybe Category:en:Terms relating to stars and Category:en:Types of stars for disambiguation, there's still the issue that our codes are obscure, unlike normal English. This vote would solve that. --Daniel Carrero (talk) 21:30, 23 August 2017 (UTC)
    Your proposal of using Category:English blah blah would appear to preclude the use of {{c}}, {{C}} etc, which require the code en, nb etc. which would be yet another reason for voting against. DonnanZ (talk) 21:57, 23 August 2017 (UTC)
    It would make that template obsolete, which allows us to repurpose it for another use. —Rua (mew) 22:09, 23 August 2017 (UTC)
    You have already expressed your dislike in another current vote. DonnanZ (talk) 22:31, 23 August 2017 (UTC)
    My dislike is with the name. —Rua (mew) 22:44, 23 August 2017 (UTC)
    The use of two-letter codes is not really a problem anyway, they are used everywhere, e.g. {{en-noun}}, {{nb-noun-m1}}, {{l|en|, {{lb|en|, {{t|de|, {{m|la|, {{cog|sv|, {{der|en|fr|. So their use is more or less universal, and most users get to know them. DonnanZ (talk) 23:52, 23 August 2017 (UTC)
    Those are not user-facing. They are only for editors. Editors can be expected to learn the codes, users can't. —Rua (mew) 23:55, 23 August 2017 (UTC)
    I agree with CodeCat. FWIW, as a bit of anecdotal evidence, I've had the experience of introducing Wiktionary to a friend and attempting to teach him how our ISO and non-ISO codes work to let him navigate a few categories. That's non-obvious stuff that seems to make navigation harder for our readers. --Daniel Carrero (talk) 00:08, 24 August 2017 (UTC)
    It still shouldn't create too much difficulty. For example, looking at the clutter at the bottom of the entry for car you will find that categories are grouped with the relevant language; even for Welsh (perhaps the least obvious one) {{Category:cy:Vehicles}}, if you click on it it tells you that its "Welsh terms related to Vehicles". DonnanZ (talk) 00:18, 24 August 2017 (UTC)
    I don't speak Welsh, but its English version Category:en:Vehicles could be confused for either "terms relating to vehicles" or "terms for types of vehicles". Currently, the description states the former, but it's populated with the latter. The category is currently missing vehiclelike, vehicle identification number, railway, undercarriage, hit the road, carjack, etc. It seems the category name does not invite any of these terms even though the description does, which is a major problem that will probably cause the categories to be forever underpopulated if left unchecked. Category:Welsh terms relating to vehicles and/or Category:Welsh terms for types of vehicles are clearer and better than Category:cy:Vehicles. --Daniel Carrero (talk) 00:33, 24 August 2017 (UTC)
    If you don't like the description used in a category module it can be edited, but I think the descriptions are probably designed to be "catch-all". There is still the danger of an overprovision of categories, especially in a language like Welsh with possibly very few entries in each category. But besides Category:en:Vehicles there is also Category:en:Auto parts (a horrid title, car parts is more preferable), Category:en:Automobiles, and Category:en:Automotive. A Winnebago or garbage truck shouldn't be classed as an automobile.
    I think how categories appear in an entry also needs to be looked at, especially with multi-language words like car. I think it would be better to be able to access categories used in a particular language entry within the entry itself, instead of having to search through the clutter at the bottom of the page. DonnanZ (talk) 09:00, 24 August 2017 (UTC)
    What about categories like Category:en:Internet? It's filled with a lot of terms that belong on Category:English internet slang. Category descriptions seem to be traditionally ignored. Do you have any idea on how to make people read and follow the descriptions? If reading descriptions is needed to avoid confusion, it means the category names are not good enough. This vote would fix that problem, by renaming Category:en:Internet to Category:English terms relating to the internet, so any mistake would be readily apparent and thus all but sure to be corrected. Aside from the obscure language code, at first sight there may be nothing wrong with placing LOL in Category:en:Internet, until you read the category description and discover that the other category exists.
    I'm fine with discussing ways to present categories within the entry itself. --Daniel Carrero (talk) 13:24, 24 August 2017 (UTC)
    The problem with Category:en:Internet is that we use topical categories to categorise most other kinds of slang or jargon. We also use labels to indicate where a term is used. So when a term is used in the UK, we use {{lb|en|UK}}, and when it's used on the internet, we use {{lb|en|Internet}}... —Rua (mew) 13:35, 24 August 2017 (UTC)
    Maybe we should make {{lb|en|Internet}} categorize into Category:English internet slang. When a terms semantically involves the internet (URL, webpage, etc.) it doesn't actually need to start with the context label "(Internet)". Of course, we also have the option of typing {{lb|en|internet slang}} when a term is used on the internet, which currently works and successfully categorizes the entry in Category:English internet slang. --Daniel Carrero (talk) 13:54, 24 August 2017 (UTC)
  3.   OpposeAryaman (मुझसे बात करो) 14:02, 23 August 2017 (UTC)
  4.   Oppose. I don't even know how to begin to express how strongly I oppose this proposal. I always envied the English Wiktionary's categorisation system, because the system we have back home in the Romanian Wiktionary – which is quite similar to the proposal above – is a complete nightmare. A reoccurring issue we've had is that we encourage ambiguity. Do we name categories "Culori în franceză", or, "Culori în limba franceză" – both forms are acceptable and there are just as many people who prefer the first form as the second. And don't get me started on languages that have different names: should it be olandeză or neerlandeză? How do we spell Malay? Is it malaieziană, malaieză or malaeză (N.B. all are correct)? The system with ISO language codes that we have now strikes me as both logically and technically sound. On another note, I appreciate everything you do around here @Daniel Carrero and the votes you have started, but allow me to be brazen and ask you why there's a need for a revamping of our categorisation system? Personally, I have not seen anyone complain. I hate to use this cliché, but if ain't broke, why fix it? I'm afraid that if this vote passes, we will be substituting a functional method with something that hasn't worked in other projects, and that's not taking into consideration the tremendous undertaking this change implies. --Robbie SWE (talk) 18:16, 23 August 2017 (UTC)
    Just because you don't see a problem doesn't mean there isn't one, and that it hasn't been discussed before. Some links to discussions were even helpfully provided in the vote. —CodeCat 18:41, 23 August 2017 (UTC)
    @Robbie SWE: We use the same language name at all places. We always use "Old English", never "Anglo-Saxon" (code: ang). We always use "Austronesian Mor", never "Mor" or "Mor (Austronesian)" (code: mhz). When a language name needs to change for whatever reason, it changes everywhere. The language name used in categories is the same as the one used in entries. Categories like "<language> nouns" and "<language 1> terms derived from <language 2>" never have any problems like what seems to be happening in the Romanian Wiktionary. More information: WT:LANG. This system is kept by large modules like Module:languages/data3/m. I apologize if I said anything you were already aware of. If the only problem was that, please consider changing your mind and voting support. --Daniel Carrero (talk) 18:58, 23 August 2017 (UTC)
    Let's agree to disagree – I believe we have other issues to worry about, categories not being one of them. Daniel Carrero, thank you for your explanation. I promise to think long and hard and consider changing my mind. However, right now, I'm pretty sure I'm sticking to my initial gut feeling. --Robbie SWE (talk) 19:18, 23 August 2017 (UTC)
    @Robbie SWE Thank you for promising to think long and hard and consider changing your mind. We have extra time to think if needed since this is a two-month vote, so there's no rush. I would just like to add this: Please refrain from voting oppose on the grounds that we could be doing something else. I personally like to clean up our categories -- I've been doing it since 2008. So even if we have other issues to worry about, this is a focus of mine. I would like to organize all of our categories, given enough time and the opportunity to do so. --Daniel Carrero (talk) 06:02, 1 September 2017 (UTC)
    @Daniel Carrero, I assure you that I don't in any way, shape or form downplay the need to clean up our categories — I fully respect the work and thought you (and others) have put into this. In all honesty, 99,9% of the reason why I voted oppose is because I'm in love with the language codes and wouldn't want to see them go. Sad, but true. --Robbie SWE (talk) 09:48, 1 September 2017 (UTC)
    @Robbie SWE: Thanks, it's nice of you to clarify that. Sometimes I've seen people voting "oppose" on some project on the grounds that we could be doing something else. I understand that's not the case with your vote. Well, now I guess I can't argue with your reason. C'est la vie. --Daniel Carrero (talk) 07:15, 2 September 2017 (UTC)
  5.   Oppose. Wyang (talk) 09:13, 24 August 2017 (UTC)
  6.   OpposeΜετάknowledgediscuss/deeds 06:10, 1 September 2017 (UTC)
  7.   Oppose While I support changing the category naming system in principle, I don't believe the suggested alternatives given here are an improvement. I think expanding the names for clarity is a good thing, but getting rid of the codes is the main gripe for me; for example, I would support a system where an ambiguous category such as Category:en:Dogs becomes Category:en:Dog breeds and Category:en:Terms relating to dogs. BigDom 06:43, 1 September 2017 (UTC)
  8.   OpposeZ. [ קהת ] b"A. — 14:19, 3 September 2017 (UTC)
  9.   Oppose. — justin(r)leung (t...) | c=› } 20:19, 8 September 2017 (UTC)
  10.   Oppose. Formatting of category names should be like the formatting of our entries: concise and streamlined. As I've said before, burying the essential information in long strings of English text risks making category names TLDR. If we're going to do something like this, it should be telegraphic in style with the more changeable stuff up front: Category:English:Cats:Kinds Category:English:Cats:Related terms Keeping the colons makes it easier for the eye to find the structure, and minimizing the function words needed to make the names work as running English text makes it easier to read. I also think that we need to think more about the way we divide the topical categories before we cast things in concrete like this. Chuck Entz (talk) 02:52, 14 October 2017 (UTC)
    I like this. —suzukaze (tc) 02:59, 14 October 2017 (UTC)
    This alternative structure works for me too. It replaces the language code with the more accessible (for users) language name, whilst keeping the category names concise. -Stelio (talk) 10:25, 16 October 2017 (UTC)
    @Chuck Entz, your vote isn't showing up in the total. Perhaps your name needs to be on the same line as the "oppose"? -Stelio (talk) 10:59, 17 October 2017 (UTC)
    You're probably right. I removed the formatting. Thanks! Chuck Entz (talk) 13:27, 17 October 2017 (UTC)
    Personally, I don't like Category:English:Cats:Related terms. I disagree with the comparison in your first sentence ("Formatting of category names should be like the formatting of our entries: concise and streamlined."), Chuck Entz. Our entries may be concise and streamlined, but they still need to make sense as normal English text.
    Currently, streamlined is defined as: "1. Designed to offer little resistance to the flow of fluid, especially by having sleek, graceful lines. / 2. Having been made more simple and straight forward."
    The way I see it, Category:English:Cats:Related terms is too concise, and is not even streamlined as defined above. In my opinion, the name Category:English terms relating to cats which was proposed in the vote is better - after reading all the vote comments, I can say this is the most concise option given which still makes sense as normal English, which by definition makes it the most streamlined option too. You can just read it like normal text. How can it be more simple and straightforward than normal English text?
    If we are going to compare entry formatting with category names, note that the entry dog could be even shorter, sacrificing syntax in favor of added colons too. These are the first three definitions of that entry:
    1. A mammal, Canis lupus familiaris, that has been domesticated for thousands of years, of highly variable appearance due to human breeding.
    2. A male dog, wolf or fox, as opposed to a bitch (often attributive).
    3. (slang, derogatory) A dull, unattractive girl or woman.
    These are the same definitions, in a style closer to Category:English:Cats:Related terms. We could still kind of understand them, but normal English would be better in my opinion, both for entry formatting and category names.
    1. Mammal:domesticated:Canis lupus familiaris
    2. Mammal:dog,wolf,fox:male
    3. (slang, derogatory) Woman:ugly
    --Daniel Carrero (talk) 16:43, 17 October 2017 (UTC)
    I checked a few random pages in Wikipedia, Commons, MediaWiki, Meta-Wiki, Wikibooks, Wikidata, Wikinews, Wikiquote, Wikisource, Wikispecies, Wikiversity and Wikivoyage.
    The categories I have found are written as normal English text, with normal syntax, as opposed to obscure abbreviations. For example: w:Category:Cat breeds originating in Thailand, w:Category:Articles containing potentially dated statements from 2015.
    Exceptions include:
    Let me know if I missed anything. Wiktionary seems to be the only Wikimedia project where you need to decode a whole new system to understand a large chunk of the category names, as opposed to just reading them as normal text. --Daniel Carrero (talk) 17:59, 17 October 2017 (UTC)
  11.   Oppose. Crom daba (talk) 20:21, 19 October 2017 (UTC)
  12.   Oppose After considering both sides, I think I have to oppose. We can do disambiguation without removing the ISO tags and making names unconscionably long. As a previous user suggested, Category:en:Dogs could be split into Category:en:Dog breeds and Category:en:Terms relating to dogs. The non-ISO codes present a dilemma, but the vast majority of global speakers and headwords are from languages with ISO codes, so it doesn't make sense to rewrite the system for that reason. Catrìona (talk) 23:11, 19 October 2017 (UTC)


  •   Abstain: I am leaning towards supporting the proposal, but agree that as it stands it may lead to rather long category names (which I don't necessarily object to). Perhaps a compromise could be to retain the language codes, for example, "Category:en:Terms for dog breeds" (or even "Category:en:Dog breeds") and "Category:en:Terms relating to dogs". — SGconlaw (talk) 09:15, 30 August 2017 (UTC)
    Part of the point was to eliminate the language codes, so that the names agree with the other categories such as Category:English nouns and so that people don't need to know codes to navigate our categories. —Rua (mew) 10:11, 30 August 2017 (UTC)
    Ah, right. Well, if this is a key concern then I essentially support the proposal. However, if the length of category names is a big issue for editors, I think my suggestion strikes a compromise. — SGconlaw (talk) 10:26, 30 August 2017 (UTC)
    Maybe this is a stupid question but why not Category:en:Nouns? It would be consistent and increase brevity. Catrìona (talk) 23:15, 19 October 2017 (UTC)
    Your question is not stupid; it is a good question. I wonder if there are people who would support Category:en:Nouns, maybe you would? Currently, the category exists, to hold terms like common noun and abstract noun. Sometimes, we used to have POS categories like these (e.g., placing random nouns in Category:en:Nouns). I removed those I found around 2006-2008. We also used to have a large system of etymological categories named like Category:fr:Japanese derivations and other categories like Category:es:Vulgarities.
    I will have to repeat some arguments given before, if you don't mind. I can't speak for anyone else, but in my opinion "English nouns" (like "Spanish vulgarities" and "Spanish terms derived from Italian") is better because its meaning is readily understandable as normal English text. If all language-specific categories had codes instead of names, including the ones I mentioned above, this would at least be a consistent system. (should it be Category:en derived from ja instead of Category:en:Japanese derivations?) This is all I can say in its favor at the moment, and I would object to this system anyway. This is just my opinion, naturally other people might think differently. --Daniel Carrero (talk) 03:41, 21 October 2017 (UTC)
  1.   Abstain I am inclined to oppose, but I sense I did not find the energy to consider the benefits of the proposal seriously enough. Short names are much easier to skim, and also to type. A distinction between a set category and a relating-to category could be made by category definitions placed into the categories themselves; and a convention could be made that categories named in plural would be set categories. I think it was Chuck Entz who, in relation to this subject, pointed out that the verbosity of Cobol did not necessarily make it a better, easier to use language than the alternatives, especially modern alternatives. --Dan Polansky (talk) 20:52, 13 October 2017 (UTC)


No consensus: 9-12-1 (42.85%).

(Procedural note: As specified in WT:VTIME, for votes with at least 40% support, I've been using "No consensus" instead of "Failed".)

--Daniel Carrero (talk) 04:38, 28 October 2017 (UTC)

  • I wish it worked like that (no consensus) in referendums - 48 to 52% in the UK EU referendum. DonnanZ (talk) 09:53, 28 October 2017 (UTC)

User:Chuck Entz for checkuser

Nomination: I hereby nominate User:Chuck Entz as a local English Wiktionary CheckUser. Chuck has indicated willingness in the BP discussion.


  • Vote starts: 20:39, 11 October 2017 (UTC)
  • Vote ends: 23:59, 1 November 2017 (UTC)
  • Vote created: TheDaveRoss 20:39, 11 October 2017 (UTC)

Acceptance: I accept this nomination. Chuck Entz (talk) 01:41, 13 October 2017 (UTC)


  1.   Support - TheDaveRoss 20:39, 11 October 2017 (UTC)
  2.   Support Highly trusted and helpful user. —Justin (koavf)TCM 20:43, 11 October 2017 (UTC)
  3.   Support. I generally subscribe to the idea that one user should not be given all the privileges available in the project. However, we need a second checkuser in order to have local powers for TheDaveRoss, and if any user has earned the level of trust that would be requisite for this, it would be Chuck. I nominated him to be a bureaucrat, and he has handled very sticky problems in that role with admirable levelheadedness and attention to detail. I expect no less of him in using the checkuser tool. —Μετάknowledgediscuss/deeds 23:31, 11 October 2017 (UTC)
  4.   Support Already an experienced sysop and helpful editor. —Aryaman (मुझसे बात करो) 00:48, 12 October 2017 (UTC)
  5.   Support Never loses his temper somehow! Equinox 00:49, 12 October 2017 (UTC)
    Almost never... Chuck Entz (talk) 01:49, 13 October 2017 (UTC)
  6.   Support Wyang (talk) 03:08, 12 October 2017 (UTC)
  7.   Support — justin(r)leung (t...) | c=› } 03:33, 12 October 2017 (UTC)
  8.   Support No doubt in my mind that Chuck is the right choice. --Robbie SWE (talk) 17:04, 12 October 2017 (UTC)
  9.   Support His username is almost an anagram of "check user" anyway. --Barytonesis (talk) 17:09, 12 October 2017 (UTC)
  10. support (I hate straw polls, but this is important.) - Amgine/ t·e 18:44, 12 October 2017 (UTC) Check Untz?
    You may want to read our entry straw poll, because that is very much not what this is. —Μετάknowledgediscuss/deeds 18:46, 12 October 2017 (UTC)
    On this we may agree to disagree; normally I would call this a beauty pageant. - Amgine/ t·e 19:02, 12 October 2017 (UTC)
    We might need an extra metaphorical sense at beauty pageant. But if I interpret your meaning correctly, that's not the same as a straw poll. I wonder if you actually looked at that entry. —Μετάknowledgediscuss/deeds 19:30, 12 October 2017 (UTC)
  11.   Support --Vahag (talk) 17:43, 13 October 2017 (UTC)
  12.   Support --Dan Polansky (talk) 21:00, 13 October 2017 (UTC)
  13.   Support Ks0stm (TCE) 23:03, 13 October 2017 (UTC)
  14.   SupportVorziblix (talk · contribs) 18:06, 14 October 2017 (UTC)
  15.   SupportTAKASUGI Shinji (talk) 06:56, 15 October 2017 (UTC)
  16.   Support Lingo Bingo Dingo (talk) 13:59, 16 October 2017 (UTC)
  17.   Support I thought he already was one, otherwise I would have mentioned him as a choice in my comment here. --WikiTiki89 21:56, 16 October 2017 (UTC)
  18.   SupportAɴɢʀ (talk) 09:50, 20 October 2017 (UTC)
  19.   Support -Xbony2 (talk) 20:04, 20 October 2017 (UTC)
  20.   Support Yes, of course. bd2412 T 02:00, 21 October 2017 (UTC)
  21.   SupportUngoliant (falai) 16:02, 23 October 2017 (UTC)
  22.   Supportsuzukaze (tc) 18:50, 26 October 2017 (UTC)
  23.   Support -- Chuck has consistently been a positive force in this community. No reservations. ‑‑ Eiríkr Útlendi │Tala við mig 16:31, 31 October 2017 (UTC)
  24.   Support Redboywild (talk) 16:55, 31 October 2017 (UTC)
  25.   SupportPalaestrator verborum (loquier) 17:12, 31 October 2017 (UTC)
  26.   SupportPanda10 (talk) 18:53, 31 October 2017 (UTC)
  27.   Support, of course. Sorry to be so late. - DCDuring (talk) 00:37, 1 November 2017 (UTC)
  28.   Support for obvious reasons. PseudoSkull (talk) 13:42, 1 November 2017 (UTC)
  29.   Support - -sche (discuss) 14:50, 1 November 2017 (UTC)
  30.   Support --Makaokalani (talk) 16:40, 1 November 2017 (UTC)
  31.   SupportEru·tuon 19:37, 1 November 2017 (UTC)
  SupportBukhariSaeed (talk) 09:28, 10 November 2017 (UTC)
Thank you for voicing your support for Chuck, however this vote is both late - the vote is closed - and not valid due to account age. - TheDaveRoss 12:45, 10 November 2017 (UTC)




Passes unanimously, with 31-0-0. Congrats, Chuck. You'll have to give the WMF your info and sign up at meta:Steward requests/Permissions. —Μετάknowledgediscuss/deeds 03:49, 2 November 2017 (UTC)

@Chuck Entz, if you wouldn't mind, please let me know when you are IDed and ready to request access so I can request at the same time. Thanks. - TheDaveRoss 14:40, 2 November 2017 (UTC)
@Chuck Entz, you could update Wiktionary:CheckUsers too if you feel like. -WF

Templatizing topical categories in the mainspace 2

Voting on: Templatizing the markup for topical categories in the mainspace with one of two particular templates, {{cat}} or {{c}}. Thus, giving a full go ahead to all automatic and semiautomatic edits that replace the likes of "[[Category:nl:Mammals]]" with "{{cat|nl|Mammals}}" or "{{c|nl|Mammals}}". Note that the templates support multiple parameters, such as {{c|nl|Mammals|Zoology}}. Note that, currently, {{c}} is a redirect to {{topics}}. This proposal is about using templates for this purpose in general, and also about the particular template names to appear in wikitext in the mainspace.


  • Vote starts: 00:00, 6 August 2017 (UTC)
  • Vote ends: 23:59, 4 October 2017 (UTC)
    Extended: 23:59, 28 November 2017 (UTC)
  • Vote created: Dan Polansky (talk) 09:19, 30 July 2017 (UTC)


Support for cat

  1.   Support --Daniel Carrero (talk) 22:17, 6 August 2017 (UTC)
    I like {{cat}}, like the alias "Cat" for categories. Typing {{cat|en|dogs}} seems similar to typing [[Cat:en:Dogs]]. --Daniel Carrero (talk) 22:17, 6 August 2017 (UTC)
  2.   Support -Xbony2 (talk) 01:37, 9 August 2017 (UTC)
  3.   Support, same reasons as in the previous vote. — Vorziblix (talk · contribs) 18:07, 10 August 2017 (UTC)
  4.   Support Ƿidsiþ 12:32, 12 August 2017 (UTC)
  5.   Support, the main reason being sortkeys. —Aryaman (मुझसे बात करो) 14:39, 28 October 2017 (UTC)
  6.   Support; this is consistent with the Chinese specific template {{zh-cat}}. — justin(r)leung (t...) | c=› } 21:58, 28 October 2017 (UTC)
  7.   Support Lingo Bingo Dingo (talk) 12:15, 30 October 2017 (UTC)
  8.   Support – Because (as @Daniel Carrero says above) {{cat|en|Languages}} is similar to [[CAT:en:Languages]], I think it makes sense as a name for the template that generates language code–prefixed categories. — Eru·tuon 18:16, 3 November 2017 (UTC)
  9.   Support. Better than {{c}}, worse than {{topics}}, much better than [[Category:]]. — Ungoliant (falai) 15:48, 9 November 2017 (UTC)
    @Ungoliant MMDCCLXIV If you want {{topics}}, you should vote oppose like I did. —Rua (mew) 15:56, 9 November 2017 (UTC)
    I’d rather settle for a smaller improvement than insisting on one that is not likely to pass. — Ungoliant (falai) 16:08, 9 November 2017 (UTC)
    Indeed, {{topics}} had only one support in Wiktionary:Votes/2017-05/Templatizing topical categories in the mainspace, and 6 opposes. I find {{topics}} a fine name, but it is unlikely to gain 2/3-supermajority. {{cat}} seems to be an okay name, especially since its functions can be expanded to handle non-topical categories as well, as indicated on the talk page of the vote. --Dan Polansky (talk) 16:43, 10 November 2017 (UTC)

Oppose for cat

  1.   Oppose DonnanZ (talk) 20:03, 8 August 2017 (UTC)
    @DonnanZ: Could you please clarify why you oppose this? Is it because you consider it too long? (You seem not to oppose {{c}} and {{C}}.) --Dan Polansky (talk) 18:22, 31 October 2017 (UTC)
    I am all in favour of shorter template names, which is why I support {{c}} rather than {{cat}}. But if {{c}} causes problems for some users I have no objection to {{cat}} being used by them. I trust that {{c}} and {{cat}} are intended to be options chosen by the user, and it's not an either/or situation, where one of them wins. But I don't want to use {{cat}} myself. And I don't use HotCat. DonnanZ (talk) 17:18, 1 November 2017 (UTC)
    @DonnanZ: The proposal of the vote is to give a go ahead to certain replacements; it is not to force users to use a particular template name. If this particular proposal passes (very uncertain), you should still be able to use {{c}} but someone else may feel free to change that to {{cat}}. If {{c}} gets deprecated (not part of the proposal as written), that's going to be a different story. --Dan Polansky (talk) 17:46, 3 November 2017 (UTC)
  2.   Oppose. Not at all indicative of function. Yes, it categorises, but it's specifically for topical categories. Thus, {{topics}} makes more sense. Compare {{categorize}}, which is a general categorizing template. {{cat}} should redirect to {{categorize}}. —CodeCat 20:10, 8 August 2017 (UTC)
  3.   Oppose. It will mess up MediaWiki:Gadget-HotCat.jsInternoob 01:12, 27 August 2017 (UTC)
    Wouldn't that already be messed up with the use of {{topics}} or am I missing something? -Xbony2 (talk) 12:56, 27 August 2017 (UTC)
    Yes, any categories added through templates are not editable through HotCat. I mainly disagree with the go-ahead for all automatic and semi-automatic edits that replace [[Category:]] with {{cat}}, because that only takes away my ability to edit those with HotCat. —Internoob 00:21, 3 September 2017 (UTC)

Abstain for cat

  1.   Abstain Prefer to keep as is. --Victar (talk) 19:18, 1 November 2017 (UTC)
    @Victar: In Wiktionary:Votes/2017-05/Templatizing topical categories in the mainspace, you said "Would support {{cat}}". Have you changed your mind? --Dan Polansky (talk) 17:41, 3 November 2017 (UTC)

Support for c

  1.   Support -Xbony2 (talk) 01:37, 9 August 2017 (UTC)
  2.   Support, same reasons as in the previous vote. — Vorziblix (talk · contribs) 18:07, 10 August 2017 (UTC)
  3.   Support - better than {{cat}} and much better than {{topics}}. DonnanZ (talk) 09:21, 19 August 2017 (UTC)
  4.   Support Lingo Bingo Dingo (talk) 12:15, 30 October 2017 (UTC)

Oppose for c

  1.   Oppose. Same as above, except worse. —CodeCat 20:11, 8 August 2017 (UTC)
  2.   Oppose. It will mess up MediaWiki:Gadget-HotCat.jsInternoob 01:12, 27 August 2017 (UTC)
  3.   Oppose. Same as above. Also opposed to case-sensitive templates. --Victar (talk) 19:18, 1 November 2017 (UTC)

Abstain for c

  1.   Abstain for the present. What's wrong with {{C}}? DonnanZ (talk) 20:05, 8 August 2017 (UTC)
    @DonnanZ: {{C}}, in contrast to {{c}}, is capitalized for no obvious reason. We have {{m}}, {{lb}}, {{l}}, {{ux}}, etc., not {{M}}, etc.
    Furthermore, {{C}} in capital did not make it in Wiktionary:Votes/2017-05/Templatizing topical categories in the mainspace; I opposed there on account of the wrong capitalization. {{c}} in lowercase still has a chance. --Dan Polansky (talk) 07:45, 19 August 2017 (UTC)
    What you really mean is "no consensus", it didn't fail. I am now supporting {{c}}. DonnanZ (talk) 09:35, 19 August 2017 (UTC)
  2.   AbstainAryaman (मुझसे बात करो) 14:39, 28 October 2017 (UTC)
  3.   Abstain — justin(r)leung (t...) | c=› } 21:58, 28 October 2017 (UTC)
  4.   Abstain – I've used {{c}} and {{C}}, but I don't know if they really are intuitive names, or if the names are best used in this way. — Eru·tuon 18:18, 3 November 2017 (UTC)


  • Previous votes on this subject had more participants, so I would like to extend the vote. I know there is some opposition to extensions. --Dan Polansky (talk) 14:57, 8 October 2017 (UTC)
    I extended it to November 28, 2017, per your request, if no one minds. To be extra clear: I, personally, support extending the vote. --Daniel Carrero (talk) 04:40, 28 October 2017 (UTC)

Desysopping CodeCat aka Rua

Let us remove admin rights from Rua (talkcontribs), formerly known as CodeCat.

Rationale: see Wiktionary talk:Votes/sy-2017-11/Desysopping CodeCat aka Rua#Rationale. The voters only vote on the proposed action, not on the rationale.


  • Vote starts: 23:59, 11 November 2017 (UTC)
  • Vote ends: 23:59, 11 December 2017 (UTC)
  • Vote created: Dan Polansky (talk) 22:22, 4 November 2017 (UTC)


  1.   Support per my rationale on the talk page. Let me emphasize that it should be reasonably easy to let the nominee edit templates and modules by lowering their protection or by adding the nominee to the template editor group. During the approximately last year during which the nomineed was temporarily desysopped, they were able to request lowering of protection for particular templates or modules, from what I remember. Dan Polansky (talk) 10:13, 11 November 2017 (UTC)
    Note: My rationale does not include "incivility" or "cold persona". Issues I raise include repeated non-consensual volume changes, use of admin tools to gain an upper hand in a dispute, high-rate wheel warring showing lack of self-control, and a dictatorial position taken in a discussion about re-sysopping. Details are on the vote talk page. --Dan Polansky (talk) 07:14, 17 November 2017 (UTC)
  2.   Support. Ignorant, yet disdainful and imperious. Just have a read of the conversations on her talkpage and her posts in various discussions (e.g. search for 'Rua' on Wiktionary:Beer parlour/2017/August) ― there is no warmth whatsoever, only the exhibition of a rather cold persona. Wyang (talk) 12:16, 11 November 2017 (UTC)
    Warmth comes when warmth is offered. If I appear cold, it's because all the hassle and coldness people have given me has destroyed whatever warmth was inside me. Wiktionary is a cold and harsh place, if I open up emotionally I'll just get hurt more. Case in point: this very vote. —Rua (mew) 12:37, 11 November 2017 (UTC)
    I do not agree that Wiktionary is a cold and harsh place; if it were true, most people would have turned similarly apathetic via this devolution. If anything, warmth in interpersonal interactions is highly infectious, and being on the receiving end of reciprocated warmth (and consequently feeling respected as a person) is arguably the most fulfilling and addictive outcome of it. This vote exists because some people, me included, felt you were unempathetic, and that you had not respected them as equal human beings with opinions worth paying attention to. It's an unfortunate outcome. You sound discontented, dejected, and burnt out. It may be worthwhile to take a break. Wyang (talk) 14:18, 11 November 2017 (UTC)
    It's how I perceive Wiktionary to be. It's not a matter of fact. I'm definitely burnt out, but I also feel better when I can do the Wiktionary work I enjoy, without having to endure social interactions. So it's a double-edged sword for me. Wiktionary drives me insane at times, but I also need it for sanity. —Rua (mew) 16:23, 11 November 2017 (UTC)
  3.   Support if includes template editor access Callous, condescending, and spiteful -- her woefully poor interpersonal skills require mediation between herself and other users, arbitration she is able to skirt as an admin by locking and deleting entries without discussion. A new wheel war between another admin is all but inevitable, because to her, being right is more important than the project, which she blatantly illustrates in this discussion. I really and truly appreciate the exceptional work she does and value her knowledgeable opinions, but CodeCat needs to be desysopped to save her from herself. --Victar (talk) 18:29, 11 November 2017 (UTC)
  4.   Support Consistently exhibits the kind of behavior I don't like to see an admin. Chiefly incivility and coding without consensus. Purplebackpack89 23:29, 11 November 2017 (UTC)
  5.   Weak support if includes template editor access I don't like the way the discussion is playing out here at all, but I have been convinced. I think future readminship should be allowed though. —Aryaman (मुझसे बात करो) 16:06, 15 November 2017 (UTC)


  1.   Oppose I agree that Rua needs to work on her civility and consensus-building skills, but at this point I don't think desysopping is a necessary step. —Aɴɢʀ (talk) 11:11, 11 November 2017 (UTC)
    @Angr, what do you see as a next step in correcting a behavioral issue? --Victar (talk) 20:18, 12 November 2017 (UTC)
    I don't know yet. —Aɴɢʀ (talk) 20:27, 12 November 2017 (UTC)
  2.   Oppose Per Angr. --Anatoli T. (обсудить/вклад) 11:18, 11 November 2017 (UTC)
  3.   Oppose I don't think this vote is the way forward, and I echo Angr's feelings, particularly re consensus-building. She does a number of daft things which get up my nose, most recently adding USA to States in the USA (the only one I agree with is Georgia), clogging up Category:Candidates for speedy deletion in the process, and changing "Municipalities in" to "Municipalities of", I'm not sure what the logic behind that was. Another thing: if DP can vote for the proposal, surely Rua can vote against it. Fair's fair. DonnanZ (talk) 15:15, 11 November 2017 (UTC)
    "USA" → WT:RFM#Categories about country subdivisions to include the country name
    "of" → WT:RFM#Standardising "of" vs "in" in place-name categories
    --Daniel Carrero (talk) 16:02, 11 November 2017 (UTC)
    I missed the first discussion, more time should have been allowed, and took part in the second although I was late on the scene. Municipalities shouldn't be treated any differently from cities in my opinion. DonnanZ (talk) 16:17, 11 November 2017 (UTC)
    Almost 1 month passed in the first discussion, with no oppose votes. That is, 100% support. How much time did you want? --Daniel Carrero (talk) 16:58, 11 November 2017 (UTC)
    On principle, I'm pretty sure I agree with you that municipalities shouldn't be treated any differently from cities. But nobody has said otherwise, did they? Let me know if you found any proposal to treat them differently. --Daniel Carrero (talk) 17:02, 11 November 2017 (UTC)
    I have been busy doing etyl clean-ups, something else I didn't vote for or on. But OK, I should make time to read the more obscure discussions. DonnanZ (talk) 17:20, 11 November 2017 (UTC)
    Really, how much time did you want? Give a number and that probably can be arranged. The intro of WT:RFM does not mention any time limit. --Daniel Carrero (talk) 17:55, 11 November 2017 (UTC)
    Hmm, a difficult question. There was only one vote in support (yours) on one of them, so I think more time should have been given. On the other hand, I pushed Category:Toiletries through pretty quickly. I don't want to be accused of using double standards. DonnanZ (talk) 20:32, 11 November 2017 (UTC)
    It can be pretty frustrating when you're waiting for support and nobody cares enough to post anything, in support or in opposition. The current BP post for adopting the new revised/improved WT:ACCEL suffers from the same problem, nobody has responded to it at all yet. —Rua (mew) 20:44, 11 November 2017 (UTC)
    Is there some reason why they weren't made into votes? That certainly given it more eyes, and potentially more votes. Would that have been an incorrect use of the voting system, or is it an issue of unwieldiness? --Victar (talk) 21:18, 12 November 2017 (UTC)
    Just to note, the reason that the speedy deletion category is so full is because a bot can't move pages without leaving a redirect, unless it has admin rights. So I did the next best thing and programmed it to place {{delete}} on the leftover redirects. I'm not sure how to actually delete them. —Rua (mew) 17:44, 11 November 2017 (UTC)
    You can always rerun your bot and revert them (wish, wish). DonnanZ (talk) 17:55, 11 November 2017 (UTC)
    Turn them back into redirects? Why? We don't want those redirects... What we really need is someone who can run a bot to delete them all. —Rua (mew) 18:00, 11 November 2017 (UTC)
    It could have been done, I was able to cancel a redirect I did last night. But it's too late now. DonnanZ (talk) 09:57, 12 November 2017 (UTC)
  4.   Oppose DTLHS (talk) 16:24, 11 November 2017 (UTC)
  5.   Oppose. I'm grateful to Rua for cleaning up some of our otherwise random mess of categories. If she weren't an admin already, I'd nominate her. --Daniel Carrero (talk) 17:04, 11 November 2017 (UTC)
    Becoming an admin isn't just some award you get after x amount of edits -- it's a job you're entrusted with and if you can't do your job responsibly, that job is taken away from you. --Victar (talk) 18:34, 11 November 2017 (UTC)
    I agree with Victar. This is why we have rollbacker and template editor privileges now, and if this vote were to pass, Rua could do fine with those. —Aryaman (मुझसे बात करो) 21:34, 11 November 2017 (UTC)
    I also edit JavaScript, though not very often. —Rua (mew) 21:44, 11 November 2017 (UTC)
    Becoming an admin is, partially, some award you get after x amount of edits. No one gets to be an admin without doing x amount of edits. It is also a job you're entrusted with, yes. The criteria for becoming an admin may be subjective, but the 100% approval in Wiktionary:Votes/sy-2010-03/User:CodeCat for admin indicates that she does some of that subjective stuff right. If the current vote fails, it will confirm that it is still the case. --Daniel Carrero (talk) 16:13, 12 November 2017 (UTC)
    That's absolutely not true. There are probably thousands of basic users with more edits than the admins on this page, and conversely plenty of admins with low edit counts. And to argue that she has 100% approval from 8 people 7 years ago is also completely irrelevant. That's like arguing "I was hired 7 years ago with no issues, why am I being fired now"? Also, I think it needs to be made clear, we're not voting to ban CodeCat -- I would not vote yes on such a ballot -- we're voting desysop her, which had been working out fine for that past year, and if she need some extra tools here and there, why can try and provide them. --Victar (talk) 16:43, 12 November 2017 (UTC)
    To repeat, becoming an admin is, partially, some award you get after x amount of edits. x may be the low. No one gets to be an admin after only 0 edits. I said "partially" because there are other factors involved, like quality of the edits. --Daniel Carrero (talk) 17:40, 12 November 2017 (UTC)
    And what I'm saying is having high edit counts is a causality, not a causation. --Victar (talk) 18:10, 12 November 2017 (UTC)
    Note: You broke my message in pieces. I'm OK with that, I'm not complaining at all. I added my signature in all pieces now.
    I guess I kinda understand what you mean, but you know I was already disagreeing with you in the first place and you didn't explain it much better now. Your last message is cryptic. I could try and explain your point, but to do that I would almost have try to read your mind. It's your job to make your point (if you are interested, of course) and I couldn't guarantee I'd do it well for you. Let's put it this way: everything is a causality and a causation to something. What is your point? --Daniel Carrero (talk) 18:46, 12 November 2017 (UTC)
    This is what I'm trying to say: w:Correlation does not imply causation. If edit counts were the basis of adminship, it would be automatically granted, sans voting, which it is not. --Victar (talk) 19:12, 12 November 2017 (UTC)
    OK. One more time, I agree with everything you are saying now. Nice. --Daniel Carrero (talk) 19:17, 12 November 2017 (UTC)
    This can be fact-checked, and shown not to be the case: "There are probably thousands of basic users with more edits than the admins on this page". Currently the admin in this page with most mainspace edits is Saltmarsh with 108,177 as per the most recent report.[1] Almost all the 11 other non-bots with more edits than him/her are admins too. --Daniel Carrero (talk) 17:40, 12 November 2017 (UTC)
    No, what I said was there are non-admins with higher edit counts that admins on this page, not higher than the admin with the highest edit count. You have not disproven that. --Victar (talk) 18:10, 12 November 2017 (UTC)
    Fair enough: There are non-admins with higher edit counts than admins on this page. I completely agree with you. That can be fact-checked and proved to be true. This is different than your previous claim ("There are probably thousands of basic users with more edits than the admins on this page"). We can write it off as, maybe that's what you were thinking the whole time and now you made yourself clearer -- if that's fine with you. --Daniel Carrero (talk) 18:46, 12 November 2017 (UTC)
    You're right, my mistake for not explaining my point clearly at first. --Victar (talk) 19:12, 12 November 2017 (UTC)
    Rua's first edit was in 2007 and she became an admin in 2010. That is, her work was known for 3 years before she became an admin. In my experience, apparently people often get hired in the real world without their work necessarily being known to all the other employees for 3 years. That's why in real life, apparently you often wouldn't be able to check for work issues before hiring someone.
    The 2010 admin vote has no bearing over whether the current vote passes or fails. You said "And to argue that she has 100% approval from 8 people 7 years ago is also completely irrelevant", but what do you think I'm arguing? I merely pointed out that if the current vote fails, it will confirm the 2010 decision that it's OK to let her be an admin. --Daniel Carrero (talk) 17:40, 12 November 2017 (UTC)
    I beg to differ. We have degrees, CVs, references, accolades for citing previous work. Also, just because you're a good employee 3 years in, doesn't mean you still are 7 years in, so my anecdote still stands. A decision fire some presently does not made a decision 7 years earlier to hire them wrong. --Victar (talk) 18:10, 12 November 2017 (UTC)
    I agree with everything you are saying now. Still, I merely pointed out that if the current vote fails, it will confirm the 2010 decision that it's OK to let her be an admin. I mean, confirm as of 2017. --Daniel Carrero (talk) 18:46, 12 November 2017 (UTC)
    Let us bask in the rare occasion that we both agree on something. Thanks for working through it with me. --Victar (talk) 19:12, 12 November 2017 (UTC)
    Alright, thank you. --Daniel Carrero (talk) 19:17, 12 November 2017 (UTC)
  6.   Oppose Per Angr and Donnanz. --Robbie SWE (talk) 17:41, 11 November 2017 (UTC)
  7.   Oppose. — Kleio (t · c) 23:39, 11 November 2017 (UTC)
  8.   OpposeSaltmarsh. 07:33, 12 November 2017 (UTC)
  9.   Oppose Ƿidsiþ 07:46, 12 November 2017 (UTC) I was asked to add a justification. Rua can be curt, but I don't see anything worse than that. Ƿidsiþ 15:48, 15 November 2017 (UTC)
  10.   Oppose A difficult person for sure, but also an immensely valuable editor. Crom daba (talk) 19:24, 12 November 2017 (UTC)
    @Crom daba I think it's certainly possible to still be a valuable and productive editor while not being an admin. In fact, I think most of CodeCat's value lies within the boundary of those tasks. --Victar (talk) 20:24, 12 November 2017 (UTC)
    I admit I do not understand clearly what privileges admins are granted, but I thought they were needed for most technical jobs where Rua contributes a lot. Crom daba (talk) 20:35, 12 November 2017 (UTC)
    Only template editorship is needed to edit most modules and templates, but adminship is needed to edit JavaScript gadgets and other things in the MediaWiki namespace. — Eru·tuon 20:43, 12 November 2017 (UTC)
  11.   OpposeJohnC5 12:45, 16 November 2017 (UTC)
  12.   Oppose Way too severe a sanction. Lingo Bingo Dingo (talk) 14:10, 16 November 2017 (UTC)


  Abstain On one hand, contributes a lot of good stuff, especially in modules. On the other hand, does so without proper consensus. —Aryaman (मुझसे बात करो) 16:27, 11 November 2017 (UTC)
  1.   Abstain. Honestly, I don't really want Rua to lose her admin bit, because it comes in handy now and again. But the issues are real, and the unfortunate flip side of not having an overbearing bureaucracy like 'pedia means that we don't really have any punishments to hand out besides desysopping. —Μετάknowledgediscuss/deeds 18:14, 11 November 2017 (UTC)
    @Metaknowledge, I don't think it should be really framed as a "punishment", but rather limiting someone's privileges to deter future conflicts. --Victar (talk) 21:29, 12 November 2017 (UTC)
    Isn't that the definition of a punishment? —Aryaman (मुझसे बात करो) 12:27, 13 November 2017 (UTC)
    Is enforcing a no-fly-zone for commercial planes a punishment to airline companies? --Victar (talk) 16:08, 13 November 2017 (UTC)
  2.   Abstain I see definite issues on both sides of this argument -- Rua has been prone to unilateral moves to reworking infrastructure that we all depend on, without doing enough consensus-building. And she has also been instrumental in a number of significant improvements.
    I'm on the fence here. If I lean either way, it's slightly towards not sysop: much of what she's done can be implemented by an editor without the sysop bit, and others have noted that her not being a sysop could help avoid certain kinds of conflict in future.
    I see several users who have voted without listing any reasons. Request: @DTLHS, Kleio, Saltmarsh, Widsith, would you be willing to add a rationale to your vote?
    Also, for @Rua herself, would you be willing to explain what you do that would require sysop privileges? Even a simple bulleted list would help.
    ‑‑ Eiríkr Útlendi │Tala við mig 19:12, 13 November 2017 (UTC)
    I voted against more or less per Angr. There are some things she could improve, but her behavior to me does not warrant sysopping at this time and I think she could do her work better with admin privileges. — Kleio (t · c) 01:41, 15 November 2017 (UTC)
    Some people seem to have said quite enough already :) — Saltmarsh. 07:37, 15 November 2017 (UTC)
  3.   Abstain Equinox 22:40, 14 November 2017 (UTC)
  4.   Abstain I have no horse in this race but I am surprised that I don't see much serious discussion of de-sysopping + Template Editor privileges. Either way, I am grateful for Rua's contributions and I dislike the off-putting atmosphere here (By "here" I mean at en.wikt in general, not on this particular discussion). —Justin (koavf)TCM 22:46, 14 November 2017 (UTC)
    "I dislike the off-putting atmosphere here" -- I feel you. The anonymity of the internet can make people respond quite harshly and cynically to even minor mistakes made in good faith by otherwise valuable editors. It's unfortunate. — Kleio (t · c) 01:41, 15 November 2017 (UTC)
  5.   Abstain As I am finally in long-winded enough mood to answer this vote, I drop what I think on the matter: I have mostly not been around when the contested “uncivilities” took place to perceive them to their full extent, but I am quite confident that the litigant people make mountains out of molehills. I do not see substantial evidence to back up a withdrawal of administrative rights, even if older corpus delicti is admissible I would suggest dismissal of the case in application of the de minimis rule, and it is rather striking how people rely on sentiments like “unemphaticness” and “disdainfulness” and “imperiousness”, all accidentialia. That seem to be real old-school typical qualities of a genial scientist, and the tact in applying the intellect is always more valuable than the amenity of the features of the behavior that expresses the intellect’s conclusions (this is not a matrimonial proceeding and you are not on a date with Rua to partake in her warmth). Such way the behavior of Rua fulfills the highest requirements of predictability – she is a handsome personality of one piece that services the claims brought upon her. I am more worried by what Wyang may commit in the future than by what Rua could commit. It is disgusting how much he sticks to trifles and courtesies like when I superficially appeared to side with Rua (which wasn’t even a trap) or he is “pissed” when a user obviously only very objectively referring to the objects of his address spoke of a stupid idea executed by Wyang and simply said “Stop.”. Some people, all of us sometimes, make mistakes by the attention not being sharpened, but Wyang indulges in being superficial. As seen in that long post where I appeared to side with Rua: Who has not treated the other as equal human being with opinions worth paying attention to? He leaves the ship when it burns instead of confronting the discontent. Granted, I would disprefer either as judge, but as for the standards needed for this project, Rua exceeds them fairly well, while Wyang should invest a bit more willpower to satisfy the expectations. Palaestrator verborum (loquier) 00:46, 15 November 2017 (UTC)
    diff. I definitely agree. Wyang (talk) 02:45, 15 November 2017 (UTC)
    This comment by Wyang only confirms the observation that Wyang acts completely arbitrarily and disregards arguments independently of how much reason there is in them. Also Stephen is a candidate for the same judgment as he abuses words for his pure comfort and calls texts nonsense that aren’t such. Or does he lack words to point out the lacunae in my argumentation strains because he is a child (it cannot be true biologically, considering the date he has already worked for Wiktionary)? There is no essential difference between children and adults in what relates to arguments, and it is obviously impossible that I am a child, just considering the times I write here in my approximate altitude, or the count of languages I know, or the style which is never seen on childs (you might argue on insanes, but that is also nothing in rem and not even necessarily bad in effect). What’s true is that how I talk has nothing to do with how they chatter on the streets, and elsewhere these days, but that is the worse for the current language and those who think they should speak modern, as dead languages like literary English are advantageous by being free of the recent prejudices of the unenlightened majority.
    Obviously Wyang cannot think how I do, for in that case memorizing all those Chinese tones &c. were not so much bearable. But this capacity is begotten by the very same trait which I have poked. The reluctance to do anything than to repeat what other people have recited, the expectation that everything can be cut into atoms of ideas conveyed instead of being a twisted hypotaxis, which is why in that post where I appeared to side with Rua he does nothing than to repeat the things which I and others already have said instead of treating the truth behind the words. A useful quality to pass school, eminence in being a normie, but of course completely dishonest.
    Alas, what do I talk so much? How can someone not be dishonest that posts a diff of an argumentless rant and “agrees”? That is below 4channers. Palaestrator verborum (loquier) 04:08, 15 November 2017 (UTC)
    Palaestrator, the more you write, the more naïve you look. If you are unable to express yourself clearly and concisely, the consequence is simply that your posts will be ignored. Not everyone has time for your ridiculously long passages. It just comes across as pretentious. Wyang (talk) 05:46, 15 November 2017 (UTC)
    This is honestly disappointing to read. I really shouldn't have bothered. —Aryaman (मुझसे बात करो) 16:00, 15 November 2017 (UTC)
    If you're trying to say civility and cordiality are irrelevant to one's role as an admin, I completely disagree. This project is built upon community and cooperation -- building on the foundation of others. I also want to stress that this vote should not be made into a Wyang v. CodeCat issue, because it is not. --Victar (talk) 07:38, 15 November 2017 (UTC)
    It's "Wyang". "Wang" is something rather different... —Μετάknowledgediscuss/deeds 07:52, 15 November 2017 (UTC)
    Victar, are you implying that Wyang is a d*ck? If yes, I disagree, I find him very nice. --2A02:2788:A4:F44:20C7:30E9:F585:19D6 10:20, 15 November 2017 (UTC)
    Looks to be an honest (but unfortunate) typo to me. —Aryaman (मुझसे बात करो) 16:03, 15 November 2017 (UTC)
    Oh no, I rather point out the weighting. Civility and cordiality are nice to have. But I imagine community and cooperation in a cold way, i.e. cold reason, which is hard to fit into the crude manners of the everyday language. It reminds me of that post of Linus Torvalds from July 15th, 2013. Better be a bit more pretentious, i.e. have pretensions, than simplifying all indiscriminately by the superficiality of being “clear and concise”. Possibly I am going a bit into the other extreme (opposite to posting votes without explanations). But sadly Wyang is habitually neither cordial nor intellectual. That’s why I say he should invest more willpower, and why I find it comparatively displaced to reprove Rua who tries hard to expound her solutions rather than trying to swim below the radar. There is nothing naïve in exerting oneself. Palaestrator verborum (loquier) 14:38, 15 November 2017 (UTC)
    I believe some of us are trying to say that CodeCat doesn't need her admin status to continue her work, particularly if you give her template editor access. That would prevent her from deleting and locking articles, and require her to use consensus gathering and communication, something she otherwise tries to avoid, from my experience. It's worked out well the past year, in my opinion. --Victar (talk) 15:32, 15 November 2017 (UTC)
  6.   Abstain Leasnam (talk) 02:02, 15 November 2017 (UTC)


Placing Wikidata ID in sense ID of proper nouns

Voting on: Placing Wikidata ID (e.g. Q174193) in sense ID of proper nouns. For example, changing

# A [[kingdom]] and [[sovereign]] [[state]] in [[Western Europe]] comprising the four countries of [[England]], [[Scotland]] and [[Wales]] in the island of [[Great Britain]], and [[Northern Ireland]] in the island of [[Ireland]]. Since 1922.
# {{lb|en|historical}} The [[United Kingdom of Great Britain and Ireland]] (1801–1922)
# {{lb|en|historical|informal}} The [[Kingdom of Great Britain]] (1707-1801)


# {{senseid|en|Q145}}A [[kingdom]] and [[sovereign]] [[state]] in [[Western Europe]] comprising the four countries of [[England]], [[Scotland]] and [[Wales]] in the island of [[Great Britain]], and [[Northern Ireland]] in the island of [[Ireland]]. Since 1922.
# {{senseid|en|Q174193}}{{lb|en|historical}} The [[United Kingdom of Great Britain and Ireland]] (1801–1922)
# {{senseid|en|Q161885}}{{lb|en|historical|informal}} The [[Kingdom of Great Britain]] (1707-1801)

The template used is {{senseid}}.


  • Vote starts: 00:00, 19 November 2017 (UTC)
  • Vote ends: 23:59, 18 December 2017 (UTC)
  • Vote created: Dan Polansky (talk) 09:28, 12 November 2017 (UTC)






Restricting Thesaurus to English

Voting on: Restricting Wiktionary:Thesaurus to English, moving current content of non-English thesaurus entries to the mainspace and then deleting the non-English entries.

Rationale: see Wiktionary talk:Votes/pl-2017-11/Restricting Thesaurus to English#Rationale. The voters only vote on the proposed action, not on the rationale.


  • Vote starts: 00:00, 22 November 2017 (UTC)
  • Vote ends: 23:59, 20 January 2018 (UTC)
  • Vote created: Dan Polansky (talk) 10:18, 15 November 2017 (UTC)






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: