Wiktionary:Votes

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

Wiktionary > Votes

Shortcuts:
WT:VOTE
WT:V

The page Wiktionary:Votes consolidates policy votes and procedural votes that take place on Wiktionary. It formalizes and documents the consensus building and voting policy. For an archive of previous votes, see Wiktionary:Votes/Timeline and Wiktionary:Votes/. This header is at Wiktionary:Votes/header.

Voting policy
  • 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, Wikisaurus, or Concordance namespaces on English Wiktionary by the start time of the vote.
    3. One vote per person. Sockpuppet voting results in a block on all related accounts.
  • Tentative guidelines for the creation of new votes:
    1. Votes should not be called for on this page. They should be the result of prior discussion located elsewhere (the Beer Parlor).
    2. Votes should last about a month, usually, or two weeks for bots.
    3. No topic should have a new vote more than once a day (24 hr period).
    4. Votes should use {{premature}} while working out the particular wording.
  • The failure of a vote does NOT mean that it cannot become a new vote in the future.
Voting procedure
  1. Once a discussion has reached a point where a vote is in order, a new voting page should be created here, linked to and from the original discussion, including {{premature}}.
  2. Once the vote is ready to start, the voting page should be included here and then the start and end dates filled.
  3. Debate is welcome on these pages.
  4. Each vote will remain in the “current and new votes” section for a while after the completion of the vote, at which time it will be archived and listed in the “recently ended votes” section.
Starting a new vote on this page
  1. Replace “Title of vote” with what you’d like to start a vote on, or add the relevant user in one of the boxes below.
  2. Ctrl-A, Ctrl-C (select all, copy) of the text in that input box (it is the new link).
  3. Edit in a new tab this page and add the one line of magic text below the editbox. Again, replace “Title of vote” with your exact vote topic name. Remember to add {{ and }} around your pasted text.
  4. For nominations that should be listed in multiple places (in essence, WT:A, WT:B or WT:C) open that page in another new tab and repeat the pasting of the transclusion line.
  5. Click the button below the relevant box, fill out the form displayed and save it.


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


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


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


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


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


{{Wiktionary:Votes/bt-2015-03/User: for bot status}}
Other

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

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

Current and new votes

Planned and running votes

Migrating from Template:term to Template:m

Support

  1. Symbol support vote.svg Support --Vahag (talk) 18:23, 29 August 2014 (UTC)
  2. Symbol support vote.svg Support —CodeCat 19:28, 2 September 2014 (UTC)
  3. Symbol support vote.svg Support Mulder1982 (talk) 19:45, 12 September 2014 (UTC)
  4. Symbol support vote.svg Support, but I would like the final result to be {{term}} redirecting to {{m}} (or vice versa). --WikiTiki89 19:46, 12 September 2014 (UTC)
    To do that, we would first need to orphan {{term}}, as the parameters are not compatible. And at that point there is no need for a redirect anyway, is there? —CodeCat 20:03, 12 September 2014 (UTC)
    Yeah there is: so that people can start using {{term}} instead of {{m}} if they feel like it suits them better. --WikiTiki89 20:05, 12 September 2014 (UTC)
    We should aim at there being one template in the mainspace. We should aim at at least a semblance of professionalism. Keeping term with old parameter order to make old revision legible is fine. --Dan Polansky (talk) 20:13, 12 September 2014 (UTC)
    Actually, that's also a good idea. --WikiTiki89 20:31, 12 September 2014 (UTC)
  5. Symbol support vote.svg Support — It's better to have one term (whichever) than two - since the newbie suspects there's a subtle difference between them. Since most will look for an example (like me) either would do, but m is shorter — Saltmarshαπάντηση 19:30, 5 November 2014 (UTC)
  6. Symbol support vote.svg Weak support — I can agree that "term" is more descriptive than "m", which can be confusing. On the other hand, not needing a named language parameter makes things a lot easier. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:14, 25 November 2014 (UTC)
  7. Support "term" does not mean what it says, and it's NOT more descriptive; it's misleading, beside being longer. "m" would force the newbies to read the docs, which is eventually a good thing, because by seeing "term" they probably think that they already know what the template does, while they usually don't. --Z 10:07, 1 December 2014 (UTC)
  8. Symbol support vote.svg Support per Z. --Fsojic (talk) 10:53, 1 December 2014 (UTC)
  9. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 02:05, 8 December 2014 (UTC)
  10. Support per Z. — Keφr 08:02, 9 December 2014 (UTC)
  11. Symbol support vote.svg Support. {{m}} is much easier to use and should be the default. I agree with Wikitiki89, though, that it's best to leave {{term}} functional, since it's been in use for so long, and because we should go as easy as possible on casual editors. I think the best course of action is to swap out current uses of {{term}} to reduce confusion and encourage the use of {{m}}, but not to introduce any overt obstacles to use of {{term}} by those who want to use it (hidden tracking categories should be ok). I can understand the resentment of many here for the way the changes in behavior of some templates with respect to omitted language codes was handled, but, on balance, I think this is a better course of action. Chuck Entz (talk) 20:15, 3 January 2015 (UTC)
  12. Symbol support vote.svg Support embryomystic (talk) 05:25, 22 January 2015 (UTC)
  13. Symbol support vote.svg Support — Ungoliant (falai) 05:29, 22 January 2015 (UTC)
  14. Symbol support vote.svg Support Vorziblix (talk) 01:25, 29 January 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose No user will ever guess what {{m}} means, while the meaning of {{term}} is rather obvious. We need to think about non-regulars and casual contributors too. -- Liliana • 18:05, 29 August 2014 (UTC)
    At least the name of {{m}} is intriguing while term is misleading - one may take it for only a decorating template (like I did until recently xD).--Dixtosa (talk) 19:07, 29 August 2014 (UTC)
    Just to note, {{m}} is now a shortcut for the more descriptive name {{mention}}, while {{l}} is likewise a shortcut to {{link}}. —CodeCat 21:10, 5 November 2014 (UTC)
    I always thought {{l}} stood for "list-item", not just "link". — Keφr 09:05, 8 December 2014 (UTC)
    I also thought that. --WikiTiki89 09:33, 8 December 2014 (UTC)
  2. Symbol oppose vote.svg Oppose. It's a cryptic and unhelpful name. But I think the parameter order of {{m}} is better. Perhaps it would be nice to migrate all existing uses of {{term}} to that parameter order. This, that and the other (talk) 07:37, 31 August 2014 (UTC)
  3. Symbol oppose vote.svg Oppose deleting Template:term. No opinion regarding any other action. —Mr. Granger (talk • contribs) 19:32, 2 September 2014 (UTC)
  4. Symbol oppose vote.svg Oppose. The name term is more comprehensible. The old revision histories will be clearer (not that that's a strong argument in my opinion, but it's worth something). And even if all were equal (m and term were equally good), there'd be no reason to specifically change from one to the other. I have no opposition, however, to reordering the parameters of either template to match those of the other, provided that that's done without introducing errors.​—msh210℠ (talk) 16:35, 18 September 2014 (UTC)
    Changing {{term}}'s parameters to match {{m}} would break the old revision histories anyway. --WikiTiki89 20:45, 18 September 2014 (UTC)
  5. Symbol oppose vote.svg Oppose. As above - term means what is says; m will always mean masculine to me. SemperBlotto (talk) 08:51, 13 October 2014 (UTC)
  6. Symbol oppose vote.svg Oppose Per others, especially Liliana's argument. User: PalkiaX50 talk to meh 09:19, 13 October 2014 (UTC)
  7. Symbol oppose vote.svg Oppose --Dijan (talk) 19:33, 14 October 2014 (UTC)
  8. Symbol oppose vote.svg Oppose strong. Another unnecessary merge. Purplebackpack89 14:14, 2 November 2014 (UTC)
  9. Symbol oppose vote.svg Oppose – I read the ‘rationale’ but can't see any explanation…does this new template do something different? If not, why can't we just change how {{term}} works? And why ‘m’?! Basically, no. Ƿidsiþ 08:15, 17 November 2014 (UTC)
    If we change term to work like m... that's basically what the support camp is arguing for. That's basically support but under another name. Renard Migrant (talk) 18:54, 7 December 2014 (UTC)
    @Renard Migrant: I don't think so. The disagreement seems to be about the template name. I don't see anyone insisting that term should be used like {{term|...|lang=en}} instead of {{term|en|...}}. --Dan Polansky (talk) 18:59, 7 December 2014 (UTC)
  10. Symbol oppose vote.svg Oppose This doesn't simplify anything. At all. --Neskaya sprecan? 05:02, 28 December 2014 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain I can't decide between the pros and the cons. --Dan Polansky (talk) 17:18, 26 September 2014 (UTC)
  2. Symbol abstain vote.svg Abstain, I prefer {{m}} but I see no reason to 'ban' {{term}}. Renard Migrant (talk) 18:50, 7 December 2014 (UTC)
    @Renard Migrant: Would it be accurate to say you support "Replacing all uses of Template:term with Template:m" but not "subsequently discontinuing Template:term"? --Dan Polansky (talk) 18:56, 7 December 2014 (UTC)
    No it wouldn't. Renard Migrant (talk) 12:37, 21 January 2015 (UTC)

Decision

  • No consensus (14-10-2; 58% support) after 6 months of voting. This, that and the other (talk) 01:56, 1 March 2015 (UTC)
    For completeness: Mr. Granger said "oppose deleting Template:term. No opinion regarding any other action", so migrating the template without deleting {{term}} has 14-9-3 = 60.9% support. That is still "no consensus". --Dan Polansky (talk) 10:01, 1 March 2015 (UTC)

Templates context and label

  • Polling on: Clarifying which template to use to tag definition lines as "countable", "transitive", "colloquial", "geography" and the like. Currently available templates are {{context}}, {{cx}}, {{label}}, {{lb}}. The choice is about template name, not about syntax of its parameters. Two choices are presented: one between (context, cx) and (label, lb), and another one between long form (context, label) and short form (cx, lb).

    The syntaxes might look like this, assuming the language as the first parameter of the template:

    • {{context|es|colloquial}}
    • {{cx|es|colloquial}}
    • {{label|es|colloquial}}
    • {{lb|es|colloquial}}

I prefer label over context

  1. Symbol support vote.svg Support Because {{label}} takes the language as the first parameter, whereas {{context}} requires lang=. —CodeCat 19:25, 2 September 2014 (UTC)
    The vote text makes it clear this is about the template name, not about the parameter order and syntax. We can make {{context}} behave exactly like {{label}}, yielding syntax like {{context|es|colloquial}}. --Dan Polansky (talk) 17:28, 3 September 2014 (UTC)
  2. Symbol support vote.svg Support More accurate when dealing with grammatical categories like "transitive" or "passive", or "with accusative", and still fits the idea of a context semantically. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:20, 25 November 2014 (UTC)
  3. Symbol support vote.svg Support embryomystic (talk) 23:37, 6 December 2014 (UTC)
  4. Symbol support vote.svg Support per Newt. Vorziblix (talk) 01:32, 29 January 2015 (UTC)

I prefer context over label

  1. Symbol support vote.svg Support We want to make it clear that you aren't supposed to write definitions like "(tree) oak", and context does a better job at that. -- Liliana • 10:57, 30 August 2014 (UTC)
    That could be addressed by template documentation. And how often has this been a problem in practice? — Keφr 15:28, 2 November 2014 (UTC)
  2. Symbol support vote.svg Support I prefer to make clear that register and other context information is the primary purpose of information so position on a definition line. DCDuring TALK 16:51, 25 October 2014 (UTC)
  3. Symbol support vote.svg Support, and in addition, I'd like to note that I prefer slang and certain other things being decoupled from context. Purplebackpack89 14:16, 2 November 2014 (UTC)
    Nonsensical. Of all things, "slang" is definitely a context label. — Keφr 15:28, 2 November 2014 (UTC)
    @Kephir:: And? The main jist of my comment is I believe context covers too many things that would be better covered in other templates Purplebackpack89 22:55, 28 November 2014 (UTC)

I prefer short template name over long template name

  1. Symbol support vote.svg Support Dan Polansky (talk) 09:50, 30 August 2014 (UTC) I dislike the introduction of {{context}}, but if we need to have a template before "colloquial" and the like, let it be short. --Dan Polansky (talk) 09:50, 30 August 2014 (UTC)
    Symbol oppose vote.svg Oppose —CodeCat 19:27, 2 September 2014 (UTC)
  2. Symbol support vote.svg Support I don't care whether the short name is botically changed afterward to a longer, more communicative name: I just like to save keystrokes. DCDuring TALK 16:47, 25 October 2014 (UTC)
  3. Symbol support vote.svg Support Ivan Štambuk (talk) 21:49, 26 October 2014 (UTC)
    Symbol abstain vote.svg Abstain Too amorphous, depends on what the short and long template names are Purplebackpack89 14:17, 2 November 2014 (UTC)
  4. Symbol support vote.svg Support, but also in agreement with This below. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:20, 25 November 2014 (UTC)
    Symbol oppose vote.svg Oppose --Neskaya sprecan? 16:50, 8 January 2015 (UTC)
    This poll was designed to be free from opposes in these "I prefer" sections; each preference has a heading under which a support can be filed, and a complementary heading. I won't be removing these "opposes", but they make the poll results a bit more confusing. --Dan Polansky (talk) 13:38, 10 January 2015 (UTC)
    I've indented non-supports to ease counting of supports. --Dan Polansky (talk) 13:54, 10 January 2015 (UTC)
  5. Symbol support vote.svg Support Vorziblix (talk) 01:32, 29 January 2015 (UTC)

I prefer long template name over short template name

  1. Symbol support vote.svg Support again, for clarity purposes. -- Liliana • 10:57, 30 August 2014 (UTC)
    Symbol oppose vote.svg Oppose —CodeCat 19:27, 2 September 2014 (UTC)
    I've indented non-supports to ease counting of supports. --Dan Polansky (talk) 13:54, 10 January 2015 (UTC)
  2. Symbol support vote.svg Support because clarity and readability, also accessibility to new users on the project. --Neskaya sprecan? 16:49, 8 January 2015 (UTC)

Oppose the poll

  1. Why can't we have them all, as redirects to the one central template? Or is this vote to choose a "canonical" name for the template? This, that and the other (talk) 07:39, 31 August 2014 (UTC)
    This is a poll about which template editors prefer. This poll does not propose any deletion of a template. A participant in the poll may clarify in their comment that they oppose deletion of any template. Right now, at least one editor is performing a particular conversion in the mainspace, and we do not know whether that conversion matches editor preferences. --Dan Polansky (talk) 15:55, 31 August 2014 (UTC)
  2. Moo. — Keφr 14:05, 4 September 2014 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain. Whateva. Renard Migrant (talk) 16:55, 8 January 2015 (UTC)

Decision

This was a difficult vote to close, and if anyone disagrees with anything I have written below, I am open to being corrected.

  • The choice between the template names "context" and "label" did not reach a consensus: 4 users (57%) prefer "context" while 3 (43%) prefer "label".
  • The choice between long and short template names came out as follows:
    • 5 users preferred the short template name. One of the users who opposed the short template name supported the long template name.
    • 2 users preferred the long template name.
    • 1 user opposed both choices, and 2 others "opposed the poll".
  • On the basis of the numbers, it appears there is support for the short template name (5-2; 72% support). However, I don't think this vote was very well structured, and I would recommend a second vote be held with a more explicit statement and clearer options. For example, it is not apparent, from the statement at the top of the vote, what exactly is meant by "clarifying which template to use"; it would have been clearer to state exactly what will happen to the template that is not preferred.

This, that and the other (talk) 02:27, 1 March 2015 (UTC)

This is a poll ("Polling on", "Poll starts", "Poll ends"), so it cannot be really "closed" in a way leading to immediate action or decision. It was intended to form a basis for a follow-up vote. However, too few people posted their preferences for us to have a truly representative sample. Judging from the limited sample that this poll provided, one could try to create a vote that proposes to give editors a go ahead to use automatic and semiautomatic means to replace all occurrences of {{context}} with {{lb}}. --Dan Polansky (talk) 09:35, 1 March 2015 (UTC)


Migrating from Template:context to Template:cx

  • Voting on: Replacing all uses of {{context}} with {{cx}}. First making sure {{cx}} is unused, then changing {{cx}} to use "cx|en|colloquial" syntax instead of "cx|colloquial|lang=en" syntax, then furnishing {{cx}} with the fastest code currently available in Wiktionary templates and modules for the purpose, and then performing the replacement. No proposal is being made about whether {{context}} should be retained afterwards, e.g. to simplify reading of revision history.
  • Rationale: For a rationale, see Wiktionary talk:Votes/2014-08/Migrating from Template:context to Template:cx#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote starts: 00:01, 5 October 2014 (UTC) (delayed by one month)
  • Vote ends: 23:59, 5 November 2014 (UTC)
    • Vote extended to 23:59, 30 December 2014. (UTC) --Dan Polansky (talk) 22:51, 28 November 2014 (UTC)
    • Vote extended to 23:59, 30 January 2015 (UTC) --Dan Polansky (talk) 08:26, 30 December 2014 (UTC)

Support

  1. Symbol support vote.svg Support Dan Polansky (talk) 08:40, 5 October 2014 (UTC)
  2. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 00:49, 3 December 2014 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose due to the fact that it needlessly complicates things. Why are we moving templates away from things that can be remembered again? "context" is a lot clearer to newer editors to use than "cx", and always will be. --Neskaya sprecan? 17:50, 29 October 2014 (UTC)
  2. Symbol oppose vote.svg Oppose Whenever you migrate a template, you kill a kitten and drive an editor off the project. Purplebackpack89 19:43, 2 December 2014 (UTC)
    No, I actually read a study this the other day. There is no statistically significant correlation between template migration and kitten deaths. --WikiTiki89 00:44, 3 December 2014 (UTC)
    I think you missed the point. The point is template migration confuses the heck out of editors. IMO, it's in the top 5-10 of reasons editors throw up their hands and leave the project. So it should be avoided whenever possible. It's possible to avoid it here. Purplebackpack89 14:33, 3 December 2014 (UTC)
    I think you missed my point: I was joking. --WikiTiki89 15:52, 3 December 2014 (UTC)
    Not sure what to respond to that. This is formulated as a blanket opposition to any and all template migrations. I think this extreme position is generally harmful; there should be moderation in template migrations, but to do template migrations after careful deliberation, after a public discussion took place and editors agree is useful. I do not believe infrequent and carefully deliberated template migrations drive productive editors away.--Dan Polansky (talk) 09:59, 20 December 2014 (UTC)
    For one thing, Dan, it's not infrequent in this case. There are slang terms that used to have their own templates, and then (wrongfully, IMO) got merged into Template:context. Now, people are using Template:label instead, and proposing to move Template:context. So, a high-profile template has been migrated multiple times since I got here. And if it's happened multiple times, it means we weren't careful or deliberate the first time. The other problem is that a lot of editors seem to expect the learning curve on new or migrated templates to be quick and easy. From all the evidence I've seen, it isn't. Wiktionary is already hard to use as it is (with overuse of templates and arbitrary policy); migrating templates makes it worse. Purplebackpack89 14:58, 19 January 2015 (UTC)
    The migrations you mention happened and are happening without votes. They would not have so easily happened via a vote. Yes, we used to have {{slang}}, and yes, I would have opposed migrating away from it. --Dan Polansky (talk) 18:21, 19 January 2015 (UTC)
  3. Symbol oppose vote.svg Oppose If users don't become editors, one of the main reasons is that the internal page format frightens them. Everything making it still less readable is a bad thing. Lmaltier (talk) 18:29, 19 January 2015 (UTC)
    Any evidence? (They don't have these wikitext hurdles at OmegaWiki, but OmegaWiki does not fare better than the English Wiktionary.) --Dan Polansky (talk) 19:25, 19 January 2015 (UTC)
    Most Wiktionary editors come from Wikipedia, they are used to the wiki syntax. I was not referring to it, but to all these templates making the page difficult to understand. On fr.wikt, we already had a number of users telling us that they could not contribute to Wiktionary because of that. Lmaltier (talk) 21:23, 19 January 2015 (UTC)

Abstain

  1. Moo. — Keφr 09:21, 5 October 2014 (UTC)
    What an interesting self-disclosure. As per moo, are you (a) a cow, (b) a bull or (c) a foolish woman? --Dan Polansky (talk) 09:23, 5 October 2014 (UTC)
    I think he means mu#Etymology 2. —Aɴɢʀ (talk) 13:11, 5 October 2014 (UTC)
  2. Symbol abstain vote.svg Abstain There are too many options that are not accounted for in this vote. --WikiTiki89 00:54, 3 December 2014 (UTC)
  3. Symbol abstain vote.svg Abstain because polls are evil. —Aɴɢʀ (talk) 14:34, 3 December 2014 (UTC)
    Policy votes in English Wiktionary -- transparent, fair, open-to-discussion and timely collective decision making enabling broad editor participation since 2006. --Dan Polansky (talk) 17:10, 5 December 2014 (UTC)
    Policy votes in English Wiktionary — replacing discussion and consensus-seeking with divisiveness and the tyranny of the majority since probably earlier than 2006. —Aɴɢʀ (talk) 20:35, 5 December 2014 (UTC)
    I ask the reader to check English Wiktionary votes to verify the presence of plentiful open discussion (a) before the votes in locations referenced by the votes, (b) directly on the vote pages, and (c) on the talk pages of the votes. I also ask the reader to verify in the votes that plain majority does not get to decide in English Wiktionary votes as evidenced by the closure of the votes; we actually decide by supermajority, at the very least 2/3 of voters, although higher thresholds have been mentioned. I also submit to the reader that I saw no unjust or cruel rule imposed by the votes, so no case of "tyranny" can be confirmed. To the contrary, I point to my favorite vote Wiktionary:Votes/pl-2010-05/Names of specific entities, which relaxed stringent requirements on proper names required by a vocal minority; via that vote, a rule by a minority via inflexible application of unvoted-on policy in RFV process was removed. --Dan Polansky (talk) 21:58, 5 December 2014 (UTC)

Decision

  • No consensus (2-3-3; 40% support) after 5 months of voting. The turnout here was poor, and I think Wikitiki89 makes a good point in their Abstain vote. If the creator of this vote had waited until the closure of the "Templates context and label" vote, it might have been able to be more meaningfully structured. This, that and the other (talk) 08:18, 1 March 2015 (UTC)

Renaming rhyme pages

Support proposal 1

  1. Symbol support vote.svg Support Even if it wasn't a fait accompli I would still have supported it. This, that and the other (talk) 10:24, 23 September 2014 (UTC)
  2. Support Having a slash (/) after the language name is a natural extension of our appendix names like "Appendix:Frankish/kawa". — Keφr 07:55, 9 December 2014 (UTC)
  3. Symbol support vote.svg Support, works better because of the subpage system and templates like {{subpages}}. Renard Migrant (talk) 14:05, 4 January 2015 (UTC)
  4. Symbol support vote.svg Support Lmaltier (talk) 16:35, 4 January 2015 (UTC)
  5. Symbol support vote.svg Support per Kephir. DCDuring TALK 16:41, 4 January 2015 (UTC)
  6. Symbol support vote.svg Support per above. Gizza (t)(c) 09:36, 29 January 2015 (UTC)

Oppose proposal 1

  1. Symbol oppose vote.svg Oppose Having colon (:) after the language name is a natural extension of our category names like "Category:en:Physics". --Dan Polansky (talk) 19:58, 23 September 2014 (UTC)
    But we only do that with language codes, while the Rhymes pages currently use language names. --WikiTiki89 20:19, 23 September 2014 (UTC)

Abstain from proposal 1

  1. Symbol abstain vote.svg Abstain It really makes no difference to me. --WikiTiki89 14:50, 23 September 2014 (UTC)
  2. Symbol abstain vote.svg Abstain Me either. —Aɴɢʀ (talk) 13:25, 4 January 2015 (UTC)

Support proposal 2

  1. Support, though quite weakly, on the grounds that it makes some string processing simpler. The hyphen carries zero entropy; or in plain English, everyone already knows that we are dealing with suffixes, indicating that explicitly is unnecessary. If we ever find ourselves making pages in rhymes namespace which are not rhymes lists, I might change my mind. — Keφr 07:55, 9 December 2014 (UTC)
    You mean that Lua code does not need to drop the leading "-"? That is very straightforward for Lua code to do. Is that the reason why we should not prioritize human ease of recognition of what is presented on the user interface? --Dan Polansky (talk) 12:28, 14 December 2014 (UTC)
    For Lua code this is easy, for plain templates less so. — Keφr 14:20, 4 January 2015 (UTC)
    Plain templates can call Lua to drop the hyphen (or minus), right? --Dan Polansky (talk) 14:22, 4 January 2015 (UTC)
  2. Support. When you look for rhymes, you know what you mean. And it sometimes happens that the rhyme is the complete word pronunciation (e.g. it), which makes the - meaningless. Lmaltier (talk) 16:30, 4 January 2015 (UTC)
    I think of e.g. "-eɪm" as the regular expression ".*eɪm", where .* also matches an empty string (or think if "*eɪm" if you are used to file name patterns). --Dan Polansky (talk) 22:32, 7 January 2015 (UTC)
    This is not the usual meaning of - for suffixes. Therefore, this might be slightly misleading. But the important point is that it's not needed, it would not help anybody. Lmaltier (talk) 22:38, 7 January 2015 (UTC)
    You are right that the whole word matching the ending is something of an oddity, one which does not happen with morphological suffixes AFAIK. But again, it does not feel like a real problem to me. To your other point: hyphen does help me to immediately recognize what is going on, and I am missing it when I don't see it. So it is not accurate to say it would not help anybody, when it in fact helps at least me. In fact, hyphen is still used in the mainspace: check e.g. name where it says "Rhymes: -eɪm". (It says so now; I cannot rule out a non-consensual change to follow.) The person who originally designed the rhyme pages with hyphen must have felt and perceived the same way as I do. --Dan Polansky (talk) 22:48, 7 January 2015 (UTC)

Oppose proposal 2

  1. Symbol oppose vote.svg Oppose Makes it clear that we're talking about suffixes. This, that and the other (talk) 10:24, 23 September 2014 (UTC)
  2. Symbol oppose vote.svg Oppose What he^ said. --WikiTiki89 14:50, 23 September 2014 (UTC)
  3. Symbol oppose vote.svg Oppose The rhyme pages are organized by what is an auditory analogue of a suffix. Since suffixes are usually denoted with a leading dash (e.g. -ness), using dash in rhyme page names seems natural. --Dan Polansky (talk) 19:58, 23 September 2014 (UTC)
  4. Symbol oppose vote.svg Oppose What they↑ said.​—msh210℠ (talk) 12:09, 15 October 2014 (UTC)
  5. Symbol oppose vote.svg Oppose Per above. DCDuring TALK 16:43, 4 January 2015 (UTC)

Abstain from proposal 2

  1. Symbol abstain vote.svg Abstain We aren't talking about suffixes. The /eɪm/ of name isn't a suffix. It's a syllable rhyme. But I still don't really care whether that's indicated by a leading hyphen or not. —Aɴɢʀ (talk) 13:27, 4 January 2015 (UTC)
    We are talking about auditory analogue of a suffix, not a morphological suffix. --Dan Polansky (talk) 14:10, 4 January 2015 (UTC)
    But a hyphen is written, not oral. Renard Migrant (talk) 14:13, 4 January 2015 (UTC)
    Yes, hyphen is written, so is IPA. So what? Both the hyphen and IPA are written to indicate what is auditory. The hyphen before the IPA suggests that the IPA is not a complete IPA (of a complete word) but rather IPA missing something at the left. --Dan Polansky (talk) 14:17, 4 January 2015 (UTC)
    To write "The /eɪm/ of name" is misleading; one should write "the /eɪm/ of /neɪm/". --Dan Polansky (talk) 14:24, 4 January 2015 (UTC)
    OK, rather than "suffixes", say "endings". I'm no lexicographer. This, that and the other (talk) 11:34, 7 January 2015 (UTC)
  2. Symbol abstain vote.svg Abstain I agree 100% with Angr. Renard Migrant (talk) 13:51, 4 January 2015 (UTC)

Decision

  • Proposal 1 passes (6-2-2 = 75%), proposal 2 fails (2-5-2 = 29%, noting also that one of the support votes was "quite weak"). In my interpretation, this means that Rhymes pages should be named along the lines of Rhymes:English/-eɪm. This, that and the other (talk) 05:41, 22 February 2015 (UTC)
    Agreed. I'll start moving rhyme pages to this naming scheme. Maybe someone with a bot can help. --Dan Polansky (talk) 10:24, 22 February 2015 (UTC)

Adding RFEs to all lemma entries where etymology is missing

Support

Oppose

  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 09:03, 14 December 2014 (UTC) I have never seen substantive numbers of etymologies added by people filling in RFE requests. The people whom I saw add larger numbers of etymologies did not go by requests; similarly, the people whom I saw add larger numbers of Latin lemma entries did not go by requests. The presence of RFE in every lemma entry may possibly slightly increase the rate of addition, but only at the cost of flooding Wiktionary mainspace with information-free etymology sections for many years.

    An editor mentioned that placing requests worked well for inflection. I do not know whether this is true, but even if it is true, we have to realize that, for native speakers, inflection is largely trivial and easy-to-fill, whereas etymology requires research in sources unless it is folk etymology.

    As for evidence, I have seen presented no evidence to support claims about efficacy of placing these sorts of request boxes to pages. Such evidence could be collected from dumps. --Dan Polansky (talk) 09:03, 14 December 2014 (UTC)

  2. Symbol oppose vote.svg Oppose I always try to add etymology where I can, but this info is not always available, or incomplete. Entering the etymology of compound words can be a lot easier. The mass addition of RFE to entries tends to make them look untidy. Donnanz (talk) 09:15, 14 December 2014 (UTC)
  3. Symbol oppose vote.svg Oppose, but I wouldn't be opposed to lemmata missing an etymology being placed in a hidden category (according to language, e.g. "Category:English lemmata with no etymology section"). This, that and the other (talk) 06:03, 18 December 2014 (UTC)
  4. Symbol oppose vote.svg Oppose, but I agree that a hidden category is fine. —Mr. Granger (talk • contribs) 15:17, 18 December 2014 (UTC)
  5. Symbol oppose vote.svg Oppose, some of the other language Wiktionaries have such requests for every section, but it hasn't (as far as I am aware) encouraged lots of editors to join and add the missing information. Kaixinguo (talk) 15:35, 10 January 2015 (UTC)
  6. Symbol oppose vote.svg Oppose as proposed. A great many languages and words are not even etymologically well-researched in the first place. A hidden category sounds like a good idea though, but should not be conflated with items tagged with regular {{rfe}}. Something like "entries with no etymology" for the former, "entries with etymology requested" for the latter? --Tropylium (talk) 02:42, 31 January 2015 (UTC)
  7. Symbol oppose vote.svg Oppose Equinox ◑ 02:47, 31 January 2015 (UTC)

Abstain

Decision

  • Fails (0-7-0; 0% support). My suggestion of a hidden category had limited support from the oppose voters; this could be the subject of further discussion. This, that and the other (talk) 01:59, 1 March 2015 (UTC)

Making simplified Chinese soft-redirect to traditional Chinese

Support

  1. Symbol support vote.svg Support. Altthough simplified is the standard in PRC and Singapore, I vote for centralization of Chinese entries. It can be one or the other, not both. --Anatoli T. (обсудить/вклад) 04:27, 26 December 2014 (UTC)
  2. Symbol support vote.svg Support Wyang (talk) 22:11, 27 December 2014 (UTC)
  3. Symbol support vote.svg Support Centralisation of data will greatly facilitate the work of editors and the parsing of chinese entries for reuse of wiktionary data.
    For the problem of readers only interested in simplified being invaded by traditionnal in examples, traditionnal will be dispalyed anyway in entries which are both simplified and traditionnal. Keeping Simplified and traditionnal separated don't solve this problem and will create inconsistency in the display of chinese entries.Meihouwang (talk) 09:17, 28 December 2014 (UTC)
    There is a lot of opposition on this vote. Maybe we should instead do a vote on centralising data in traditional page and displaying definitions in simplified page with a template. This way we will get most of the opposing people on our side. I read some people said that it is not technicaly possible but I have already parsed wiktionary data to use in a chinese dictionnary that I am programming. I was able to store definitions in my database sorted by Simplified/Traditionnal/Pinyin using {{zh-hanzi-box}} to know in which Simp/Trad pair the definitions should be stored. Character with several Simp/Trad pair have several {{zh-hanzi-box}} (At least in the entries I edited). I think displaying definitions from traditionnal page on simplified page should be less complicated than this. But I have no experience with Wiktionary scripting so I might be wrong. Meihouwang (talk) 16:09, 9 January 2015 (UTC)
  4. Symbol support vote.svg Support Avoids duplication of content, which is a scourge of this dictionary (especially for non-English languages). Ideally what we would do is automagically replicate the contents of the traditional entry at the simplified page, with all traditional forms converted to simplified. But that is not technically feasible right now. This, that and the other (talk) 11:32, 7 January 2015 (UTC)
  5. Symbol support vote.svg Support DTLHS (talk) 17:21, 8 January 2015 (UTC)
  6. Symbol support vote.svg Support Reducing duplication is good, and makes Wiktionary easier to manage. I call upon the opposers to be more constructive, and propose an alternative idea that would reduce the workload of managing Chinese entries in another way. Voting oppose to solutions doesn't make the problem go away. —CodeCat 17:24, 8 January 2015 (UTC)
    An alternative idea that would reduce the workload has been put forward and its is to make traditional Chinese make soft-redirect to simplified. Why are people to fast to dismiss that? It has been claimed that the other way is easier to maintain for contributors but how much more work is it really to make it the other way? Simplified is used far more than traditional so if we can make the simplified form the lemma that must be the right thing to do. Kinamand (talk) 18:40, 8 January 2015 (UTC)
  7. Symbol support vote.svg Support --Vahag (talk) 00:24, 12 January 2015 (UTC)
  8. Symbol support vote.svg Support --Ivan Štambuk (talk) 01:42, 12 January 2015 (UTC)
  9. Symbol support vote.svg Support I do not agree that a soft direct makes it look like an implicit claim that one of the two is more correct. Everyone knows that the traditional form came first. It is true that there is no one-to-one correspondence between simplified and traditional, but it is reasonably close. Simplified 后 = Traditional 後 (hòu, "after") and 后 (hòu, "queen"). The Chinese and Japanese characters (and their categorization) are extremely complex, and it actually requires more knowledge to make use of the Wiktionary offerings of these languages. Splitting 后 into 後 and 后 will be a relative minor hurdle for users. If we do not use redirects, simplified 后 becomes doubly complex, since it has to define both meanings (and sometimes different pronunciations), as well as different etymologies. —Stephen (Talk) 03:48, 13 January 2015 (UTC)
    Good example, Stephen! I have just made a split of two etymologies for 後／后 and 后. Maintaining in sync complicated entries like 惡／恶 is quite complicated. Editors have been focussing on one or the other form. The unified approach allows to treat both forms equally, without making one form or the other better, literally. That's the approach taken by the majority of electronic or book dictionaries. It's impossible to centralise the contents while having duplicate entries. Entries get out of sync momentarily. Eventually, it may be possible to include the contents of the traditional entry in the simplified one. --Anatoli T. (обсудить/вклад) 04:40, 13 January 2015 (UTC)
    Stephen mentioned 後／后 and 后 because of their non-trivial simplified/traditional conversions. They needed attention, so I fixed them. For relative complexity I meant 惡／恶, which now has a list of derivations in both trad. and simpl. forms, previously only in simplified form in 恶 only. The traditional entry didn't have derivations. Now it has. Note that the entry has usage examples and derived forms IN BOTH TRADITIONAL AND SIMPLIFIED. This is how the Chinese entries are meant to look with the new structure. No discrimination, the only disadvantage is having to click through from to traditional to simplified. There is no problem with sound or many other English or Chinese entries with multiple etymologies. However, there are problems with various revisions of color and colour. One thing that commonly quickly makes them out of sync is translation tables or lack thereof. Template {{trans-see}} is used for that to avoid duplication of contents. Yes, one can copy/paste from one another but how long will it be before they get out of sync? {{zh-see}} is meant to link to the Chinese entry, which contains info in both character sets (unlike Serbo-Croatian, for example, which only display the other form in the header). We didn't create the rationale for this vote but the change is not meant to make one character set better than the other, no. It's all about centralising the contents. --Anatoli T. (обсудить/вклад) 21:48, 13 January 2015 (UTC)
    As the reader can see in this revision of 恶, section Mandarin, there were derived terms in simplied script before Atitarev removed them (diff); his solution is to have a mixed table of compounds as in 惡#Chinese, where the list now mixes both simplified and traditional. The first four items look like this:
    The reader who wants to only deal with simplified script will no longer have the option, and the same is true of the traditional script; both scripts will be presented at the same time in example sentences and derived term lists.
    The reason I do not undo those non-consensual changes by Atitarev and others is above all that I do not want to get into a revert war, and that I prefer the civilized methods of government exemplified by this vote. --Dan Polansky (talk) 22:12, 13 January 2015 (UTC)
    Symbol support vote.svg Support. Traditional characteristics contain more meaningful information for the words or terms of the culture. This is what our dictionary really needs.--Wildcursive (talk) 15:05, 18 January 2015 (UTC)
    Vote struck as invalid per policy. — Keφr 21:07, 18 January 2015 (UTC)
  10. Symbol support vote.svg Support Whether it's a preference of one script over another is simply one's value judgment at work. To me, if it help improve editing, that's all that matters. Jamesjiao → T ◊ C 22:47, 19 January 2015 (UTC)
  11. Symbol support vote.svg Weak support This is not a hard redirect and can reduce a lot of duplicate entries which can not be synchronized. However:
    1. Only redirect words which is not used by Japanese;
    2. Do not redirect character. They contains non-translingual data.
    This problem will ultimately be resolved by Wiktionary support of Wikidata (phab:T986).--GZWDer (talk) 15:10, 27 January 2015 (UTC)

Oppose

Oppose. Bad idea! 173.89.236.187 04:09, 26 December 2014 (UTC)
Anonymous accounts can comment but they can't vote. --Anatoli T. (обсудить/вклад) 04:27, 26 December 2014 (UTC)
  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 10:01, 26 December 2014 (UTC) Making simplified Chinese entries mere soft redirects (featuring no definitions) would create a significant inconvenience for those readers who are interested in simplified Chinese writing and not in traditional Chinese writing. Simplified Chinese is currently the prevalent form in the mainland China as per W:Simplified Chinese characters. Having definitions in both simplified and traditional Chinese entries, as has been English Wiktionary practice for many years, creates duplication of definitions, which I admit to be a disadvantage for maintenance; it is a cost of making the dictionary easy to use for the readers. Those editors who want to focus e.g. only on traditional Chinese entries should be allowed to do so, without being chastised for not creating simplified Chinese entries at the same time. As an example of similar practice, we now have definitions in both Latin and Cyrillic Serbo-Croatian entries, which is a duplication (mačka, мачка). As a further inconvenience of soft-redirects as envisioned at Wiktionary:Beer_parlour/2014/December#New_changes_to_Chinese_entries in paragraph "The problem is not about having or not wanting to create ...", usage examples would newly feature both simplified and traditional Chinese (probably along with Pinyin), becoming even more busy with information that the reader is not interested in: the reader with the interest in simplified Chinese does not necessarily want to see traditional Chinese. --Dan Polansky (talk) 10:12, 26 December 2014 (UTC)
    Don't forget Malay entry versions in both Jawi and Rumi. (I'm not voting, though; but if I were forced to do so, I could abstain, right?) --Lo Ximiendo (talk) 10:26, 26 December 2014 (UTC)
    On the other hand, all those simplified Chinese edits are clogging up the Short pages. --Lo Ximiendo (talk) 17:20, 8 January 2015 (UTC)
    (Oppose vote retracted due to not having enough contributions here for it to be valid. I use Wiktionary very often, but apparently I don’t contribute enough…) A redirect, whether soft or hard, from simplified to traditional or vice versa, looks like an implicit claim that one of the two is more correct than the other. This happens regardless of whether making that claim is intentional or not. Since it is not the case that either of the two types of character is more correct than the other, it seems clear to me that redirecting from one to the other is a bad idea. In addition, as stated above, a soft redirect like this (as opposed to a hard redirect) causes significant inconvenience to anyone who commonly looks up words in simplified Chinese. The analogy to Latin vs. Cyrillic Serbo‐Croatian entries is an excellent point too. With regard to the point about maintaining separate entries being too much work, I have an alternative suggestion which, if properly thought through and implemented, could have the same effect of reducing the workload without the major disadvantages of a redirect: For the information that would otherwise be duplicated (which in some cases is an entire entry, in other cases only part of an entry), move that information to a template that is transcluded onto the pages that would otherwise duplicate that information. That way the relevant information is visible everywhere it should be, and only needs maintaining from one location. MTC (talk) 09:06, 2 January 2015 (UTC)
    I am afraid your vote is invalid per policy: not enough edits in content namespaces. — Keφr 18:43, 12 January 2015 (UTC)
    Ah, that’s a shame. In that case, I have re‐indented it so that the comment is still there while the votes are counted correctly. MTC (talk) 13:40, 13 January 2015 (UTC)
  2. Symbol oppose vote.svg Oppose as far as I know there is no one-to-one correspondence between simplified and traditional Chinese, i. e. one simplified term may map to multiple traditional terms. This makes the proposal infeasible because readers won't be able to guess the correct form if they're unfamiliar with traditional Chinese, as residents of the PRC and Singapore tend to be. -- Liliana • 12:36, 4 January 2015 (UTC)
  3. Symbol oppose vote.svg Oppose Since simplified is use far more often than traditional I believe that people using Wiktionary will find it odd and backward with redirects to traditional Chinese. The argument is that it is easier for people writing templates to use the traditional form as lemma but how much extra work is it really to do it with simplified as lemma? Kinamand (talk) 09:22, 8 January 2015 (UTC)
  4. Symbol oppose vote.svg Oppose, though not strongly. Each should have its own entry explaining the characteristics unique to it. bd2412 T 16:54, 8 January 2015 (UTC)
  5. Symbol oppose vote.svg Oppose (strongly) When a page is correct and helpful to readers, its contents should never be removed, even to avoid replication. This should be a strong principle of the project. One of the reasons is that most readers want to find what they look for immediately (statistics show that each additional click needed makes the probability of a donation to the Foundation 30% less). Another reason is neutrality: as both writing styles are used, they must be addressed the same way. A third reason is that it would tend to discourage editors preferring simplified characters, and fewer editors is something bad for the project. Soft redirects might be used as a first step, but it must be allowed to convert these soft redirects to full pages. @CodeCat: an alternative idea that would reduce the workload of managing Chinese entries: allow editors to contribute to the pages they wish. This way, there will be more editors, making it easier to make the project more complete. Anyway, strictly speaking, there is no workload, everybody contributes as much as they wish, not more, and we are not in a hurry. Lmaltier (talk) 22:40, 10 January 2015 (UTC) I see Splitting 后 into 後 and 后 will be a relative minor hurdle for users.. But priority must be given to users, not to editors. Slowly but surely, this dictionary could become the perfect dictionary for users. Lmaltier (talk) 19:20, 13 January 2015 (UTC)
    We could compare this issue to two other ones: 1. the typographic issue of s/long s, ct grouped as a single character in ols books, or capitalized words (where/Where), where we create a single entry, and this is quite normal. 2. the existence of several scripts for the same language (e.g. Serbian), where we create one entry by script, and this is quite normal. I feel that the simplied Chinese is felt as a different ideographic script, just like Cyrillic is a different alphabetic script, and this is confirmed by the absence of a general one-to-one correspondence with the traditional Chinese script. This should be sufficient for creating both complete entries. I'm afraid that some editors want to promote one of the scripts. Lmaltier (talk) 06:56, 9 February 2015 (UTC)
    Symbol oppose vote.svg Oppose Although simplified Chinese is widely used, I don't think traditional Chinese should be redirected to it unconditionally, and the opposite direction of redirection is a little confusing. "Who-redirect-to-who" problem is always a controversial issue, and I think that it can be determined by who create the entry first. If it is created with the title in traditional Chinese, the later simplified Chinese version should redirect to the former entry (if the meaning of the word is same), and vice versa.--Snowkylin (talk) 14:34, 16 January 2015 (UTC)
    Unfortunately, your vote is invalid per the first two points of our voting policy. See at the top of WT:VOTE. --Vahag (talk) 14:52, 16 January 2015 (UTC)
    Oh, I just find that minutes ago, my fault. Edit count is not universal, what a pity :-( --Snowkylin (talk) 14:58, 16 January 2015 (UTC)
    You can't vote in China, you can't vote in Wiktionary. Poor disenfranchised fellow :-( --Vahag (talk) 15:10, 16 January 2015 (UTC)
    The opinion that citizen in China can't vote is quite incorrect, just like the opinion that users in English Wiktionary can vote. I do not know much about English Wiktionary, and maybe you do not know much about China either, seems that it's a tie game. :-)--Snowkylin (talk) 08:53, 17 January 2015 (UTC)
    I hear you, man. I too was born in a communist country. Western liberal media misrepresents our vibrant democracies. --Vahag (talk) 09:29, 17 January 2015 (UTC)
    Symbol oppose vote.svg Oppose, the same as above. --LNDDYL (talk) 06:44, 17 January 2015 (UTC)
    I'm afraid your vote doesn't count per voting policy #2 (you need at least 50 edits by the start time of the vote). --Vahag (talk) 09:29, 17 January 2015 (UTC)
  6. Oppose. — Keφr 10:41, 18 January 2015 (UTC)
    @Kephir: Could you explain your reasons, please? As a programmer, how would make (a rather trivial - single etymology, no variant pronunciations) entry 笔#Chinese to have the same information as 筆#Chinese without duplicating the contents? --Anatoli T. (обсудить/вклад) 03:56, 19 January 2015 (UTC)
    I would duplicate the contents. I simply find this preferable to the alternative. Despite all reassurances to the contrary, this obviously will create a preference for one orthography over the other. In itself, it might not necessarily be a problem. But given that (as I am told) there is no one-to-one correspondence between the two, this will necessitate creating some kind of disambiguation cluttering up entries, which are cluttered enough already. Chinese entries are already very confusing to read with all their nonstandard L3s and content splits between Translingual, Chinese and topolect L2, and I believe this proposal will only add more to the confusion for little benefit. And never call me a programmer. — Keφr 12:00, 19 January 2015 (UTC)
    I'm sorry if "programmer" was an offence to you. It wasn't meant to be. --Anatoli T. (обсудить/вклад) 13:19, 19 January 2015 (UTC)
    Symbol oppose vote.svg Oppose Amphineko (talk) 12:10, 31 January 2015 (UTC)
    Your vote is invalid per the first two points of our voting policy. See at the top of WT:VOTE. --Vahag (talk) 12:50, 31 January 2015 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain Byfserag (talk) 22:18, 18 January 2015 (UTC)
    You are not eligible to vote anyway. You might as well not bothered. — Keφr 12:01, 19 January 2015 (UTC)
    Your vote has been struck out as invalid as you have not yet made a single contribution to this wiki. Jamesjiao → T ◊ C 22:49, 19 January 2015 (UTC)
  2. Symbol abstain vote.svg Abstain until there is solution for some problems of this action. Firstly, characters who are both simplified and traditional need to have another format. Secondly, characters who are neither simplified nor traditional, but a varients of another character instead, would have to be considered also. Thirdly, some Japanese kanji actually use the simplified form of a character, making the derived terms section troubling. Fourthly, one simplified character may correspond to two traiditional character, and a short definitional would be required for them to be distinguishable. Including definition would make the entry almost same as before. --kc_kennylau (talk) 07:35, 21 January 2015 (UTC)

Decision

Passes: 11:6:02 (support:oppose:abstain). --Ivan Štambuk (talk) 19:23, 7 February 2015 (UTC)

Trimming CFI for Wiktionary is not an encyclopedia

Support

  1. Symbol support vote.svg Support The sentence suggests we only include place names if they happen to be given names or surnames, which is untrue. The best evidence of broad support for broad inclusion of place names that I know of is Wiktionary:Votes/pl-2010-05/Placenames with linguistic information 2. --Dan Polansky (talk) 09:27, 8 February 2015 (UTC)
  2. Symbol support vote.svg Support. "Many places [...] are known by single word names that qualify for inclusion as given names or family names." Er, what? (Alternatively, "[...] some people, are known by single word names that qualify for inclusion as given names or family names" makes sense, but what are placenames doing at the start of the line?) I guess this was an inept reference to the fact that Winston Churchill is often called simply 'Churchill', Hillary Clinton is often called simply 'Hillary', etc, but I have no idea why placenames got shoehorned into the mix. The line could be revised as suggested on the talk page, but then it would still be vacuous. - -sche (discuss) 18:35, 1 March 2015 (UTC)

Oppose

Abstain

  1. Symbol abstain vote.svg Abstain It's not obvious what the author of this sentence was trying to say; its intended meaning, and the reason why it was included in the policy, seem to have got lost in the mists of time. Having said that, I think it would be more useful to replace this sentence with a comment on the includability (or otherwise) of the place and person names in question. This, that and the other (talk) 08:23, 1 March 2015 (UTC)
    Thank you for your vote. FYI, the sentence was added by Uncle G (talk • contribs) on 22 May 2005 in diff, so he would know what he intended by the sentence and what discussion, if any, preceded his edit to CFI. Furthermore, includability of places and people is driven by WT:CFI#Names of specific entities, which is a section of CFI fully created via votes: Wiktionary:Votes/pl-2010-05/Names_of_specific_entities, Wiktionary:Votes/pl-2010-05/Placenames with linguistic information 2, Wiktionary:Votes/pl-2011-02/Remove "Place names" section of WT:CFI, Wiktionary:Votes/pl-2010-12/Names_of_individuals. As you can see from the linked votes, there was a specific regulation for place names until the editors decided that that was unnecessary or unwanted; this revision of CFI is one where you can see a section for place names before it was removed. --Dan Polansky (talk) 10:13, 1 March 2015 (UTC)

Decision

Allowing well-attested romanizations of Sanskrit

  • Voting on: That whenever citations can be provided showing that a romanization of a Sanskrit word is well-attested in a string of transliterated Sanskrit text (used to convey meaning in permanently recorded media in at least three independent instances, spanning at least three years; see, e.g. [1], [2]), we allow an entry for that romanization consisting of the modicum of information needed to allow readers to get to the native-script entry.
  • Rationale: This differs from the previous vote, which would have allowed romanizations of all attested Sanskrit words, irrespective of whether the romanizations themselves were attested. This, by contrast, will apply only to those words for which attestation is demonstrated prior to the creation of an entry for the word. This will allow definitions to be created for words (or things that a reader would reasonably expect to be words) that an English-speaking reader might reasonably be expected to encounter while reading English-language materials containing strings of romanized Sanskrit text, while preventing the creation of definitions for unattested romanizations.
  • Vote starts: 00:01, 5 February 2015 (UTC)
  • Vote ends: 23:59, 5 March 2015 (UTC)

Support

  1. Symbol support vote.svg Support as nom. bd2412 T 20:39, 4 February 2015 (UTC)
  2. Symbol support vote.svg Support (conditionally) Bowing to pressure and evidence provided that Sanskrit romanisation is used. My condition: only IAST romanisation and only as soft redirects to Devanagari entries, all entry info (definitions, pronunciations, synonyms, example sentences, etc.) should be in the Devanagari entries, just like Mandarin pinyin and Japanese rōmaji entries. --Anatoli T. (обсудить/вклад) 22:02, 4 February 2015 (UTC)
    • I am fine with everything you have said. bd2412 T 22:12, 4 February 2015 (UTC)
      • OK. I want to stress that it should be standard IAST, e.g. "ṃ", not "ṁ" for anusvāra and one transliteration per entry with possible hard redirects. Details to be worked out, including the use of hyphens (for etymological word splits) and stress marks (only for pronunciation in Devanagari entries, which should not be in IAST entries). I don't see dedicated editors to create and check IAST entries, though. --Anatoli T. (обсудить/вклад) 23:36, 4 February 2015 (UTC)
        • I consider words with different accents to be different words. I wonder how likely we are to find three independent citations in running strings of transliterated Sanskrit text using the wrong diacritics. That said, I have no objection at all to an IAST limitation. bd2412 T 03:18, 5 February 2015 (UTC)
  3. Symbol support vote.svg Support Other than for the "modicum" part, this is our current CFI (WT:CFI#Attestation) as I understand it. I see no added value for the user of the dictionary in disallowing attestation of transliterations beyond the current CFI.

    I am slightly confused by the following: "This, by contrast, will apply only to those words for which attestation is demonstrated prior to the creation of an entry for the word." I do not support that attesting quotations must be in the entry before the entry is created; attestation of transliterated text should work the same way as attestation of native-script text.

    On yet another note, this vote proposes to explicitly allow modicum entries; I do not see the vote anywhere disallowing non-modicum entries. I surmise it to be the current CFI to allow even fuller entries than modicum ones, for attested transliterations. --Dan Polansky (talk) 16:37, 15 February 2015 (UTC)

  4. Symbol support vote.svg Support having Rōmaji-style entries for all attested transliterations of Sanskrit. (@Atitarev: How about tagging non-IAST transliterations {{lb|sa|nonstandard}}?) — I.S.M.E.T.A. 18:28, 19 February 2015 (UTC)
    If we decide to start allowing entries for romanizations, then it will make sense to tag the nonstandard ones, yes — but probably with a dedicated tag like {{lb|sa|nonstandard romanization}} (which could display "nonstandard") or better yet a dedicated template like {{nonstandard romanization of}}, so that the entries can be categorized differently from terms that are nonstandard in the 'usual' way. Templates would presumably also be needed for e.g. Hunterian transliterations and other non-IAST standards. - -sche (discuss) 21:06, 19 February 2015 (UTC)
    @-sche: That seems sensible. I'd support such a practice. — I.S.M.E.T.A. 21:10, 19 February 2015 (UTC)
  5. Symbol support vote.svg Support As these transliterated forms are attested, it's not so much a question of whether they should be included, but how, and that shouldn't come into consideration for this vote. None of the objections so far have said anything except to defer to previous votes. Previous objections were that there might be development of "reverse transliteration modules" to aid search -- this is irrelevant for this vote, as it ignores the change in this poll, namely that is only for attested forms. It also assumes future technology, when in reality Wiktionary code development is particularly slow (e.g. you still can't even search by language). Another previous objection was that there would be an explosion of entries with transliterations for Sanskrit in multiple scripts: "Sanskrit is written in a hell of a lot of scripts". Again this is rendered irrelevant by the requirement for attestation. Another objection was against bot-generated transliterations. Again, not relevant. So, the objectors who are simply deferring to previous votes really need to expand their arguments. I've only gone through Wiktionary:Votes/pl-2014-06/Romanization_of_Sanskrit, but none of the objections made there appear to be relevant for this vote, so please point to specific arguments if you object. Pengo (talk) 23:12, 19 February 2015 (UTC)
    Are you sure you've read the talkpages? --Ivan Štambuk (talk) 22:04, 20 February 2015 (UTC)
    Seriously? I've gone to the effort of going through one page of voting and found nothing relevant there. If you want to point out specific arguments, you're going to have to meet me half way. Pengo (talk) 15:46, 21 February 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose per the previous vote. Wyang (talk) 07:50, 6 February 2015 (UTC)
  2. Symbol oppose vote.svg Oppose per Wyang. --Vahag (talk) 09:52, 6 February 2015 (UTC)
  3. Symbol oppose vote.svg Oppose per Vahag. --Ivan Štambuk (talk) 20:37, 6 February 2015 (UTC)
  4. Symbol oppose vote.svg Oppose --Dijan (talk) 07:29, 13 February 2015 (UTC)
  5. Symbol oppose vote.svg Oppose — Ungoliant (falai) 16:34, 15 February 2015 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain I like this idea from the perspective of users who are trying to find a romanized Sanskrit word found in either a religious text or dictionary but who are not familiar with or are incapable of typing in Devanagiri. On the other hand, even the IAST cannot be easily typed into a search bar, which defeats the purpose of that argument. —JohnC5 21:32, 19 February 2015 (UTC)
    You type maha, and at the top, on the "See also:" row, you'll find mahā. So ease of typing should not be an issue for a person who can type Latin letters used in English. (Works for Czech as well; if a person can only type kocka, they can click kočka at the top of the entry.) --Dan Polansky (talk) 21:39, 19 February 2015 (UTC)
    That only works though if the page without diacritics already exists and has a See also, neither of which is always the case. Regardless I can understand both arguments quite well and cannot make up my mind. —JohnC5 23:12, 19 February 2015 (UTC)
    Even assuming the diacritic-free pages will not eventually exist, learning to enter these diacritics is much easier than to enter a script with which one is entirely unfamiliar. And the search for the non-existing diacritic-free page would presumably turn up the page with diacritics near the top of the search results. Or even, when I enter "tuzka" into the search box and press "Go", Wiktionary takes me to "tužka"; similary for "muska" and "muška". --Dan Polansky (talk) 16:35, 20 February 2015 (UTC)
    Fair enough. I still feel too strongly in both directions to choose. Thanks for the clarification, though. —JohnC5 21:08, 20 February 2015 (UTC)

Decision

Templatizing topical categories in the mainspace

  • Voting on: Templatizing the markup for topical categories in the mainspace. Thus, giving a full go ahead to all automatic and semiautomatic edits that replace the likes of "[[Category:nl:Mammals]]" with "{{catlangcode|nl|Mammals}}" or similar.
  • Rationale: See Wiktionary talk:Votes/2015-03/Templatizing topical categories in the mainspace#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote started: 00:00, 8 March 2015 (UTC)
  • Vote ends: 23:59, 6 April 2015 (UTC)
Ambox warning yellow.svg

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.

Support

Oppose

Abstain

Decision

Recently ended votes

Votes that have recently ended, to be ultimately moved to /Timeline:

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:

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