Open main menu

Wiktionary:Beer parlour

Wiktionary > Discussion rooms > Beer parlour

Lautrec a corner in a dance hall 1892.jpg

Welcome, all, to the Beer Parlour! This is the place where many a historic decision has been made and where important discussions are being held daily. If you have a question about fundamental Wiktionary aspects—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list (click on Start a new discussion), and it will be considered. Please keep in mind the rules of discussion: remain civil, don't make personal attacks, don't change other people's posts, and sign your comments with four tildes (~~~~), which produces your name with timestamp. Also keep in mind the purpose of this page. There are various other discussion rooms which may serve the idea behind your questions better. Please take a look to see which is most appropriate.

Sometimes discussion identifies an issue as an idea for policy development or rewriting. Such discussions may be taken out of the Beer parlour to a relevant page, or a brand new page may be created. Usually, the active policy pages will be listed in one of the sections below. See also the policy development page and the votes page.

Questions and answers will not remain on this page indefinitely, as it would very soon become too long to be editable. After a period of time with no further activity (usually a couple of weeks), information will be moved to the archives. We make a point to preserve all discussions that were started here in the archives. However, talk that is clearly not intended for this page may be moved and will not end up in the archives. Enjoy the Beer parlour!

Beer parlour archives edit
2002
December
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018


Contents

November 2018

Point/counterpoint: apostrophesEdit

Abolish them, recognize them as letters. (Feel free to move this to the Tea Room if you feel it's more appropriate there.) —Justin (koavf)TCM 00:53, 1 November 2018 (UTC)

Our current practice is to recognize apostrophes as part of the spelling of a word (e.g. fo’c’s’le), except when used to form the possessive of a noun (so father’s is not an entry), with an exception to that exception when that possessive itself forms part of an idiomatic phrase or (part of) a proper name (e.g. men’s room and McDonald’s). We similarly recognize capitalization and hyphens as part of the spelling. We aim at being descriptive. As long as apostrophes are in widespread use, we are not going to abolish them. We do have an entry for anapostrophic aint because it is attestable but label it as a misspelling because that is how it is generally considered today. Whether or not we see apostrophes or hyphens as letters seems irrelevant. Do you feel we should take a position? In that case, please give some argument indicating the relevance.  --Lambiam 12:34, 1 November 2018 (UTC)
@Lambiam: Interestingly, anapostrophic doesn't come up on google searchs; non- is usually the best option --Backinstadiums (talk) 14:29, 1 November 2018 (UTC)
For every word, someone must have been the first to use it. Apart from my dislike of Greek–Latin chimeras like tele- + vision – why not teleopsis? – I feel that the Greek prefix an- carries a connotation of lacking and not merely negation. For example, since one cannot reasonably say that the word “sock” is lacking an apostrophe, one should not label it as anapostrophic. In fact, since it is not lacking an apostrophe, it is non-anapostrophic :).  --Lambiam 23:39, 1 November 2018 (UTC)
@Lambiam: Everyone is free to make up words, but it's important that those who read them can understand them. Simple prose is often best, and "without an apostrophe" would have been understood by everyone. — Paul G (talk) 07:51, 3 November 2018 (UTC)

Dictionary-only diacritics need to be documented betterEdit

Currently, where we do document dictionary-only diacritics, it's usually on the WT:About (language) page. But those pages seem to be primarily aimed at editors for a particular language, and are probably rather hard to read for people who merely read Wiktionary. I therefore think that these concerns should be separated more clearly: one page to document the reader-facing parts of Wiktionary, and another to document what editors need to know in addition. A paper dictionary would usually document its conventions somewhere in the prologue, so we should have something equivalent. Given that our namespace convention so far is to use Wiktionary: for editors and Appendix: for readers, Appendix: seems like the logical choice. However, Help: is also a good candidate, and is not used as much as it should be currently. —Rua (mew) 14:12, 1 November 2018 (UTC)

Sometimes I wonder if we should link to Wiktionary:About ____ from each L2 header. —Suzukaze-c 04:01, 4 November 2018 (UTC)
I would like to suggest that we have a User's Guide for each language (shortcut U+language code), giving the kind of information that one would find in the introduction to an English-language dictionary or lexicon for that language. That would be a good place for explaining practices like which form is the lemma, what we don't cover (things like forms with clitics like 's or Latin -que) and other features that need to be understood to use the entries, like the difference between attributive nouns and adjectives in English. We would need to develop a standard format and some ground rules to keep them from turning into reference grammars or verbose essays, but I think it would be worth the effort. Chuck Entz (talk) 04:21, 4 November 2018 (UTC)
I think something like Help:English would be a good name. Alternative names for the language can be redirects, and ambiguous names can be "disambiguation" pages. —Rua (mew) 11:49, 6 November 2018 (UTC)

Adding information about historical inflections for Japanese entriesEdit

Including what were called

  • 4-grade inflection
  • upper and lower 2-grade inflection
  • ra, na, ka and sa inflection (irregular)
  • ku and shiku inflection (adjectives)

reference.

These inflections are explicitly given in dictionaries so they can be verified. [1]

Although somehow "archaic", they can still be found in fossil words, or even productive sometimes in modern speech, e.g ○○せず, ムダヅモ無改革.

Huhu9001 (talk) 14:20, 1 November 2018 (UTC)

  • @Huhu9001:
    • For verbs (conjugations, more specifically than inflections), I believe the {{ja-verb}} template already supports type=yo for yodan verbs, as well as ni, kami ni, and shimo ni for the nidan verbs. Granted, this isn't yet documented anywhere besides the module code itself, which is not ideal. I've added or edited a few verb entries where I've used these type values; see the relevant subcategories at Category:Japanese_verbs.
    • I'm not sure what you mean by "ra, na, ka and sa inflection". What part of speech are you referencing? I'm used to (sa) as the nominalizing adjective suffix that is a rough equivalent of English -ness, but I suspect you're talking about something else?
    • Re: -ku and -shiku adjective types, we haven't had occasion yet to build out those paradigms -- these are largely gone from modern Japanese, although they are widely known and occasionally used to deliberately archaic effect. See, for instance, that scene in the Ghibli movie Spirited Away when Sen saves the "stink god" who turns out to be the god of a polluted river -- at the end of his big reveal, he says, 良きかな (yoki ka na, “that's better, isn't it”) and disappears.
    • Re: せず, that form is already accounted for -- see する#Conjugation, in particular the Negative continuative row. Granted, the ず ending is also used as a terminal form in formal modern Japanese; however, I'm not sure if a per-entry conjugation table is the best place to treat such stylistic and usage information...
More broadly, we (Wiktionary JA editors) are collectively still in a bit of a muddle about what to do with these aspects of the language -- as you note, many of these constructions are still productive in limited fashion, and thus don't really belong to a wholly different stage of the language in quite the same way that Middle English is differentiated from modern English. We've batted around ideas of setting up "Classical Japanese" or some such as a new L2 "language". But there's no lang code, we're unclear on how to differentiate, and there's potential for tons of duplication -- some verbs are no longer in common use and linger on as yodan paradigms, while others are modern godan verbs that evolved regularly from earlier yodan forms → would we have "Classical Japanese" entries for both? Or only for the yodan-only verbs? Etc. etc.
Setting aside the bigger issue of our overall approach to earlier Japanese grammar, it'd be helpful for starters if you could explain what you mean by "ra, na, ka and sa inflection". ‑‑ Eiríkr Útlendi │Tala við mig 00:15, 7 November 2018 (UTC)
To Eiríkr Útlendi:
  • I mainly suggest we give two inflection tables, one modern and one archaic/classical, for every Japanese entry, e.g. 燃える: 燃え 燃え 燃える 燃える 燃えれ 燃えよ and 燃え 燃え 燃ゆ 燃ゆる 燃ゆれ 燃えよ. I think this is not hard.
  • "ra, na, ka and sa inflection" are archaic/classical irregular inflections, e.g. 死ぬ: 死な 死に 死ぬ 死ぬる 死ぬれ 死ね.
Huhu9001 (talk) 05:51, 7 November 2018 (UTC)
@Huhu9001 -- Re: the irregulars, ah, yes, now I've got you. For 死ぬ, for instance, that's more formally called called the ナ行変格活用 (na-gyō henkaku katsuyō, na-row irregular conjugation). Only two verbs exhibited that pattern, 死ぬ (shinu, to die) and 往ぬ / 去ぬ (inu, to go away, obsolete), with scholars apparently undecided on whether shinu might derive from inu, thus suggesting only one underlying verb with this paradigm.
Re: adding two inflection tables to all modern verbs, I'm not sure I can agree with that. For instance, the classical terminal (i.e. dictionary) form of modern terminal-form 燃える (moeru) is 燃ゆ (moyu): the lemma form is different for certain verb classes. Additionally, various verbs spelled -える in the modern language, such as 変える (kaeru, to change something), were spelled -へる before the spelling reforms of the 20th century, tracing back to terminal (lemma) forms ending in -ふ. Wiktionary practice, as I've understood it, is for conjugation tables and other detailed information to go in the entry for the lemma form of a word.
We don't seem to have any consensus at present for building out a whole new L2 language as "Classical Japanese" or something along those lines. As such, it seems to me more like the conjugation tables for the older paradigms should go collectively on the WT:AJA page, or somewhere similar, rather than on each entry page. Would that be acceptable? ‑‑ Eiríkr Útlendi │Tala við mig 20:03, 7 November 2018 (UTC)
To Eiríkr Útlendi:
  • I insist every entry should contain this inflection information because they are in fact still in use. -> (where are they used)
  • Different lemmas are never a problem in Wiktionary, the entry τελέω gives the inflection of τελῶ as well.
  • WT:AJA is a policy page telling you how to compose an entry. Inflection table is obviously not supposed to be there. Huhu9001 (talk) 06:00, 8 November 2018 (UTC)

Use pronunciation templateEdit

@Huhu9001 What about dropping the inflection templates and extend {{ja-pron}} to achieve the effect?

{{ja-pron
|m=もえる    // modern kana spelling
|mcat=v1     // modern inflection type, v1 = vowel base (一段) verb
|h=もえる,moyeru    // historical kana spelling
|c=もゆ      // Classical Japanese predicative (終止形) form
|ccat=v2s    // Classical inflection type, v2s = e/u-alternating vowel base (下二段) verb
}}
Conjugation of “燃える” (ichidan conjugation)
Traditional paradigm
Imperfective (未然形) 燃え もえ moe
Continuative (連用形) 燃え もえ moe
Terminal (終止形) 燃える もえる moeru
Attributive (連体形) 燃える もえる moeru
Hypothetical (仮定形) 燃えれ もえれ moere
Imperative (命令形) 燃えよ¹
燃えろ²
もえよ¹
もえろ²
moeyo¹
moero²
Key constructions
Passive 燃えられる もえられる moerareru
Causative 燃えさせる
燃えさす
もえさせる
もえさす
moesaseru
moesasu
Potential 燃えられる
燃えれる³
もえられる
もえれる³
moerareru
moereru³
Volitional 燃えよう もえよう moeyō
Negative 燃えない
燃えぬ
燃えん
もえない
もえぬ
もえん
moenai
moenu
moen
Negative continuative 燃えず もえず moezu
Formal 燃えます もえます moemasu
Perfective 燃えた もえた moeta
Conjunctive 燃えて もえて moete
Hypothetical conditional 燃えれば もえれば moereba
¹ Written imperative
² Spoken imperative
³ Colloquial potential
Classical conjugation of “燃ゆ” (shimo nidan conjugation)
Traditional paradigm
Imperfective (未然形) 燃え もえ ⟨moye⟩
Continuative (連用形) 燃え もえ ⟨moye⟩
Terminal (終止形) 燃ゆ もゆ ⟨moyu⟩
Attributive (連体形) 燃ゆる もゆる ⟨moyuru⟩
Evidential (已然形) 燃ゆれ もゆれ ⟨moyure⟩
Imperative (命令形) 燃えよ もえよ ⟨moyeyo⟩

(Notifying Eirikr, Wyang, TAKASUGI Shinji, Nibiko, Atitarev, Suzukaze-c, Poketalker, Cnilep, Britannic124, Fumiko Take, Nardog, Marlin Setia1, AstroVulpes, Tsukuyone, Aogaeru4): --Dine2016 (talk) 08:21, 8 November 2018 (UTC)

To Dine2016: Acceptable to me.Huhu9001 (talk) 09:14, 8 November 2018 (UTC)
Two thoughts.
  • Putting the classical form in {{ja-pron}} seems really weird -- the pronunciation template is intended to show the pronunciation of the headword. The example above ... hides the pronunciation, which seems confusing and poor usability. Also, /moju/ is not a pronunciation of 燃える (moeru, to burn, intransitive). Likewise, conjugation type, historical kana spellings, and romanization schemes do not belong in this template. I'd be fine if some other template were created for this purpose, but {{ja-pron}} is not the place for this.
(Separately, I'm confused by the comment, "what about dropping the inflection templates", since the example above ... includes the inflection templates?)
  • I'm resistant to the idea of conjugating 燃ゆ in the 燃える entry. The Ancient Greek example does not seem germane here; τελῶ (telô) appears to be simply a contemporaneous contraction of τελέω (teléō), and it looks like the editors collapsed the information about the former into the entry for the latter as an exceptional case. For classical Japanese, we're talking instead about every verb in sizable verb classes.
That said, I'd like to survey other dictionaries, get a handle on their approaches. Let me chew on this a bit (where to put classical conjugations).
‑‑ Eiríkr Útlendi │Tala við mig 13:07, 8 November 2018 (UTC)
@Eirikr: Thank you for your reply. By "what about dropping the inflection templates", I meant to make {{ja-pron}} generate the inflection tables, thus eliminating individual inflection templates such as {{ja-ichi}}. Here are some considerations.
  • Putting the historical kana spellings and the romanization schemes in headword templates might seem good at first, but when there are more than one parts of speech, they have to be duplicated, which is not ideal. The Korean pronunciation template {{ko-IPA}} includes romanizations, and the Chinese {{zh-pron}} includes not only romanizations but also Middle and Old Chinese, which can be comparable to historical kana spellings. Therefore I find it convenient for Japanese to follow the model of Korean and Chinese, which means putting the historical kana spellings and the romanizations in the pronunciation template.
  • As for inflection tables, I have no objection to having a separate "Inflection/Conjugation" section and templates, but making {{ja-pron}} take over that functionality is more convenient for editors, isn't it? Moreover, by doing so, phonetic information such as もえる (for 燃える), き.いろい, or |acc=0 can be directly used when generating the inflected forms, eliminating the need to copy them to the inflection templates.
  • 燃ゆ and 燃える are pretty much the same lexeme if you consider what linguistics call the stem or the base: the former is /moje-/, and the latter is /moe-/, clearly regular development. The reason the dictionary form look different is because the modern 終止形 comes from the classical 連体形 and 二段動詞の一段化, both of which concern morphology only. Even in the traditional Japanese analysis, も・える(ア下一) is a direct reflex of classical も・ゆ(ヤ下二) too. Larger dictionaries such as 広辞苑, 大辞林, and 国語大辞典 are all diachronic and treat 上代 も古事記では甲ゆ, 中古 もゆ, and 中世 もゆる in the same entry as modern もえる, and I think we can follow the same approach too. --Dine2016 (talk) 16:04, 8 November 2018 (UTC)
I prefer separating Ancient Japanese and Modern Japanese. Some ancient verb forms are still used in Modern Japanese but the paradigm as a whole is already dead. (I have tried to include as many surviving forms as possible in Wiktionary talk:About Japanese/Conjugation.) — TAKASUGI Shinji (talk) 21:33, 8 November 2018 (UTC)
  • I agree that ja-pron is not the appropriate place for such information. I can sympathize with the desire to include as much information as possible as readily as possible. But there is no direct link between historical inflection and pronunciation as such. I also keep thinking about a comment left some time ago at 'Feedback' where a user complained about having Etymology at the top of the entry because the user was not interested in Etymology. I think that there probably are a lot of users interested in pronunciation of Japanese lemmas, but probably far fewer interested in historical forms. In that case, putting those pieces of information together at the top of an entry may be frustrating. Furthermore, as others have pointed out, although there are reflexes of historical forms in the conjugation of some words, this is not the case for all words. In short, ja-pron is the wrong place for this information, if it is even desirable for all entries. Cnilep (talk) 04:05, 9 November 2018 (UTC)
Ok, thanks, I agree with the idea to limit the pronunciation section to the modern lemma form only and put inflections in a separate section below the definitions. What about creating a unified interface, for example {{ja-infl|もえる|v1|acc=0}} (for modern Japanese) and {{ltj-infl|もゆ|v2s}} (for Classical Japanese) and code the inflection rules in a module, instead of having a separate template for each inflection type? That will be easier to program and come with better extensibility, I think. --Dine2016 (talk) 06:17, 9 November 2018 (UTC)
@Eirikr: Putting the classical form (e.g. 燃ゆ for 燃える) in {{ja-pron}} was actually an idea from 日本国語大辞典, which has a 発音 section of entries that looked like this:

み-ちがえる みちが・ふ〔他ハ下二〕 … 発音 ミチカ゜エル〈標ア〉 〈京ア〉 「みちがふ」ミチカ゜ウ、ミチコ゜ーとも 〈標ア〉 〈京ア〉

As can be seen, the classical 終止形 also has relevance in modern Japanese, with modern pronunciation, Tokyo accent, and Kyoto accent. A Reference Grammar of Japanese even identifies more conjugated forms borrowed from the literary language such as V-uru and V-uréba and give them modern accentuation, indicating their relevance to modern Japanese.
Since the pronunciation section already deals with two different forms: classical 終止形 (≒ modern 連体形) and the modern 終止形, I concluded that it would be convenient to deal with other forms there together. However, if the pronunciation deals with only these two forms, or better yet, only the modern 終止形, and other conjugated forms are listed in a “Conjugation”/“Inflection” section below the definitions with their pronunciation dealt with on their perspective entries, I'm totally fine with that, and it would be more logical as each entry deals with its own pronunciation.
@TAKASUGI Shinji On the other hand, I also agree that separating Ancient Japanese and Modern Japanese has advantages. The current entry ない has three lexemes; the first (suffix in 切ない、幼けない、ぎこちない) is no longer productive in Modern Japanese and is likely to confuse learners. Putting the first lexeme under the Ancient Japanese L2 header would surely be an improvement. --Dine2016 (talk) 11:33, 12 November 2018 (UTC)
I don't believe I am knowledgeable enough to comment productively. —Suzukaze-c 04:29, 13 November 2018 (UTC)

Contribute to the Wikipedia Asian Month 2018Edit

This month is Wikipedia Asian Month and Tofeiku suggested we, wiktionarians, take part of this. So, we discussed in Meta about it, and we ends up with the proposal of working on traditional asian games such as go, hanafuda, xiangqi, shogi, mahjong. There is a lot of games but no category here, and we may also look at the vocabulary used in the game, such as the famous atari in go. So, it's part of LexiSession initiative, and we aim at showing interproject short term projects can be cool, so I hope you like the suggestion, and let us know what you improve around it!   Noé 15:40, 1 November 2018 (UTC)

Synonyms given after each senseEdit

I see that color has synonyms given immediately after each sense rather than in a separate section. Is this how we are doing synonyms now, or is this a permissible alternative method? Or should they be moved to the "Synonyms" section that is also on that page? — Paul G (talk) 07:47, 3 November 2018 (UTC)

Both methods are currently permissible. Some discussion is here. — Vorziblix (talk · contribs) 08:13, 3 November 2018 (UTC)

Passive verbs: should they have full definitions or Template:passive of?Edit

In Northern Sami, there is technically no passive inflection, but many verbs have an accompanying passive verb. This passive verb is a full verb in every respect, and has its own infinitive, participles and can also have words derived from it. Moreover, the meaning can sometimes be somewhat idiosyncratic, and there is more than one way a passive verb could be formed. This makes it seem like it is a lemma in its own right. On the other hand, passive verbs are used very much productively to form passive sentences, and I've often found them missing from other dictionaries, which suggests they are also somewhat inflectional in nature like the North Germanic passive.

I'd like to know how to best treat these. Should they be given a full definition, as if they were a true lemma, or should they be defined with {{passive of}}? Should they appear in the inflection tables of verbs, or the "derived terms" section? —Rua (mew) 13:11, 5 November 2018 (UTC)

In Mongolian I use {{passive of}}/{{causative of}} but also add definitions below that if they don't obviously follow from the verb it is derived from. I use the usual verb lemma headword and they of course don't have an etymology section, but I stopped listing them in derived terms, with a possible exception for passives that have many derived forms themselves. Crom daba (talk) 21:44, 12 November 2018 (UTC)

Vandalism with "by ___" edit summariesEdit

Just curious whether anyone else has noticed the periodic vandalism (it looks like ignorance rather than malice) where the edit summaries strangely begin with "by", along the lines of "by adding it" or "by writing my name". What could be the cause of this odd grammar? Possibly some kind of automated translation? Equinox 14:00, 5 November 2018 (UTC)

Open call for Project GrantsEdit

Greetings! The Project Grants program is accepting proposals until November 30 to fund both experimental and proven ideas such as research, offline outreach (including editathon series, workshops, etc), online organizing (including contests), or providing other support for community building for Wikimedia projects.

We offer the following resources to help you plan your project and complete a grant proposal:

Also accepting candidates to join the Project Grants Committee through November 15.

With thanks, I JethroBT (WMF) 19:46, 5 November 2018 (UTC)

{{quote-meta}} should auto-transliterateEdit

It's strange that {{quote-meta}} accepts a |transliteration= param but doesn't auto-transliterate the way that {{ux}} does. Unless someone objects, I'll fix this and make it auto-transliterate. Benwing2 (talk) 02:47, 6 November 2018 (UTC)

Don’t you need a language parameter for that?  --Lambiam 10:22, 6 November 2018 (UTC)
Please add any tracking categories for the modified templates missing the language parameter, also for {{quote-book}}, which didn't have it before. --Anatoli T. (обсудить/вклад) 11:41, 6 November 2018 (UTC)
  Oppose - I think we should get away from having templates do this sort of thing. Any result which is unlikely to change often should be static text, which is better for the servers and better for anyone who might wish to use the underlying data in any context other than this wiki. If we could make the template subst in the transliteration automatically I would support that. - TheDaveRoss 14:41, 6 November 2018 (UTC)
Ah, but we want to be able to change our transliteration schemes and have that reflected instantly across the wiki. —Μετάknowledgediscuss/deeds 18:39, 6 November 2018 (UTC)
One would hope that such activity would be rare. And when it was required it can be done through via a bot just as easily as through module editing. - TheDaveRoss 19:10, 6 November 2018 (UTC)
@TheDaveRoss: I don't understand your opposition. subst is always a preferred functionality for long transliterations but manual transliteration is also always an option for languages, which don't transliterate automatically or occasionally need it. It shouldn't be a showstopper for not implementing the auto-transliteration. Can you give an example where it's a bad idea?
Note that automatic transliteration for usage examples in Chinese, Japanese, Thai and Khmer exists but it's implementation is different from other non-Roman languages for known reasons. There's also an implementation for Korean with a few tricks, which make it different from the automated Korean transliteration. It would be hard or impossible to merge these three five into the common citation templates. --Anatoli T. (обсудить/вклад) 22:34, 6 November 2018 (UTC)
  Support. DTLHS (talk) 16:09, 6 November 2018 (UTC)
I don't remember where I got the idea, but I use the quotation templates w/o giving them the actual text + templates like {{ja-usex}}. Perhaps doing this all the time would be more simple, and would avoid duplication of {{usex}} and {{quote}} functionality. —Suzukaze-c 02:33, 7 November 2018 (UTC)
@Suzukaze-c: Well, that's what I mentioned in the side comments. These language-specific templates are far-more advanced and do a lot of great work but they don't necessarily have all the bits and pieces present in the other generic templates, such as categorisations of e.g. citations by language or parameters like year, URL, page number, etc. --Anatoli T. (обсудить/вклад) 23:57, 7 November 2018 (UTC)

Making Template:defdate more machine-readableEdit

Right now this template has only one parameter, which is just plain text. This means that there is no actual standard format, the text could be written in any number of ways, which makes Wiktionary harder to parse for automated processes. I therefore propose to introduce a second parameter, so that the first and second give the start and end dates of use respectively. The second argument would be left empty if the sense is still in use. The format of these parameters would still need further standardisation, but it's a start. —Rua (mew) 13:20, 6 November 2018 (UTC)

I think that is a good idea. I am not sure it will ensure the values are standardized or machine readable, but it is a step in the right direction. Oh, and I think it should show still in use if the second argument is empty or missing. - TheDaveRoss 14:44, 6 November 2018 (UTC)
Introducing a second parameter has no effect on whether the values are standardized. Sure, let's add a second parameter as a first step though. DTLHS (talk) 16:14, 6 November 2018 (UTC)
Splitting it into a from and a to date makes that part at least readable. You know, then, that each parameter only contains a single time description, rather than a range between two. My plan is to automatically add "from" before the first argument if there is no second, like the template's talk page suggests that people enter manually. The next step would be to make a module that parses each date and throws an error for a format it doesn't understand. —Rua (mew) 18:46, 6 November 2018 (UTC)
I vehemently oppose this effort as at best premature and probably wrong-headed.
  1. We don't have the information to support the changes proposed, nor is such information likely to be forthcoming, especially not without risking COPYVIO.
  2. At the very least could someone take the trouble to take a census of the information currently in {{defdate}}?. I have never understood how such proposals can be made without a fact base.
  3. If we are to attempt to standardize the use of {{defdate}}, shouldn't we begin by agreeing on what is acceptable data.
@Widsith. DCDuring (talk) 19:40, 6 November 2018 (UTC)
I think "we don't have the information" is the main problem. If we lack it for most senses of most words, there seems little point in making things more complex than they are. Equinox 19:51, 6 November 2018 (UTC)
Splitting it into from and to parameters might be good, but parsing dates and throwing errors for strange formats would essentially make this template useless for some ancient languages (I am thinking particularly of Egyptian here), as chronologies are uncertain and dates can usually only be narrowed down to specific dynasties, reigns, bodies of religious texts, etc. rather than centuries or years. Such usages need to be taken into account somehow. — Vorziblix (talk · contribs) 02:28, 7 November 2018 (UTC)
I have no objection on the face of it. When I created {{defdate}} it was really just to force the font size and square brackets, the actual text bit was always a more-or-less stopgap decision. I do think we are safer continuing to use centuries rather than specific years (in most languages – ancient extinct languages will have to do things differently), partly from lack of information and partly to avoid COPYVIO issues. Ƿidsiþ 07:44, 7 November 2018 (UTC)
Tentative support. I quite like the idea (it bugs me that we vary between "c." and "century" and "Century", or "from" and "From", etc.). However, I'm hesitant about being too restrictive with this. Usually we give dates in terms of centuries, but occasionally we know the exact date something was coined, and it can be useful to give the specific date. We need to make sure that one can use "early", "mid-", "late" in descriptions, and it should be possible to add other notes as well, in case there is more complex information. Andrew Sheedy (talk) 18:51, 8 November 2018 (UTC)
Some format standardization seems appropriate, but will it be the same for English, Middle English, Old English, Torre Straits Creole, and Ancient Egyptian? DCDuring (talk) 18:57, 8 November 2018 (UTC)
I see no reason why the format itself wouldn't be the same most of the time (the meaning might be different (e.g. an Old English word might be marked as "from 10th century", meaning that it survived into Middle English, but not necessarily that it is used today). Ancient Egyptian, I suppose, might mention dynasties rather than centuries, or have more speculative dates, so I'm not sure if it could be forced into a regular format. It might be preferable to vote on a preferred format, rather than imposing it via a template. Andrew Sheedy (talk) 19:10, 8 November 2018 (UTC)
The first step would seem to me to be making a survey of the different formats in use right now. DTLHS (talk) 19:12, 8 November 2018 (UTC)

Per-lemma etymologiesEdit

In the past, "Alternative forms" was allowed to be entered as a level 4 header under the lemma/part-of-speech header, instead of at level 3 above everything else. I want to do this with the Etymology header as well. It makes no sense to me that the etymology is structurally disconnected from the lemma it belongs to (both on level 3) or even that the lemma is subsumed under the etymology. Assigning etymology to lemma instead of lemma to etymology is much more sensible, and it's the structure that Wikidata's lexemes follow as well. My ultimate desire is to entirely abolish level 3 etymology sections, and especially numbered etymologies, but I think in the meantime the two formats can be allowed as alternatives like we already do with "Alternative forms". That way, there is no immediate need to change any entries, and those who want to can experiment with the new format.

For those who think etymology should be visually the first thing to appear in a lemma, before senses, keep in mind that this proposal is about the logical structure of the entries, not the visual ordering. If you want to preserve the ordering, then the only option that also has a sensible logical structure is to have senses under their own L4 header with the etymology L4 header immediately above, both with the lemma's L3 header as their parent. I'm open to this option, but I think senses should come before etymology, those are what users are mostly looking for and not etymologies. —Rua (mew) 19:42, 9 November 2018 (UTC)

What is your vision for the numbered etymology pages format? What headers would be used? DTLHS (talk) 19:48, 9 November 2018 (UTC)
Each lemma would have its own L4 Etymology section, without numbers. —Rua (mew) 20:13, 9 November 2018 (UTC)
So for the English entry set, for example, we would have the level 3 headers Verb, Noun, Adjective, Noun (2), Verb (2), each with potentially their own etymology and no possibility to group them? DTLHS (talk) 21:31, 9 November 2018 (UTC)
Yes, just like in other dictionaries. —Rua (mew) 22:24, 9 November 2018 (UTC)
I agree with the idea. I just think we should do it all at once and not introduce a 3rd layout possibility that will probably stick around with the others for years. DTLHS (talk) 22:29, 9 November 2018 (UTC)
I also think doing it all at once would be preferable if this is to be done. — Vorziblix (talk · contribs) 04:16, 13 November 2018 (UTC)
I was looking at leave as an example of how this would work out. @Rua, might you be inclined to create a trial page demonstrating the proposed new look for our perusal? (BTW, what is the point of the repeated use of heading in the labels for the first leave#Verb?) The proposal makes sense to me; it is also what is promised by the inscrutable passage in WT:ELE that states that “[a] key principle in ordering the headings and indentation levels is nesting”. As an aside, if we had a more structured way of marking up the entries, along the lines of {{entry|lemma=...|language=...|part_of_speech=...|...}}, somewhat similar to many of the citation templates, such sweeping changes could be effected in one swell foop. (See also the (much more modest) suggestion in Wiktionary:Beer parlour/2018/October#What about uniformise a little bit all Wiktionaries?.)  --Lambiam 08:22, 10 November 2018 (UTC)
I made diff. —Rua (mew) 11:32, 10 November 2018 (UTC)
I'm not opposed to this, but I don't like that closely related nouns and verbs will be no more closely grouped than completely unrelated homographs. I think if we make a change like this, there should be some way of linking them together (especially when one POS comes from another POS in English, and their etymologies are no more distinct than the etymologies of different senses under the same POS). Andrew Sheedy (talk) 18:49, 12 November 2018 (UTC)
Well, how do other dictionaries do it? I don't remember ever seeing a dictionary that gives special treatment to etymologically related words. —Rua (mew) 18:42, 13 November 2018 (UTC)
@Rua I don't use online dictionaries other than Wiktionary very much, but the way I usually see it in print dictionaries is that for different etymologies, the headword will be listed again (usually with a number, like a superscript 1, 2, etc.). Each headword is then followed by its various definitions, further grouped by part of speech. This is especially common with more inflected languages, I find, where homographs might have different genders. Andrew Sheedy (talk) 23:29, 13 November 2018 (UTC)
Even so, paper dictionaries don't normally give any etymology at all, so the idea of being "somewhat" related (e.g. from the same PIE root) is enough to justify a grouping. But on Wiktionary, we do give proper etymologies, and words that are related will still each have their own etymology. The verb sleep and the homographic noun have separate histories that each deserve their own etymology section. This is the same whether the history of the words is long or short (if the noun had been derived from the verb only in modern English, for example). My experience is that when multiple lemmas are grouped under a common etymology, this is almost always an error of omission and each one could be given its own etymology. One of them is always the older, and the other derived from the first, or something similar. So in a future situation where every lemma indeed does have its own proper etymology, each etymology section will have at most one lemma. What is there to gain from that layout then? —Rua (mew) 00:23, 14 November 2018 (UTC)
I definitely agree that it would be an improvement to give etymological information for each part of speech (as well as to better indicate the development of different senses over time). I still don't like that the first verb and noun sections of lay would be no more closely connected than they would be to any other senses. However, one possible compromise would be to adopt the same style as the French Wiktionary, and have only one etymology section, and have "Noun 1", "Verb 2", etc. headers. (See botte for an example of what I mean.)
I oppose etymologies following the definitions for the folowing reasons:
  1. There's enough clutter as it is with all the -nyms, translations, derived terms, references, usage notes, etc. following the defs;
  2. Many dictionaries begin with the etymology. Every print dictionary I've seen with etymological information has it before the defs;
  3. Etyms are currently at the beginning of entries, and it would be far, far more work to place them all below defs than it would be to make the modification I am suggesting;
  4. As has been mentioned, it's very easy to skip over information one doesn't care about, and far more confusing if there is inconsistency in the way information is presented, as there would be for some time if we tried to move etyms from where they are;
  5. And finally, if all etymological information were to be put under one header, as I am suggesting, putting it at the very bottom of an entry would make it hard to find and not very clear. Andrew Sheedy (talk) 03:58, 14 November 2018 (UTC)
As I said in my first post, this proposal is about rectifying the logical structure of the entries. If you want the etymology to appear first, then it should still be nested under a header of some sort, so that it's clear that the etymology belongs to some word and doesn't stand entirely on its own. However, I think both that and the current structure are less desirable than the one I proposed, which simply nests etymology below part of speech and definitions. Definitions are primary, so they should come first.
I'm also opposed to the French structure, which is essentially what we used to do for synonyms and antonyms using the {{sense}} template. Each lemma has its own etymology, just like each sense has its own synonyms and antonyms, so separating them out makes no sense for the logical structure of an entry. —Rua (mew) 13:37, 14 November 2018 (UTC)
I like what you are trying to accomplish, but I think that not having etymologies as headers at all is the way to go. Page ordering and layout is currently logical, but has nothing to do with usability (except, perhaps, that English is the first language presented). While etymologies are very interesting, they are, at best, secondary information for most users. The fact that etymology is present before, and with more prominence, than definitions and translations is downright silly. I would have etymologies live in their own namespace, and transclude them at each relevant definition. I would have them displayed in the same manner as usage examples, hidden by default with a small link indicating their existence. Obviously that is not an easy transition to make.
To be clear, I like what Rua is proposing more that the status quo and would support pursuing it further. - TheDaveRoss 19:01, 13 November 2018 (UTC)
Why, heavy language learners sort the words by etymology. Older dictio­naries mingle un­related words to safe space in a confusing manner. I would still separate unrelated words spelled (with all dia­cri­ti­cal marks, if ap­pli­cable) the same as different lemmas even if they aren’t nested under etymologies. عقار‎ looks totally fine. Not knowing the relation of the meanings of كُور(kūr) makes me un­com­for­table. And as a dictionary aiming at de­pic­ting hi­sto­rical be­gin­ning with the ety­mo­lo­gy as the root of all things is ob­vious any­way. I can’t follow @Rua’s ar­gu­ment “It makes no sense to me (…) that the lemma is sub­su­med under the ety­mo­logy.” – Umm that’s the way I imagine the words, so it makes sense to me?
If one uses this dictionary often, the consistent structure allows to learn where to put the eyes to get only the infor­ma­tion one wants, so abundant etymo­lo­gies can be overlooked with resolve (your own fault then if you read too much). People don’t care what is under what, they only care that things are always in the same order. Fay Freak (talk) 23:14, 13 November 2018 (UTC)
That last point is of course an argument for the change as well as against it. However, I made arguments in favour of a logical nesting structure as well, and that is not achieved with the current layout, but is with my proposal. So if all else is equal, logical nesting wins out. —Rua (mew) 00:11, 14 November 2018 (UTC)
Not sure how it’s for it, it seemed to me that you wanted to introduce a new order. However I do remove splitups into numbered etymology sections, often they are really nasty as on حرس, in this example even containing the identical references under each section, which I have lamentably perceived to be the “Benwing layout”. Sectioning needs more discretion. Notably, I have now put that pronunciation file between a lemma template and its header because somebody recording a pronunciation file does not lead me into banjaxing the whole layout based on this file. By the way the pronunciation section layout believed to be standard is too much based on “inflectionless languages” – there is no point in having such sections when words have many permutations and the lemma form is just one, particularly when the pronunciation in a language is certain based on spelling or transcription. Instead the tables should convert the Latin spellings to IPA with a click (like tables resort) and allow inclusion of audio files in parameters. @Rua Fay Freak (talk) 16:27, 14 November 2018 (UTC)
@Fay Freak A problem I see with the current version of that Arabic entry, is that it's not possible to see how each of the words was formed. Surely, Arabic has well-developed methods of deriving words from roots, and it's not just a matter of "fill in some random vowels"? This is the kind of information that I would want to see in an etymology, and it's currently lacking. —Rua (mew) 12:44, 16 November 2018 (UTC)
I support the proposal. The "lateness" with which our entries get around to providing definitions is a recurring complaint from new and experienced users alike, on WT:FEED, entry talk pages, and even in other sections of this very subpage. I sympathise with the sentiment that this should be done all at once, though also with the original suggestion of allowing either format, like with alternative forms: most entries have only one POS and etymology, but for the few that have several etymologies, maybe the current setup is better. (Still, even switching all entries to nested/L4 etymologies would be better than the current setup, I think, if it were a choice between those two options.) Other online dictionaries I can think of also put etymologies after pronunciations and definitions. - -sche (discuss) 17:02, 14 November 2018 (UTC)
I was ambivalent at first, but having thought some more, I also support the proposal. For words with multiple etymology headers, currently the POS is L4, while all its subheadings are L5 — but L4 is visually indistinguishable from L5, rendering the hierarchy confusing and unclear. While I think the loss of closer grouping for multiple headwords with similar etymologies is regrettable, it’s not that great a loss: those headwords will still directly follow each other, and their individual etymology sections will still indicate their close relation. While most print dictionaries have etymologies before definitions, most online dictionaries seem to have it the other way, so either choice seems find as far as precedent (and thus new users’ expectations) goes. I am, however, opposed to hiding etymologies in small links like usage examples, as they’re one of Wiktionary’s greatest strengths — from what I’ve read elsewhere, many users come to Wiktionary specifically to find etymological information — and also as etymologies don’t generally correspond to specific senses but to the whole headword. — Vorziblix (talk · contribs) 19:02, 14 November 2018 (UTC)
Can’t the distinguishability of L4 and L5 be tweaked in some CSS?
The rest I rather harmonize with, particularly the emphasis about similar etymologies: But what’s with leave’s different etymologies for noun and verb if the headwords are even more riven by translation sections? @Rua, you have not mentioned this. Fay Freak (talk) 19:11, 14 November 2018 (UTC)
What do you mean? I didn't change the translations at all. —Rua (mew) 19:24, 14 November 2018 (UTC)
I mean that the translation sections are so heavy that it weighs littles if around them the lemmas are ordered under etymologies.
Wow, I have just reached a wicked idea: What if we put translations sections under each gloss like with {{synonyms}}? Fay Freak (talk) 20:24, 14 November 2018 (UTC)
That has been suggested before, and I would support it in principle. It would make the wikicode very hard to navigate though. —Rua (mew) 20:32, 14 November 2018 (UTC)
Please, let's keep this to one topic. DTLHS (talk) 20:40, 14 November 2018 (UTC)

The problem is that ideally (in my head, and in all historical dictionaries), the definitions flow on from the etymology and so should come after it. But I do agree that it's normal to see at least some indication of the lemma and part of speech before any of that. In an ideal world, the inflection line would itself be the L3, with etymology and definitions coming below, but I realise this is probably unfeasible at this point. Ƿidsiþ 08:47, 15 November 2018 (UTC)

  • I'm sorry, I have TLDR'd this, but just in case my point is relevant, I would like to say that I am strongly opposed to having top-level etymology heading splits for words (esp. parts of speech) that are closely etymologically related. I think this is immensely confusing for users, and that these splits should be reserved for words that are etymologically unrelated. If this is not on-topic, apologies, and please ignore. Mihia (talk) 17:34, 19 November 2018 (UTC)
    But for what reasoning? As I mentioned to Benwing below, what if these words weren't spelled the same, and therefore were placed on different pages? Would it be equally confusing? —Rua (mew) 13:19, 20 November 2018 (UTC)
@Rua I am a bit late to this discussion, but IMO it's extremely important to be able to group etymologically related terms with different POS's under a given etymology. Print dictionaries do this, too; see for example https://books.google.com/books/about/Webster_s_New_World_Dictionary.html?id=wSISgTZ7xrQC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false on page 223 (for the word "fine") or pages 261-262 (for the word "ground"). For example, there are two entries for "fine", labeled "fine1" (= good, well) and "fine2" (= penalty); "fine1" has two POS's under it (adj. and adv.) and "fine2" also has two POS's under it (n. and vt.). I also distinctly remember there being four etymological entries for "flag", each with its own etymology and multiple POS's at least under "flag1". In Russian entries we also rely on this, even though it's less common to have multiple related POS's under the same lemma; see хвата́ть (xvatátʹ) for an example. Benwing2 (talk) 02:12, 20 November 2018 (UTC)
But under what conditions do both parts of speech have the same etymology? If they both existed in Middle English, then one of them derives from each Middle English part of speech, so the etymologies are different. If they were both formed in modern English, then did they both pop into existence at the same time, or was one of them first, and the second derived from the first? Once you start looking at such details you realise that two different parts of speech never have the exact, word-for-word same etymology. And given that assumption, it means that every etymology section will only have one part of speech, in which case my proposal makes more sense anyway. —Rua (mew) 12:59, 20 November 2018 (UTC)
Also, consider the case where all those different parts of speech on fine all had different lemma forms, too. What would their etymologies be then? I am a strong supporter of the principle that entries should be independent of the chosen lemma form and independent of the existence of other entries that happen to be spelled the same. So I would write the etymologies for each part of speech of fine the same way I would if they were all on different pages instead. I don't think we should be omitting etymological information just because certain words are homographs. Each lemma should stand on its own. —Rua (mew) 13:18, 20 November 2018 (UTC)

To give a case in point for my argument that homography of lemma forms should not affect etymologies: In Dutch there is the noun adem (breath) and the verb ademen (to breathe). Both of these have a form in common, namely the singular of the noun is homographic with the first-person singular present indicative and the imperative of the verb. This means that, given a different course of history, the lemma form of both could have been adem and it is just a historical accident that the lemma forms are different. Yet, as you can see, these two lemmas have different etymologies. If the lemma forms were the same, would you keep the two etymologies split, like they are now, or would you merge them like some people do now for English, thereby omitting information that is currently present in Wiktionary, just because the lemmas are homographs? This is why I'm strongly opposed to merging etymologies of related words. The etymologies aren't the same, you're just pretending they are by omitting the information that makes them different. —Rua (mew) 13:31, 20 November 2018 (UTC)

https://en.wiktionary.org/wiki/%D1%85%D0%B2%D0%B0%D1%82%D0%B0%D1%82%D1%8C

  • Although I am not technically knowledgeable about etymologies, I can see that different POS of the "same word" might (and probably do) need different, or at least slightly diverging, etymology explanations, and I absolutely agree that these should be included (given that etymologies are potentially long and technical, and the detail may not be of interest to all users, whether they need to be so prominent at the top of articles is a different question). However, I think this can be readily achieved within one top-level section. For words that are "sufficiently closely related" I advocate this kind of approach:
Etymology
Noun from ... blah blah ... ; Verb from ... blah blah ...
Noun
Blah blah
Verb
Blah blah
Rather than this:
Etymology 1
Blah blah ...
      Noun
      Blah blah
Etymology 2
Blah blah ...
      Verb
      Blah blah
The second layout can then be reserved for etymologically unrelated words. Mihia (talk) 19:26, 20 November 2018 (UTC)

Classical K'iche'(Quiché) Mayan vs Modern K'iche' MayanEdit

There are two languages that are currently sharing the tag K'iche', the modern variety spelled "K'iche'", and the Classical variety, "Quiché". The Classical Variety is written in documents from the 1600's, and differs from the modern variety; for example: the Classical Quiche word for food is tioh, and its modern descendant is ti'ij. I have created the category "Classical K'iche'" to sort the Classical words from the Modern. We should change the tag "quc" tag or change the word headings to Classical K'iche' to avoid confusion. Aearthrise (𓂀) 14:19, 10 November 2018 (UTC)

Etymology of phrasal verbsEdit

Would it be possible to trace some notion similar to etymology for phrasal verbs? Otherwise, what relevant lexicographic information could be added? --Backinstadiums (talk) 18:10, 10 November 2018 (UTC)

Date of first use is one possible item. DTLHS (talk) 20:26, 10 November 2018 (UTC)
@DTLHS: What about [[forbrecan]] > [[break up]] ? --Backinstadiums (talk) 20:46, 10 November 2018 (UTC)
@Leasnam could probably answer that. DTLHS (talk) 20:58, 10 November 2018 (UTC)
I've made a few etymologies for phrasal verbs (I can't seem to actually find an example at the moment though...) where it was possible that the verb + adverb was derived from an inflected or imperative form of an earlier separable-prefix type verb (similar in Dutch and German) in Middle English, like come up from upcomen. We still have upcome however which is fading away in favour of its replacement, and it's possible that the adjective upcoming may be a relic of the earlier verb's present participle. I'll keep looking for an example I've actually worked. Additionally, there may also be the kind mentioned by Backinstadiums where the verb has been supplemented (translated?) from an earlier synonymous verb with a different structure. Those are more difficult to prove a connection to IMO, but is possible that a move from for- + verb to verb + up (compare also for be- + verb to verb + about) was made across multiple verbs at one time. I haven't really read anything (yet) stating that was the case. Leasnam (talk) 21:30, 10 November 2018 (UTC)
@Leasnam This URL for concise academic references to the reasons of the change. --Backinstadiums (talk) 21:56, 10 November 2018 (UTC)
@Backinstadiums Thanks ! I'll take a look at it. Also, I found a phrasal verb that I "etymologised": break off Leasnam (talk) 22:10, 10 November 2018 (UTC)
@Leasnam: According to this reference, abrecan > break off --Backinstadiums (talk) 22:18, 10 November 2018 (UTC)
There's nothing in that article that says that phrasal verbs are direct descendants in an etymological sense of anything in Old English. They're a different construction that replaced the prefixed-verb construction and filled in the same "slots", just as the gerund replaced many uses of the infinitive. Referring to one as the "ancestor" of the other seems to be strictly a metaphor, and not something to be cited in an etymology. I would say that the replacement of Old English forbrecan with English break up is just applying a different, but equivalent construction to the same verb- English up and Old English for- aren't related in any etymological sense, and one isn't a descendant of the other. Chuck Entz (talk) 01:29, 11 November 2018 (UTC)
@Chuck Entz, I would agree with you...there is no etymological connection between forbrecan and break up. Break up simply replaces OE forbrecan/ME forbreken/ModE forbreak with a newly constructed word: break up Leasnam (talk) 08:21, 11 November 2018 (UTC)
@Leasnam, Chuck Entz: ORIGINAL POST: ... some notion similar to etymology ... Otherwise, what relevant lexicographic information ... --Backinstadiums (talk) 10:28, 11 November 2018 (UTC)
@Backinstadiums I suppose then the answer is simply: not much. You could list the Middle English or Old English word for comparison, but that does little except show that those languages had a synonymous term for whatever the new English term is. In cases where the change-over is regular, like a note showing break up replacing earlier forbreak might be interesting (and we do this often when a French word displaces a native word)...but it also can add unnecessary clutter. Leasnam (talk) 18:50, 11 November 2018 (UTC)
@Leasnam What reference did you use to etymologyze break off? --Backinstadiums (talk) 20:01, 11 November 2018 (UTC)
Middle English Dictionary (University of Michigan) Leasnam (talk) 20:31, 11 November 2018 (UTC)
As far as I can tell, Proto-Germanic had no phrasal verbs. All it had were verbs prefixed by various (unstressed!) adverbs, and verb+adverb phrases like they still exist in English. This is the situation that's found in Gothic. The prefixed verbs have become relics in modern English, and the verb+adverb combinations have taken over. The separable verbs of Dutch and German arose from those same verb+adverb combinations, but the quirks of OV+V2 word order in those languages mean that the verb is sometimes after the adverb (OV) and sometimes before (V2). English has VO word order, so there is no need for separable verbs; the same situation is found in other Germanic languages with VO order, such as Swedish. —Rua (mew) 22:53, 10 November 2018 (UTC)

Change coming to how certain templates will appear on the mobile webEdit

CKoerner (WMF) (talk) 19:34, 13 November 2018 (UTC)

confusing article layoutEdit

Please take a look at policy and imagine this is your first time here.

Our article layout makes (especially but not only longer pages in) our dictionary very user unfriendly or even unusable for most people because we don't have the policy of listing the rare and obsolete meanings last, as most or all other good modern dictionaries now do.

In addition, we need a better UI that puts meanings with different etymologies close to each other. Most people never find the only other common meaning of the noun "policy" because it's physically so far away, and confusingly after the verb with the first etymology.

Etymologies are wonderful and one of the strengths of this dictionary, but they should be folded away (like the quotations are now) instead of confusing users and preventing them from finding what they're looking for (or, in fact, ever coming back). --Espoo (talk) 05:57, 14 November 2018 (UTC)

I disagree that etymologies should be hidden by default, but I do think that we should organized definitions by how common they are, and/or by their relation to each other, and include information about historical development in the etymology. Andrew Sheedy (talk) 12:56, 14 November 2018 (UTC)
I definitely agree that an obsolete sense should never be the first sense listed, unless there are only obsolete senses. —Rua (mew) 13:31, 14 November 2018 (UTC)
I disagree. I think earliest senses should be first, including when they're obsolete, as in any historical dictionary (which Wiktionary is, like it or not). Ƿidsiþ 14:42, 14 November 2018 (UTC)
What makes you believe Wiktionary is primarily a historic dictionary rather than an all-purpose one? Allahverdi Verdizade (talk) 18:22, 19 November 2018 (UTC)
Currently entries have a chronological logic, hence first the origin, then the (known or presumed) first or original senses. That’s useful for historical reading. Often one can also group meanings in abstract formulation (so field) to make pages more readable. Frequency is also a criterion however, and it does not exclude counting historical usage. One just has to look if one thinks the result looks best. On policy one may perhaps try grouping. Fay Freak (talk) 14:50, 14 November 2018 (UTC)
I have no objections to a historical ordering of definitions, personally, but if we're going to do it, we should do it consistently, and recognize that mainstream users are not our target audience. I doubt Wiktionary will ever be a truly valuable resource for the average person, unless other dictionaries go out of business or something. We're much better off tailoring ourselves towards people with an interest in language. Andrew Sheedy (talk) 18:34, 14 November 2018 (UTC)
To be honest I agree. Serious dictionaries are not really ideal for casual users looking up common meanings of slightly uncommon words. On the other hand, there are ways that could be tried. For instance, we could order things historically but slightly "grey out" the obsolete senses, and/or perhaps "highlight" or "star" in some way the most common ones. Ƿidsiþ 08:37, 15 November 2018 (UTC)
"Currently entries have a chronological logic" They certainly do not- that is promulgated by certain users but by no means universal in practice or required. DTLHS (talk) 18:36, 14 November 2018 (UTC)
Aye that’s what I said. They just have it. Not exclusively. Also frequential and topical or abstract grouping is done and of course no or arbitrary grouping in many entries. This dictionary is driven by fancy. Fay Freak (talk) 18:49, 14 November 2018 (UTC)
Apropos of one or two of the comments above, I would be disappointed if Wiktionary did not aspire to be accessible to mainstream users, or at least "upper mainstream" users. I would consider myself a upper-ish mainstream dictionary user, certainly not a linguist or language expert, and I find myself increasingly using Wiktionary as a go-to dictionary for practical purposes. Partly this is because of the absence of ads and extraneous crap, and partly because of its breadth of coverage and the pretty good quality of a large part (not all) of its content. Personally I disagree with the chronological order approach, and the consequent risk of obsolete senses appearing first, though I understand the reasons why some people advocate this approach. In an ideal world, in my opinion, definitions should by default appear with common modern senses first and/or in "logical" order, but each definition would have a "first recorded use" date attached, and there would be a function for users to sort by that if they desired. Obviously it would be a huge task to implement that across the project. Mihia (talk) 23:05, 17 November 2018 (UTC)
I've suggested that before, but I think it's a distant dream at this point... Maybe in 20 years, when people have nothing better to do here than adding {{defdate}} to entries. Andrew Sheedy (talk) 23:53, 17 November 2018 (UTC)
It just doesn't work for entries with dozens or hundreds of senses, and besides, having "common modern" senses first is not the same as a "logical" order. The most common use of "mouse" for most people now is a piece of computer technology, but it would surely seem bizarre to list it first. Historical ordering is the only system that has any data-based logic to it, and it also helps explain the sense-development of a word, which should be one of the main jobs of a dictionary – see something like bead for a simple example. But I agree it would be nice if, for instance, obsolete senses could be "greyed-out" or something, or maybe if very common senses could be highlighted somehow. Ƿidsiþ 08:44, 19 November 2018 (UTC)
When you say "it just doesn't work", "it" refers to putting "common modern senses first and/or in "logical" order", right? (I initially replied thinking that it referred to the idea of having a user sort function.) Mihia (talk) 17:50, 19 November 2018 (UTC)
Right! Ƿidsiþ 08:24, 20 November 2018 (UTC)
I do not see why "common modern senses first and/or logical order" does not work for long entries. Of course, unlike chronological order, it does not provide a unique ordering. It is to some extent a matter of opinion how senses are grouped and ordered. However, I don't think, in my somewhat limited experience here, that I can recall any serious dispute between people about this issue (I mean, assuming that "common modern senses first and/or logical order" is to be followed, a dispute about how entries should be ordered under that scheme). I think in the majority of cases there will be broad acceptance across a moderately flexible spectrum of orderings. By the way, I did not intend to suggest that "common modern senses first" and "logical order" were always the same thing. In fact, "and/or" was supposed to indicate exactly the opposite. For example, if a long entry is split into subgroupings A, B, C, etc., and A contains common senses, but a less common one should also "logically" go in that grouping, rather than further down the list, then fine, that can be accommodated. Mihia (talk) 22:56, 20 November 2018 (UTC)
Well, what's the commonest meaning of set? Or put? How do you quantify it? As for logical groupings using subsenses, I see what you mean and yes, that is also done with historical ordering too – each main logical "group" is organised chronologically but related senses are then kept together. See for instance mark, Etymology 1. Ƿidsiþ 09:20, 21 November 2018 (UTC)
Finding the single commonest meaning of a highly polysemous word may be difficult, but there is no difficulty in putting all archaic/obsolete senses after all those that are not. Equinox 11:23, 21 November 2018 (UTC)
I don't personally think that "common modern meanings first and/or logical order" requires us to exactly quantify "commonest". My feeling, as I say, is that there is a fair degree of flexibility. I think that, under this scheme, most people would be happy most of the time with anything that seems "sensible". Mihia (talk) 18:41, 21 November 2018 (UTC)
I originally supported ordering senses by date, and I appreciate that this helps show how senses developed, but I now agree that putting obsolete senses first is unhelpful to people who turn to the dictionary for the unlikely</sarcasam> purpose of learning what the word means (present tense). (It also precisely doesn't show how senses developed, whenever a 'bridging' sense obviously must have existed between two senses but doesn't have surviving attestations until later.) On polysemous entries I've overhauled like take or know or absolute, I've used a "logical order", and this is indeed (as Mihia says) easier to do a de-facto-acceptable job of than some people think: I haven't tried to ascertain which common sense is exactly most common, just started with a common basic sense and ordered other common senses after it "logically" based on (synchronic) semantic similarity/development, which people have found acceptable and indeed liked enough that they've asked me to overhaul other entries.
Greying-out obsolete senses is an interesting idea, and I'd like to see it mocked up; perhaps it wold help, though it might be tricky to make the greying-out sufficiently noticeable without making it so light as to make the text hard to read; or, if grey background/highlighting were used, it might perversely highlight those senses (but maybe that wouldn't actually be a problem / confuse anyone). Also, as someone (Ruakh?) pointed out about an earlier idea in that vein, editors' decision of whether to mark something as obsolete vs archaic vs dated might then be influenced by whether or not they thought it was important enough to deserve 'full' display (although that seems entirely manageable / relatively easy to fight/fix). - -sche (discuss) 17:12, 21 November 2018 (UTC)
Yes, this seems like the right approach to me. Don't worry about precisely which sense is most common, but in principle do put the "common sense" current uses early in the list. Other senses can be ordered "logically", whether that be by synchronic similarity or diachronic evolution. This will, of course, always be imperfect and controversial, as people don't all share one idea of "common sense" or "logic" in this sense, but the difficulties seem workable. Also, I would support making etymologies collapsible. I don't have a strong preference for whether they should be collapsed by default – whether showing them should be opt-in or opt-out – but whichever version is the default, the other should be readily opt-able. Cnilep (talk)
Indeed, putting obsolete senses first is user unfriendly. There was a poll at Wiktionary:Beer_parlour/2012/December#Positions of obsolete senses. Maybe views have changed. The current status is undecided and therefore, the actual practice is mixed; Wiktionary does not have the established practice of putting obsolete senses first. --Dan Polansky (talk) 09:36, 25 November 2018 (UTC)

not itEdit

[2] [ זכריה קהת ] Zack. — 13:10, 16 November 2018 (UTC)

WT:About Chinese: Romanisations of CantoneseEdit

According to the present policy, Pinyin romanisations of monosyllables and polysyllables for Standard Mandarin (aka Putonghua), such as "" and "bùguò" are allowed. However, for Standard Cantonese, only Jyutping romanisations of monosyllables of monosyllables are allowed (e.g. jyut6, ping3), while those of polysyllables are disallowed. Why is there such unequal treatments for the two languages? I believe that Jyutping romanisations of polysyllables should be allowed and massly created, as Pinyin romanisations of polysyllables are allowed and exist in a large quantity. Jonashtand (talk) 15:59, 16 November 2018 (UTC)

@Jonashtand: Interesting question; try posting in its talk page itself. --Backinstadiums (talk) 19:03, 21 November 2018 (UTC)

Nest "Further reading" under lemmaEdit

According to WT:EL, the "Further reading" heading should be level 3, placed below all the lemmas. But there is always further reading about something. I doubt you'll find many cases where you find further reading material about all words spelled X, but instead you would find material about a particular lemma. To me, it therefore makes more sense to treat this as a level 4 header, and nest it underneath the lemma to which it applies. This is also useful in the interest of machine readability, because a bot can't tell which information belongs to which lemma if it's all put together under the same section. —Rua (mew) 11:57, 17 November 2018 (UTC)

  • I agree this makes more sense. In those cases where there are several lemmas for a given language and the further reading happens to apply to all, it should remain at the L3 level, though.  --Lambiam 07:45, 18 November 2018 (UTC)
    • And if some of it applies to all, but not the rest? —Rua (mew) 11:54, 18 November 2018 (UTC)
      Probably we should, in general, attach extra info to the deepest common node of all lemmas to which it applies, so as to avoid duplication while remaining otherwise as specific as possible. But there may always be exceptions to the general rule, based on considerations of common sense.  --Lambiam 06:28, 19 November 2018 (UTC)
      • I suppose the same should apply to References, Derived terms, Related terms, See also. Perhaps we should follow the example of Synonyms and place the items under appropriate senses and/or subsenses. DCDuring (talk) 16:36, 18 November 2018 (UTC)
  • If the “Further reading” section is on L3 it apparently applies to the whole language section – the machine-readability part is a strawman. And indeed in many cases one finds reading material about words spelled X, like general Arabic dictionaries include words spelled a certain way. And in general my impression is that the links and references are detached from the lemmata and I have an aesthetical aversion to “further reading” placed on L4; it clutters. When I prefer a layout it is to make it palatable to the eyes and not because it is most logical. Like with map projection you must bid farewell to the notion that you could project the reality of language in a truest way into the two-dimensional space of a reference work. Fay Freak (talk) 01:40, 19 November 2018 (UTC)
  • I prefer Further reading at L3 rather than L4; it makes the page less cluttered and makes it easier for me to find the further reading since it is at a predictable location at the end of a language section. --Dan Polansky (talk) 09:31, 25 November 2018 (UTC)

Layouts of zenith, nadirEdit

Stumbled across the layouts of zenith and nadir just now (see synonyms and antonyms specifically). This is not the WT:ELE standard layout, but I do like it. Has this been discussed before? Especially if the synonyms and antonyms become collapsible this would be my strong preference. @Jberkel as the editor in question. - TheDaveRoss 15:25, 19 November 2018 (UTC)

It's been discussed many times before. DTLHS (talk) 17:53, 19 November 2018 (UTC)
@TheDaveRoss Although collapsible -nym sections aren't the default, you can make it so for yourself, courtesy of Ungoliant: importScript("User:Ungoliant MMDCCLXIV/synshide.js"); Andrew Sheedy (talk) 03:02, 20 November 2018 (UTC)
Thanks for sharing that. While I appreciate being able to have a better personal experience, I also think that it this would be a better experience for the 24 million other people who will view the site this month. I appreciate the thought Rua has been putting into the user experience tweaks, it would be great if we could collectively put some additional thought and effort into that front. - TheDaveRoss 13:11, 20 November 2018 (UTC)
We should probably also "formalize" the current practice and include it in WT:EL. I'll set up a vote to do so. – Jberkel 16:58, 20 November 2018 (UTC)
Agreed with both the above. Andrew Sheedy (talk) 18:02, 20 November 2018 (UTC)
@TheDaveRoss: I dislike that a lot but I am in a minority. I gave an example where it makes the entry harder to peruse at User talk:Dan_Polansky/2017#Separate synonyms sections; it was cat entry. There was a poll in Wiktionary:Beer parlour/2017/May#Poll: putting "nyms" directly under definition lines. The items are shown as uncollapsed in mobile view. --Dan Polansky (talk) 09:27, 25 November 2018 (UTC)
@TheDaveRoss, DTLHS, Andrew Sheedy, Dan Polansky Please have a look at Wiktionary:Votes/pl-2018-11/Allow semantic relations under definition lines, in which I've tried to address and synthesize the various concerns and requirements, not an easy task. – Jberkel 01:52, 27 November 2018 (UTC)

Template:FWOTD‎Edit

Protection needed.--2001:DA8:201:3512:34FD:9D6E:E918:F818 17:29, 19 November 2018 (UTC)

Done; I only gave it AC protection, but any admin at their discretion may increase it. SURJECTION ·talk·contr·log· 17:32, 19 November 2018 (UTC)

The use of k in normalisation of old continental West Germanic languagesEdit

The general practice among dictionaries of these old languages is to use k and never c, when spelling normalisation is applied. Our own entries mostly follow that practice. But when you look at how these languages are actually written, you find that c is the norm, and k is only used before e or i. This is the standard that's used for Middle Dutch normalisation on Wiktionary, but not for Old Dutch, which is a bit strange. For example, look at the various attested spellings of drinkan, fisk, folk, kraft, kuning and sprekan. There are some forms with k, but c is definitely in the majority. In the case of kwethan, there's not a single attestation with a k. So I think it would make more sense to use the forms with c as the lemmas on Wiktionary, at least for Old Dutch. What is the situation for Old Saxon and Old High German? —Rua (mew) 20:30, 19 November 2018 (UTC)

Personally, I would say whatever form is most commonly attested for each individual word should be the form used for the wikt entry. I'm not a fan of fabricating standardized forms that never actually existed. --Victar (talk) 05:42, 21 November 2018 (UTC)
But what if the fabricated form itself is standard in the field? Grammars of these languages, Old Norse in particular, use only normalised spellings. We'd be doing a disservice to people studying these languages if we included them in an orthography that's incomprehensible to them. —Rua (mew) 12:19, 21 November 2018 (UTC)
I agree... and therefore also think that, iff we did move words to c, we would probably need to leave soft redirects from the "normal normalization" (if it is indeed widespread in literature, and thus the form someone would see and look up), as Widsith suggests. - -sche (discuss) 17:02, 23 November 2018 (UTC)
The study of these languages isn't as widespread as, say, Old Norse or Old English. It's probably mostly confined to people in the Netherlands and Germany who want to learn about the history of their language. This means that the norms are less firmly established overall. Philippa's Dutch etymological dictionary gives this: "Onl. kuning ‘heerser, vorst’ in cuninga tharsis in alende geuon bringon sulun ‘de koningen van Tarsis en de eilanden zullen geschenken brengen’", with the lemma cited with k, but then c in the actual citation. Personally, I find normalisation invaluable, because it helps people studying the grammar and vocabulary by getting rid of variations that don't actually matter. At the same time, the use of normalisation into spellings that aren't used in texts is strange, because then you have to include all actually attested forms as alternative spellings. I suppose if these spellings with k are standard in reference works, then we have to stick with them, even if I wish they'd chosen a different normalisation scheme. For Old Dutch, it gives the impression that Old Dutch writers followed different spelling norms regarding the use of c, k and q than Middle Dutch writers, when that isn't actually the case. —Rua (mew) 11:33, 24 November 2018 (UTC)
  • Generally it's better to have the best-attested form as the lemma, but there may be conventions with some languages which make this undesirable, especially if a language is not well attested overall. If all reference works cite "kwethan" then there is a logic to lemmatising it here. But in the end it doesn't really matter, as long as C-forms and K-forms are both here and one of them acts as a soft redirect to the other. Ƿidsiþ 07:48, 23 November 2018 (UTC)
@Rua, I see you moved over a dozen or so Old Dutch entries to c-normalized forms, but without redirects. I'm with @-sche and @Widsith, and think if dictionaries list a k-normalized form, we should have a redirect from it. --Victar (talk) 20:22, 26 November 2018 (UTC)

{{usex}} inline formattingEdit

I'd like to recommend changing the inline formatting of {{usex}} from:

  • वृषणं धीभिर अप्तुरं सोमम ऋतस्य धारया । मती विप्राः सम अस्वरन ॥vṛ́ṣaṇaṃ dhībhír aptúraṃ sómam ṛtásya dhā́rayā । matī́ víprāḥ sám asvaran ॥To the water-crossing bull, Soma, in a stream of truth have the inspired poets cried out in unison with their insights, their thought.
  • यस्त्वेतान्युपक्ल्प्तानि द्रव्याणि स्तेनयेन्नरःyastvetānyupaklptāni dravyāṇi stenayennaraḥ(please add an English translation of this quote)

to:

  • वृषणं धीभिर अप्तुरं सोमम ऋतस्य धारया । मती विप्राः सम अस्वरन ॥ (vṛ́ṣaṇaṃ dhībhír aptúraṃ sómam ṛtásya dhā́rayā । matī́ víprāḥ sám asvaran ॥, To the water-crossing bull, Soma, in a stream of truth have the inspired poets cried out in unison with their insights, their thought.)
  • यस्त्वेतान्युपक्ल्प्तानि द्रव्याणि स्तेनयेन्नरः (yastvetānyupaklptāni dravyāṇi stenayennaraḥ, [translation needed])

This would standardize it to the formatting used in {{l}}. If anyone has any objections, please let me know. --Victar (talk) 03:13, 21 November 2018 (UTC)

I object. A usex is not a list so it's not clear to me why we should use the same formatting. In a list, the translation and transliteration are truly parenthetical. In a usage example they are much more important. DTLHS (talk) 03:16, 21 November 2018 (UTC)
@DTLHS:, I'm sorry, what do you mean by "not a list" and why's it relative? I'm not sure also why a transliteration and translation wouldn't be parenthetical to the given sentence. --Victar (talk) 03:38, 21 November 2018 (UTC)
Go for it. No reason to misuse mdashes and this is actually a more logical way to do things. But please do not misuse HTML5's <small> tag: it is for fine print. There's no need for small text at all, as this isn't a print encyclopedia. —Justin (koavf)TCM 05:15, 21 November 2018 (UTC)
Regarding the <small>, I'm actually just mirroring what's used in {{l}}, ex. [script needed] (aptúraṃ). --Victar (talk) 05:45, 21 November 2018 (UTC)
  • Throwing another 2p in the pot, I very much prefer the italics for romanizations, as that immediately and obviously sets the romanization apart from the translation. It's much easier to visually parse.
For similar reasons, I prefer the — as the separator, and I dislike the parentheses. ‑‑ Eiríkr Útlendi │Tala við mig 18:06, 21 November 2018 (UTC)
Thanks for your input, @Eirikr. To counter your two points:
  1. If you recall, we recently had a whole debate and subsequent vote about the italicization of transcriptions in {{l}}, and the consensus in the end was that a) italicized transcriptions are more difficult to read, particularly with special ligatures, and b) it causes a loss of data in language transcription systems that use italicization as a means of distinction, such as seen in Hittite.
  2. Em dash as a separator can be very problematic in texts that actually use dashes. For instance, in Rigvedic transcription, dashes are used very heavily to break up sentences. Parenthesis are also good at making it clear that everything within the parentheses is related to the previous sentence. --Victar (talk) 19:09, 21 November 2018 (UTC)
Since it took me a while, to find, I'll post the related vote here: [[Wiktionary:Votes/2018-03/Showing_romanizations_in_italics_by_default]]
FWIW, I ultimately came to disagree then with a blanket approach to changing italicization, and I disagree more now after dealing with some messy fallout from related changes. There were blanket assertions that "italicized transcriptions are more difficult to read", but those were largely subjective statements limited to specific people and specific contexts -- I have encountered no such difficulty myself in working with Japanese, and I've found instead that non-italicized transcriptions can be visually confusing. Granted, I am fully aware that this is specific to my work with Japanese. One idea floated on the vote's talk page was having language-specific settings. I suspect that might still be the better route. ‑‑ Eiríkr Útlendi │Tala við mig 19:39, 21 November 2018 (UTC)
Definite oppose. I think the way it looks know is pretty much perfect. It's easy to parse, thanks to transliterations being set apart from the example sentence, and the translations being set apart from the translaterations. And because the latter are italicized. Parentheses and quotation marks don't do that, and end up squishing everything together. Not to mention that in longer examples like the ones you give, its better if they're on different lines, in which case it makes little sense to add quotation marks and parentheses. Not to mention that people have not used the template in many entries, and the format they usually use is fairly consistent with the current format of the template, so changing what {{usex}} displays would create a lot of inconsistency. Andrew Sheedy (talk) 18:18, 21 November 2018 (UTC)
@Andrew Sheedy see my remarks regarding italicization and the use of dashes above. I want to make it doubly clear, I'm only talking about inline formatting when |inline=1 is used. When not used, the formatting would be the same as it is currently, on multiple lines. --Victar (talk) 19:09, 21 November 2018 (UTC)
OK, good points. I would rather exceptions be made on a per-language basis than make a unversal modification to the template. Andrew Sheedy (talk) 19:19, 22 November 2018 (UTC)

Okay the current formatting looks goofy when one actually uses the quotation dash U+2015 the way it is devised for. So as I just have written:

Indefinite:
Haben wir noch Zwiebeln? ― Es gibt noch welche im Keller.Do we have any onions yet? ― There are some in the cellar.
Haben wir noch Spinat? ― Es gibt noch welchen im Gefrierfach.Do we have spinach yet? ― There is some in the freezer.
Haben wir Streichhölzer? ― Ich hab eins / eines hier gesehen.Do we have matches? ― Ich have seen one over here.

We should use an obelism, which would be in Unicode apparently ÷ U+00F7 DIVISION SIGN, or perhaps ⁜ U+205C DOTTED CROSS. I want the one the left of that image. Such is found as a mark of conclusion in medieval and early modern notarial deeds. (Usex are not comparable to {{l}} links anyway.) Fay Freak (talk) 11:48, 22 November 2018 (UTC)

I'm not opposed to this, although I would rather a regular slash or backslash be used (with about the same amount of space on either side as there is now with the em dashes). I see no reason why spaces should surround slashes in example sentences (as you did in your third example). Andrew Sheedy (talk) 19:19, 22 November 2018 (UTC)
The style I usually use is no spaces when the alternative is between two words, and spaces when the alternative is between phrases. Personally I am not very keen on using slashes to separate original text, romanisation and translation. Forward slashes tend to visually blend in with italic text, and backslashes would just look a bit odd and unexpected, IMO. Mihia (talk) 20:38, 22 November 2018 (UTC)
Wait I did not suggest ”using slashes to separate original text, romanisation and translation.” That’s only coincidentally in the midst of the third example to point to variant declension. I want something ornate that separates original text, romanisation and translation. Fay Freak (talk) 00:10, 23 November 2018 (UTC)
No, you didn't, but I did. Other possible alternatives might include (U+FF5E FULLWIDTH TILDE) or (U+2053 SWUNG DASH), although maybe that would be confusing, given the role they play in other dictionaries. Andrew Sheedy (talk) 01:27, 23 November 2018 (UTC)
Haben wir Streichhölzer? ― Ich hab eins hier gesehen. ➢ Do we have matches? ― Ich have seen one over here.
U+27A2 THREE-D TOP-LIGHTED RIGHTWARDS ARROWHEAD
Haben wir Streichhölzer? ― Ich hab eins hier gesehen. ⧐ Do we have matches? ― Ich have seen one over here.
U+29D0 VERTICAL BAR BESIDE RIGHT TRIANGLE
And to separate transcription and original text there can be a different sign because the connection is closer.
Есть у нас спи́чки? ― Я тут одну́ ви́дел. ⎬ Jestʹ u nas spíčki? ― Ja tut odnú vídel ⧐ Do we have matches? ― Ich have seen one over here.
U+23AC RIGHT CURLY BRACKET MIDDLE PIECE and U+29D0 VERTICAL BAR BESIDE RIGHT TRIANGLE
Есть у нас спи́чки? ― Я тут одну́ ви́дел. ║ Jestʹ u nas spíčki? ― Ja tut odnú vídel ┃ Do we have matches? ― Ich have seen one over here.
U+2551 BOX DRAWINGS DOUBLE VERTICAL and U+2503 BOX DRAWINGS HEAVY VERTICAL.
It is not excluded that you find better combinations. Fay Freak (talk) 02:15, 23 November 2018 (UTC)
How about using an arrow? Like one of the following: → ⟹ ➞ ➥ (the latter could be used when transliterations/translations are displayed on a separate line, for consistency). Andrew Sheedy (talk) 03:59, 23 November 2018 (UTC)
I'm against inventing new symbols and rather think we should stick to close publishing standards. One formatting you might find is Шустрая бурая лиса прыгает через ленивую собаку, Šustraja buraja lisa prygajet čerez lenivuju sobaku, "The quick brown fox jumps over the lazy dog", or perhaps 날쌘 갈색 여우가 게으른 개를 뛰어넘는다 [nalssaen galsaek yeouga geeureun gaereul ttwieoneomneunda] (The quick brown fox jumps over the lazy dog), both of which I think would be better than the current formatting, though I prefer my original suggestion. --Victar (talk) 06:47, 23 November 2018 (UTC)
I actually haven't even mentioned transliterations, which we currently enclose in forward slashes (//). --Victar (talk) 07:00, 23 November 2018 (UTC)
  • In cases where there is a romanisation, I like this to be in italics. It's what I'm used to, I think it sets the romanisation apart clearly, and I do not find it in any way difficult to read. I don't mind the brackets and quotation marks. Mihia (talk) 18:42, 22 November 2018 (UTC)
  Oppose: the lack of decorations in t:uxi is consistent with t:ux. I don't like the idea of making it visually similar to t:l/m either; the decorations of the latter are suited for short text embedded in a sentence (including t:usex-suffix). (yes, t:l is used in lists: but I have personal gripes about those as well). I think that this is a potential application for personal CSS gadgets that can be toggled in Special:Preferences. —Suzukaze-c 23:49, 22 November 2018 (UTC)
Lack of decorations or not, separating the three parts with quotation dashes is unfortunate if the original text contains a quotation dash (which it does when it is in “question ― answer” format). Fay Freak (talk) 00:10, 23 November 2018 (UTC)

Greek pronunciation and funny ordinalsEdit

I found myself at Template:grc-IPA, wondering why periods are identified with Microsoftised ordinals (10th CE and so on). I am not familiar with the language the script is written in, but surely someone should be able to remove the superscripts for normal style? Imaginatorium (talk) 06:24, 21 November 2018 (UTC)

The practice of writing ordinal indicators as superscripts, which became old-fashioned with the introduction of the typewriter, long predates Microsoft. This issue is hardly a fundamental Wiktionary aspect; a better spot to complain may be Module talk:grc-pronunciation.  --Lambiam 09:00, 21 November 2018 (UTC)

Vote: Mnemosientje for adminEdit

Mnemosientje has accepted a nomination for admin. Please see here. ←₰-→ Lingo Bingo Dingo (talk) 11:46, 21 November 2018 (UTC)

Vote: Donnanz for adminEdit

Wiktionary:Votes/sy-2018-11/User:Donnanz for admin. The vote needs to be added to the main vote page. --XY3999 (talk) 23:35, 21 November 2018 (UTC)

Community Wishlist Survey voteEdit

18:13, 22 November 2018 (UTC)

I would like to take this opportunity to point out that there are several proposals concerning the Wiktionnary projects

Other ideas that could help the Wiktionary projects:

Pamputt (talk) 07:39, 23 November 2018 (UTC)

Hey! It seems you are not very concerned by this survey. None of the proposals for Wiktionary came from English Wiktionary community and only few of you supports our proposals. I can't reach any conclusion about your motive for not being into it. Maybe our idea are not interesting for you, maybe your convinced this survey is useless, maybe you prefer develop your own tools internally. I don't know. I'll be glad to hear any critic or point of you about this matter!   Noé 14:35, 27 November 2018 (UTC)

Thesaurus:shit redirectEdit

(Sorry if this is not the correct forum. Correction welcome)

Currently Thesaurus:shit is a redirect to Thesaurus:feces. But while "feces" is the most common meaning of shit, the word also refers to various other things, including rubbish, recreational drugs, and objects generally. Also, Thesaurus:feces includes a Ws link to Thesaurus:shit, which winds up being circular. That is, if one clicks the "shit [Ws]" link on Thesaurus:feces, they find themselves at Thesaurus:feces. It seems to me like the title Thesaurus:shit should be either reworked or deleted. Cnilep (talk) 03:38, 23 November 2018 (UTC)

I'd delete it: vulgar slang is not the best lemma for a thesaurus. Equinox 03:44, 23 November 2018 (UTC)
Not all uses are considered vulgar. We could distinguish the various senses and link for each to the thesaurus entry for an appropriate synonym.  --Lambiam 09:09, 23 November 2018 (UTC)
But there aren't usually separate pages for each sense; there is one page for a lemma. See, for example, Thesaurus:spirit. I think the question is, should we delete this title or rework it into a proper page? Cnilep (talk) 23:31, 23 November 2018 (UTC)
Delete: the name for a Thesaurus page should be a neutral word that has a high level of generality, not jargon or slang. — SGconlaw (talk) 14:25, 24 November 2018 (UTC)
Delete Thesaurus:shit: No redirects in thesaurus. One thesaurus page per term bucket. --Dan Polansky (talk) 15:15, 24 November 2018 (UTC)

I've requested deletion at Wiktionary:Requests for deletion/Others#Thesaurus:shit. Cnilep (talk) 03:10, 1 December 2018 (UTC)

Titles of morphological relations templatesEdit

Discussion relocated from Wiktionary:Grease pit/2018/November

It ({{der3}}) was edited last month removing the automatic title "Terms derived from" and replacing it with "Derived terms" which is merely a repeat of the header, diff. I could revert the edit but …. {{der3-u}} wasn't touched. DonnanZ (talk) 22:41, 20 November 2018 (UTC)

Why does there need to be a title at all, if all we can think of is repeating the header? —Rua (mew) 22:52, 20 November 2018 (UTC)

(Edit conflict) The same happened to {{der2}}, diff, and the same user is responsible. {{der4}} was also tampered with, but this was reverted.

Answering Rua, presently it looks silly, but the title can be amended manually. Extra work which should be unnecessary. DonnanZ (talk) 23:01, 20 November 2018 (UTC)
Sometimes it is necessary to distinguish between different parts of speech, for example, "Terms derived from walk (noun)" and "Terms derived from walk (verb)". If so, then for consistency I feel it would be preferable for other templates to display "Terms derived from walk" rather than just "Derived terms" or nothing. Do we need to have a vote on this? — SGconlaw (talk) 03:04, 21 November 2018 (UTC)
To achieve "Terms derived from xyz (noun)", (verb) or even (adjective), it requires adding "title=Terms derived from xyz (noun)" etc. whether the displayed wording of the template is "Derived terms" or "Terms derived from xyz". I can't see any other way of doing it. But on the whole I would prefer restoring "Terms derived from" by reverting these edits. I don't think a vote is necessary. DonnanZ (talk) 13:05, 21 November 2018 (UTC)
  Support. — SGconlaw (talk) 13:44, 21 November 2018 (UTC)
In that case, there would be separate sections for derived terms from the noun and verb anyway. When does a given derived terms section ever need to contain more than one collapsible list? —Rua (mew) 13:58, 21 November 2018 (UTC)

I would prefer a layout for these collapsible lists that is as follows:

  • In the collapsed state, a few items are still shown, up to a set maximum number of lines, in order to limit the vertical space used. Any additional items will be hidden. This way, if there aren't many items to begin with, there is no need to expand the template.
  • In the expanded state, all items are shown.
  • No visible box around the list, so that it looks the same as a plain list. This reduces visual clutter.
  • No title bar at the top of the box, just a single floating clickable more/less link. The link could be placed in various locations, such as above the list (like now) or below it.

Rua (mew) 13:58, 21 November 2018 (UTC)

I disagree with all of these points. DTLHS (talk) 03:53, 22 November 2018 (UTC)
I agree with DTLHS. No title bar is a non-starter. DonnanZ (talk) 14:52, 22 November 2018 (UTC)
Alerting @Dan Polansky to this discussion. — SGconlaw (talk) 03:09, 23 November 2018 (UTC)
  • It has been my position that repeating "Derived terms" looks less silly than "Terms derived from X", and I pointed out we could leave the title empty and or we could say "Term list" to avoid repetition. As for "Terms derived from walk (noun)" and "Terms derived from walk (verb)", that is not necessary since these are under separate section headings. Showing some terms in the collapsed state as proposed by Rua is also an option. --Dan Polansky (talk) 10:35, 24 November 2018 (UTC)
  • As for forum, this does not belong to Grease pit: it is about the user-visible appearance of things, not about technical means of achieving a particular appearance. --Dan Polansky (talk) 10:39, 24 November 2018 (UTC)
I brought the matter here as they are templates, without thinking that it would grow into a lengthy discussion. Fortunately there are ways around the problem created, which I will use. DonnanZ (talk) 11:06, 24 November 2018 (UTC)
  • I like Dan's suggestion to use "Term list" as the header, or maybe even just "List". That way, you don't need different titles for different types of list, and can bring down the number of templates needed ({{der3}} vs {{rel3}} etc). My ultimate preference is still for what I suggested above, though. —Rua (mew) 11:42, 24 November 2018 (UTC)
This matter is getting out of hand, diff. I hate to say this, I think these templates need to be protected by admin-only editing. And maybe the discussion should be moved to the Beer Parlour. DonnanZ (talk) 12:30, 24 November 2018 (UTC)
I am fine with Rua's "List" as well. I am fine with showing a condensed list unless uncollapsed, as proposed by Rua. As for the out of hand thing, this is handled by the status quo ante principle, which I am applying as usual. --Dan Polansky (talk) 13:58, 24 November 2018 (UTC)
@Rua, was your idea something like this? --Victar (talk) 00:26, 28 November 2018 (UTC)
Yes, pretty much! Nicely done! —Rua (mew) 13:48, 28 November 2018 (UTC)

Despite DonnanZ's view, I think a vote is going to be required to eventually resolve this issue. By all means please continue the discussion above the line, but I've created a voting section below. — SGconlaw (talk) 14:33, 24 November 2018 (UTC)

The below is not a vote but a poll. --Dan Polansky (talk) 15:12, 24 November 2018 (UTC)
Is there some special way in which these terms are used here at the Wiktionary? — SGconlaw (talk) 15:27, 24 November 2018 (UTC)
Sure, votes have a vote page, as a subpage of WT:VOTE. They land on many people's radar screen since they are automatically added to the watchlist. --Dan Polansky (talk) 15:31, 24 November 2018 (UTC)
I see. — SGconlaw (talk) 17:19, 24 November 2018 (UTC)

This should be made into an actual vote. --Victar (talk) 04:43, 25 November 2018 (UTC)

Option 1: The default text should be "Terms derived/related/etc. from/to XYZ"Edit

  •   SupportSGconlaw (talk) 14:33, 24 November 2018 (UTC)
    • To summarize my reasons, as mentioned above, if some templates are going to be titled "Terms derived from XYZ (noun)", for instance, then for consistency I feel the rest of them should be similarly titled "Terms derived from XYZ". — SGconlaw (talk) 17:17, 24 November 2018 (UTC)
      • But there is hardly ever a need for there to be "Terms derived from XYZ (noun)"; the location of the section heading makes it clear whether they are derived from a noun or a verb. Furthermore, even if such sections were next to each other, they could be just listed as one list since it does not really matter whether a term is derived from a verb from a noun. --Dan Polansky (talk) 08:19, 25 November 2018 (UTC)
  •   Support, "derived from" actually. DonnanZ (talk) 14:36, 24 November 2018 (UTC)
  •   Support DTLHS (talk) 16:48, 24 November 2018 (UTC)
  •   Support Panda10 (talk) 17:15, 24 November 2018 (UTC)
  •   Oppose Too wordy, while only repeating items already on page. --Dan Polansky (talk) 15:21, 24 November 2018 (UTC)
  •   Oppose, it just repeats the header. —Rua (mew) 15:30, 24 November 2018 (UTC)
  •   Oppose duplicating instead of clarifying. DCDuring (talk) 17:30, 24 November 2018 (UTC)
    @DCDuring: I agree in regards to the option below, but this option does add more clarification. Is there any way you think it could be better clarified? --Victar (talk) 22:34, 27 November 2018 (UTC)
    Maybe I didn't understand. As I see it, unless a contributor replaces or edits the text, what would appear to users would be "Terms derived/related/etc. from/to XYZ". Is the intent to shame the contributor into editing or deleting the show/hide bar text? Perhaps we could augment the shame by inserting the user's name in the bar as well, and display it in red. DCDuring (talk) 00:07, 28 November 2018 (UTC)
  •   Support --Victar (talk) 04:43, 25 November 2018 (UTC)
  •   Oppose Equinox 08:24, 25 November 2018 (UTC)
  •   Weak support for lack of anything better. — Vorziblix (talk · contribs) 21:09, 25 November 2018 (UTC)
  •   Oppose unwieldy. Ƿidsiþ 05:26, 28 November 2018 (UTC)
  •   Oppose Circumvention (rephrasing) of a repetition (option 2). Fay Freak (talk) 14:06, 28 November 2018 (UTC)
  •   Abstain. Neither good nor bad. Per utramque cavernam 23:00, 29 November 2018 (UTC)

Option 2: The default text should be "Derived/Related/etc. terms"Edit

  •   Abstain This is acceptable, but "Term list" or "List" would address the concern that the heading, e.g., "Derived terms" is then immediately repeated in the title of the collapsible section. --Dan Polansky (talk) 15:21, 24 November 2018 (UTC)
  •   Oppose: don't see much point in the title duplicating the section heading exactly. — SGconlaw (talk) 15:26, 24 November 2018 (UTC)
    I think the point is to avoid an empty title. I think an empty title is acceptable; it is also not listed as an option. And if duplicating a section heading is pointless, it is even more pointless to rephrase the section heading and at the same time duplicate the entry name. Such a duplication may fool the eye, but will not fool the perceptive mind. --Dan Polansky (talk) 15:29, 24 November 2018 (UTC)
  •   Oppose, it just repeats the header. —Rua (mew) 15:30, 24 November 2018 (UTC)
  •   Oppose for the same reason as SGconlaw. DonnanZ (talk) 15:42, 24 November 2018 (UTC)
  •   Oppose duplicating instead of clarifying. DCDuring (talk) 17:30, 24 November 2018 (UTC)
  •   Oppose --Victar (talk) 04:43, 25 November 2018 (UTC)
  •   Oppose Equinox 08:24, 25 November 2018 (UTC)
  •   OpposeEru·tuon 06:31, 28 November 2018 (UTC)
  •   Oppose repetitive. Fay Freak (talk) 14:06, 28 November 2018 (UTC)
  •   Abstain. Neither good nor bad. Per utramque cavernam 23:00, 29 November 2018 (UTC)

Option 3: The default text should be "Term list" or "List"Edit

  •   Support, given the three options given. The creator of the poll omitted Rua's proposal of showing a couple of items even when uncollapsed, which is also a good option that I's support. Let's explore options. --Dan Polansky (talk) 15:18, 24 November 2018 (UTC)
    • Sure, please add further options as required. — SGconlaw (talk) 15:20, 24 November 2018 (UTC)
  •   SupportRua (mew) 15:30, 24 November 2018 (UTC)
  •   Oppose - DonnanZ (talk) 15:41, 24 November 2018 (UTC)
I come across this at knowledge, I wasn't impressed and was tempted to modify it. I left it so others can form an opinion. DonnanZ (talk) 21:07, 27 November 2018 (UTC)
  •   Oppose, because I don't think "term list" or "list" is clear enough. — SGconlaw (talk) 16:32, 24 November 2018 (UTC)
    @SGconlaw: Can you clarify? Are you saying that when there is a heading "Derived terms" and, underneath, there is a collapsible section entitled "Term list" or "List", the user would not know what to expect there? --Dan Polansky (talk) 16:55, 24 November 2018 (UTC)
    Personally, I feel that "term list" is an odd collocation, the meaning of which is not immediately evident. As for "list", it seems too terse and so a little unclear. — SGconlaw (talk) 17:13, 24 November 2018 (UTC)
    @SGconlaw: Why does "List" need clarifying, given there is "Derived terms" immediately above it? What makes you say "term list" is an odd collocation, in view of google books:"term list", which finds "A bridge of words: a term list based on the study and classificatio ..." as the first item found and contains plentiful other items found? --Dan Polansky (talk) 17:39, 24 November 2018 (UTC)
  •   Oppose Panda10 (talk) 17:16, 24 November 2018 (UTC)
  •   Oppose per SGconlaw. DCDuring (talk) 17:26, 24 November 2018 (UTC)
  •   Oppose --Victar (talk) 04:43, 25 November 2018 (UTC)
  •   Oppose Equinox 08:25, 25 November 2018 (UTC)
    @Equinox: May I ask about your preference, if any? Should the collapsible box be empty? Should it show →? Should there be no collapsible box per default? Or should it show a truncated list, as proposed by Rua? --Dan Polansky (talk) 08:29, 25 November 2018 (UTC)
    All of the options are very stupid and people deserve what they get. I hope that answers your question. Equinox 15:38, 25 November 2018 (UTC)
  • Weak   support. It's at least not repetitive. — Eru·tuon 06:35, 28 November 2018 (UTC)
  •   Oppose Tautological, of course a terms list follows. Fay Freak (talk) 14:06, 28 November 2018 (UTC)
  •   Oppose. Per utramque cavernam 22:56, 29 November 2018 (UTC)
  •   AbstainSuzukaze-c 02:02, 30 November 2018 (UTC)

Option 4: The default text should be →Edit

  •   Support No need for text: Less to parse. Fay Freak (talk) 17:22, 24 November 2018 (UTC)
    I can only see a square and 01F80A in it. --Dan Polansky (talk) 17:40, 24 November 2018 (UTC)
    @Dan Polansky It is an arrow to right. Which do you see?
    (People are used to click on arrows, hence the suggestion.) Fay Freak (talk) 17:43, 24 November 2018 (UTC)
    A right arrow that I can see is →, not the one in the title. In any case, I support making the right arrow the default title. --Dan Polansky (talk) 17:59, 24 November 2018 (UTC)
  •   Oppose, all I can see is a square, totally baffling, less than helpful. DonnanZ (talk) 17:57, 24 November 2018 (UTC)
    @Donnanz: I have changed the the title to show →. Can you please indicate that you oppose that as well? --Dan Polansky (talk) 08:31, 25 November 2018 (UTC)
    I am still unimpressed. DonnanZ (talk) 10:07, 25 November 2018 (UTC)
  •   Oppose --Victar (talk) 04:43, 25 November 2018 (UTC)
    @Victar: I have changed the the title to show →. Can you please indicate that you oppose that as well? --Dan Polansky (talk) 08:31, 25 November 2018 (UTC)
    I am against any symbols in a title. --Victar (talk) 08:40, 25 November 2018 (UTC)
    Thanks. By the way, the right arrow symbol is part of Mediawiki user interface, visible e.g. in diff, where it is clickable. --Dan Polansky (talk) 08:48, 25 November 2018 (UTC)
  • comment: The box currently has the word “show” and a downward-facing triangle at the right end. What if this were shifted to the left side in lieu of a title? Would that look odd? — SGconlaw (talk) 01:57, 27 November 2018 (UTC)
  •   Oppose: I find it strangely jarring. —Suzukaze-c 02:00, 27 November 2018 (UTC)
  •   Weak support if there is no consensus for Option 1. — SGconlaw (talk) 02:03, 27 November 2018 (UTC)

Option 5: Omit the default text and display a few rows of terms, with a button to click on to reveal the restEdit

Note: depends on whether a technical solution for doing so can be found.
See this demonstration created by Victar.
  •   Support, if technically achievable. — SGconlaw (talk) 06:48, 28 November 2018 (UTC)
  •   Support. Yeah, with nice CSS where a line or two get blurred progressively to the bottom. Fay Freak (talk) 14:06, 28 November 2018 (UTC)
  •   Oppose No coherent method for choosing which items to show is proposed. DTLHS (talk) 16:09, 28 November 2018 (UTC)
  •   Caveated support: I would only support this if all headers were removed from Module:columns. --Victar (talk) 17:45, 28 November 2018 (UTC)
  •   Support. I prefer this over the "list" header option if the details of implementation can be worked out. — Eru·tuon 19:59, 28 November 2018 (UTC)
    @Erutuon, I created the module {{links-list}}, which if sorting can be worked in, I think it could replace Module:columns. --Victar (talk) 20:54, 28 November 2018 (UTC)
  •   Support above all other options I have supported. —Rua (mew) 20:09, 28 November 2018 (UTC)
  •   Support. A straightforward method for choosing which items to show is outlined below. - -sche (discuss) 23:18, 28 November 2018 (UTC)
  •   Oppose. The Victar demo looks pretty useless. DonnanZ (talk) 15:51, 29 November 2018 (UTC)
    @Donnanz, I'm fine with the status quo of option #1, but for the sake of being constructive, what so you find "useless" about this idea? --{{victar|talk}} 16:51, 29 November 2018 (UTC)
  •   Support. Per utramque cavernam 22:59, 29 November 2018 (UTC)
  •   Support. The demo Example #1 in User:Victar/der3 looks pretty good, and it can be made even better if adjustments are explored. For reference, the example shows 3 columns and 3 rows. Some time ago, I verified that 3 columns look okay on a fairly small mobile device. I find 3 rows to be okay; there do not need to be fewer. --Dan Polansky (talk) 00:01, 1 December 2018 (UTC)
  •   Oppose I think it gives the impression that the previewed terms are somehow more important or common than the expanded ones. Victar's lists look nice, but... what the hell is wrong with a collapsible box? It's straightforward, simple, and useful even if we can't agree on the text. Ultimateria (talk) 21:55, 1 December 2018 (UTC)
    A collapsible box hides all the items, making it inferior to a plain list, which shows you items without having to click anything. It really annoys me when I have to click a button to see any terms. —Rua (mew) 22:20, 1 December 2018 (UTC)
  •   Support after some thought. — Vorziblix (talk · contribs) 17:09, 4 December 2018 (UTC)

DiscussionEdit

Why not have a pulldown with the finite list of most common headings from ELE? DCDuring (talk) 15:29, 24 November 2018 (UTC)

Could you clarify? — SGconlaw (talk) 16:32, 24 November 2018 (UTC)
I'm not saying that we wouldn't need a default. It just occurred to me that it would be nice if there were a list of common valid content that automagically appeared when {{der}} was first added or on demand by, say, clicking on a "+". Show/hide bars are useful for concealing all kinds of space-consuming content (other than definitions), such as multiline cognates sections and multiple conjectural etymologies, semantic relations etc. Thus "cognates" and "conjectural etymologies" might be included among the choices as well as "terms derived from {{PAGENAME}} ([pulldown for PoS])", "terms related to {{PAGENAME}} ([pulldown for PoS])". We could add other possibilities such "hypernyms of", "hyponyms of", etc. At least there would be some significant labor-saving, arthritis-relieving benefit associated with nudging contributors away from free-form and absent content. DCDuring (talk) 17:26, 24 November 2018 (UTC)

Repeating a header in a template is — not smart. In programming there is a rule called DRY ("don't repeat yourself"). This isn't just to save our fingers but it means that if we make changes (like moving things around) we don't have to change and update a lot of separate copies. If an entry has a Derived or Related Terms subsection then we already know the source term (because it's the entry headword) and the function of the listed terms (because that's what the subheading says) and repeating it is unwise. Equinox 08:53, 25 November 2018 (UTC)

I guess removing the headers like ====Derived terms==== is not an option, is too radical and would upset the applecart. Which is why I support option 1, the best one. DonnanZ (talk) 11:56, 25 November 2018 (UTC)
Of the options above, I guess I like 1 or 2 best, but I am most interested in the suggestion of having no header and just displaying a portion of the list with some sort of "expand" button to reveal the rest (similar to what's done for quotations). - -sche (discuss) 21:51, 25 November 2018 (UTC)
And I suppose we'll just pick 5 random entries to show? Or now we have to do even more work to determine which are the most important and mark them up somehow? DTLHS (talk) 21:52, 25 November 2018 (UTC)
The first entries in the order they are provided, of course. There's no need to make it complicated. —Rua (mew) 22:02, 25 November 2018 (UTC)
I do not mind Rua's proposal if it can be technically implemented, again if there isn't consensus for option 1. Rua, perhaps you would like to formulate your proposal as another option and add it above. — SGconlaw (talk) 19:09, 27 November 2018 (UTC)
(OK, decided to go ahead and add Option 5. — SGconlaw (talk) 07:33, 28 November 2018 (UTC))
See also Victar's demonstration of what it could look like, linked above. I'm not sure yet how to implement it. — Eru·tuon 06:38, 28 November 2018 (UTC)
I don't mind that solution if it can be done. I'd say display no more than two rows, maybe even just one, though. — SGconlaw (talk) 06:48, 28 November 2018 (UTC)
It could be made into a configurable option. Displaying zero rows by default would then be equivalent to the current setup. —Rua (mew) 13:50, 28 November 2018 (UTC)
How would the items to be displayed be selected and ordered? DCDuring (talk) 14:07, 28 November 2018 (UTC)
Wouldn't they just be the terms that would ordinarily appear in the first line(s) of the fully expanded table? — SGconlaw (talk) 15:22, 28 November 2018 (UTC)
Hungarian entries use multiple tables, one for derived terms (with suffix), one for compound words, one for expressions and one for words with verbal prefixes. See folyik. This is to separate the different derivations and to provide clarity and ease for the user to find items. How would this structure be impacted by this change? Panda10 (talk) 17:42, 28 November 2018 (UTC)
We could use ; pseudoheaders like some declension sections have done. - -sche (discuss) 23:18, 28 November 2018 (UTC)
I would rather a |limit= parameter if people want to override the default, but I don't understand why people need to. --Victar (talk) 02:27, 29 November 2018 (UTC)
Abnormal initial characters tend to be especially abundant at the beginnings and ends of alphabetical lists. Look at Category:English lemmas, for instance. Chuck Entz (talk) 04:03, 29 November 2018 (UTC)
I don't see that being an issue with derived terms lists. --Victar (talk) 05:55, 29 November 2018 (UTC)
Victar and Chuck Entz, I'm not sure I understand your replies to Panda, who I understood to be asking how multiple tables would be kept separate and distinctly-labelled if the tables didn't have header bars saying "Derived terms", "With prefixes", etc. I don't think Panda's issue is sorting the terms inside the table. I am suggesting that they could be kept separate by prefacing each headerless table with ;With prefixes etc, like here (except with each list of derived terms being enclosed in a collapsed table). Adding a parameter to the template which would add such a header would also work (but "limit" seems like an opaque name for such a thing). - -sche (discuss) 17:13, 29 November 2018 (UTC)
@-sche:, I was actually replying to @Sgconlaw's concern, but to address @Panda10, subheaders could work, but ====Derived terms with prefixes===, etc. would be just fine IMO. --{{victar|talk}} 23:32, 29 November 2018 (UTC)

Discussion, part 2Edit

My demonstration try based on Victar: User:Vriullop/der3. --Vriullop (talk) 07:35, 29 November 2018 (UTC)

@Vriullop, I don't get it. What's the point of scrolling the collapsed entries line-by-line? If you're going to suggest a scrollbox, you may as well do away with the collapse feature. --{{victar|talk}} 08:11, 29 November 2018 (UTC)
Ok, I did not notice the parameter limit of links-list. Your template does it better, but note that it does not work on mobile view. The difference is that columns are not rearranged and Firefox does not show the scroolbar for just one line. A simple scroll box can be an alternative. --Vriullop (talk) 08:53, 29 November 2018 (UTC)
I'm not enamoured with the scroll box. There are times when one wishes to see all the terms at once, and this is not possible with a scroll box. Also, I'm not sure how well it would work on mobile devices. In general, let's also ensure that whatever solution is adopted meets accessibility standards. — SGconlaw (talk) 09:03, 29 November 2018 (UTC)
On mobile, it's best to just show the full list because mobile browsers often do wonky things with javascript, if it isn't disabled entirely. The collapse method I'm using is the one found in the en.wikt common JS and is used in declension tables and such. --{{victar|talk}} 09:59, 29 November 2018 (UTC)

Yet another version; this time individual list elements are assigned to the hidden and expanded states so there's less duplication: User:Erutuon/der3. (A vsAlwaysShow class would avoid duplication altogether.) I don't love how list items change position between the hidden and expanded states. It would be nice if they could stay in the same position. But since the columns are apportioned by the browser renderer, I don't know of a way to locate the items that should be hidden (the items in all rows besides the rows shown in the hidden state) either in Lua or in JavaScript. — Eru·tuon 10:24, 29 November 2018 (UTC)

Actually I quite like the way the first three items shown in the collapsed list become the first three items in column one when the list is expanded, because it means that we are consistently displaying the first three (or whatever number of) items in the list rather than what randomly happens to be at the top of all the columns in the list. But I'm not too fussed either way. — SGconlaw (talk) 11:00, 29 November 2018 (UTC)
For consistency with other "click to display" links like "quotations", perhaps the "show more" link should be on the right side of the screen? — SGconlaw (talk) 11:04, 29 November 2018 (UTC)
I like Erutuon's method as well, and code-wise it's cleaner than Victar's. A downside is that the number of items that's shown and hidden is hardcoded in the output, instead of configurable in some way. —Rua (mew) 15:34, 29 November 2018 (UTC)
A method I have considered is to not use vsSwitcher at all, but instead have a single div (or even reuse the ul) whose vertical size is changed when the button is clicked. CSS would ensure that the excess items disappear, and no scroll bar is shown. If CSS is disabled, then the box would revert to its default sizing, which means showing all of it. I'd also prefer not hardcoding the number of columns, people have different display sizes so the number of columns should depend on the available width. —Rua (mew) 15:40, 29 November 2018 (UTC)
@Rua, the code in my example has been optimized quite a bit since I initially put it together. You might want to have a look. --{{victar|talk}} 16:02, 29 November 2018 (UTC)
It's better now, but I'm not really fan of dividing the list into two separate lists. I know it doesn't really matter much for how it looks, but I like the HTML to be clean too. —Rua (mew) 16:10, 29 November 2018 (UTC)
The problem with the method Erutuon is using is that vsSwitcher leaves a sliver of spacing for each item you hide, which can add up, and is why you see a huge gap now between the columns and button. I'm not sure what you mean about the HTML being cleaner.
I added a few /n if that's what you meant. --{{victar|talk}} 17:57, 29 November 2018 (UTC)
@Victar: I'm not seeing any extra spacing. It might be a browser-specific thing; I'm currently using Firefox 63. But if it happens for anyone, it's a problem. — Eru·tuon 23:02, 29 November 2018 (UTC)
@Erutuon, I noticed it in my mobile Chrome browser, but I don't see it now in desktop Chrome. --{{victar|talk}} 23:18, 29 November 2018 (UTC)
Now that I've jogged my memory, I've had this problem with declension tables as well when I apply vsHide to table cells instead of rows. I'm wondering if it's related to this. --{{victar|talk}} 00:18, 30 November 2018 (UTC)
Since it's the same JavaScript function doing the showing and hiding, probably the two issues are related. Maybe the mobile Chrome renderer doesn't completely invisiblify elements that have the CSS property display: none; (which is used by jQuery.prototype.hide and thence by the vsSwitcher-handling function), but leaves a bit of space. That is unfortunate because from what I read online it's not how the CSS property is supposed to be rendered. — Eru·tuon 00:33, 30 November 2018 (UTC)
Did you want to make an example of what you have in mind for a vsSwitcher-less version? I'm having trouble understanding it. --{{victar|talk}} 16:38, 29 November 2018 (UTC)
I considered the idea of cutting off the bottom part of the list with an enclosing block element, but is there a way to ensure that the block element cuts off a whole row (does not chop words in half vertically)?
I created an example Example #3, which I think was what @Vriullop was trying to accomplish and what you are referring to above. As you mention, the problem with this is the possibility of cropping the content at the wrong place. I've set it to height:calc(24px * 3) based on line-height:14px;padding-bottom:10px, but I'm not sure how static these values are. --{{victar|talk}} 00:18, 30 November 2018 (UTC)
In my browser, that height value is too large: the top of the letters in the fourth row is visible. The actual size of each row probably depends on multiple factors, such as font family and font size. You could try using em values, which I guess are related to at least one of the font sizes used on the page. — Eru·tuon 01:11, 30 November 2018 (UTC)
The problem is the line-height is set in pixels, not em, which is unfortunate. You might be able to get the line-height in each case using JS. --{{victar|talk}} 01:22, 30 November 2018 (UTC)
In my browser, the line height for the li elements is set in em. So I guess it's browser-dependent or something. That complicates the cropping technique. — Eru·tuon 03:03, 30 November 2018 (UTC)
The number of items that is shown could be configured using JavaScript. If we stick with vsSwitcher, a script could switch the class of some number of elements from vsShow to vsHide or the other way around, and duplicate items if necessary. Then users can decide how many list items to show by default. But that's kind of hacky, so if we want to allow customization, it would make more sense to design a new switcher that hides or shows all but a certain number of items in the list, and doesn't use classes for individual items at all. [Edit: Prototype at User:Erutuon/scripts/listSwitcher.js. To try it, add importScript("User:Erutuon/scripts/listSwitcher.js") to your common.js and look at User:Erutuon/der3 § List switcher.] — Eru·tuon 21:41, 29 November 2018 (UTC) — Eru·tuon 20:41, 29 November 2018 (UTC)
We could also probably use the module to add class="vsShow" to the first, middle, and last items in the terms table.
I'm surprised no one seems interested in Example #2. It's my preference between the two. --{{victar|talk}} 21:23, 29 November 2018 (UTC)

@Erutuon, please checkout Example #4 I created. I'm not sure why the bullets are disappearing, but it seems a pretty straightforward solution. --{{victar|talk}} 06:44, 30 November 2018 (UTC)

@Victar: Looks like li elements need display: list-item;. — Eru·tuon 07:05, 30 November 2018 (UTC)
@Erutuon: Hmm, $("#example4 ul li").addClass("vsHide").css("display", "list-item") didn't fix it. Meh, going to bed, but with this, we can set the number to display with data-vs-showcount="3". --{{victar|talk}} 07:19, 30 November 2018 (UTC)
OK, fixed. --{{victar|talk}} 16:07, 30 November 2018 (UTC)
Your code isn't working for me yet. I think that using simple arithmetic to figure out which items are in each column will not always be accurate. For instance, if several items in column 1 take up two or more lines, then column 2 will start sooner and some of the items from the top of column 2 will probably be in the "vsHide" group. — Eru·tuon 19:42, 30 November 2018 (UTC)
@Erutuon: Fixed. --{{victar|talk}} 21:34, 30 November 2018 (UTC)

Discussion, part 3Edit

Given that some people like Ultimateria prefer a collapsible box, a compromise would be to design the collapsible list in such a way that it can be converted to a collapsible box by JavaScript. Then those who want a collapsible box could just install a gadget or script that changes the list to a box. — Eru·tuon 23:17, 1 December 2018 (UTC)

I would not be in favor of that and in a vote, would downvote it. I would rather the status quo of option #1 than have two formats. --{{victar|talk}} 23:46, 1 December 2018 (UTC)
Why? You would only see the collapsible list format because that's what you prefer. — Eru·tuon 00:17, 2 December 2018 (UTC)
Like I said, I just don't want two completely different looking versions of the same module. If people want to be stubborn, they can modify their personal CSS and JS. --{{victar|talk}} 00:30, 2 December 2018 (UTC)
That sounds rather like what I'm proposing. To make it easy for people to change the appearance of the list through JavaScript or CSS. I don't see where we disagree. — Eru·tuon 00:50, 2 December 2018 (UTC)
Yeah, I might have misread your suggestion. What I'm saying is, I would not support a built in option for users to select between two different versions, but if you're just suggesting some JS or CSS people can put in their common file, I have no problem with that. --{{victar|talk}} 01:15, 2 December 2018 (UTC)
Okay. I don't know what you mean by built-in; I wouldn't object to such a script being added as a gadget. But that is a remote future possibility. — Eru·tuon 01:50, 2 December 2018 (UTC)
Erutuon, what is your rationale for having the boxes expanded by default and collapsed as an option, and not vice versa? Look at water; who wants to scroll past an entire 3.5 screens' worth of derived terms? Ultimateria (talk) 02:17, 2 December 2018 (UTC)
Huh? That's not what I'm proposing. My proposal is to allow users to convert Option 5 (a collapsible list) back to the current format of a collapsible box using JavaScript. — Eru·tuon 02:25, 2 December 2018 (UTC)
Let’s recall that the aim of this discussion is the title that should be used with such lists, and the point of Option 5 is to eliminate the need for a title altogether. If a collapsible table is reintroduced and it needs a title, then we’re back at square one and Options 1–4. — SGconlaw (talk) 04:07, 2 December 2018 (UTC)
Oops, don't know how I read it that way. I'm more or less okay with Option 5 as long as the option to collapse is at the top and not the bottom. But I take the opposite approach to Rua on collapsible boxes. I'd rather open any that I'm interested in than scroll through endless lists on a page; think of Romance verbs like alterar which triples in length when you open the 5 conjugation tables. Ultimateria (talk) 19:24, 2 December 2018 (UTC)
The box has to be expanded by default because otherwise it won't ever be expandable on mobile. This just means that the HTML, as we write it, is in the expanded state. The JavaScript will then collapse it as soon as the page is loaded. I wouldn't like it if the content stayed expanded, either. —Rua (mew) 17:34, 4 December 2018 (UTC)

Advanced SearchEdit

Johanna Strodt (WMDE) (talk) 10:57, 26 November 2018 (UTC)

Fabulous. Wyang (talk) 11:19, 26 November 2018 (UTC)

Mover roleEdit

English Wikipedia has a very convenient page mover role. Would it be possible to make such a role here on en.wikt? I don't have any need for vandalism tools, but I move pages on a daily basis, and relying on admins to delete pages, especially when moving a page back, is a very tedious time-killer. @Chuck Entz, -sche, Surjection, Dixtosa --Victar (talk) 00:50, 27 November 2018 (UTC)

It's probably technically possible, but it'd probably need some kind of consensus within admins, and I'm not sure who exactly could even create a role like that. SURJECTION ·talk·contr·log· 10:56, 27 November 2018 (UTC)
It doesn't exist on this wiki yet, so it's not just waiting for admins to assign. If it's anything like the template editor role, it would require a Phabricator request to the Wikimedia technical powers that be to add it to our wiki, which they would only grant if we demonstrated that there was a consensus here in favor of it- among the community as a whole, not just the admins.
Once it was added, we would need to set up a procedure for nominating and approving candidates. It sounds similar to the rollbacker role, which we currently grant after one admin requests it at the Whitelist and another admin concurs.
At any rate, I'm a bit fuzzy on the exact steps to make it happen, but the above is my general impression based on what happened with the template editor role. Chuck Entz (talk) 14:48, 27 November 2018 (UTC)
Although it's not overly pressing (redirects get deleted eventually), adding such a user group/right seems useful. AFAICT it wouldn't allow vandals to move pages any quicker than the normal "move" function, so I see no reason to be concerned about misuse. Probably a straw poll here would be sufficient evidence of consensus (for linkng to in a Phab ticket), assuming a reasonable number of users participate and this doesn't turn out to be controversial for some reason. - -sche (discuss) 19:31, 27 November 2018 (UTC)
@-sche:, the biggest annoyance for me is moving back an entry, which normally requires that I add a {{d}} to the redirect, wait patiently for and admin to delete it, and then move the entry back. If I could use the undo button in some of those cases, that would be really helpful. --Victar (talk) 22:31, 27 November 2018 (UTC)

PollEdit

Indicate whether you support or oppose having the "page mover" right described above turned on for en.Wiktionary, tentatively to be granted to users through the same procedure as "rollbacker" rights.

  1.   Support. - -sche (discuss) 19:31, 27 November 2018 (UTC)
  2.   Support. —Μετάknowledgediscuss/deeds 20:14, 27 November 2018 (UTC)
  3.   Support Per utramque cavernam 22:07, 27 November 2018 (UTC)
  4.   Support --Victar (talk) 22:31, 27 November 2018 (UTC)
  5.   Support.  --Lambiam 05:39, 28 November 2018 (UTC)
  6.   Support. — SGconlaw (talk) 06:35, 28 November 2018 (UTC)
  7.   SupportEru·tuon 06:44, 28 November 2018 (UTC)
  8.   Abstain, because I'm ambivalent, but I certainly don't oppose. Andrew Sheedy (talk) 02:59, 30 November 2018 (UTC)

AlphagramsEdit

I have been adding alphagrams to anagram sections (for example antiscreening). This means it is possible to search for "alphagram XYZ" and get all anagrams of XYZ even if XYZ isn't a word. If this isn't wanted the display can be turned off in Module:anagrams. DTLHS (talk) 02:03, 27 November 2018 (UTC)

Oh, so that's what those are for. — SGconlaw (talk) 11:15, 27 November 2018 (UTC)

Thai ว่า and ที่ both meaning that and what belongs in See also sectionsEdit

I'm currently learning Thai, mainly online. I don't have a teacher or a reference grammar.

I've discovered that ว่า and ที่ both mean that and are used in some kinds of relative/subordinate clause equivalent. But I have not yet understood them and their differences at any depth.

From what I have been able to figure out ว่า is used for "He said that ...", "It seems that ..."; and ที่ is for "The thing that did X", "The thing which did Y".

I regard those functions is similar in English, which is why the same word can be used for both situations. Of course "which" cannot be used for the "said", "seems" situations though.

When I come across pairs of words like this in any language where the usage crosses over to any degree in English I have always linked them in the "See also" section. This is the section for connecting words that are not derived from or etymologically related to each other but have some semantic or usage overlap of any kind. And to me, not necessarily in the native language, but an overlap in their translations to English has been sufficient.

I recently linked these two via see also and those have been reverted.

I've posted an "attention" in the relevant sense of each Thai word asking for usage examples. Only one of the words appeared in any translation table at "that" so I added the other in the section that looked appropriate to me and also added an "attention" template so somebody more knowledgeable can check it.

Firstly, I'd like to first ask any contributors who know Thai if they can explain the differences between these two words, assuming my rough attempt above is not sufficient.

Secondly, I'd like to ask all contributors if they think there is or is not sufficient semantic or usage overlap to warrant these two words for "that" to refer to each other in a "See also" section. Thought on why or why not greatly appreciated.

Links to grammar references are also greatly appreciated. Thanks in advance. — hippietrail (talk) 02:28, 28 November 2018 (UTC)

I added some examples on both.
ที่ tîi is “which, that”, a relative pronoun used to refer to people, places and things, restricting the noun in front. It can also be used to mean “that which, the one that, the ones that, ...” in a way similar to สิ่ง sìng, and thus function as a nominaliser. Verbs of emotion (‘sorry, happy, angry’, etc.) can also be followed by tîi.
ว่า wâa typically follows a verb and is similar to “that” in English, although it is less droppable in Thai. It can only follow certain verbs, e.g. verbs of utterance (‘say, whisper, call’, etc.), mental activity (‘think, remember, hope’, etc.) and perception (‘see, understand, know’, etc.).
Wyang (talk) 04:31, 28 November 2018 (UTC)
Thanks! It so happens that I now live walking distance from a university library. I visited this afternoon and they had three Thai reference grammars. One referred to these two words as "complementizers" and another had a little section specifically about how they differ. This reinforced my opinion that they should be cross-linked via "See also". It turns out there is another word which is a compound of these two: ที่ว่า, another term for "that". — hippietrail (talk) 07:24, 28 November 2018 (UTC)
There's also ว่าที่ (wâa-tîi) (meaning is different). :) Wyang (talk) 07:38, 28 November 2018 (UTC)
Haha yeah I found that one too but it seems to be outside the current scope... but why not request an entry anyway? (-: — hippietrail (talk) 08:26, 28 November 2018 (UTC)

December 2018

References for Vietnamese readings listed under Template:vi-readingsEdit

I would like to add superscript references for readings of Vietnamese Han characters using the following code as a suggestion:

{{vi-readings|rs=老04
| hanviet = giả - tdcn
| nom = giả - tdcn;gdhn, giã - tdcn, rả - tdcn, trả - gdhn;btcn, dã - gdhn
}}

The abbreviations used are: tdcn = {{vi-ref|Nguyen (2014).}} gdhn = {{vi-ref|Trần (2004).}} btcn = {{vi-ref|Hồ (1976).}}

The desired output using as an example is as follows:

Han characterEdit

: Hán Việt readings: giả[1]
: Nôm readings: giả[1][2], giã[1], giở[1], rả[1], trả[2][3], [2]

ReferencesEdit

Currently, this is also achievable using the bulkier code below:

{{vi-readings|rs=老04
| hanviet = [[giả#Vietnamese|giả]]<ref name="tdcn">{{vi-ref|Nguyen (2014).}}</ref>
| nom = [[giả#Vietnamese|giả]]<ref name="tdcn"/><ref name="gdhn">{{vi-ref|Trần (2004).}}</ref>, [[giã#Vietnamese|giã]]<ref name="tdcn"/>, [[giở#Vietnamese|giở]]<ref name="tdcn"/>, [[rả#Vietnamese|rả]]<ref name="tdcn"/>, [[trả#Vietnamese|trả]]<ref name="gdhn"/><ref name="btcn">{{vi-ref|Hồ (1976).}}</ref>, [[dã#Vietnamese|dã]]<ref name="gdhn"/>
}}

If possible, could someone edit Module:vi so that the suggested code in the first paragraph would give the desired output? KevinUp (talk) 15:49, 1 December 2018 (UTC)

@Suzukaze-c Hi. If you have the time, would you mind comparing the desired output above with 者#Vietnamese? I can't figure out how to implement this within the module. KevinUp (talk) 06:50, 7 December 2018 (UTC)

unchanged pluralEdit

What does "unchanged plural" exactly mean in the Usage note for craft? that's not the general terminology used in Wkt, is it? --Backinstadiums (talk) 16:38, 2 December 2018 (UTC)

I've changed it to be explicit: "The plural craft is used to refer to vehicles. All other senses use the plural crafts." Ultimateria (talk) 19:12, 2 December 2018 (UTC)

Inevitable discussion about reference works from non-Latin culturesEdit

Given the situation where issue |lang= in {{quote-web}} in the Grease-pit page of this month insinuates opening all reference templates it has become opportune to uniformize their content. It has caught my eye that there are lurking multiple fashions of displaying references for cases of a work published in a script that is not the one of the Romans, namely, the author name was written in a certain script and the title of course too, but to my great surprise and contrary to Wiktionary’s usual laudable Unicode- and internet-standard compliance I encountered that there were reference templates here already created that did not even include the original title but wrapped it in {{xlit}} so that only a transliteration of it remained, and the same has also been done with titles of their authors, so that I could not recognize any of the books and almost did not find already created templates by Wiktionary’s search function, being already prepared – in vain – to create the templates.

So I reasoned that, since we are in late 2018 and our letter case is unlimited in what concerns languages that have in the Modern Age been used for pursuing science, the templates must all be uniformized so that the original title is displayed, opining also that transliterations are to be discarded for scripts that are unambiguous since they are no gain for anyone (if you don’t know the language you don’t know the transcription either, short of negligible cases when one is literate in Latin script only but not the actual script for a non-Latin-script-written language one knows) and “En.Wiktionary entries already have too much wasted space”, as @-sche acutely observed on the Grease pit page of this month and also has been voiced as a cause of displeasure.

There might be little experience in reference sections in any works containing non-Latin references, but naively and naturally and looking at how my computer does it, I always ordered references by the Latin names first and then the Cyrillic ones, and so I have come to the belief that the original-script author names can be had easily. People might however be more appealed to by Latin-transliterated names, but even then I am apprehensive of those being less iconic, but this is of limited importance for names. It can very well be grave in logographic writing systems some of which are still in use, for particularly people’s names can have the most arbitrary characters and it would be utterly impossible to reconstruct the original name without browsing the web again only to find a name which a Wiktionary editor has needlessly left out. Currently the Japanese reference templates have all formats.

So how does Wiktionary look upon all these factoids? What should references have, perhaps with distinctions by writing systems? I’d like to see completely removed the transcriptions of the titles of alphabetic and syllabaric scripts because they have no non-theoretical uses and would sort references by Unicode (I don’t actually know how Chinese sort their Chinese reference sections, and perhaps one feels that Japanese titles transliterated could somehow help, I avoid talking about those scripts). Plus why have people even thought that |title= and the author parameters would be the correct place to put transliterations or transcriptions? This would easily be different parameters |tr-title=, |tr-author= and so on that can be expanded for those who need it (whose existence I deny), and this would make reference templates use more expected parameters. Which of course entails as a minimum that we have original-script titles – come on, are readers supposed to reverse-transliterate titles? Author titles perhaps in both since one might not know the script but the author from other publications in other, Latin-written languages? But this is not generally true, though there are often adapted author names around. Avicenna is quite iconic, no need for اِبْن سِينَا (ibn sīnā), but that’s more often for classics and applicable to quotation templates. What does iconicity tell us here? And I have not even mentioned how often title-translations should be done, which have a parameter already. There is still this issue around of quotation templates containing bare long titles, and there are a few “click to expand” solutions for these as I remember. Pinging some people I find interesting to hear or interested: @Sarri.greek, Eirikr, Sgconlaw, Dan Polansky. Fay Freak (talk) 00:29, 5 December 2018 (UTC)

I’m sorry, could you summarize all that? I’m having trouble understanding what your concerns are. — SGconlaw (talk) 01:51, 5 December 2018 (UTC)
@Sgconlaw I wanted to uniformize references of books written in a non-Latin alphabet a bit, pointing out the questions whether the original script of a) the author name b) the title should be shown, and c) whether transliterations of the author names should be shown d) whether transliterations of the titles should be shown. I was just formulating much pros and contras. My result has been to vehemently affirm b), deny d) (hardly valuable clutter), lean to a), I am rather open to c), but it would need to look good enough (like on the Chinese reference page KevinUp has linked it is great but we need |tr-author= for this I think). Fay Freak (talk) 19:35, 5 December 2018 (UTC)
I say show both the original and the transliteration, in the future we will be able to customize this to everyone's satisfaction with css magic. Crom daba (talk) 03:42, 5 December 2018 (UTC)
Yes, and at the least transliteration does not belong to |title=, otherwise there won’t be CSS magic. There need to be separate fields for original titles and author names and their transliterations, I don’t think I can be wrong here, @Sgconlaw. Now supra there are the arguments for displaying. The decision about display should not be influenced by limited forms of saving the information. Fay Freak (talk) 19:35, 5 December 2018 (UTC)
Here are the formats used for Chinese references: Wiktionary:About Chinese/references, Korean references: Wiktionary:About Korean/references and Vietnamese references: Wiktionary:About Vietnamese/references. Also, all Chinese quotations and usage examples (whether it is cited from a book, song, video or the web) are provided using Template:zh-x. A list of abbreviations for well known references used by this template can also be found at Module:zh-usex/data. KevinUp (talk) 04:08, 5 December 2018 (UTC)
@KevinUp The Chinese reference page is great. Until the point where I find: “Starostin, Sergei (1989). Rekonstrukcija drevnekitajskoj fonologicheskoj sistemy (A Reconstruction of the Phonological System of Old Chinese)”. Why is the Russian title not given in Russian script but the Chinese titles are given in Chinese script only (and not in Pinyin)? No logics.
There is also the issue of some titles being translated and some not, but that’s minor. Fay Freak (talk) 19:35, 5 December 2018 (UTC)
@Fay Freak: I'm not sure why the work by Sergei Starostin was not written in the Cyrillic script. I tried to trace the source of that work, and this is what I managed to find: [3]. Unfortunately I was unable to trace the original source. Perhaps someone else could help by looking up the bibliography of Sergei Starostin.
 

Phonological reconstructions for Early Zhou, Classical, and Middle Chinese are based on Sergei Starostin's version as originally published in: [Starostin, Sergei. Rekonstrukcija drevnekitajskoj fonologicheskoj sistemy [Reconstruction of the Phonological System of Old Chinese]. Moscow, 1989.] Particular reconstructions are transliterated into the UTS from S. Starostin's etymological database of Chinese characters (bigchina.dbf), available online at http://starling.rinet.ru.

 
As to why Chinese titles are given in Chinese script only and not in Pinyin, this may have been done to prevent a cluttered appearance of the reference works. Also, it seems that pinyin tone marks are omitted for Chinese reference works in Yale University Library's Quick Guide on Citation Style for Chinese, Japanese and Korean Sources: APA Examples. KevinUp (talk) 16:32, 6 December 2018 (UTC)

Adding pinyin for numbers in Chinese (Mandarin?) example sentencesEdit

@Dokurrat, KevinUp, Justinrleung, Suzukaze-c, Tooironic, Wyang & co. (alphabetically organized) I added Pinyin for the numbers in a Mandarin Chinese example sentence, and that pinyin was removed- see [4]. I think we should give the pinyin for the numbers (maybe?). I'm okay either way- in fact I don't think we need to do all sentences one way (no pinyin for numbers in example sentences) or all the other way (pinyin for all numbers in example sentences). But I'm not sure. idk. I'm just putting it out there for y'all to discuss. Any which way is fine to me. --Geographyinitiative (talk) 04:30, 5 December 2018 (UTC)

No, I don't think we should add pinyin for Arabic numerals. Dokurrat (talk) 04:41, 5 December 2018 (UTC)
I like the idea. I usually do it for Japanese. —Suzukaze-c 04:42, 5 December 2018 (UTC)
I'd like to see the numbers as pinyin, because they are read according to its Mandarin pronunciation. Also, depending on context, they can be read as cardinal numbers or standalone digits:
365  ―  sānbǎiliùshíwǔ tiān  ―  Three hundred and sixty five days.
員工365失踪 / 员工365失踪  ―  Yuángōng sānliùwǔ shīzōng le.  ―  Employee no. 365 is missing.
KevinUp (talk) 05:04, 5 December 2018 (UTC)
^ this. —Suzukaze-c 05:18, 5 December 2018 (UTC)
Agreed that we should add pinyin conversion for Arabic numerals. ---> Tooironic (talk) 06:09, 8 December 2018 (UTC)
It has to be added manually, of course, otherwise we are asking for possible future errors in conversion. Perhaps re-transliterated numbers need to be displayed differently, so that e.g. sānbǎiliùshíwǔ for "365" is known to mean to stand for 三百六十五 (sānbǎiliùshíwǔ, “three hundred sixty five”) or 三六五 (sānliùwǔ, “three six five”). A different colour or underlined? Also, maybe a trick is needed to use a hidden "三百六十五"/"三六五" but display "365", so that a manual pinyin is not required? BTW, @KevinUp: I have suppressed the display of "365" in your example with @. --Anatoli T. (обсудить/вклад) 07:15, 8 December 2018 (UTC)
@Atitarev: Automatic pinyin transliteration of Arabic numerals can be done by adding pronunciation data of 0-9 to data.polysyllable_pron_correction in Module:zh-usex/data. However, this would render "365" as 三六五 (sānliùwǔ, “three six five”). Manual input would still be needed if "365" is intended to be read as 三百六十五 (sānbǎiliùshíwǔ, “three hundred sixty five”). KevinUp (talk) 14:45, 8 December 2018 (UTC)
@KevinUp: I understand. As I said, what we need is, a new method in the module to use the transliteration of hidden characters, in this case "三百六十五" for transliteration purposes only - "sānbǎiliùshíwǔ" but display unlinked "365" in the Chinese text. --Anatoli T. (обсудить/вклад) 04:16, 9 December 2018 (UTC)
This seems to be slightly complex, so we may have to add this to Wiktionary:About Chinese/tasks. KevinUp (talk) 04:25, 9 December 2018 (UTC)

Wiktionary lemmas written in a nonnative scriptEdit

As Wiktionary grows, I noticed some unusual entries written in a nonnative script such as 0.5#Chinese, の#Chinese that qualify for Wiktionary:Criteria for inclusion and may have also passed Wiktionary:Requests_for_verification due to its widespread used in a particular language or region. However, I think that it might be better to list such entries (that have passed RFV) in an appendix or separate namespace or to put a banner right below the language header to inform our readers that this lemma is written in a nonnative script along with categorization. KevinUp (talk) 15:14, 5 December 2018 (UTC)

Out of curiosity, do we have Arabic, Greek, Hebrew, Hindi, Russian lemmas that are written in the Latin script, for example? I've also found Category:Terms written in foreign scripts by language, but only Chinese, Japanese and Korean are listed in this category. KevinUp (talk) 15:24, 5 December 2018 (UTC)
Category:Chinese terms written in foreign scripts DTLHS (talk) 15:26, 5 December 2018 (UTC)
These entries are rather interesting: fighting#Chinese, friend#Chinese, part-time#Chinese. Yes, I've heard these terms used in real life, such as in TVB dramas, but I am surprised to see these entries included in Wiktionary. I would like to propose for such terms to be listed in an appendix or separate namespace, because such entries are more likely to be found in an informal dictionary such as an A-Z pocket slang dictionary, rather than a formal dictionary. KevinUp (talk) 15:55, 5 December 2018 (UTC)
The issue has come up before, with marketing being used (in Latin script) in Greek texts. Wiktionary:Beer parlour/2017/September § Modern Greek terms spelt with Latin characters. See also this revision history for a recent disagreement. I'm not comfortable at all with including that sort of things. Per utramque cavernam 16:15, 5 December 2018 (UTC)
Foreign script is a strong argument for code-switching. Even when it is used constantly in Greek it can be the case that it never passes into Greek, and it is no loss not to add it either because the English entry suffices (you read a Greek text, look up a word here but find it as English, that’s enough, you don’t expect anyway that all that you read is in the dictionary as Greek). Fay Freak (talk) 19:39, 5 December 2018 (UTC)
Script is secondary to the actual spoken language, and usage of words should be analyzed for codeswitching, and for what-language lexicon a word belongs to. French has fr:American way of life#Français and fr:web design#Français, and Japanese has サード (sādo, third) and ホエールウォッチング (hoēru wotchingu, whale watching); are these "acceptable"? —Suzukaze-c 19:42, 5 December 2018 (UTC)
Maybe we need to find a way to represent code-switching? It would seem like a common pattern for a foreign word to have a code-switched variant (with foreign pronunciation, in a foreign script) and a nativized one (being closer to the native language's phonology, spelled in the language's native script) with the first one being extremely common and the second at the edge of attestability, but due to our policies we only include the second one and create a distorted picture of actual usage patterns.
I remember @Vahagn Petrosyan having something to say about this. Crom daba (talk) 20:06, 5 December 2018 (UTC)
I create a Usage note, as in վարագույր (varaguyr). --Vahag (talk) 12:18, 6 December 2018 (UTC)
Yes, I think that we need to find a way to represent code-switching. Rather than using foreign script as an argument for code-switching it might be better to decide based on the pronunciation of the entry.
I would like to suggest for entries such as (1) part-time#Chinese, (2) PK#Chinese, (3) SUS#Japanese that have been nativized to become closer to the phonology of the language it was borrowed into (despite retaining its nonnative script) to be accepted as legit entries whereas entries such as (1) fighting#Chinese, (2) fr:American way of life#Français, (3) の#Chinese that are found mostly in written form but rarely in spoken conversations are to be put under some sort of banner to inform our readers that such entries are of unconventional usage and are mostly written for stylistic effect. KevinUp (talk) 16:32, 6 December 2018 (UTC)
Alternatively, we should set up some sort of guideline to decide whether or not an entry is considered code-switching or not. KevinUp (talk) 06:50, 7 December 2018 (UTC)
Yes, language-specific CFI are needed. --Anatoli T. (обсудить/вклад) 07:17, 8 December 2018 (UTC)
I think that the issue of the script is a bit of a red herring. Take the originally English word online, which has become commonplace in many languages, including Serbian. Now when Danas, a major newspaper, uses the word, they write for example ”Srbi sve više kupuju online. The Politika newspaper is also written in Serbian but uses Cyrillic script; when they use the word, they write for example “Политика Online, as they in fact do on every page of their website. It would be strange to consider the use by Danas a loan word but the use by Politika a case of code switching, merely because one happens to use Roman script and the other Cyrillic for what is the same language.  --Lambiam 17:30, 8 December 2018 (UTC)
In this particular case, the spelling is a strong indicator of code-switching, as Serbian orthography is phonemic and (unlike Croatian) strongly prefers transcribing foreign names and terms. You could consider onlajn (abundantly attested) a nativized variant, although arguably the choice between these spellings is a matter of personal style. Crom daba (talk) 18:00, 10 December 2018 (UTC)

For an example in English, Москва is citeable (Citations:Москва) but was deleted (Talk:Москва), and Citations:ἄρχων is also citeable (as are, I expect, Arabic-script forms of Allah and PBUH, etc). An older Chinese example is Talk:Thames河, deleted in 2011.) - -sche (discuss) 17:54, 8 December 2018 (UTC)

When I read, “With absolute confidence I can boast that my Frittelle di Fiori di Zucca are the best in the world”, I don’t think, “Oh, perhaps we should consider including an entry for the English term frittella di fiori di zucca. No, I think this is an instance of code switching, and in this case one of a very common type. I think we should not have an English entry oliebol either. Although the term can be found in English texts, it is obviously a Dutch word. There is a need for a test or criterium when the use of a foreign term is simply code switching, and when the term becomes part of the lexicon of a borrowing language. As I’ve tried to argue above, being written in a different script is not a litmus test. Being included in quotation marks is a strong indicator of not being seen as part of the lexicon, but not all authors will use these when code switching. When the imported term becomes subject to local inflection, or can serve as a component to form new compound words, this is a strong indicator of having become lexicalized, but as a test this does not work for analytic languages like Mandarin.  --Lambiam 12:33, 9 December 2018 (UTC)
In personal experience, code switched fragments can very easily be inflected and are likely to be joined in compounds to attach them to native sentence structure. Also, lexicalized loans are likely to have defective inflection.
Pronunciation is also no good, since it is extremely speaker and context dependent, and lexicalized loans can themselves have a special phonology.Crom daba (talk) 18:07, 10 December 2018 (UTC)
I don't think we can have a coherent policy or test across different languages. Speakers of different languages will absolutely differ in their criteria for what counts as a native word. This is even more difficult with global languages like English where different communities are in contact with a huge variety of other languages from which to borrow from. DTLHS (talk) 18:23, 10 December 2018 (UTC)
  Good words, @Crom daba. I want to point out how language is really written on the internet: In printed works or works inspired by print practices there are many things that don’t happen but are unproblematic elsewhere, in unrestrained speech where people can develop their own standards or own morals, unspooked by societal expectation, so to speak in Stirnerian language: Remarkably, nowadays in Russian chats, and I mean those where discussions take place and people try to write correctly, one just writes some foreign words in foreign script and then immediately joins Russian endings in Cyrillic script to them. It’s also the way I think and do it: Writing Russian in Germany, referring to things in Germany without having a notion of a Russian equivalent, I just write German words or English words in Latin script and decline them Russian and in Cyrillic script (without space I mean, you understand; most iconic, I think), and this does not make them Russian. I often can think “Is this word Russian already”? There are some obvious ones that do exist, like everyone uses the word терми́н (termín) in reference to appointments in Germany, a word that does not exist in Russia, and I long did not even know that it doesn’t, it seems so indispensable. This middle ground of dubiosa (is this English or Latin, huh? Not English because of lacking spread) is only left out by me and other dictionary editors often because these words have limited relevance to a greater world and one would look up these words in German dictionaries anyway (as I said earlier, an entry in one language suffices, a Greek entry marketing (marketing) is otiose), plus they are CFI-problematic (best one can do is quote them from fora and commentaries under articles, perhaps with archive links, but that’s it, these Soviets here don’t produce a corpus that would help to quote Russian as spoken in Germany). Separating the words is even more difficult if you look at inter-Slavic conversations: Like is Russian менто́вка (mentóvka, mint liquor as popular in Bulgaria) Russian? It is used in Russian texts here and there, and obviously with Russian endings then, but is it perceived as Russian? (With a German legalese term with no equivalent in English, how does the Verkehrsanschauung or Verkehrsansicht see it?) I have also read quite a lot strange words from Russian expats in Serbia and things like that, you could make large lists of such words if you wanted to; theoretically this could lead to having words in Russian written with Cyrillic characters we thought do not exist in Russian – I make here the strange observation that Latin words with foreign diacritics pass easier into texts of other languages but the Cyrillic languages tend more to transcribe all, i. e. having a Russian text with ђ is way more weird than Vietnamese diacritics, Semitic transcriptions and what you can imagine in English texts. And that’s only in Europe, elsewhere things become crazier, which others can describe better.
For the phonetical point, see that legit French words contain pharyngeal fricatives, like hebs (prison, can), hnouch (popo, bacon). Here we have also an issue arising if we know that a word has passed into French, English, and you can attest it from songs (like they have been printed on CD or are buyable as downloads or else unlikely to vanish, so durable). The flip side of words written in a non-native script are words which have passed but cannot or only with uncertainty be written in the native script. English example: gwop (moolah).
Normal dictionaries to a large part avoid such problems because they leave out exotisms, i. e. words for things that do not exist in an area where there is a community of the language documented. With this I lean towards an exclusion ground that is that if a word in English is for a foreign thing and the Verkehrsanschauung does not see the word as English then it is not English. Confer mesdemet! This is “not really English”. What does apply for abstracta then, what is Greek marketing then? This criterion I have just stated becomes difficult for foreign “ways of life”. Maybe Greek marketing is not actually Greek because he who uses such a word ceases to think like a Greek, regardless of the script it is written in. There are many gross things written and said in Arabic or Hindi texts that I would for this reason see as not-Arabic and not-Hindi. And the same criterion can apply to determine if a word has passed from German into Russian.
The issue gets complicated however because there is not only code-switching for Wiktionary but there is also Translingual: You could make a case for “marketing” being Translingual and not only English. I have argued already (User talk:Fay Freak § Translingual) for grammatical terms like genitivus absolutus, status constructus and the like being Translingual in the first place. Maybe “marketing” is translingual because teachers of business and marketing have made it so ex cathedra, which is why it is used in Greek, never able to become Greek. Fay Freak (talk) 20:02, 10 December 2018 (UTC)
Agree. Crom daba (talk) 23:18, 10 December 2018 (UTC)

Linking elements of a term in {{en-noun}}Edit

At l'esprit de l'escalier, should the individual elements of the phrase in {{en-noun}} be linked to French words, like this: {{en-noun|head=[[l'#French|l']][[esprit#French|esprit]] [[de#French|de]] [[l'#French|l']][[escalier#French|escalier]]}}? (Pinging @Per utramque cavernam as we discussed this on the entry talk page.) — SGconlaw (talk) 17:11, 5 December 2018 (UTC)

No. They should be linked in the etymology. DTLHS (talk) 17:13, 5 December 2018 (UTC)
In the case at hand, the link is to an entire French term, esprit de l'escalier. Where should the individual elements be linked, or do we just not link them in this case? I was thinking that since the elements of a term in {{en-noun}} are usually linked by the template anyway, it makes sense to include the links to the French words manually. — SGconlaw (talk) 17:20, 5 December 2018 (UTC)
Those links are one click away. Theoretically it can be different if a French phrase exists only in English or an other language, the French not being CFI-compliant as French. Fay Freak (talk) 19:43, 5 December 2018 (UTC)
I usually link to component multi-word terms of a term if they reflect the sense of that term, eg, black sugar maple would link to black and sugar maple. And, as Fay Freak says, the individual words are just one more click away. It seems unhelpful to make a user guess at whether there are multiword components and which grouping leads to a possible entry. DCDuring (talk) 23:08, 5 December 2018 (UTC)
The {{en-noun}} template links to English terms, though. In this case, the terms are French, so it's not appropriate to link. —Rua (mew) 10:45, 6 December 2018 (UTC)
Generally, yes, but arguably not exclusively. For example, sometimes when an element is not present in the Wiktionary (for example, a person's name), I've seen a link to an English Wikipedia article. I see no reason why links can't be to other languages where appropriate. — SGconlaw (talk) 12:01, 6 December 2018 (UTC)
Because, again, {{en-noun}} creates English links. If you put a French word in there, it will still be an English link. A dead link, moreover. —Rua (mew) 18:43, 10 December 2018 (UTC)

New sinograph QIOU "poor and ugly"Edit

How should this situation be dealt with in terms of lexicography?

 
poor and ugly
--Backinstadiums (talk) 00:26, 6 December 2018 (UTC)
The same way we deal with any other word or sinograph — add it if it is attested in durably archived media, spanning over a year, etc. (It doesn't look like this is.) —Μετάknowledgediscuss/deeds 02:01, 6 December 2018 (UTC)

quadrumanusEdit

quadrumanus appears in the Cambridge Grammar of the English Language, page 1663; is it a typo or a variant of quadrumanous --Backinstadiums (talk) 15:58, 6 December 2018 (UTC)

(This sounds like a Wiktionary:Tea room question. — SGconlaw (talk) 16:02, 6 December 2018 (UTC))
It is a taxonomic designation (as in Chiropsalmus quadrumanus). Highly unlikely to be an English adjective because of the spelling. Equinox 16:40, 6 December 2018 (UTC)
The authors were probably looking for a word that began with quadru and was not formed in Latin, as they are talking about "marginal vowels" as English morphological elements, which in the case of 'quadr' can be i, a, or u. Why they didn't choose quadrumane or quadrumanous for the purpose is beyond me. We could ask them. Maybe it is was typo. DCDuring (talk) 18:16, 6 December 2018 (UTC)

New Wikimedia password policy and requirementsEdit

CKoerner (WMF) (talk) 20:02, 6 December 2018 (UTC)

Programming languagesEdit

Since the Wiktionary includes all languages; Does it also include Programming languages? --2A01:112F:742:C00:14B9:E7A5:D1B3:F0B3 09:23, 8 December 2018 (UTC)

No, as they aren't human language (though a few words may rarely get borrowed into English grammar). Equinox 10:23, 8 December 2018 (UTC)
Is tlhIngan Hol a human language?  --Lambiam 19:26, 8 December 2018 (UTC)
Eh, it's clearly a totally different kind of thing from a programming language. The only programming language I've ever seen that even inflects verbs is Inform 7. Equinox 19:34, 8 December 2018 (UTC)
Programming languages are determined by a language specification, not by usage. That falls under "documentation", not lexicography. DTLHS (talk) 17:31, 8 December 2018 (UTC)
But the reference manuals for a programming language use terms from that language as if they were English, French etc - so we really ought to have them somehow. SemperBlotto (talk) 14:23, 10 December 2018 (UTC)
We've had this discussion before. Early programming languages only had a few keywords, but now there are hundreds of frameworks with thousands of named classes (e.g. ExecutionEngineException, HttpMessageInvoker) and each class may have hundreds of named properties, methods and fields. These, too, are listed in manuals and guides. Equinox 14:30, 10 December 2018 (UTC)
See Wiktionary:Requests_for_verification/English#caddr as well. - TheDaveRoss 14:31, 10 December 2018 (UTC)
Take this sentence from a book on conversational French: Bonjour is usually used until around six p.m., whereas bonsoir is used after six p.m.” In a book on French you can expect to find French words used as nouns in English sentences. Only, they are not used with their French meaning. They stand for themselves. So these sentences mention the word in the sense of the use–mention distinction. Likewise, the English sentence esac is case spelled backward, rather like fi is if spelled backward” only mentions these keywords. To understand the sentence you don’t have to know the meaning of any of these words. On the other hand, grep, originally just another computer command, can be used as a verb (”I grep, he greps, we grepped”), so it clearly has become lexicalized and merits to be included.  --Lambiam 18:12, 10 December 2018 (UTC)

Appendix:Reference detailEdit

According to the description: "This appendix provides detail to sources linked by Wiktionary. It is to be linked from reference templates." It contains three items, all created by User:Dan Polansky. Is this a new policy? The only reason I've noticed it is that Dan changed one of the Hungarian reference templates. I'd prefer to link directly from the template to its corresponding website and not to an appendix. Was there a Beer parlour discussion or vote on this? Panda10 (talk) 15:25, 9 December 2018 (UTC)

It is not a new policy, not anything mandatory and rigid. If you don't like my change in Template:R:TotfalusiEty 2005, please revert it. The point of the appendix is to provide more information than comfortably fits in the mainspace, e.g. English rendering of the title. Some reference templates link to Wikipedia, which is similar in that it does not lead to the main website of the reference. --Dan Polansky (talk) 15:31, 9 December 2018 (UTC)
Dan, thanks for your prompt reply. I do see your point, but for now, if you don't mind, I will revert the changes until it is decided by the community how to standardize reference templates. Panda10 (talk) 16:46, 9 December 2018 (UTC)
@Dan Polansky: I see too what you want. Actually instead of listing references in Appendices a technical solution that I consider agreeable is to have the transliterations, transcriptions and translations present in the templates but not shown without clicking to collapse – no? @Panda10: On this page, section 3 is actually about standardizing the information given by reference templates but the community does nothing, you could weigh in too. Fay Freak (talk) 20:21, 10 December 2018 (UTC)

Interesting BBC articlesEdit

An interesting BBC article on an analysis of Twitter that traces the geographic rise and spread of neologisms in American English: Feeling litt? The five hotspots driving English forward (4 May 2018). -Stelio (talk) 08:26, 12 December 2018 (UTC)

Another one on anti-languages: The secret “anti-languages” you’re not supposed to know (12 Feb 2016).

- Stelio (talk) 13:28, 12 December 2018 (UTC)

English words with contraction-'s, etcEdit

A recent RFD got me thinking: by vote, we don't allow entries for words with possessive-'s, with only a few exceptions. Do we have any policy on which contractions are allowed? I've created some more interesting ones myself (double and triple contractions), but...it seems like contraction-'s can be added to as many words as possessive-'s. Just googling the first few words from various parts of speech that pop into my head, I can find citations of all of them: not just nouns like cat's but difficult's (see google books:"difficult's an", etc), write's (google books:"If any line I write's a nobbler", etc), wow's (google books:"wow's an"), see also google books:dogs're. I presume we don't want entries for all of these! (The small set of ones attached to pronouns (he's, y'all'd've, etc) are worth keeping, IMO.) - -sche (discuss) 18:00, 12 December 2018 (UTC)