Wiktionary

Wiktionary:Votes

Wiktionary > Votes

Shortcuts:
WT:VOTE
WT:VOTES
WT:V

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 to the “active” list 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.

Before clicking the “Start a new vote!” button below, change “Title of vote” in the field just above the button to a short descriptive title. Once you have created your vote, add it to the list at Wiktionary:Votes/Active.


{{Wiktionary:Votes/2023-03/Title of vote}}


{{Wiktionary:Votes/pl-2023-03/Title of vote}}


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


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


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


{{Wiktionary:Votes/bt-2023-03/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)
EndsTitleStatus/Votes
Mar 16Removing the horizontal rulepassed
Mar 18Vote creation eligibilityfailed
Mar 26THUB amendmentfailed
Apr 30Allow "Clitic" as a POS headerstarts: Apr 1
(=4)[Wiktionary:Table of votes](=71)

Removing the horizontal rule

Voting on: Removing the horizontal rule ---- between language section because of its redundancy. Furthermore, it has been assured that the visual outcome can be reached with a simple CSS snippet. See BP discussion link below for more.

Schedule:

  • Vote starts: 00:00, 15 February 2023 (UTC)
  • Vote ends: 23:59, 16 March 2023 (UTC)
  • Vote created: Catonif (talk) 20:13, 8 February 2023 (UTC)Reply[reply]

Discussion:

Support

  1.   Support. Annoying for new users to remember, apparently a hassle for bot operators, does nothing visually that can't be achieved automatically by CSS. —Al-Muqanna المقنع (talk) 00:56, 15 February 2023 (UTC)Reply[reply]
  2.   Support, same reasons as Al-Muqanna. Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 02:28, 15 February 2023 (UTC)Reply[reply]
  3.   Support — SURJECTION / T / C / L / 05:14, 15 February 2023 (UTC)Reply[reply]
  4.   Support. Catonif (talk) 06:52, 15 February 2023 (UTC)Reply[reply]
  5.   Support Since another solution has been presented. Vininn126 (talk) 08:16, 15 February 2023 (UTC)Reply[reply]
  6.   Support Per the above points and my discussion in the abstain section below. --Overlordnat1 (talk) 12:07, 15 February 2023 (UTC)Reply[reply]
  7.   Support Same reasons as Al-Muqanna.--Ser be être 是talk/stalk 12:25, 15 February 2023 (UTC)Reply[reply]
  8.   Support Always found the bar annoying. Nicodene (talk) 14:30, 15 February 2023 (UTC)Reply[reply]
  9.   Support Easier for humans, easier for bots JeffDoozan (talk) 18:36, 15 February 2023 (UTC)Reply[reply]
  10.   Support. — excarnateSojourner (talk · contrib) 18:53, 15 February 2023 (UTC)Reply[reply]
  11.   Support and good riddance. Ioaxxere (talk) 19:44, 15 February 2023 (UTC)Reply[reply]
  12.   Support Per everyone else's reasons. Benwing2 (talk) 03:34, 16 February 2023 (UTC)Reply[reply]
  13.   Support — Fenakhay (حيطي · مساهماتي) 03:50, 16 February 2023 (UTC)Reply[reply]
  14.   Support Allahverdi Verdizade (talk) 10:34, 16 February 2023 (UTC)Reply[reply]
  15.   Support Bogdan (talk) 10:51, 16 February 2023 (UTC)Reply[reply]
  16.   Support ←₰-→ Lingo Bingo Dingo (talk) 17:42, 16 February 2023 (UTC)Reply[reply]
  17.   Support Since the horizontal lines will still show up on the entry, and there's never a scenario where an L2 header wouldn't require a horizontal line, then there's no harm in passing the repetitive work off of the editor and onto CSS. Just get rid of the horizontal rule altogether. – Guitarmankev1 (talk) 14:15, 17 February 2023 (UTC)Reply[reply]
  18.   Support per above. Megathonic (talk) 14:56, 17 February 2023 (UTC)Reply[reply]
  19.   Support I guess we can have better results with CSS and an informational value is not there. Fay Freak (talk) 14:37, 18 February 2023 (UTC)Reply[reply]
  20.   Support We can achieve a similar result more efficiently. John Cross (talk) 08:37, 26 February 2023 (UTC)Reply[reply]
  21.   Support Kinda thing that should be handled with CSS or header templates so it can be modified without a bot run. kwami (talk) 07:17, 27 February 2023 (UTC)Reply[reply]
  22.   Support Was ugly for readers, and annoying for all editors, not only new ones, to check every time whether they needed to place it on top or bottom of their new entry. Daniel.z.tg (talk) 04:49, 2 March 2023 (UTC)Reply[reply]
  23.   Support - Sarilho1 (talk) 23:36, 9 March 2023 (UTC)Reply[reply]
  24.   Support with the CSS snippet, but oppose otherwise. DCDuring (talk) 20:30, 15 March 2023 (UTC)Reply[reply]

Oppose

  1.   Oppose. Gnosandes ❀ (talk) 19:18, 17 February 2023 (UTC)Reply[reply]
    Care to explain why? Vininn126 (talk) 23:24, 17 February 2023 (UTC)Reply[reply]
    @Vininn126: Since I don't use bots, this horizontal line doesn't bother me. On the contrary, the line is visually pleasing. I don't want this thing to be removed because of bots. Since this line is useful and pleasant, it cannot be a redundant thing, as it is said in the description of the vote. Gnosandes ❀ (talk) 11:59, 18 February 2023 (UTC)Reply[reply]
    @Gnosandes: The proposal is to generate the same line by CSS automatically so whatever visual pleasantness it has is not going to change. —Al-Muqanna المقنع (talk) 00:54, 19 February 2023 (UTC)Reply[reply]
    @Al-Muqanna: The voting description says otherwise. Gnosandes ❀ (talk) 14:03, 19 February 2023 (UTC)Reply[reply]
    @Gnosandes: As @Catonif says in the voting description, "Furthermore, it has been assured that the visual outcome can be reached with a simple CSS snippet." —Al-Muqanna المقنع (talk) 15:38, 19 February 2023 (UTC)Reply[reply]
  2.   Oppose RichardW57m (talk) 11:32, 1 March 2023 (UTC). I find the quadruple hyphen and the blank lines above and below useful when editing. When I add a new language section, I generally start by editing an adjacent language section to include the new section above or below.Reply[reply]

Abstain

  •   Abstain. If it helps bots then I suppose we should change how we do things but how would I go about adding the dividers with the new system (assuming I remember about them in the first place)? Would I click on 'edit' and then type the code beginning with 'body.ns-0'? --Overlordnat1 (talk) 09:43, 15 February 2023 (UTC)Reply[reply]
    Im pretty sure you wont have to type anything. The whole point of this is to simplify. The CSS code above is not needed, not even for bots ... its what we're going to offer as an option to add to your custom CSS if you want to see the extra line on the screen once we make the switch. —Soap— 11:01, 15 February 2023 (UTC)Reply[reply]
    In my user preferences? --Overlordnat1 (talk) 11:36, 15 February 2023 (UTC)Reply[reply]
    yeah, it should be under the Appearance tab in the preferences screen.Seems to be the same on both desktop and mobile. —Soap— 11:58, 15 February 2023 (UTC)Reply[reply]
    Changing vote to support then. --Overlordnat1 (talk) 12:06, 15 February 2023 (UTC)Reply[reply]
  1.   Abstain I find them useful when editing but I guess if it harms our bot jobs then they should go. Thadh (talk) 10:53, 15 February 2023 (UTC)Reply[reply]
  2.   Abstain No strong feelings on the issue either way. — Sgconlaw (talk) 21:40, 15 February 2023 (UTC)Reply[reply]
  3.   Abstain, in all honesty, I actually like the horizontal line but if there is an alternative, then I guess it's fine. --Robbie SWE (talk) 18:28, 16 February 2023 (UTC)Reply[reply]
  4.   Abstain, I also like the separator, but this is just a mild preference and good arguments for the removal have been presented. tbm (talk) 14:07, 17 February 2023 (UTC)Reply[reply]
  5.   Abstain, I find the four hyphens to be a useful visual separator of language sections when I'm looking at the wikicode of the page, and I also find the horizontal line before a new language section useful when looking at the displayed page (and auto-generating a horizontal line in the displayed text of the page only solves the latter issue), but if it's inconvenient for users who run bots, I don't feel strongly about it. - -sche (discuss) 20:28, 17 February 2023 (UTC)Reply[reply]
  6.   Abstain: If the four dashes are to be automatically generated, fair enough. There is an issue with present use where a blank line is left above the dashes, no visible gap occurs between the entry above and the dashes, if however two blank lines are left that's what you get, a two-line gap. I would like to see a gap, but why does that happen? DonnanZ (talk) 16:01, 19 February 2023 (UTC)Reply[reply]
  7.   Abstain When editing or adding a new language entry, it is useful. --Gorec (talk) 17:39, 20 February 2023 (UTC)Reply[reply]
  8.   Abstain It is not a big deal either way Pious Eterino (talk) 13:30, 1 March 2023 (UTC)Reply[reply]

Decision

Passed 24-2-8. Van Man Fan (talk) 23:59, 16 March 2023 (UTC)Reply[reply]

Now that the bot did his run, someone with editing permission should probably amend WT:EL. Catonif (talk) 10:42, 19 March 2023 (UTC)Reply[reply]
Oh, there's also WT:NORM. Catonif (talk) 19:38, 21 March 2023 (UTC)Reply[reply]
Both have now been done. bd2412 T 13:17, 25 March 2023 (UTC)Reply[reply]

Vote creation eligibility

Voting on renaming the section on Wiktionary:Voting policy called "Voting eligibility" to "Eligibility" and amending the content below from:

For a Wiktionary user to be eligible for voting, the following requirements must be satisfied:

  1. Their account’s first edit to English Wiktionary (made locally rather than transwikied from another project) must predate the start time of the vote by at least 1 week.
  2. Their account must have at least 50 edits in total to the main, Citations, Appendix, Rhymes, Thesaurus, Reconstruction, or Concordance namespaces on English Wiktionary by the start time of the vote.
  3. Only one vote can be made per person. Sockpuppet voting results in a block on all related accounts.

to the following:

For a Wiktionary user to be eligible to create or vote on a vote, the following requirements must be satisfied:

  1. Their account must not be subject to a permablock, nor a sockpuppet of a permablocked account.
  2. Their account's first edit to English Wiktionary (made locally rather than transwikied from another project) must predate the creation timestamp when creating a vote, or the start time when casting a vote, by at least 1 week.
  3. Their account must have at least 50 edits in total to the main, Citations, Appendix, Rhymes, Thesaurus, Reconstruction, or Concordance namespaces on English Wiktionary by the creation timestamp when creating a vote or the start time when casting a vote.
  4. When voting, only one vote can be made per person. Sockpuppet voting results in a block on all related accounts.


Schedule:

  • Vote starts: 00:00, 17 February 2023 (UTC)
  • Vote ends: 23:59, 18 March 2023 (UTC)
  • Vote created: {{victar|talk}} 05:44, 10 February 2023 (UTC)Reply[reply]

Discussion:

Support

  1.   Support WF is not the only blocked user who'd be targeted by this, but most importantly I must ask why this community is so protective of a permabanned user that keeps creating new accounts? What image does this give? Why are we allowing a permabanned user to keep nominating the admin for this community? If it were anyone but WF, the votes would be deleted on the spot. We need to either decide to not unban WF or actually enforce the bans that we have in place and stop these votes from proceeding. I remember there was a time where WF votes would be autodeleted, but apparently we've decided to keep proceeding with them. It is a problem that needs a solution. And for the record, I was also tapped by WF but rejected the nomination, and I would hope for the future that folks nominated by WF would reject it as well. For me it's just not a good look to be nominated by a banned user. AG202 (talk) 13:34, 17 February 2023 (UTC)Reply[reply]
    For me, if WF's ban is being enforced then he shouldn't be editing anything. If it's not being enforced then I don't see why he should be prevented from creating votes. Either way there doesn't seem to be any reason to implement a specific policy for creating votes. WF seems in practice to be handled as a special case and it's dubious IMO to create general policies just to handle special cases. —Al-Muqanna المقنع (talk) 13:52, 17 February 2023 (UTC)Reply[reply]
    They are not the only user that’s been blocked that’s tried to create a vote or vote in a vote. I remember there was an issue of a user that was blocked in one namespace voting in another. Also, honestly, I don’t know why there’s such strong opposition to this. Even if it’s just for WF, is it really that controversial to have an explicit policy that states that blocked users can’t vote or create a vote, to the point that folks are opposing and not abstaining? It’s putting what should be practice into explicit text and should have been here from the beginning. As a side note, I also don’t think it’s fair to the nominees, especially those who are newer, to be thrown into the gauntlet of adminship votes when they’re not ready, and WF has nominated folks as almost a joke before, so it really needs to stop. AG202 (talk) 14:59, 17 February 2023 (UTC)Reply[reply]
    If there were a sentence somewhere in our policies that read "All votes which pass are valid", then I would drop my opposition. I don't want to create an excuse for someone to try and retroactively challenge a passed vote. Megathonic (talk) 15:16, 17 February 2023 (UTC)Reply[reply]
    Sounds fine with me, pinging @Victar. AG202 (talk) 18:08, 17 February 2023 (UTC)Reply[reply]
    I wouldn't support any language that encourages permablocked users to attempt to evade their block. -- {{victar|talk}} 21:02, 17 February 2023 (UTC)Reply[reply]
    This is the problem I see with the current wording though. If you're saying that if someone—after the vote is closed—discovers the vote creator was ineligible and thus should have grounds to invalidate said vote on the basis of it having taken place outside of the official rules, that opens up far more headaches. Would we desysop someone and force them to go through another vote? Do we purge a perfectly good, agreed-upon policy and wait a month until a new vote is finished before we can re-implement it? It should be obvious how absurd that would be. Megathonic (talk) 21:33, 17 February 2023 (UTC)Reply[reply]
    Nothing is really changing in terms of permablocked users -- any vote created by a permablocked user is already a block evade, and thus against the rules. This is just making that rule explicitly stated on the policy page. -- {{victar|talk}} 07:46, 18 February 2023 (UTC)Reply[reply]
    @Al-Muqanna "At the very least, this will be something that people can point to directly, and as such, people who aren't admin will be able to respond and delete votes on their own with an official written policy to back them up." Brought from the talk page, but this is an additional benefit of having this be explicitly written out. AG202 (talk) 20:11, 17 February 2023 (UTC)Reply[reply]
  2.   Support It's not fair on nominated editors to reject votes to give them admin (or bureaucrat or similar) status solely on the grounds that the nominator is banned. On the other hand why should banned users be able to create votes? It makes no sense to even say that they are banned if they can. Explicitly banning them from creating votes and immediately striking out any votes that they do create is clearly the best solution. --Overlordnat1 (talk) 16:20, 17 February 2023 (UTC)Reply[reply]
  3.   Support The bar to vote shouldn't be higher than the bar to create a vote. -- {{victar|talk}} 19:10, 17 February 2023 (UTC)Reply[reply]
  4.   Support Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 22:16, 17 February 2023 (UTC)Reply[reply]
  5.   Support Hythonia (talk) 15:39, 18 February 2023 (UTC)Reply[reply]
  6.   Support Roger.M.Williams (talk) 10:45, 20 February 2023 (UTC)Reply[reply]
  7.   Support — excarnateSojourner (talk · contrib) 21:45, 22 February 2023 (UTC)Reply[reply]
  8.   Support Might as well get in down explicitly and I hope this discourages the allowance of further created votes and votes cast by permabanned users which I have always disliked because permabans should be realized as actual permanent bans. —⁠This unsigned comment was added by The Editor's Apprentice (talk • contribs) at 22:58, February 25, 2022 (UTC).
    #   Support Anything to put restrictions on Wonderfool's editing is a good thing for their mental health OpenForceage (talk) 10:22, 26 February 2023 (UTC)Reply[reply]
    To those who do not know, OpenForceage is Wonderfool. J3133 (talk) 10:26, 26 February 2023 (UTC)Reply[reply]
    Sorry, I couldn't resist voting. OpenForceage (talk) 11:31, 26 February 2023 (UTC)Reply[reply]

Oppose

  1.   Oppose This vote appears to be driven by disapproval of the fact that WF nominated them, or others, for adminship. I don't see a problem here. We are not seeing inappropriate candidates becoming admins as a result of this activity by WF. The votes are appropriately being supported or opposed on their merits. And candidates should have the good sense to decline the nomination if they know they are unlikely to succeed (as indeed I did once). The vote page can be deleted, no harm done. In any case, I don't view WF's admin nominations as a problem, no-one has pointed out any other ongoing issues that might necessitate this policy changem, and no solution is required in the absence of a problem. So I see no reason to support the vote. This, that and the other (talk) 10:40, 17 February 2023 (UTC)Reply[reply]
    @This, that and the other: "No harm done" is not true. WF was permabanned for a reason: because they're reckless and enjoy trolling. I won't mention usernames, but they also have a habit of prematurely nominating users, which then fail and cause to discourage the user. They've also gone as far as to create bad-faith nominations in order to troll them. Nominating a user is meant to be a mentorship role, but WF is not the mentor you would want for someone. -- {{victar|talk}} 19:33, 17 February 2023 (UTC)Reply[reply]
  2.   Oppose per This, that and the other. I don't see any particular problem stemming from an ability to propose votes beyond possibly wasting people's time, but I do feel anyway that admin nominations should be judged on the strength of the nominee, not the nominator. —Al-Muqanna المقنع (talk) 13:20, 17 February 2023 (UTC)Reply[reply]
    @Al-Muqanna: WF seems to have no problem doing so on user's talk pages. They're recommendations can end there for someone else to take up the mantle of creating a vote. -- {{victar|talk}} 19:33, 17 February 2023 (UTC)Reply[reply]
  3.   Oppose Votes created by permabanned users can already be immediately deleted without any further ado, just like any other edit a banned user makes. A policy change is not needed for this. However, all votes which pass must be considered valid, even if they were improperly created. This policy change should state so, otherwise it could create an argument for people to contest the validity of passed votes which were proposed by a banned user. Megathonic (talk) 14:36, 17 February 2023 (UTC)Reply[reply]
    @Megathonic: You're absolutely right, but this vote actually gives someone the teeth without room for complaint. -- {{victar|talk}} 19:33, 17 February 2023 (UTC)Reply[reply]
  4.   Oppose – Guitarmankev1 (talk) 15:28, 17 February 2023 (UTC)Reply[reply]
  5.   Oppose: creating votes and actually voting are clearly different - if the creator does not vote then technically they have no contribution to the vote's passing. All the Wonderfool admin nominations have passed and failed only based on the community's votes and they are pretty legitimate. Consider another scenario, if a user from a sister project, say another language Wiktionary, or Wikipedia, etc. etc. creates a vote for some change (e.g. language related, or relating to technical matters, etc.), it should definitely not be inherently invalid even if they don't meet the minimum requirements for casting a vote. Oh, and I thought permabanned users were not supposed to edit at all, right? I seriously doubt that this vote will have any effect on WF nominations. Svartava (talk) 05:32, 18 February 2023 (UTC)Reply[reply]
    Again, you are correct -- permablocked users are already forbidden from editing en.Wikt. This is just a vote to explicitly mention that on the voting policy page. If you like Wonderfool as a contributor, you should create a vote for him to be reinstated, not against making already existing rules more clear.
    And to your second point, having the bar to create votes lower than it is to vote on a vote makes bunk sense, and I certainly wouldn't want some Wikipedian creating votes with no edits to en.Wikt. --{{victar|talk}} 07:52, 18 February 2023 (UTC)Reply[reply]
    @Svartava ""At the very least, this will be something that people can point to directly, and as such, people who aren't admin will be able to respond and delete votes on their own with an official written policy to back them up." That is what I expect out of this. AG202 (talk) 14:55, 18 February 2023 (UTC)Reply[reply]
  6.   Oppose. Everyone can vote. Gnosandes ❀ (talk) 02:37, 19 February 2023 (UTC)Reply[reply]
    @Gnosandes are you aware that, as things currently stand, not everyone can vote? For instance, in order to vote, one must have at least 50 edits total to certain namespaces in a certain time period, as set out in the existing policy text at WT:VP. This, that and the other (talk) 06:08, 19 February 2023 (UTC)Reply[reply]
    @This, that and the other: Yes, and that's why everyone can vote. Gnosandes ❀ (talk) 10:06, 19 February 2023 (UTC)Reply[reply]
    I don't get it, but okay. This, that and the other (talk) 11:25, 19 February 2023 (UTC)Reply[reply]
    @Gnosandes: This vote doesn't change voting rules, only vote creation rules. See Wiktionary:Voting policy#Voting eligibility for the current voting rules. --{{victar|talk}} 20:01, 19 February 2023 (UTC)Reply[reply]
  7.   Oppose, because of the anti-WF provision, so to speak. It is true that WF has a history of facetious nominations, but it is also true that he has nominated several excellent staff members. ←₰-→ Lingo Bingo Dingo (talk) 21:15, 21 February 2023 (UTC)Reply[reply]
    @Lingo Bingo Dingo: WF creating votes is already a block-evade, regardless of this vote, and thus grounds for immediate deletion. But as I wrote above, if you support his contributions, you should petition for his permablock to be lifted, not condone block-evades. --{{victar|talk}} 06:41, 22 February 2023 (UTC)Reply[reply]
    In practice, it is already lifted as he continues regular editing. If he is allowed to edit, then how is he permablocked?! --Svartava (talk) 02:59, 26 February 2023 (UTC)Reply[reply]
  8.   Oppose I assume the rationale behind this is to reduce the amount of so-called "bad" votes. The "quality of votes", so to speak, is not a matter of who proposed the vote, but rather the content of the vote itself. I don't think there is a need to disallow certain users from creating votes, it only becomes an issue when the votes are spammy/non-constructive and the problems becomes so egrenious that the admins have to step in and nuke them. In fact well-established users could also create pointless vote, while disruptive users can also be constructive. – Wpi31 (talk) 16:16, 25 February 2023 (UTC)Reply[reply]
  9.   Oppose Banned users are banned from voting, no specification needed, but this vote leaves open the consequence of a vote created by a banned user passing. If the rationale is indirectly targeted and some kind of steering effect as reducing the amount of bad votes is aimed at then this vote is also bad; what Equinox says on the vote talk page “it is potentially a bad thing to state an implied rule explicitly.” This vote is only there to be interpreted in a way I am supposed to be unable to predict so I am against it. Probably only means “Victar is vexed by Wonderfool voting so he needs an explicit text he can point at to demand deletion from admins” though. Fay Freak (talk) 12:25, 3 March 2023 (UTC)Reply[reply]
    I'm not vexed -- I'm just pro-rule enforcement. {{victar|talk}} 20:40, 5 March 2023 (UTC)Reply[reply]
  10.   Oppose I am part of the pro-WF cabal. —AryamanA (मुझसे बात करें • योगदान) 19:57, 5 March 2023 (UTC)Reply[reply]
    @AryamanA: then create a vote to reinstate him. {{victar|talk}} 20:38, 5 March 2023 (UTC)Reply[reply]
    @Victar: No fun in that! —AryamanA (मुझसे बात करें • योगदान) 03:13, 6 March 2023 (UTC)Reply[reply]

Abstain

  1.   Abstain As worded, the proposal would also prevent unregistered users from creating votes. 70.172.194.25 08:35, 19 February 2023 (UTC)Reply[reply]
    This is arguably already the case, just as you're prohibited from voting. --{{victar|talk}} 19:54, 19 February 2023 (UTC)Reply[reply]
    I don’t see how it’s explicitly prohibited currently. The policy doesn’t say anything about who can create votes. It’s possible to create a vote but not participate in it.
    This is pretty much just a theoretical point, as I’ve never had a need to create a vote and I don’t think many other IP editors would need to either. Just felt like pointing it out. 70.172.194.25 20:03, 19 February 2023 (UTC)Reply[reply]
    Maybe IPs should unionize. – Jberkel 20:28, 19 February 2023 (UTC)Reply[reply]
    We should have a "comments" section on votes. Then people could comment without putting it in the abstain section, which is technically voting. Megathonic (talk) 20:11, 19 February 2023 (UTC)Reply[reply]
    Sure. Or feel free to move all of this to the talk page. 70.172.194.25 20:12, 19 February 2023 (UTC)Reply[reply]
  2.   Abstain. Oh my god, who the hell cares? Vox Sciurorum (talk) 19:11, 20 February 2023 (UTC)Reply[reply]

Decision

Failed 8-10-2. Vininn126 (talk) 00:00, 19 March 2023 (UTC)Reply[reply]

Allowing closed compounds that are word-for-word translations of the English term to qualify to support that term

Voting on: Removing the following sentence from WT:THUB: “a closed compound that is a word-for-word translation of the English term: German Autoschlüssel does not qualify to support the English "car key"; or”

Current text:

Translation hubs

A translation hub (translation target) is a common English multi-word term or collocation that is useful for hosting translations. Some attested translation hubs should be included despite being non-idiomatic and some excluded, but there is no agreement on precise, all-encompassing rules for deciding which are which. Therefore, the following criteria for inclusion of attested non-idiomatic translation hubs are tentative:

  • The attested English term has to be common; rare terms don't qualify.
  • A translation does not qualify to support the English term if it is:
    • a closed compound that is a word-for-word translation of the English term: German Autoschlüssel does not qualify to support the English "car key"; or
    • a multi-word phrase that is a word-for-word translation of the English term; or
    • a diminutive: Spanish mecedorcito does not qualify to support the English "small rocking chair"; or
    • an augmentative: Portuguese amigão does not qualify to support the English "good friend"; or
    • a comparative or a superlative; or
    • a phrase in a language that does not use spaces to separate words.
  • At the very least, two qualifying translations must support the English term. Editor judgment can require a higher number, on a case-by-case basis.
  • The existence of a rare single-word English synonym of the considered English term does not disqualify the considered English term: the existence of Anglistics, which is rare, does not disqualify English studies.

Proposed text:

Translation hubs

A translation hub (translation target) is a common English multi-word term or collocation that is useful for hosting translations. Some attested translation hubs should be included despite being non-idiomatic and some excluded, but there is no agreement on precise, all-encompassing rules for deciding which are which. Therefore, the following criteria for inclusion of attested non-idiomatic translation hubs are tentative:

  • The attested English term has to be common; rare terms don't qualify.
  • A translation does not qualify to support the English term if it is:
    • a multi-word phrase that is a word-for-word translation of the English term; or
    • a diminutive: Spanish mecedorcito does not qualify to support the English "small rocking chair"; or
    • an augmentative: Portuguese amigão does not qualify to support the English "good friend"; or
    • a comparative or a superlative; or
    • a phrase in a language that does not use spaces to separate words.
  • At the very least, two qualifying translations must support the English term. Editor judgment can require a higher number, on a case-by-case basis.
  • The existence of a rare single-word English synonym of the considered English term does not disqualify the considered English term: the existence of Anglistics, which is rare, does not disqualify English studies.

Rationale: under our current policy, an entry such as smoked salmon, while admittedly useful, cannot be kept on the basis of its translations alone. Indeed, its translations into Finnish (savulohi), German (Räucherlachs) or Norwegian (røkelaks), although they are closed compounds, cannot be used to support its existence, because said compounds are word-for-word translations of the English term. It is furthermore highly unlikely that any translation will satisfy the condition that it not be a word-for-word translation. Other examples include murder weapon, insurance agent, car key, prostate cancer, penis enlargement, kidney failure, car accident, air resistance, heat-resistant, yesterday's, tomorrow's.

Schedule:

  • Vote starts: 00:00, 25 February 2023 (UTC)
  • Vote ends: 23:59, 26 March 2023 (UTC)
  • Vote created: PUC – 11:25, 18 February 2023 (UTC)Reply[reply]

Discussion:

Support

  1.   Support German is a good example of a language that has what we call a sum-of-parts distinction built into its grammar, and there are others. This idea could spare us a lot of pointless debate. Like other translation hubs, these phrases will need to pass two important tests: 1) that a single-word translation must exist in at least two languages; and 2) that the phrase must be in common use in English. Because of these pre-existing rules, I don't think we need to worry about being flooded with translations of nonce words from German poems and the like. —Soap— 09:35, 25 February 2023 (UTC)Reply[reply]
    I'd like to add a bit more. Rather than end my vote with "it won't be so bad", I should highlight an important positive aspect. One benefit of including phrases like car key in our dictionary is that it will be easy for people who know one language to find the translations in other languages. After all, most languages, including English, have more than one word for car. People don't say *auto key in English, and in German, people don't say *Karreschlüssel. What might seem unnecessary or even frivolous at first glance can actually be an important help to language learners. —Soap— 09:51, 25 February 2023 (UTC)Reply[reply]
  2.   Support The current policy is too strict in this regard. It's advantageous to have translations located in one spot, and commonly used phrases are useful to include. To restate my argument in the beer parlour discussion, this proposal will not support adding phrases which are superfluous in English, such as "animal garden" as a translation of Tiergarten, because the phrase in question has to actually be in common English usage to qualify. Megathonic (talk) 16:05, 25 February 2023 (UTC)Reply[reply]
  3.   Support Our current policy is way too strict, and this would go a long way towards fixing that. I'd also like to note that other dictionaries usually have entries for common SOP terms, such as car keys and prostate cancer, and our doing so would benefit readers in ways Soap outlined above. Binarystep (talk) 21:57, 25 February 2023 (UTC)Reply[reply]
  4.   Support: This is long overdue. The scaremongers voting "Against" should relax, commonsense is still needed. There is no problem with SoP place names. DonnanZ (talk) 21:09, 26 February 2023 (UTC)Reply[reply]
  5. Leaning towards   Support: I agree with Soap that this would be helpful when the translations are not intuitive or immediately obvious to the reader. I don't think this change itself would lead to what some of the opposing people have mentioned as a large influx of English entries. The THUB policy already theoretically allows the creation of English entries that are otherwise SoP (for example I made shaved female genitalia not long ago, which I must say is not particularly useful), it's just no one has ever bothered to do so. This is evident by the fact that most entries in Category:English translation hubs are just grammar words, common words in daily usage, and stuff that English lacks the distinction (e.g. kinship terms or n days after/before today). On the otherhand I do think a slightly stricter condition should be imposed, but that should already be covered by the phrasing "Editor judgment can require a higher number, on a case-by-case basis." – Wpi31 (talk) 15:14, 27 February 2023 (UTC)Reply[reply]
    @Wpi31: As far as I know the THUB policy is specifically designed for terms that are otherwise SoP, that's not theoretical. Given the translations listed, shaved female genitalia seems far more useful than what's being discussed here, which would be terms where the only translations are terms that match the English lexeme-for-lexeme but happen to be written as a single word. —Al-Muqanna المقنع (talk) 01:12, 28 February 2023 (UTC)Reply[reply]
    "where the only translations". I'd be glad to go a step further and strike out "a multi-word phrase that is a word-for-word translation of the English term" as well. Obviously that's not what is proposed in this vote, but it would be sounder policy. It's not the slightest bit clear whether a word in a given language is coincidentally word-for-word equivalent to the English word, and even when it is, which equivalent words would one use? English could have just as easily picked "vehicle key" or "auto key" instead of "car key". Just because the term is SOP doesn't make it unuseful; the phrasing is not inherently obvious to a language learner. Megathonic (talk) 05:21, 28 February 2023 (UTC)Reply[reply]

Oppose

  1.   Oppose This would inevitably result in a flood of new English entries that only exist because some languages prefer closed compounds, which is not a good outcome. — SURJECTION / T / C / L / 16:06, 25 February 2023 (UTC)Reply[reply]
  2.   Oppose. I would certainly consider supporting if something like the ten translations condition that @PUC mentions were added, since I think the point about closed compounds not always being straightforward is fair, but just removing the criterion entirely would lead to a lot of more or less useless entries being created. The criterion about phrases being common does not solve this problem given the huge number of phrases (or even entire sentences) that are common without necessarily being idiomatic. —Al-Muqanna المقنع (talk) 18:41, 25 February 2023 (UTC)Reply[reply]
  3.   Oppose per Al-Muqanna. Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 02:22, 26 February 2023 (UTC)Reply[reply]
  4.   Oppose per Surjection. --Svartava (talk) 02:56, 26 February 2023 (UTC)Reply[reply]
  5.   Oppose per above. I certainly do not want to open the door to any sufficiently attested closed compound with at least X word-for-word translations. ←₰-→ Lingo Bingo Dingo (talk) 13:14, 26 February 2023 (UTC)Reply[reply]
  6.   Oppose Thadh (talk) 15:58, 26 February 2023 (UTC)Reply[reply]
  7.   Oppose per Surjection. - -sche (discuss) 18:30, 27 February 2023 (UTC)Reply[reply]
  8.   Oppose per Surjection. What would be more useful is translation tables for collocations; why split information over so many different pages? MuDavid 栘𩿠 (talk) 02:16, 1 March 2023 (UTC)Reply[reply]
  9.   Oppose per Surjection. — Fenakhay (حيطي · مساهماتي) 02:30, 1 March 2023 (UTC)Reply[reply]
  10.   Oppose per Surjection, in consideration of how people will understand this amendment. I cannot exclude that car key should be included anyway for its being a technical thing, or in general all the mentioned terms should be included anyway because the translations tend to be idiomatic and not too easy to guess, however it is true that the mere existence of closed compound that represent word-for-word translations are no criterion to qualify the translation, and people should not think that it is.
    It can well be that a combination of the criteria, I cannot exclude, turn the scales to conclude that an English term should be maintained. I created lack of sleep, well received since 2021, because it is a particular condition we can all feel and contradistinguished from other entry-demanding ones AND the ledger of translations is attractive, but neither the idiomaticity of the term nor the translations alone appeared to afford a sufficient cause for the entry; a larger context did, the complexity of which the current law explicitly confesses, while enumerating some wrong causes. Fay Freak (talk) 03:09, 1 March 2023 (UTC)Reply[reply]
  11.   Oppose Learners of languages with closed compounds will know how to form them just as easily as English noun clusters. I looked at the smoked salmon example in the rationale. savulohi has savu- (“smoked”) +‎ lohi (“salmon”), Räucherlachs has räuchern (“to smoke”) +‎ Lachs (“salmon”), røkelaks has røke +‎ laks. If we extrapolate Latin into English analogically, smoked salmon would become *fumisalmon. Imagine speakers of other languages telling you that "smoked salmon" is complicated and noteworthy as a separate entry because they think "salmon that is smoked" would be a simpler construction. It's the same way with those languages with closed compounds. Those learners will find it just as easy to glue prefixes together as we find it easy to place a noun after another noun, so they will not need this amendment. Daniel.z.tg (talk) 05:17, 2 March 2023 (UTC)Reply[reply]
    Translating smoked salmon literally into German would give you geräucherter Lachs, which works, but it's not the principal term. It's highly unlikely that a language learner would come up with Räucherlachs on their own. When the English entry for a compound word doesn't exist and thus no translation is given, they will turn to another dictionary or translation tool to figure it out. Megathonic (talk) 08:29, 2 March 2023 (UTC)Reply[reply]
    People who want to figure out how to say “smoked salmon” in German will more probably look up smoked and salmon separately. We should give the translation of “smoked salmon” on those two pages, not on a separate page. (That’s how most other dictionaries work, by the way.) MuDavid 栘𩿠 (talk) 06:53, 3 March 2023 (UTC)Reply[reply]
    Perhaps, but our project serves a different purpose than traditional one-to-one dictionaries. If someone wanted to look up the words for smoked salmon in more than one language using the system you're proposing, not only would they need to click through to each language individually, they would have no idea, without brute-force checking every single language, which languages we even list translations for. Centralizing the information all in one place, using a Translation Hub, is much more convenient for our readers, and I'd argue also more convenient for our editors. —Soap— 14:38, 3 March 2023 (UTC)Reply[reply]
    Apologies, I replied in haste and probably misread. I thought you wanted the German word for smoked salmon to be listed under the German word for salmon. It see now you're saying it should be on the English page, which would mean that we could put all of the languages together and save the users a lot of work. But wouldn't that just be a Translation Hub by another name? And it would need to be there twice, once on smoked and once on salmon. I don't think this is a good idea. —Soap— 14:44, 3 March 2023 (UTC)Reply[reply]
    This "German word for [...] under the Germain word" already exists everywhere like Lachs#Related terms. As for saving work for the other layout, you could click on https://en.wiktionary.org/wiki/Special:WhatLinksHere/salmon . But your point still stands as that's a lot of search results to work through and I hated using WhatLinksHere for something else in Korean. Daniel.z.tg (talk) 15:22, 3 March 2023 (UTC)Reply[reply]
    Now I've thought of another problem being discoverability. It never occurred to me to look up multi-word terms in a dictionary, and I was pleasantly surprised that I could find phrasal verbs and idioms here on Wiktionary. I would not have thought of looking up smoked salmon even if I wanted to find something like that because it is a noun cluster. After trying that a few times, I've learned that pages for noun clusters tend to exist only if I'm lucky and usually they doesn't have a page simply because of the number of combinations. Someone trying to translate "smoked salmon" would need to first discover that they can expect to find pages titled that, and even if they become confident in doing so, they won't find the new page if they worded their search slightly differently such as if they used synonyms. If this discoverability problem exists, then this amendment would create a lot of new pages but not reach many people with those pages. Daniel.z.tg (talk) 15:22, 3 March 2023 (UTC)Reply[reply]
  12.   Oppose Jesielt (user talk) 19:29, 12 March 2023 (UTC)Reply[reply]
  13.   Oppose: Not a fan of the t-hub argument for inclusion anyways. I don't see why non-English words which translate into English SOP phrases deserve their own entries. – Guitarmankev1 (talk) 18:48, 14 March 2023 (UTC)Reply[reply]

Abstain

  1.   Abstain for now until I see some arguments. Some of the arguments for this brought up look like they can be solved with collocations, which we have; however on the other hand having a singular link for a definition is usually handy. Vininn126 (talk) 10:45, 25 February 2023 (UTC)Reply[reply]
  2.   Abstain I'm unsure and undecided. As Surjection, I worry this could lead to a flood of useless English entries. However, I think the added condition I envisioned (that "at least ten (this is a tentative number) entry-worthy word-for-word-compound translations, ideally from different language families, be present") could alleviate the issue. Also, the already present condition that "the attested English term has to be common; rare terms don't qualify" will continue acting as a safeguard. PUC – 16:12, 25 February 2023 (UTC)Reply[reply]
    Btw, @Soap, I think you have misunderstood this part: the added condition I suggested would only apply to word-for-word compounds. Two non word-for-word translations would still be enough. PUC – 16:19, 25 February 2023 (UTC)Reply[reply]
    Im just posting to make clear that I understood the modification as proposed ... that it would apply only to words entered under the new, amended criterion. I dont think this is a good idea, as there will be very few words meeting such a criterion, and in those few cases, it creates a lot of extra work for our editors. —Soap— 14:46, 3 March 2023 (UTC)Reply[reply]
    Honestly, I'm now more confused as to why you started this vote all of a sudden with no prior substantive discussion (per the links here, please correct me if I'm wrong) if you were only going to vote abstain. Who was hard pushing for this vote? Especially considering that the example smoked salmon was nominated for RFD by you yourself, I was surprised when you proposed this change to CFI and thought that maybe your approach had changed, but after this abstain vote, it seems to me that you set this proposal up for failure, and that post its failure, there'd be a failed vote to point to in RFD discussions (which has happened in the past). AG202 (talk) 15:38, 26 February 2023 (UTC)Reply[reply]
    I wasn't clear either on PUC's position but there's nothing wrong with getting a vote on something you don't personally support to make clear the community position, as long as it's not purely grandstanding (which this one doesn't seem to be, there are people who support it). —Al-Muqanna المقنع (talk) 16:56, 26 February 2023 (UTC)Reply[reply]
    I'm not particularly eager to see smoked salmon deleted, as I think it's a rather useful entry, but votes like Donnanz's, which are absolutely not rooted in policy, irritate me. I'd prefer if we could point to something in our CFI to keep it. In this particular instance, my reasoning has been exactly the reverse of what you're suggesting.
    On the other hand, I fear this vote will indeed lead to the inclusion of some crap, so I'm not super enthusiastic either.
    So yes, I'm genuinely undecided on the issue, which has been bugging me for more than a year already. If I'd set this vote up for failure I would have voted oppose. By the way, I did not start it myself, and would not have done so with so little input from other contributors. But since someone else went ahead, let's it run its course (is this grammatical?), I guess. PUC – 18:05, 26 February 2023 (UTC)Reply[reply]
    "But since someone else went ahead, let's let it run its course." Only one word was missing :) Megathonic (talk) 19:59, 26 February 2023 (UTC)Reply[reply]
    Thanks for the clarification. I do wish that the person who started the vote would've waited until there's been more discussion (as seen by the oppose votes), but here we are now. AG202 (talk) 13:39, 1 March 2023 (UTC)Reply[reply]
    I started the vote because it was scheduled to start on that day. Are scheduled votes sometimes postponed? Even if so, I dont think waiting would have changed much, as the Beer Parlour thread that led to this vote had been inactive for five days by that time. —Soap— 16:40, 1 March 2023 (UTC)Reply[reply]
    Perhaps you didnt mean me. I started the vote in the sense of bringing it live, but I wasnt the one who wrote it up. In either case, I dont think there would have been much more discussion in the Beer Parlour thread if we had waited longer. —Soap— 16:58, 1 March 2023 (UTC)Reply[reply]
    @Soap: Yes, scheduled votes are sometimes postponed, or even not run at all. I would have waited longer, but that's not too bad I think. If necessary, we can start a new discussion and run another vote in a few months, taking into account the objections that have been raised. PUC – 18:00, 12 March 2023 (UTC)Reply[reply]
  3.   Abstain this ought to be discussed more fully. Helrasincke (talk) 12:35, 19 March 2023 (UTC)Reply[reply]

Decision

Failed 5-13-3. Vininn126 (talk) 11:00, 27 March 2023 (UTC)Reply[reply]

Allow "Clitic" as a POS header

Voting on amending WT:POS to remove "Clitic" from the list of explicitly disallowed part-of-speech headers, and to add it to the list of allowed part-of-speech headers as a morpheme type. Specifically, at WT:POS,

  1. Add "Clitic" to "Allowed POS headers: […] • Morphemes: Circumfix, Clitic, Combining form, Infix, Interfix, Prefix, Root, Suffix"
  2. Remove "Clitic" from "Some POS headers are explicitly disallowed: […] • Clitic, Gerund, Idiom"

Justification:

No real discussion took place on the merits of "Clitic" at the vote in 2015 that determined it would be excluded as a part-of-speech header: indeed, the only mention of "Clitic" was in the context of I.S.M.E.T.A. noting that they opposed banning it but didn't "care enough" about it to vote on that basis.

I don't see a convincing reason to ban editor communities for specific languages from using "Clitic" as a header. Some languages already use "Clitic" as a part of speech header notwithstanding the disallowance, e.g. -kaa, -e, and if "Particle" is used for units that are treated as independent words, then allowing "Clitic" also fills an obvious gap between affixes in a strict sense and particles.

 

This vote has not yet started. It has been created to solicit advice on wording and fitness to purpose. Feedback and new ideas are highly encouraged! If you have not done so, please follow the discussion links for a better understanding of the topic. However, do not vote for any options at this time, as any premature votes may be struck. On the other hand, if the discussion is stagnant and there are no recent changes, anyone may choose to start this vote by properly listing it. Once the starting date has arrived, this banner may be ignored or removed.

Schedule:

  • Vote starts: 00:00, 1 April 2023 (UTC)
  • Vote ends: 23:59, 30 April 2023 (UTC)
  • Vote created: —Al-Muqanna المقنع (talk) 13:59, 25 March 2023 (UTC)Reply[reply]

Discussion:

Support

Oppose

Abstain

Decision

Proposed votes

The following are proposals for new votes, excluding nominations, in cases where the proposer of the vote prefers that the vote is written collaboratively, or where 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.

Forthcoming votes:

Wiktionary:Votes/2020-09/Review of Gheg Albanian circumflexes
Wiktionary:Votes/2022-01/Excluding trivial present participal adjectives
Wiktionary:Votes/pl-2022-06/Streamlining the approval process of online sources
Wiktionary:Votes/pl-2022-07/Stubifying alternative forms
Wiktionary:Votes/pl-2022-11/Should unidiomatic phrases be included if there is consensus for likely utility to readers?
Wiktionary:Votes/pl-2023-03/Allow "Clitic" as a POS header

Votes intended to be written collaboratively or substantially revised:

Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Votes&oldid=68494125"