Open main menu

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 to the "active" list 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.

Before clicking the "Start a new vote!" button below, change "Title of vote" in the field just above the button to a short descriptive title.


{{Wiktionary:Votes/2019-08/Title of vote}}


{{Wiktionary:Votes/pl-2019-08/Title of vote}}


Note: add to this page and WT:A.
{{Wiktionary:Votes/sy-2019-08/User: for admin}}


Note: add to this page and WT:B.
{{Wiktionary:Votes/bc-2019-08/User: for bureaucrat}}


Note: add to this page and WT:C.
{{Wiktionary:Votes/cu-2019-08/User: for checkuser}}


{{Wiktionary:Votes/bt-2019-08/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:

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

Current and new votes

Lemmatizing Akkadian terms in their transliteration

Voting on: Moving the current content of Akkadian entries to its transliteration, and leaving a hard redirect when possible (except for single-signed words), leaving a soft one otherwise. The cuneiform script would be included in the head of the word for all entries.

Rationale: The voters only vote on the proposed action, not on the rationale.

Firstly, Cuneiform would still be displayed. They would be in the head of every entry, as in Egyptian hieroglyphs, and in inflection-tables. Therefore, no content would be lost by this vote.

Books and dictionaries lemmatize words according to their transliteration or transcriptions. These are the very sources we use for our Akkadian entries. They rarely ever display cuneiforms, and never to list words, mostly to list signs.

This is because very few people actually know cuneiform script, and those who know enough, do not use Wiktionary as a resource. Most of the readers do not even pay attention to the signs, unless they are trying to learn the script. In that case, the script would still be displayed. So they have no benefit from words being lemmatized in cuneiform.

Moreover, no one would ever give themselves the trouble to search for an Akkadian word in cuneiforms, specially, given that no one ever publishes anything in them, and whenever they do, they never use Unicode, but images instead. This makes most of the content inaccessible for readers. As a result, most pages have less than 5 views per month. It'd be ridiculous for us to expect that our readers know the script. And if we acknowledge they don't, then why listing words for them in a script we know they can't read?

Cuneiform signs changed depending on the period, area or scribe, while Unicode only renders one version for each sign. Furthermore, there are lapidary and cursive signs, where the first are inscribed in stone and the second are pressed into clay, and they can differ greatly. So lemmatizing entries in them does not guarantee an accurate representation of any given word if context isn't taken into account. Therefore, arguing for accuracy would be pointless. This is why books rely mostly on images instead of Unicode. And maybe we should consider in the future doing the same if we want to include different dialects.

It also makes it unnecessarily difficult to look for words in categories. For example, even though I am familiar with the script, being mostly the main editor of Hittite, it is still too cumbersome for me to quickly browse for a word in its categories. This also makes it extremely tedious to edit, since signs can not be quickly written, and I am forced to copypaste cuneiform words countless times. Besides, not all users might be able to display the signs properly, which would make it pointless for them to have words lemmatized in cuneiforms if they can’t even see them.

Egyptian words are lemmatized in their transliteration. And in spite that Unicode has characters for hieroglyphs, they aren’t used for Egyptian entries. So this wouldn’t mean that a huge exception is being done for Akkadian, since it’s been done before, for very similar reasons. Currently we have over 2 thousand Egyptian lemmas, while our Akkadian entries do not even make a tenth of that number. On average the last 10 Akkadian entries had a creation frequency of roughly 20 days. If Akkadian was lemmatized in roman script, it is quite likely that it would be able to grow, and could acquire regular editors, which currently doesn't have.

Furthermore, lemmatizing at cuneiform restricts the lemmas admissible for entries. Roots and sometimes other morphemes cannot be written in cuneiform, since it is a syllabary, and it's impossible to write a sequence of three consecutive consonants in it. This means that we should either write them in Latin script, or not write them at all, which wouldn't be a favorable option, since as in other semitic languages, Akkadian words are often listed by root rather than alphabetization, so it'd be important to have a list of Akkadian roots and their derivatives as well as entries.

There is no real benefit of lemmatizing Akkadian in cuneiforms, it is done at the expense of the legibility of our entries, as well as the accessibility of our content. So why sacrifice so much for so little?

Schedule:

  • Vote starts: 00:00, 22 May 2019 (UTC)
  • Vote ends: 23:59, 22 July 2019 (UTC)
  • Vote created: Tom 144 (𒄩𒇻𒅗𒀸) 18:29, 11 May 2019 (UTC)

Discussion:

Support

  1.   SupportTom 144 (𒄩𒇻𒅗𒀸) 00:02, 22 May 2019 (UTC)
  2.   Support, and I'd support doing this for Hittite as well. Not even scholars use the cuneiform. —Mahāgaja · talk 07:01, 10 June 2019 (UTC)
  3.   Support. I am strongly against any proposal that suggests we should not write any language in its official standard script because of obscurity (this includes Egyptian). However, the technical difficulties with Unicode as of this moment are a serious issue. I do not know if other signs are as problematic or even worse, but for example the w:DINGIR sign is seriously different between Sumerian and Akkadian, yet they both share the same codepoint. Readers should get the right signs or no signs at all if their devices do not support the character block, but to give them signs that are that different knowing that there is such problem with Unicode is not professional at all. So until the Unicode issue gets resolved, for the sake of accuracy I support this proposal. --Emascandam (talk) 02:11, 14 June 2019 (UTC)
    That seems a weird reason to support. I actually don't see this as an issue. A simple solution is to have an Akkadian specific font. If a specific unicode character is indeed the better solution, we can always just use a bot to convert entries when that's released. No reason to throw the baby out with the bath water. --{{victar|talk}} 04:18, 14 June 2019 (UTC)
    It is indeed true that Unicode represents inaccurately most Akkadian cuneiform signs. And as I said in the rationale, signs changed according to period and dialect, so more than a single set of signs would be required if we want to include different dialects at different stages (which I intend to do). Using fonts however, we would only be able to display one set of signs at a time, so it would use the same fonts for Babylonian, Assyrian, Sumerian, and Hittite, all of which require a different set. Furthermore, they would have to be installed by the reader, which I highly doubt will happen. These are the reasons not a single assyriological book uses Unicode but rely on images instead. And as I've already said, that's the proper way to deal with this issue, but that's matter of a different vote. –– Tom 144 (𒄩𒇻𒅗𒀸) 15:40, 14 June 2019 (UTC)
    No, fonts on wikt can be both language and script dependent, so you ca have one font for Akkadian, and another Sumerian, even if they are the same script. --{{victar|talk}} 16:27, 14 June 2019 (UTC)
    If your system has the proper fonts, should appear differently in multiple places on the page. —Suzukaze-c 17:58, 14 June 2019 (UTC)
    I wasn't aware of that. However, I do not see how you'd attempt to do this, because if the signs on the content of the entry are dependent on the language but the fonts of the title remain the same (which is what we're really discussing), the problem hasn't been fixed. The only thing this would achieve is confuse the viewer, not knowing if the correct form is the one in the title or the one in the content, see for example 𒀭 (DINGIR), where there are different contradictory images representing different stages of the sign. – Tom 144 (𒄩𒇻𒅗𒀸) 18:22, 14 June 2019 (UTC)
    The head and links would be correct though. It might be too much to ask for the page header as well. I could make the same complaint for Middle Persian written in Avestan, which doesn't use Avestan ligatures, but it's really not that big of a deal if it's just the page name. --{{victar|talk}} 20:30, 14 June 2019 (UTC)
    Yeah, it seems to be a matter of markup. Wouldn’t it be even stranger if “the same sign” is multiple times encoded and thus what is written DINGIR is spread across multiple pages? Also historical representations of Chinese letters don’t get encoded separately either. Fay Freak (talk) 20:14, 22 June 2019 (UTC)
  4.   Support trusting in the judgement of Tom 144 as being the primary editor of Akkadian content. —Suzukaze-c 04:28, 14 June 2019 (UTC)
    (The rationale is sensible to me. —Suzukaze-c 17:58, 14 June 2019 (UTC))
  5.   Support--ჯეო/მიქაელ (talk) 15:43, 14 June 2019 (UTC)
  6. I oppose this. Words should always be listed under their native script whenever possible, and obscurity of the script is absolutely no excuse. However, I agree that there are technical problems with cuneiform Unicode, so only out of necessity, I suppose that I have to   Support instead. But if the technical challenges can be overcome in the future, then this policy should be revoted upon to be changed. Nicole Sharp (talk) 15:18, 24 June 2019 (UTC)
    @Nicole Sharp, see above reply to Emascandam's vote. I really wouldn't call it much of a technical problem at all. --{{victar|talk}} 17:35, 24 June 2019 (UTC)
    Unfortunately, an Akkadian font loaded with CSS will not always work outside of Wikimedia. Wiktionary is more than just a website since it is designed to be copied and redistributed in a wide variety of different media and formats. Simplest case would be if someone wants to copy and paste the text, they will lose the font formatting. Unicode should always be used for word entries, and if the script is not fully supported by Unicode, then I agree that Roman transliteration is the best fallback. But the display of cuneiform on Wiktionary should always use both Unicode and graphics (preferably SVG) in my opinion (for cuneiform that can be displayed by Unicode). Using graphics-only is a real pain, since then one has to look up the Unicode equivalent (assuming it exists). For displaying cuneiform, Unicode should ideally be used first, and then graphics as a fallback. Nicole Sharp (talk) 02:03, 25 June 2019 (UTC)
    @Nicole Sharp: So your argument is because not everyone has fonts installed for certain unicode characters, we should all just use latin characters everywhere? You also do realize that every entry has transliterations and transcriptions on it, right? --{{victar|talk}} 08:21, 28 June 2019 (UTC)
  7.   Support For all Sumerian cuneiform languages. —*i̯óh₁n̥C[5] 08:39, 6 July 2019 (UTC)
      Support I completely agree with Tom 144 both in the "Rationale" and in every comment written until now. --Nebhos2019 (talk) 18:01, 19 July 2019 (UTC)
    Ineligible to vote per WT:VP: "2. Their account must have at least 50 edits in total...". — surjection?〉 20:05, 19 July 2019 (UTC)

Oppose

  1.   Oppose Absolutely not. --{{victar|talk}} 07:13, 24 May 2019 (UTC)
    Any reasons why? – Tom 144 (𒄩𒇻𒅗𒀸) 11:07, 24 May 2019 (UTC)
    For many of the same reasons Fay Freak list on the talk page, and to echo a point from the Sanskrit vote, if you can't handle working in Akkadian cuneiform, you should shouldn't be working in it at all. --{{victar|talk}} 16:07, 24 May 2019 (UTC)
    Editors would still be working on cuneiforms, since the script would still be mandatory. The only difference is that the entry would be located under it's transliteration. The content does not change at all, and the knowledge requirements would be the same. --– Tom 144 (𒄩𒇻𒅗𒀸) 19:02, 24 May 2019 (UTC)
    Disagree. People will always be lazy, and the lazy is just adding the transliteration. You can say it's "mandatory" until your face is blue. --{{victar|talk}} 20:15, 24 May 2019 (UTC)
    This. Can’t force the people to work a certain amount unless by the rod. The bad characters rule the world, and optimism is what makes it even more mediocre. Fay Freak (talk) 23:32, 24 May 2019 (UTC)
    This kind of pesimist thinking leads nowhere. – Tom 144 (𒄩𒇻𒅗𒀸) 20:19, 26 May 2019 (UTC)
    See my proposal. --{{victar|talk}} 17:44, 6 July 2019 (UTC)
  2.   Oppose Reasons verso. My prognosis is disfavourable. Fay Freak (talk) 23:32, 24 May 2019 (UTC)
    The phrase "Reasons verso" is probably intended to mean "reasons are on the talk page of the vote". That people who intentionally make themselves hard to understand (as others have noted) still have a discussion right and voting right is the downside of a wiki where anyone can edit. --Dan Polansky (talk) 07:27, 1 June 2019 (UTC)
  3.   Oppose Transliteration pages should point to a cuneiform lemma. /mof.va.nes/ (talk) 23:43, 24 May 2019 (UTC)
    Why? There’s absolutely no benefit for doing that. We lose legibility, accessibility, accuracy, and entries for roots. – Tom 144 (𒄩𒇻𒅗𒀸) 01:32, 7 June 2019 (UTC)

Abstain

  1.   Abstain The proposal is interesting. I like the following part of the rationale: "Books and dictionaries lemmatize words according to their transliteration or transcriptions. These are the very sources we use for our Akkadian entries." The opposition so far has produced only weak arguments. However, I will wait to see if more worthwhile discussion develops than has so far been the case. I would be happy to see some sources, like links to online dictionaries or to Google Books or other places where I can see the same thing the author of the proposal has seen. --Dan Polansky (talk) 07:22, 1 June 2019 (UTC)
    @Dan Polansky: The Chicago Assyrian Dictionary is the most prestigious and complete dictionary of the field. Other sources include a glossary of Old Babylonian words in John Huehnergard's grammar book, and another glossary on Old Akkadian in Ignace Gelb's Old Akkadian's grammar. Plus this fairly accurate online reasource that I found. All of these lemmatize at romanizations. I'd challenge the opposition to provide a single source that lemmatizes at cuneiform. I feel the main unstated argument of the opposition is that this violates wiktionary lemmatization tradition. – Tom 144 (𒄩𒇻𒅗𒀸) 16:52, 1 June 2019 (UTC)
    @Tom 144: This argument has been played out so many times, it's practically a meme. What's best online isn't always what's best in print, and vice versa. We're not restricted by things like space and legibility, which I can see as legitimate reasons to not include cuneiform in an Akkadian dictionary. We have the ability to make a better, more complete dictionary, without such restrictions. --{{victar|talk}} 16:45, 20 June 2019 (UTC)
    @Victar: As I've said numerous times now, cuneiform is still going to be included, the location of the entry is the only thing that changes. No content will be lost. None of the arguments I presented on the rationale are restricted to printed dictionaries. Why would the fact that wiktionary is an online resource have anything to do with legibility. – Tom 144 (𒄩𒇻𒅗𒀸) 19:54, 20 June 2019 (UTC)
    @Tom 144: And as I replied, that's an unrealistic expectation and the only way to have it truly be enforced is to mandate that the entries be in cuneiform. Come again? Print is both restricted in physical page size and print costs. For cuneiform to be legible, it needs to be larger than normal Latin text, especially in print where you have ink bleeding. Trying to say that online and print are no different is just plain silly. --{{victar|talk}} 20:07, 20 June 2019 (UTC)
    @Victar:As I understand your main objection, you start under the assumption that people will be as lazy as they can be, and unless they are forced to do some laborious task, people would opt not to do it. So lemmatizing at cuneiforms serves as a measure against those who will try to ignore the policy and not include the cuneiform script. However, from this initial assumption, this whole project should not work out, because no one is getting paid. Why would people work unnecessarily unless they were forced to do it.
    Concerning the print and online discussion, I didn't say that print and online were no different, I said they irrelevant to the arguments I raised. – Tom 144 (𒄩𒇻𒅗𒀸) 21:42, 20 June 2019 (UTC)
    I don't see how getting paid as anything to do with it. I spend much of my time getting on people's case for being too lazy on en.Wikt, by not including sources, sloppy formatting, etc. If you think laziness of editors isn't a factor, than you've been working in isolation for too long, my friend.
    It's absolutely relative because you're making an apples to oranges comparison of print dictionaries to the online one on en.Wikt, which is flawed. --{{victar|talk}} 00:02, 21 June 2019 (UTC)
    @Victar: Can you provide a link to a dictionary that places Akkadian lemmas on cuneiform, whether in print or online? And can you provide a link to a corpus-like resource that uses cuneiform where use of Akkadian terms in Akkadian sentences can be verified? --Dan Polansky (talk) 07:27, 22 June 2019 (UTC)
    Just like I do with Old Persian, when I want to verify the cuneiform, I go straight to the texts. {{R:akk:Lenzi:2011}} has great facsimiles of texts, for one.
    Secondly, I want to point out that there is a huge difference between dictionaries in transliterations ({{R:akk:GOA}}), and those in transcriptions ({{R:akk:CDA}}). I assume Tom is actually suggesting Akkadian entries in transcriptions, like ḫurāṣum, and not transliterations, like KU₃-SIG₁₇. @Tom 144, can you please clarify? --{{victar|talk}} 01:23, 23 June 2019 (UTC)
    And thirdly, I'm also against Akkadian being lemmatized at all because many of these words only have a single attestation and a lemmatisation makes assumptions that aren't always correct. --{{victar|talk}} 01:23, 23 June 2019 (UTC)
    @Victar: I'm sorry for not answering sooner, I have been very busy with my exams lately. I mean transliteration, because unlike transcription, it preserves information about the original orthography, since it's purpose is in fact to describe unambiguously the native script. – Tom 144 (𒄩𒇻𒅗𒀸) 15:57, 27 June 2019 (UTC)
    @Tom 144: Could you please indicate where 𒊓𒄠𒋢𒌝, 𒌋𒊏𒀸𒌴, and 𒌨𒈨 would be lemmatized, so we see some examples? --Dan Polansky (talk) 15:56, 28 June 2019 (UTC)
    @Dan Polansky: 𒊓𒄠𒋢𒌝 would be at ša₁₀-am-šu₁₁-um as an alternative of UTU. 𒌋𒊏𒀸𒌴 would go at u-ra-aš-ṭu, and 𒌨𒈨 would have to be placed at UR.ME. I would try to lemmatize at syllabifications whenever possible, unless of course the logographic orthography is vastly more common than the syllabic one. Again, sorry for the delay. – Tom 144 (𒄩𒇻𒅗𒀸) 02:15, 30 June 2019 (UTC)
    @Tom 144, Dan Polansky See my proposal. --{{victar|talk}} 17:43, 6 July 2019 (UTC)
  2.   Abstain Canonicalization (talk) 09:50, 5 June 2019 (UTC)

Decision

7-3-2 passedTom 144 (𒄩𒇻𒅗𒀸) 04:41, 29 July 2019 (UTC)
@Tom 144 This vote was ill-conceived and needs much discussion before you start moving entries. There needs to be better consensus on what format the entries should have first. --{{victar|talk}} 22:06, 29 July 2019 (UTC)
@Victar What do you think is worth re-discussing? Is it the format we should choose for entries or for transliteration? – Tom 144 (𒄩𒇻𒅗𒀸) 03:12, 8 August 2019 (UTC)
Speaking about format, how do you think roots should be listed? Should they be hyphenated, or in capitals? --– Tom 144 (𒄩𒇻𒅗𒀸) 03:22, 8 August 2019 (UTC)
@Tom 144: Well, as I wrote on the talk page, I think they should be transcriptions if they're lemmatized (@JohnC5 agrees), because lemmatizing transliteration poses the same problems as cuneiform, making it rather pointless. I also think transcriptions should be reconstructions, as that's what they really are. I recommend you go over all the points raised here and on the talk page and start a new discussion in the Beer Parlour, something that really should have happened before this vote. --{{victar|talk}} 16:28, 9 August 2019 (UTC)
Which is why I consider this vote void. It didn’t vote for something certain, and one can’t vote against cuneiform either if the alternative is an unknown – although hm, according to the result of this vote one can now put Akkadian in any form one likes. Great job, Tom. Fay Freak (talk) 00:12, 10 August 2019 (UTC)

Lemmatize Japanese wago words at kana spellings

Voting on: Change Wiktionary:About Japanese#Lemma entries to either:

(1) Lemmatize all wago words at kana spellings.

Lemma entries

Following are the guidelines for entries for the lemma form of Japanese terms: (vote)

  • For wago (和語) words aka Yamato-kotoba (大和言葉), i.e. words of native Japanese origin, the kana form is considered the lemma.
  • For everything else, the most common or most regular spelling is considered the lemma.
  • When the situation is unclear, editors are advised to use their best judgment on a case by case basis.

For non-lemma entries (e.g. for alternative spellings, rōmaji, and conjugated forms), see #Non-lemma forms for the more abbreviated form to use instead.

Or (2) only lemmatize rare or archaic wago at kana spellings.

Lemma entries

Following are the guidelines for entries for the lemma form of Japanese terms: (vote)

  • As a general rule, the most common spelling is considered the lemma.
  • Rare or archaic 和語 (wago) terms may use the kana spelling as the lemma, to avoid cramming kanji entries with too many readings. (This does not apply to proper nouns, specialized terms, etc.)
  • When the situation is unclear, editors are advised to use their best judgment on a case by case basis.

For non-lemma entries (e.g. for alternative spellings, rōmaji, and conjugated forms), see #Non-lemma forms for the more abbreviated form to use instead.

Schedule:

  • Vote starts: 00:00, 12 May 2019 (UTC)
  • Vote ends: 23:59, 10 June 2019 (UTC)
    • Vote extended to: 23:59, 10 August 2019 (UTC). People are slow to come to the vote as obvious on the vote page, and the participation so far has been low, so let's extend it and gain more comments. --Dan Polansky (talk) 07:45, 29 June 2019 (UTC)
  • Vote created: Dine2016 (talk) 14:22, 5 May 2019 (UTC)

Discussion:

Lemmatize all wago at kana

  1.   SupportSuzukaze-c 01:08, 13 May 2019 (UTC)
    I also support the second option if there would be "no consensus" between options 1 and 2 otherwise. —Suzukaze-c 23:12, 27 May 2019 (UTC)
  2.   Support. By the way, can we create a category for wago terms such as Category:Native Japanese nouns? Here's a shortcut to look for native Japanese verbs, which are easier to identify. KevinUp (talk) 05:38, 24 May 2019 (UTC)
    Main reason for supporting this option is because native Japanese words tend to have many different kanji spellings — つく (tsuku) has about fourteen. Since Wiktionary is an etymological dictionary, I would prefer to see words being lemmatized in a way that can better explain its etymology. KevinUp (talk) 06:04, 24 May 2019 (UTC)
  3.   Support I see that I argued against an early version of this proposal (March last year), but I think the case for wago entries is very well thought out. (I could write for ever, but most of it has already been said.) Imaginatorium (talk) 07:02, 24 May 2019 (UTC) Followup comment I would like to vote against the idea of restricting this to "rare" (who decides what's rare?) or "archaic" (marginal case anyway) entries. Saying "like any Western language" doesn't work, because Japanese isn't. Imaginatorium (talk) 08:59, 24 May 2019 (UTC)
    "Rare or archaic": Perhaps using the official Jōyō kanji list as a standard? As a counterargument, is a 表外字, but it's very common. --Dine2016 (talk) 09:25, 24 May 2019 (UTC)
  4.   Oppose "Lemmatize all wago at kana" per TAKASUGI Shinji: "we should use the most common spellings for words currently in use, just like any Western languages." I cannot place this into the oppose section which would be for both proposals at once; each proposal needs its own oppose section. I see no problem with "Lemmatize only rare/archaic wago at kana", and I abstain on it. --Dan Polansky (talk) 09:33, 7 June 2019 (UTC)
    Comment: I think there is a huge problem with using the term "spelling" to refer to completely different ways of writing something. It sounds supremely convincing to say "Use most common spelling", but this is not what is being talked about. Consider in English: is the cardinal 1 more commonly written as "1" or "one"? Would you call these "alternative spellings"? I think not. Dictionaries of the English language normally include this under "One", because that is its spelling. If you have to make an analogy with Japanese it would be that 'やま' is the "spelled-out" form of '山'. Imaginatorium (talk) 05:06, 10 June 2019 (UTC)
  5.   Support, albeit with the understanding that this is largely a technical consideration due to the inherent limitations of the MediaWiki software.
    One argument that leads me to this support is that various terms, even (especially?) very common terms, are only spelled differently for specific senses, and the core meanings and etymologies are identical. C.f. the many spellings of つく (tsuku). Breaking all of these out to separate entries requires a lot of data duplication. Native-language electronic dictionaries get around this by containing all the core information in one place, and essentially having all relevant spellings included in a single headword line. Example headline from my electronic copy of Shogakukan's KDJ: つ・く【突く・衝く・撞く・搗く・舂く・築く・吐く】 A search for any of the kanji spellings will deliver the user to the entry, and a search for the kana spelling つく (tsuku) will give the user a list of entries to choose from that match that reading. Since we can't seem to come up with a way to induce the MediaWiki framework to allow us to use a similar organizational scheme, lemmatizing at the kana spelling strikes me as the best way forward. ‑‑ Eiríkr Útlendi │Tala við mig 04:21, 10 June 2019 (UTC)
  6.   Support (quite strongly) User Eiríkr Útlendi sums it up well. Many wago don't have a specific kanji, and often when kanji differ depending on reading, sources are inconsistent. There's also the problem of inconsistency in which kana are written after the kanji for the inflectional endings -- some of that variation is easy to decide on per common usage, but much is not, not without us imposing our POV as to how Japanese should be written. Our trying to force order into this chaos is not likely to be practical, and not what we're here for anyway. kwami (talk) 02:07, 29 July 2019 (UTC)
  7. I'm between the   Abstain and   Oppose sides... per TAKASUGI Shinji and Dan Polansky. ~ POKéTalker) 23:18, 8 August 2019 (UTC)

Lemmatize only rare/archaic wago at kana

  1.   Support: we should use the most common spellings for words currently in use, just like any Western languages. That is what users look for in a dictionary. Moving out rare readings is for readability. — TAKASUGI Shinji (talk) 05:43, 24 May 2019 (UTC)
    I think it's mistaken to draw false analogies between Japanese and western languages because Japanese is fundamentally different fron western languages: a word in a western language usually has one spelling, but a word in Japanese usually has two spellings. For example, English 'book' has only one spelling, but Japanese 本 has two spellings, 本 and ほん. The English verb 'read' has only one spelling, but Japanese 読む has two spellings, 読む and よむ (and a few others). As a result, a printed dictionary of a western language uses the most common spelling of words as headwords, but a printed dictionary of Japanese use the kana spelling of word as headwords, even though kanji spellings are more common for most words. If printed dictionaries of Japanese used the most common spelling of words as headwords, then looking up will be more difficult, which does not help but hinder users. (Whether Wiktionary should use the most common spelling as lemma is a separate issue.) --Dine2016 (talk) 08:59, 15 August 2019 (UTC)
  2.   Support --Anatoli T. (обсудить/вклад) 08:36, 24 May 2019 (UTC)
  3.   Support I agree that the most common spelling should be the lemma; that will not always be a kana spelling. (By the way, I appreciate the "use their best judgment" caveat in both suggestions.) Cnilep (talk) 09:46, 25 May 2019 (UTC)
  4.   Support. The "most common written form as lemma" rule is sensible. Deryck Chan (talk) 13:29, 14 June 2019 (UTC)
    (Indented, as a vote added after the close. ‑‑ Eiríkr Útlendi │Tala við mig 23:27, 27 June 2019 (UTC))
    Unindented due to the extension. —Suzukaze-c 04:38, 30 June 2019 (UTC)
  5.   Support (explicit support as suggested by User:Dan Polansky on the talk page) —Suzukaze-c 01:17, 1 July 2019 (UTC)
  6.   Support Xbypass (talk) 15:59, 1 July 2019 (UTC)
  7.   Oppose: I've noticed that in single character kanji entries such as (hi), wago derived terms of (hi) may have spellings that do not contain :
    1. (higashi)
    2. (hiko)
    3. (hime)
    4. (hiru)
    5. 光る (hikaru)
I would like to propose for wago of single character kanji such as () and (やま) to be lemmatized at kana and redirected using {{ja-see}} such as the format currently used in (waga, a, are). The main reason is because entries such as (mizu) and (hito) are currently experiencing memory errors. For example, I recently broke the entry for in this edit. KevinUp (talk) 22:34, 26 July 2019 (UTC)
Han character entries that have Lua memory overflows can be found here: Special:WhatLinksHere/Template:character_info/subpage (this template reduces Lua memory)
As I continue to work on Han character entries in sections such as Japanese, Korean, Vietnamese and the addition of Classical Chinese quotations to these entries, Lua memory overflows are bound to occur in future. KevinUp (talk) 15:49, 28 July 2019 (UTC)
@Dan Polansky, Chuck Entz Would it be possible to ask those who have already voted on "Option 2: Lemmatize only rare/archaic wago at kana" to make a second vote to see whether they would support or oppose making an exception for single character kanji entries (lemmatizing wago of single character kanji at kana form) due to technical limitations? KevinUp (talk) 15:49, 28 July 2019 (UTC)
Could you explain how your rational is related to your vote? hi, higasi, hiko, hime etc. would all be separate entries regardless, so I don't understand what they have to do with this. kwami (talk) 02:03, 29 July 2019 (UTC)
@Kwamikagami: What I mean is that (higashi), (hiko), (hime), (hiru), 光る (hikaru) are currently listed as ====Derived terms===== of (hi). This may lead some people to think that kanji such as , , , are derivatives of the kanji which is not true. KevinUp (talk) 22:50, 29 July 2019 (UTC)
If higashi, hiko, hime, hiru, hikaru, etc. which are etymologically related were listed as derived terms of (hi, day; sun), I think that would be less confusing for our readers. KevinUp (talk) 22:50, 29 July 2019 (UTC)
I agree. I guess I'm confused as to how that counts as 'opposed', when it would be solved by making the change? kwami (talk) 23:35, 29 July 2019 (UTC)
I was also confused by the "oppose" header in this vote, so I have moved my vote for {{oppose}} to option 2 for less ambiguity. Anyway, I had already put my support for option 1 (lemmatize all wago at kana) around last month. KevinUp (talk) 00:46, 30 July 2019 (UTC)
Anyway, my main concern is that single character kanji are taking up too much Lua memory. I hope that those who have voted for option 2 would be willing to make an exception for single character kanji and to lemmatize wago spellings of kanji such as (ひと) and (みず) at kana form to solve the issue of "Lua error: not enough memory" at entries such as and . KevinUp (talk) 22:50, 29 July 2019 (UTC)
50 MB (error)
50 MB (error)
50 MB (error)
50 MB (error)
48.24 MB
47.72 MB
46.48 MB
46.42 MB
46.41 MB
46.17 MB
45.46 MB
45.44 MB
45.28 MB
44.62 MB
44.52 MB
44.50 MB
44.43 MB
43.29 MB
43.24 MB
42.98 MB









The table above is a random selection of entries that are almost reaching the 50 MB memory limit. KevinUp (talk) 22:50, 29 July 2019 (UTC)
Again, I seem to be missing something. I read this as an argument in support. kwami (talk) 23:35, 29 July 2019 (UTC)
Okay, to make things clearer, I am opposing option 2 (I had previously put {{oppose}} under the "Oppose" header below). KevinUp (talk) 00:46, 30 July 2019 (UTC)
  1.   Support “Lemmatize *some* only rare/archaic wago at kana” per KevinUp, anything to reduce the overflowing memory. Why not create something like 水/Chinese, 水/Japanese, etc.? Oh I get it, the {{head|langcode|head=}} problem. ~ POKéTalker) 23:18, 8 August 2019 (UTC)
    Regarding the issue of overflowing memory, I will start a separate Beer Parlour discussion to discuss this issue. A tentative proposal is to redirect wago forms of kanji taught at primary school level (教育漢字 (kyōiku kanji) to kana form. This will affect only kanji readings written without okurigana (送り仮名). KevinUp (talk) 12:11, 11 August 2019 (UTC)

Oppose

  1.   Oppose I have a slightly different opinion. Most-common-spelling policy should be stuck to, except when it is the case that one wago word has different kanji spellings, like 着く/付く/就く or 掛かる/架かる/懸かる. Only in that case, lemmatizing at kana is beneficial enough to resort to, for the reason of reducing redundancy. Also I strongly oppose treating wago proper nouns, like 富士山 or 埼玉, in this way, since the spellings of proper nouns are well established and should not be changed unless there be some really good reasons. -- Huhu9001 (talk) 03:56, 1 June 2019 (UTC)
    Comment: Regarding wago proper nouns, placenames and family names have fixed spelling. Indeed, these are well-established so it would make sense to use the most common spelling. However, kanji spelling for given names can have many different combinations, which is why I would prefer to see Japanese given names lemmatized using hiragana spelling.
    I think this is also a good suggestion, i.e. to stick to the most common spelling for all terms, except when one wago word has different kanji spellings. If this is available as a third option I would vote for it. KevinUp (talk) 10:22, 15 June 2019 (UTC)
  2. Generally speaking,   Oppose per Huhu. Generally speaking, list words at their most common "spelling" (obviously with link from kana spelling if most common is kanji). Treat cases with multiple common kanji "spellings" individually on their merits, including option of listing at hiragana spelling. Mihia (talk) 00:27, 27 June 2019 (UTC)
    Indented, as being a vote made after the end of the vote. —Suzukaze-c 06:51, 27 June 2019 (UTC)
    Unindented due to the extension. —Suzukaze-c 04:38, 30 June 2019 (UTC)

Abstain

  1.   Abstain I'm actually ok with any of the three outcomes. I created the vote to finalise the soft-redirection templates based on the outcome. For example, {{ja-spellings}} was originally designed for wago at kana entries so I put it on the right side of the page, expecting it would be in complementary distribution with {{ja-kanjitab}}. If it's decided that we lemmatize a large number of wago at kanji entries, then we definitely need to change its appearance so it does not clash with {{ja-kanjitab}}. Dine2016 (talk) 02:39, 12 May 2019 (UTC)

Decision


User:Julia for admin

Nomination: I hereby nominate Julia (talkcontribs) as a local English Wiktionary Administrator. Equinox 04:34, 27 July 2019 (UTC)

There was a previous vote on this: Wiktionary:Votes/sy-2018-08/User:Julia for admin; that vote was aborted early because of academic/sporting commitments (what in England we call "messing about in a boat").

She has continued doing a lot of work here and now would like to run the vote again. See contribs here: Special:Contributions/Julia

Schedule:

  • Vote starts: 04:34, 27 July 2019 (UTC)
  • Vote ends: 23:59, 10 August 2019 (UTC)
  • Vote created: Equinox 04:34, 27 July 2019 (UTC)

Acceptance:

  • Languages: en, de-3
  • Timezone: UTC-5
Julia 23:21, 27 July 2019 (UTC)

Support

  1.   SupportVorziblix (talk · contribs) 22:28, 27 July 2019 (UTC)
  2.   Support – Fay Freak (talk) 00:53, 28 July 2019 (UTC)
  3.   Support Equinox 22:26, 28 July 2019 (UTC)
  4.   Support PseudoSkull (talk) 22:57, 29 July 2019 (UTC)
  5.   Support Ketiga123 (talk) 12:14, 30 July 2019 (UTC)
  6.   Support - TheDaveRoss 12:45, 30 July 2019 (UTC)
  7.   Support Kaixinguo~enwiktionary (talk) 11:40, 2 August 2019 (UTC)
  8.   Support. On a general note: in the past, I casted conditional supports pointing to lacking proper desysop policy but these supports have produced quite a lot of antagonism, as evidenced e.g. in Wiktionary:Votes/2019-03/Disallowing conditional voting. Instead of casting a conditional support, let me point out that it is currently too hard to desysop people, which is not in the spirit of consensus based decision making and governance. The English Wiktionary needs a policy that enables something like votes of confidence, in which an admin keeps an admin flag only if they achieve consensual support, or if that policy is considered to make admins too vulnerable, if they achieve a plain majority support. Keeping admins supported only by a superminority is fundamentally flawed in my view, and raises unnecessary doubts about prospective admins instead of letting them prove themselves fit for the mop and the power. --Dan Polansky (talk) 10:09, 3 August 2019 (UTC)
    After seeing that you had added nearly 1,000 bytes to the page, I hoped that you'd be the first to provide some actual cogent rationale to why Julia needs adminship; unfortunately, I still seem to be out of luck. --Hazarasp (talk · contributions) 14:06, 3 August 2019 (UTC)
    All right. Julia probably does not need admin tools very much. An unstated English Wiktionary policy (or would-be policy?) seems to be that anyone who has contributed to the English Wiktionary for an extended period of time and did not disqualify themselves by doing something questionable can become an admin; the more the merrier. The examination is not of the need for tools but rather of possible problems or risks; that seems reasonable to me. On a different note, on the vote talk page, Julia said "The most useful tool would be able to speedily delete things myself in languages I work on like Alemannic German and Cimbrian. I would also like to be able to edit some of the Module:languages data." --Dan Polansky (talk) 06:55, 4 August 2019 (UTC)
    And to repeat what I wrote there, {{delete}} should suffice in all such (rare) cases and the template editor roles grants language data access, if that's even something they would ever need. I simply fundamentally disagree that just being a (semi) active user is grounds for automatic adminship, especially when desynoping an admin is virtually impossible. --{{victar|talk}} 16:56, 5 August 2019 (UTC)
  9.   Support DTLHS (talk) 18:09, 5 August 2019 (UTC)
  10.   Support, haven't seen much reason not to support really, the given reason that the tools would be useful for moving entries from unattested dictionary spellings makes sense. ←₰-→ Lingo Bingo Dingo (talk) 14:28, 8 August 2019 (UTC)
    @Lingo Bingo Dingo: That's why we have the page mover role, without the need to adminship. --{{victar|talk}} 01:14, 9 August 2019 (UTC)
    @Victar I would have gone for that had I seen cogent arguments that Julia would be unfit for the role, but I hadn't. The point was that the application/acceptance for admin status was not without reasonable motivation. ←₰-→ Lingo Bingo Dingo (talk) 10:28, 13 August 2019 (UTC)
  11.   Support Canonicalization (talk) 14:56, 8 August 2019 (UTC)
  12.   Support AuroraeLux (talk) 23:56, 8 August 2019 (UTC)
  13.   Support --Robbie SWE (talk) 10:00, 9 August 2019 (UTC)
  14.   Support a high-volume quality editor. --Habst (talk) 04:09, 10 August 2019 (UTC)

Oppose

  1.   Oppose Still a sloppy editor, in my opinion. There also has been no indication why this user should be synoped. --{{victar|talk}} 20:24, 29 July 2019 (UTC)
    Some examples of "sloppy editing" from the last few months (any earlier examples are irrelevant, as she could've learned from them or at least learned to avoid doing them) would make your point come across as more credible. --Hazarasp (talk · contributions) 02:20, 30 July 2019 (UTC)
    I removed my example because I just wanted to let people look at Julia's record and judge for themselves, but since you asked, the other day, Julia added this to an entry, which is not how we handle Chinese at all, but more importantly, shows that they didn't bother to look at other Chinese entries for guidance. It's rookie mistakes like that which make me wary and again, it hasn't ever been made clear what she needs admin tools for -- this is practically a blank nomination. --{{victar|talk}} 04:30, 30 July 2019 (UTC)
  2.   Oppose While I don't have any particular objections to Julia becoming an admin, I find it slightly concerning that nobody supporting her adminship has offered any sort of reasoning whatsoever for why she should become an admin (it's not like this vote matters anyways, given that it still leaves a comfortable 80% majority; if it gets more competitive, I might reconsider what is essentially a protest vote). --Hazarasp (talk · contributions) 14:06, 3 August 2019 (UTC)
    I now responded under my vote: need is usually not carefully examined, risks are. Our experience shows fresh admins usually find ways to use their tools, often in ways they could not have articulated or predicted beforehand. I like this ad hocism. --Dan Polansky (talk) 07:13, 4 August 2019 (UTC)

Abstain

  1.   Abstain Julia did point me in the right direction regarding uploading images using the Commons Upload Wizard, something I have made good use of. However I cannot comment on her editing, our paths don't usually cross there. DonnanZ (talk) 18:32, 4 August 2019 (UTC)

Decision

14 supported, 2 opposed, and 1 abstained. The vote passes, with 87.3% (not counting abstention) support. It also should be mentioned that this is over 3/4 support, which is the maximum Wiktionary seems to require for a supermajority. Could a bureaucrat please change @Julia's rights? PseudoSkull (talk) 03:24, 11 August 2019 (UTC)

3/4 (75%) has never been required in the last several years, from what I remember, if ever at all. Wiktionary:Votes/2019-03/Defining a supermajority for passing votes applies to this vote, and the applicable threshold is 2/3 of supports to supports + opposes. --Dan Polansky (talk) 09:00, 11 August 2019 (UTC)
  Done Chuck Entz (talk) 14:59, 11 August 2019 (UTC)

Language code into reference template names

Voting on: Renaming reference templates including those used for further reading to contain language code in their name, as long as the language code can be meaningfully determined. Thus, for instance, renaming {{R:Webster 1913}} to {{R:en:Webster 1913}}, {{R:OneLook}} to {{R:en:OneLook}}, {{R:DRAE}} to {{R:es:DRAE}}, {{R:TLFi}} to {{R:fr:TLFi}}, and {{R:Duden}} to {{R:de:Duden}}, with the caveat that the part of the new name after the second colon does not need to be the same as the original name if desired.

Schedule:

  • Vote starts: 00:00, 14 June 2019 (UTC)
  • Vote ends: 23:59, 12 August 2019 (UTC)
  • Vote created: Dan Polansky (talk) 07:58, 7 June 2019 (UTC)

Discussion:

@Dan Polansky has taken it upon himself to enforce this vote as if it was to put into effect a policy to ban the moving of any and all reference templates to names with language codes. It is not. This vote has been worded as a vote to systematically move all reference template those with language codes. If a ban was his intention of this vote, then a follow-up vote should be started explicitly stating that intent. @A12n, Cnilep, Daniel Carrero, Donnanz, Fay Freak, Jberkel, JohnC5, Lingo Bingo Dingo, Mahagaja --{{victar|talk}} 08:44, 10 July 2019 (UTC)

That is a misrepresentation; there is no ban but there is also the principle that status quo ante prevails unless overriden by consensus. A discussion is at User talk:Victar#Adding language code to reference template names. This discussion does not belong to the top of this vote, and I do not know why Victar is posting here; I am not sure I should be responding here either. --Dan Polansky (talk) 08:58, 10 July 2019 (UTC)
Again, this vote does not state that no templates currently formatted without a language code will be forbidden from being moved due to "status quo", or any reason whatsoever. As such, I will continue to move whatever templates I feel best suit the templates I work with, regardless of this vote, and will recommend others do the same. --{{victar|talk}} 18:11, 11 July 2019 (UTC)
The above editor should stop skipping WT:RFM, a process that covers template moves; this is a concern that existed before this vote was created. When the above editor moves a template without RFM and consensus, other editors may naturally move the template back; the status quo ante prevails barring consensus. --Dan Polansky (talk) 20:11, 11 July 2019 (UTC)
I agree that RFM applies to each and every renaming. DCDuring (talk) 14:52, 18 July 2019 (UTC)
@DCDuring: That's absolute nonsense. Show me the rule that says all moves require a WT:RFM. --{{victar|talk}} 20:06, 18 July 2019 (UTC)
We live by our prevailing practices. If you like rules, try Wikipedia. DCDuring (talk) 20:08, 18 July 2019 (UTC)
"Prevailing practices" are unenforceable. If you wish to enforce something, I recommend you start a vote --{{victar|talk}} 20:15, 18 July 2019 (UTC)
This is an obstructionist position. Harankas (talk) 16:59, 23 July 2019 (UTC)
Which one? Yours? Victars? Mine? Something earlier? DCDuring (talk) 17:03, 23 July 2019 (UTC)
Obviously the one that says you are entitled to have it your way unless there is a vote stating you're not. Harankas (talk) 18:22, 23 July 2019 (UTC)
Nothing is obvious online. Obviously I don't see my position as "my way". I see it as the Wiktionary way. DCDuring (talk) 19:01, 23 July 2019 (UTC)
Fine, let me spell it out (I see that reading between the lines is not your strong suit): the position of the user Victar is obstructionist. Harankas (talk) 19:41, 23 July 2019 (UTC)

Support

  1.   Support Fay Freak (talk) 19:52, 14 June 2019 (UTC)
  2.   SupportSuzukaze-c 21:41, 14 June 2019 (UTC)
  3.   SupportMahāgaja · talk 06:52, 15 June 2019 (UTC)
  4.   Support --{{victar|talk}} 00:44, 18 June 2019 (UTC)
    Nearly a third of all reference templates are not sorted into any language categories. This is obviously due to people being too lazy to add [[C:LANG reference templates]]. If we mandate a [[T:R:LANG:*]] format, when applicable, with the use of {{documentation}} and/or a bot, we could automatically add a reference templates category to those are are missing them. That's a really practical, and not pointless, reason to start mandating them. @Cnilep, PseudoSkull --{{victar|talk}} 21:19, 27 June 2019 (UTC)
    That's far from good enough a reason to start introducing this visual overhead into template names. The time spent putting the language code into the template names would be better spent putting the same templates into the proper language categories. We do the same with mainspace entries: they are put to categories rather than being put into a nested naming structure, like moving train into en/noun/train or even en/transportation/noun/train. --Dan Polansky (talk) 11:26, 28 June 2019 (UTC)
    You're welcome to that opinion, but it does not make it fact. Do I need to quote you again from below on how editors choose to spend their time is irrelevant to a vote? I'm looking at this from a future perspective, not a present one. People will continue in their human nature of being lazy -- this, I believe, can help offset that. --{{victar|talk}} 14:33, 28 June 2019 (UTC)
    Sure, and people's being lazy in categorizing mainspace entries could be offset by introducing en/transportation/noun/train. And people's being lazy in adding further reading to entries could be offset by deleting all entries that have neither attesting quotations nor further reading. I don't think this kind of bondage-and-discipline approach befits the spirit of the wiki. My general position is that people have every right to be lazy and work on the aspects of this wiki that they find interesting as long as it does not harm the project; providing further reading to monolingual sources everywhere would be much more useful than putting some templates into categories, and yet, I do not wish to impose that kind of duty on editors. --Dan Polansky (talk) 14:56, 28 June 2019 (UTC)
    Any mechanism that offsets laziness and brings greater utility to the project, I will vote for hands down, every time. If that doesn't suit you, who am I to argue. --{{victar|talk}} 15:07, 28 June 2019 (UTC)
    Erutuon, has already gone ahead and created a great little module for categorizing reference templates based on the lang code in their URL, {{T:refcat}}. Now we just need to get it added to the header to automate it completely. --{{victar|talk}} 16:45, 30 June 2019 (UTC)
  5.   Support –– Jberkel 11:44, 22 June 2019 (UTC)
    @Jberkel: I did not ask the other supporters but could I perhaps ask you which rationale for the proposal do you find convincing? --Dan Polansky (talk) 12:43, 22 June 2019 (UTC)
    I like self-explanatory names. For example, if {{R:xyz:Foo}} is mentioned somewhere, and I don't work on language xyz, I can safely ignore it, and don't have to go to the the template page to figure out what language it is for. It's also consistent with the practice of prefixing templates/modules with language codes ({{it-IPA}}, {{fr-IPA}} etc.). And lastly, with 4000+ languages ambiguities will become more and more frequent as the project grows (this also affects {{RQ:}} where translated works need to be taken into account, {{RQ:Cervantes Shelton Don Quixote}}, {{RQ:Cervantes Viardot Don Quichotte}} etc). – Jberkel 13:55, 22 June 2019 (UTC)
    Thank you. Let me note that {{it-IPA}} and {{fr-IPA}} is not really analogous since there the language code is indispensable unless we want to provide the language via a parameter, like {{IPA|it|...}} or rather {{IPA-auto|it|...}} since {{IPA}} does take language code already but does not automatically produce pronunciation. --Dan Polansky (talk) 14:55, 22 June 2019 (UTC)
  6.   Support --Vahag (talk) 18:13, 27 June 2019 (UTC)
  7.   Support --Daniel Carrero (talk) 01:03, 5 July 2019 (UTC)
  8.   Support*i̯óh₁n̥C[5] 08:37, 6 July 2019 (UTC)

Oppose

  1.   Oppose. This seems a bit excessive. The only case I can think of where it may be handy is {{R:Dokpro}}, where lang=nb and lang=nn can be added. DonnanZ (talk) 12:03, 15 June 2019 (UTC)
  2.   Oppose The current simplicity of most template names has worked well. I have seen two arguments in favor of the change: 1) Use the language code prefix for disambiguation, that is, make sure that templates for different languages can have the same name. As for that, name overlap is going to be rather rare, and can be addressed by various means, including using an alternative acronym or by adding a year to the template name. 2) The prefix makes it easier to find the template by typing R: plus the language code into the search bar. As for that, if you remember the beginning of the template name ("R:Web", "R:Dud"), you do not need a language prefix and you can type the beginning of the template name into the search bar and the search bar will show you possible templates ("R:Webster 1913", "R:Duden"). As for the case where you only remember the language, redirects can be created to help memory, like a redirect from {{R:de:Duden}} to {{R:Duden}}; furthermore, there are template categories by language, e.g. Category:German reference templates. As a final note, the template names without language codes look a little less like letter salad and more human, are shorter to type, and present no serious practical obstacles. They are more simple; let's make everything as simple as possible but not more simple. --Dan Polansky (talk) 07:31, 16 June 2019 (UTC)
    @Dan Polansky: Especially for templates I don't use so often, sometimes I can't remember even the beginning of the template name. Then it's just easier to type Template:R:ga: (or whatever) into the search box and see what pops up. That to me is simpler than going to CAT:Irish reference templates, since doing so requires me to open a new a tab in my browser. —Mahāgaja · talk 13:16, 16 June 2019 (UTC)
    @Mahagaja, nice pro tip! --{{victar|talk}} 02:49, 21 June 2019 (UTC)
    Sure, and this search box function would be provided by creating a redirect, e.g. from Template:R:ga:Dinneen 1904 to Template:R:Dinneen 1904, right? You can verify that this works with template:R:BTS, which was moved out of process to template:R:ru:BTS and the redirect is still there. --Dan Polansky (talk) 07:10, 22 June 2019 (UTC)
    Fair enough, but this vote isn't about moving templates that already have language codes in them to versions without the code. —Mahāgaja · talk 09:02, 22 June 2019 (UTC)
    Well, it isn't, but what's the point? Let me try again: Let us suppose you cannot remember the German reference template names. One way to help you (in reference to search box) is to move {{R:Duden}} to {{R:de:Duden}}, and that is the proposal of the vote. Another way to help you is to create a redirect from {{R:de:Duden}} to {{R:Duden}} without moving the template. This alternative shows that we do not need to move the template to help you, and therefore, I oppose the proposal since I do not like its bad consequences and its good consequences can be achieved by creating redirects. --Dan Polansky (talk) 09:24, 22 June 2019 (UTC)
    By the way, the template redirect from T: enables you to enter "T:R:Du" into the search box and find Duden; you do not need to type Template:. --Dan Polansky (talk) 09:52, 22 June 2019 (UTC)
    Let me make a note about economy. One argument made is that the prefix in the template name helps automatic categorization of the template. However, the categorization of a template is something you make once per template, while entering the template name into the mainspace is something you make thousand times, and you read the template name even more times; surely it is the entering into the mainspace that should be optimized. --Dan Polansky (talk) 20:05, 11 July 2019 (UTC)
  3.   Oppose I tend to feel that language codes should be omitted where they don't add information to an entry or facilitate things like category sorting. Simplicity is usually best, in my opinion. Cnilep (talk) 06:27, 21 June 2019 (UTC)
  4.   Oppose If I already know to use the reference template, I think I'd probably know the language it's for by that point. Including the code seems pointless to me and seems like clutter. PseudoSkull (talk) 00:09, 23 June 2019 (UTC)
  5.   Oppose I don't think it makes sense to go and rename a bunch of templates to include language codes in their name when there are very few reference templates where this would make any sense. Such efforts would be better spent making Wiktionary easier to use for non-technically-minded people. פֿינצטערניש (Fintsternish), she/her (talk) 19:43, 26 June 2019 (UTC)
    @פֿינצטערניש: The time it would take to get a project done is never a valid reason not to vote for something and the productivity of one project does not take away from the productivity of another. To quote Dan, "[editors] should feel to dispose of [their time] as they see fit; we should not act as managers of other people's resources." --{{victar|talk}} 21:34, 27 June 2019 (UTC)
    At the same time this still means introducing an extra level of difficulty in using templates, and I oppose doing this; I think it is moving in the exact opposite direction as making the site easier to use for non-technical people. פֿינצטערניש (Fintsternish), she/her (talk) 21:43, 27 June 2019 (UTC)
    @פֿינצטערניש: Well, a) if you're too technically inept to add a language code to the URL, then I have bad news for them in creating the actual reference template, because that's the easiest part of it, and b) see my rational in my vote in this being a mechanism to actually help people that are doing a poor job of creating templates, i.e. the inept/lazy. --{{victar|talk}} 21:48, 27 June 2019 (UTC)
    Actually I voted pro because it will be easier when one does not have to remember whether a template one wants to use uses the language prefix or not. Hard to remember that it is {{R:L&S}} and not {{R:la:L&S}}. Fay Freak (talk) 00:10, 28 June 2019 (UTC)
    That is an argument in both directions: if some people did not start using the language code prefixes, everything would have been consistent and no one would need to remember which of the two inconsistent practices to use. Historically, it was the people who started to use the language code who introduced inconsistence into the reference template naming. --Dan Polansky (talk) 11:21, 28 June 2019 (UTC)
    That is not an argument in both directions. It insinuates to complete what some people have begun so it becomes consistent instead of keeping it inconsistent. You are voting for inconsistency and incomprehensibility. Fay Freak (talk) 19:09, 28 June 2019 (UTC)
    I mostly started using the format because we began simplifying some templates to their acronyms. Three letters and a language code is easier to remember than the spelling of an author's name and the year of publication, i.e. {{R:De Vaan 2008}} > {{R:itc:EDL}}. --{{victar|talk}} 05:30, 28 June 2019 (UTC)
    The space of three-letter acronyms is large enough (17 576 items); we don't need language code to disambiguate them. For the few cases where disambiguation will be required, switching to a four-letter acronym or another ad hoc disambiguation means can be used.
    And the above claim about what is easier to remember is empirically unsubstantiated and does not appear particularly obvious to me. For instance, {{R:Duden}} is super easy to remember. --Dan Polansky (talk) 11:28, 28 June 2019 (UTC)
    Did I say anything about overlap? I was merely stating what the catalyst for this change was in my case. My rationale for supporting the migration of references templates to this format is listed in my support vote. --{{victar|talk}} 14:28, 28 June 2019 (UTC)
    Without an implied overlap argument, the statement "I mostly started using the format because we began simplifying some templates to their acronyms" makes no sense. --Dan Polansky (talk) 14:57, 28 June 2019 (UTC)
    There are many reasons I could have given, like it being the defacto standard for creating new templates, but I gave none, and I'm not obliged to. You make assumptions of me. --{{victar|talk}} 15:04, 28 June 2019 (UTC)
    As said, the statement makes no sense without the overlap concern, and the above response makes me no wiser as to what else could make sense of the statement. --Dan Polansky (talk) 15:09, 28 June 2019 (UTC)
    Dan, I'm not here to make sense or justify my personal catalyst in this issue. All I wanted to say in that regard is in my upvote comment. --{{victar|talk}} 15:12, 28 June 2019 (UTC)
  6.   Oppose ←₰-→ Lingo Bingo Dingo (talk) 14:22, 28 June 2019 (UTC)
    Clarification: I understand this oppose vote to mean opposition to mandatory inclusion of language codes, not support for banning any renaming to a name with a language code. ←₰-→ Lingo Bingo Dingo (talk) 08:54, 10 July 2019 (UTC)
    Indeed, this vote cannot ban renames. That said, renames are governed by the consensus principle via WT:RFM process, especially renames that are likely to be controversial. --Dan Polansky (talk) 09:37, 10 July 2019 (UTC)
  7.   Oppose - I don't see any advantage SemperBlotto (talk) 08:49, 10 July 2019 (UTC)
    @SemperBlotto: for one. --{{victar|talk}} 08:54, 10 July 2019 (UTC)
  8.   Oppose. I don't feel for having to type in an extra "az:", or, G-d forbid, "trk-oat:" Ketiga123 (talk) 14:05, 11 July 2019 (UTC)
  9.   Oppose. Reasons: (1) It is shown that redirect is good solution. (2) More convenient for old editors. (3) I like short templates names. --Andrew Krizhanovsky (talk) 12:34, 18 July 2019 (UTC)
  10.   Oppose Each and every template renaming should go through RFM. Redirects from the old names should remain if new names with language codes are created. DCDuring (talk) 14:52, 18 July 2019 (UTC)

Abstain

  1.   Abstain: no strong feelings either way. — SGconlaw (talk) 13:05, 15 June 2019 (UTC)
  2.   Abstain: Sitting on the fence, at least for now. Nice idea in terms of orderliness of the reference library, as it were, but the case doesn't seem so strong. Main advantage I see is being able to tell the language which an R template serves. Otoh, not clear any advantage for references w/ multiple language targets. The potential advantage for automatic categorization seems offset by the amount of work needed to add the language codes - would it be any more work to just manually categorize R templates per relevant language(s) that are not so already? --A12n (talk) 12:58, 29 June 2019 (UTC)
    @A12n: I'm mostly looking towards the future for the automatic categorization feature, and adding R:LANG:NAME is easier than adding categorization manually. --{{victar|talk}} 16:42, 30 June 2019 (UTC)
    The initial amount of work needed to perform the template renaming is pretty manageable, I think, and if the proposal were in the other direction, i.e. removing the lang codes, I would volunteer. I think it is about what you want to see and type into the wikitext, whether e.g. {{R:de:Duden}} or {{R:Duden}}. I prefer the latter, and if I find a reference template used in a section ==German==, I don't think I need any hints as to the language; and if I find the template alone, the manual categorization will do the trick. The alleged advantage of automatic categorization seems bogus to me: it is only automatic after you have manually placed the language code into the template name. --Dan Polansky (talk) 21:03, 4 July 2019 (UTC)
  3.   Abstain:Xbypass (talk) 15:52, 1 July 2019 (UTC)

Decision

Fails 8-10-3. - TheDaveRoss 17:39, 13 August 2019 (UTC)

Abolish the Old Latin header

Voting on: Voting on: Abolish the “Old Latin” header. Move everything under it to Latin. Latin without adjectives!
Rationale: See Wiktionary talk:Votes/2019-08/Abolish the Old Latin header. The voters only vote on the proposed action, not on the rationale.

Schedule:

  • Vote starts: 00:00, 14 August 2019 (UTC)
  • Vote ends: 23:59, 13 September 2019 (UTC)
  • Vote created: Fay Freak (talk) 15:51, 4 August 2019 (UTC)

Support

  1.   Support Canonicalization (talk) 12:53, 15 August 2019 (UTC)
  2.   Support /mof.va.nes/ (talk) 14:49, 15 August 2019 (UTC)
  3.   Support Fay Freak (talk) 19:51, 15 August 2019 (UTC)
  4.   Support Ketiga123 (talk) 15:29, 16 August 2019 (UTC)
  5.   Support AuroraeLux (talk) 02:31, 17 August 2019 (UTC)

Oppose

Abstain

Decision


Rescinding the "Coalmine" policy

Voting on: Rescinding the "Coalmine" policy, as originally approved at WT:COALMINE and incorporated into the CFI at Wiktionary:Criteria for inclusion#Idiomaticity. That is, removing the following paragraph from WT:CFI:

Unidiomatic terms made up of multiple words are included if they are significantly more common than single-word spellings that meet criteria for inclusion; for example, coalmine meets criteria for inclusion, so its more common form coal mine is also included.

The effect of this vote, if passed, would therefore be that a multi-word term that means no more than the sum of its parts, such as coal mine, would become eligible for deletion under standard rules (assuming that no other exemptions apply), irrespective of the fact that an entry for the corresponding single word exists.

For the proposer's rationale for rescinding, as well as other statements in favour of or against the poposal, please see the Disussion page.

Be sure to vote the right way. A support vote is a vote to rescind the "Coalmine" policy; an oppose vote is a vote to retain the policy.

Schedule:

  • Vote starts: 00:00, 18 August 2019 (UTC)
  • Vote ends: 23:59, 16 September 2019 (UTC)
  • Vote created: Mihia (talk) 17:25, 11 August 2019 (UTC)

Other Discussion:

Support

Oppose

  1.   Oppose 1) Use the right lemma: Let us have compound term, compound-term and compoundterm, all attested. I consider the three items to be three different forms of what is essentially one word. The question is: where should we lemmatize it? If compound term is much more common than compoundterm, compound term is the proper lemma, in my view, even if sum of parts; alternatively, compound-term could be the lemma, depending on the frequency. 2) COALMINE is usually easy to administer, and from my experience often has us keep terms that I would instinctively like to keep for other reasons, which are harder to investigate and articulate. That is a bonus of COALMINE: it speeds up RFD for terms worthwhile for other less well articulable reasons. 3) Vanishingly rare solid forms compoundterm that we have good reasons to believe are misspellings should be deleted using WT:CFI#Spellings rare misspelling exclusion policy, thereby making COALMINE toothless: himand was deleted, so him and is not supported by COALMINE. (himand*10000), him and at Google Ngram Viewer provides frequency evidence of rare misspelling, and these are deleted. --Dan Polansky (talk) 19:20, 18 August 2019 (UTC)
  2.   Oppose I am in favor of simple rules that are easy to apply. I think we should be less afraid to have "arbitrary" inclusion criteria that helps us avoid long philosophical discussions in RFD on what even really is a word, man (we just don't know). DTLHS (talk) 20:37, 18 August 2019 (UTC)

Abstain

Decision


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: