Wiktionary:Votes

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

Wiktionary > Votes

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.

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

Current and new votes

Templatizing topical categories in the mainspace

Support

  1. Symbol support vote.svg Support --Daniel 01:56, 22 April 2015 (UTC)
  2. Symbol support vote.svg Support Languages with different sort ordering from default will greatly benefit. Already used in Module:zh-cat, which sorts by radicals, rather than characters themselves. Japanese would be greatly simplified (there would be no need to pass hiragana spelling for each category, if implemented (requires work but the logic is already used in other Japanese modules). Besides, it's simpler - multiple categories can be added as parameters in one template. --Anatoli T. (обсудить/вклад) 02:59, 22 April 2015 (UTC)
    How many languages are there of such kind?--Dixtosa (talk) 15:48, 5 May 2015 (UTC)
    I don't know how many apart from Chinese and Japanese (Korean hangeul entries used to have them but it's no longer necessary) but you can try checking how often |sort= is used in the {{context}}/{{cx}} or what is used by {{DEFAULTSORT}}. Korean and Vietnamese entries in hanja and Hán tự also use some logic to sort by the modern scripts. Sorting order for many languages could be improved with a module. E.g., I'm annoyed to see Russian letter Ё appearing before any other letter in categories when it should be between letters Е and Ж. It also effects other Cyrillic letters in other languages. You have much more control over categories and their behaviour when you have a program than when you just use square brackets - [[Category:Blah]].--Anatoli T. (обсудить/вклад) 03:38, 6 May 2015 (UTC)
    @Anatoli T.: Is the sorting order for Russian for "ё" okay at Category:Russian lemmas, from letter Е? If so, is this because the category is created by templates and modules that contain dedicated code to support this? --Dan Polansky (talk) 06:58, 16 May 2015 (UTC)
    @Dan Polansky: Yes, it seems OK there but if you look at the very first page of the category, words starting with the archaic Cyrillic letter "і" still come first (probably this hasn't been addressed yet). In Category:Russian_adjectives words starting with the Cyrillic letter "ё" (BTW, the first two of them are vulgar, which is annoying) come before other letters. There are other examples I've come across before in other languages as well. Yes, I think some modules/templates help the sorting order but I don't know the details.
    A categories module would make sure that languages are sorted as they should be - alphabetically, as the order may differ for Roman-based languages as well, e.g. Czech letter ch should come after h, shouldn't it? But Czech lemmas are sorted by letter c, AFAIK. --Anatoli T. (обсудить/вклад) 07:12, 16 May 2015 (UTC)
    @Anatoli T.: Czech sorting in Czech categories is kind of broken (non-conventional), as you say. Should not the sorting order be first fixed in a category generated by templates (Category:Russian_adjectives) before the sorting order is used as a selling point? What I would actually prefer is that each category is assigned the sorting order on the Mediawiki software level, regardless of the means by which the items are added to the category (direct markup, template, etc.). Are you sure there is no extension or software in Mediawiki that supports that? --Dan Polansky (talk) 07:19, 16 May 2015 (UTC)
    I'm not selling it, just voting with my reasons. Yes, PoS categories need to be fixed as well. I don't know what Mediawiki can offer but I remember we had issues with Arabic diacritics display order before Benwing has created a module to address this - after many complaints about how MediaWiki does it. Editors will have more control over things, not just sorting order, when the code is here, at Wiktionary. I don't see why not either. Apart from HotCat, I don't see other reasons to oppose and HotCat can be taught to work with the module, I'm sure. I've seen the benefits of Module:zh-cat -> {{zh-cat}} and the sorting order was changed quickly for Chinese entries when a decision was made. --Anatoli T. (обсудить/вклад) 07:37, 16 May 2015 (UTC)
    My reason for opposing would be, don't complicate or templatize anything unless there is a tangible (not hypothetical) benefit in doing so; but I guess I am myself guilty of excessive complicating or templatizing. The template name {{catlangcode}} is pretty bad too, but that could be changed to {{cat}} or {{topiccat}}; the template is only intended for topical categories, from what I understand. --Dan Polansky (talk) 08:19, 16 May 2015 (UTC)
    I'd say opposition to templates is a weak reason. Templates are supposed to help, not to complicate. The idea is already implemented with Chinese topical categories with tangible benefits, so it's not entirely hypothetical. Compare old [[Category:zh-tw:Beginning Mandarin|止12歷史]] (an editor needed to know the character radicals and stroke counts to add to categories) with the new {{zh-cat|Beginning}}. I have given examples of what could be done with Japanese entries, which also have a complicated sorting order. Agreed about the length of the template name but the vote says ... "{{catlangcode|nl|Mammals}}" or similar. I prefer {{cat}}. --Anatoli T. (обсудить/вклад) 09:18, 16 May 2015 (UTC)
    Templates increase the learning curve for newcomers; that is why they should only be introduced when the tangible benefit exceeds this downside. You are right: the vote does not require that the template name is specifically {{catlangcode}}. --Dan Polansky (talk) 09:39, 16 May 2015 (UTC)
    {{cat|en|People}} is not more complicated than [[Category:en:People]], besides, curly brackets and pipes are a second nature at Wiktionary, newcomers learn this fast. --Anatoli T. (обсудить/вклад) 10:52, 16 May 2015 (UTC)
    FYI, Daniel Carrero pointed out there is {{topics}}, at Wiktionary talk:Votes/2015-03/Templatizing topical categories in the mainspace#catlangcode. --Dan Polansky (talk) 13:46, 16 May 2015 (UTC)
  3. Symbol support vote.svg Support if and only if the template be called {{C}} instead of {{catlangcode}}. — I.S.M.E.T.A. 20:15, 20 May 2015 (UTC)
    The dating template currently coded at {{C}} should be deleted. — I.S.M.E.T.A. 20:17, 20 May 2015 (UTC)
    {{C}} is now a redirect to {{catlangcode}} (the dating template has been moved to {{C.}}). — I.S.M.E.T.A. 01:26, 27 May 2015 (UTC)
  4. Symbol support vote.svg Support —Stephen (Talk) 23:36, 26 May 2015 (UTC)
  5. Symbol support vote.svg Support. — Ungoliant (falai) 15:20, 11 June 2015 (UTC)

Oppose

Symbol oppose vote.svg Oppose unless and until CodeCat gives a rationale for the change. This, that and the other (talk) 13:32, 16 April 2015 (UTC)
Now neutral, per Anatoli's justification. I'd like a better name than "catlangcode" though. What a waste of valuable letters and precious keystrokes! This, that and the other (talk) 10:02, 5 May 2015 (UTC)
I agree about the name "catlangcode". --Daniel 15:11, 5 May 2015 (UTC)
  1. Symbol oppose vote.svg Oppose Equinox 01:59, 22 April 2015 (UTC)
  2. Symbol oppose vote.svg Oppose HotCat will be affected --Dixtosa (talk) 15:48, 5 May 2015 (UTC)
    This could be addressed, I'm sure and made better. --Anatoli T. (обсудить/вклад) 03:38, 6 May 2015 (UTC)
  3. Symbol oppose vote.svg Oppose in general but support for languages that need it. Not all languages have a different sort order from default and it would mess up HotCat for the ones that don't. —Internoob 19:43, 11 May 2015 (UTC)
    @CodeCat Will the templatising of categories really mess with HotCat? Do you wish to address this or tell us your thoughts because this seems to be a concern. --Anatoli T. (обсудить/вклад) 07:16, 16 May 2015 (UTC)
  4. Symbol oppose vote.svg Oppose. CatScan doesn't work for templatized categories. (Sort order can also be handled by pipes.)​—msh210 (talk) 03:59, 17 June 2015 (UTC)

Abstain

Comments

  • I went to ruwiki being sure they have done something about it, and I was right. See this to see how Russian wikiprojects addressed this problem. So, now they sort like this

АБВГДЕ
Ё
ЖЗИЙКЛМНОПРСТУФХЦЧШЩЬЫЪЭЮЯабвгде
ё
жзийклмнопрстуфхцчшщьыъэюя

We can request the same for all languages.--Dixtosa (talk) 12:06, 16 May 2015 (UTC)

@Dixtosa Any improvement is welcome, of course. I'm not sure how the above affects topical and other categories but we'll have much more control if we have language-specific sorting logic. I mentioned {{DEFAULTSORT}}. This is needed for certain abugida-based languages. See the end of this discussion. It's quite important that Thai, Lao, etc. are sorted by proper initial consonants, not by "preposed" vowels. E.g. แข็ง (kăeng, hard, strong, solid) (note that it's spelled as "ăe + k + ng", certain vowels are written in front of syllables, they are preposed). It should be sorted by "ข็แง" (i.e. teh way it's read out: "k + ăe + ng") in entries {{DEFAULTSORT|ข็แง}}, the way people look up Thai words in dictionaries, in this case by consonant (k), not by the vowel (ae), even though it's physically written before the consonant. --Anatoli T. (обсудить/вклад) 07:50, 28 June 2015 (UTC)

Decision


User:Alhen for de-sysop

5 edits since 2010. User:Alhen is the userpage

  • Vote starts: 17 June 2015
  • Vote ends: 1 July 2015

Support removing sysop rights

  1. Symbol support vote.svg Support as nom. --Type56op9 (talk) 20:43, 17 June 2015 (UTC)
  2. Symbol support vote.svg Support for long-term inactivity. I see 9 edits since 2007. The magic keyword {{NUMBEROFADMINS}} gives 101 admins. There is no risk that removing admin rights creates unhealthy concentration of power. --Dan Polansky (talk) 18:15, 19 June 2015 (UTC)
  3. Symbol support vote.svg Support —Stephen (Talk) 06:02, 3 July 2015 (UTC)

Oppose removing sysop rights

  1. Symbol oppose vote.svg Oppose Nom states no grounds for desysopping. -- Visviva (talk) 04:26, 18 June 2015 (UTC)

Abstain removing sysop rights

Decision


User:GerardM for de-sysop

User inactive since 2013. User:GerardM is the userpage

  • Vote starts: 17 June 2015
  • Vote ends: 1 July 2015

Support removing sysop rights

  1. Symbol support vote.svg Support as nom. --Type56op9 (talk) 20:41, 17 June 2015 (UTC)

Oppose removing sysop rights

  1. Symbol oppose vote.svg Oppose Nom states no grounds for desysopping. -- Visviva (talk) 04:27, 18 June 2015 (UTC)

Abstain removing sysop rights

  1. Symbol abstain vote.svg Abstain I see 13 edits since 2010. The magic keyword {{NUMBEROFADMINS}} gives 101 admins. There is no risk that removing admin rights creates unhealthy concentration of power. --Dan Polansky (talk) 18:24, 19 June 2015 (UTC)

Decision


User:Rodasmith for de-sysop

User inactive since 2013. User:Rodasmith is the userpage

  • Vote starts: 17 June 2015
  • Vote ends: 1 July 2015

Support removing sysop rights

  1. Symbol support vote.svg Support as nom. --Type56op9 (talk) 20:42, 17 June 2015 (UTC)

Oppose removing sysop rights

  1. Symbol oppose vote.svg Oppose Nom states no grounds for desysopping. -- Visviva (talk) 04:27, 18 June 2015 (UTC)

Abstain removing sysop rights

  1. Symbol abstain vote.svg Abstain I see 8 edits since 2011. The magic keyword {{NUMBEROFADMINS}} gives 101 admins. There is no risk that removing admin rights creates unhealthy concentration of power. --Dan Polansky (talk) 18:26, 19 June 2015 (UTC)

Decision


Revise nominating criteria for whitelist

  • Voting on: Replacing the language of Wiktionary:Whitelist, specificially regarding procedures point 1 and 2 (text being changed is in bold).
    • Procedure 1 currently reads: "One sysop nominates a name for auto-whitelisting."
    • Procedure 1 would read: "Any auto-confirmed user may nominate a name for auto-whitelisting."
    • Procedure 2 currently reads: "A second sysop approves the nomination."
    • Procedure 2 would read: "A sysop approves the nomination."

This proposal still requires the approval of a sysop to receive whitelist rights, and will continue to allow sysops to defer whitelist rights. However, it would allow non-admins to nominate themselves or other non-admins for the rights.

Rationale: At present, nominations for the whitelist are supposed to be only done by administrators. That seems:

  1. excessive (why should we need so many hoops to jump through with whitelist? It's harder to be whitelisted here than many other projects; to say nothing of the fact that many projects don't even bother with whitelisting)
  2. unfair (it grants too much power to sysops and not enough power to Joe users), and
  3. time-consuming (it'd be so much easier for people to self-nom).


  • Vote started: 00:00, 26 May 2015 (UTC)
  • Vote ends: 23:59, 24 June 2015 (UTC)

Support

  1. Symbol support vote.svg Support as nom Purplebackpack89 01:18, 26 May 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose as this is something that only affects patrollers (which on this wiki, is essentially equivalent to sysops) and has absolutely no bearing on the editor in question. Some sysops will approve just about any nomination, so the current system ensures that some other sysop has looked at the user in question first. —Μετάknowledgediscuss/deeds 04:50, 26 May 2015 (UTC)
  2. Symbol oppose vote.svg Oppose per Metaknowledge. —Stephen (Talk) 14:00, 26 May 2015 (UTC)
  3. Symbol oppose vote.svg Oppose. The only people who would benefit from this are hat collectors. — Ungoliant (falai) 16:27, 26 May 2015 (UTC)
  4. Symbol oppose vote.svg Oppose per Metaknowledge and Ungoliant. And notice I'm not a sysop. --Makaokalani (talk) 08:58, 30 May 2015 (UTC)

Abstain

Decision


Normalization of entries

  • Voting on:
    • Promoting the revision 32887410 of Wiktionary:Normalization of entries (WT:NORM) to a policy, the same as WT:CFI and WT:ELE. Its purpose is described as follows, quoted from the page:
      "This is a list of aspects of formatting which usually make no or little difference to how a user sees the page, but does make the pages conform more to a standard format reflecting what we think of as best when editing a page. Issues such as where to put blank lines and how many, whether to put spaces inside the == ==, or after asterisks in lists."
    • Adding to the page the same policy box from CFI and ELE, whose policy status reads specifically as follows.
      "This is a Wiktionary policy, guideline or common practices page.
      It should not be modified without discussion and consensus. Any substantial or contested changes require a VOTE."
  • Vote started: 00:00, 4 June 2015 (UTC)
  • Vote ends: 23:59, 3 July 2015 (UTC)
  • Vote ends: 23:59, 17 July 2015 (UTC)

Support

  1. Symbol support vote.svg Support --Daniel 11:31, 4 June 2015 (UTC)
  2. Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 03:17, 5 June 2015 (UTC)
  3. Symbol support vote.svg Support Renard Migrant (talk) 11:18, 7 June 2015 (UTC)
  4. Symbol support vote.svg Support, with the understanding that the line “Each category and interwiki on its own line” will not affect how {{catlangcode}} and {{catlangname}} are used. — Ungoliant (falai) 15:14, 10 June 2015 (UTC)
  5. Symbol support vote.svg Support Haplogy () 01:57, 14 June 2015 (UTC)
  6. Symbol support vote.svg Support Matthias Buchmeier (talk) 20:23, 17 June 2015 (UTC)
  7. Symbol support vote.svg weak support It's nice to have a set of guidelines. That said, (1) some of these are faulty as described below, (2) few of these really seem important to enforce, even among bots—and the ones that are probably belong in ELE proper. —ObsequiousNewt (εἴρηκα|πεποίηκα) 01:23, 4 July 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose — 1) {{acronym-old}} has been deleted; reference to it should be removed from WT:NORM#Headings 5. 2) WT:NORM#Headings 7 reads “---- before each language heading heading except the first.”; one of the words heading should be removed for grammaticality. 3) I disagree with WT:NORM#POS sections; headword lines; senses/definitions 1.1; beyond that, I would prefer that {{wikipedia}} were banned in favour of {{pedia}} occurring in External links sections. 4) Re WT:NORM#POS sections; headword lines; senses/definitions 3, POS sections should be permitted to contain multiple headword lines, at least until numbered Pronunciation sections are permitted without having to use code like {{rfc-pron-n|Pronunciation 1|lang=la}}. 5) Re WT:NORM#Translation sections 1, Neapolitan has grammatical gender; accordingly, the example text should read Neapolitan: {{t|nap|acqua|f}}. 6) Unless Ungoliant MMDCCLXIV is right in his interpretation of it (see the Support section, in his post timestamped: 15:14, 10 June 2015), WT:NORM#Categories and interwikis 3 destroys the potential of {{C}} and should, therefore, not be enacted. 7) I have seen an interwiki link on a Hebrew-script page (without niqqud) link to a page on another Wiktionary for a Hebrew-script page of the same spelling, except that it had niqqud; there would be no such beneficial linking if WT:NORM#Categories and interwikis 7 were enacted. 8) Re WT:NORM#Others/Technical, whilst templates are preferable to wikitables, and wikitables are preferable to HTML tables, none of them should be banned. 9) I'm sorry that I did not raise my objections in the Beer Parlour before this vote began. — I.S.M.E.T.A. 02:17, 13 June 2015 (UTC)
    Re niqqud: I'm sure one of more bots has removed the nonstandard interwiki link from whatever page you saw. Links between non-identical pages are handled by redirects (see e.g. Takasugi's outline of how en.Wikt and fr.Wikt link between their differently-apostrophed entries). - -sche (discuss) 02:26, 13 June 2015 (UTC)
    @-sche: That wouldn't work in this case, because we don't have entries for Hebrew terms written with niqqud (if the other Wiktionary had redirects from niqqud-free spellings to those with niqqud, then they'd have an interwiki to our page, but we wouldn't have one to their page). — I.S.M.E.T.A. 02:32, 13 June 2015 (UTC)
    It would work exactly the way the linking between fr.Wikt and en.Wikt works: each side has an entry at its desired pagetitle, and a redirect to there from the other site's desired pagetitle, and all of the pages (including the redirects) host interwiki links to their identical counterparts on other wikis. In any event, interwiki links have been required to be between exactly identical pagetitles for longer than I've been an editor here (see e.g. WT:Links#Interwiki_links), and interwiki-bots to my knowledge uniformly enforce this, so codifying or declining to codify this practice in an additional place, viz. WT:NORM, won't make a difference. - -sche (discuss) 02:43, 13 June 2015 (UTC)
    @-sche: But we don't have a redirect from the other site's desired pagetitle. — I.S.M.E.T.A. 12:01, 13 June 2015 (UTC)
    And we're constitutionally incapable of creating new pages. No one here knows how! If you figure out how, can you let us know? (PS, we even have an edit filter that warns people against adding interwikis to non-matching pages.) - -sche (discuss) 00:04, 14 June 2015 (UTC)
    @-sche: What's the policy on redirecting spellings with niqqud to those without? Are they considered good or bad redirects? — I.S.M.E.T.A. 00:10, 14 June 2015 (UTC)
    Sorry for the snarkiness of my previous comment.
    If other wikis lemmatize niqqud spellings, having redirects from those spelling to the spellings we lemmatize would seem to be a (informal) requirement for us, as with the curly vs straight apostrophes. But I don't see anything on the subject in WT:AHE or [[WT:T:AHE (although the variableness of niqqud’s spelling makes it hard to search WT:T:AHE) so it's possible that the fact that other wikis lemmatize niqqud spellings and that this affects interwiki linking hasn't occurred to Hebrew editors, so one could raise the issue on WT:T:AHE before creating such redirects. One of our main Hebrew editors is also the operator of one of our main interwiki bots (Ruakh).
    - -sche (discuss) 01:42, 14 June 2015 (UTC)
    @-sche: Re snarkiness, no worries. Thanks for the helpful response. I've raised this issue at Wiktionary talk:About Hebrew#Redirects from spellings with niqqud to those without. — I.S.M.E.T.A. 16:15, 14 June 2015 (UTC)
    Symbol oppose vote.svg Oppose I have no problem with normalization of the sort proposed (and, perhaps modulo some details of the sort mentioned in ISMETA's vote in opposition, no problem even with the specific normalizations proposed). But I oppose the imposition of such a page as policy unless it clearly indicates that it is meant as an objective for entries, as best practice for humans, and perhaps as a requirement for bots — but not as a requirement for humans. I don't want editors reprimanded for not following the bulk of NORM, which is solely for editors' (and bots') ease and doesn't affect readers' experience at all.​—msh210 (talk) 03:53, 17 June 2015 (UTC)
    Reading Dan P's vote in opposition, I realized that I had, somehow, missed the NORM's lede completely. It does say almost precisely what I said I'm opposing because it doesn't say. My apologies; and I'm now striking my vote in opposition.​—msh210 (talk) 07:02, 21 June 2015 (UTC)
  2. Symbol oppose vote.svg Oppose Currently, the page mixes regulations obligatory for bots only with regulations obligatory for humans as well ("These norms are mandatory for bots. When they make a difference to how users see the entries, such as the presence of ---- and non-linking of language names in translatio ren sections, they are mandatory for everyone."). Thus, if it becomes policy, every human editor will have to wade through the page and figure out which parts are obligatory for humans. To address this, all parts that are mandatory for humans should be transferred to WT:ELE (Entry Layout Explained), which is the already existing location for formatting policy. Thereafter, the normalization page should only contain regulations that affect aspects of formatting invisible in the rendered page, and that humans should not be too anxious to forget to heed. It seems my comments are along similar lines as those above by msh210, while being slightly different. --Dan Polansky (talk) 17:25, 19 June 2015 (UTC)
    I support transferring all rules mandatory for humans from WT:NORM to WT:ELE. If the vote passes and NORM is enacted as it is now, as the creator of the vote I believe this would be a way to further improve NORM afterwards. It seems the items affected would be as follows:
    • Edit NORM's "Translation sections: Language names should not be linked or templated". ELE already mentions that language names should not be linked; this part could be removed from NORM. The part about "should not be templated" is invisible to the reader and therefore could remain in NORM.
    • Remove from NORM "Translation sections: Markup such as gender should be provided within the {{t}}/{{t+}} template, except for qualifiers, which should use {{qualifier}}." ELE already mentions {{t}} template but does not seem to mention {{qualifier}}, so it should be edited to mention the latter.
    • Remove from NORM "---- before each language heading except the first" but keep "One blank line before ----" and "One blank line after ----". ELE does not satisfactorily explain that we have ---- between languages, except for the subtle presence of ---- in the list of headings of WT:ELE#Additional headings, so the policy should be edited to explain it further.
    --Daniel 17:55, 4 July 2015 (UTC)
  3. Oppose. Arbitrary rules created for no benefit, like the intro to that page admits. Bots have to be resilient against whitespace variations anyway. More sensible regulations can be integrated into WT:ELE — and I think some are already. Keφr 10:24, 4 July 2015 (UTC)
    Re: "Arbitrary rules created for no benefit". As the creator of the vote, I disagree with that statement, on the basis that these rules are supposed to be simply a formalization of what the community already does in matters of standardization of newlines, category placement, etc. based on extensive discussions in this 2006 thread in a time where all of this was very random and we needed AutoFormat to fix it. Further to the point that these are just what the community already does, nothing undiscussed or controversial if possible, Wiktionary talk:Normalization of entries#Removed items contains a list of items I removed before the vote started, based on the 13 polls from May 2015; any of these items can be added later pending further discussion. Concerning ELE, I partially agree with you on the fact that I believe some of the items could be better placed in ELE and not NORM; see my reply to Dan Polansky above please. --Daniel 17:55, 4 July 2015 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain WT:NORM is utterly irrelevant and no more time should be wasted on it. —Aɴɢʀ (talk) 14:52, 11 June 2015 (UTC)
  2. Symbol abstain vote.svg Abstain This should be enforced by software, not human beings. DTLHS (talk) 03:14, 13 June 2015 (UTC)
    Human beings must write the software. Would you rather leave it to the one editor who writes the bot, or have an agreement among many which then determines how the bot must work? —CodeCat 01:48, 14 June 2015 (UTC)

Decision


Collapsing offensive images

  • Voting on: Images that may be offensive or obscene, chiefly to anglophone cultural sensibilities, would be collapsed by default on the page so that a user would have to click them to be able to view them, with a warning that they may be offensive or NSFW (as appropriate for the image in question). This is not censorship, because nothing would be removed from entries or the dictionary as a whole, but instead those who do not wish to see such images would not have to, should they wish to navigate to that page (e.g. to read another language's L2 section with a non-offensive meaning). Editors may collapse images at will if they do so in good faith, but if any debate or disagreement about whether or not to collapse an individual image ensues, the issue would be subject to community consensus.
  • Vote started: 00:00, 16 June 2015 (UTC)
  • Vote ends: 23:59, 15 July 2015 (UTC)

Support

  1. Symbol support vote.svg Support. If anyone is so desperate to see pictures of penises, vaginas and people with their heads blown to bits that they will feel censored by having to click one more time, then perhaps an online dictionary is not what they are looking for. — Ungoliant (falai) 18:51, 19 June 2015 (UTC)
    Support. The reader gets the freedom to choose. --ContraVentum (talk) 13:52, 22 June 2015 (UTC)
    Vote withdrawn. --ContraVentum (talk) 14:15, 24 June 2015 (UTC)
  2. Symbol support vote.svg Support Just seems reasonable, I guess, pictures aren't the main purpose of a dictionary anyway. It'd be better to make NSFW pictures just slightly harder to see in exchange for making the project as a whole much easier to use in schools and other sensitive places. WurdSnatcher (talk) 16:59, 4 July 2015 (UTC)
  3. Symbol support vote.svg Support In my view, the goal of Wiktionary is to provide its information efficiently and intelligently to its users. Whenever we make a policy change, we should ask ourselves: how will this affect the users' ability to use this site?
    In this case, we have on the one hand users that may shy away from certain entries (or the site altogether) because they are worried that they would be exposed to images that would be unpleasant for them to see. On the other hand, we have users who are not squeamish about such images, and it is conceivable that image illustrations sometimes could be really useful in conveying what the definition of the sense actually says: maybe a direct translation between language A and English is not possible. In this case, drawings could be a good substitute; but if we don't have a drawing but an image, we would be limiting ourselves if we didn't use the image - so there is an argument to use the image. A compromise is to use the image but to make it collapse by default.
    A second vote could establish something like a preference for drawings rather than images; which could be a better option, but I don't see any harm in a guideline like this (it does not say we should use such images, only how they are presented if we do), so therefore I support it. --Njardarlogar (talk) 13:27, 5 July 2015 (UTC)
  4. Symbol support vote.svg Support per Njardarlogar, in the mindset of This, that and the other. — I.S.M.E.T.A. 18:33, 5 July 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose If we have the picture at all, we should show it uncollapsed, IMHO. I support removing some less acutely relevant pictures, and replacing some photographs with drawings, as long as there is no loss in illustrative ability, as I did at bra in diff. Wikipedia does fine with having no images collapsed at W:Penis and the like. Wikipedia also does fine with having no images collapsed at W:Rorschach test, heated discussions of which you can find in the archives of W:Talk:Rorschach test; see also W:Wikipedia:Requests for comment/Rorschach test images. --Dan Polansky (talk) 19:36, 19 June 2015 (UTC)
  2. Oppose. What DP said. Either remove the image entirely or switch it to something less objectionable. Keφr 18:28, 22 June 2015 (UTC)
  3. Oppose Excessive. Also, unnecessary to vote on; should be discussed image-by-image. Purplebackpack89 22:13, 22 June 2015 (UTC)
  4. Symbol oppose vote.svg Oppose per DP. --Daniel 15:53, 23 June 2015 (UTC)

Abstain

  1. I'd rather see us using our editorial judgment to avoid needlessly graphic imagery. A dictionary can get its point across well without using graphic NSFW-type imagery - for example, using informative diagrams instead of photographs - although there may be vanishingly rare exceptions (can't think of any offhand) where it may be necessary to include graphic images. While some Wikipedians get a bit over-exuberant over the idea that the encyclopedia is not censored, I think as lexicographers we can afford to be a little more modest, while still not actually "censoring" anything. This, that and the other (talk) 13:29, 22 June 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)
    • Vote extended to 23:59, 5 April 2015 (UTC) --Dan Polansky (talk) 19:53, 4 March 2015 (UTC)
    • Vote extended to 23:59, 5 May 2015 (UTC) --Dan Polansky (talk) 19:52, 8 April 2015 (UTC)
    • Vote extended to 23:59, 5 June 2015 (UTC) --Dan Polansky (talk) 08:43, 3 May 2015 (UTC)
    • Vote extended to 23:59, 5 July 2015 (UTC) --Dan Polansky (talk) 20:06, 1 June 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)
    • I believe we should use ISO 15919 as either the standard or an alternative. It covers more basis (letters that IAST ignores) and is also used by google translate. Also, since both IAST and ISO 15919 are 1 to 1 transliterations (digaṃbara/digaṁbara will always be दिगंबर) we could even just do hard-redirects. This makes sense if the purpose is simply to get the user to the Devanagari-script page. DerekWinters (talk) 18:49, 3 May 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)
  6. Symbol support vote.svg Support As long as this is the English Wiktionary, and we assume that most of our contributors can't read other scripts and only have access to Latin input tools, it makes sense for usability's sake to be pretty liberal with romanizations. The RFV of maha/mahā found plenty of unglossed quotations of Sanskrit written in the Latin alphabet, so it's certainly not beyond the realms of possibility that a user will come across Sanksrit words and want to know what they mean. Smurrayinchester (talk) 14:32, 12 March 2015 (UTC)
  7. Symbol support vote.svg Support See Wiktionary talk:Votes/pl-2014-07/Allowing_well-attested_romanizations_of_Sanskrit#Software_alternative?. DCDuring TALK 18:50, 7 April 2015 (UTC)
  8. Symbol support vote.svg Support It may also be prudent to add Thai-cizations, Tamilicizations, Balicizations, etc. Especially for the Thai-script Sanskrit entries, pronunciation should be added to reflect the special usage of Thai Sanskrit. "In Thailand, Sanskrit is read out using the Thai values for all the consonants (so ค is read as kha and not [ga]), which makes Thai spoken Sanskrit incomprehensible to sanskritists not trained in Thailand" (from w:Thai_alphabet#Sanskrit_and_Pali). DerekWinters (talk) 08:28, 3 May 2015 (UTC)
    Also Tibetan, Javanese, Grantha (used only for Sanskrit), Sarada, and Siddham (still somewhat used in Japan). DerekWinters (talk) 19:08, 3 May 2015 (UTC)
  9. Symbol support vote.svg Support. And I would similarly support the inclusion of romanizations of Greek, Russian etc if used similarly. SemperBlotto (talk) 08:53, 3 May 2015 (UTC)
  10. Symbol support vote.svg Support, based on the arguments made at Wiktionary talk:Votes/pl-2014-06/Romanization of Sanskrit#Rationale. Inclusion should be based on attestation in Latin-script Sanskrit-only text (whether or not it matches any standard, such as IAST), and not in the running text of any other language. As of now, I only support this for Sanskrit; any other language we want to do this for has to be considered separately. --WikiTiki89 18:43, 15 May 2015 (UTC)
  11. Symbol support vote.svg Support   — Saltmarshσυζήτηση-talk 03:24, 27 May 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 OpposeUngoliant (falai) 16:34, 15 February 2015 (UTC)
  6. Symbol oppose vote.svg Oppose There are several scripts used for writing Sanskrit, but the Latin script is not one of them. The uſer hight Bogorm converſation 20:32, 7 April 2015 (UTC)
    @Bogorm: People may have all sort of reasons; yours is demonstrably factually wrong: Sanskript is written in Latin, among other scripts. --Dan Polansky (talk) 19:54, 8 April 2015 (UTC)
    @Dan Polansky: You appear to confuse Sanskrit with Pāli. Among Indo-Aryan languages Pāli texts have been published in Latin script, not Sanskrit ones. The uſer hight Bogorm converſation 20:12, 8 April 2015 (UTC)
    @Bogorm: Actually, I have that information from someone else, so maybe it is wrong, and if it is, I apologize. W:Devanagari_transliteration tells me that "Contemporary Western editions of Sanskrit texts appear mostly in IAST"; don't know whether that unreferenced claim is true - can you comment? --Dan Polansky (talk) 20:18, 8 April 2015 (UTC)
    I found it. User:Angr said "There are whole books of Sanskrit written in Latin script, so I see no reason to exclude Sanskrit in Latin from the dictionary.". --Dan Polansky (talk) 20:20, 8 April 2015 (UTC)
    @Dan Polansky: I should have written published by a reputable publisher (not by Samizdat or yoga amateurs). Reputable here may be defined thus: a publishing house that has published writings of eminent Indologists (such as Geiger, Liebert, H. Smith and so forth). In Pāli this is the PTS, but as regards Sanskrit, hardly any corresponding publication society is discernible. The uſer hight Bogorm converſation 20:34, 8 April 2015 (UTC)
    @Bogorm: Referring back to the quoted Wikipedia sentence: do you mean that "Contemporary Western editions" mentioned are published by publishers that are not reputable? Do you have any such particular publisher that is not reputable in mind? --Dan Polansky (talk) 20:40, 8 April 2015 (UTC)
    Why does it matter whether words are found in books published by a reputable publisher? We are not a dictionary restricted to including words found in such works. bd2412 T 22:56, 8 April 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


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: