Jump to content

Wiktionary:Votes

From Wiktionary, the free dictionary
(Redirected from Wiktionary:VOTE)
Notice This is an information page.
It is not an dictionary entry, nor one of Wiktionary's policies or guidelines; rather, its purpose is to explain certain aspects of Wiktionary's norms, customs, technicalities, or practices. It may reflect differing levels of consensus and vetting.
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.

See 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.

Creating a new vote

For the policy, see Wiktionary:Voting policy.
For a tutorial for creating a vote, see Help:Creating a vote.
Warning Before starting a new vote
Change “Title of vote” in associated the field to add a short description, or add the user to after “User:”. Once the vote is created, add it to the list of active votes.


Note: Update the vote list at WT:A.


Note: Update the vote list at WT:B.


Note: Update the vote list at WT:C.


Routine clean-up

For admins, periodically check for orphan votes at Wiktionary:Votes/ for votes and voting templates, including templates for creation of new votes:

Current and new votes

Planned, running and recent votes [edit this list]
(see also: timeline, policy)
EndsTitleStatus/Votes
Feb 27Reconsidering the parameters text and tree of etymon21 (21 people)
(=1)Wiktionary:Table of votes(=21)

Reconsidering the parameters text and tree of etymon

Voting on: This vote is to decide whether the |text= feature of {{etymon}} is still experimental and to decide whether the display of trees should be controlled by the user.

Schedule:

Discussion(s):

Issue 1 (Parameter text as experimental)

Rationale

I propose to formally allow the |text= parameter to be used in its various options in the mainspace under the languages whose editing communities have explicitly approved it, as long as it does not imply the removal of valuable information which cannot be produced by the module. The label "experimental" would be removed from the template's documentation.

Support
  1.  Support Vininn126 (talk) 00:00, 29 January 2026 (UTC)[reply]
  2.  Support. Although the explicitly allowing its use per language community clause is overkill, I understand this approach will likely gain the most support. I expect very few language communities to publicly discourage its use. TranqyPoo [💬 | ✏️] 00:10, 29 January 2026 (UTC)[reply]
    This was an explicit condition of the original vote. --{{victar|talk}} 22:43, 6 February 2026 (UTC)[reply]
    I'm saying that I think this vote would have passed without that clause (which I could be wrong). But since the clause is stated, I still support it. I'm not advocating nor implying to disregard the conditions of the vote. TranqyPoo [💬 | ✏️] 03:32, 7 February 2026 (UTC)[reply]
  3.  Support This, that and the other (talk) 22:06, 29 January 2026 (UTC)[reply]
  4.  Support — Fenakhay (حيطي · مساهماتي) 22:34, 29 January 2026 (UTC)[reply]
  5.  Support — I'd be into adding text=++ as a default. It looks better imho and gives more detailed information Tashi (talk) 23:27, 30 January 2026 (UTC)[reply]
  6.  Support [ɪˈɫa.wə kəˈta.kə] (talk) (edits) 00:56, 31 January 2026 (UTC)[reply]
  7.  Support I'm about to ask the Latin-editing community to get it approved too. Saumache (talk) 17:30, 2 February 2026 (UTC)[reply]
  8.  Support. – Svārtava (tɕ) 06:43, 8 February 2026 (UTC)[reply]
  9.  Support: all perceptions of reduced quality are subjective and language-dependent. Let each community decide. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:32, 13 February 2026 (UTC)[reply]
  10.  Support Ioaxxere (talk) 18:24, 14 February 2026 (UTC)[reply]
  11.  Support per nom and Polomo.  Juwan  🕊️🌈 23:40, 14 February 2026 (UTC)[reply]
  12.  Support per nom and Polomo. Davi6596 (talk) 14:50, 17 February 2026 (UTC)[reply]
  13.  Support Let each language community decide. —AryamanA (मुझसे बात करें • योगदान) 01:57, 19 February 2026 (UTC)[reply]
Oppose
  1.  Oppose Thadh (talk) 12:21, 29 January 2026 (UTC)[reply]
  2.  Oppose because 1) I'm unconvinced that the alleged improved synchronization is such a great boon and 2) as I wrote in the most recent Beer parlour thread this will encourage simplistic etymologies that will be more difficult to improve. —Caoimhin ceallach (talk) 10:39, 31 January 2026 (UTC)[reply]
    @Caoimhin ceallach: At least 90% of etymologies are simplistic (borrowed from X, inherited from Y, compound of A + B) and there is no meaningful way to improve on such sentences. I challenge you to prove me wrong. Ioaxxere (talk) 18:24, 14 February 2026 (UTC)[reply]
    How could I possibly prove something like that??? Here's a simple task for you instead: find me any etymological dictionary in which 90% of etymologies are simplistic. —Caoimhin ceallach (talk) 21:04, 14 February 2026 (UTC)[reply]
    {{R:pl:WSWO}}, {{R:pl:USJP}}, {{R:pl:PSWP}} and also plenty of Polish etymological dictionaries focus on the ultimate etymology, so you'll see how Boryś talks about Proto-Slavic, it just concerns Polish, but to be frank, it often ends up in a simple etymology. So if you want examples, I have plenty. As to simple etymologies on Wiktionary, it makes sense that some entries will be complex, but the information at hasard#French shouldn't be there, but moved up. Vininn126 (talk) 21:07, 14 February 2026 (UTC)[reply]
    I don't think those are etymological dictionaries. Am I missing something? For what it's worth, I'm often dissatisfied with short etymologies and think more could be said. (First use, history of use, context, and motivation for borrowing, etc.) —Caoimhin ceallach (talk) 16:01, 15 February 2026 (UTC)[reply]
    They provide etymologies in them, but are not dedicated to it. I think that a lot of the information your seeking would go in a Wikipedia article talking about what time periods words from certain languages began entering the language. Unique cases ought to be discussed further, but again, most people have said that any important information should not be removed, but we don't need to be repeating ourselves in every etymology. Vininn126 (talk) 16:10, 15 February 2026 (UTC)[reply]
  3.  Oppose Module:etymon is still being frequently edited with parameter changes and hotfixes, which does not suggest that it is no longer experimental. Additionally, troubling comments such as those made by TranqyPoo above highlight the risk that removing the experimental label may weaken adherence to the per-language community condition set by the original vote. --{{victar|talk}} 22:21, 6 February 2026 (UTC)[reply]
  4.  Oppose Because of the existence of |text=++ and |text=N. While the other options (:LANG and +) give the editor control over the area of pertinence of an etymology, these do not. I am of the opinion that encouraging people to use ++ and N is harmful, I cannot think of a situation where they would be of use. I cannot support a template that allows these options. Catonif (talk) 13:46, 7 February 2026 (UTC)[reply]
    @Catonif: I’m not sure I completely understand you, but I find those parameters extremely useful (and had proposed that before), and certainly not all language-editing communities prefer just a single step etymology, so what's such a deal-breaker about them? – Svārtava (tɕ) 04:38, 15 February 2026 (UTC)[reply]
    As I said, they do not give the editor control over the area of pertinence of an etymology. The parameters do not themselves contain the semantic information that dictates the content of the etymology. Of course not all etymologies should be single steps, which is where you can use the :LANG syntax. Admittedly, your example of "from A, fom B + C" cannot be currently covered with it, but on one hand I'd suggest to stop doing that in the first place (I do not consider that information pertinent), and on the other hand it may be possible to complicate :LANG to work with these cases. The number syntax, I believe, can cause many more issues than it can fix. Both it and especially ++ need to be turned off. Catonif (talk) 05:01, 15 February 2026 (UTC)[reply]
    Okay, it's clearer now. I do think |text=:LANG is as useful as |text=N, and slightly better only (e.g. in case a new step is added in between but the desired format for the etymology is still the one going back to LANG).
    But I strongly disagree with your suggestion to not write "from A, from B + C", and I really don't think that is something that needs to be standardized either way and is better left to the editors of a language community to decide. – Svārtava (tɕ) 05:37, 15 February 2026 (UTC)[reply]
    Fair, but I still think that the parameter value should be semantic in reflecting what the editor means, so if we want an etymology that goes back to "Sanskrit and its components" the parameter value should be something around the lines of :sa+ rather than 3 which would change its meaning the moment you add a Prakrit intermediate. In any case, by far the biggest issue I have is with ++. Catonif (talk) 08:41, 15 February 2026 (UTC)[reply]
  5.  Oppose Chihunglu83 (talk) 14:39, 8 February 2026 (UTC)[reply]
  6.  Oppose
    per [User:Caoimhin ceallach]: This will encourage [excessively] simplistic etymologies that will be more difficult to improve.
    per [User:Victar] and [User:Catonif]: Module:etymon is still being frequently edited with parameter changes and hotfixes […] Encouraging people to use |text=++ and |text=N is [potentially] harmful.
    Kutchkutch (talk) 15:50, 8 February 2026 (UTC)[reply]
  7.  Oppose It still seems to be in flux technically. An insider-only advocacy project like this needs to be absolutely bullet-proof to be other than tentative. DCDuring (talk) 17:10, 17 February 2026 (UTC)[reply]
Abstain
  1.  Abstain: Good compromise, but I'm worried about enforcement. AG202 (talk) 01:24, 30 January 2026 (UTC)[reply]
  2.  Abstain: I think in principle this makes sense for simple etymologies, but I feel victar's right that the module is not particularly stable yet. It may be better to try to get issues completely resolved first before trying to roll it out further.--Urszag (talk) 22:58, 7 February 2026 (UTC)[reply]
Decision

Issue 2 (Parameter tree as controlled by a gadget)

As per Wiktionary:Votes/2024-04/Allowing_etymology_trees_on_entries, trees are meant to be displayed on a per language-editing-community basis, such that if active editors for a given language agree it should be displayed, it may. As suggested first by User:Surjection, giving more control to the reader is better, as it removes any need to quarrel over what is best. Two proposals to resolve this issue have been given:

Option 1 (trees are enabled by default and may be disabled with a user gadget)
Rationale

With this option, if {{etymon}} is present, trees will be automatically enabled (Module:etymon can be modified to automatically disable them for multiword entries per Wiktionary:Votes/2024-04/Allowing_etymology_trees_on_entries) and will be togglable with a setting or gadget made by User:Surjection by the user. I also propose to inform the reader of this option somewhere on the etymology tree. The upside to this option is visibility, if the tree is hidden by default, users might not even know that there is an option to turn them on or off.

Support
  1.  Support Vininn126 (talk) 00:00, 29 January 2026 (UTC)[reply]
  2.  Strong support. Let the user be aware and decide according to their preference! TranqyPoo [💬 | ✏️] 00:10, 29 January 2026 (UTC)[reply]
  3.  Support This, that and the other (talk) 22:06, 29 January 2026 (UTC)[reply]
  4.  Support — Fenakhay (حيطي · مساهماتي) 22:34, 29 January 2026 (UTC)[reply]
  5.  Support: Tashi (talk) 23:27, 30 January 2026 (UTC)[reply]
  6.  Support [ɪˈɫa.wə kəˈta.kə] (talk) (edits) 00:56, 31 January 2026 (UTC)[reply]
  7.  Weak support The tree box is quite bulky and just as much ugly set over the etymology text like that, I'd prefer something that would be more in line with what we have for inline nyms, coordinate terms, etc., i.e., placed under the etymology text itself and having a distinct look that won't make it seem out of place. Saumache (talk) 17:31, 2 February 2026 (UTC)[reply]
  8.  Support as better than the status quo. I think trees make it a lot easier as an editor to see what etymon is doing in the associated chain of entries. So I want to see trees on all entries myself, and I want other people's eyes on them too in general. As a compromise, I would also be OK with having a "notree" parameter that could be used to turn trees off by default on particular entries, so long as this notree parameter can be overridden by a user gadget. Urszag (talk) 22:58, 7 February 2026 (UTC)[reply]
  9.  Support. – Svārtava (tɕ) 06:43, 8 February 2026 (UTC)[reply]
  10.  Support per nom.  Juwan  🕊️🌈 23:40, 14 February 2026 (UTC)[reply]
  11.  Support per nom and Urszag. Davi6596 (talk) 14:53, 17 February 2026 (UTC)[reply]
Oppose
  1.  Oppose Thadh (talk) 12:21, 29 January 2026 (UTC)[reply]
  2.  Oppose If this is implemented, I will avoid using {{etymon}} altogether, as there are times when it could be useful, but trees would be unwieldy and/or wouldn't add anything constructive. This proposal would add them everywhere. I prefer the status quo and leaving it to editor/community discretion. AG202 (talk) 01:24, 30 January 2026 (UTC)[reply]
  3.  Oppose I don't see the advantage of this in comparison to the status quo. I agree with AG202. —Caoimhin ceallach (talk) 10:39, 31 January 2026 (UTC)[reply]
  4.  Strong oppose The {{etymon}} tree is large and, in many cases, detracts from the readability of otherwise simple etymologies. Enabling it by default everywhere with no override would therefore do a disservice to the project. --{{victar|talk}} 22:21, 6 February 2026 (UTC)[reply]
    To be clear, the tree would be collapsed by default and expanded once clicked. The override is mentioned in the vote (togglable with a setting or gadget). Please see this discussion for more details. TranqyPoo [💬 | ✏️] 03:44, 7 February 2026 (UTC)[reply]
    I'm fully aware of how {{etymon}} functions. A user setting isn't an override -- it's an opt-out. An override is an explicit, per-entry mechanism, i.e. {{etymon|notree=1}}. --{{victar|talk}} 05:09, 7 February 2026 (UTC)[reply]
  5.  Strong oppose This seems to foist the etymology tree on unregistered and casual users. As such it erects a barrier to them getting what they most want: definitions and translations. We can ensure that such users never come back to Wiktionary by creating more such barriers. Why not make all images full screen by default? That would be an even more efficient means. DCDuring (talk) 15:43, 17 February 2026 (UTC)[reply]
    @DCDuring Trees are collapsed by default, I don't think a singe soul is here fighting for having them uncollapsed, though the box could use being a tad less conspicuous. Saumache (talk) 16:22, 17 February 2026 (UTC)[reply]
    Then I seem to have read "Option 1 (trees are enabled by default and may be disabled with a user gadget)" wrong. "Trees are enabled by default" means "trees are disabled by default". I need new glasses. DCDuring (talk) 17:04, 17 February 2026 (UTC)[reply]
    @DCDuring Up until now, trees were only enabled when one uses |tree=, this part of the vote is about whether trees should be enabled by default (a box appears when {{ety}} is called) or whether they should be disabled by default (no box when {{ety}} is called), either without the help of |tree=, as I understand it. Saumache (talk) 19:28, 17 February 2026 (UTC)[reply]
    Saumache Please read what this specific vote is about. I repeat: "Option 1 (trees are enabled by default and may be disabled with a user gadget)"
    @DCDuring "Enabled", in this context, means that the underlying code will run and will generate the etymology tree box. Contrast that with "disabled", which means that the underlying code will not run at all, leaving no etymology tree box - not even a collapsed one capable of expansion. The vote is saying nothing about collapsing vs uncollapsing, so we can take it that the status quo (for etymology tree boxes to start off collapsed and be capable of expansion by the user if desired) will remain in place. We have never referred to collapsed boxes as "disabled" or uncollapsed boxes as "enabled". This, that and the other (talk) 04:04, 18 February 2026 (UTC)[reply]
    @DCDuring Just as I said, so you might be the one voting for the wrong guy! Saumache (talk) 19:22, 18 February 2026 (UTC)[reply]
    Who wrote this vote? The wording is extremely misleading if you expect broad participation. It would never pass muster in a real-world vote about a proposition. DCDuring (talk) 14:22, 18 February 2026 (UTC)[reply]
    Funny, you had ample time before the vote to ask and make suggestions like others did, yet you didn't. Vininn126 (talk) 14:30, 18 February 2026 (UTC)[reply]
    I believe in the concept of division of labor. In this case, advocates and technowizzes do their thing (debate, etc) and write vote wording suitable for the slower non-technowiz contributors. I am disappointed that the obvious plain-English reading of the headings eliminates the advantage of division of labor, requiring a detailed review of the entire debate. I'm afraid it betrays a kind of insider chauvinism more than most votes. DCDuring (talk) 19:53, 18 February 2026 (UTC)[reply]
    So what you're saying is you can complain despite having contributed nothing to make sure you understand and then vote despite making no effort to make sure you understand what you're voting on. Gotta love editing with you, DC. Vininn126 (talk) 20:01, 18 February 2026 (UTC)[reply]
    Correct. That is how the division of labor in a democratic process has to work. The purpose of a vote is get the views of community members that were neither active participants nor in the audience in a TL;DR debate/discussion. I made the reasonable assumption that the plain English of the proposition on the vote page is a faithful rendition of the proposal made understandable for slower contributors or those who did not in the audience for the discussion. If that assumption is not correct, we may as well not even ask for votes from anyone not active in the discussion. DCDuring (talk) 20:37, 18 February 2026 (UTC)[reply]
    To be fair, there was a discussion about the wording of this vote before it started. Yes, it could have been worded better, but it was suitable for the drafters and those who requested clarification. If you'd like, we can consult you to ensure the wording of future votes meet your criteria. TranqyPoo [💬 | ✏️] 23:47, 18 February 2026 (UTC)[reply]
Abstain
  1.  Abstain I think it’d overall be a very good thing show etymology trees more frequently. But I think we should adopt the same approach as on Issue 1, by letting editing communities decide on the parameter’s use. I would rather support enabling trees by default for some languages but not others. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:35, 13 February 2026 (UTC)[reply]
    @Polomo: I'm sorry but I don't understand this vote. Currently the status quo is much closer to allowing the enabling of trees by default by language community, by giving said language community the option to allow trees in general, as stated on the template page. This new vote would force every language community to have to enable trees if they want to use {{etymon}}, so I don't know how you'd be able to abstain here if the current status quo is closer to what you want. AG202 (talk) 00:46, 16 February 2026 (UTC)[reply]
    I want to see tress enabled by default for the majority of languages, rather than needing to have the |tree= parameter manually inserted. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 01:02, 16 February 2026 (UTC)[reply]
    I could support that, but in the meantime, this vote would force that upon everyone, and if this option passes, it'll likely require another 2/3 vote to change part of it. Also, as stated, it'll disincentivize the use of {{etymon}} entirely for certain communities. AG202 (talk) 21:46, 16 February 2026 (UTC)[reply]
  2.  Abstain I don't see this going well but I don't oppose giving it a try. Ioaxxere (talk) 18:24, 14 February 2026 (UTC)[reply]
  3.  Abstain I object the trees, but since here we're not challenging their existence but rather their visibility, keeping them hidden under the carpet is the best way to ensure that they stay poor and misinformative, while showing them by default forces us to make them at least mediocre. I will keep them invisible as I have been doing until now, whatever informational clutter others want to see is up to them. Catonif (talk) 08:57, 15 February 2026 (UTC)[reply]
    @Catonif: I feel like there's a misunderstanding of the options of this vote vs. what the status quo is. The current status quo gives editor/community discretion using the {{etymon|tree=1}} parameter so it's not a matter of trees being enabled by default, but rather whether someone chooses to add a tree to any entry. If both options in this vote fail, that is what would remain. It's not an either or between Option 1 & Option 2 (and I wish that had been made more clear in the vote's description...).
    Option 1 here will force every instance of {{etymon}}, barring multi-word entries, to display a tree, even if editors had chosen not to display the tree for whatever reason, significantly increasing the work it'll take to verify the displays. When comparing it to the status quo, it is more of an issue of existence rather than visibility, as it'll add a significant amount of trees that hadn't existed before. AG202 (talk) 21:43, 16 February 2026 (UTC)[reply]
    I had not misunderstood the vote, although I agree it isn't clear. I was initially going to oppose with the reasons you give, but realised I would not be able to give a coherent criterion of when an entry should have a tree and when not. The reasons why I dislike the trees (and I hope with my words not to hurt the feelings or lose the favour of the hard-working volunteers who have built the ingenious infrastructure) apply to them in toto. I could not pick out an entry where it would be more or less acceptable than another. Keeping the status quo is an option I can only instinctively prefer because it partially leans towards by preferred direction, but I cannot rationally justify it. Catonif (talk) 22:08, 16 February 2026 (UTC)[reply]
    I do appreciate that you vote based on what you can or can't rationally justify, but I do think that votes do just come down to preference in the end. Most votes either way don't even have an explanation. AG202 (talk) 12:20, 17 February 2026 (UTC)[reply]
    I think that's horrible practice. If you can't justify something, why do it? Vininn126 (talk) 12:23, 17 February 2026 (UTC)[reply]
    I agree, but I don't think that'll change anytime soon as it's not required. AG202 (talk) 05:11, 18 February 2026 (UTC)[reply]
  4.  Abstain —AryamanA (मुझसे बात करें • योगदान) 01:57, 19 February 2026 (UTC)[reply]
Option 2 (trees are disabled by default and may be enabled with a user gadget)
Rationale

Similar to above, but trees are disabled by default. The upside to this is that the box is less intrusive overall.

Support
  1.  Support Thadh (talk) 12:21, 29 January 2026 (UTC)[reply]
  2.  Support If there are users who wish to have this enabled everywhere, despite its drawbacks, so be it. --{{victar|talk}} 22:21, 6 February 2026 (UTC)[reply]
  3.  Support Display by default seems a particularly outrageous imposition on unregistered and casual users. Etymology is not the principal reason any normal human being comes to Wiktionary. The incredibly annoying, screen-space-greedy display would likely lead potential repeat users to become repeat users for other on-line dictionaries. Certainly unreasonable to link the display to whatever other displays are selected by the Visibility selectors on the sidebar at "Show other boxes". A gadget should be sufficient for those enamored of the tree. DCDuring (talk) 18:23, 16 February 2026 (UTC)[reply]
    @DCDuring: Make sure you vote on all three. --{{victar|talk}} 02:42, 17 February 2026 (UTC)[reply]
Oppose
  1.  Oppose - I think that the feature being invisible by default would mean that too few people would be aware of its existence. Vininn126 (talk) 00:00, 29 January 2026 (UTC)[reply]
  2.  Oppose. Agree with Vininn126. TranqyPoo [💬 | ✏️] 00:10, 29 January 2026 (UTC)[reply]
  3.  Oppose — Fenakhay (حيطي · مساهماتي) 22:34, 29 January 2026 (UTC)[reply]
  4.  Oppose: I'm not sure if having trees everywhere is a good idea but if we want people to use them they should be enabled by default. We can have option to disable them in a given entry though Tashi (talk) 23:27, 30 January 2026 (UTC)[reply]
    How does one agree that "having trees everywhere is [not] a good idea", but then vote for having trees everywhere? --{{victar|talk}} 23:56, 6 February 2026 (UTC)[reply]
    @Tashi: I'd suggest checking my comment that I added in this diff. This vote would not mandate a plan to disable them in a given entry, unless they are a multiword entry. The status quo allows editors to enable & display trees in entries where they see fit, using the {{etymon|tree=1}} parameter, and those trees are already enabled for the reader by default.
    However, Option 1 would again force every instance of {{etymon}} to display a tree, removing the choice from the editor. AG202 (talk) 21:51, 16 February 2026 (UTC)[reply]
  5.  Oppose [ɪˈɫa.wə kəˈta.kə] (talk) (edits) 00:59, 31 January 2026 (UTC)[reply]
  6.  Oppose as I said in the previous vote I think the trees are a neat addition so I don't understand why we should make it so that most people won't know they exist as an option? —Caoimhin ceallach (talk) 10:39, 31 January 2026 (UTC)[reply]
  7.  Oppose Saumache (talk) 17:31, 2 February 2026 (UTC)[reply]
  8.  Oppose per Vininn126. – Svārtava (tɕ) 06:43, 8 February 2026 (UTC)[reply]
  9.  Oppose per Vininn126. I am not a fan of the tree but (victar will have a few words for me) I think this is a bad idea as this would result in the ety tree becoming an essentially forgotten easter egg. Having seen some posts from (well, presumably) non-logged in users on Twitter and Bluesky praising the tree as well, it appears our userbase is a fan of the etymology trees, and as such it should not be automatically hidden. LunaEatsTuna (talk) 20:18, 8 February 2026 (UTC)[reply]
    It won't be forgotten by the advocates here. If etymology doesn't carry its own weight as quotations and semantic relations do, it doesn't deserve the lavish treatment it already receives. It won't be missed by those who are looking for a less obstacle-laden path to definitions, which can be found elsewhere. Are you saying we don't need users who aren't interested in etymologies? We don't serve those users who are only interested in sense development, which the tree is not any help with. DCDuring (talk) 15:35, 17 February 2026 (UTC)[reply]
    This I understand, which is why I still think that the status quo (what we have now) is better than either option being presented here. AG202 (talk) 05:04, 9 February 2026 (UTC)[reply]
    I do wonder whether there might be a halfway solution, like a hint icon after etymologies to let people know that a tree view is available. See how less intrusive {{quote}} is. --{{victar|talk}} 07:41, 9 February 2026 (UTC)[reply]
    I would also be more happy with something like that, some kind of small tooltip. Thadh (talk) 10:41, 9 February 2026 (UTC)[reply]
  10.  Oppose — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:35, 13 February 2026 (UTC)[reply]
  11.  Oppose per User:LunaEatsTuna Ioaxxere (talk) 18:24, 14 February 2026 (UTC)[reply]
  12.  Oppose per nom and Luna. expanding that, defaults are the only option that any average user will ever know.  Juwan  🕊️🌈 23:40, 14 February 2026 (UTC)[reply]
  13.  Strong oppose per above. Davi6596 (talk) 15:04, 17 February 2026 (UTC)[reply]
  14.  Oppose —AryamanA (मुझसे बात करें • योगदान) 01:58, 19 February 2026 (UTC)[reply]
Abstain
  1.  Abstain: I prefer the status quo. AG202 (talk) 01:24, 30 January 2026 (UTC)[reply]


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/2023-12/Represent the GenAm NURSE and STRUT vowels as schwa
Wiktionary:Votes/2024-06/CFI for mainspace constructed languages
Wiktionary:Votes/2025-04/Deletion of user talk pages
Wiktionary:Votes/2025-08/Prefer Synonyms and Antonyms Templates
Wiktionary:Votes/2025-09/Delete and regenerate pinyin entries
Wiktionary:Votes/bt-2026-02/WikkiaccounttBot
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?
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Votes&oldid=89572126"