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

Planned and running votes
Disallow typographic punctuation in policies
Typographic vs ASCII punctuation in policies
User:RileyBot
User:NjardarBot for bot status
Japanese Romaji romanization - format and content
Romanization and definition line

Disallow typographic punctuation in policies

  • Voting on: disallowing standard publishing-style typographic punctuation in the text of policy pages, in favour of typewriting-style ASCII punctuation. This includes using typographic apostrophes ( ’ ) in favour of neutral apostrophes ( ' ), single quotation marks ( ‘ ’ ) in favour of neutral apostrophes ( ' ' ), double quotation marks ( “ ” ) in favour of neutral quotation marks ( " " ), en dashes ( – ) and em dashes ( — ) in favour of hyphens ( - ) or doubled hyphens ( -- ), and other such changes. It is anticipated that this vote will set a precedent, to obviate many future votes on insignificant changes to policy pages that may be contested.


  • Vote starts: 00:01, 22 February 2013 (UTC)
  • Vote ends: 23:59, 23 March 2013 (UTC)

Support

  1. Symbol support vote.svg Support Not only are they a big burden, but usage is different across the languages of the world, making it a pain to correctly typeset quotes in foreign languages. It's much easier to just forget about them and use the symbols everyone has on their keyboard. -- Liliana 06:40, 25 February 2013 (UTC)
    I think the vote is referring ("in the text of policy pages") to the running text of policy pages and not examples therein, though I have to say I'm not certain.​—msh210 (talk) 06:55, 25 February 2013 (UTC)
    Usage is different between British and North American English practices, but I’m afraid we have to deal with that with either style of quotation mark glyphs. Michael Z. 2013-02-25 16:38 z

Oppose

  1. Symbol oppose vote.svg Oppose  Our lack of a style guideline is preventing editors from trying to realize good typography, or even consistent typography, in our documents. This vote can be a step forward. Michael Z. 2013-02-24 17:56 z
  2. Symbol oppose vote.svg Oppose. — Ungoliant (Falai) 18:32, 24 February 2013 (UTC)
  3. Symbol oppose vote.svg Oppose. I don't support disallowing either style of quotation mark.​—msh210 (talk) 06:18, 25 February 2013 (UTC)
    Incidentally, the word "changes" in the "Voting on" section makes it seem (to me, anyway) that we're voting on barring emending preexisting words of the policy pages to change typewriter-style marks to typeset-style marks only, and not on barring typeset-style marks in additions to the pages. The first part of the "Voting on" section, on the other hand, sounds like it's referring to any edit to the policy pages. So I can't tell exactly what we're talking about. Either way, though, I oppose.​—msh210 (talk) 06:26, 25 February 2013 (UTC)
    It was intended to mean any edits that introduce typographical-style punctuation, whether they are style changes or additions of new text. Michael Z. 2013-02-25 16:43 z
  4. Symbol oppose vote.svg Oppose. --Prosfilaes (talk) 07:25, 25 February 2013 (UTC)
  5. Symbol oppose vote.svg Oppose. I think that viewing curly vs. straight quotes should be somehow user-configurable for the reader. I don't want to see any particular style enforced for the writer. Equinox 16:51, 25 February 2013 (UTC)
    I don’t think that’s practical unless we switch from typing quotation marks to using HTML <q> tags.[1] This is an interesting idea for other reasons, but I can’t imagine any reader actually bothering with such an option. Do you know of any websites that successfully offer this? Michael Z. 2013-02-25 17:05 z
    I don't. But we, for example, support serial comma/Oxford comma with the {{,}} notation. Equinox 17:07, 25 February 2013 (UTC)
    We don’t support it in our writing (for fun, add {{,}} to all of our policy pages), and I can’t find any docs or interface for it. We also have some horrendous stuff to do with brackets and declension tables that puts in redundant content and hides some of it with CSS, which I have to get around to removing. Good, consistent writing that doesn’t distract readers is much more valuable than complicated widgets that do. Michael Z. 2013-02-25 18:42 z
  6. Symbol oppose vote.svg Oppose Ƿidsiþ 17:01, 25 February 2013 (UTC)
  7. Symbol oppose vote.svg Oppose this vote. However, I oppose unvoted-on quote-style-switching edits to policies. Currently, policies use a mixture of styles of quotations marks. --Dan Polansky (talk) 17:11, 25 February 2013 (UTC)
  8. Symbol oppose vote.svg Oppose —Stephen (Talk) 06:32, 21 March 2013 (UTC)

Abstain

Decision

Fails 1–8–0. Thus, standard publishing-style typographic punctuation isn't disallowed in the text of policy pages in favor of typewriting-style ASCII punctuation.​—msh210 (talk) 07:33, 4 April 2013 (UTC)


Typographic vs ASCII punctuation in policies

I prefer ASCII over typographic

  1. Symbol support vote.svg Support  - I don't even know how to type in "Typographic" SemperBlotto (talk) 17:49, 24 February 2013 (UTC)
    w:Quotation_marks#Typing_quotation_marks_on_a_computer_keyboardMichael Z. 2013-03-07 23:06 z
  2. Symbol support vote.svg I'm not sure what "Voting on: Whether to use typographic or ASCII punctuation in policy pages" means, but I prefer old-fashioned 7-bit quotation marks and apostrophes over the other style, which is what this section indicates I'm choosing.​—msh210 (talk) 03:45, 27 February 2013 (UTC)
  3. Symbol support vote.svg Support Additionally although it's far less frequent these days some computers still don't support the typographic ones. Not to mention, I prefer the old-fashioned ones too. --Neskayagawonisgv? 22:18, 7 March 2013 (UTC)
    You rocking an abacus? Incidentally, it’s the dumb quotes that are new-fangled. They were invented in the nineteenth century to save typewriter keys.  Michael Z. 2013-03-07 23:06 z
  4. Symbol support vote.svg SupportInternoob 23:18, 7 March 2013 (UTC)
  5. Symbol support vote.svg Support -- Liliana 21:49, 19 March 2013 (UTC)
  6. Symbol support vote.svg Support —This unsigned comment was added by Mglovesfun (talkcontribs). [2]

I prefer typographic over ASCII

  1. Symbol support vote.svg Support  I guess. There’s a substantial difference between “whether to use” and “I prefer,” and it’s unclear what the result of this vote means. I certainly wouldn’t support this if it means anyone is prevented from making edits with only the characters available on their keyboard. Michael Z. 2013-02-24 17:47 z
  2. Symbol support vote.svg Support. — Ungoliant (Falai) 18:30, 24 February 2013 (UTC)
  3. Symbol support vote.svg Support. It's not that hard to enter these punctuation, and even less hard to leave them alone when someone else makes the change.--Prosfilaes (talk) 07:24, 25 February 2013 (UTC)
  4. Symbol support vote.svg Support Ƿidsiþ 08:07, 27 February 2013 (UTC)
  5. Symbol support vote.svg Support --Vahag (talk) 08:41, 16 March 2013 (UTC)
  6. Symbol support vote.svg Support —Stephen (Talk) 06:34, 21 March 2013 (UTC)

Oppose this vote

Abstain

Decision

By a vote of 6–6–0, I both prefer ASCII over typographic and prefer typographic over ASCII.​—msh210 (talk) 07:30, 4 April 2013 (UTC)


User:RileyBot for bot status

  • Vote ends: 23:59 24 February 2013 (UTC)
  • Vote started: 23:24, 17 February 2013 (UTC)

Support

  1. Symbol support vote.svg Support. The bot has been doing a great and, in my opinion, important job. — Ungoliant (Falai) 15:46, 22 February 2013 (UTC)
  2. Symbol support vote.svg Support. every 6 hours. —Stephen (Talk) 17:45, 22 February 2013 (UTC)

Oppose

  1. Symbol oppose vote.svg I don't see the point. Neither is edited very often. Moreover, even if they are at some point in the future (and we can write a bot then if we wish so certainly don't need one now), we can let them be unemptied: why would we need to empty them periodically?​—msh210 (talk) 07:16, 18 February 2013 (UTC)
    Well there are several reasons but the main point is; if you were a new user: would you like to be directed to a blank page or a page full of junk? Or: Would you like to be told to go edit at a sandbox but since the header is missing which includes the link to "How to edit a page", you don't know how to edit? Either way, this is a simple task that doesn't require a lot of edits. No harm in my mind. :) -Riley Huntley (SWMT) 06:45, 21 February 2013 (UTC)
  2. Every hour is much too frequent. I would support it running once per day. SemperBlotto (talk) 15:47, 22 February 2013 (UTC)
    Once per day is not frequent enough, it almost ruins the purpose. How about every 2 hours or 3? Maybe even 6? -Riley Huntley (SWMT) 19:26, 22 February 2013 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain  It can run as often as you want, but only clean up if the page has been left idle for at least a couple of hours. I can see someone leaving a tab open and coming back to it after being distracted by real life for much of an afternoon. Michael Z. 2013-02-28 16:46 z
  2. Symbol abstain vote.svg Abstain Same reason as what Michael has stated. I can see how this can be vexing for newbies testing stuff out in the sandbox. JamesjiaoTC 23:46, 1 March 2013 (UTC)

Decision

It looks like there's ample support for a bot of this nature, but no agreement on its parameters. This vote fails (technically 1–3 for hourly, which was the proposal, and there's no clear alternative frequency favored by the voters, so I can't pass any one such), but I do think that a later vote that takes into account this vote's voters' views will pass. Perhaps the bot owner should straw-poll us in the Beer parlour first.​—msh210 (talk) 06:26, 3 March 2013 (UTC)


User:NjardarBot for bot status

  • Nomination: I hereby request the Bot flag for User:NjardarBot for the following purposes:
    Creating inflected forms of Norwegian Nynorsk verbs, nouns and adjectives; with my script being an extension of the standard Pywikipedia library.
Proof that it does not mess up existing entries: "sett", "hugs" and "et". See Special:Contributions/NjardarBot for all entries created.
  • It is run only semi-automatically, as I have no interest in cleaning up dozens of erroneous entries. I usually select one word at a time; but as my confidence in my script increases, I'll probably let it handle smaller lists.
  • CV:
    In 2008 I created more than 1000 asteroid entries on the Nynorsk Wikipedia (sample: 422 Berolina), and also around 1000 on the Bokmål Wikipedia on request (sample: 542 Susanna, the template has since changed)
    It is a global bot and has over 145 000 edits globally, interwiki or otherwise.

--Njardarlogar (talk) 16:18, 22 February 2013 (UTC)

  • Vote ends: 23:59 8 March 2013 (UTC)
  • Vote started: 16:18, 22 February 2013 (UTC)

Support

  1. Symbol support vote.svg Support  Michael Z. 2013-02-28 16:42 z
  2. Symbol support vote.svg SupportCodeCat 16:47, 28 February 2013 (UTC)
  3. Symbol support vote.svg Support JamesjiaoTC 23:43, 1 March 2013 (UTC)
  4. Symbol support vote.svg Support. — Ungoliant (Falai) 21:23, 8 March 2013 (UTC)

Oppose

Abstain

Decision


Japanese romaji romanization - format and content

  • Voting on: Constraining the content of romaji entries. In particular:
    1. A headings that, for an English entry, usually contains a part of speech should, for romaji entries, be "Romanization" rather than a part of speech. These are level 3 headings.
    2. In each romaji entry, there should only be cross-reference links output by a template. Examples would look like "# See: ちゅうけい" or "# Romanization of ちゅうけい".
    3. In each romaji entry, there should be no glosses following the links. Thus, chūkei, would look like "# See: ちゅうけい" or "# Romanization of ちゅうけい", rather than "# See: ちゅうけい: delay; abbreviation of relay broadcast; ceremonial folding fan; younger of two elder brothers".
The ultimate goal is that each Japanese romaji entry will be no more than a cross-reference to the corresponding hiragana, katakana, or mixed-script forms. This is intended to allow for easier automatic generation of romaji entries, and to eliminate the maintenance overhead required in the past whenever a gloss or other information was added to a romaji entry but not to the corresponding kana entry, or vice versa.
  • A typical example, this proposal only affects romaji entries, which had the same information as in hiragana entries:
  1. romaji: dentaku (links to でんたく), no definition) - a disambiguation entry (here, only one kana equivalent exists)
  2. hiragana: でんたく (links to 電卓 (or any other kanji with the same hiragana reading) with PoS and short definitions); no link if the term is only written in hiragana.
  3. kanji: 電卓 - a complete entry
  • Vote starts: 00:01, 30 March 2013 (UTC)
  • Vote ends: 23:59, 28 April 2013 (UTC)

Support constraining romaji entries

  1. Symbol support vote.svg Support --Anatoli (обсудить/вклад) 03:48, 30 March 2013 (UTC)
  2. Symbol support vote.svg Support --Haplology (talk) 13:10, 30 March 2013 (UTC)
  3. Symbol support vote.svg Support --Ultimateria (talk) 13:15, 30 March 2013 (UTC)
  4. Symbol support vote.svg Support just to add my support, even though I am tempted to boycott like Angr. —Μετάknowledgediscuss/deeds 17:45, 31 March 2013 (UTC)
    Symbol support vote.svg Support (voting due to tactical considerations). - -sche (discuss) 21:25, 8 April 2013 (UTC) - -sche (discuss) 18:28, 17 May 2013 (UTC)

Oppose constraining romaji entries

  1. Symbol oppose vote.svg Oppose We have two formats of romanization entries to serve as a precedent, Chinese and Gothic. Creating a third format without any reason is a thoughtless disregard for the readability of this reference. How can editors argue that this is so thoroughly designed and call a vote about “format” while refusing to explain its essential form? And who uses a colon to write a two-word imperative statement? Michael Z. 2013-04-02 15:28 z
    Michael. Pinyin, Gothic and Romaji were all developed independently and they don't even belong to the same supercategory (like "Romanizations by language") and I don't know if they ever could. As I explained multiple times, pinyin entries can't have a limited number of parameters because of homophones. The choice of the word "See" was a result of a consensus of JA contributors, my opinion on whether we should use Romanization of (Gothic), See (Romaji) and nothing (Pinyin) is weak but why should we follow Gothic if Japanese may have several lines of Romanization of, which will look ugly. We ended up having See but I don't know anything about how Gothic standards came up to be so. There are inconsistencies in Gothic romanisation entries. Template:ja-romaji doesn't allow such inconsistencies.
    We don't have to stick to formats of Chinese and Gothic. Gothic and Pinyin examples were only used in the discussion to show that romanisation entries can serve as links, they are not meant to have definitions, and not as a means to stop the work on the Japanese romaji. There's perfect readability of both the result and the code and it's very to use.
    I have removed the colon after See.
    Re: "...while refusing to explain its essential form...". Please clarify what is still not clear.
    Re: "..call a vote about “format”". The name of the vote was chosen by Dan Polansky.
    You seem to have jumped from tentative support to opposition (if I understand correctly). As you yourself pointed out Wiktionary:ELE#Definitions doesn't say must have definitions. Is it because we still use the wording "See" despite your protest? --Anatoli (обсудить/вклад) 04:56, 3 April 2013 (UTC)
    Yes, I am opposing this just because the design/copywriting details don’t appear to be thought through. We don’t have to stick to, e.g., the Gothic format, but if we diverge from it then we should articulate some reason justifying it.
    How many links can a romaji entry have? I was under the impression that it is only one or up to two, for katakana and hiragana. Michael Z. 2013-04-03 14:19 z
    What is "copywriting details"? The design was thought, discussed and agreed on. Where were you? The reasons are already articulated many times. What has Gothic to do with Japanese? I didn't know Gothic romanisation entries exist before I was told. But what is different? Wording? Originally we had Hiragana: or Katakana:, then we changed to See: to allow for mixed scripts (hiragana/katakana/Roman letters, numerals). The definition line question was already explained. Gothic romanisation could be done the same way as Japanese with less parameters.
    Maximum 6. "zu" has 4 links. Combinations like ああ, あー, アア, あー will all give "ā". Romaji with ō may be linked to hiragana おお, おう, おー, katakana オオ, オウ, オー. Small つ (tsu) - っ may be silent at the end of a word after vowels, thus giving more variants. --Anatoli (обсудить/вклад) 22:31, 3 April 2013 (UTC)
    Yes, copy=wording of the text used in entries, like “Romanization of” vs. “See:” vs. “See”. Now we know about Gothic, and the question of consistency needs to be addressed.
    Where was I? Why? Look, Anatoli, I wasn’t involved in a big conversation about romaji. Now it has become evident that this is relevant to the design of entries in three or more languages, and that it is a controversial edge case not covered perfectly clearly by our guidelines. Don’t imply that I don’t have a right to give my input. We all make an investment here, and I recognize your amazing contribution, but that doesn’t mean any of us owns some part of this project. Michael Z. 2013-04-04 00:50 z
    IMO, this is not "relevant [] to three or more languages" (it only affects Japanese, obviously), and not that "controversial" (note that you are the only editor to vote against the new format). I ask too — where were you? If you had voiced your concerns earlier, it might not be a problem now. You have a right to give your input, but waiting for the vote after much discussion is not as helpful. —Μετάknowledgediscuss/deeds 02:17, 4 April 2013 (UTC)
    A new design pattern being implemented for romanization entries does not only affect Japanese. This vote came up and I chose to participate in it. I voiced my concerns as soon as I became aware and informed about the issue. Michael Z. 2013-04-07 17:47 z
    You seem to be either misled or misleading, but I can't tell which. "A new design pattern being implemented for romanization entries" describes WT:V#Romanization and definition line perfectly, but this is a different vote. This one is just about Japanese. —Μετάknowledgediscuss/deeds 18:18, 7 April 2013 (UTC)
    That vote is about wikitext. It doesn’t affect the design of the entries at all. Michael Z. 2013-04-07 19:06 z
    I meant that you can't say it wasn't thoroughly thought if the discussion lasted a month before a consensus and a decision was made in a very visible area. You criticise me for some implications but what are you implying? That we should consult Dan Polansky and yourself before making any change in any language because you don't take part in the discussion and language policy pages like WT:AJA are not on your watchlist? A decision on individual type of entries such as romanisation is not a common thing, so we didn't have a standard on how design them. They don't belong to any common category and exist independently.
    Having said this, I took the liberty and changed {{got-romanization of}} to display See and suggested to CodeCat to use a similar format to romaji where a definition line is generated by the template. We'll see if there is any negative reaction. I still don't get it why it should be dependent on Gothic or other languages. Pinyin, Gothic and Romaji existed independently for a long time and nobody cared. --Anatoli (обсудить/вклад) 01:27, 4 April 2013 (UTC)
    No you don’t have to consult Dan Polansky and me about everything. Likewise, I am not obligated to read every single Beer Parlour discussion in realtime, or to stay out of discussions if I have not.
    I am glad to see consideration being given to harmonizing these romanization templates. Michael Z. 2013-04-07 17:47 z
  2. Symbol oppose vote.svg Oppose It appears that this new format caused an admin to block the Autoformat bot because it violates WT:ELE regulations. That is completely unacceptable, we need that bot. As such, I cannot accept this change. -- Liliana 14:27, 8 April 2013 (UTC)
    Arrowred.png @Liliana, I'm afraid I don't understand -- the Autoformat bot was violating WT:ELE? The format of {{ja-romaji}} violates WT:ELE? It's unacceptable that the bot was blocked? It's unacceptable that the bot or the template violates WT:ELE?
    And what precisely do you oppose -- the simplification of romaji entries in general? Or the current format of {{ja-romaji}}?
    It's also not entirely clear whether {{ja-romaji}} violates WT:ELE. CodeCat and I have been going back and forth about that a bit recently; I suspect the problem is partly that the writing in WT:ELE allows for more than one interpretation. -- Eiríkr Útlendi │ Tala við mig 21:44, 8 April 2013 (UTC)
I have already explained to Liliana-60 that the Autoformat is still running and romaji entries don't get picked up by it because they don't violate the format. Liliana-60 doesn't seem to pay attention to answers. No admin has blocked the Autoformat bot, to my knowledge. Are you implying that one of the JA developers did it? --Anatoli (обсудить/вклад) 23:00, 8 April 2013 (UTC)
  • @Anatoli, I think that Liliana was referring to User:KassadBot. See my comment below -- KassadBot's behavior changed some time yesterday, at which point KassadBot started mass-tagging Japanese romaji entries with {{defn}} until -sche blocked the bot. -- Eiríkr Útlendi │ Tala við mig 23:08, 8 April 2013 (UTC)

Arrowred.png I'm also very concerned by an apparent change yesterday (2013-04-07) to KassadBot's programming that specifically targets all entries using {{ja-romaji}}, adding {{defn}} notices.

This is a particularly troublesome change for a number of reasons:

  1. KassadBot did not previously analyze these entries as problematic.
    I suspect this was due to how KassadBot was programmed, and the kind of markup that KassadBot was analyzing. Depending on various parameters, bots can view the raw wikitext (same as what an editor sees), or expanded wikitext (an intermediary format, after templates are transcluded in; similar to manually subst-ing all the templates), or final HTML, among other possible formats. (See Special:ApiSandbox to poke around, if you're interested). Viewing the expanded wikitext would result in KassadBot seeing separate def lines, each starting with #, as produced by the template; viewing the raw wikitext would result in KassadBot seeing no def lines, as the template's effects are only visible once expanded.
    Since nothing changed in the format of {{ja-romaji}}, KassadBot's programming must have been adjusted.
  2. We're in the middle of two different votes related to the format of Japanese romanization entries, and the format output by {{ja-romaji}}.
    Both of these votes include discussion about whether we need a separate line with a separate template call, or whether it's acceptable to have the template do that. Changing bot behavior with regard to this issue before the votes conclude is bad form, and could be viewable as either a willful nuisance or an attempt at strong-arming.
  3. The crux of this issue appears to be WT:ELE.
    Some editors are of the opinion that WT:ELE lays out strict requirements for separate lines in the wikitext starting with #, while other editors have made the point that WT:ELE doesn't actually say that this is a requirement. But again, changing bot behavior while these discussions are ongoing is not appropriate.

I'd like to thank -sche for blocking KassadBot until these votes and discussions can be sorted out. -- Eiríkr Útlendi │ Tala við mig 22:12, 8 April 2013 (UTC)

Did -sche really do it? If he did, was it to accommodate romaji entries? I don't think KassadBot would get romaji entries as badly formatted. We had one single instance, if you remember, when the template had * instead of # on a new line. --Anatoli (обсудить/вклад) 23:06, 8 April 2013 (UTC)
See Special:Contributions/KassadBot. -- Eiríkr Útlendi │ Tala við mig 23:08, 8 April 2013 (UTC)
I see. Thank you, Eirikr. I missed that development. So there may be some messing with KassadBot to undermine this project? Can we see if there was any change to coding or is it invisible? --Anatoli (обсудить/вклад) 23:21, 8 April 2013 (UTC)
  • Bots run based on client-side code, so any changes to bot code would be invisible to everyone except the bot owner. Liliana is KassadBot's owner, so I have asked her about the change in behavior over at User_talk:Liliana-60#Japanese_romaji.
It's possible that KassadBot depends on other code, such that the change in KassadBot's behavior on 7 April might have been due to a change not in KassadBot's own code, but instead in some other code that KassadBot calls. I have no idea if this is the case, but it is a possibility, so I have asked Liliana about that too. -- Eiríkr Útlendi │ Tala við mig 18:15, 9 April 2013 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain. Consensus has already been achieved; this vote is superfluous. —Angr 08:02, 31 March 2013 (UTC)
  2. Symbol abstain vote.svg Abstain. This whole thing has been a muddle since shortly after the JA editors arrived at consensus. I'm even muddled about whether it would be better to write here in the ====Abstain==== section, or below in the ====Oppose having this vote==== section. At any rate, it seems like there's already agreement amongst all the folks who might be working on JA romaji entries. Let my post here then count as Symbol oppose vote.svg Opposed to voting on largely settled issues, and Symbol oppose vote.svg Opposed to setting things in stone when discussion and consensus building should suffice (and so far had sufficed).

    @Michael, it sounds like your opposition is to the format of romaji entries, and not to the general idea of reducing romaji entries to limited stub content. Is that a correct interpretation of your comments above? -- Eiríkr Útlendi │ Tala við mig 15:42, 2 April 2013 (UTC)

    Yes, quite. It’s all part of the extended discussion. Michael Z. 2013-04-02 16:04 z
  3. Symbol abstain vote.svg Abstain --Dan Polansky (talk) 20:30, 24 April 2013 (UTC)

Oppose having this vote

  1. Symbol oppose vote.svg Oppose - -sche (discuss) 17:50, 31 March 2013 (UTC)
    Can I vote here as well as above? If we're going to have an unwanted, badly executed vote, it might as well be clear... —Μετάknowledgediscuss/deeds 17:55, 31 March 2013 (UTC)
    I don't see why not. I will find it funny if this vote shows that there's consensus to make a change, yet explicitly rejects codifying that consensus... but (if I may preach to the choir) if this vote establishes some format for romaji entries, it sets that format in stone, such that editors will have to run more time-consuming policy votes any time some detail of romaji formatting needs to be updated. Hence, I reject the idea of voting upon the issue, and prefer to let consensus on a format be reached by discussion. - -sche (discuss) 18:29, 31 March 2013 (UTC)
    @Metaknowledge: I don't know what -sche intended by this section heading, but nothing prevents you from writing "I don't want this vote", "I support the voted-on proposal but I object to having this vote" or the like as part of your support vote. In general, you can write in your vote comment anything that you think is related to what is being voted on. --Dan Polansky (talk) 18:36, 31 March 2013 (UTC)
  2. Symbol oppose vote.svg OpposeΜετάknowledgediscuss/deeds 21:49, 31 March 2013 (UTC)
  3. Symbol oppose vote.svg Oppose Consensus was had, and any who might oppose on this vote should have discussed there first.--Prosfilaes (talk) 06:28, 1 April 2013 (UTC)
  4. Symbol oppose vote.svg Oppose This is becoming ridiculous. Lack of understanding, accusations, unproductive comments. New development - was KassadBot messed with?--Anatoli (обсудить/вклад) 23:08, 8 April 2013 (UTC)

Decision


Romanization and definition line

  • Voting on: Requiring that each romanization entry contain at least one definition line starting with "#" in the wikitext. This revision of chūkei does not contain a definition line in the wiki text and thus fails to meet this requirement. By contrast, this revision of bàndǎotǐ and this revision of afdomjanda do contain a definition line starting with "#", and thus do meet the requirement.

An example of wikitext that does not meet the requirement:

==Japanese==
===Romanization===
{{ja-romaji|ちゅうけい}}

Examples of wikitext that meet the proposed requirement:

==Gothic==

===Romanization===
{{got-rom}}

# {{got-romanization of|𐌲𐌰𐌱𐌰𐌹𐍂𐌰𐌽}}
==Mandarin==

===Romanization===
{{cmn-pinyin}}

# {{pinyin reading of|半導體|半导体}} semiconductor
  • The examples above are informative. The issue being voted on is wholly incorporated in the first sentence fragment ("Requiring… wikitext") after "Voting on".
  • Vote starts: 00:01, 6 April 2013 (UTC)
  • Vote ends: 23:59, 5 May 2013 (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: