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)
  5. Symbol oppose vote.svg Oppose. This may be useful for generating category names in templates, but in the main namespace it is unnecessary. --WikiTiki89 20:12, 22 July 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


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)
    • Vote extended to 23:59, 19 August 2015 (UTC) --Dan Polansky (talk) 09:14, 19 July 2015 (UTC)

Support

  1. Symbol support vote.svg Support as nom. bd2412 T 20:39, 4 February 2015 (UTC)
    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)
  2. 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)

  3. 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)
  4. 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)
  5. 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)
    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)
  6. 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)
  7. 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)
  8. 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)
    Just want to add that I would prefer it if citations were limited to before the 1960s. --WikiTiki89 18:20, 21 July 2015 (UTC)
  9. Symbol support vote.svg Support   — Saltmarshσυζήτηση-talk 03:24, 27 May 2015 (UTC)
    Symbol support vote.svg Support —Stephen (Talk) 13:21, 6 July 2015 (UTC)
  10. Symbol support vote.svg Support. I would not support this for any random language but I think it's useful with Sanskrit given that there is a standard transcription scheme in general use (IAST) and that Devanagari is not a script that we can reasonably expect our users to either be familiar with or figure out (I'd say that for all foreign scripts except maybe Greek and Cyrillic). As for entering IAST text, on the Mac for example it's not hard to enter all sorts of diacritics using the "US Extended" keyboard; you can also go to the Character Viewer and type in e.g. "a" and you will get "related characters" including variants of "a" with lots of different diacritics on them. Someone else also mentioned the helpfulness of the auto-completion in the search bar, e.g. if I type in "mahru" (which is not an attested word) the search bar shows an entry for the Comanche word "mahrʉ" without me needing to figure out how to enter the character "ʉ". I think this should be limited to IAST text but I think the requirement for attestation will ensure that we're unlikely to get very many weird non-IAST transcriptions. (BTW on a different note, I think Egyptian Arabic and other Arabic dialects should be rendered in Latin transcription because the Arabic alphabet is not sufficient for representing the phonologies of these languages. All sources I have on Arabic dialects use transcription exclusively. Unfortunately this is a potential can of worms because there isn't a single accepted transcription scheme ... in any case, an issue for another day.) Benwing (talk) 09:31, 20 July 2015 (UTC)
  11. Symbol support vote.svg Support If indeed the Latin entry is nothing more than a soft redirect to the Devanagari entry, I suppose I can't really come up with a decent reason as to how this differs from pinyin and romaji entries, per Angr's point. Aperiarcam (talk) 17:41, 22 July 2015 (UTC)
  12. Symbol support vote.svg Support partially. There aren't many reasons we would ever deny an attested term an entry here. Because the romanization is "wrong", because you think the script is anti-traditional, careless, or otherwise inappropriate, is exactly the wrong reason. Very fundamentally this is a prescriptive argument that holds no water here. We describe all words in all languages as they are used, not as any of us wish that they would be. The proposed criteria are so narrowly tailored that they can't in good conscious be any stricter, except maybe to require warning. Conceivably, this rule could be applied as an inclusionist principle to any transliteration for any language without any repercussion other than indexing terms that are actually in use. English written in Japanese characters? Why the heck not? Is the difference of a context label all that we're missing here? DAVilla 03:24, 9 August 2015 (UTC)
    I'm amending my vote by persuasion of arguments that one of the referenced citations is in the wrong language. I'm not one to object to that kind of inclusiveness, but I don't feel as strongly about it now. I should also say in fairness that, although I disagree with the practice, transcriptions have always been somewhat prescriptive here. DAVilla 03:04, 11 August 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)
  7. Symbol oppose vote.svg Oppose. In my opinion, shared by some others in previous discussions, it is inaccurate to consider the results of one language rendering something from another language into a script the rendering language's speakers can read (or in older times, a more basic practical concern: rendering it into a script the rendering language's printers/typesetters have the capacity to print/typeset) to be "words". I've seen transliterations of the entire text of the Soviet national anthem into Latin letters (different Latin letters depending on the language of the person doing the transliterating), transcriptions of Chinese strings into Latin and into Cyrillic, transcriptions of English and Russian strings into Chinese and Japanese characters, etc. "Soyuz nerushimy respublik svobodnykh" isn't written in the script Russian is written in; it's not Russian, it's a rendering of Russian; ditto "Zhongguo dalu" and the Sanskrit strings this vote is about. Such strings aren't English, either. Our format requires us to include only words which belong to languages, and to assign all words we include to langiages. Hence, I not only don't think we should include "nerushimy", etc, I don't think we can include them (accurately). I oppose trying to include them.
    I had refrained from participating in this vote, however, because I thought: if the majority is against me, and I don't have to edit such conceptually messy entries, why not let the majority get their way? But as has been pointed out in the BP, the only way a majority has been assembled here is by keeping this vote open for months on end, far past the length of time votes are usually kept open.
    Another issue is the nature of what this vote proposes. Allowing systematic romanization of a language (a la Gothic) is one thing. Allowing ad-hoc transliteration systems, but only for a single language, is inconsistent; what makes e.g. a French book's Latin-script Sanskrit different from a French book's Latin-script Chinese or a Chinese or Japanese book's Chinese- bzw. Japanese-character English, that we should be allowing only one of them?
    On a practical note, what effect would including Latin-script Sanskrit (and Devanagari-script Chinese, Chinese-character Russian, etc) have on our efforts to apply to languages fonts that best cover the characters they use? Suddenly, we'd have to anticipate that {{head}}s and other strings from most major languages might be present in most major scripts with varying, and if we allow ad-hoc transliterations then potentially unpredictable, arrays of diacritics.
    - -sche (discuss) 02:30, 20 July 2015 (UTC)
    • @-sche Would it help to limit the discussion to transliterations that are well-attested? Thus far, as a dictionary, we have tried to include words that a person might run across in print and want to define. bd2412 T 17:55, 20 July 2015 (UTC)
  8. Symbol oppose vote.svg Oppose this will be the end of Wiktionary if it passes. We need to maintain a level of seriosity and not be a rehash of unreliable Geocities websites from the past. -- Liliana 18:27, 20 July 2015 (UTC)
    • @Liliana-60 Since your objection seems to rest on the reliability of websites, would your view be different if citations were limited to books in print? bd2412 T 18:35, 20 July 2015 (UTC)
    • @Liliana I don't understand that objection at all. The vote does not propose to relax our attestation criteria. Our WT:ATTEST does not allow quotations to be from "unreliable Geocities websites". The vote uses the same language as WT:ATTEST, namely "used to convey meaning in permanently recorded media ...", italics mine. What is the point? --Dan Polansky (talk) 18:58, 20 July 2015 (UTC)
    There are way too many websites that use Latin script because they're way too lazy to actually use the proper script. Especially for ancient languages like Egyptian, this makes it next to impossible to find out the actual attested form. I see no need to copy others' mistakes in that regard. -- Liliana 19:03, 20 July 2015 (UTC)
    @Liliana And what makes these websites permanently recorded media? Do we accept these kind of websites for, say, English? --Dan Polansky (talk) 19:15, 20 July 2015 (UTC)
    How can it make it next to impossible to find the "actual" form? You just go out to the monument and read what it says. If that's hard, then I think calling the people who do that "lazy" is completely unjust. Because that's what the people who go out and look at the monuments publish in, transliteration. Again real scholars use transliteration.--Prosfilaes (talk) 20:36, 20 July 2015 (UTC)
  9. Symbol oppose vote.svg Oppose I don't see why the threshold for inclusion of Latin-alphabet Sanskrit should be higher than it is for Devanagari Sanskrit. Sanskrit is not a WDL, so one single mention should be sufficient. —Aɴɢʀ (talk) 06:12, 21 July 2015 (UTC)
    I think Sanskrit counts as extinct for CFI purposes, so it would need "one use in a contemporaneous source". Since Latin-script Sanskrit can't possibly fulfill that criterion (guess why), they're trying to make Latin-script Sanskrit count as a living language, rather than an extinct language, so they can go by the normal, less restrictive (due to not being restricted to contemporaneous sources) three-citations rule instead. I think that's a violation of our CFI. -- Liliana 08:02, 21 July 2015 (UTC)
    If the requirement for Sanskrit is "one use in a contemporaneous source" then we can't host any Sanskrit here at all in any script, since Sanskrit was not written down until centuries after it became extinct. Nevertheless, CFI does permit one mention for extinct languages under the same conditions as for living LDLs. —Aɴɢʀ (talk) 08:28, 21 July 2015 (UTC)
    When was that added? I remember the "contemporaneous" restriction was made to prevent people from coining modern words for extinct languages, like having entries on nuclear energy in Egyptian language. But if you can just cite these words as LDL instead, that restriction becomes completely ineffective. -- Liliana 08:50, 21 July 2015 (UTC)
    I suppose the condition that "the community of editors for that language should maintain a list of materials deemed appropriate as the only sources for entries based on a single mention" is there to exclude that sort of thing. If the community of editors of Ancient Egyptian maintains a list that excludes anything coining words for nuclear energy, then such coinings will not be included. —Aɴɢʀ (talk) 09:35, 21 July 2015 (UTC)
    Unless these coinages take hold and are published in three independent sources. We still don't want to call them Ancient Egyptian. --WikiTiki89 12:55, 21 July 2015 (UTC)
    @ User:Angr: If I read the vote proposal correctly, it does not introduce any exclusion criterion, only an inclusion criterion. The vote proposal is of the form "Whenever X, we allow Y". It does not logically follow from that that "Whenever not X, we disallow Y". Therefore, it seems to me that even if you deem the criteria too stringent, you should be able to support the inclusion of the set allowed by the criteria. Am I wrong? --Dan Polansky (talk) 07:04, 9 August 2015 (UTC)
    It's a matter of establishing a precedent. I don't want to support a proposal with an overly narrow inclusion criterion, because if it passes it will then become the status quo, making it that much harder to later broaden the inclusion criteria. —Aɴɢʀ (talk) 07:28, 9 August 2015 (UTC)
    @User:Angr I see. What do you think is going to happen to prospective Sanskrit entries in Latin script if the proposal does not pass, but rather, say, ends in 60% support - no consensus? Do you think they are going to be created and then kept? Do you see a chance that when someone creates such an entry, a nasty quarrel, maybe a create-delete repetitive sequence, ensues? --Dan Polansky (talk) 07:36, 9 August 2015 (UTC)
    Symbol oppose vote.svg Oppose I don't think the proposal is well-formed, judging from the range of possible interpretations of "well-attested" that have been offered. Flexibility of interpretation is not bad in principle, but it seems to leave too much in doubt for those opposing the proposal. I hadn't realized how problematic the proposal formulation was. Given the elasticity of our interpretations of terms such as "well-attested", one might well expect that all possible definitions will be applied with connecting "or"s. Perhaps the third try will be the charm. DCDuring TALK 18:15, 21 July 2015 (UTC)
    @DCDuring: You forgot to strike your support vote. As for your objection, "well-attested" indeed should have been "attested", IMHO, but that is very minor given that the vote is explicit about what it means: "used to convey meaning in permanently recorded media in at least three independent instances, spanning at least three years"; this I quote from the wording of the vote. I see no room for interpretation, or certainly no more room than is currently in WT:ATTEST which uses the same language. I think you should reconsider or clarify. From your support vote, I take it that you support including Latin-written Sanskrit in some form; please clarify if this is not the case. --Dan Polansky (talk) 18:34, 21 July 2015 (UTC)
    You are right. I don't know what I am talking about on the substance.
    I suppose I am trying to make sure that the result is the one that would have occurred had the vote ended at the first vote-termination date (5 March 2015) as I view the process as irregular and, if not in violation of any specific policy or procedure here, at least in violation of my sense of fairness and due process. DCDuring TALK 19:08, 21 July 2015 (UTC)
    @DCDuring That's fair enough. Abstaining because of disagreement with perceived process irregularities make perfect sense. Nonetheless, let me point you to diff and the principle that I stated there: "If a vote is getting the result of no consensus, and if at least one vote was cast to it during the last month, the vote can be extended in good conscience. A result is "no consensus" if it is 50% in support or higher but lower than a pass." When I extended this vote multiple times (it is my repeated extensions that you appear to be objecting to), I was following this principle. I think this principle is reasonably fair, and even if it shows selection bias a bit, the benefits offset the bias. --Dan Polansky (talk) 19:43, 21 July 2015 (UTC)
    Symbol oppose vote.svg Oppose I hope I understand this proposal correctly. I think it would be fine to create a redirect to the Devanagari entry (at least where the Latin spelling would not coincide with words from other languages), but it strikes me as silly to use the somewhat narrow and recent attestation of Romanized Sanskrit to argue that it has a comparable claim to being a native script as Devanagari does. Regardless of the controversy regarding Sanskrit's lack of a native script, scholars from both East and West have been using Devanagari as the de facto standard script for Sanskrit for centuries. Sure, this is influenced by Hindi's prominence in India today, but I don't think this is different from any other editorial standard we use in a dictionary. Just as we use lowercase letters, accent markings, etc. in modern printings of classical Latin and Greek texts, and dictionaries of said languages, we should not be hesitant to apply this standard on Sanskrit, to the exclusion of the Latin alphabet, notwithstanding the anachronism. Aperiarcam (talk) 22:36, 21 July 2015 (UTC)
    Why to the exclusion of the Latin alphabet? Why not have both? Why should we allow romanizations for Gothic, Chinese, and Japanese, and prohibit them for Sanskrit? —Aɴɢʀ (talk) 22:55, 21 July 2015 (UTC)
    I think you're not quite correct when you say Western scholars use Devanagari as the de-facto standard script for Sanskrit. Most recent Western works I've seen on Sanskrit use IAST Latin transcription, often exclusively and without Devanagari. It seems it's mostly older works, e.g. William Dwight Whitney's grammar, that used Devanagari primarily. Benwing (talk) 13:45, 22 July 2015 (UTC)
  10. Symbol oppose vote.svg Oppose I changed my mind. —JohnC5 07:56, 9 August 2015 (UTC)
    @JohnC5: Any rationale? --Dan Polansky (talk) 08:06, 9 August 2015 (UTC)
    @Dan Polansky: None that hasn't already been said. Well, I might say that I spent a long time working on standardizing Old Italic transcription stuff only to have people say that we should just romanize all the Old Italic languages. This sort of put me off of romanization entries. —JohnC5 08:13, 9 August 2015 (UTC)
    @JohnC5: Would you point me to at least one discussion that pertains to Old Italic transcription so I can follow what you are talking about? --Dan Polansky (talk) 08:19, 9 August 2015 (UTC)
    As for "None that hasn't already been said": Can you please point me to one specific location containing that specific rationale, in a manner that makes it possible for me to find the specific sentences containing the ratioanle? The phrase "None that hasn't already been said" does not uniquely identify any rationale. The rationale would help answering the following question: Why is it beneficial for the user of Wiktionary to have attested romanizations excluded from Wiktionary? --Dan Polansky (talk) 08:24, 9 August 2015 (UTC)
    @Dan Polansky: As far as I'm aware, Wiktionary:Beer parlour/2015/July#Old Italic standardization proposals is the locus classicus of discussion pertaining to Old Italic transcription. @JohnC5, please correct me if I'm wrong. — I.S.M.E.T.A. 13:52, 9 August 2015 (UTC)
    @I'm so meta even this acronym: Thanks, that is quite correct.
    @Dan Polansky: I'm sorry for the delay, but I went to sleep soon after my last response because I was awake at a very unreasonable hour. To your question, I don't particularly appreciated your tone in asking for further rationale. I know the written word transfers people's intentions poorly, but it reads very much like you are haranguing me for not answering you. In truth, I did not give more rationale both because I do not want to become involved in the argument here and because I'm under no obligation to give rationale in the first place, much less go over points that have already been made. I understand that you feel strongly in this matter and would like to convince me of your point (an admirable endeavor!), but I tend to avoid getting into debates like this because people do not make the minuscule effort it takes to be cordial. Again, I'm sorry to assert that you were berating me, but it does read that way from my perspective. —JohnC5 16:28, 9 August 2015 (UTC)
    If what you intended to say is "I won't give you my rationale", maybe that is what you should have said in the very beginning rather than indicate that you support some sort of amorphous mass of rationales spread in this vote and previous votes. The strategy employed by multiple opposers consisting in avoiding to pick up any specific rationale is objectionable; it makes it hard to investigate the validity of rationales since no specific ones are given. While there is no requirement to state a rationale, a refusal to give one is nowhere an admirable thing to do. Wikipedia has this nice string "!vote", which suggests that arguments are important. While I am sorry about any tone issues I have, what matters in the first place is substance, and, unfortunately, I am not seeing much of it in your vote and your comments. --Dan Polansky (talk) 20:11, 9 August 2015 (UTC)
    I have very specific reasons, but I do not care to argue them. You may say that I am avoiding having them disproved or undermining the voting process by not giving people fodder for debate, but no, I won't defend my position. Again, it is vaguely offensive that you are implying that my failure to give rationale represents an absence of proper reasoning. Feel free to continue attempting to goad me into an argument, I suppose―it is entirely your prerogative. —JohnC5 21:30, 9 August 2015 (UTC)
    The failure to give rationale prevents other people from examining it. Human experience shows that reasoning is all too often faulty. He who does not expose reasoning for other people to examine is all too often too uncertain about correctness or plausibility of that reasoning. I find it in poor taste that people who want to prevent others from creating certain attested entries can't be bothered to tell us why. Whether you have proper reasons or wrong reasons I do not know; you have some reasons, and you fail to disclose them, which all too often happens to people who feel that their arguments do hot hold water. Your argument may hold water or it may not; I will not know. Again, this is obviously not about you in particular but about other votes as well. With you, I had hope. --Dan Polansky (talk) 23:23, 9 August 2015 (UTC)
    Well, I appreciate that you had hope for me. I promise I am a friendly and reasonable, regardless of my opinion on this issue. Too often animosity from one issue spills over into unrelated parts of this project, which again leads me to avoid debating topics to which I have little to add. I, in turn, hope you will not begrudge me this! —JohnC5 05:26, 10 August 2015 (UTC)
  11. Symbol oppose vote.svg Oppose Changed my vote to "oppose". --Anatoli T. (обсудить/вклад) 05:07, 10 August 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)
  2. Symbol abstain vote.svg Abstain —Stephen (Talk) 02:34, 20 July 2015 (UTC)

Decision

  • Passes, 12 - 6 - 1. —Stephen (Talk) 13:22, 6 July 2015 (UTC)
    • I wouldn't deem a 12–6 vote passed, myself, though I know others do; but I really don't think we should in this case, in light of the procedural irregularity.​—msh210 (talk) 20:54, 14 July 2015 (UTC)
      • @msh210: I thought that the required supermajority is ⅔… That's exactly the proportion of 12:6. — I.S.M.E.T.A. 21:19, 14 July 2015 (UTC)
        • (@) There's been quite a bit of past discussion, and no consensus or even widespread agreement AFAIK, about what the required supermajority is.​—msh210 (talk) 06:18, 15 July 2015 (UTC)
          • Discussions are not exercises in bean counting. In the above discussion, five out of six editors expressing opposition to the proposal provided no substantive argument on the matter. The sixth offered an argument based on a premise that was noted to be factually incorrect based on citations that have been provided with respect to this discussion in the past. bd2412 T 13:17, 15 July 2015 (UTC)
            • Wyang is clearly saying that the reason he (and possibly others) gave in the previous vote still applies. Vahag and Ivan explicitly agree with Wyang; Dijan and Ungoliant agree with him implicitly. I wouldn't call that not providing a substantive argument, since there are many substantive arguments discussed in the previous vote and other discussions linked to above. There is no rule that says the argument must be provided in the vote itself. --WikiTiki89 14:56, 15 July 2015 (UTC)
              • Wyang's previous vote called for developing reverse transliteration modules as an alternative. Such modules have not been developed. Any editor with the programming ability is welcome to develop such a thing and offer it as a functional alternative, at which point the need for romanizations can be revisited. bd2412 T 15:31, 15 July 2015 (UTC)
                • You can disagree with him, but you can't say that his vote is baseless. --WikiTiki89 15:33, 15 July 2015 (UTC)
                  • I can certainly say that it is based on a weak premise, in light of our determinations for other transliterations. I can also certainly say that votes 4 and 5 are explicitly baseless (I don't see an implication where there is no evidence for one), and that vote 6 is based on a factual error that is undercut by actual citations that have been provided for the one word that is primarily at issue here. bd2412 T 16:47, 15 July 2015 (UTC)
                    • "The sixth offered an argument based on a premise that was noted to be factually incorrect based on citations" Based on which citations in particular? Could you provide a link? This is an example for a Pali composition (Dhammasaṅgaṇi) published in the Latin script by a reputable publisher (PTS). If you can provide an example for a Sanskrit publication in the Latin script analogous to that, I pledge to reconsider my position. However, the claim that my justification had arguably been noted to be factually incorrect is a groundless, unfounded assumption. The uſer hight Bogorm converſation 17:36, 16 July 2015 (UTC)
                      • Based on the citations collected at Citations:mahā, including a section of transliterated Sanskrit passages. I don't know why you keep referring to "a reputable publisher", as if Wiktionary has some rule discounting words or usages found in other texts. Our only rule is that the text must be durably archived. We even use usenet group archives for citations. If you think that there is a requirement that words be cited to a work by any particular kind of publisher, then you are factually wrong on an entirely different level. bd2412 T 18:11, 16 July 2015 (UTC)
                        • The first edition is overtly proselytic and proselytism relies on maximal simplification and minimal thoroughness and profundity with regard to perquisition and authenticity. The second one is an edition of a living person again with the aim of maximal distribution with minimal effort. The third which you essayed to incorporate into the page less than an hour ago, has been fortunately removed (not by me) because there the word was part of a proper name. Thus, all of them are nowhere near as reputable with regard to the publisher (as is PTS) and/or classical with regard to content (as is Dhammasaṅgaṇi). Therefore I am afraid that there is either a misconception of analogous example or (as I am still convinced) absence of analogous examples that corroborates the above argument from the Oppose section. The uſer hight Bogorm converſation 18:47, 16 July 2015 (UTC)
                        • P. S. I would like to propose moving that conversation concerning reputable publications of classical works (classical, since an ancient language is concerned here) either to the Oppose section or to the discussion of the vote, lest the decision section diverge from its main purpose which is the closure of the vote; if BD2412 does not object. The uſer hight Bogorm converſation 18:47, 16 July 2015 (UTC)
                          • If your intent is to impose a standard of "reputable publications", then the place this discussion needs to go is Wiktionary talk:Criteria for inclusion, because the citations I provided clearly meet the current strictures of that policy. bd2412 T 22:19, 16 July 2015 (UTC)
      • As for "procedural irregularity" mentioned above, the only irregularity that I see is that the vote was closed on the same day on which the last vote was cast. I reject the claim that the extensions themselves are procedural irregularity. More discussion is now at Wiktionary:Beer_parlour/2015/July#Persistent_extensions_of_votes; it could as well have been on this page of the vote, and I find it inappropriate that the vote was locked to prevent discussions about its outcome and manner of closure. --Dan Polansky (talk) 08:54, 19 July 2015 (UTC)
    • By my lights, 2/3 should be pass, for a vote like this that does not change the constitution. But I disagree with how the vote was closed by Stephen. On the day Stephen cast his vote, he should have extended the vote, IMHO. If multiple people agree, we can extend the vote one month. --Dan Polansky (talk) 07:54, 19 July 2015 (UTC)
    • I extended this vote by one month from today, to 19 August 2015. I support the extension and so do DCDuring and msh210 if I understand their comments in Wiktionary:Beer_parlour/2015/July#Persistent_extensions_of_votes correctly. Please let me know here if you agree with this extension.--Dan Polansky (talk) 09:14, 19 July 2015 (UTC)
      • This extension confirms the blundering nature of the underlying process to achieve this proposal and similarly marginal proposals. Obviously the original vote was premature. The second vote, as it has turned out, was also premature. The use of voting in lieu of BP discussion and polls makes the corruption of the voting process possible, even inevitable. But, instead of any lesson being learned, we have another vote (on the voting process itself) being promoted without sufficiently broad discussion in advance. DCDuring TALK 12:49, 20 July 2015 (UTC)
        • Contrary to the above ranting against voting, this vote was not premature. There was plenty of time for discussion, and some actual discussion, before the vote. We are having great results with voting in the English Wiktionary, with cleaner and better policies, achieved through a timely and transparent process. The reader might not object to be reminded of such votes as Wiktionary:Votes/pl-2010-05/Names of specific entities, which terminated endless discussions about the attributive-use rule which almost no one supported, a rule that threatened to be used by a minority in the RFV process to remove a significant portion of our coverage of proper names including placenames. A recent vote improving our policies by eliminating poorly attested, and IMHO unreal, content is Wiktionary:Votes/pl-2014-03/CFI: Removing usage in a well-known work 3. I will remind the reader that our votes are ripe with rather open discussion: discussing directly on the vote page is not forbidden and is common. We have a very open and transparent voting culture that many Wiktionaries can only envy. --Dan Polansky (talk) 18:56, 20 July 2015 (UTC)

Fails. Thanks to all who left constructive feedback. DAVilla 00:09, 21 August 2015 (UTC)

  • That's no consensus 12-11-2 by our long-standing practice, not "fails". Furthermore, the vote could have been further extended using the result-agnostic algorithm "new votes in the last extension period => extend further by one month". I am reluctant to extend the vote given the heat the past extensions of this particular vote have created, but the the mentioned extension algorithm cannot be accused of allowing result selection, and thus does not show selection bias, AFAICS. --Dan Polansky (talk) 19:52, 21 August 2015 (UTC)
    This nearly passed and now it has nearly failed. While technically it is no consensus, I'm reluctant to call a vote that has been extended 5 times anything but a failure. I would be happy to change my ballot if that's all that's needed to make the harsher description technically accurate, but I would imagine everyone would prefer me to vote my conscience. DAVilla 10:43, 24 August 2015 (UTC)
    I think you are confusing two things. Saying that this vote is a failure (i.e. a procedural failure) has nothing to do with the outcome of the vote (i.e. pass/fail/no consensus). --WikiTiki89 12:34, 24 August 2015 (UTC)
    It is rather a moot point. After the failure of the vote on "excluding romanizations by default", which was initiated after this vote, the upshot of this vote failing is that romanized Sanskrit terms that have a CFI-worthy number of citations can now be entered with no standards at all. bd2412 T 13:08, 24 August 2015 (UTC)
    I don't see how that other vote could carry any weight whatsoever. Its author voted against it, which means that he could have inserted language, not necessarily deliberately or consciously, that would ensure its demise. (Disallowing extending of votes is a good example of this. I nearly voted against because I felt it went too far. An author who was genuinely interested in seeing it pass would have been more certain to take others' input into consideration.) Furthermore, while the vote you reference was worded in such a way as to require consensus that it did not gain, it neither gained anti-consensus. That is, the negation of the vote would not be policy either. Next time I want to push through a policy, should I state the opposite of what I truly want, and declare success when barely half of the community agrees with me? Excepting precedent, I'm inclined to start treating any losing vote in which the author votes against as withdrawn. DAVilla 19:09, 24 August 2015 (UTC)
    Re: "Excepting precedent, I'm inclined to start treating any losing vote in which the author votes against as withdrawn": That's inacceptable. If the supporters of the proposal had any issue with the wording, they (1) could have raised the issue on the talk page, and (2) could have created a vote that used wording to their liking. There are people around all to eager to do things without votes and contrary to consensus, and it is essential that their opposers are allowed to create votes for proposals that they themselves oppose. Unless you can point out specific defects with wording, your fantasies about proper procedure and bad faith should be disregarded as lacking any verifiable substance. Wiktionary:Votes/pl-2014-06/Excluding romanizations by default provides a verifiable objective evidence of the scope of consensus for exclusion of romanizations; your claims will not prevent the reader from checking this evidence. --Dan Polansky (talk) 19:20, 24 August 2015 (UTC)
    As for Wiktionary:Votes/pl-2015-07/Disallowing extending of votes: (1) Editors had the opportunity to make specific wording enhancement proposals on the talk page. They did not do it. In fact, the vote says what I saw multiple editors say before, so it only creates a channel for what they said they supported. (2) Editors can create a vote with an alternative proposal. They can do it right now. The vote is scheduled to run for three months so they have plenty of time. They may do the real work and draft a specific proposal. I drafted a specific proposal of a result-agnostic extension procedure on the talk page of Wiktionary:Votes/pl-2015-07/Disallowing extending of votes. No one contributed a specific proposal for an alternative policy or algorithm. The only thing they ever came up with was stick with the original end date. So that is what the vote proposes. Again, venues are open for real drafting and political work. --Dan Polansky (talk) 19:26, 24 August 2015 (UTC)
    It's "inacceptable" to feel a certain way and not act on it in deference to precedent? It's "inacceptable" that such consideration would have no real consequence since neither a losing vote nor a vote that was withdrawn affect policy? The only act that would seem to be unacceptable to me is the one you propose, to start a new vote that parallels an existing vote still in progress. Apart from its disrespectful nature, the confusion this could potentially create, especially if both pass and worse if any of us get creative with our supporting votes, would be a waste of people's time.
    Let me be very clear. I am not assuming bad faith on your part or anyone else's when I say that the author of a proposal should have an interest in seeing that vote pass. In particular you have made changes in good faith when they were suggested. However, expecting contributors to make alternative proposals on the vote's talk page the week before it starts is often not enough to get a feel for where the community consensus lies, which is something the author must gauge well in order to push a vote through successfully. Lord knows I've had my share of misjudgments on that front. DAVilla 06:16, 25 August 2015 (UTC)
    Who started what vote is ultimately irrelevant. The bottom line is that no consensus has been articulated to exclude romanizations by default, the only suggestion of such a rule has failed to gain consensus, and we are in the wilderness on this issue. bd2412 T 15:36, 25 August 2015 (UTC)

Disallowing extending of votes

Support

  1. Symbol support vote.svg Support. My first choice is the traditional practice of closing votes which show no consensus as "no consensus", and then if need be having more discussion and a better vote (with refined wording, or after working out some of the side issues that blocked the first vote, as happened with the "well-known work rule" votes). What Dan suggests on the talk page (a set of rules for when to extend votes in a way that minimizes selection bias) would be my second choice, although I think it might be good to have some cutoff to keep votes from dragging on indefinitely as several have already shown a tendency to; e.g. "no vote shall last more than 3 months (even if this means it is closed as no consensus)". - -sche (discuss) 17:40, 8 August 2015 (UTC)
    A vote that keeps on dragging on is better than a vote that is closed as "no consensus", IMHO. I do not see any harm im votes lasting more than 3 months. For instance, Wiktionary:Votes/2014-08/Migrating from Template:term to Template:m would have benefitted from being extended even longer than it was; I stopped extending it because people started to object. For some reasons, some people came to vote only after several months. From what I have seen, the fact that the vote was opened for a long time did not in any way diminish its consensus based character. More votes passing via repeated extensions, even those suffering from some small degree of something like selection bias, is much better than volume non-consensual changes indirectly supported by many here. When the same people who did not oppose and take action against non-consensual volume changes made without a vote now find a little confirmation bias issue with a real, transparent vote, I don't really know what to think. The important thing to me is to have votes that work better, and the repeatedly extended votes do work better, from what I can see. --Dan Polansky (talk) 14:34, 9 August 2015 (UTC)
  2. Symbol support vote.svg Support in general (weak support). Perhaps there could be cases when extensions should be allowed, e.g. when nobody voted on a topic, which is of interest to at least a few editors and some editors expressed interest in extending a vote. --Anatoli T. (обсудить/вклад) 01:14, 13 August 2015 (UTC)
  3. Symbol support vote.svg Support reluctantly: I don't think this is the best solution to the problem, but it's the proposal before us and surely better than what we've got now. (Cf. my recent comments on the topic on this vote's talkpage and especially in the Beer parlour.)​—msh210 (talk) 04:36, 16 August 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 07:46, 1 August 2015 (UTC)
    If we require that the vote duration specified at the time of the start of the vote is binding and cannot be changed during the run of the vote, then we either have to create relatively short votes that get too little chance for gaining cast votes or we have to create long votes such as for 3 months, which gives more chance for people to come to the vote but also creates an avoidable delay for those votes that get a clear result fairly early. And then, even 3 months can prove too short a period. I think the following is a good principle for repeatedly extended votes:
    If a vote is getting the result of no consensus, and if at least one vote was cast to it during the last month or extension period, the vote can be extended in good conscience. A result is "no consensus" if it is 50% in support or higher but lower than a pass.
    The above principle involves a certain amount of something that resembles (but is IMHO not identical to) W:selection bias: without its application, more votes would be closed as "no consensus" which in practice is similar to "fail". On the other hand, the votes that pass as a result of extension are those that gained more cast votes as a result of the extension and are thus more representative of the positions of all editors. Furthermore, the longer the vote lingers on the WT:VOTE page, the less plausible it is for a regular editor to claim that they did not see the vote or that they did not find the time to consider its proposal, do the research and thinking, and oppose if applicable.
    As for previous practice, votes with a single extension include Wiktionary:Votes/pl-2010-05/Placenames with linguistic information 2. Votes with multiple extensions include Wiktionary:Votes/pl-2007-05/Placenames 2, but most of the multiple extensions were brought about fairly recently by me, including those in Wiktionary:Votes/pl-2014-03/CFI: Removing usage in a well-known work 3, Wiktionary:Votes/2014-08/Migrating from Template:term to Template:m, Wiktionary:Votes/2014-09/Renaming rhyme pages, Wiktionary:Votes/pl-2014-07/Allowing well-attested romanizations of Sanskrit, and Wiktionary:Votes/pl-2015-02/Trimming CFI for Wiktionary is not an encyclopedia. --Dan Polansky (talk) 07:49, 1 August 2015 (UTC)
    Oppose I think that extending votes is a good idea if (1) there were votes cast close to the closing date, as in hours or just a few days before, and (2) the status is not clear because the tally is right on the dividing line. Even in the case of a technically late vote, though one made before a decision, it is better to keep things open than to either disregard the late vote or include only it, either of which could be seen as preferential treatment. However, votes should not be extended indefinitely, especially if there is a clear outcome (meaning 60% is failure, end of story), but even if there is no recent activity they should just be closed as no consensus. Also, it's not necessary to extend them beyond 1 or 2 weeks at a time (at least 1 week from the date of extension, no more than 2 weeks beyond the initial closing date). DAVilla 06:27, 10 August 2015 (UTC)
    I would argue that extending by a mere week rather than a month creates more of a selection bias. And it does very little in giving votes significantly more chance to gather participants. --Dan Polansky (talk) 07:05, 10 August 2015 (UTC)
    There is selection bias inherent in the term of the vote, so of course keeping it open for a month more is going to give a better chance for participation. If you think it is necessary for the vote to be open that long, though, then it should have had a longer timeframe in the first place. The point of extending the vote is not to bring correction to an interval of time that was too short, it is to round out an arbitrary cutoff date when doing so would be useful to determination of the outcome.
    I should also say that I don't believe it's the author's prerogative to extend a vote in order to achieve consensus, regardless of any argument about decreasing selection bias over a longer period of time. If this is the level of control you desire over votes you've initiated, it might be wiser to step back, recuse yourself in a way, and simply let others close your votes for you. DAVilla 02:46, 11 August 2015 (UTC)
    Re: "There is selection bias inherent in the term of the vote": I cannot confirm this. Please read W:Selection bias and clarify why any vote should automatically (inherently) have a selection bias. Selection bias can be exemplified on a clinical trial. It occurs when you run a clinical trial and end it at a date different from the one originally set up for the trial; you keep observing results at various prospective dates of termination, and pick the date of termination that looks best for you; and because there is certain random variation, your ability to pick the termination date translates into your ability to pick a more favorable result, and skews the result. If a clinical trial ends on the date originally set up for it, there is no selection bias; similarly, if a vote ends on the date originally set up for it, there cannot be a selection bias: the closer does not choose the termination date, and this lacking choice cannot translate to choice of more favorable result. Generally, the higher the number of candidate termination dates, the higher the selection bias. On the talk page of this vote, I have presented a mechanism that lets the choice to extend or not extend be made only once by a human: after the first month. Thereafter, the extension is under control of the algorithm, and is result-agnostic, depending merely on whether new votes are coming to the vote. --Dan Polansky (talk) 08:38, 11 August 2015 (UTC)
    Re: "then it should have had a longer timeframe in the first place": not really. At the outset, you don't know how many people will come to the vote during the first month. The vote may end up in 11:0:3, which I don't think should be extended. Yes, we had such a vote: Wiktionary:Votes/pl-2013-10/Removing SAMPA and X-SAMPA. --Dan Polansky (talk) 08:38, 11 August 2015 (UTC)
    The timeframe establishes a bias in that "some members of the population [would] be less likely to be included than others", namely those who are less active. Since that delineation between contributors isn't usually a major concern, I'm sorry if I misunderstood the kind of bias you meant. On your point, I agree that selecting a termination date based on the data is a stronger bias, which is why I only consider extending the deadline when the result is not clear. Extending a failed vote in the hope of gaining more support, even if it's done once, is fishing for the result you want. That's a more important point than the duration of the extension, which I'd only mentioned as an aside. DAVilla 05:31, 12 August 2015 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain Although, as noted above, I think there are cases where this can be useful, I wouldn't want to stand in the way of a simple solution to a simple problem, and wouldn't have any objection to following the rule myself. DAVilla 00:02, 21 August 2015 (UTC)
    And what is the simple problem? Selection bias? Selection bias has much better, also simple, solution: "new votes added in the last extension period => extend further by one month". --Dan Polansky (talk) 19:50, 21 August 2015 (UTC)
    I'm not saying it's happened yet to this extent, but potentially there could be votes that seem to go on forever, to the point where people who are for go against just to make it die already. DAVilla 06:01, 22 August 2015 (UTC)
    This could be prevented by setting one year to be the maximum duration. And it could not go forever, since there is a relatively small number of editors capable of adding new votes. --Dan Polansky (talk) 08:43, 22 August 2015 (UTC)

Decision


Nesting inflected form definition lines

  • Voting on: Volume changing the formatting of inflected form entries from the currently common one exemplified by
  1. nominative plural of aqua
  2. genitive singular of aqua
  3. dative singular of aqua
  4. vocative plural of aqua

to new one exemplified by

  1. inflections of aqua:
    1. genitive singular
    2. dative singular
    3. nominative plural
    4. vocative plural

The use of boldface, italics, hyperlinks, and capitalization are not covered by this proposal, and should be therefore unaffected by the result of this vote.

As part of this proposal, creating the new formatting by means of a single template invocation instead of multiple ones as before, possibly like the following one:

# {{inflection of|aqua||gen|s|;|dat|s|;|nom|p|;|voc|p|lang=la}}

rather than the previous

# {{inflection of|aqua||nom|p|lang=la}}
# {{inflection of|aqua||gen|s|lang=la}}
# {{inflection of|aqua||dat|s|lang=la}}
# {{inflection of|aqua||voc|p|lang=la}}

Support

Oppose

  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 09:55, 10 August 2015 (UTC) I prefer the relational format to the hierarchical one. The hiearchical format adds one more horizontal line, and thus takes more space. I find the proposed wiki markup outright ugly. This is all mostly of the nature of personal preference, and so will be the supports, I fear. If someone comes up with arguments that go beyond personal preference, I will look at them and reconsider. One argument that is less of a personal preference is that the proposed markup makes it impossibly to place attesting quotations below the individual inflection lines, but some people argued these quotations should be in the lemma. --Dan Polansky (talk) 09:55, 10 August 2015 (UTC)
  2. Symbol oppose vote.svg Oppose We do not have a standard way of presenting subsenses, and I'm not keen on creating one now. DAVilla 10:25, 24 August 2015 (UTC)
  3. Symbol oppose vote.svg Oppose — My main reason for opposing this is that it prevents placing attesting quotations beneath specific inflected forms' definition lines (I personally from time to time place {{seecites}} beneath specific {{inflection of}} definition lines, which requires the same functionality as placing whole quotations there). It's valuable to indicate when certain forms are attested; in Latin, this is especially so in the case of vocatives, which occur rather infrequently. For example, take comētēs ‎(shooting star): I would want to know if it were attested in the vocative (be it the singular, comētē, or the plural, comētae), since that may suggest religious usage (perhaps in the "when you wish upon a star" vein), and would be remarkable; compare chelys ‎(tortoise [shell]), which is, unexpectedly, attested in the vocative singular (chely). My other, lesser reason for opposing this is that it seems simply pointless: firstly, unless the subsenses are collapsed by default, this adds an extra definition line (as already noted by Dan Polansky), which is surely contrary to the intention behind this; secondly, I see little value in going to all this trouble to save what isn't really very much space (for Latin, I think that the maximum number of definitions for inflected forms you'll get for any one word is six — the isomorphic dative and ablative plural forms in all three genders of adjectives of the first–second (-īs) and third (-ibus) declensions); and, thirdly, this is likely to lead to inconsistency of presentation within entries (in cases like those of Latin first–second-declension adjectives, whose nominative and vocative feminine singular forms and nominative, accusative, and vocative neuter plural forms all end in -a, whereas their ablative feminine singular forms end in — one would see "inflections of adjectīvus:" with five subsenses under one headword, but "ablative feminine singular of adjectīvus" under another). I really can't see any good reasons for supporting this proposal. — I.S.M.E.T.A. 22:00, 24 August 2015 (UTC)

Abstain

Decision


Normalization of entries 2

  • Voting on:
    • Promoting the revision 33764378 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 that govern how the wiki code behind an entry should be formatted. They are invisible to the readers, e.g., following these rules makes no difference to how a user sees the page, but they do make the pages conform more to a standard format reflecting what we think of as best for the wiki code. 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."
  • About the policy:
    • The list of items currently in the policy was developed from this extensive 2006 thread, which shaped the wiki code of our entries as we know to this date with the major role of User:AutoFormat (2007–2010) and I proposed to be officialized through this discussion from May 2015 with 13 polls. Controversial, outdated or undiscussed items were removed from the list and moved to here. This policy was voted before here but failed with 7 - 4 - 2 (63,6% support); the policy has since been revised based on the previous vote. The version of the policy being voted now is different from the version proposed then.
  • Vote started: 00:00, 5 August 2015 (UTC)
  • Vote ends: 23:59, 3 September 2015 (UTC)

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 04:39, 5 August 2015 (UTC)
  2. Symbol support vote.svg Support, with the understanding that this restriction on bots' edits applies only to the part of a page that a bot edits and not to the entire page.​—msh210 (talk) 14:15, 5 August 2015 (UTC)
    OK, I was thinking about that too, when I edited the page. Sorry if this is not too clear in the policy yet, the text can be amended later with this point. --Daniel Carrero (talk) 18:18, 5 August 2015 (UTC)
    If all (or sufficiently many people) supporters specify such a qualifier on their respective votes, as you and I just did, and the vote passes, then the vote should be said to pass (and policy be effected) with that qualifier, even if the text of the policy page doesn't reflect it.​—msh210 (talk) 21:21, 5 August 2015 (UTC)
  3. Symbol support vote.svg Support. — Ungoliant (falai) 18:53, 5 August 2015 (UTC)
    Do you intend that the restriction on bots in NORM apply only to the part of a page that a bot edits and not to the entire page, Ungoliant?​—msh210 (talk) 21:21, 5 August 2015 (UTC)
    I don’t care. I’m more pleased with how this will affect human editors. — Ungoliant (falai) 21:30, 5 August 2015 (UTC)
  4. Symbol support vote.svg Support and also support Msh210's qualifier. —Μετάknowledgediscuss/deeds 22:08, 5 August 2015 (UTC)
  5. Symbol support vote.svg Support with msh210's qualifier. Re Dan Polansky's concern about "No leading or trailing whitespace in templates (name, parameter name and value), links, categories and so on" (WT:NORM#Whitespace and characters 4), I take that to be a regulation equivalent to WT:NORM#Categories and interwikis 4, but with broader application (so that it prohibits, for example, usage like {{ en-noun | head= noun }}, prescribing instead usage like {{en-noun|head=noun}}); @Daniel Carrero, can you confirm or correct my interpretation, please? Given that this policy document is intended to regulate entries, I would think that a stricture concerning the wikicode of templates would be ultra vires. — I.S.M.E.T.A. 15:50, 24 August 2015 (UTC)
    Some context:
    @CodeCat is the one who added the rule in the policy, initially written as No leading or trailing whitespace in templates (name, parameter name and value), links, categories and so on. For templates, newlines are allowed for clarity. (diff) Later, I asked about the part For templates, newlines are allowed for clarity. in the Poll 7, but five out of six people abstained and asked for more information, including myself, and the sixth person (@ObsequiousNewt) seemed to apply the rule to the source code of templates themselves, mentioning two Ancient Greek templates with different formatting. So I removed this last bit, (moved to Wiktionary talk:Normalization of entries#Removed items) though I admit I could have copied the entire rule when making the poll, for more clarity, or just removed the entire line from the policy until further discussion.
    Replying your question:
    Anyway, yes, you are correct in saying: "so that it prohibits, for example, usage like {{ en-noun | head= noun }}, prescribing instead usage like {{en-noun|head=noun}}."
    That said, WT:NORM does not attempt to regulate the source code of the templates themselves. But the policy does attempt to regulate how the templates are called in entries. --Daniel Carrero (talk) 17:06, 24 August 2015 (UTC)
    @Daniel Carrero: Thanks for the context and confirmation; and thank you, Dan Polansky, for your clarification. I myself dislike and do not use {{quote-book}}; however, the line breaks certainly do aid readability, and as such I would support allowing their use as an exception to the no-leading-or-trailing-whitespace regulation. — I.S.M.E.T.A. 02:40, 25 August 2015 (UTC)
    I was thinking, I also support, as you said, allowing their use as an exception to the no-leading-or-trailing-whitespace regulation. --Daniel Carrero (talk) 14:43, 25 August 2015 (UTC)
  6. Symbol support vote.svg Support --Vahag (talk) 09:07, 27 August 2015 (UTC)

Oppose

Abstain

  1. Symbol abstain vote.svg Abstain --Dan Polansky (talk). I suspect there is something I won't like when I see it applied but will not notice before. One thing suspect is this: "No leading or trailing whitespace in templates (name, parameter name and value), links, categories and so on"; I think it forbids template parameters to be on multiple lines since a newline before a new parameter is a trailing whitespace in template parameter value, and I am not sure people really want to have each template marked up on a single line as a result, especially {{quote-book}}. There may be other issues. None of this is bad enough for me to oppose at this point, I guess. --Dan Polansky (talk) 10:36, 23 August 2015 (UTC)
    To clarify, the following seems to be forbidden by the wording of WT:NORM#Whitespace and characters, item 4 ("No leading or trailing whitespace in templates (name, parameter name and value), links, categories and so on."):

    #*{{quote-book|year=1899|author={{w|Stephen Crane}}
    |title=[[s:Twelve O'Clock|Twelve O'Clock]]|chapter=1
    |passage=There was some laughter, and Roddle was left ...}}

    It is because the newlines that enable the title and passage to start on a new line are trailing whitespace. From browsing the dump, I see that placing the passage on a new line seems rather common. --Dan Polansky (talk) 18:46, 24 August 2015 (UTC)

Decision


Clarify exclusion of companies

  • Voting on: Clarification of Wiktionary:Criteria for inclusion#Company names to say more precisely what we mean by companies not being allowed.
    Company names
    Regardless of attested use, commercial businesses such as American Airlines are not included as definitions.
    Exceptions to this rule are made for:
    • Fictional companies, which must still meet the requirements under “Fictional universes”.
    • Certain nicknames including abbreviations used outside of the industry without reference to the full name, such as Mickey D's or HP (for Hewlett-Packard).
    A term may also be allowed if it has a meaning apart from the business. This could include its sense as the signature product of the company if attested under other criteria, for example the Atari brand name.
  • Vote started: 00:00, 8 August 2015 (UTC)
  • Vote ends: 23:59, 6 September 2015 (UTC)

Support

  1. Symbol support vote.svg Support This doesn't effectively change existing policy much, not as it's practiced, but it does make that practice clearer. DAVilla 23:56, 8 August 2015 (UTC)
  2. Symbol support vote.svg Support Equinox 11:45, 9 August 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose This cements the Wiktionary:Criteria for inclusion#Company names into CFI, a section with no consensual support. It confirms that companies should be basically excluded, even those having single-word names such as Pfizer, which can host etymology and pronunciation. Companies are specific entities. No one has as yet explained why companies should be regulated differently from other specific entities, which are regulated in WT:CFI#Names of specific entities. No one has explained why small villages can be included but large companies must be excluded. Like, is it because they are relatively transitory or short-lived? Or is it because they represent commercial interest and we fear we are doing advertising for them (very implausible to me)? Let me note that not all companies are using their names as brands for their products; pharmas, for instance, use specific brand names for their specific products, and thus, WT:BRAND does not protect such company names. It should be also said that WT:BRAND is over-exclusionist, leading to removal of lexicographical content for reasons not specified anywhere, AFAIK. For reference, a related vote is Wiktionary:Votes/pl-2012-02/CFI and company names. --Dan Polansky (talk) 08:19, 8 August 2015 (UTC)
    Yes, it's because we fear opening the floodgates to advertising for the commercial interests they represent. Read the opposing comments in your vote, which I supported by the way.
    This doesn't really change existing policy, so I don't understand your rationale for voting against. If anything, it sets up a framework where we can consider other exceptions, which I would be more than willing to entertain here. Pfizer may not be the best example because pronunciation can be added for the family name.
    Our brand name policy is highly exclusionist because that's what the community supports. If you remember, it had to be modified several times before it was accepted. DAVilla 00:04, 9 August 2015 (UTC)
    The advertising argument does not hold water in the slightest. To take my example Pfizer, it would have a definition consisting of a small number of words, possibly "an American multinational pharmaceutical corporation headquartered in New York City, New York", which I took from Wikipedia. By contrast, the company has Wikipedia article W:Pfizer of much larger scope. Of course, Wikipedia does not remove companies to avoid representing commercial interest; it tries to take care that they do not become promotional, with varying success. Wikipedia's risk of failing to ensure articles do not become promotional is many times higher than the risk Wiktionary has: we only have to take care of the definition, and ensure that it does not become promotional.
    As for not changing policy, that is not really true. Current "policy" was entered into CFI by you without a vote, and as a consequence, it carries relatively little weight. If this vote passes, there will be a voted, real policy, which of course will have a lot of weight.
    As for reason for exclusivenes of BRAND, "because that's what the community supports" is not a reason, it is a cause: I have not seen any rationale presented by supporters of BRAND. --Dan Polansky (talk) 14:11, 9 August 2015 (UTC)
    As for "Read the opposing comments in your vote": Wiktionary:Votes/pl-2012-02/CFI and company names does not contain the words "commercial" or "commerce", and there is very little of any argument coming from the opposers at all. The following votes there have a comment that is more than empty or redirecting and thus can contain an argument: Liliana, msh210, and Ruakh. In none of the three votes do I find an explanation why having single-word company names in Wiktionary is a bad thing. --Dan Polansky (talk) 14:21, 9 August 2015 (UTC)
  2. Symbol oppose vote.svg Oppose It's nonsensical to allow the names of fictional companies and not allow the names of real ones. In general, I would support liberalising this dictionary's somewhat strict policy on company names – although I gather there has been a significant amount of discussion on this issue in the past, which I probably should read before commenting further. This, that and the other (talk) 09:36, 9 August 2015 (UTC)
    Re: "I gather there has been a significant amount of discussion on this issue in the past": I don't think so. There was some discussion in the vote I mentioned, but there is very little of substance to be found anywhere, as far as I know. The part of CFI on company names has never passed a vote, and its supporters have never explained why keeping single-word company names is a bad thing, except perhaps one editor who says that company names are not words (as per Wiktionary:Votes/pl-2012-02/CFI_and_company_names), and that "place-names", given names and surnames are not words either (as per Wiktionary:Votes/pl-2010-05/Placenames with linguistic information 2). --Dan Polansky (talk) 10:25, 10 August 2015 (UTC)
  3. Symbol oppose vote.svg Oppose Company entries can contain useful etymology and pronunciation. I see no reason to have different criteria for inclusion for brands and company names. The given example is bad since American Airlines is both a company name and a brand (it is used when marketing flights). A better example would be Berkshire Hathaway or Goldman Sachs. They would pass CFI if they were product brands or place names, and I see no reason for excluding them. --Tweenk (talk) 22:22, 12 August 2015 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain I think the criteria need to be changed more generally. Company and brand names are words, and should be included. However, it's not up to us to define them. So my own proposal is to allow entries, but their only definition would be a Wikipedia link and no further information on the company, brand or product should be given. Etymologies can be allowed. —CodeCat 14:32, 9 August 2015 (UTC)
    A short description on a definition line can be made very succinct and non-promotional. The genus should be stated, e.g. company, corporation or the like. And there should be some differentia. Pfizer can be made as short as "an American multinational pharmaceutical corporation"; beyond the fact that it is a corporation, it states its branch of business, the country of the headquarters and that it is multinational. I can't see how that harms or promotes anything. If that is considered too long, even "a pharmaceutical corporation" would be acceptable, IMHO: state that it is a corporation and state the branch of business. --Dan Polansky (talk) 10:39, 10 August 2015 (UTC)
    I agree with this. --Tweenk (talk) 22:22, 12 August 2015 (UTC)
    The "genus" of companies, and what they do, make, cover, etc. changes a lot more than the meaning of words. One business takes over another every day; for example, Google has just formed a parent company called Alphabet. So definitions would be tedious and soon outdated. Equinox 23:24, 12 August 2015 (UTC)
    The definition of "Google" as "multinational information technology company originating in the Silicon Valley" would not need changing in that case, and Alphabet would not pass CFI yet. --Tweenk (talk) 10:40, 14 August 2015 (UTC)
  2. Symbol abstain vote.svg Abstain Company names should be allowed. I find especially interesting cases when English and FL names (specifically Chinese) are completely different, such as Acer and (a deleted entry) 宏碁宏棋 (Hóngqí). --Anatoli T. (обсудить/вклад) 01:26, 13 August 2015 (UTC)

Decision


Dominic for de-sysop

  • Voting on removing sysop powers from User:Dominic, who hasn't been here for a couple of years. --A230rjfowe (talk) 21:42, 8 August 2015 (UTC)
  • Vote started: 00:01, 9 August 2015 (UTC)
  • Vote ends: 00:01, 23 August 2015 (UTC)

Support

Oppose

Abstain

  1. Symbol abstain vote.svg Abstain. Note: This vote is currently listed at WT:VOTE and was listed there since 8 August 2015 (diff). This vote does not seem to have any Beer parlour thread created for it. The "premature" box was removed from the vote on 8 August 2015 (diff). Dan Polansky (talk) 10:16, 23 August 2015 (UTC)

Decision


Templatizing usage examples

  • Voting on: Templatizing the markup for usage examples in the mainspace. Thus, giving a full go ahead to all automatic and semiautomatic edits that replace the likes of
    #: ''This is a '''usage''' example.''
    with
    #: {{usex|lang=en|This is a '''usage''' example.}},
    #: {{ux|en|This is a '''usage''' example.}}
    or similar.
  • See also {{usex}}, {{ux}}, WT:ELE#Example sentences, and Wiktionary:Example sentences.
  • Rationale: See Wiktionary talk:Votes/pl-2015-08/Templatizing usage examples#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote started: 00:00, 17 August 2015 (UTC)
  • Vote ends: 23:59, 18 November 2015 (UTC)

Support

Oppose

Abstain

Decision


User:TweenkBot for bot status

  • Nomination: I hereby request the Bot flag for User:TweenkBot for the following purposes:
    Replacing obsolete templates with regex: [3] [4]
    Disambiguating animacy in Polish masculine nouns: [5] [6] - this is a semi-automated task where the script displays the word with some context, and I enter the animacy for each word.
    Both tasks would be done with pywikibot, the first with replace.py and an interactive function in user-fixes.py, the second with plain replace.py (the -regex and -transcludes options).
    Tweenk (talk) 21:40, 12 August 2015 (UTC)
  • Vote started: 00:01, 18 August 2015 (UTC)
  • Vote ends: 23:59, 25 August 2015 (UTC)

Support

  1. Symbol support vote.svg Support - -sche (discuss) 17:28, 17 August 2015 (UTC)
  2. Symbol support vote.svg Support on the condition that (1) the bot will heed WT:BOT, especially the part "I will ask around for consensus, perhaps at the Beer parlour, or I will make sure that the task is so innocuous that no one could possibly object", and (2) that the bot will lose the bot flag when someone objecting to the bot creates a vote to confirm the bot in the bot status and the vote does not achieve consensus; I oppose enbotting of bots that cannot then be easily debotted. Nothing personal; I have no issue with the bot operator although I do not really know him. As for en wikt practice regarding conditional supports, see e.g. Wiktionary:Votes/pl-2015-07/Normalization of entries 2. --Dan Polansky (talk) 10:24, 23 August 2015 (UTC)
  3. Symbol support vote.svg Support Sorry this is late; based on the above statements about pywikibot as well as other evidence, this user seems to know what they're doing. Benwing2 (talk) 08:38, 27 August 2015 (UTC)
  4. Symbol support vote.svg Support --Vahag (talk) 09:03, 27 August 2015 (UTC)
  5. Symbol support vote.svg SupportAɴɢʀ (talk) 11:01, 27 August 2015 (UTC)
  6. Symbol support vote.svg Support - useful edits, very repetitive and dull for human editors. --A230rjfowe (talk) 17:52, 27 August 2015 (UTC)
  7. Symbol support vote.svg SupportUngoliant (falai) 17:57, 27 August 2015 (UTC)

Oppose

Abstain

Decision


Reconstructions need references

  • Voting on:
    Letting appendix pages on reconstructed protoforms (e.g., *h₂ŕ̥tḱos) be allowed only if they have references to sources (scholarly work) that
    a. give the exact form, or
    b. provide evidence that supports that form (e.g., sound changes that would create it).
    Appendix pages on reconstructed protoforms that remain unreferenced after a certain amount of time was given for references to be added should be deleted.
  • Rationale: See Wiktionary talk:Votes/2013-10/Reconstructions need references#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote starts: 00:01, 30 August 2015 (UTC)
  • Vote ends: 23:59, 30 September 2015 (UTC) or later

Support

Oppose

Abstain

Decision


Allowing matched-pair entries

  • Rationale (edited from the first message in this July 2015 discussion):
    1. (repetition) With separate entries ( and ), most definitions tend to be repeated: sometimes, the left side sense is "Begins X" and the right side sense is "Ends X", thus requiring one to check two separate pages to see definitions for the same thing; also, "begins" and "ends" makes it a bit longer to read, especially when these two words are present in almost all senses in the two pages.
    2. (consistency) With two almost identical entries, editing one entry often requires editing the other for consistency. One example of inconsistency (although easy to be fixed) is that as of August 27, 2015, { has a sense that } doesn't.
    3. (lexical unit) Arguably, since in most senses, you can't use one parenthesis without the other, they are together only one lexical unit.

Disclaimers:

  • This vote does not intend to decide what exactly to do with separate-part entries such as ( or ). One possibility would be deleting all repeated content which can be found on matched-pair entries.
  • This vote does not intend to decide what exactly is the format for the matched-pair entries. At least four different formats have been discussed: ( ), (), ( ... ) and (...).
  • Any of the entries used as examples above can undergo RFD and RFV normally, voting here does not mean endorsing any of those entries in particular, just the format of matched-pair entries.

Known issue:

  • Some punctuation marks are used in vertical writing, such as and (vertical parentheses) and some CJK punctuation. Until further discussion, any vertical punctuation is considered outside the scope of this vote. In other words, even if this vote passes it does not mean that we should create a single entry for those such as ⏜ ⏝, which could be unsighthly and problematic if it just uses this format without being adjusted in any way. Similarly, pieces of the same symbol such as , , , , and (parentheses pieces) are left outside of the scope of this vote as well.

Schedule:

  • Vote started: 00:00, 3 September 2015 (UTC)
  • Vote ends: 23:59, 2 October 2015 (UTC)

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: