Wiktionary:Votes/pl-2015-11/NORM: 10 proposals

NORM: 10 proposals
Voting on:

Proposal 1. Renaming Normalization of entries (WT:NORM).

Renaming Normalization of entries (WT:NORM) into one of the following options, while keeping the old name and shortcut as usable redirects.


 * Option 1. Wiktionary:Entry markup (WT:EM)
 * Option 2. Wiktionary:Entry source code (WT:ESC)
 * Option 3. Wiktionary:Wikicode normalization (WT:WCN)
 * Option 4. Wiktionary:Wikicode style guide (WT:WSG)
 * Option 5. Other name. Specify.

Proposal 2.

Adding the sentence "This applies to the part of a page that the bots edit, not to the entire page." to the introduction of the policy.

Current text:

These norms are mandatory for bots only, so that any changes made by bots must conform to this policy. Editors other than bots can treat these norms as guidelines, while they are encouraged to use this format and correct pages which deviate from it.

Proposed text (the underlined formatting is for purposes of the vote only; the text added to the policy should not be underlined):

These norms are mandatory for bots only, so that any changes made by bots must conform to this policy. This applies to the part of a page that the bots edit, not to the entire page. Editors other than bots can treat these norms as guidelines, while they are encouraged to use this format and correct pages which deviate from it.

Proposal 3. Formatting some mentions of wikicode using.

Current text:


 * 1) No whitespace between = and heading title, i.e. ==English== and ===Noun===, not == English == or === Noun ===.
 * 2) One blank line before the  between language sections.
 * 3) One blank line after the  between language sections.

Proposed text:


 * 1) No whitespace between   and heading title, i.e.   and , not   or.
 * 2) One blank line before the   between language sections.

Proposal 4. Renaming the section "Whitespace and characters" to "General", moving 1 rule to a new section "Templates" and adding two rules about line breaks.

Current text:


 * Whitespace and characters
 * 1) No whitespace at the start or end of a line. Consequently, no lines consisting only of whitespace.
 * 2) Not more than 1 blank line in a row.
 * 3) No tab characters.
 * 4) No leading or trailing whitespace in templates (name, parameter name and value), links, categories and so on.

Proposed text:


 * General
 * 1) No whitespace at the start or end of a line. Consequently, no lines consisting only of whitespace.
 * 2) Not more than 1 blank line in a row.
 * 3) No tab characters.


 * Templates
 * 1) No leading or trailing whitespace in templates (name, parameter name and value), links, categories and so on.
 * 2) Line breaks are not allowed in parameter names.
 * 3) For templates with many or long parameter values, line breaks are allowed at the end of a template's name or a parameter's value, for the purpose of making the wikicode easier to read. Example about :

Proposal 5.

Renaming the section "Categories and interwikis" to "Categories" and moving some information to the section "Interwikis" which already exists.

Current text:

No blank lines between two categories or between two interwikis.
 * Categories and interwikis

Proposed text:

No blank lines between two categories.
 * Categories

No blank lines between two interwikis.
 * Interwikis

Proposal 6. Adding a few rules to WT:NORM concerning contents that should be on their own lines.

Adding to the section "General" (or "Whitespace and characters", should the proposal 4 fail):
 * 1) The template  on its own line.

Adding to the section "Headings":
 * 1) The horizontal rule (,   and.

Current text: One space after "#", "*" and ":" on the start of a line.

Proposed text: One space after,   and   on the start of a line. If multiple of these are combined (e.g. ), the space is placed after all of them, no spaces should be in between.

Proposal 8. Adding this rule to WT:NORM:


 * 1) No multiple spaces in a row.

Proposal 9.

Adding a section "Boxes and images" and editing the "Example entry" accordingly.

1. Adding a section "Boxes and images" with the following text:
 * Boxes and images
 * 1) Each box or image on its own line.
 * 2) No blank lines between two boxes or images, or between a box and an image.
 * 3) No blank lines between a heading and a box or image directly below the heading.
 * 4) One blank line between a box or image and a heading directly below the box or image.

2. Editing the WT:NORM section accordingly:

Noun

 * 1) Noun sense.

Synonyms

 * synonym

Portuguese
(...)

Proposal 10. Deciding whether there should be a blank line before the first language section, if other content (such as ) precedes.

Adding one of these opposite rules to WT:NORM:

Option 1: One blank line between the first language heading and any preceding content.

Option 2: No blank lines between the first language heading and any preceding content.

Schedule:
 * Vote started: 00:00, 15 November 2015 (UTC)
 * Vote ends: 23:59, 14 February 2016 (UTC) (duration: 3 months)


 * Vote created: --Daniel Carrero (talk) 07:19, 1 November 2015 (UTC)

Discussions:


 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 1)
 * (BP) Renaming Wiktionary:Normalization of entries (WT:NORM) → Wiktionary:Entry source code (WT:ESC)
 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 2)
 * NORM vote (Support section)
 * [[Image:Wikt rei-artur3.svg|20px]] (proposals 3, 5 and 7)
 * Changes made at Special:PermanentLink/35297129 and reverted per (BP) Restoring WT:NORM
 * (proposal 7) (2006 discussion) 27. One space after "#"
 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 4)
 * NORM vote (Abstain section)
 * (BP) WT:NORM and multiple spaces, tabs and indentation
 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 6)
 * (NORM talk) Things that should appear on a line by themselves (this one also affected other proposals)
 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 8)
 * (Thread) MewBot and spaces
 * (NORM talk) Collapse multiple spaces into one space
 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 9)
 * (BP) Poll 6 (about the blank line between "right-aligned content" and the next heading)
 * (BP) Poll 16 - Comments
 * [[Image:Wikt rei-artur3.svg|20px]] (proposal 10)
 * (2006 discussion) 1. No whitespace before first language heading
 * (Thread) MewBot removing blank line after 
 * (NORM talk) Blank line before first heading
 * [[Image:Wikt rei-artur3.svg|20px]] (notices about the vote)
 * (BP) Created Wiktionary:Votes/pl-2015-11/NORM: 10 proposals
 * (BP) Wiktionary:Votes/pl-2015-11/NORM: 10 proposals - starting soon
 * [[Image:Wikt rei-artur3.svg|20px]] (vote talk page)
 * Wiktionary talk:Votes/pl-2015-11/NORM: 10 proposals

Proposals: 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10

Support option 1: Wiktionary:Entry markup (WT:EM)

 * 1)  --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
 * 2)  —CodeCat 20:36, 18 November 2015 (UTC)
 * 3)  SemperBlotto (talk) 20:49, 18 November 2015 (UTC)
 * 4)  --WikiTiki89 03:19, 25 November 2015 (UTC)
 * Suppport Seems better than "normalization". Seems to nicely completement "layout" in WT:Entry layout. --Dan Polansky (talk) 14:13, 29 November 2015 (UTC)

Oppose option 1: Wiktionary:Entry markup (WT:EM)

 * 1)  "Wiktionary:Entry markup". The page is clearly not a guide to the markup you can use, only to how to format it. Would be an extremely frustrating page to open if you were looking for a guide to Wiktionary's markup. Really needs "normalization" (or perhaps "style") in the title. This page is most useful for programmers who would understand the meaning of "normalization" to mean exactly what this page describes. Pengo (talk) 15:44, 7 December 2015 (UTC)
 * Do you oppose renaming WT:NORM to any name, or do you oppose only renaming WT:NORM to Entry markup? --Daniel Carrero (talk) 07:56, 15 December 2015 (UTC)
 * I'd support renaming it if options 3 & 4 were fixed per your suggestions. i.e. Renaming it to either "Wikitext normalization" or "Wikitext style guide" would be fine, but as proposed I don't support any of the options. Pengo (talk) 15:28, 15 December 2015 (UTC)
 * I understand, but to clarify, using "wikitext" rather than "wikicode" was a suggestion of, not mine. Also, if you want, you can use the option 5 in this vote to support as many custom options you might think, including "Wikitext normalization" and "Wikitext style guide". --Daniel Carrero (talk) 15:34, 15 December 2015 (UTC)
 * Ah, sorry for the mixup. Yep. Ok I've added support for that change, however I still strongly oppose "Wiktionary:Entry markup" as the page is not a guide to entry markup. Maybe this "oppose" should have gone under that heading. Pengo (talk) 02:14, 16 December 2015 (UTC)
 * 1)  per Pengo. "normalization" is not particularly good, but having read Pengo's response, I realized "entry markup" is really too suggestive of e.g. which templates to use. WT:NORM is actually largely about the use of whitespace. --Dan Polansky (talk) 09:06, 31 January 2016 (UTC)
 * 2)  --Dixtosa (talk) 08:05, 7 February 2016 (UTC)
 * 3)  -Xbony2 (talk) 00:19, 9 February 2016 (UTC)

Oppose option 3: Wiktionary:Wikicode normalization (WT:WCN)

 * 1) ; it's called "wikitext", not "wikicode". This, that and the other (talk) 01:48, 25 November 2015 (UTC)
 * For CFI purposes, wikicode looks attestable: it has 270 Google Books hits. We also have entries for wikitext and wiki markup. --Daniel Carrero (talk) 07:06, 29 November 2015 (UTC)
 * I don't dispute that the word exists, but this is a vote, not RFV. I am saying that the term almost exclusively used by MediaWiki developers and technicians is "wikitext" (and those that don't use "wikitext" use "wiki markup"). "Wikicode" is simply not an accepted term. This, that and the other (talk) 09:32, 16 December 2015 (UTC)
 * 1)  per TTATO -Xbony2 (talk) 00:20, 9 February 2016 (UTC)

Support option 4: Wiktionary:Wikicode style guide (WT:WSG)

 * 1) ; it's called "wikitext", not "wikicode". This, that and the other (talk) 01:48, 25 November 2015 (UTC)
 * 2)  per TTATO -Xbony2 (talk) 00:20, 9 February 2016 (UTC)

Support option 5: Other name. Specify.

 * : Wiktionary:Wikitext normalization (WT:NORM) The page does not tell you about the "entry markup" you can use, only how to normalize it. The word normalize is used this way in software and other contexts and its meaning is unambiguous. —Pengo (talk) 02:14, 16 December 2015 (UTC)
 * 1)  "Wiktionary:Wikitext normalization" per Pengo. This, that and the other (talk) 06:45, 9 February 2016 (UTC)

Oppose

 * 1)  any title without the word "normalization" in it. I'm quite happy with the existing title. This, that and the other (talk) 01:48, 25 November 2015 (UTC)
 * My opinion is different from yours. I commented about the word "normalization" in this discussion:
 * The name "Normalization of entries" is unclear. Since Entry layout, too, provides rules for "normalization" of "entries", the uninformed reader cannot tell at a glance why we have two different policies currently named as "Entry layout" and "Normalization of entries".
 * --Daniel Carrero (talk) 14:16, 25 November 2015 (UTC)

Abstain

 * 1)  — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)

Support

 * 1)  --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
 * 2)  —CodeCat 20:36, 18 November 2015 (UTC)
 * 3) . Closes up an anti-bot loophole. --WikiTiki89 03:18, 25 November 2015 (UTC)
 * 4)  —Μετάknowledge discuss/deeds 17:49, 25 November 2015 (UTC)
 * 5)  I would phrase it something like "This applies to the parts of a page that the bot edits. The bot may also normalize other parts of the page." Pengo (talk) 15:34, 7 December 2015 (UTC)
 * , but see my comment below.--Dixtosa (talk) 08:20, 7 February 2016 (UTC)
 * 1)  -Xbony2 (talk) 00:23, 9 February 2016 (UTC)
 * 2)  — Somewhat awkwardly phrased, but a sensible enough addition. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)

Oppose

 * 1)  Sentence is pretty meaningless. It seems to say that bots can do what they like with those parts of a page which fall outside "the part of a page that the bots edit", which isn't very helpful to anyone trying to code a bot or enforce the policy. This, that and the other (talk) 01:51, 25 November 2015 (UTC)
 * I don't follow: "It seems to say that bots can do what they like with those parts of a page which fall outside 'the part of a page that the bots edit'".
 * The part of the page that the bots edit should obey this policy. How can the bot do " what they like" on the rest of the page without editing the rest of the page? --Daniel Carrero (talk) 02:50, 25 November 2015 (UTC)
 * This basically ensures that if a bot is editing only part of a page, it is not responsible for fixing any violations of this policy that our outside of that part of the page. It just reinforces common sense. --WikiTiki89 03:21, 25 November 2015 (UTC)
 * Oh, that makes some more sense. So what it should really say is "bots are not obliged to correct all violations of this policy when editing a page; they may restrict their attention to certain sections of the page, or the entire page, as they choose". This, that and the other (talk) 10:17, 25 November 2015 (UTC)
 * I oppose making bots responsible for fixing violations outside the part of the policy they are editing. If the only thing a bot does is adding/removing interwikis, it makes sense obeying the section about interwikis: "Interwikis are placed at the very end of a page.", "Each interwiki on its own line.", etc. But should that same bot look for, say, incorrect spacing everywhere? It makes sense that a bot can fix any mistakes they find, but it should not be held responsible for any mistake left alone which is unrelated to the part of the policy they edit. Having the requirement that bots fix everything means extra bureaucracy and work/coding when creating/running a bot. --Daniel Carrero (talk) 13:56, 25 November 2015 (UTC)
 * OK, but that isn't really my point. What I am wondering is, do you think my proposed sentence above is clearer than that put forward in the vote? This, that and the other (talk) 10:29, 27 November 2015 (UTC)
 * I've thought about your question. I think your sentence could be an improvement, in the direction of allowing/encouraging bots to fix any mistakes they find. For example, a bot approved for adding/removing interwikis might still go beyond its duty to fix some incorrect spacing without the need to ask for permission first. At least, that's my interpretation of your proposed sentence, I don't know if you were thinking exactly about something like I described. (Your exact question "do you think my proposed sentence above is clearer" seems to assume both "This applies to the part of a page that the bots edit, not to the entire page." and "bots are not obliged to correct all violations of this policy when editing a page; they may restrict their attention to certain sections of the page, or the entire page, as they choose" serve the same purpose or convey the same idea, which I think they don't.)
 * For the moment, I'm still going to support the original proposal "This applies to the part of a page that the bots edit, not to the entire page." because I think it's straightforward and it fulfills the purpose of freeing bots from the responsibility of fixing every mistake they find on a page -- which in my view is an important thing to do, as discussed before. We could consider changing the rule later to encourage bots to fix mistakes even when it's not their responsibility, but I think of this as a possible next step, not necessarily a priority. --Daniel Carrero (talk) 06:49, 29 November 2015 (UTC)
 * For credit purposes, I'd like to clarify that the proposal of "This applies to the part of a page that the bots edit, not to the entire page." was not originally mine. I got it from in Votes/pl-2015-07/Normalization of entries 2 and a number of people already supported his idea in the vote, with statements on the likes of "I support Msh210's qualifier." --Daniel Carrero (talk) 06:53, 29 November 2015 (UTC)
 * Note that, as mentioned at Votes/pl-2015-07/Normalization of entries 2, this sentence is already policy. All we're voting on here is whether it should be in the text of NORM or, on the other hand, remain policy without being in the text of NORM. Ping Daniel Carrero, Wikitiki89, because I'm coming late to this discussion (and because what I'm saying here seems to contradict what they said above). &#x200b;—msh210℠ (talk) 21:53, 30 November 2015 (UTC)
 * Thanks, I was not aware of that. Although I don't see how it contradicts what I was saying. --WikiTiki89 22:04, 30 November 2015 (UTC)
 * You said "This basically ensures that if a bot is editing only part of a page, it is not responsible…", but in fact that's already ensured. &#x200b;—msh210℠ (talk) 22:37, 30 November 2015 (UTC)
 * Then I guess it's a semantic question of whether one can ensure something that is already ensured. --WikiTiki89 23:10, 30 November 2015 (UTC)

Abstain

 * 1)  For reference, proposal 2 is the addition of "This applies to the part of a page that the bots edit, not to the entire page." That is pretty obvious; bots should not be forced to make a complete whitespace cleanup of a page. And even then, the adversarial reading is still not completely prevented since it is not clear what is meant by "part of a page that the bot edits"; I don't think that a bot that switches e.g. template context to template lb should be forced to handle whitespace after # in the definition line concerned. The intention of the wording probably was that the bot should not introduce new deviations from the whitespace convention. --Dan Polansky (talk) 21:52, 14 February 2016 (UTC)

Comments

 * We could make a function that correct or detect these anomalies and make it mandatory to include this function in their sources. --Dixtosa (talk) 08:20, 7 February 2016 (UTC)

Support

 * 1)  --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
 * 2)  —CodeCat 20:37, 18 November 2015 (UTC)
 * 3) . In the future, I don't think we need to vote on minor formatting changes like this. --WikiTiki89 03:17, 25 November 2015 (UTC)
 * 4)  and per Wikitiki89 as well.  This, that and the other (talk) 06:35, 30 November 2015 (UTC)
 * , and what Wikitiki says. IMO it's easier to read for beginning editors. —Aryamanarora (मुझसे बात करो) 23:32, 15 December 2015 (UTC)
 * 1)  Helps to distinguish code from normal text. Also "" looks awful and unrecognizable. —suzukaze (t・c) 12:26, 31 December 2015 (UTC)
 * , and I agree that something this minor probably doesn't require a vote. Also, as Pengo says below, it should probably be "e.g." rather than "i.e." (and I don't think that change requires an additonal vote). Andrew Sheedy (talk) 01:58, 2 February 2016 (UTC)
 * 1)  -Xbony2 (talk) 00:24, 9 February 2016 (UTC)
 * 2)  — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)

Oppose

 * 1)  We should use plain typography, IMHO, rather than enclosing wikicode in,  ,  , or combinations such as   on the start of a line" in the first sentence would be sufficient. —suzukaze (t・c) 12:33, 31 December 2015 (UTC)
 * 2)  Just here to point out that the proposed wording has a run-on sentence with a comma. Equinox ◑ 14:53, 12 February 2016 (UTC)
 * 3)  — Mightn't "One space after ,  ,   (or combination thereof) on the start of a line." be better? — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)

Support

 * 1)  --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)
 * 2)  —CodeCat 20:39, 18 November 2015 (UTC)
 * 3)  DTLHS (talk) 20:42, 18 November 2015 (UTC)
 * 4)  —Enosh (talk) 12:01, 15 December 2015 (UTC)
 * 5)  —Μετάknowledge discuss/deeds 02:25, 2 January 2016 (UTC)
 * 6)  — Andrew Sheedy (talk) 02:05, 2 February 2016 (UTC)
 * 7)  -Xbony2 (talk) 00:30, 9 February 2016 (UTC)


 * Query: Could those in favor please provide a few words explaining their reasons? ‑‑ Eiríkr Útlendi │Tala við mig 07:43, 9 February 2016 (UTC)

Oppose

 * 1)  for usability reasons, as described at Wiktionary_talk:Normalization_of_entries.  ‑‑ Eiríkr Útlendi │Tala við mig 20:27, 18 November 2015 (UTC)
 * I don't see any usability reasons mentioned there. Is there a particular advantage to having multiple consecutive spaces in the wikitext? —CodeCat 23:38, 15 December 2015 (UTC)
 * As described in the linked thread, greater spacing between sentences improves legibility. ‑‑ Eiríkr Útlendi │Tala við mig 00:11, 16 December 2015 (UTC)
 * But different browsers may use different fonts thus showing different views, don't they?--Dixtosa (talk) 08:40, 7 February 2016 (UTC)
 * I've tested Chrome + Firefox + IE on Windows, and Chrome + Firefox + Safari on Mac. Windows browsers consistently use a monospace font.  On Mac, Firefox uses monospace, while Chrome and Safari use proportional.
 * That said, whitespace in the editor is not normalized, so regardless of font, two spaces appear wider than a single space. ‑‑ Eiríkr Útlendi │Tala við mig 08:58, 7 February 2016 (UTC)
 * 1)  proposal "No multiple spaces in a row"; for more, see the above Eiríkr link. --Dan Polansky (talk) 14:15, 29 November 2015 (UTC)
 * 2)  I like 'em. DCDuring TALK  21:01, 9 February 2016 (UTC)
 * 3)  — Sometimes, using &amp;#32;&amp;nbsp;&amp;#32; is necessary for replicating unusually long spacing in quoted texts. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)

Abstain

 * 1)  I would support, but I think the wording is too general. Perhaps it should say "There should not be more than one space in a row within running text." --WikiTiki89 03:09, 25 November 2015 (UTC)
 * The proposed rule is: "No multiple spaces in a row." In practice, it does not feel much different from your suggested change, except it mentions running text. Are you thinking of places other than running text, where you'd like to let people use 2 spaces in a row? --Daniel Carrero (talk) 22:08, 1 December 2015 (UTC)
 * There could be. I can't think of very many off the top of my head. Maybe to align templates? Since this rule is envisioned as applicable to running text, I think that should be made an explicit part of the rule. --WikiTiki89 22:22, 1 December 2015 (UTC)
 * In the proposal 4, there is an example about using line breaks to visualize a table in the code when calling . It is conceivable that using multiple spaces inside a template call could be helpful to align parameters and/or values, particularly if the user edits the page using a monospaced font. By "maybe to align templates", did you think of anything else? If there are no other exceptions, we could change the rule to: "No multiple spaces in a row, except within templates."
 * The original "No multiple spaces in a row." was designed to try and make the life of the bot owner easier -- by converting all instances of multiple spaces into single spaces. The suggested "No multiple spaces in a row, except within templates." adds a single exception to that. --Daniel Carrero (talk) 00:14, 2 December 2015 (UTC)
 * Templates are a rather bad place to have spaces, as they tend to mess up stuff, particularly modules that do text processing. —CodeCat 01:09, 2 December 2015 (UTC)
 * My point is that neither you nor I know whether there are any other exceptions, which is why we should not generalize beyond our field of view. --WikiTiki89 01:10, 2 December 2015 (UTC)
 * 1)   I was going to vote "Oppose" because who cares about spacing after a sentence???? but then remembered that   the main issue is that no-one      wants to     see   ten meaningless  consecutive spaces in a row in wikitext.  However, I think that having two spaces after a sentence-ending period is harmless and not an issue and should not be outlawed. —suzukaze (t・c) 12:21, 31 December 2015 (UTC)

Support

 * 1)  --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)
 * 2)  Rules 3 and 4 are redundant though, as the blank lines next to headers are already regulated. —CodeCat 20:41, 18 November 2015 (UTC)
 * 3)  Only natural. --WikiTiki89 03:06, 25 November 2015 (UTC)
 * 4)  — Andrew Sheedy (talk) 02:06, 2 February 2016 (UTC)
 * 5)  -Xbony2 (talk) 00:31, 9 February 2016 (UTC)

Oppose

 * 1)  Subject: Boxes and images. The example contains Example.png, with hardwired pixel width, and someone explained to me a long time ago that hardwired widths are a bad idea. --Dan Polansky (talk) 09:14, 31 January 2016 (UTC)
 * I'm curious. What is the problem with hardwired widths? --Daniel Carrero (talk) 17:39, 1 February 2016 (UTC)
 * If you don't give the MediaWiki software a "hardwired" width it's going to assign the picture its own width anyways. MediaWiki doesn't do responsive design (yet). —suzukaze (t・c) 06:49, 9 February 2016 (UTC)
 * 1)  because of the inclusion of  in the example entry. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)
 * 2)  Example encourages use of hard-coded fixed width rather than using "thumb". Also, this locks in our inability to position images or example boxes close to the associated definition. Some clever JSer may be able to come up a way to do so. I see no reason to discourage someone from doing so by limiting the tools available. DCDuring TALK  00:10, 14 February 2016 (UTC)
 * Indeed, it does not even contain "thumb"--one more reason to oppose. I did not notice that. --Dan Polansky (talk) 21:17, 14 February 2016 (UTC)
 * What's wrong with hard-coded width? If you don't give the software one and use, it'll just choose a width for you, one that may be oddly large. I don't see what's wrong with choosing to make an image smaller. —suzukaze (t・c) 21:35, 14 February 2016 (UTC)
 * Per User_talk:Dan_Polansky/2008, pixel width can be set in user preferences. I have not double checked myself. --Dan Polansky (talk) 21:43, 14 February 2016 (UTC)
 * 1)  Needs   D: —suzukaze (t・c) 21:35, 14 February 2016 (UTC)

Comment

 * It seems like the Oppose votes are mostly due to personal dissatisfaction with the elements used. Perhaps it should be noted that "This is what layout should look like if one choose to use elements that act like these do (floating to the right)" (something that says that you don't have to use or   with a fixed width if you don't want to). —suzukaze (t・c) 21:41, 14 February 2016 (UTC)

Support option 1: "One blank line"

 * 1)  One blank line before all headers, so why not before the first? —CodeCat 20:41, 18 November 2015 (UTC)

Support option 2: "No blank lines"

 * 1)  --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)
 * Same as Wikitiki89 vote below, I am supporting this because it has been our standard practice for a long time. --Daniel Carrero (talk) 06:57, 29 November 2015 (UTC)
 * 1)  It is very easy to accidentally introduce a visible blank paragraph at the top of an entry. Doing this will stop this problem from happening so often. This, that and the other (talk) 01:54, 25 November 2015 (UTC)
 * 2)  This has been our standard practice for a long time. --WikiTiki89 03:05, 25 November 2015 (UTC)
 * 3)  —Μετάknowledge discuss/deeds 03:17, 25 November 2015 (UTC)
 * 4)  -- profesjonalizm • reply 01:45, 4 January 2016 (UTC)
 * 5)  -Xbony2 (talk) 00:32, 9 February 2016 (UTC)
 * 6)  — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)
 * 7)  DCDuring TALK  00:11, 14 February 2016 (UTC)

Decision
Proposal 1 was confusingly structured, and I am unsure of how to close it best. The option Wiktionary:Wikitext normalization had 2 editors in support and none in opposition, but gained a minority of the support votes overall. This looks like no consensus, although I welcome a discussion on this.

Proposal 2 passes 8-1-1 (89%).

Proposal 3 passes 9-1-1 (90%).

Proposal 4 passes 7-0-0 (100%).

Proposal 5 has no consensus at 5-3-1 (62,5%).

Proposal 6 passes 6-0-1 (100%).

Proposal 7 fails 3-4-3 (43%).

Proposal 8 has no consensus at 7-4-2 (63,6%).

Proposal 9 has no consensus at 5-4-0 (55,6%).

Proposal 10's Option 2 passes 8-0-0 (Option 1 also had no opposition, but only one vote in support). —Μετάknowledge discuss/deeds 01:38, 15 February 2016 (UTC)
 * For the record, the proposal 1 is confusingly structured because some people added new options to the vote. See for the last version of the vote before it started. I'm not particularly opposed to people doing that, since it just reflects the fact that they wanted to oppose some of the specific proposals.
 * I'll try to keep track of the individual results. I'll add 1 abstention in all the results below.
 * Option 1 "Wiktionary:Entry markup" = 4-5-1 (55%) (counting 1 "Oppose any title without the word 'normalization' in it.")
 * Option 2 "Wiktionary:Entry source code" = 0-1-1 (0%) (counting 1 "Oppose any title without the word 'normalization' in it.")
 * Option 3 "Wiktionary:Wikicode normalization" = 0-2-1 (0%)
 * Option 4 "Wiktionary:Wikicode style guide" = 0-3-1 (0%) (counting 1 "Oppose any title without the word 'normalization' in it.")
 * Option 5 "Wiktionary:Wikitext normalization" = 2-0-1 (100%)
 * I think it's best to support Metaknowledge's assessment, but it also arguably means that the option 5 was completely useless. It's true that "Wiktionary:Wikitext normalization" was supported by a small margin. It technically got 100% for the lack of votes in opposition, but one could argue that nobody has the obligation to oppose an option added in the middle of the vote. Maybe we could create a separate vote and/or discussion for it. --Daniel Carrero (talk) 04:10, 15 February 2016 (UTC)
 * I implemented the changes in WT:NORM. The proposal 10 did not specify exactly where to place the new rule and the proposal 6 did not specify where to place the new section "Inflection tables", so I placed them where I saw fit, feel free to discuss or maybe change that. --Daniel Carrero (talk) 04:38, 15 February 2016 (UTC)