Wiktionary:Votes

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


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


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


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


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


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

Other

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
Aug 22 Gallery 33 (13 people)
Aug 26 Rename the Wikisaurus namespace 38 (10 people)
Oct 4 Templatizing topical categories in the mainspace 2 11 (6 people)
Oct 19 Rename categories Symbol support vote.svg4 Symbol oppose vote.svg2 Symbol abstain vote.svg0
Sep 3 User:Koavf for checkuser Symbol support vote.svg2 Symbol oppose vote.svg2 Symbol abstain vote.svg0
(=5) [Wiktionary:Table of votes] (=92)

Gallery

Voting on:

Proposal 1:

Allowing the "Gallery" section to be freely used in entries, as per the specifications below.
  • Purpose:
    Listing images using the tags <gallery></gallery>.
  • Style:
    Edit mw:Manual:$wgGalleryOptions (through a Phabricator request) to apply "mode=packed" by default in all galleries.
    After the default configuration above is applied, allow bots to remove the superfluous code "mode=packed" from all galleries that use it.
    ("mode=packed" produces a centered gallery with significantly less wasted space around each image, and causes all images to be the same height)
  • Section level:
    Generally, the same as currently used for "See also", "Further reading" and "References".
    "Gallery" can be a level 3 section that applies to any and all POS sections of the current language.
    "Gallery" can be a subsection of the section to which it applies: for example, a level 3 "Noun" can have a level 4 "Gallery".
  • Section placement:
    After the POS section(s), "Usage notes", "Inflection", "Declension", "Conjugation", "Mutation", "Quotations", "Alternative forms", "(...)nyms", "Coordinate terms", "Derived terms", "Related terms", "Descendants", "Translations", "Trivia".
    Before "See also", "References", "Further reading", "Anagrams".
  • Procedural note:
    If the proposal 1 fails, then the proposals 2 and 3 below are void.

Proposal 2:

Disallowing the use of the "Gallery" section with fewer than three images.
(Naturally, if the proposal 2 fails, then galleries with any number of images — including one or two images — will be permitted.)

Proposal 3:

Allowing {{commonslite}} (an inline template that links to Wikimedia Commons) to be placed in the "Gallery" section when it links to galleries or image categories.
Allowing, too, {{commonslite}} to be placed in an otherwise empty "Gallery" section (i.e., a "Gallery" section with zero images), even if "Gallery" sections with fewer than three images are disallowed as per the proposal 2.
Allowing bots to move all instances of {{commonslite}} from "Further reading", "See also", or "External links" to "Gallery".
Layout rule: If the "Gallery" section contains both a gallery and {{commonslite}}, then the gallery must be placed above the {{commonslite}}.

Example:

(this example is merely illustrative -- supporting this vote does not imply supporting the existence of three separate pictures of kittens at kitten)

Wikitext Result
==English==

===Noun===
{{en-noun}}

# ...

===Gallery===
<gallery>
Stray kitten Rambo002.jpg|One kitten
Louis-&-Chanel-taking-a-nap.jpg|Two kittens
Abykitten.jpg|Three kittens
</gallery>
* {{commonslite}}

English

Noun

kitten (plural kittens)

  1. ...

Gallery

Entries with "Gallery" sections as of 21 July 2017:

(Note: As of this date — which is before the vote started — all existing galleries in entries were moved to a "Gallery" section.)

Schedule:

  • Vote starts: 00:00, 24 July 2017 (UTC)
  • Vote ends: 23:59, 22 August 2017 (UTC)
  • Vote created: --Daniel Carrero (talk) 11:36, 17 July 2017 (UTC)

Discussion:

Support: Proposal 1 (allowing "Gallery" sections)

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 08:54, 24 July 2017 (UTC)
  2. Symbol support vote.svg Support - DonnanZ (talk) 11:30, 24 July 2017 (UTC)
  3. Symbol support vote.svg Support -Xbony2 (talk) 19:43, 27 July 2017 (UTC)
  4. Symbol support vote.svg SupportVorziblix (talk · contribs) 17:56, 10 August 2017 (UTC)

Oppose: Proposal 1 (allowing "Gallery" sections)

  1. Symbol oppose vote.svg Oppose. Images should be included only to supplement the definition(s) of a term. Anything that would make sense to include in a gallery section doesn't belong on Wiktionary at all. --WikiTiki89 18:10, 25 July 2017 (UTC)
  2. Symbol oppose vote.svg Oppose. Awful idea. Go to WikiCommons if you want a gallery. --Victar (talk) 19:14, 25 July 2017 (UTC)
    Actually, WikiCommons often has a lot of images per gallery. Here on Wiktionary we have like one image per sense. That's an important difference. And some entries have more senses than most, and galleries to match, like line and head. --Daniel Carrero (talk) 19:32, 25 July 2017 (UTC)
    Oppose --Victar (talk) 19:36, 25 July 2017 (UTC)
    @Victar: What would you like to do with the images currently in the two entries I mentioned above? --Daniel Carrero (talk) 19:42, 25 July 2017 (UTC)
    Delete them. You could have thousands of photos of different uses of "head". As said above, images are supplements, not to be used as definitions themselves. Unless someone else has a comment, that's all I'm going to say. --Victar (talk) 19:51, 25 July 2017 (UTC)
    I would delete most of them, and keep a few of the more necessary ones as thumbnails to the right of the definitions, as we have always been doing. --WikiTiki89 20:16, 25 July 2017 (UTC)
  3. Symbol oppose vote.svg Oppose On the one hand we want Synonyms to appear under definitions, but for image-based ostensive definitions we want them separate? What about definitions that support etymogies? We could well encourage the use of "NNNpx" eg, 160px, 80px to reduce images to a size that enable them to appear next to appropriate definition. I'm sorry: I must have missed the prior discussion. Where is it? DCDuring (talk) 12:14, 26 July 2017 (UTC)
    @DCDuring: The prior discussions are in the vote description itself. --Daniel Carrero (talk) 12:17, 26 July 2017 (UTC)
    Sorry. I should have said discussions meaningfully connecting specific proposals to specific problems and indicating a possible consensus, preferably with more than half the content from participants other than the proposer. DCDuring (talk) 12:26, 26 July 2017 (UTC)
    The June 2017 discussion does have a consensus in favor of allowing Gallery sections. But I don't think votes should be created only after there's already consensus in the discussion. I suppose you disagree with me on that? --Daniel Carrero (talk) 12:34, 26 July 2017 (UTC)
  4. Symbol oppose vote.svg Oppose They just look really ugly to me. Equinox 16:23, 26 July 2017 (UTC)
  5. Symbol oppose vote.svg Oppose --Droigheann (talk) 21:53, 27 July 2017 (UTC)
  6. Symbol oppose vote.svg OpposeSaltmarsh. 05:22, 3 August 2017 (UTC)
  7. Symbol oppose vote.svg Oppose Ƿidsiþ 12:31, 12 August 2017 (UTC)
  8. Symbol oppose vote.svg Oppose. Images are most helpful when they are alonside the definitions, not far below them. I also think images should be limited to the way they're used in illustrated print dictionaries, i.e. simply illustrating something that can't be fully captured in a written definition. I think we should therefore have images for every taxon, as well as the majority of concrete objects, such as tools, musical instruments, household items, etc. I oppose having images for more abstract senses, adjectives, or verbs (I'm not entirely opposed to GIFs for verbs, provided they're used sparingly). There shouldn't be so many images that we need to relegate them to a gallery. The French Wiktionary handles images in a very balanced way, IMO. See botte, for example. Andrew Sheedy (talk) 19:38, 20 August 2017 (UTC)

Abstain: Proposal 1 (allowing "Gallery" sections)

  1. Symbol abstain vote.svg Abstain I can't bring myself to think more deeply about this; the proposal is not passing anyway. I don't think galleries are necessarily a bad thing; some entries would benefit from our having rather many images, and these would fit poorly at the right since there they can take only one column. Some entries had gallery sections without the gallery heading, directly under definitions, and that seemed fine. --Dan Polansky (talk) 19:54, 20 August 2017 (UTC)

Support: Proposal 2 (forbidding "Gallery" sections with fewer than three images)

Oppose: Proposal 2 (forbidding "Gallery" sections with fewer than three images)

  1. Symbol oppose vote.svg Oppose per Wiktionary talk:Votes/pl-2017-07/Gallery#oppose proposal 2. --Daniel Carrero (talk) 08:55, 24 July 2017 (UTC)
  2. Symbol oppose vote.svg Oppose --Victar (talk) 19:14, 25 July 2017 (UTC)
  3. Symbol oppose vote.svg Oppose Seems arbitrary, unnecessary, possibly stupid. DCDuring (talk) 12:16, 26 July 2017 (UTC)
  4. Symbol oppose vote.svg Oppose As noted below in "abstain" section. I wonder whether a couple of users have misread the wording of this particular vote. DonnanZ (talk) 16:33, 26 July 2017 (UTC)
  5. Symbol oppose vote.svg Oppose -Xbony2 (talk) 19:45, 27 July 2017 (UTC)

Abstain: Proposal 2 (forbidding "Gallery" sections with fewer than three images)

  1. Symbol abstain vote.svg Abstain - I'm not sure about this one. It is possible to place images side by side using "left", "centre" or "center", and "right". DonnanZ (talk) 11:36, 24 July 2017 (UTC)
    I made an attempt a while ago with side-by-side images at gravel road. Some feedback would be useful. DonnanZ (talk) 12:35, 26 July 2017 (UTC)
    @Donnanz: I saw the entry on my PC and took a screenshot. Here it is: File:gravel road entry.png.
    Thanks for the idea, but I found three problems with it which I was hoping could be fixed:
    1. The images are too far apart.
    2. The "Translations" heading got moved a bit to the right, which is awkward.
    3. The images are currently in a "Derived terms" section. I quite like the proposal of specifically using a section named "Gallery" as proposed in this vote. I can't speak for everyone, but I prefer keeping "Derived terms" sections with derived terms only, and using "Gallery" sections for galleries.
    --Daniel Carrero (talk) 12:46, 26 July 2017 (UTC)
    OK, maybe you're using a wider monitor than me. Can you try reformatting it using gallery templates or shall I? DonnanZ (talk) 13:03, 26 July 2017 (UTC)
    My monitor resolution usually is (and currently is) 1920x1080. What about the use of {{multiple images}} at trousseau? See also Special:WhatLinksHere/Template:multiple images. --Daniel Carrero (talk) 13:22, 26 July 2017 (UTC)
    Multiple images is complex, I prefer a simpler solution. I have experimented by adding a gallery to gravel road, leaving the old layout there for comparison for the time being. I tried both with and without "mode=packed", the result seems slightly off-centre to me but that may be an optical illusion. Anyway I can give galleries with less than three images the thumbs-up, it looks OK-ish, and I'm changing my vote to oppose a ban on less than 3 images. DonnanZ (talk) 16:29, 26 July 2017 (UTC)
    Thank you for checking different styles. It helps, to see if the vote is going on the right track. If you had found some other better style we could talk about implementing that instead. --Daniel Carrero (talk) 17:53, 26 July 2017 (UTC)
  2. Symbol abstain vote.svg Abstain --WikiTiki89 18:10, 25 July 2017 (UTC)
  3. Symbol abstain vote.svg Abstain --Droigheann (talk) 21:54, 27 July 2017 (UTC)
  4. Symbol abstain vote.svg AbstainVorziblix (talk · contribs) 17:56, 10 August 2017 (UTC)
  5. Symbol abstain vote.svg Abstain. I think entries should rarely have more than three images, and when they do, a gallery section is not the solution. Andrew Sheedy (talk) 19:39, 20 August 2017 (UTC)

Support: Proposal 3 (allowing "commonslite" in "Gallery" sections)

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 08:55, 24 July 2017 (UTC)
  2. Symbol support vote.svg Support - DonnanZ (talk) 11:32, 24 July 2017 (UTC)
  3. Symbol support vote.svg Support -Xbony2 (talk) 19:45, 27 July 2017 (UTC)
  4. Symbol support vote.svg SupportVorziblix (talk · contribs) 17:56, 10 August 2017 (UTC)

Oppose: Proposal 3 (allowing "commonslite" in "Gallery" sections)

  1. Symbol oppose vote.svg Oppose --WikiTiki89 18:10, 25 July 2017 (UTC)
  2. Symbol oppose vote.svg Oppose --Victar (talk) 19:14, 25 July 2017 (UTC)
  3. Symbol oppose vote.svg Oppose Ugly. DCDuring (talk) 12:15, 26 July 2017 (UTC)
  4. Symbol oppose vote.svg Oppose --Droigheann (talk) 21:57, 27 July 2017 (UTC)
  5. Symbol oppose vote.svg OpposeSaltmarsh. 05:23, 3 August 2017 (UTC)
  6. Symbol oppose vote.svg Oppose. Andrew Sheedy (talk) 19:40, 20 August 2017 (UTC)

Abstain: Proposal 3 (allowing "commonslite" in "Gallery" sections)

Decision


Rename the Wikisaurus namespace

Voting on:

Proposal 1: Aliasing (i.e., automatically redirecting) "Thesaurus:" to "Wikisaurus:".

(examples: Thesaurus:goodWikisaurus:good, Thesaurus:beverageWikisaurus:beverage, etc.)

Proposal 2: Aliasing (i.e., automatically redirecting) "Synonyms:" to "Wikisaurus:".

(examples: Synonyms:goodWikisaurus:good, Synonyms:beverageWikisaurus:beverage, etc.)

Proposal 3: Moving all the (otherwise unchanged) contents of "Wikisaurus:" to either "Thesaurus:" or "Synonyms:", while keeping "Wikisaurus:" as a namespace alias.

Part 1: Vote whether the namespace should be renamed in the first place.
Part 2: Vote on which of the names should be chosen.
Procedural note: If the "part 1" vote fails, then the "part 2" vote is void.
(naturally, if "Wikisaurus:" is renamed, then any alias approved in the previous proposals will redirect to the new namespace name, unless the alias itself is the new main name of the namespace)

Schedule:

  • Vote starts: 00:00, 28 July 2017 (UTC)
  • Vote ends: 23:59, 26 August 2017 (UTC)
  • Vote created: Equinox 20:37, 21 July 2017 (UTC)

Discussion:

Proposal 1: "Thesaurus:" as an alias

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 12:31, 28 July 2017 (UTC)
  2. Symbol support vote.svg Support. I don't see why not. -Xbony2 (talk) 16:05, 29 July 2017 (UTC)
  3. Symbol support vote.svg Support Equinox 16:09, 29 July 2017 (UTC)
  4. Symbol support vote.svg Support Only if renaming the namespace to Thesaurus cannot be done; oppose otherwise. Since, if the namespace will be called Thesaurus, there will of course be no alias Thesaurus. --Dan Polansky (talk) 09:39, 30 July 2017 (UTC)
    Well, I sort of think that's implied :P although the vote itself isn't too specific so your safety net is well-noted. If need be my vote should be counted in the same fashion -Xbony2 (talk) 20:22, 30 July 2017 (UTC)
    This possibility was predicted in the note in the vote description that starts with: "naturally, if "Wikisaurus:" is renamed, ..." --Daniel Carrero (talk) 20:25, 30 July 2017 (UTC)
  5. Symbol support vote.svg SupportEru·tuon 06:44, 1 August 2017 (UTC)
  6. Symbol support vote.svg SupportVorziblix (talk · contribs) 18:01, 10 August 2017 (UTC)
  7. Symbol support vote.svg Support - TheDaveRoss 15:04, 16 August 2017 (UTC)

Oppose

Abstain

Proposal 2: "Synonyms:" as an alias

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 12:31, 28 July 2017 (UTC)
  2. Symbol support vote.svg Support. I don't see why not. -Xbony2 (talk) 16:05, 29 July 2017 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose Since the pages are not only for synonyms, this would be inaccurate. "Synonyms" is not even shorter to type than "Thesaurus:". A shorter and still reasonably accurate alias would be "Nyms:", even though Wikisaurus does not cover certain -nym relations such as homonyms; it covers synonyms, antonyms, hyponyms, hypernyms, holonyms and meronyms. --Dan Polansky (talk) 08:19, 30 July 2017 (UTC)
  2. Symbol oppose vote.svg Oppose per User:Dan Polansky. PseudoSkull (talk) 06:09, 1 August 2017 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain – Synonyms are one of the semantic relations covered by the namespace (though I would guess the most numerous one), and it wouldn't exactly hurt to use the word as a redirect. But to be consistent, all the -nyms that Dan Polansky listed above should be redirects as well. — Eru·tuon 06:44, 1 August 2017 (UTC)
  2. Symbol abstain vote.svg AbstainVorziblix (talk · contribs) 18:01, 10 August 2017 (UTC)
  3. Symbol abstain vote.svg Abstain __Gamren (talk) 13:44, 19 August 2017 (UTC)

Proposal 3, part 1: Move all contents of "Wikisaurus:" to either "Thesaurus:" or "Synonyms:"

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 12:31, 28 July 2017 (UTC)
  2. Symbol support vote.svg Support -Xbony2 (talk) 16:05, 29 July 2017 (UTC)
  3. Symbol support vote.svg Support Equinox 16:09, 29 July 2017 (UTC)
  4. Symbol support vote.svg Support Move all contents of "Wikisaurus:" to "Thesaurus:", ideally (not necessarily) by renaming the namespace to Thesaurus and aliasing Wikisaurus to that namespace; oppose for "Synonyms:". --Dan Polansky (talk) 08:23, 30 July 2017 (UTC)
  5. Symbol support vote.svg Support – Only if "Thesaurus" is chosen. — Eru·tuon 06:44, 1 August 2017 (UTC)
  6. Symbol support vote.svg Support if moved to "Thesaurus:"--Barytonesis (talk) 12:01, 2 August 2017 (UTC)
  7. Symbol support vote.svg Support if and only if it’s to ‘Thesaurus:’ — Vorziblix (talk · contribs) 18:01, 10 August 2017 (UTC)
  8. Symbol support vote.svg Support - TheDaveRoss 15:05, 16 August 2017 (UTC)
  9. Symbol support vote.svg Support __Gamren (talk) 13:44, 19 August 2017 (UTC)

Oppose

Abstain

Proposal 3, part 2: If the proposal 3, part 1, passes, what should the name be?

"Thesaurus:"

Support
  1. Symbol support vote.svg Support --Daniel Carrero (talk) 12:31, 28 July 2017 (UTC)
  2. Symbol support vote.svg Support -Xbony2 (talk) 16:06, 29 July 2017 (UTC)
  3. Symbol support vote.svg Support Equinox 16:09, 29 July 2017 (UTC)
  4. Symbol support vote.svg Support --Dan Polansky (talk) 08:24, 30 July 2017 (UTC)
  5. Symbol support vote.svg SupportEru·tuon 06:44, 1 August 2017 (UTC)
  6. Symbol support vote.svg Support --Barytonesis (talk) 12:01, 2 August 2017 (UTC)
  7. Symbol support vote.svg SupportVorziblix (talk · contribs) 18:01, 10 August 2017 (UTC)
  8. Symbol support vote.svg Support Will already be familiar to users. Also, using wiki- as a prefix strikes me as sort of whimsical.__Gamren (talk) 13:44, 19 August 2017 (UTC)
Oppose
Abstain
  1. Symbol abstain vote.svg Abstain I liked the name Wikisaurus, but Thesaurus does sound a bit more appropriate and formal. I can't decide which I'd rather have. PseudoSkull (talk) 06:14, 1 August 2017 (UTC)

"Synonyms:"

Support
Oppose
  1. Symbol oppose vote.svg Oppose. There are antonyms, hypernyms, hyponyms, etc., not just synonyms. --Daniel Carrero (talk) 12:31, 28 July 2017 (UTC)
  2. Symbol oppose vote.svg Oppose per above. -Xbony2 (talk) 16:06, 29 July 2017 (UTC)
  3. Symbol oppose vote.svg Oppose per Daniel C. --Dan Polansky (talk) 08:24, 30 July 2017 (UTC)
  4. Symbol oppose vote.svg Oppose per above. PseudoSkull (talk) 06:12, 1 August 2017 (UTC)
  5. Symbol oppose vote.svg OpposeEru·tuon 06:44, 1 August 2017 (UTC)
  6. Symbol oppose vote.svg OpposeVorziblix (talk · contribs) 18:01, 10 August 2017 (UTC)
Abstain

Decision


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.

Schedule:

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

Discussion:

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)

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)

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)

Decision


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:

Topic

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.

Schedule:

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

Discussion:

Support

  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)

Oppose

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

Abstain

Decision


User:Koavf for checkuser

Nomination: I hereby nominate User:Koavf as a local English Wiktionary CheckUser. We need a second active CheckUser so that User:TheDaveRoss can regain his powers (per WMF policy, at least two need to be active or the remaining one gets suspended). He is a CheckUser at Wikispecies, so he is already vetted by WMF and knows how the tools work. Additionally, I think there is a benefit in having a non-admin who is nevertheless a longtime trusted editor have this right.

Schedule:

  • Vote starts: 23:40, 21 August 2017 (UTC)
  • Vote ends: 23:59, 4 September 2017 (UTC)
  • Vote created: —Μετάknowledgediscuss/deeds 23:40, 20 August 2017 (UTC)

Acceptance: Accepted, thank you. Please let me know any questions or concerns you have. Note that I already have these rights on Wikispecies and have used them (in addition to non-WMF wikis like WikiIndex). —Justin (koavf)TCM 15:06, 21 August 2017 (UTC)

Support

  1. Symbol support vote.svg Support as nom. Regardless of admin status, we need a second active checkuser. —Μετάknowledgediscuss/deeds 19:43, 21 August 2017 (UTC)
  2. Symbol support vote.svg Support conditional on admin status, since it seems impossible to effectively be a checkuser without also being an admin. DTLHS (talk) 19:44, 21 August 2017 (UTC)
    @DTLHS: I urge you to reconsider that conditionality. Even if you believe that to be the case, this vote enables TheDaveRoss to regain his checkuser status. —Μετάknowledgediscuss/deeds 19:46, 21 August 2017 (UTC)
    If we only have one effective checkuser then we're subverting the rule to require at least two. We should either have two useful checkusers or none. DTLHS (talk) 19:53, 21 August 2017 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose. Nothing personal, I just think there are much better candidates for checkuser status who are long-time admins here at Wiktionary. --WikiTiki89 16:41, 22 August 2017 (UTC)
    @Wikitiki89: Then make a vote and nominate one. —Μετάknowledgediscuss/deeds 16:44, 22 August 2017 (UTC)
    I don't like being in position to pick any single editor, but my top choices would probably be User:Stephen G. Brown, User:SemperBlotto, User:-sche, and User:Angr. --WikiTiki89 17:16, 22 August 2017 (UTC)
  2. Symbol oppose vote.svg Oppose -Xbony2 (talk) 21:20, 22 August 2017 (UTC)

Abstain

Decision


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: