Wiktionary

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

< Wiktionary:Votes

NORM: 10 proposals edit

Voting on:

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

See details

Renaming Wiktionary: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.

See details

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 <code></code>.

See details

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. ==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.

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.

See details

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 {{ru-decl-noun}}:
{{ru-decl-noun
|пау́к-во́лк|пауки́-во́лки
|паука́-во́лка|пауко́в-волко́в
|пауку́-во́лку|паука́м-волка́м
|паука́-во́лка|пауко́в-волко́в
|пауко́м-во́лком|паука́ми-волка́ми
|о пауке́-во́лке|о паука́х-волка́х}}

Proposal 5.

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

See details

Current text:

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

Proposed text:

Categories
No blank lines between two categories.
Interwikis
No blank lines between two interwikis.

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

See details

Adding to the section "General" (or "Whitespace and characters", should the proposal 4 fail):

  1. The template {{also}} on its own line.

Adding to the section "Headings":

  1. The horizontal rule (----) on its own line.

Adding to the section "Categories" (or "Categories and interwikis", should the proposal 5 fail):

  1. Each template whose only purpose is categorization on its own line.

Adding to the section "Translation sections":

  1. Each of the following templates on its own line:
    {{trans-top}}, {{trans-mid}}, {{trans-bottom}}, {{trans-see}}, {{checktrans-top}}

Adding a new section "Inflection tables", with the following rule:

  1. Each inflection table on its own line.

Proposal 7.

Editing the rule about spaces after #, * and :.

See details

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.

See details

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#Example entry section accordingly: 

==English==
[[File:Example.png|100px]]
{{wikipedia}}

===Noun===
{{en-noun}}

# 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 {{also}}) precedes.

See details

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)

Discussions:

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

Proposal 1 edit

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

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

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

  1.   Oppose "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)[reply]
    @Pengo: Do you oppose renaming WT:NORM to any name, or do you oppose only renaming WT:NORM to Wiktionary:Entry markup? --Daniel Carrero (talk) 07:56, 15 December 2015 (UTC)[reply]
    @Daniel Carrero: 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)[reply]
    @Pengo: I understand, but to clarify, using "wikitext" rather than "wikicode" was a suggestion of @This, that and the other, 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)[reply]
    @Daniel Carrero: 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)[reply]
  2.   Oppose 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)[reply]
  3.   Oppose --Dixtosa (talk) 08:05, 7 February 2016 (UTC)[reply]
  4.   Oppose -Xbony2 (talk) 00:19, 9 February 2016 (UTC)[reply]

Support option 2: Wiktionary:Entry source code (WT:ESC) edit

Support option 3: Wiktionary:Wikicode normalization (WT:WCN) edit

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

  1.   Oppose; it's called "wikitext", not "wikicode". This, that and the other (talk) 01:48, 25 November 2015 (UTC)[reply]
    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)[reply]
    @Daniel Carrero 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)[reply]
  2.   Oppose per TTATO -Xbony2 (talk) 00:20, 9 February 2016 (UTC)[reply]

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

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

Support option 5: Other name. Specify. edit

  1.   Support : 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)[reply]
  2.   Support "Wiktionary:Wikitext normalization" per Pengo. This, that and the other (talk) 06:45, 9 February 2016 (UTC)[reply]

Oppose edit

  1.   Oppose 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)[reply]
    My opinion is different from yours. I commented about the word "normalization" in this discussion:
    • The name "Normalization of entries" is unclear. Since Wiktionary: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)[reply]

Abstain edit

  1.   Abstain — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]

Proposal 2 edit

Support edit

  1.   Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)[reply]
  2.   Support —CodeCat 20:36, 18 November 2015 (UTC)[reply]
  3.   Support. Closes up an anti-bot loophole. --WikiTiki89 03:18, 25 November 2015 (UTC)[reply]
  4.   Support —Μετάknowledgediscuss/deeds 17:49, 25 November 2015 (UTC)[reply]
  5.   Support 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)[reply]
  6.   Support, but see my comment below.--Dixtosa (talk) 08:20, 7 February 2016 (UTC)[reply]
  7.   Support -Xbony2 (talk) 00:23, 9 February 2016 (UTC)[reply]
  8.   Support — Somewhat awkwardly phrased, but a sensible enough addition. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]

Oppose edit

  1.   Oppose 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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? (== English ==, [[Category: English nouns]]) 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)[reply]
    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)[reply]
    @This, that and the other 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)[reply]
    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 @msh210 in Wiktionary: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)[reply]
    Note that, as mentioned at Wiktionary:Votes/pl-2015-07/Normalization of entries 2#Decision, 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).​—msh210℠ (talk) 21:53, 30 November 2015 (UTC)[reply]
    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)[reply]
    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.​—msh210℠ (talk) 22:37, 30 November 2015 (UTC)[reply]
    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)[reply]

Abstain edit

  1.   Abstain 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)[reply]

Comments edit

Proposal 3 edit

Support edit

  1.   Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)[reply]
  2.   Support —CodeCat 20:37, 18 November 2015 (UTC)[reply]
  3.   Support. In the future, I don't think we need to vote on minor formatting changes like this. --WikiTiki89 03:17, 25 November 2015 (UTC)[reply]
  4.   Support and per Wikitiki89 as well. This, that and the other (talk) 06:35, 30 November 2015 (UTC)[reply]
  5.   Support, and what Wikitiki says. IMO it's easier to read for beginning editors. —Aryamanarora (मुझसे बात करो) 23:32, 15 December 2015 (UTC)[reply]
  6.   Support Helps to distinguish code from normal text. Also "----" looks awful and unrecognizable. —suzukaze (t・c) 12:26, 31 December 2015 (UTC)[reply]
  7.   Support, 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)[reply]
  8.   Support -Xbony2 (talk) 00:24, 9 February 2016 (UTC)[reply]
  9.   Support — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]

Oppose edit

  1.   Oppose We should use plain typography, IMHO, rather than enclosing wikicode in <code></code> --Dan Polansky (talk) 14:17, 29 November 2015 (UTC)[reply]

Abstain edit

  1.   Abstain "i.e." should be "e.g." Also is it possible to format the "good" and "bad" examples so they have green and red borders? But I agree we shouldn't really need to vote on minor formatting issues like this. Pengo (talk) 15:24, 7 December 2015 (UTC)[reply]

Proposal 4 edit

Support edit

  1.   Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)[reply]
  2.   Support —CodeCat 20:37, 18 November 2015 (UTC)[reply]
  3.   Support --WikiTiki89 03:15, 25 November 2015 (UTC)[reply]
  4.   Support Adds the useful allowance of newlines in template markups. --Dan Polansky (talk) 14:19, 29 November 2015 (UTC)[reply]
  5.   Support — Andrew Sheedy (talk) 01:59, 2 February 2016 (UTC)[reply]
  6.   Support -Xbony2 (talk) 00:26, 9 February 2016 (UTC)[reply]
  7.   Support; however, general point 2 should read "No consecutive blank lines." rather than "Not more than 1 blank line in a row.", since blank lines cannot ever occur in rows in wikitext. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]

Oppose edit

Abstain edit

Proposal 5 edit

Support edit

  1.   Support --Daniel Carrero (talk) 03:39, 15 November 2015 (UTC)[reply]
  2.   Support —CodeCat 20:38, 18 November 2015 (UTC)[reply]
  3.   Support --WikiTiki89 03:13, 25 November 2015 (UTC)[reply]
  4.   Support —Μετάknowledgediscuss/deeds 02:24, 2 January 2016 (UTC)[reply]
  5.   Weak support — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]

Oppose edit

  1.   Oppose The amendment, although logically separated by subject, feels like a poor use of space as it ultimately says to do the same thing. If they had different instructions it would be a different story. —suzukaze (t・c) 12:28, 31 December 2015 (UTC)[reply]
  2.   Oppose per suzukaze -Xbony2 (talk) 00:27, 9 February 2016 (UTC)[reply]
  3.   Oppose We need more space displayed between L2 sections than this allows. DCDuring TALK 23:02, 10 February 2016 (UTC)[reply]

Abstain edit

  1.   Abstain Dan Polansky (talk) 10:29, 13 February 2016 (UTC). The proposal for reference: "No blank lines between two categories or between two interwikis" to be split in two rows; policy impact: none. --Dan Polansky (talk) 10:29, 13 February 2016 (UTC)[reply]

Proposal 6 edit

Support edit

  1.   Support --Daniel Carrero (talk) 03:39, 15 November 2015 (UTC)[reply]
  2.   Support —CodeCat 20:38, 18 November 2015 (UTC)[reply]
  3.   Support DTLHS (talk) 20:43, 18 November 2015 (UTC)[reply]
  4.   Support --WikiTiki89 03:12, 25 November 2015 (UTC)[reply]
  5.   Support — Andrew Sheedy (talk) 02:00, 2 February 2016 (UTC)[reply]
  6.   Support -Xbony2 (talk) 00:28, 9 February 2016 (UTC)[reply]

Oppose edit

Abstain edit

  1.   Abstain The proposal again, for reference: The template {{also}} on its own line. The horizontal rule (----) on its own line. Each template whose only purpose is categorization on its own line. Each of the following templates on its own line: {{trans-top}}, {{trans-mid}}, {{trans-bottom}}, {{trans-see}}, {{checktrans-top}}. Each inflection table on its own line. --Dan Polansky (talk) 10:26, 13 February 2016 (UTC)[reply]

Comment edit

Proposal 7 edit

Support edit

#   Support --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)[reply]

  1.   Support —CodeCat 20:39, 18 November 2015 (UTC)[reply]
  2.   Support, although this is unnecessary, since putting a space in between the characters will break the functionality anyway. --WikiTiki89 03:11, 25 November 2015 (UTC)[reply]
    True, this just formalizes existing practice. --Daniel Carrero (talk) 18:34, 25 November 2015 (UTC)[reply]
    It's not a "practice", it's a necessary circumstance. Just like we don't say "Template invocations must begin with with two opening curly braces and end with two closing curly braces." There's no other way to do it. --WikiTiki89 18:54, 25 November 2015 (UTC)[reply]
    Point taken. --Daniel Carrero (talk) 06:57, 29 November 2015 (UTC)[reply]
  3.   Support, though I doubt anyone will be prevented from making the mistake by the documentation. DCDuring TALK 23:06, 10 February 2016 (UTC)[reply]

Oppose edit

  1.   Oppose per Wikitiki89. Just adding complication to the language. Pengo (talk) 15:27, 7 December 2015 (UTC)[reply]
  2.   Oppose due to pointlessness. —Μετάknowledgediscuss/deeds 02:23, 2 January 2016 (UTC)[reply]
  3.   Oppose per Wikitiki89. --Daniel Carrero (talk) 08:10, 18 January 2016 (UTC)[reply]
  4.   Oppose -Xbony2 (talk) 00:29, 9 February 2016 (UTC)[reply]

Abstain edit

  1.   Abstain I don't like the second sentence. Something like "#, *, :, 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)[reply]
  2.   Abstain Just here to point out that the proposed wording has a run-on sentence with a comma. Equinox ◑ 14:53, 12 February 2016 (UTC)[reply]
  3.   Abstain — 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)[reply]

Proposal 8 edit

Support edit

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

Oppose edit

  1.   Oppose for usability reasons, as described at Wiktionary_talk:Normalization_of_entries#Collapse_multiple_spaces_into_one_space. ‑‑ Eiríkr Útlendi │Tala við mig 20:27, 18 November 2015 (UTC)[reply]
    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)[reply]
    As described in the linked thread, greater spacing between sentences improves legibility. ‑‑ Eiríkr Útlendi │Tala við mig 00:11, 16 December 2015 (UTC)[reply]
    @Eirikr: But different browsers may use different fonts thus showing different views, don't they?--Dixtosa (talk) 08:40, 7 February 2016 (UTC)[reply]
    • 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)[reply]
  2.   Oppose proposal "No multiple spaces in a row"; for more, see the above Eiríkr link. --Dan Polansky (talk) 14:15, 29 November 2015 (UTC)[reply]
  3.   Oppose I like 'em. DCDuring TALK 21:01, 9 February 2016 (UTC)[reply]
  4.   Oppose — Sometimes, using &#32;&nbsp;&#32; is necessary for replicating unusually long spacing in quoted texts. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]

Abstain edit

  1.   Abstain 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)[reply]
    @Wikitiki89 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)[reply]
    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)[reply]
    In the proposal 4, there is an example about using line breaks to visualize a table in the code when calling {{ru-decl-noun}}. 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)[reply]
    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)[reply]
    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)[reply]
  2.   Abstain 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)[reply]

Proposal 9 edit

Support edit

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

Oppose edit

  1.   Oppose Subject: Boxes and images. The example contains [[File:Example.png|100px]], 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)[reply]
    I'm curious. What is the problem with hardwired widths? --Daniel Carrero (talk) 17:39, 1 February 2016 (UTC)[reply]
    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)[reply]
  2.   Weak oppose because of the inclusion of {{wikipedia}} in the example entry. — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]
  3.   Oppose 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)[reply]
    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)[reply]
    What's wrong with hard-coded width? If you don't give the software one and use thumb, 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)[reply]
    Per User_talk:Dan_Polansky/2008#cloak, pixel width can be set in user preferences. I have not double checked myself. --Dan Polansky (talk) 21:43, 14 February 2016 (UTC)[reply]
  4.   Oppose Needs thumb D: —suzukaze (t・c) 21:35, 14 February 2016 (UTC)[reply]

Abstain edit

Comment edit

  • 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 {{wikipedia}} or [[File:]] with a fixed width if you don't want to). —suzukaze (t・c) 21:41, 14 February 2016 (UTC)[reply]

Proposal 10 edit

Support option 1: "One blank line" edit

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

Support option 2: "No blank lines" edit

  1.   Support --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)[reply]
    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)[reply]
  2.   Support 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)[reply]
  3.   Support This has been our standard practice for a long time. --WikiTiki89 03:05, 25 November 2015 (UTC)[reply]
  4.   Support —Μετάknowledgediscuss/deeds 03:17, 25 November 2015 (UTC)[reply]
  5.   Support --profesjonalizm • reply 01:45, 4 January 2016 (UTC)[reply]
  6.   Support -Xbony2 (talk) 00:32, 9 February 2016 (UTC)[reply]
  7.   Support — I.S.M.E.T.A. 01:22, 13 February 2016 (UTC)[reply]
  8.   Support DCDuring TALK 00:11, 14 February 2016 (UTC)[reply]

Oppose edit

Abstain edit

Decision edit

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). —Μετάknowledgediscuss/deeds 01:38, 15 February 2016 (UTC)[reply]

For the record, the proposal 1 is confusingly structured because some people added new options to the vote. See this link 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)[reply]
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)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Votes/pl-2015-11/NORM:_10_proposals&oldid=39066126"