Definition from Wiktionary, the free dictionary
Jump to: navigation, search

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-10/Title of vote}}

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

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

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

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

{{Wiktionary:Votes/bt-2017-10/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 4 Templatizing topical categories in the mainspace 2 decision?
Oct 19 Rename categories decision?
Nov 1 User:Chuck Entz for checkuser Symbol support vote.svg19 Symbol oppose vote.svg0 Symbol abstain vote.svg0
(=3) [Wiktionary:Table of votes] (=54)

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)
  • Vote created: Dan Polansky (talk) 09:19, 30 July 2017 (UTC)


Support for cat

  1. Symbol support vote.svg 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. Symbol support vote.svg Support -Xbony2 (talk) 01:37, 9 August 2017 (UTC)
  3. Symbol support vote.svg Support, same reasons as in the previous vote. — Vorziblix (talk · contribs) 18:07, 10 August 2017 (UTC)
  4. Symbol support vote.svg Support Ƿidsiþ 12:32, 12 August 2017 (UTC)

Oppose for cat

  1. Symbol oppose vote.svg Oppose DonnanZ (talk) 20:03, 8 August 2017 (UTC)
  2. Symbol oppose vote.svg 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. Symbol oppose vote.svg 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

Support for c

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

Oppose for c

  1. Symbol oppose vote.svg Oppose. Same as above, except worse. —CodeCat 20:11, 8 August 2017 (UTC)
  2. Symbol oppose vote.svg Oppose. It will mess up MediaWiki:Gadget-HotCat.jsInternoob 01:12, 27 August 2017 (UTC)

Abstain for c

  1. Symbol abstain vote.svg 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)


  • 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)

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. Symbol support vote.svg Support --Daniel Carrero (talk) 13:39, 22 August 2017 (UTC)
  2. Symbol support vote.svg SupportCodeCat 14:11, 22 August 2017 (UTC)
  3. Symbol support vote.svg Support DTLHS (talk) 18:51, 22 August 2017 (UTC)
  4. Symbol support vote.svg Support -Xbony2 (talk) 21:21, 22 August 2017 (UTC)
  5. Symbol support vote.svg Support Pariah24 (talk) 14:21, 23 August 2017 (UTC)
  6. Symbol support vote.svg Support (though see my comments in the "Abstain" section below for a suggested compromise). — SGconlaw (talk) 10:28, 30 August 2017 (UTC)
  7. Symbol support vote.svg 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. Symbol support vote.svg 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. Symbol support vote.svg Support per Suzukaze and Stelio. DCDuring (talk) 15:53, 3 October 2017 (UTC)


  1. Symbol oppose vote.svg 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. Symbol oppose vote.svg 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. Symbol oppose vote.svg OpposeAryaman (मुझसे बात करो) 14:02, 23 August 2017 (UTC)
  4. Symbol oppose vote.svg 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. Symbol oppose vote.svg Oppose. Wyang (talk) 09:13, 24 August 2017 (UTC)
  6. Symbol oppose vote.svg OpposeΜετάknowledgediscuss/deeds 06:10, 1 September 2017 (UTC)
  7. Symbol oppose vote.svg 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. Symbol oppose vote.svg OpposeZ. [ קהת ] b"A. — 14:19, 3 September 2017 (UTC)
  9. Symbol oppose vote.svg Oppose. — justin(r)leung (t...) | c=› } 20:19, 8 September 2017 (UTC)
  10. Symbol oppose vote.svg 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. Symbol oppose vote.svg Oppose. Crom daba (talk) 20:21, 19 October 2017 (UTC)
  12. Symbol oppose vote.svg 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)


  • Symbol abstain vote.svg 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)
  • Symbol abstain vote.svg 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)


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. Symbol support vote.svg Support - TheDaveRoss 20:39, 11 October 2017 (UTC)
  2. Symbol support vote.svg Support Highly trusted and helpful user. —Justin (koavf)TCM 20:43, 11 October 2017 (UTC)
  3. Symbol support vote.svg 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. Symbol support vote.svg Support Already an experienced sysop and helpful editor. —Aryaman (मुझसे बात करो) 00:48, 12 October 2017 (UTC)
  5. Symbol support vote.svg 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. Symbol support vote.svg Support Wyang (talk) 03:08, 12 October 2017 (UTC)
  7. Symbol support vote.svg Support — justin(r)leung (t...) | c=› } 03:33, 12 October 2017 (UTC)
  8. Symbol support vote.svg Support No doubt in my mind that Chuck is the right choice. --Robbie SWE (talk) 17:04, 12 October 2017 (UTC)
  9. Symbol support vote.svg 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. Symbol support vote.svg Support --Vahag (talk) 17:43, 13 October 2017 (UTC)
  12. Symbol support vote.svg Support --Dan Polansky (talk) 21:00, 13 October 2017 (UTC)
  13. Symbol support vote.svg Support Ks0stm (TCE) 23:03, 13 October 2017 (UTC)
  14. Symbol support vote.svg SupportVorziblix (talk · contribs) 18:06, 14 October 2017 (UTC)
  15. Symbol support vote.svg SupportTAKASUGI Shinji (talk) 06:56, 15 October 2017 (UTC)
  16. Symbol support vote.svg Support Lingo Bingo Dingo (talk) 13:59, 16 October 2017 (UTC)
  17. Symbol support vote.svg 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. Symbol support vote.svg SupportAɴɢʀ (talk) 09:50, 20 October 2017 (UTC)
  19. Symbol support vote.svg Support -Xbony2 (talk) 20:04, 20 October 2017 (UTC)
  20. Symbol support vote.svg Support Yes, of course. bd2412 T 02:00, 21 October 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: