Wiktionary:Votes

Wiktionary > Votes

Votes formalize and document the consensus-building process and the decisions that the community makes. This page displays the full contents of recent, current and planned votes. Edit Wiktionary:Votes/Active to add new votes and remove old ones. Finished votes are added to Wiktionary:Votes/Timeline, an organized archive of previous votes and their results, sorted by the vote end date.

Policy and help pages, respectively: Wiktionary:Voting policy (including who is eligible to vote) and Help:Creating a vote.

See also Wiktionary:Votes/ for an automatically generated, less organized list of votes.

{{Wiktionary:Votes/2017-06/Title of vote}}	{{Wiktionary:Votes/pl-2017-06/Title of vote}}
Note: add to this page and WT:A. {{Wiktionary:Votes/sy-2017-06/User: for admin}}	Note: add to this page and WT:B. {{Wiktionary:Votes/bc-2017-06/User: for bureaucrat}}
Note: add to this page and WT:C. {{Wiktionary:Votes/cu-2017-06/User: for checkuser}}	{{Wiktionary:Votes/bt-2017-06/User: for bot status}}

Other

Admins, please periodically check for orphan votes at Wiktionary:Votes/

Look for votes and voting templates, including templates for creation of new votes:

• Look at pages starting with Wiktionary:Votes_.
• Look at pages starting with Template:vote-_.

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

Current and new votes

Simplifying CFI about constructed languages

Voting on: Simplifying WT:CFI#Constructed languages as follows:

Old text:

Constructed languages

Constructed languages have not developed naturally, but are the product of conscious effort in the fulfillment of some purpose. In general, such languages, particularly languages associated with works of fiction, do not meet the basic requirement that one might run across them and want to know the meaning of their words, since they are only used in a narrow context in which further material on the language is readily available. There are specific exceptions to this general rule, listed below, based on consensus of the Wiktionary community; Esperanto, for example, is a living language with a sizeable community of fluent speakers, and even some native speakers.

Some individual terms from constructed languages have been adopted into other languages. These should be treated as terms in the adoptive language, and the origin noted in the etymology, regardless of whether the constructed language as a whole meets the criteria for inclusion.

Languages that are not natural languages must have consensus to be included.

• These languages have an apparent consensus (all have ISO 639-3 codes): Esperanto, Ido, Interlingua, Interlingue (Occidental), Lojban, Novial, Volapük.

• At present, several other languages have ISO 639-3 codes and are classified as constructed languages. Three are prohibited (see below); the remainder have not yet been approved for inclusion in the English Wiktionary.

• There is no apparent consensus for including these additional languages which do not have ISO 639-3 codes: Ceqli (Tceqli), D'ni, Delason, Ekspreso, Europanto, Glos, Jakelimotu, Kyerepon, Latejami, Latino sine Flexione, Linga, Romanica, Sasxsek, Suoczil, Toki Pona.

• There is consensus that languages whose origin and use are restricted to one or more related literary works and its fans do not merit inclusion as entries or translations in the main namespace. They may merit lexicons in the Appendix namespace. These languages include Quenya, Sindarin, Klingon, and Orcish (the first three do have ISO 639-3 codes).

Even when rejected for treatment as a language for purposes of this Wiktionary, a single article about the name of that language may be acceptable.

References:

New text:

Constructed languages

Constructed languages have not developed naturally, but are the product of conscious effort in the fulfillment of some purpose.

All constructed languages are excluded except for Esperanto, Ido, Interlingua, Interlingue (Occidental), Lojban, Novial, and Volapük.

Some individual terms from constructed languages have been adopted into other languages. These should be treated as terms in the adoptive language, and the origin noted in the etymology, regardless of whether the constructed language as a whole is included.

Languages originating from literary works should not be included as entries or translations in the main namespace, consistent with the above. However, the following ones should have lexicons in the Appendix namespace: Quenya, Sindarin, Klingon, and Orcish.

References:

Schedule:

• Vote starts: 00:00, 26 May 2017 (UTC)
• Vote ends: 23:59, 24 June 2017 (UTC)
• Vote created: Dan Polansky (talk) 09:40, 19 May 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/May#Vote: Simplifying CFI about constructed languages
• Wiktionary talk:Votes/pl-2017-05/Simplifying CFI about constructed languages

Support

1. Support --Daniel Carrero (talk) 00:07, 26 May 2017 (UTC)
2. Support. Makes sense. -Xbony2 (talk) 00:28, 28 May 2017 (UTC)
3. Support —Μετάknowledge^{discuss/deeds} 03:46, 28 May 2017 (UTC)
4. Support For a rationale, see the vote talk page. --Dan Polansky (talk) 20:47, 29 May 2017 (UTC)
5. Support It is to the point and removes a lot of useless banter. Lingo Bingo Dingo (talk) 09:56, 1 June 2017 (UTC)

   Support The old policy basically said nobody will ever see words in constructed languages, which is not true. --IAmAmillion

   Struck as ineligible to vote. —Granger (talk · contribs) 23:52, 10 June 2017 (UTC)

6. Support I guess… Mistrz (talk) 13:40, 14 June 2017 (UTC)
7. Support I approve of removing clutter.__Gamren (talk) 15:34, 17 June 2017 (UTC)
8. Support New version says everything that needs to be said. - [The]DaveRoss 13:06, 23 June 2017 (UTC)
9. Support The new version is much more concise and to the point, while still retaining all the pertinent information. BigDom 16:06, 24 June 2017 (UTC)

Oppose

1. Oppose on the basis that it omits the rationale: "In general, such languages, particularly languages associated with works of fiction, do not meet the basic requirement that one might run across them and want to know the meaning of their words...". This helps the first-time reader to understand why the policy exists. Otherwise, people might think we are purists with an arbitrary dislike of constructed languages. This, that and the other (talk) 12:32, 30 May 2017 (UTC)

   For one thing, I don't think the policy should contain a rationale. For another thing, the rationale seems to be incorrect: Constructed languages do not differ all that much from poorly documented natural languages in their ability to contain words that people once in a long while run across. It surely is quite possible for people to run across a word in a constructed language, although rarely so; but then, the same holds true of very rare English words: since they are rare, people only rarely run across them. --Dan Polansky (talk) 17:41, 30 May 2017 (UTC)

2. Oppose Too much useful information has been cut out. --WikiTiki89 16:41, 30 May 2017 (UTC)

   If you can be more specific, this may help draft a follow-up vote. --Dan Polansky (talk) 17:41, 30 May 2017 (UTC)

   I guess mostly just the second sentence of the first paragraph, which others have already mentioned. --WikiTiki89 17:53, 30 May 2017 (UTC)

   Thank you. The 2nd sentence seems false as per my response to TTTO above: you can run across words of constructed languages, even if rarely so. --Dan Polansky (talk) 18:02, 30 May 2017 (UTC)

   It should have been corrected, but not removed. --WikiTiki89 18:14, 30 May 2017 (UTC)

   Corrected to say what? (I don't think a policy should contain a rationale, but that is a separate argument.) --Dan Polansky (talk) 18:15, 30 May 2017 (UTC)

   To explain why constructed languages do not meet CFI. --WikiTiki89 18:20, 30 May 2017 (UTC)

   Sure, and what is the specific explanation that you have for the reader, to be placed to CFI? --Dan Polansky (talk) 18:23, 30 May 2017 (UTC)

Abstain

1. Abstain. Some of what has been cut could be useful in clarifying what constitutes a constructed language and how we handle them, but I'm ambivalent as to whether it stays or not. Andrew Sheedy (talk) 07:09, 29 May 2017 (UTC)

Decision

Passed: 9-2-1 (81%). Edited WT:CFI accordingly. --Daniel Carrero (talk) 02:46, 25 June 2017 (UTC)

---

Removing bureaucrat and checkuser rights for inactivity

Automatically removing bureaucrat and checkuser rights after a certain period of not using either those tools or admin tools.

Schedule:

• Vote starts: 00:00, 28 May 2017 (UTC)
• Vote ends: 23:59, 26 June 2017 (UTC)
• Vote created: —Μετάknowledge^{discuss/deeds} 03:33, 26 May 2017 (UTC)

Discussion:

• Wiktionary:Votes/pl-2017-03/Desysopping for inactivity
• Wiktionary:Beer parlour/2017/May#Admin Rights Removals
• Wiktionary:Votes/bc-2017-05/User:Paul G for de-bureaucratisation
• Wiktionary talk:Votes/2017-05/Removing bureaucrat and checkuser rights for inactivity

Support removing rights after 5 years without use of the relevant tools

1. Support --Daniel Carrero (talk) 02:37, 29 May 2017 (UTC)
2. Support —Μετάknowledge^{discuss/deeds} 03:28, 29 May 2017 (UTC)
3. Support - [The]DaveRoss 12:39, 29 May 2017 (UTC)
4. Support Equinox ◑ 12:41, 29 May 2017 (UTC)
5. Support --Dan Polansky (talk). Note the "relevant tools" are "either those tools or admin tools", as per the text at the beginning of the vote. --Dan Polansky (talk) 17:47, 30 May 2017 (UTC)

   If someone is an active editor and happened to have not used their admin tools or their bureaucrat or checkuser tools, why should they be de-bureaucrated/de-checkusered? --WikiTiki89 17:56, 30 May 2017 (UTC)

   If someone is an active editor and happened to have not used their admin tools, why should they be desysopped? Since, the present proposal is similar to Wiktionary:Votes/pl-2017-03/Desysopping for inactivity just that it is more lenient in that it tracks activity not only in the tools to be removed but also in any power tools. An alternative proposal tracking any activity could be fine, but this one is fine too. --Dan Polansky (talk) 19:00, 30 May 2017 (UTC)

   You're right. I had misread the desysopping vote. I would have had the same problem with it. --WikiTiki89 19:04, 30 May 2017 (UTC)

   (after edit conflict) Correcting myself: not any power tools: for a bureaucrat, checkusering does not count. But since admin tools are so often used, no use of admin tools suggests no interest in use of power tools. --Dan Polansky (talk) 19:05, 30 May 2017 (UTC)

   Let us see the difference of the discussed policies by means of an example of Paul G (talk • contribs): his last logged action is from 7 May 2012, while is last edit is from 24 December 2015. Thus, his last logged action is > 5 years old while is last edit is < 2 years old. --Dan Polansky (talk) 06:17, 3 June 2017 (UTC)

6. Support —Granger (talk · contribs) 21:25, 30 May 2017 (UTC)

Oppose removing rights after 5 years without use of the relevant tools

1. Oppose I think it should be based on inactivity in general and not only inactivity in the relevant tools. --WikiTiki89 18:02, 29 May 2017 (UTC)
2. Oppose Too long. --Victar (talk) 16:08, 30 May 2017 (UTC)

   So when the 2 year limit fails, you would prefer there be no time limit? - [The]DaveRoss 16:58, 30 May 2017 (UTC)

   @Victar, so you can see Dave's question. I too find your vote puzzling. —Μετάknowledge^{discuss/deeds} 15:24, 8 June 2017 (UTC)

   It's my right to vote how I wish. --Victar (talk) 20:56, 8 June 2017 (UTC)

   @Victar Of course that's true. I think several of us are just curious about your reasoning. Why is it that you prefer two years rather than no limit, but prefer no limit rather than five years? —Granger (talk · contribs) 22:12, 8 June 2017 (UTC)

3. Oppose -Xbony2 (talk) 19:29, 2 June 2017 (UTC)
4. Oppose per Wikitiki89. --Droigheann (talk) 00:19, 3 June 2017 (UTC)
5. Oppose — Z. [ קהת ] b"A. — 14:50, 11 June 2017 (UTC)

Support removing rights after 2 years without use of the relevant tools

1. Support. I think these user rights have so much power that it really requires something more than we ask of someone who is an admin alone. —Μετάknowledge^{discuss/deeds} 03:28, 29 May 2017 (UTC)
2. Support Per Metaknowledge. --Victar (talk) 06:05, 29 May 2017 (UTC)
3. Support per Metaknowledge. Andrew Sheedy (talk) 07:10, 29 May 2017 (UTC)
4. Support - [The]DaveRoss 12:39, 29 May 2017 (UTC)
5. Support —Granger (talk · contribs) 21:25, 30 May 2017 (UTC)
6. Support -Xbony2 (talk) 19:29, 2 June 2017 (UTC)

Oppose removing rights after 2 years without use of the relevant tools

1. Oppose: Too little time, in my opinion. --Daniel Carrero (talk) 18:00, 29 May 2017 (UTC)
2. Oppose I think it should be based on inactivity in general and not only inactivity in the relevant tools. --WikiTiki89 18:02, 29 May 2017 (UTC)
3. Oppose Compared to adminship, I don't see much relevance of the increased power. Do we have any cases of stolen accounts or something? I think it is about granting fairly long sabbatical without the bureaucracy of reelection. --Dan Polansky (talk) 20:43, 29 May 2017 (UTC)
4. Oppose per Wikitiki89. --Droigheann (talk) 00:19, 3 June 2017 (UTC)
5. Oppose — Z. [ קהת ] b"A. — 14:50, 11 June 2017 (UTC)

Decision

No consensus.

• Proposal 1: 6-5-0 (54.54%) - No consensus.
• Proposal 2: 6-5-0 (54.54%) - No consensus.

--Daniel Carrero (talk) 08:54, 27 June 2017 (UTC)

---

Modern Latin as a WDL 2

Voting on: If Wiktionary:Votes/2017-05/Modern Latin as a WDL does not pass, adding the following list item to Wiktionary:Criteria for inclusion/Well documented languages:

9. Latin, for words having quotations only after the year 1500

The "and" and punctuation in items 7 and 8 are to be modified as necessary.

If Wiktionary:Votes/2017-05/Modern Latin as a WDL does pass, replacing the New and Contemporary Latin item that it added with the one above.

Schedule:

• Vote starts: 00:00, 3 June 2017 (UTC)
• Vote ends: 23:59, 2 July 2017 (UTC)
• Vote created: Dan Polansky (talk) 08:36, 27 May 2017 (UTC)

Discussion:

• Wiktionary:Votes/2017-05/Modern Latin as a WDL
• Wiktionary talk:Votes/pl-2017-05/Modern Latin as a WDL 2

Support

1. Support per reasoning stated in my cast vote at Wiktionary:Votes/2017-05/Modern Latin as a WDL. --Dan Polansky (talk) 06:08, 3 June 2017 (UTC)
2. Support -Xbony2 (talk) 13:26, 3 June 2017 (UTC)
3. Support —Μετάknowledge^{discuss/deeds} 15:29, 3 June 2017 (UTC)
4. Support -- Andrew Sheedy (talk) 04:21, 4 June 2017 (UTC)
5. Support - -sche (discuss) 18:08, 5 June 2017 (UTC)
6. Support this one. This, that and the other (talk) 11:36, 6 June 2017 (UTC)
7. Support —Granger (talk · contribs) 10:18, 13 June 2017 (UTC)
8. Support Mistrz (talk) 13:43, 14 June 2017 (UTC)
9. Support The proportion of New Latin's texts available online is probably higher than anything but a constructed language.--Prosfilaes (talk) 08:30, 23 June 2017 (UTC)
10. Support --Daniel Carrero (talk) 08:33, 23 June 2017 (UTC)

Oppose

1. Oppose for the same reason as before. Also, I think this vote is a bit unfair, since a similar vote had just failed with only slightly different wording. --WikiTiki89 16:37, 5 June 2017 (UTC)

   If you're going to be making accusations of unfairness, you'd best be honest about it. That vote has not yet ended, and even if no more votes are cast or changed, it will be closed as having no consensus, rather than failing. —Μετάknowledge^{discuss/deeds} 16:41, 5 June 2017 (UTC)

   and this vote adjusts the proposal to take into account some of the concerns expressed by opposers of that vote, which is not an uncommon phenomenon (and seems desirable). - -sche (discuss) 18:08, 5 June 2017 (UTC)

2. Oppose for the same reason as before. Latin after 1500 is neither a constructed language nor is it well documented on the Internet. —Aɴɢʀ (talk) 06:34, 7 June 2017 (UTC)
3. Oppose — Z. [ קהת ] b"A. — 14:38, 11 June 2017 (UTC)
4. Oppose, it isn't a WDL. — Kleio (t · c) 19:43, 18 June 2017 (UTC)
5. Oppose — Slœtel (talk) 20:36, 19 June 2017 (UTC)
6. Oppose - Surely you jest. DCDuring (talk) 08:03, 25 June 2017 (UTC)

   @DCDuring What makes you say that? This is already the way modern Latin is treated in practice at RFV; the goal of this vote is to codify existing practice. —Granger (talk · contribs) 11:18, 25 June 2017 (UTC)

   Apparently modern Latin isn't treat so uniformly at RFV. Certainly this vote proves there's no consensus for doing so. —Aɴɢʀ (talk) 15:42, 25 June 2017 (UTC)

   I didn't seem uniform/settled to me. I just gave up waiting for it to be settled and created {{epinew}} so all inflection line templates could link to whichever language section (Translingual, Latin, or other) the whims of the "consensus" may favor for that purpose. I am fairly sure that any change in the current lack of consensus will require some level of pointless work for me.

   As is typical with vote proposals that affect entries, there is no mention of the work required to implement whatever changes may be required. DCDuring (talk) 21:16, 25 June 2017 (UTC)

   Huh? No work at all is required to implement this. —Granger (talk · contribs) 21:19, 25 June 2017 (UTC)

   Well, okay, one edit is required—an edit to WT:WDL to add the proposed text. Other than that, this vote doesn't actually change anything, it just reaffirms the way we already treat these entries at RFV. —Granger (talk · contribs) 21:22, 25 June 2017 (UTC)

   @DCDuring: This vote proposes to require 3 attesting quotations in use for inclusion of a Latin term with quotations only after 1500. I also don't understand what sort of work required you are talking of. Presumably, if this passes (an if), some currently included Latin terms will eventually fail RFV, if any. --Dan Polansky (talk) 18:18, 26 June 2017 (UTC)

7. Oppose. The case of Latin is a very special and complex one, and I don't think we should solve the matter with what looks like a hastily prepared vote to me.
   • What exactly do we mean by "Modern Latin"? Wikipedia gives it as a synonym of "New Latin", i.e. Latin from the late Middle Ages til the beginning of the twentieth century; but our entry New Latin says it includes Renaissance Latin and Contemporary Latin (don't know where the eighteenth and nineteenth centuries went in that definition...). "Latin, for words having quotations only after the year 1500" rather points to that second definition, apparently; fair enough but...
   • The situation between Renaissance Latin and Contemporary Latin is definitely very different. Yes, there's still a fair amount of contemporary Latin secular prose (and poetry) published today (several periodical, Latin translations of modern works, even a few books), and various enterprises promoting the use of Latin (Accademia Vivarium Novum, many Latin circles, the Finnish Latin news; although their respective objectives aren't always the same); but Latin is definitely not the tool of communication it was anymore.
   • Also, as someone who was once relatively well-acquainted with the world of Latinitas viva, I wonder what Internet resources you plan to use.
   • That said, this doesn't mean that I don't want to be stringent on what we will add here. I coined the term "corporisculptor" as a calque of bodybuilder (actually, "corporisculptrix", since I was translating in Latin the French feminine word bodybuildeuse), which was published in the Melissa journal a couple years ago; but I definitely wouldn't want to see it here unless I were sure it has taken off.
   • The continued use of Latin by the Catholic Church (Ecclesiastical Latin) and its promotion of the Latinitas viva (publication of the Lexicon Recentis Latinitatis, among other things) further complicates the picture. --Barytonesis (talk) 11:40, 26 June 2017 (UTC)

     Nothing depends on the term "Modern Latin"; it is just in the name of the vote, for lack of better ideas how to name the vote. The change in the policy is specified in terms of time range: "Latin, for words having quotations only after the year 1500". --Dan Polansky (talk) 18:03, 26 June 2017 (UTC)

     The idea of the vote is fairly simple: For Latin after 1500, we are not so desperate as to consider a single use or single mention good enough. Basing the dictionary on singles is bad lexicography. For some languages or their phases, we are desperate enough to allow that kind of bad lexicography, albeit with the {{LDL}} badge of shame. --Dan Polansky (talk) 18:07, 26 June 2017 (UTC)

     You speak of your coinage not taking off. With single uses allowed, new coinages are not required to take off to any degree; it suffices that they are made. --Dan Polansky (talk) 18:10, 26 June 2017 (UTC)

---

Numbers, numerals, and ordinals

Voting on: Adding handling of numbers and numerals to WT:CFI.

Proposal 1:

Expanding WT:CFI#Idiomaticity with the following, placing it after the paragraph starting with "Unidiomatic terms made up of multiple words...":

An attested integer word (such as twenty-three or twenty-third) or a decimal numeral (sequence of 0, ..., 9 digits) that is ≥ 0 and ≤ 100 should be kept even if it is not idiomatic. In sequences of digits such as 125, the digits are considered to be separate components for the purpose of idiomaticity, and therefore, the sequences are often not idiomatic.

Proposal 2:

Adding the following text to WT:CFI, to a new heading "Numbers, numerals, and ordinals":

Numbers, numerals, and ordinals

Numbers, numerals, and ordinals over 100 that are not single words or are sequences of digits should not be included in the dictionary, unless the number, numeral, or ordinal in question has a separate idiomatic sense that meets the CFI.

Schedule:

• Vote starts: 00:00, 5 June 2017 (UTC)
• Vote ends: 23:59, 4 July 2017 (UTC)
• Vote created: --Daniel Carrero (talk) 11:58, 20 May 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/May#CFI and sum of part numbers
• User talk:Daniel Carrero#Numbers in the CFI
• Wiktionary talk:Votes/pl-2017-05/Numbers, numerals, and ordinals
• Talk:105
• Talk:one hundred and twelve
• Talk:two hundred and twenty-five
• Talk:two hundred and one

Support proposal 1

1. Support --Daniel Carrero (talk) 00:49, 5 June 2017 (UTC)
2. Support - we need something on this. bd2412 T 13:45, 5 June 2017 (UTC)
3. Support — SMUconlaw (talk) 15:50, 5 June 2017 (UTC)
4. Support Andrew Sheedy (talk) 20:30, 9 June 2017 (UTC)
5. Support --Dan Polansky (talk) I prefer proposal 1: we already exclude sum of parts items, so we only need something to ensure additional inclusion. By contrast, proposal 2 ensures additional exclusion, which is in fact redundant to what we already do in CFI. That said, pragmatically, proposal 2 is probably going to work as well, so I abstain on it. --Dan Polansky (talk) 21:16, 9 June 2017 (UTC)

   I disagree that the proposal 2 is redundant to what we already do in CFI. If the proposal 2 fails, we might have to discuss about keeping some entries like 101, one hundred and one and one thousand and one. Not all sum of parts items get deleted. Some are kept as "non-idiomatic translation targets". Numbers like twenty-three itself (which will be kept if the proposal 1 passes) are basically NITTs too. --Daniel Carrero (talk) 21:29, 9 June 2017 (UTC)

   I don't think there would be much discussion: one hundred and one contains "A great many; numerous" as a sense, and is therefore kept as idiomatic, per current CFI. Ditto for one thousand and one. --Dan Polansky (talk) 11:46, 10 June 2017 (UTC)

6. Support -Xbony2 (talk) 21:47, 12 June 2017 (UTC)
7. Support Mistrz (talk) 13:45, 14 June 2017 (UTC)
8. Support — Vorziblix (talk · contribs) 14:10, 23 June 2017 (UTC)
9. Support Ƿidsiþ 10:19, 28 June 2017 (UTC)

Oppose proposal 1

1. Oppose - [The]DaveRoss 13:09, 23 June 2017 (UTC)

Support proposal 2

1. Support --Daniel Carrero (talk) 00:49, 5 June 2017 (UTC)
2. Support, per above. bd2412 T 13:46, 5 June 2017 (UTC)
3. Support — SMUconlaw (talk) 15:50, 5 June 2017 (UTC)
4. Support Andrew Sheedy (talk) 20:31, 9 June 2017 (UTC)
5. Support Equinox ◑ 21:35, 9 June 2017 (UTC)
6. Support -Xbony2 (talk) 21:47, 12 June 2017 (UTC)
7. Support - [The]DaveRoss 13:09, 23 June 2017 (UTC)
8. Support — Vorziblix (talk · contribs) 14:10, 23 June 2017 (UTC)

Oppose proposal 2

1. Oppose I realized I actually oppose. This exclusion rule does not need to be added, I think, since it is covered by sum of parts terms being excluded except for a partially specified set of exceptions. Proposal 1 provides that numbers 0 to 100 are an exception to be kept; an addition of proposal 2 is redundant. --Dan Polansky (talk) 16:35, 16 June 2017 (UTC)
2. Oppose I see no reason to exclude them. Ƿidsiþ 10:22, 28 June 2017 (UTC)

---

Allowing character boxes

Voting on: Allowing the use of {{character info/new}} in all single-character entries.

Schedule:

• Vote starts: 00:00, 12 June 2017 (UTC)
• Vote ends: 23:59, 11 July 2017 (UTC)
• Vote created: --Daniel Carrero (talk) 09:54, 5 June 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/May#'character info' box
• Wiktionary talk:Votes/2017-06/Allowing character boxes

Support

1. Support --Daniel Carrero (talk) 18:08, 11 June 2017 (UTC)

   Some context: I'm pretty sure all single-character entries already have the character boxes. I could probably name at least three or four people other than myself who helped a lot to achieve that since boxes were created in 2009. (but then again, if I ping them, I'll be technically calling them specifically to vote here, which seems wrong) I created this vote because the character boxes were being recently discussed in Wiktionary:Beer parlour/2017/May#'character info' box, some people seemed to oppose keeping the boxes. Personally, I like the boxes. That said, I'm interested in what will happen after this vote ends.

   If the vote fails and we follow the rule "When a vote fails, ignore it, the status quo prevails." then the boxes would be kept anyway because I believe keeping them is the status quo. But it should be easier to discuss further about deleting them.

   If the vote fails and we follow the rule "We can't have or do anything that failed a vote." then we would have to automatically delete the boxes... I suppose?

   Well, I hope it passes, anyway. --Daniel Carrero (talk) 18:18, 12 June 2017 (UTC)

   One thing about {{character info/new}} that I like is having multiple character boxes to display what exactly are the codepoint variations for the same character, which are usually redirects to the main entry. In the entry $, there are character boxes for $ (the normal dollar sign), 💲 ("heavy dollar sign"), ﹩ ("small dollar sign") and ＄ ("fullwidth dollar sign"). --Daniel Carrero (talk) 18:03, 14 June 2017 (UTC)

2. Support -Xbony2 (talk) 21:45, 12 June 2017 (UTC)
3. Support. Part of the purview of an online dictionary that covers characters in the age of Unicode. —Μετάknowledge^{discuss/deeds} 17:45, 13 June 2017 (UTC)
4. Support, but make them way less obtrusive. Andrew Sheedy (talk) 22:52, 18 June 2017 (UTC)

   I second that. I like the boxes, but they could be smaller, especially when there are various boxes in an entry, like at $. --Daniel Carrero (talk) 23:16, 18 June 2017 (UTC)

5. Support — Vorziblix (talk · contribs) 13:59, 23 June 2017 (UTC)

Oppose

1. Oppose --WikiTiki89 17:28, 12 June 2017 (UTC)
2. Oppose Don't really want to see this on digits and suchlike. Equinox ◑ 17:31, 12 June 2017 (UTC)
3. Oppose Mistrz (talk) 14:18, 14 June 2017 (UTC)
4. Oppose. Keep them only on "extreme" characters. I especially think these boxes are merely unwelcome clutter on U+4E00 to U+9FA5 (they have literally no useful information, unlike the Unihan link in Translingual > References), and for those using Tabbed Languages, it doesn't help that they're outside ==Translingual==. —suzukaze (t・c) 18:13, 14 June 2017 (UTC)

   What characters would you consider "extreme" for that purpose? --Daniel Carrero (talk) 18:26, 14 June 2017 (UTC)

   𫠠, CJK UNIFIED IDEOGRAPH-2B820 from CJK Unified Ideographs Extension E which was introduced in June 2015. Very, very few fonts support the newer blocks of CJK characters, partly because they're new and partly because no-one cares (unlike, say, Tangut, which was introduced in June 2016). —suzukaze (t・c) 18:29, 14 June 2017 (UTC)

   If we remove the character box from most entries, why keep it in 𫠠 at all? If the reasoning is showing an image and character information for a character that "Very, very few fonts support", then it would follow that any character with few supporting fonts should have the box. --Daniel Carrero (talk) 05:02, 17 June 2017 (UTC)

   If you can't see the character (don't have the right fonts), then the only other possible way to identify it is by name, which would be provided by {{character info/new}}. Also, I've changed my mind for hanzi entries. I think they shouldn't be on any of them since {{Han ref}} is more useful in all cases. I'd like to change my example to 𒀉 (definitely a "weird" character that is unavailable for many, although Segoe UI Historic, which supports it, seems to come with Windows 10). —suzukaze (t・c) 07:20, 19 June 2017 (UTC)

   It also serves as an easy, on-wiki way to identify homoglyphs (for example, it can dispel confusion over the {{also}} entries at ə). —suzukaze (t・c) 06:06, 20 June 2017 (UTC)

5. Oppose I never liked these character boxes, we're not a Unicode database. I don't really think we should even have entries about characters; alphabets would be much better suited to an appendix page. I also share Suzukaze's objection of having them outside a language section, which takes up extra space with Tabbed Languages. —CodeCat 18:29, 14 June 2017 (UTC)
6. Oppose - [The]DaveRoss 13:10, 23 June 2017 (UTC)
7. Oppose --Droigheann (talk) 15:55, 25 June 2017 (UTC)
8. Oppose — Saltmarsh. 04:43, 27 June 2017 (UTC)

Abstain

1. Abstain It might be good for pages that have few definitions and much space on the right; they are usually short. They can display variations which are not able to have their own pages due to policies. But it might be bad for pages that have many definitions and/or too many boxes stacking up. I can't decide. However, I will continue keeping them on Thai Wiktionary. Octahedron80 (talk) 07:33, 19 June 2017 (UTC)

   @Octahedron80: Do you think you would support keeping the character boxes in all single-character entries if the boxes were way smaller (possibly either by being collapsed by default and/or having less information)? --Daniel Carrero (talk) 05:49, 20 June 2017 (UTC)

   I prefer minimum width as Wikipedia box. I am okay if the stacking boxes can be merged into one box/template so they could be much smaller. --Octahedron80 (talk) 06:00, 20 June 2017 (UTC)

---

borrowing, borrowed

Note: All the proposals below concern the template {{bor}}. The other templates are shown for comparison purposes only.

This is the status quo:

{{bor}}, {{cal}}, {{der}} and {{inh}} as of June 2017
Template	Syntax	Result	Notes
{{bor}}	{{bor|en|it|pizza}}.	Borrowing from Italian pizza.	"Borrowing from" is added automatically, with a link to "loanword" in Appendix:Glossary.
	{{bor|en|it|pizza|nocap=1}}.	borrowing from Italian pizza.	Same as above, except nocap=1 causes "borrowing" to start with a lowercase b.
	{{bor|en|it|pizza|notext=1}}.	Italian pizza.	notext=1 removes "Borrowing from" altogether.
{{cal}}	{{cal|en|fr|surnom}}.	Calque of French surnom.	"Calque of" is added automatically, with a link to "calque" in Appendix:Glossary.
	{{cal|en|fr|surnom|nocap=1}}.	calque of French surnom.	Same as above, except nocap=1 causes "calque" to start with a lowercase c.
	{{cal|en|fr|surnom|notext=1}}.	French surnom.	notext=1 removes "Calque of" altogether.
{{der}}	From {{der|en|it|pizza}}.	From Italian pizza.	The template does not add "Derived from" anywhere. Instead, many entries have "From" manually added before the template, without the word "Derived".
{{inh}}	From {{inh|en|it|pizza}}.	From Italian pizza.	The template does not add "Inherited from" anywhere. Instead, many entries have "From" manually added before the template, without the word "Inherited".
Issues to consider: The template output of {{bor}} is consistent with templates such as {{cal}} and {{bac}}, yet arguably inconsistent with {{der}} and {{inh}}. The text "Borrowing from" is ungrammatical, and more often than not would be better replaced by "Borrowed from".

Voting on:

• Proposal 1: Remove the "Borrowing from" text altogether from the output of {{bor}}, and add "Borrowed from" outside the template. Feel free to state if you think a link to Appendix:Glossary#loanword is necessary or not.

Syntax	Result
Borrowed from {{bor|en|it|pizza}}.	Borrowed from Italian pizza.
Rationale for proposal 1: This would cause {{bor}} to function exactly the same way as {{der}} and {{inh}}, for consistency. Arguably, it's simpler and easier to write normal text, as opposed to using parameters like "notext=1" and "nocap=1". Currently, some Ido and Esperanto terms may have etymologies like this, requiring the use of the code "notext=1" many times: "Borrowed from English ..., German ..., Italian ..., Spanish ..., Portuguese ..., Russian ..., Greek ..." This proposal also converts -ing to -ed.

• Proposal 2: Introduce a new parameter called "ger=1". Make {{bor}} display "Borrowed from" by default, except it shows "Borrowing from" when "ger=1" is enabled. Add, by bot, "ger=1" in all entries that currently display "Borrowing from". This may be used as a first step to use "Borrowed from" in all entries.

Syntax	Result
{{bor|en|it|pizza}}.	Borrowed from Italian pizza.
{{bor|en|it|pizza|ger=1}}.	Borrowing from Italian pizza.
Rationale for proposal 2: The functionality of {{bor}} is consistent many templates, including {{cal}}, {{bac}}, {{nam}}, {{blend}}, etc. It is also arguably consistent with {{der}} and {{inh}}, which only lack Derived from and Inherited from, respectively, because they would be superfluous. The vast majority of {{bor}} usages appear at the beginning of an etymology, and don't require |nocap= or |notext=. Having to type Borrowed from for each use is much more time consuming and will, in all likelihood, lead some editors to omit it altogether. Having a link to the glossary helps readers to understand the difference between an inherited term and a borrowed term.

If any of these proposals passes, feel free to use these template tracking categories to edit the entries. The categories are expected to be deleted at some point.

• Category:bor with notext
• Category:bor without notext
• Category:bor with nocap
• Category:bor without nocap
• Category:bor with lang

Schedule:

• Vote starts: 00:00, 14 June 2017 (UTC)
• Vote ends: 23:59, 13 July 2017 (UTC)
• Vote created: --Daniel Carrero (talk) 13:55, 7 June 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/February#Changing the text of Template:bor from "borrowing" to "borrowed"
• User talk:Daniel Carrero/2016#bor with nocap
• Template talk:borrowing#Borrowed
• Wiktionary talk:Votes/2017-06/borrowing, borrowed

Support — proposal 1

1. Support for consistency between {{bor}}, {{der}} and {{inh}}. --Daniel Carrero (talk) 01:40, 14 June 2017 (UTC)
2. Support. It's more work to have to override it than it would be to just type the words "borrowed from". --WikiTiki89 17:20, 14 June 2017 (UTC)

   I rather more work for ~10% of entries than more work for ~90% of entries. --Victar (talk) 19:35, 14 June 2017 (UTC)

   But it's a different kind of work. Typing an extra word when you're already typing a lot of things is not really extra work because it just goes with the flow of what you're doing. But adding an extra parameter to a template is much more disruptive. --WikiTiki89 19:40, 14 June 2017 (UTC)

   I think that's arguable and probably varies by person. For me, that would not be the case. I think two other points need to be addressed as well: 1. Given human nature, people will lazily or forgetfully omit adding Borrowed and 2. The benefit of linking to the glossary, which admittedly, could be improved. --Victar (talk) 19:51, 14 June 2017 (UTC)

   If the proposal 1 passes and you would like to make the text "Borrowed from" appear without typing it, we could use a subst like {{subst:new bor|en|ja|something}} which would return "Borrowed from {{bor|en|ja|something}}".

   I don't mind if some people omit the "Borrowed". We can probably run bots later to check for uses of {{bor}} without a "borrowed" in the same etymology section. If we assume that people will sometimes add "borrowed from" when needed and never remove it, the number of "borrowed from" will always increase. And the borrowing categories will probably be filled more easily because we will simply add the {{bor}} without having to worry about the default template text, which won't exist anymore.

   I added a link to the glossary in the sidebar today, between "Help" and "Donations". I don't think we need to link all instances of "borrowed" to the glossary (but it can be linked if other people want). We don't link all instances of "adverb", "diminutive", "present participle", "suffix" and other linguistical terms. --Daniel Carrero (talk) 22:51, 26 June 2017 (UTC)

3. Support per Wikitiki89. Generally speaking, I don't want any default text in etymology templates. --Barytonesis (talk) 10:05, 17 June 2017 (UTC)
4. Support in general, although I don't agree that there's anything ungrammatical about "borrowing" as opposed to "borrowed". Ƿidsiþ 11:31, 17 June 2017 (UTC)

   Right, probably not really "ungrammatical", but grammatically inconsistent, ex. Possible borrowing from French xxx, possibly from Latin xxx vs. Possibly borrowed from.... --Victar (talk) 23:04, 17 June 2017 (UTC)

   But you could make the same argument for saying "calqued" instead of "calque". Ƿidsiþ 08:15, 18 June 2017 (UTC)

   The standard text would be OK more often if the template said either "A borrowing from" or "Borrowed from", but it currently says only "Borrowing from". --Daniel Carrero (talk) 08:18, 18 June 2017 (UTC)

5. Support. Andrew Sheedy (talk) 22:59, 18 June 2017 (UTC)

   @Andrew Sheedy: any thoughts? --Victar (talk) 12:17, 20 June 2017 (UTC)

   I like consistency (so I support per Daniel, I guess). :P Andrew Sheedy (talk) 16:18, 20 June 2017 (UTC)

   Me too, so please see my arguments on consistency. --Victar (talk) 17:00, 20 June 2017 (UTC)

   I like consistency, too. To be fair, "consistency" can be applied to any situation where everything happens the same way. One completely consistent system can be replaced by another completely consistent system. It would be nice to consistently not have any automated text in {{bor}}, like it's already done in {{der}} and {{inh}}. This would still be inconsistent with other templates like {{cal}}, which have the automated text and are not affected by this vote. In my opinion, it would be even better if all templates like these didn't have the automated text. Manual text would be freely added as needed. (sorry for repeating arguments sometimes, they seem applicable here and elsewhere too) --Daniel Carrero (talk) 03:00, 21 June 2017 (UTC)

   If your goal is universal consistency, that meanes removing lead text from all etymology templates, including {{cal}}, {{blend}}, {{translit}}, {{bac}}, {{clipping}}, etc. The truth is {{der}} and {{inh}} are outliers. --Victar (talk) 21:48, 21 June 2017 (UTC)

   I would support it. --Barytonesis (talk) 15:43, 22 June 2017 (UTC)

   I think that's a battle that would be met with quite a lot of resistance. --Victar (talk) 16:12, 22 June 2017 (UTC)

   Any evidence for that? If this was not discussed/voted before, we don't know what other people might think. --Daniel Carrero (talk) 16:37, 22 June 2017 (UTC)

   @Daniel Carrero: I don't need evidence for my thoughts, but can tell you that a) people are lazy and b) people don't like change. --Victar (talk) 17:17, 22 June 2017 (UTC)

   I love when some stuff changes (improvement is a hyponym of change), so I know for a fact that the point b does not apply to 100% of the world population. All votes that pass change something. If proposal 1 or 2 passes here, things will change. --Daniel Carrero (talk) 17:34, 22 June 2017 (UTC)

   You're preaching to the choir. Again, though, there are no absolutes, no universalities, no one-size-fits-all. I'm just speaking about the majority. If the majority of people weren't complacent, we would have changed "borrowing" 6 years ago! --Victar (talk) 20:08, 22 June 2017 (UTC)

   Your last sentence is not necessarily a symptom of complacency. I mean, it does not mean people were happy or apathetic with "borrowing". It's just hard to reach an agreement and change stuff that affects thousands of entries, and we may have other priorities in mind. I don't mind preaching to the choir. I don't mind saying some obvious things, this way the conversation is clearer. We'll see where the majority lies after this vote ends. If the result is inconclusive, we might need new discussions and/or votes. I don't mind waiting. --Daniel Carrero (talk) 05:06, 23 June 2017 (UTC)

6. Support —CodeCat 16:15, 22 June 2017 (UTC)
7. Support - [The]DaveRoss 13:11, 23 June 2017 (UTC)
8. Support - I am in favour of removing default text from all such templates. BigDom 15:52, 24 June 2017 (UTC)

Oppose — proposal 1

1. Oppose Is inconsistent with with other like templates, and puts the manual burden on editors. --Victar (talk) 02:30, 14 June 2017 (UTC)
2. Oppose Why would I vote for having more work? Template already has notext, so this vote just inverts the template to default to something that's only useful in fringe cases. Korn [kʰũːɘ̃n] (talk) 08:35, 14 June 2017 (UTC)

   Exactly true. And for what, flipping Esperanto? --Victar (talk) 16:12, 14 June 2017 (UTC)

   I know your "And for what?" sounds sarcastic, but I'll try to answer where exactly the proposal 2 means less work:

   Of all entries using {{bor}}, 10%+ entries (approx. 4,000 entries) use either "notext=" or "nocap=". (Category:bor with notext = 2,056 entries; Category:bor with nocap = 1,901 entries). They are, obviously, cases where you don't need the "borrowing from" or it's not at the start of the line. The remaining 90%- entries (37,000+ entries) without these parameters are the default "forced" text, it's not clear they're is always needed that way even though that's the majority -- there's simply not much room for improvement if the text has already been decided by the template. Sorry for the lack of diffs (I don't remember), but I've seen quite a few entries using {{der}} where the correct choice would be {{bor}} with no text (because "borrowing" or "borrowed" was already previously mentioned). It could be just me, but I find it natural to type "Borrowed from" because it's what we actually mean at the time and it's a pain to type something not to type something -- that is, typing "notext=1" because we don't want any text. --Daniel Carrero (talk) 17:53, 14 June 2017 (UTC)

   By "needed", do you mean proper uses versus, improper uses, like in the middle of an etymology? If so, I think that's pretty negligible. Joking aside, with Esperanto, etc., I wonder if we should make a second templates, like {{borindex|eo|en|xxx|de|xxx|it|xxx|es|xxx|pt|xxx|ru|xxx|grc|xxx}}. --Victar (talk) 19:20, 14 June 2017 (UTC)

   I also want to point out that most of those |nocap=1 entries are from a) people fixing the grammar, ex. A {{bor|nocap=1}} from, and b) people incorrectly using {{bor}} mid-etymology, ex. From {{inh|en|enm}}, a {{bor|en|fro|nocap=1}} from --Victar (talk) 19:44, 14 June 2017 (UTC)

   I don't know what you mean by "incorrectly". There are plenty of reasons for using {{bor}} in places other than the very beginning of the etymology. The etym 2 of arpagone starts with "1829 borrowing from French harpagon, ..." It's great that it has the year. Ideally, all etymologies should have the year of origin! (I know that does not seem always possible for all words in all languages.) --Daniel Carrero (talk) 19:51, 14 June 2017 (UTC)

   @Daniel Carrero: I said most, not all, and gave two examples of it being misused. If you go through that category at random, you'll see that the majority fall under those two cases. --Victar (talk) 19:55, 14 June 2017 (UTC)

   I've also been thinking about how some templates could use a |dat= date parameter. I could really use one in {{desctree}}. --Victar (talk) 20:03, 14 June 2017 (UTC)

   @Victar: only noticing this now, but I rather like that idea. --Barytonesis (talk) 17:16, 27 June 2017 (UTC)

3. Oppose Mistrz (talk) 13:51, 14 June 2017 (UTC)
4. Oppose -Xbony2 (talk) 22:09, 14 June 2017 (UTC)
5. Oppose per Korn above — Vorziblix (talk · contribs) 14:06, 23 June 2017 (UTC)

Support — proposal 2

1. Support: {{bor}}, as is, is consistent with all like templates, including {{der}} and {{inh}}. See arguments above. --Victar (talk) 02:27, 14 June 2017 (UTC)
2. Support I guess… Mistrz (talk) 13:53, 14 June 2017 (UTC)
3. Support -Xbony2 (talk) 22:12, 14 June 2017 (UTC)
4. Support if proposal 1 fails. --Barytonesis (talk) 10:05, 17 June 2017 (UTC)

   @Barytonesis: If the proposal 1 passes, would you like to vote "oppose" or "abstain" on the proposal 2? --Daniel Carrero (talk) 16:49, 27 June 2017 (UTC)

   @Daniel Carrero: then I'd say Oppose. Now I'm thinking, how funny would it be if both proposals passed? This probably won't happen, but how should we proceed then? --Barytonesis (talk) 16:52, 27 June 2017 (UTC)

   I'm not sure and I would welcome further discussion if this happens.

   I'll suggest one possibility. But we don't need to take my word on this because I kind of have a conflict of interest: if both proposals pass, we could simply implement the proposal 1 because it's the most "extreme" one. If both proposals passed and we somehow had to implement both simultaneously, then the addition of "ger=1" would be redundant with the whole idea of taking the default text outside the template. But again, the supporters of the proposal 2 might consider this unfair. One alternative possibility would be keeping the status quo and not implementing any proposal. --Daniel Carrero (talk) 17:05, 27 June 2017 (UTC)

5. Conditional support. See my "conditional oppose" below. --Daniel Carrero (talk) 16:47, 27 June 2017 (UTC)

Oppose — proposal 2

1. Conditional oppose. I prefer the proposal 1. --Daniel Carrero (talk) 01:41, 14 June 2017 (UTC)

   If the proposal 1 passes, I vote oppose the proposal 2.

   If the proposal 1 fails, I vote support the proposal 2.

   I prefer the proposal 1, but the proposal 2 is better than nothing. --Daniel Carrero (talk) 16:42, 27 June 2017 (UTC)

2. Oppose. No real benefit compared to option 1. —CodeCat 16:16, 22 June 2017 (UTC)
3. Oppose - [The]DaveRoss 13:12, 23 June 2017 (UTC)

   @TheDaveRoss: Any reasoning behind your vote? --Victar (talk) 14:03, 23 June 2017 (UTC)

   Yup. I voted oppose because I oppose the proposal. Specifically I think it makes the use of the template an order of magnitude more difficult for those who aren't current on the most recent ways we have found to make it impossible for new or more casual editors to contribute. We are well down the road to having just one template with thousands of unnamed parameters which generate the entirety of the page text through module-based psuedo-databases. Any time now the only pages which won't have module errors will be redirects. - [The]DaveRoss 14:13, 23 June 2017 (UTC)

   @TheDaveRoss: I think perhaps you misunderstand the proposals. The point of this vote is to change the existing text of Borrowing from to Borrowed from. What part do you see being made a "magnitude more difficult"? --Victar (talk) 14:26, 23 June 2017 (UTC)

   Correction: The point of the proposal 2 is changing the existing text. The point of the proposal 1 is doing that and also removing the template text altogether.

   The addition of "ger=1" makes the template more difficult to use. It's one more way to suppress or edit the template text instead of just typing "Borrowed from" normally. (even if the "ger=1" is intended to be kept just temporarily, we'd still would need the time to review all the ~40,000 affected entries)

   Having any kind of text like "Borrowing from" or "Borrowed from" returned by the templates probably makes it difficult for new or more casual editors to contribute because they have to build their texts around the default template text or consciously make it disappear. They may have to read the (sometimes large) documentations. Typing "notext=1" is not a very intuitive thing to do.

   I see you specifically said above that you even want to add a "dat=" parameter meaning "date" to some templates after I mentioned the "1829 borrowing from French harpagon, ..." Adding that parameter to {{bor}} to show the year in the resulting text would seem like a terrible idea, you can just type the year outside the template. (I probably wouldn't mind having some template around the year for categorization purposes only.)

   Today I fixed vegeburger, whose etymology had two "Blend of" this by mistake: "Blend of vegetable +‎ burger, Blend of vegetarian +‎ burger, or alteration of veggie burger" (this revision). --Daniel Carrero (talk) 22:24, 26 June 2017 (UTC)

   @Daniel Carrero: First off, answering for another user as a way to push your agenda is both cheap and disruptive to a discussion. Secondly, to say the addition of |ger=1 will make the {{bor}} "more difficult to use" is purposefully misleading and an argument fallacy. You know as well as I that the intention of |ger=1 is simply a transitional tool for converting existing instances of Borrowing and Borrowed and is not by and means intended for actual use. If someone wishes to change the lead text back from Borrowed to Borrowing (why, I have no clue) they should use the existing |notext=1. Thirdly, this is a vote for {{bor}} not {{blend}}, but to your point, anyone can find some rare and unusual case, but we should cater to the majority of uses, not the obscure. --Victar (talk) 23:12, 26 June 2017 (UTC)

   Also, my to TheDaveRoss reply doesn't need correcting. The end goal of both proposals is to change Borrowing to Borrowed. They differ only in implementation. --Victar (talk) 00:01, 27 June 2017 (UTC)

   What I did was not cheap or disruptive at all. You simply asked a question about problems with the proposal 2 to which I had the answer. It does not matter who has the answer. It would be convenient for the proposal 2 if people were not allowed to talk about the problems it has.

   The proposed "ger=1" as a "transitional tool" affects ~40,000 entries and therefore may have to used for quite a while, so it affects the difficulty in using the template. If thousands of entries have {{bor|xx|yy|ger=1}} for a few months or years, new editors will probably feel they have to learn about the new parameter, unless we can remove it faster. (I think we are repeating arguments too much.)

   Ideally, all (or most, or many) etymologies will have the (real or approximate) year of coinage, resulting in cases like "1829 borrowing from French harpagon, ..." and therefore entries like this will need to use "nocap=1" if the default template still exists, not only some rare cases.

   In the future, I'd like to create a vote to let the text "Blend of", "Calque of", etc. to be placed outside templates like {{blend}} and {{cal}}. One person above said they would support doing it. Doing it with {{bor}} is one of the very important points of the proposal 1. In my view, you misrepresented the proposal 1, hence my correction. Although I get that you don't like the proposal 1. --Daniel Carrero (talk) 08:50, 27 June 2017 (UTC)

   That's complete horseshit. A parameter that has no intended use has zero affect on its difficulty in use. I'm so tired of your bullshit obscure usages that mean nothing to 99% of people. I'm done arguing with you in ridiculous circles. --victar (talk) 12:43, 27 June 2017 (UTC)

   Your "99% of people" is inconsistent with the vote count as of now. --Daniel Carrero (talk) 12:51, 27 June 2017 (UTC)

   I'm not angry with you, but your last message was rude. I'm going to assume you are out of arguments. --Daniel Carrero (talk) 12:52, 27 June 2017 (UTC)

   99% of people that use {{bor}}, not 99% of this vote, flipping obviously. I'm not out of arguments, I'm out of patience with your dragging a dead horse in circles. --Victar (talk) 12:56, 27 June 2017 (UTC)

   This vote is representative of real-life uses of {{bor}}. People who use the template are voting now. I realize it would be easier for the proposal 2 to pass if I and other people were not allowed to criticize it. --Daniel Carrero (talk) 13:11, 27 June 2017 (UTC)

   Guys, it's only a template. And even if this vote doesn't yield our respective preferred result, there's already been an improvement, since all documentation pages have been completed. --Barytonesis (talk) 12:57, 27 June 2017 (UTC)

   However, I think that the two proposals should have been voted on successively and separately (preferably proposal 1 first, since it is the most "aggressive" one). I suspect all the opposing votes to proposal 2 here don't really concern the issue at stake (that is, the choice of "borrowed" over "borrowing", which nobody is opposed to in itself, as far as I understand), but rather ensue from a support vote to proposal 1. Right now we're heading towards the status quo... --Barytonesis (talk) 13:06, 27 June 2017 (UTC)

   Thanks for the idea. I think I would have been fine with voting first for the proposal 1 only and then the proposal 2 later, but I'm afraid this gives an advantage to the proposal 1. I don't know if supporters of the proposal 2 would see this system as unfair. --Daniel Carrero (talk) 13:17, 27 June 2017 (UTC)

   Yes, that's what bothers me with the idea. But doing it the other way around would maybe sound a bit ridiculous/uselessly procedural: "yeah, we replaced all instances of "borrowing" with "borrowed", now we're proposing to remove any text altogether" (although I would be fine with such a way of proceeding). --Barytonesis (talk) 13:49, 27 June 2017 (UTC)

   If someone thinks "I prefer the proposal 1, but if it fails then the proposal 2 is better than nothing!", they can vote "Support proposal 1" and "Support proposal 2 only if the proposal 1 fails!", like you did. --Daniel Carrero (talk) 13:28, 27 June 2017 (UTC)

   Yes, but I'm afraid the two proposals got somewhat "linked" in people's minds: "if I vote yes for one, I vote no for the other, and conversely." You personally, regardless of your preference for proposal 1, do you actually object to replacing "borrowing" with "borrowed"? --Barytonesis (talk) 13:49, 27 June 2017 (UTC)

   I'm not sure. I've been thinking. On the one hand, any default text has the problems stated elsewhere. On the other hand, if we do have the text, it's better to have "borrowed" than "borrowing". Well, OK. I'll vote "Support proposal 2 only if the proposal 1 fails!" I can't promise I won't change my mind later, but for now it seems this can't hurt. --Daniel Carrero (talk) 16:40, 27 June 2017 (UTC)

   I think another point we mostly agree on is a desire for consistency. The problem is the consistency can go either way at the moment. I think there should be a larger vote on whether etymology templates with lead text should be lead text free. --Victar (talk) 17:00, 27 June 2017 (UTC)

   I agree, and I agree. --Barytonesis (talk) 17:16, 27 June 2017 (UTC)

   I agree. --Daniel Carrero (talk) 17:36, 27 June 2017 (UTC)

4. Oppose - prefer proposal 1 as I would prefer to see default text removed altogether. BigDom 15:54, 24 June 2017 (UTC)

Abstain — proposal 2

1. Abstain Don't think it's worth the effort, but if it makes you happy...Korn [kʰũːɘ̃n] (talk) 08:36, 14 June 2017 (UTC)

   Most of the effort has been in creating this vote! Running a bot would just take a few minutes. =) --Victar (talk) 16:09, 14 June 2017 (UTC)

   Actually, there's effort involved: if any proposal (1 or 2) passes, we'll have the chance to do the work of changing "-ing" to "-ed" in all entries, unless it turns out no one wants to do it, which seems unlikely. But let the people interested in the proposals judge by themselves if this kind of work is worth their time. --Daniel Carrero (talk) 16:26, 14 June 2017 (UTC)

   That's true. I meant the module change itself. --Victar (talk) 19:30, 14 June 2017 (UTC)

   @Korn: So if it comes down to it, would you rather neither pass? Did you have an alternative idea? --Victar (talk) 22:50, 17 June 2017 (UTC)

   Alternative to what? The alternative is the status quo, innit? In case of prop 1 I prefer it, with regards to prop 2 I don't care at all. ps.: Concerning 'effort': Whoever does anything could spend that time doing something else. That's all I mean. Korn [kʰũːɘ̃n] (talk) 11:33, 18 June 2017 (UTC)

---

Wikidata precautionary principle

Voting on:

Implementing this rule concerning the use of Wikidata. The ellipsis (...) shall be replaced by any of the proposals below:

Any and all edits using Wikidata must (...), otherwise they shall be reverted on sight. This applies to the use of Wikidata in entries, templates, categories, appendices and any other pages.

Some exceptions apply, which may freely use Wikidata for tests and proposals:

1. sandbox pages (such as Wiktionary:Sandbox, Template:sandbox and Module:sandbox, and subpages such as Template:en-noun/sandbox)
2. user pages and subpages
3. discussion pages
4. new templates and modules, if they are not transcluded anywhere (other than transclusions in the exceptional pages mentioned here)

Proposal 1:

"...have been previously approved by vote..."

Proposal 2:

"...have been previously approved in a discussion or vote..."

Procedural note:

If both proposals pass, then the proposal 1 takes precedence, because it's the stricter one.

Schedule:

• Vote starts: 00:00, 18 June 2017 (UTC)
• Vote ends: 23:59, 17 July 2017 (UTC)
• Vote created: --Daniel Carrero (talk) 00:27, 11 June 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/June#Wikidata precautionary principle
• Wiktionary talk:Votes/pl-2017-06/Wikidata precautionary principle

Support — proposal 1

1. Support per my rationale at the talk page. --Daniel Carrero (talk) 19:36, 17 June 2017 (UTC)
2. Support. Andrew Sheedy (talk) 23:01, 18 June 2017 (UTC)
3. Support —Μετάknowledge^{discuss/deeds} 00:27, 19 June 2017 (UTC)
4. Support --WikiTiki89 14:41, 23 June 2017 (UTC)
5. Support DTLHS (talk) 17:14, 23 June 2017 (UTC)
6. Support Requiring votes seems very reasonable given the potential for harm resulting from the use of Wikidata that I see. --Dan Polansky (talk) 07:55, 24 June 2017 (UTC)

Oppose — proposal 1

1. Oppose. Overly legalistic. We can build and achieve consensus for at least some uses of Wikidata via discussion rather than vote. - [The]DaveRoss 13:15, 23 June 2017 (UTC)
2. Oppose -Xbony2 (talk) 21:17, 23 June 2017 (UTC)
3. Oppose. Raises the bar too high, overly reactionary. —CodeCat 12:40, 29 June 2017 (UTC)

Support — proposal 2

1. Support. While I am sensitive to the concerns of those who think Wikidata as a whole is a negative addition, I think that there are benign enough uses that a simple discussion can be adequate (just like small changes in other areas). Let's have some faith in one another. - [The]DaveRoss 13:14, 23 June 2017 (UTC)
2. Support. Discussion is enough, I hope. -- Andrew Krizhanovsky (talk) 17:13, 23 June 2017 (UTC)
3. Support -Xbony2 (talk) 21:17, 23 June 2017 (UTC)
4. Support —CodeCat 12:40, 29 June 2017 (UTC)

Oppose — proposal 2

1. Oppose per my rationale at the talk page. --Daniel Carrero (talk) 19:36, 17 June 2017 (UTC)

   Further comment: I hope the proposal 1 passes, requiring a vote seems the best course of action because we are starting to use Wikidata right now and I'm not sure what we're going to do with it.

   Let's assume for a second that the proposal 1 will pass. Then, maybe after a few years, when we have a few accepted and rejected Wikidata use cases, we may revisit this and decide whether we can lower that restriction and simply requiring discussions to use Wikidata, or if requiring votes is still a good idea. --Daniel Carrero (talk) 13:27, 23 June 2017 (UTC)

---

CFI leading sentence

Voting on: Expanding the leading sentence of WT:CFI as follows:

Proposal 1:

As an international dictionary, Wiktionary is intended to include basically “all words in all languages”.

Proposal 2:

As an international dictionary, Wiktionary is intended to include basically “all words in all languages”, subject to the following criteria.

Proposal 3:

As an international dictionary, Wiktionary is intended to include “all words in all languages”, subject to the following criteria.

Schedule:

• Vote starts: 00:00, 23 June 2017 (UTC)
• Vote ends: 23:59, 22 July 2017 (UTC)
• Vote created: Dan Polansky (talk) 16:11, 16 June 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/June#All words in all languages
• Wiktionary talk:Votes/pl-2017-06/CFI leading sentence

Support proposal 1

1. Support --Daniel Carrero (talk) 01:06, 23 June 2017 (UTC)
2. Support As for "basically" being too informal, I did not know that, not being a native speaker. However, what the word basically does, being informal or not, is that it turns a false statement to a true statement. Clarity is not at stake, accuracy is. The only thing that can save the sentence is the present use of quotation marks; that suggests that what is in the quotation marks is to be taken with grain of salt. --Dan Polansky (talk) 07:45, 24 June 2017 (UTC)

   Here are a few synonyms of "basically" we can consider using: essentially, fundamentally, mainly, in essence, substantially, chiefly, primarily, mostly. --Daniel Carrero (talk) 07:52, 24 June 2017 (UTC)

   Yes, that is how I read the quotation marks. There's nothing else they can mean, unless we are actually quoting somebody else. Equinox ◑ 13:06, 24 June 2017 (UTC)

   Will this meaning of quotation marks be obvious to the international audience for which English is not the first language? Is not the use of quotation marks for the purpose even more informal than the use of the word "basically"? It certainly is very inexplicit, to my eye. --Dan Polansky (talk) 16:50, 25 June 2017 (UTC)

Oppose proposal 1

1. Oppose I don't like the "basically". Too colloquial, wrong register IMO. Equinox ◑ 12:42, 23 June 2017 (UTC)
2. Oppose Both restatements add words without adding any value. - [The]DaveRoss 12:53, 23 June 2017 (UTC)
3. Oppose Makes it sound worse without significantly improving clarity. —Granger (talk · contribs) 16:04, 23 June 2017 (UTC)
4. Oppose, for the reasons others have stated. It basically ;) restates the sentence without clearly changing its signification / the scope of what is included. I agree with Equinox that the tone sounds subtly off, too (although that's subtle and possibly subjective). - -sche (discuss) 16:41, 23 June 2017 (UTC)
5. Oppose. "Basically" sounds carelessly imprecise to me. Germyb (talk) 17:08, 23 June 2017 (UTC)
6. Oppose -Xbony2 (talk) 21:18, 23 June 2017 (UTC)
7. Oppose per above. Plus "all words in all languages" is supposed to have a catchphrase kind of feel to it, and adding "basically" completely eliminates that and makes it sound cringy. Andrew Sheedy (talk) 02:01, 25 June 2017 (UTC)
8. Oppose See rationale under proposal 3 below. — Vorziblix (talk · contribs) 02:35, 27 June 2017 (UTC)

Oppose proposal 2

1. Oppose I don't like the "basically". Too colloquial, wrong register IMO. Equinox ◑ 12:42, 23 June 2017 (UTC)
2. Oppose Both restatements add words without adding any value. - [The]DaveRoss 12:53, 23 June 2017 (UTC)
3. Oppose The word "basically" makes it sound worse without significantly improving clarity. If we took out the word "basically", I would be okay with the other part of this proposal. —Granger (talk · contribs) 16:04, 23 June 2017 (UTC)
4. Oppose per Granger. I think the existing sentence is fine as an "aspirational" slogan which is obviously restricted by the following sections of the page, but I wouldn't mind adding the "subject to the following criteria" part, as a way of seguing into the rest of the page. - -sche (discuss) 16:41, 23 June 2017 (UTC)
5. Oppose, although I would be okay with it if we eliminated "basically". Germyb (talk) 17:08, 23 June 2017 (UTC)

   @Germyb, you should vote in support of the new proposal below then. Andrew Sheedy (talk) 02:04, 25 June 2017 (UTC)

6. Oppose -Xbony2 (talk) 21:18, 23 June 2017 (UTC)
7. Oppose per above. Andrew Sheedy (talk) 02:01, 25 June 2017 (UTC)
8. Oppose See rationale under proposal 3 below. — Vorziblix (talk · contribs) 02:35, 27 June 2017 (UTC)

Support proposal 3

1. Support --Daniel Carrero (talk) 08:04, 24 June 2017 (UTC)
2. Support Equinox ◑ 11:53, 24 June 2017 (UTC)
3. Support -Xbony2 (talk) 13:01, 24 June 2017 (UTC)
4. Support. Andrew Sheedy (talk) 02:01, 25 June 2017 (UTC)
5. Support, with the understanding that if there are criteria located elsewhere (not strictly "following" the sentence above and on the same page as it) which are currently in force governing the inclusion of words, this change will not be used to argue that they no longer apply. For example, Wiktionary and Wikimedia policies (and applicable laws) against copyright violations have been deemed to prevent en.Wikt from including overly large portions of certain constructed languages which originate in copyrighted works, like Klingon, although these policies are not located on WT:CFI (which never mentions the word "copyright" and only says to "have [a] lexicon[] in the Appendix namespace" for Klingon) but rather elsewhere. - -sche (discuss) 18:55, 25 June 2017 (UTC)
6. Support, since it is true that there are restrictions on which words we intend to include. Germyb (talk) 19:59, 25 June 2017 (UTC)

Oppose proposal 3

1. Oppose. Adds words without adding value. - [The]DaveRoss 18:04, 25 June 2017 (UTC)
2. Oppose As has been noted, it’s meant to be an idealistic aspirational slogan, like Wikipedia’s “sum of all human knowledge”. The intent is clear, in practice (here and on Wikipedia) everyone knows that practicality must temper this ideal with restrictions, CFI is in effect one way or the other, and so per TheDaveRoss it “adds words without adding value”. — Vorziblix (talk · contribs) 02:35, 27 June 2017 (UTC)

Abstain on proposal 3

1. Abstain. I don't think it's necessary—I think the current sentence is fine as an "aspirational" slogan, as -sche put it. But like I said above, I'm okay with this proposal. (Should we have an entry for be okay with/be OK with? It doesn't seem to be covered by any of the senses at OK.) —Granger (talk · contribs) 19:09, 25 June 2017 (UTC)

---

NORM: allow multiple spaces to align equal signs in templates

Voting on:

Part 1 — editing the rule 1 of WT:NORM#Templates, by adding "except whenever allowed in this policy" as follows:

1. No leading or trailing whitespace in templates (name, parameter name and value), except whenever allowed in this policy.

Part 2 - implementing this new rule in the same section:

4. For templates with line breaks between parameters, multiple spaces are allowed to align the equal signs (=) before the parameter values, for the purpose of making the wikitext easier to read. Example about {{multiple images}}:

{{multiple images
|direction = vertical
|image1    = Obverse of 50 ₨.jpg
|image2    = PKR Rs 1000.jpg
|image3    = 25 Seychellois rupee banknote.jpg
|footer    = Rupee banknotes from ''(top to bottom)'' [[Nepal]] (50 {{w|Nepalese rupee}}s), [[Pakistan]] (1,000 {{w|Pakistani rupee}}s), and the [[Seychelles]] (25 {{w|Seychellois rupee}}s)
}}

This vote has not yet started. It has been created to solicit advice on wording and fitness to purpose. Feedback and new ideas are highly encouraged! If you have not done so, please follow the discussion links for a better understanding of the topic. However, do not vote for any options at this time, as any premature votes may be struck. On the other hand, if the discussion is stagnant and there are no recent changes, anyone may choose to start this vote by properly listing it. Once the starting date has arrived, this banner may be ignored or removed.

Schedule:

• Vote starts: 00:00, 4 July 2017 (UTC)
• Vote ends: 23:59, 2 August 2017 (UTC)
• Vote created: --Daniel Carrero (talk) 17:26, 27 June 2017 (UTC)

Discussion:

• User talk:TheDaveRoss#Removal of spaces from templates
• Wiktionary talk:Votes/pl-2017-06/NORM: allow multiple spaces to align equal signs in templates

---

Templatizing topical categories in the mainspace

Voting on: Templatizing the markup for topical categories in the mainspace with one of two particular templates, {{topics}} or {{C}}. Thus, giving a full go ahead to all automatic and semiautomatic edits that replace the likes of "[[Category:nl:Mammals]]" with "{{topics|nl|Mammals}}" or "{{C|nl|Mammals}}". Note that the templates support multiple parameters, such as {{C|nl|Mammals|Zoology}}. Note that, currently, {{C}} is a redirect to {{topics}}. This proposal is about using templates for this purpose in general, and also about the particular template names to appear in wikitext in the mainspace.

Schedule:

• Vote starts: 00:00, 4 June 2017 (UTC)
• Vote ends: 23:59, 3 August 2017 (UTC)
• Vote created: Dan Polansky (talk) 08:09, 28 May 2017 (UTC)

Discussion:

• Wiktionary:Votes/2015-03/Templatizing topical categories in the mainspace
• Wiktionary:Requests for deletion/Others#Template:C
• Wiktionary talk:Votes/2017-05/Templatizing topical categories in the mainspace

Support for topics

1. Support —CodeCat 15:00, 4 June 2017 (UTC)

Oppose for topics

1. Oppose. See my "support for C" answer below. --Daniel Carrero (talk) 06:17, 4 June 2017 (UTC)
2. Oppose -Xbony2 (talk) 14:46, 4 June 2017 (UTC)
3. Oppose This name is transparent, but in a wrong way. I think it would lead to a greater number of bad edits. —Μετάknowledge^{discuss/deeds} 22:51, 4 June 2017 (UTC)
4. Oppose - [The]DaveRoss 13:18, 23 June 2017 (UTC)
5. Oppose. DonnanZ (talk) 23:40, 26 June 2017 (UTC)

Abstain for topics

1. Abstain I think {{topics}} is a fine name for the purpose. However, I am not convinced we need category markup templatized. --Dan Polansky (talk) 09:36, 4 June 2017 (UTC)
2. Abstain — Vorziblix (talk · contribs) 02:18, 27 June 2017 (UTC)

Support for C

1. Support --Daniel Carrero (talk) 06:17, 4 June 2017 (UTC)

   I support {{C}}, and oppose {{topics}}, because the former is the better of the two available options.

   I don't think {{C}} is a great name, but at least it has the distinction of being accurate, unlike {{topics}}. I'm assuming "C" means category, which is OK. (Unfortunately, it could mean basically anything starting with C.) The word "topic" may not be the best descriptor for all categories that use the format "Category:xx:Thing". Category:en:Cities in Ontario is for a list of cities and arguably some categories like Category:en:Neurology may be for medical jargon only.

   I won't suggest better template names to use right now, because I'd rather focus my energy on this proposal currently being discussed, which concerns all categories with a language code in the name: Wiktionary:Beer parlour/2017/June#Proposal: Clean up, rename and replace "en:" → "English" in all categories. --Daniel Carrero (talk) 06:17, 4 June 2017 (UTC)

2. Support -Xbony2 (talk) 14:46, 4 June 2017 (UTC)
3. Support and I would not object to {{cat}} — Saltmarsh. 06:26, 11 June 2017 (UTC)
4. Support - DonnanZ (talk) 23:44, 26 June 2017 (UTC)
5. Support but would prefer {{c}} or {{cat}}. Given that many of our template names are completely obscure to new users anyway ({{l}}, {{n-g}}, {{m}}, {{lb}}, {{ux}}, …) I’d say that ship has sailed. This name, at least, is convenient for editors. — Vorziblix (talk · contribs) 02:18, 27 June 2017 (UTC)

Oppose for C

1. Oppose I think having templates that differ only in capitalization is a bad idea: {{C}} and {{c}}. In the world of markup languages such as HTML, capitalization does not matter. In Mediawiki, capitalization does matter, but I still don't think we should have two single-letter-named templates that only differ in capitalization. {{cat}} would be okay as the name of the template, and still short. For completeness, I find the {{catlangname}} name awful for use in the mainspace. --Dan Polansky (talk) 09:35, 4 June 2017 (UTC)

   @Dan Polansky: I don't understand. {{C}} and {{c}} both redirect to the same target, so they're not functionally different. —Aɴɢʀ (talk) 19:34, 4 June 2017 (UTC)

   @Aɴɢʀ: My mistake; indeed, {{C}} and {{c}} both redirect to {{topics}}. I retract my above rationale for opposition, replacing it with a new one: {{C}} should not be capitalized, consistent with {{m}} and {{lb}}. I abstain as for {{c}} in lowercase. --Dan Polansky (talk) 15:46, 6 June 2017 (UTC)

2. Oppose Not clear at all what it means. If you want to use a single letter so badly, why not at least pick a relevant one like "T"? —CodeCat 14:59, 4 June 2017 (UTC)

   Surely "c" for "category" :) — Saltmarsh. 06:25, 11 June 2017 (UTC)

   @Saltmarsh: It is only for topical categories, not e.g. for Category:Spanish nouns. That's one of the reasons why CodeCat seems to prefer {{topics}}. --Dan Polansky (talk) 10:18, 11 June 2017 (UTC)

3. Oppose Would support {{cat}}. --Victar (talk) 05:09, 6 June 2017 (UTC)
4. Oppose. Too obscure for at template name. - [The]DaveRoss 13:17, 23 June 2017 (UTC)

---

Modern Latin as a LDL or extinct language

Voting on: clarifying the status of Latin from after the language ceased to be spoken.

Wiktionary:Votes/pl-2017-05/Modern Latin as a WDL 2 appears to show insufficient consensus to formalize the treatment of modern Latin as a WDL, raising the question of whether there is consensus to treat Latin (from after the language ceased to be spoken natively; for example, a citation from 2016) as an extinct language (undifferentiated from Classical Latin), or alternatively as a LDL.

This vote should not be started if Wiktionary:Votes/pl-2017-05/Modern Latin as a WDL 2 passes, as the question this vote seeks to answer only exists if that vote does not pass.

This vote has not yet started. It has been created to solicit advice on wording and fitness to purpose. Feedback and new ideas are highly encouraged! If you have not done so, please follow the discussion links for a better understanding of the topic. However, do not vote for any options at this time, as any premature votes may be struck. On the other hand, if the discussion is stagnant and there are no recent changes, anyone may choose to start this vote by properly listing it. Once the starting date has arrived, this banner may be ignored or removed.

Schedule:

• Vote starts: 00:00, 5 July 2017 (UTC)
• Vote ends: 23:59, 3 August 2017 (UTC)
• Vote created: - -sche (discuss) 19:56, 26 June 2017 (UTC)

Discussion:

• Wiktionary:Votes/2017-05/Modern Latin as a WDL
• Wiktionary:Votes/pl-2017-05/Modern Latin as a WDL 2

---

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:

• Wiktionary:Votes/2016-08/Enabling different kinds of romanization in different locations
• Wiktionary:Votes/pl-2015-09/Coauthoring policy votes
• Wiktionary:Votes/pl-2014-07/Redirecting attested romanizations
• Wiktionary talk:Votes/pl-2010-12/CFI amendment
• Wiktionary:Votes/pl-2009-12/Definition layout
• Wiktionary:Votes/pl-2009-08/Common placenames get entries
• Wiktionary:Votes/pl-2009-03/ELE Amendment 1
• Wiktionary:Votes/pl-2009-03/ELE Amendment 2
• Wiktionary:Votes/pl-2007-12/Attestation criteria