Wiktionary:Beer parlour

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:Beer Parlour)
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Beer parlour

Lautrec a corner in a dance hall 1892.jpg

Welcome 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 aspects of Wiktionary—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list below (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 and consider before posting here whether one of our other discussion rooms may be a more appropriate venue for your questions or concerns.

Sometimes discussions started here are moved to other pages for further development. In particular, changes to a major policy or guideline may be discussed on the corresponding talk page and “simple votes” (as opposed to drawn-out discussions) can be conducted on our votes page.

Questions and answers typically remain visible on this page for one to two months, but they can always be found in the appropriate monthly archive (based on the date discussion was initiated). While we make a point to preserve all discussions that were started here, talk that is clearly not appropriate for this page may be deleted. Enjoy the Beer parlour!

Beer parlour archives edit

December 2020

Linking to specific meaning item within a Definition[edit]

I have in the past set an anchor e.g., {{anchor|ExampleMeaning}} and linked to it using [[ExampleDefinition#ExampleMeaning|LinkedWordInMyWikqArticle]] but I don't know if such changes are accepted within the Wiktionary Commuity as Kosher. Will such anchors set in Wiktionary articles be deleted by rigorous editors? Is there an alternative preferred method of linking to a specific meaning within the general definition from another wiki page, e.g., a Wikiquote article? I generally link to the specific part of speech, but would like the capability of narrowing down to the specific meaning which applies to the word I am linking from. Is this a valid programming or community issue? Currently, it seems that the meanings are floating, i.e., the order of the meanings can be changed by an editor, so the anchors, if retained with the specific definition, will also float with that specific meaning.

ELApro (talk) 22:00, 1 December 2020 (UTC)
A current practice is to add {{senseid}} in front of the definition and then use the |id= parameter of various templates to link to it, e.g. {{l|en|fragment|id=internet}} => fragment. – Jberkel 22:26, 1 December 2020 (UTC)
Doesn't that template only apply within Wiktionary? How could it be applied for an external link from within a Wikiquote article?–ELApro (talk) 17:44, 7 December 2020 (UTC)
Yes, it's designed to be used within Wiktionary, but you could build templates in other Wikis to generate the links, in the format used by {{senseid}} (#Language-ID). – Jberkel 17:57, 7 December 2020 (UTC)
Sure, but having a template is good practice to avoid hardcoding the specific fragment format. In theory, the links created by {{senseid}} could change. If it's just for one-off linking there's no point creating a template of course. – Jberkel 18:34, 7 December 2020 (UTC)
Thanks. That will work great for existing senseID tags, but if I need to create one, is there a "List" of "standard" senseid category identifiers that I can reference, so I'm not adding a senseID that will need to be replaced?-ELApro (talk) 23:33, 7 December 2020 (UTC)
No, it's freeform. If there's already a (unique) label attached to the sense I often use that (in the example above (“internet“). You can also use Wikidata ids (QXXX…), for the fragment this would be fragment identifier (Q1440450). – Jberkel 00:02, 8 December 2020 (UTC)
I would add that there's no reason to avoid duplication as long as you aren't duplicating a sense ID on the same page. Even then, the worst thing that could happen is you link to the wrong place on the correct page. Chuck Entz (talk) 04:16, 8 December 2020 (UTC)

What do "Template:rfdef" mean?[edit]

What do the letters of "{{rfdef}}" template mean? I'm curious. And which is the template similar to requested etymology? --Vivaelcelta (talk) 00:41, 2 December 2020 (UTC)

{{rfdef}}: request for definition, as I've understood it anyway. Along similar lines, request for etymology == {{rfe}}. ‑‑ Eiríkr Útlendi │Tala við mig 01:13, 2 December 2020 (UTC)
@Vivaelcelta: Also, please note that WT:Information desk is the better place for such questions. The Beer parlour is for discussions about policy and the like. Andrew Sheedy (talk) 05:10, 2 December 2020 (UTC)
@Andrew Sheedy: Thank you. --Vivaelcelta (talk) 00:01, 4 December 2020 (UTC)

Derived terms templates[edit]

There seem to be two competing and visually incompatible sets of templates for the derived terms section in common use. One set is template:der-top and template:der-bottom which hides everything under a banner with a "hide/show" toggle on the right. (See for example steigen#Derived terms.) Another is template:der3 (really just a redirect to template:col3) which hides all but 9 of the entries with a "show more/less" toggle at the bottom. (See for example sprechen#Derived terms.) I personally prefer the top/bottom style because it looks neater (imo), there's usually no need to view this list at all when you're looking up a word, and when you do need to view the list having just nine visible doesn't help much. On the other hand with der3 template you can just put the language code at the top and not have to have a separate label template for each entry. Another issue is that der3 automatically sorts the entries, and I can see the advantages of that but I can also imagine there might be circumstances where you might want to have the entries in a customized order. So is one of these formats preferred over the other? I'd like to know so that going forward if I end up adding a derived terms section myself I'll know which one to use. Also, since these lists can be very long, would it be helpful to break them up into subsections? For example as prefixed forms/suffixed forms/multiword forms. --RDBury (talk) 22:23, 3 December 2020 (UTC)

I've noticed more editors adding the col templates than der-top for a while now. I prefer col for the following reasons:
  • It takes advantage of horizontal space, especially in long lists (see kyrka). The fact that der-top defaults to 2 is a mistake in my opinion.
  • Without typing L templates, it takes much less time to create a list, and it's easier to read in the edit window.
  • Automated alphabetization. I don't know when you'd want to bypass it, but you can wrap everything in L templates to avoid sorting.
  • Short lists aren't hidden, like with der-top, so they don't add to page length, and they don't need to be clicked to read. The need to expand is added after a reasonable amount of terms.
I can't find an example, but I've seen {{sense}} used to separate tables. If you do distinguish terms by sense, you'll have lots of shorter lists, which is more user friendly with col (much less clicking). And as a random anecdote, I find the col lists more inviting in their design. It took me a long time to embrace them though. Ultimateria (talk) 19:18, 5 December 2020 (UTC)
Thanks. Just so you know, there are der-top3, der-top4 and der-top5 templates for higher numbers of columns, so I don't think the horizontal space issue matters either way. For common words there will often be some idioms in the list as well so fewer columns may be necessary. Personally, I prefer the list to be hidden until needed because it avoids clutter, the same reason conjugation/declination tables are hidden until needed. I also find partially hidden lists more confusing than the fully hidden lists. For example if I'm looking for "entsprechen" on the list for "sprechen", first I look at the list, find that "entsprechen" isn't there, then notice that it's between the bottom of the first column and the top of the second column, then notice the expand button, click on it, and finally discover "entsprechen". It only takes an extra second or two, but that's enough to interrupt a train of thought. I agree without about the L templates though. Anyway, I gather the upshot is that it's up to the person adding the list. In which case I suppose the best policy is to leave existing lists alone unless changing the format is absolutely necessary; follow the path of least disruption in other words. --RDBury (talk) 08:51, 6 December 2020 (UTC)

New automated nesting proposal for translations[edit]

Proposal 1[edit]

Ottoman Turkish (currently split):

* Turkish: {{t+|tr|Türkiye}}
*: Ottoman Turkish: {{t|ota|تركیه|tr=Türkiye}}

The Ottoman Turkish transliteration is capitalised above just to match the modern Turkish (it's not a statement, not an opinion)


  1. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 03:38, 4 December 2020 (UTC)
Why not the other way around, if I may ask? Allahverdi Verdizade (talk) 10:32, 13 January 2021 (UTC)
@Allahverdi Verdizade: Just following the Greek/Ancient Greek, French/Old French, etc. conventions. E.g. Greek at Greece#Translations. Modern Turkish is most likely to have translations.
* Greek: {{t+|el|Ελλάδα|f}}
*: Ancient: {{t|grc|Ἑλλάς|f}}
--Anatoli T. (обсудить/вклад) 10:46, 13 January 2021 (UTC)
Well, then Symbol support vote.svg Support Allahverdi Verdizade (talk) 10:48, 13 January 2021 (UTC)



Proposal 2[edit]

Mongolian (manual) version #1:

* Mongolian: {{t+|mn|Монгол}}
*: Uyghurjin: {{t|mn|ᠮᠣᠩᠭ᠋ᠣᠯ}}

Mongolian (manual) version #2:

* Mongolian:
*: Cyrillic: {{t+|mn|Монгол}}
*: Uyghurjin: {{t|mn|ᠮᠣᠩᠭ᠋ᠣᠯ}}

Can we have a new language codes for the traditional Mongolian script, but distinct from cmg?


  1. Symbol support vote.svg Support version #2 --Anatoli T. (обсудить/вклад) 03:38, 4 December 2020 (UTC)


  1. Procedural oppose to "a new language codes" as the mechanism for nesting things that we're not distinguishing as separate languages (with their own L2 language headers in entries, etc). I'm fine with nesting the scripts on different lines, like for Serbo-Croatian. - -sche (discuss) 03:10, 14 January 2021 (UTC)


Proposal 3[edit]

Nest Indonesian (currently separate):

* Malay: {{t+|ms|Malaysia}}
*: Indonesian: {{t+|id|Malaysia}}
*: Jawi: {{t+|ms|مليسيا}}


  1. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 03:38, 4 December 2020 (UTC)


  1. Symbol oppose vote.svg Oppose. Indonesian has branched off and become a separate language from Malay. Even though a lot of words are shared, or inherited from Malay to Indonesian, there are differences in vocabulary and even false friends, similar to how Afrikaans has branched off from Dutch. There are also differences in pronunciation and spelling. Despite being mutually intelligible to some extent, I still believe there are too many differences between the two languages for either of them to deserve being nested under the other. There are words in Indonesian that don't exist in Malay (e.g. deputi, krusial, imut), and there are words in Malay that don't exist in Indonesian (e.g. beg, besen, pentadbiran) (I mention these examples not based on whether their Wiktionary entries exist, but based on whether each exists on both KBBI Daring (Indonesia's official dictionary site) and Pusat Rujukan Persuratan Melayu (Malaysia's official dictionary site)). This, I believe, is unlike Serbo-Croatian. For purposes of nesting in translations, I wouldn't nest Afrikaans under Dutch (and at the moment that is not the case), so I think Indonesian shouldn't be nested under Malay. Just my two cents (and I'm Indonesian, so I may or may not be biased). --Bismabrj (talk | contribs) 07:55, 28 December 2020 (UTC).
    EDIT 1: Also, you can see on standard deviation, under Translations, that the translations for Malay and Indonesian are considerably different. As an Indonesian, I don't even know what sisihan or piawai means, let alone their equivalents in Indonesian, so I wouldn't nest Indonesian under Malay there. --Bismabrj (talk | contribs) 10:37, 1 January 2021 (UTC).
    EDIT 2: Oops, my bad, turns out piawai is an Indonesian word, though with a different meaning (another false friend). I apologize for that as I've never heard that word used before, it's probably a word rarely used in Indonesian compared to Malay. The point I tried to make on Edit 1 is that Indonesian and Malay can have different compounds that don't look similar at all, and even (this is something I haven't mentioned before) have loanwords with different etymologies (for example, Indonesian vocabulary from Dutch compared to Malay vocabulary from English), which would cause some etymology misrepresentation problems when Indonesian is always nested under Malay (as if all existing Indonesian words are inherited from Malay, but turns out, no, Indonesian does have loanwords from other languages too without passing through Malay). An example of this problem would be with Indonesian partai from Dutch vs. Malay parti from English, both listed as translations of political party. --Bismabrj (talk | contribs) 01:23, 14 January 2021 (UTC)
@Bismabrj: Would you support nesting Jawi script under Malay, if Indonesian is left as is (unchanged, separate)? --Anatoli T. (обсудить/вклад) 10:56, 13 January 2021 (UTC)
@Atitarev: Jawi script under Malay? I don't really have a stance on that. I wouldn't mind if it happens, but I also wouldn't mind if it doesn't happen. What I would like to point out is that that would be a transliteration rather than a translation, so maybe it would be better to somehow put the Jawi transcription next to the term instead of below, or something like that. I'm not sure. --Bismabrj (talk | contribs) 01:23, 14 January 2021 (UTC)


Proposal 4[edit]

Can we have a new language code for Malay Jawi (Arabic script)? --Anatoli T. (обсудить/вклад) 03:38, 4 December 2020 (UTC)

Hmm, if we're not going to distinguish two script forms of a language by giving them entirely separate L2 headers, I think they don't need their own language codes, do they? What is it that you want the code in order to do—is it to make the different scripts nest on different lines? In that case, we should be able to use whatever code causes Cyrillic vs Roman/Latin Serbo-Croatian to nest on different lines as a model for getting other things to nest. - -sche (discuss) 05:57, 8 December 2020 (UTC)
@-sche: Sorry for the late reply. I know what you mean but I find it difficult to add and maintain nestings in tra nslations. Even "Cyrillic" gets messed up for Serbo-Croatian by the translation-adder if there are already Cyrillic nestings for Mongolian or Old Church Slavonic. The tool doesn't work with |sclb=. For language codes such as nb or nn, cmn, the nesting is automatic and doesn't create any errors. Perhaps a different solution can be created later. Anyway, this proposal about nesting, not new language codes. --Anatoli T. (обсудить/вклад) 10:53, 13 January 2021 (UTC)

template:tlb - position, improvement, replacemenet?[edit]

So this template has been bothering me for a while now. In ceratin cases, with languages that add a lot of info to their headword template (eg. Latin), placing it after the headword is ensuring noone ever sees it. It's the part of the dictionary that most people simply skip unless looking for something specific. As such, people avoid using template:tlb altogether and just put {lb} before the definitions. However, sometimes there are many definitions, and all of these usages are obsolete or colloquial, for example. So when editing the entry ужо I've decided to experimentally put {tlb} before the headword template. Is this desirable? Can you offer better ways to solve the issues? I question the ultility of the template in its current use. Brutal Russian (talk) 18:32, 5 December 2020 (UTC)

I initially created this template's predecessor, T:term-context (counterpart to T:context), to handle the situation where an English word was specific to American or British spelling, where it felt excessive and potentially confusing to label every sense of the word "(British)" or "(British spelling)" when only the spelling and not the sense was restricted. (And imagine stacking labels on terms that also had regionally-specific senses, like "(British, British spelling)".) I do think that, for English, labelling spelling issues somewhere other than on every sense-line of highly polysemous (lemma) words is an impovement, but there are a lot of other situations where it's unclear which template to use (I've been surprised at how it's taken off), or at least, where to place whichever template is used—since this template also enables distinguishing "terms with obsolete senses" from "obsolete terms", etc. I agree it often gets lost in the "noise" of a long headword line. I'd love if we could come up with a better way to handle "American vs British spelling" cases and/or "all senses are obsolete and should be categorized as such, vs only some senses are". - -sche (discuss) 20:57, 5 December 2020 (UTC)
Looking at some random entries where the template is used, the usage does seems to be all over the board. For example in abalienation there is only one definition so label would be better, in aband it's used in both definitions (yikes!), in color it's used as intended, and in consent it's used as a valence label (i.e. intransitive) which afaik would normally go in the definition lines no matter how many there are. Another issue is that the headword template usually also adds parentheses, so you end up with two sets of parentheses in a row and that seems awkward. (You can see this in the template documentation.) I don't see anything wrong with putting tlb before the headword template, at least in most cases when it's being used as intended. It would be more consistent with the way the label template is used, it would avoid the double parentheses, and yes it would make the information more visible. --RDBury (talk) 09:27, 6 December 2020 (UTC)
PS. The head template allows additional labels as well, so really the tlb template should not be used in combination with it. I'm thinking grammatical information should go in the headword template when possible, see for example an. --RDBury (talk) 09:55, 6 December 2020 (UTC)
Except {{tlb}} is rarely used for grammatical information but for usage information, and it would require to make many language-specific head templates to be made much more complicated in order to pass labels, and it still wouldn’t address this template’s being overlooked.
The solution to {{tlb|-}} being overlooked near the head is to use {{tlb|-}} more often near the head. I have deployed it in Arabic entries so systematically that one looks thither automatically, or others got used to seek and put it there (because there wasn’t much labelled or labellable obsolete before me). Fay Freak (talk) 20:15, 6 December 2020 (UTC)
I was thinking more just the vanilla head template, not all the language specific ones, hence "when possible". In the entries I looked at it was used for grammar about half the time, but it was not a random sample. Perhaps a separate "Grammar" line under the definition, with it's own template, would solve a number of problems. Many German verbs have complicated grammatical features that are awkward to fit into the definition line, and I'm sure German is not the worst offender in this respect. --RDBury (talk) 07:27, 8 December 2020 (UTC)
As an alternative proposition, if we do decide to move it, it could also go on a separate line after the headword and before definitions, which has the advantages of both being immediately noticeable and cluttering up the headword line less than a pre-headword position. — Vorziblix (talk · contribs) 05:22, 7 December 2020 (UTC)
As long as we're spitballing: years ago, someone (Ruakh?) pointed out that some dictionaries "highlight" the text of labels with a background colour to set them off and make them more visible, and different colours and/or different kinds of brackets () [] could distinguish different categories of label, e.g. grammatical info vs dialects, or topics (saying that plant relates to "botany") vs restrictions (saying a term is only used by botanists in their jargon). Such things could also be used to distinguish labels that apply to a sense vs those that apply to a whole word, or to make term-labels more prominent, as long as the information was still accessible for colorblind or blind (screenreader) users (which it should be, since the text would still be there). - -sche (discuss) 05:44, 8 December 2020 (UTC)
Yes, DWDS is a good example of this. Blue for definitions and links, green for label-type information, dark red for what we call "non-gloss definitions". (See [1] for a page that uses all of these.) It also uses font size as well as color in meaningful ways. I don't approve of all their layout choices, but overall it's done tastefully imo. Color can open a can of worms with regard to accessibility though: Will colorblind reader be confused? Will automated text readers be confused? The Wikiverse traditionally sticks to black & white and I'm thinking accessibility worries are part of the reason. --RDBury (talk) 06:51, 8 December 2020 (UTC)

2020 Coolest Tool Award Ceremony on December 11th[edit]

Creating section headers for old discussions on the talk pages of entries[edit]

Hello, I'm wondering if anyone would object to me moving discussions like the one currently at the top of Talk:empathy into sections with names like "Untitled discussion from October 2011" or "Untitled discussion from 2011". The main reason I am interested in doing this is to make talk pages easier to navigate and the table of contents more accessible. I am posting about this here because this is usually the place where community standards (AKA "policy") are set. Best. —The Editor's Apprentice (talk) 21:57, 7 December 2020 (UTC)

I often do this manually myself, for the same reason, but I'm not sure that "Untitled discussion" would help much. It's better to give them meaningful names for the table of contents. Equinox 22:39, 7 December 2020 (UTC)
I agree; I do this too, and yes, if there's an obvious meaningful title, use it... but if not I have indeed used generic titles like proposed. - -sche (discuss) 05:48, 8 December 2020 (UTC)
Thank you both. I think this is sufficient agreement given the scale of the change so I will go forward inline with what y'all have suggested. Best. —The Editor's Apprentice (talk) 17:39, 8 December 2020 (UTC)

Descendants of Old Church Slavonic[edit]

Moved from Talk:заповѣдь#Descendants
User @Atitarev has reverted my contribution with the comment: "Only Bulgarian is considered a descendant of OCS". In many other articles I saw other South Slavic languages listed as descendants of OCS, so I need a reference for this statement. --Mladifilozof (talk) 21:50, 8 December 2020 (UTC)

@Mladifilozof:: At Module:languages/data2 "bg" has ancestors = {"cu"}. So if you try using {{bor|bg|cu|TERM}} it would be incorrect, {{inh|bg|cu|TERM}} should be used instead.
Calling @Benwing2, Bezimenen, Rua: could you please send a link for the discussions re this decision? @Mladifilozof has been adding a lot of OCS contents, so we need that formalised somehow (if it's required).
BTW, Linking to edit is better done this way: diff.--Anatoli T. (обсудить/вклад) 22:11, 8 December 2020 (UTC)
What he saw may have been old uses of {{desc}} without |bor=1. Discussions include Wiktionary:Beer parlour/2020/February § Bulgarian as descendant of Old Church Slavonic and Wiktionary:Beer parlour/2019/September § I want to add Church Slavonic terms. Well it is known on which regiolects the Old Church Slavonic language is based, some from which Modern Bulgarian and Macedonian partially descend. I don’t know why Macedonian is not reckoned a descendant of Old Church Slavonic. Fay Freak (talk) 03:43, 9 December 2020 (UTC)
What he saw was probably User:Ivan Štambuk’s old entries from back when we didn’t have many Proto-Slavic entries and instead vaguely conflated Proto-Slavic with OCS. There are a lot of these left over from the old days. They should all be changed, and the descendants moved to Proto-Slavic. — Vorziblix (talk · contribs) 17:07, 11 December 2020 (UTC)
Else, does Mladifilozof consider the Freising manuscripts “Old Church Slavonic”? If not, then it is evident why Slovene does not descend from Old Church Slavonic, similarly Serbo-Croatian. Fay Freak (talk) 03:54, 9 December 2020 (UTC)
@Fay Freak, Vorziblix, Benwing2: I don't support the theory that South Slavic languages descend from a common "Old South Slavic". They are all from different dialects, even Macedonian is apparently from a close but different dialect than Bulgarian, otherwise, it would be made another descendent of OCS.
In practical terms, Slovene, Serbo-Croatian, Bulgarian/Macedonian (as two close languages) are as close to each other as Polish to Slovene or Russian to Serbo-Croatian. They are mutually understandable (to some degree) or have a lot of similarities to each as most unrelated Slavic languages to each other. Unlike descendants of Old East Slavic, Chech/Slovak, Bulgarian/Macedonian, the rest of major Slavic languages probably don't have a common ancestor and "South Slavic" and "West Slavic" are merely territorial names, they don't have a linguistic base, even if territorial proximity and in some cases common history also had an affect on their linguistic similarities. --Anatoli T. (обсудить/вклад) 23:41, 20 December 2020 (UTC)
@Atitarev, Fay Freak, Vorziblix, Mladifilozof I am late to this discussion but yes only Bulgarian should be considered a descendant of Old Church Slavonic, at least in the standard recension. Macedonian seems to have descended from a slightly different dialect (most notably, one that did not confuse the two yers). I agree with Fay Freak that cases where other languages (including Russian!) are given as descendants are due to a missing |bor=1 in {{desc}}. Serbo-Croatian and Slovenian are definitely not descendants; they were in fact geographically isolated from Bulgarian/Macedonian for several centuries (probably by Proto-Romanian speakers, I think), which explains why they evolved in such different directions. Benwing2 (talk) 02:07, 27 December 2020 (UTC)

Jeju entries for Hangul letters[edit]

There are some Jeju entries for Hangul letters: Category:Jeju letters. With the potential caveat of and , which are now deprecated in the modern standard language, are these useful? Note that Jeju was historically not a written language. There are virtually no texts in it by native speakers, and the official, general-purpose orthography was promulgated only in 2014. In my opinion these are likely only to distract readers (by virtue of coming first in the entry) from the actually meaningful section with etymologies and everything, which are of course the Korean ones.--Karaeng Matoaya (talk) 11:37, 10 December 2020 (UTC)

I don't think that Jeju not being called 'Southernmost Korean' is a valid argument against the letters of Jeju having their own entries. RichardW57 (talk) 17:46, 10 December 2020 (UTC)
I suggest that the proper solution is to make the part that discusses the origin and usage of the letters as letters translingual; translingual entries are preceded only by English entries. Jeju combining jamo may then be treated on the same footing as Welsh etc. letters - for which there is a vote in interminable discussion to remove from the pages housing lemmas. RichardW57 (talk) 17:46, 10 December 2020 (UTC)

Desysopping on Inactivity[edit]

Per this vote, shouldn't we desysop users like Polyglot (talkcontribs), Timwi (talkcontribs), Dvortygirl (talkcontribs), and others? —⁠This unsigned comment was added by Imetsia (talkcontribs) at 19:51, 10 December 2020 (UTC).

Yes. Polyglot hasn't used his/her admin tools since May 2014, Timwi hasn't used his since February 2006 (!), and Dvortygirl hasn't used hers since March 2013. —Mahāgaja · talk 22:00, 10 December 2020 (UTC)
@SemperBlotto, Chuck Entz, Surjection? Imetsia (talk) 18:13, 19 December 2020 (UTC)

Definition: Gloss or sentence[edit]

This discussion has mostly been sparked by the recent edits of User:PadshahBahadur. Simple definitions in Wiktionary always had two possible formatting possibilities: giving a simple gloss ([[cat]]) or a sentence (A [[cat]].).[1] I believe it is time to establish some boundaries to the editors' freedom to change a well-established gloss to a sentence and vice versa, either by establishing when to use which type of definition or by agreeing not to change the style of other editors.

What I personally see as a downside to formatting (noun) definitions as sentences is the possible incorrect or inaccurate depiction of the definition as portrayed by the following example: the word cat is neither definite nor indefinite by itself, while the definition A cat. suggests this is not the case. The opposite occurs with languages without articles: Russian кот is both definite and indefinite. Thadh (talk) 21:29, 10 December 2020 (UTC)

Non-English definitions are often one-expression glosses, without a terminating dot. English definitions are usually formatted with a dot. Only certain proverbial expressions are actually defined as sentences. This seems to reflect the preferences of the relevant communities of editors, AFAICT. DCDuring (talk) 23:24, 10 December 2020 (UTC)
I think an exception can be made for non-English definitions when there is no simple English gloss, but rather an explanation of the term is required. I don't have an example off-hand, but I know I've seen them and have probably written some myself. In those cases, I think sentence formatting for a non-English entry is warranted. —Mahāgaja · talk 10:30, 11 December 2020 (UTC)
An example of such an exception in my mind is the third sense of doties or falsettone. I think this situation is generally poorly explained on the current style guide page and might try to re-write it in the future in order to clarify general practices, which may need to be surveyed. —The Editor's Apprentice (talk) 20:24, 11 December 2020 (UTC)
There is something about this in Wiktionary:Style guide#Types of definitions. Two types are distinguished: “full definitions”, which are in sentence case and end with a full stop (e.g., “The larva of a butterfly or moth; leafworm.”), and “simple glosses”, which should not be capitalized and should not end with a full stop (e.g., “caterpillar”). The former is said to be the preferred form for definitions of English terms, the latter for other languages. Next to these two main types, there are also “non-gloss definitions” for cases that cannot be defined by another phrase (in English) with the same meaning. Cases like Italian falsettone are indeed poorly explained. Is the proposal to turn the type that is currently preferred to one that is prescribed? Turning the preferred type into a non-preferred type should certainly be discouraged, but the converse (within reason – each rule has cases where it does not fit) should IMO be encouraged.  --Lambiam 23:34, 11 December 2020 (UTC)
At this point I am disinterested in trying to create prescriptions, especially since doing so requires organizing a community vote, and I don't think anyone else is proposing creating them in this discussion. The main thing that I'm personally thinking about is making the phrasing clearer and checking in with others when I notice any ambiguities. —The Editor's Apprentice (talk) 04:26, 12 December 2020 (UTC)
I personally like full-sentence definitions and add entries using both these and uncapitalised gloss definitions. I would certainly oppose an initiative to only restrict full definitions to English. Whether they should be allowed or not should in my opinion be left to the community of editors active in a language. Massively changing the style of entries without community consensus is certainly poor form, however, and doing so in languages one doesn't even know is also poor judgement. Really, changing other editors' style should be avoided in absence of a good reason. For various languages, in particular many in East Asia and Southeast Asia, nouns are not marked for grammatical number; changing to those full-definition style without community input is especially ill-considered, because that style might suggest to readers that those nouns are necessarily singular. ←₰-→ Lingo Bingo Dingo (talk) 14:11, 12 December 2020 (UTC)
I'm definitely not a fan of short definitions formatted in this style. I think having a single word with a period is silly, there is no way you are pretending that it's a full sentence so why try? I also think the use of the article is completely superfluous, it adds nothing to the definition and makes it longer than needed. —Rua (mew) 18:14, 13 December 2020 (UTC)

Community Wishlist Survey 2021[edit]

SGrabarczuk (WMF)

15:03, 11 December 2020 (UTC)

We forgot to wish for more memory. – Jberkel 15:43, 11 December 2020 (UTC)
The Wiktionary wishlist items look mostly like ways of adding mass quantities of content. They might make sense for many languages with few entries, but are likely to require lots of review. One example, is a tool to vastly simplify the addition of pronunciations. That would probably lead to many legitimate regional pronunciations as well as many spurious files that we might consider vandalism. We would need to develop some means of sorting out legitimate pronunciations from others and also reduce the visual clutter of the legitimate new content at the top of L2 sections where we have pronunciations.
My instinct is to push back, both by oppose votes and comments about the need for accompanying tools to facilitate review of such content. DCDuring (talk) 17:13, 11 December 2020 (UTC)
It seems a bit perverse that all Wikimedians get to vote on what is supposed to be good for Wiktionary (or Wiktionaries?). Transwikied “dictdefs“ from Wikipedia were also not a welcome gift.  --Lambiam 23:40, 11 December 2020 (UTC)
I agree with User:Jberkel that we forgot to wish for more memory per page (or at least, to raise the maximum allocated memory per page). There are still entries in the category wikt:CAT:E that have errors reading "Lua error: not enough memory". This proposal from last year's Community Wishlist Survey could have been re-proposed: meta:Community_Wishlist_Survey_2020/Wiktionary/More_Lua_memory_for_Wiktionary (and there, one can read more about the issue). Maybe next year. Let's hope we won't forget. --Bismabrj (talk | contribs) 14:27, 27 December 2020 (UTC)
Disallowing RFDs nominated by IPs sounds like a very good idea. DonnanZ (talk) 17:20, 16 December 2020 (UTC)

Inflected reflexive Italian infinitives[edit]

Domandarmi is defined as "first-person singular infinitive of domandarsi". By definition you can't have a first person infinitive. There must be a less confusing way to phrase this construct, domandare (to ask) + -mi (myself). Vox Sciurorum (talk) 16:01, 11 December 2020 (UTC)

  • In Italian, such terms exist for reflexive infinitives. SemperBlotto (talk) 07:28, 14 December 2020 (UTC)

hwc-en Issue[edit]

Recently, “hwc” (Hawaiian Creole English) was reinstated on Wiktionary. However, many Hawaiian Creole English words have been placed under “en” (English).

Here’s an example: hammajang

This word is clearly from Hawaiian Creole, though because Hawaiian Creole had no recognition until earlier this year, it was placed as an English entry. I’m curious if I should replace the English entry and only put the Hawaiian Creole entry on the page, or just leave both at the same time.

It’s a confusing decision for me to make since Hawaiian Creole and English sit on a continuum, and speakers of both languages (including me) code-switch depending on the situation.

Also, out of curiosity, have there been situations like this before where a new language code sort of messes things up? — Okonomiyaki39 (talk) 03:39, 12 December 2020 (UTC)

It's not too hard: don't remove the English section if it's used in English, like the quote at hammajang#English. Also, I assume you're the same person as Coastaline/Haimounten/Haimaunten. Please stop creating new usernames like this; it is disruptive and confusing for others. —Μετάknowledgediscuss/deeds 04:13, 12 December 2020 (UTC)
Okay but is “hammajang” within the realms of English? If one were to travel to Hawaii, no one would see “hammajang” as an English word, or at least not a standard one. I don’t believe it’s an English loanword just because we found a book quote that uses it.
Furthermore, I talked about the account changes with Chuck Entz and he didn’t seem to have a problem with it provided I’m not using new accounts to evade bans/kicks. But you’re right, it can get disruptive. I apologize.
But anyways, I’ll take your advice and just leave the English entry. Thanks for responding. — Okonomiyaki39 (talk) 18:45, 12 December 2020 (UTC)
Yeah, like you say, it's tricky because HWC~EN is a continuum. But this isn't the only such situation (we also have this issue with Jamaican Creole and Scots, etc), and it comes down to evaluating whether the surrounding text is English or the other language. In this case, the rest of the sentence "I can't think straight, my thoughts are all [...], but I say, 'When is his funeral?'" definitely looks like standard English and does not look like Hawaiian Creole texts like the HWC Bible quoted in the earlier discussion of HWC. And since the word is not set off in italics or quotation marks or anything else that would suggest it was being set off as a foreign term / code-switching, it looks like a solid citation of English usage of the word. (If the word were RFVed, we'd need two more such examples.) It gets trickier if there is a sentence where e.g. the grammar is English but there are a lot of HWC words. - -sche (discuss) 20:12, 12 December 2020 (UTC)


As we're in the 2020s already, when emojis are used so widely, having a link between a word and an emoji seems like a good idea. After seeing a link at aubergine, I got inspired to add more, but stopped because it was probably a poorly though-out plan. What do y'all think about it? La más guay (talk) 23:16, 15 December 2020 (UTC)

Er, no thanks. DonnanZ (talk) 17:17, 16 December 2020 (UTC)
I'm not a great fan, but we already have several. We probably won't stop you. SemperBlotto (talk) 17:20, 16 December 2020 (UTC)

Category:Stative verbs for colors, Category:Adjective verbs for colors or something else?[edit]

In some languages, which normally express colors with adjectives or nouns, there are also some stative verbs (or adjective verbs) expressing that something is, looks, shows, or appears a certain color (as opposed to making or becoming that color, i.e. dynamic color verbs), for example Proto-Indo-European *h₁rudʰéh₁ti, Latin rubeo, French verdoyer, German grünen, Russian сине́ть/​голубе́ть/​пестре́ть/​черне́ть/​зелене́ть (sinétʹ/​golubétʹ/​pestrétʹ/​černétʹ/​zelenétʹ), Esperanto blui/​ruĝi/​verdi, Hungarian kéklik/​zöldell/​sárgállik, Palauan bekerkard, Navajo łichííʼ, Marshallese kilmir, Chickasaw homma, Afar qasa, Ainu フレ, and possibly also some Korean terms. If we create a category for them, I suppose in Category:Colors and perhaps in Category:Stative verbs by language as well, shall we name it Category:Stative verbs for colors, Category:Adjective verbs for colors, or something else? Adam78 (talk) 14:06, 16 December 2020 (UTC)

Example of what you can do with Wikidata compared to Wiktionary[edit]

Continuing this old discussion, @pamputt what about pronounciation and examples for every single sense and form? That seems pretty nice to me too. Its easy with SPARQL to get a list of forms that do not have a pronounciation yet and fix it. A caveat in Wikidata is that we cannot legally add citations from works still in copyright, I'm not sure if you do that here or not.--So9q (talk) 13:59, 19 December 2020 (UTC)

I would guess that most of our citations are from works still in copyright, given that our coverage includes contemporary words, senses, and phrases that may have only existed for the past few decades (e.g., ghost#Verb (sense 10), twerk#Verb, olinguito, Netflix and chill, hit it and quit it). bd2412 T 15:44, 19 December 2020 (UTC)
The vast majority of our citations are from the 20th and 21st centuries, followed by the 19th century. It falls off precipitously from there. DTLHS (talk) 16:40, 19 December 2020 (UTC)

AWB access request[edit]

I'll be working on a new version of the Middle English conjugation templates ({{enm-conj}} and {{enm-conj-wk}}; there'll probably be a {{enm-conj-st}}, {{enm-conj-irreg}}, and possibly others). It'd be helpful to have use of AWB so I can avoid the arduous task of replacing all the templates manually. Hazarasp (parlement · werkis) 11:38, 23 December 2020 (UTC)

@Hazarasp: AWB access granted. — Eru·tuon 22:11, 23 December 2020 (UTC)
When I try to use AWB, it says "Hazarasp is not enabled to use this"; I think I need to be added to the list at Wiktionary:AutoWikiBrowser/CheckPage#Users. Hazarasp (parlement · werkis) 04:14, 24 December 2020 (UTC)
@Hazarasp: Okay, I guess the version that will use Wiktionary:AutoWikiBrowser/CheckPageJSON hasn't actually been released? I've added you to the old page as well. — Eru·tuon 09:05, 24 December 2020 (UTC)

Obsoleting Template:vi-hantu[edit]

@Mxn, PhanAnh123 I am planning to do a bot run to convert {{vi-hantu}} into {{vi-readings}}. I want to make sure (a) I do it correctly, (b) there are no objections. I think the following should work:

  • {{vi-hantu|READING|rs=SORT}} --> {{vi-readings|reading=READING|rs=SORT}} with links removed from the readings.
  • If |chu=Nom is present, either I will leave them alone or use {{vi-readings|nom=READING|rs=SORT}} (what do you think?). BTW there are 30 pages with |chu=Nom in them; that is few enough that they can be converted by hand if needed. They are as follows: , , 𩂏, 𪽵, 𠀗, 𠀖, 𥿗, 𠀲, 𠁂, 𠈋, 𥇹, 𡴉, 𥐆, 𢖮, 𣅶, 𡪇, 𩈩, 𢢲, 𤣡, 𢞂, 𠫏, 𪛇, 𪛅, 𪶾, 𫠢, 𫡁, 𫡂, 𢠄, 𬔗, 𤞼
  • Entries with |pos= probably need to be converted by hand. Luckily there's only one:
  • I'll also check to make sure all converted entries are single-character, and leave alone any that are multi-character.

Comments? Benwing2 (talk) 02:23, 27 December 2020 (UTC)

I don't think there is any reason to oppose these proposals. In the case of |chu=Nom, I think the later option would be preferable.PhanAnh123 (talk) 02:59, 27 December 2020 (UTC)
@Mxn, PhanAnh123 I went ahead and converted the templates. There were a few that couldn't be converted automatically (see below); could one of you fix them up? Thanks!
  • Page 21 : WARNING: Empty reading, skipping: {{vi-hantu}}
  • Page 22 : WARNING: Empty reading, skipping: {{vi-hantu}}
  • Page 35 : WARNING: Empty reading, skipping: {{vi-hantu|rs=卜00}}
  • Page 36 : WARNING: Empty reading, skipping: {{vi-hantu|rs=卩00}}
  • Page 38 : WARNING: Empty reading, skipping: {{vi-hantu|rs=厂00}}
  • Page 48 : WARNING: Empty reading, skipping: {{vi-hantu}}
  • Page 1290 : WARNING: Empty reading, skipping: {{vi-hantu|hanviet=đùm|rs=手12}}
  • Page 1291 : WARNING: Empty reading, skipping: {{vi-hantu|hanviet=đan, đản|rs=手12}}
  • Page 1651 : WARNING: Empty reading, skipping: {{vi-hantu|rs=木15}}
  • Page 2586 : WARNING: Empty reading, skipping: {{vi-hantu}}
  • Page 2736 : WARNING: Empty reading, skipping: {{vi-hantu|rs=艸05}}
  • Page 3386 : WARNING: Saw pos=, skipping: {{vi-hantu|đồng, đòng|pos=noun|rs=金06}}
  • Page 3808 國會: WARNING: Length of page title is 2 > 1, skipping
  • Page 3918 User:Bumm13/templates: WARNING: Length of page title is 21 > 1, skipping
  • Page 3959 𠀳: WARNING: Empty reading, skipping: {{vi-hantu|rs=一07}}
  • Page 3964 User:Kc kennylau/沙盒: WARNING: Length of page title is 19 > 1, skipping
  • Page 4023 常川: WARNING: Length of page title is 2 > 1, skipping
  • Page 4057 User:Dixtosa/ja: WARNING: Length of page title is 15 > 1, skipping
  • Page 4059 㗂西: WARNING: Length of page title is 2 > 1, skipping
Benwing2 (talk) 01:38, 28 December 2020 (UTC)
@Benwing2 Thanks for taking care of unifying the templates. I think I've addressed all the main-namespace transclusions above, copying from the Vietnamese Wiktionary which uses {{R:WinVNKey:Lê Sơn Thanh}} as its source. Now Category:Vietnamese Han characters with unconfirmed readings has over 6,200 more entries to research. At least now we have a good grasp on how much of a mess Unihan made of Vietnamese! – Minh Nguyễn 💬 03:43, 5 January 2021 (UTC)
@Mxn Thanks for that. I have changed {{vi-hantu}} to prominently display a "deprecated" message when it's used, and also in its doc page. (I didn't delete it because it is in the page history of several thousand pages.) Hopefully that will scare people off from using it in the future. Benwing2 (talk) 03:54, 5 January 2021 (UTC)

Merging language variety data[edit]

Currently there are at least four places where data on language varieties can be found:

  1. Module:etymology languages/data;
  2. Module:labels/data/subvarieties;
  3. Module:el:Dialects, Module:fr:Dialects and similar;
  4. On category pages associated with particular varieties, such as Category:Gascon or Category:Early Modern Korean.

I would like to consolidate this as much as possible. My current plan is to leave Module:etymology languages/data as-is and consolidate the remainder, avoiding duplicated data. Some discussion points:

  1. Any objections?
  2. Where should the data go? Module:labels/data/subvarieties is the most complete source of data but I think splitting by language is probably better. I'm thinking a format of either Module:varieties/fr, Module:varieties/data/fr or maybe Module:fr:Varieties. I'd like to avoid "dialect" because it's a loaded term; "variety" is already used in the data in Module:languages/data2 and such, as well as in Wikipedia articles such as Varieties of Arabic, Varieties of Chinese, Varieties of French, etc.

Benwing2 (talk) 02:42, 27 December 2020 (UTC)

Some lects that are intermediate between two languages are hard to pin down as being a variety of specifically one of the two, something that the proposed organization appears to require. I do not know whether this Buridanic problem will arise in lexicographic practice, but an example is found in the Bavarian to Alemannic transition zone, basically the drainage basin of the Lech, which includes Augsburg.  --Lambiam 12:52, 27 December 2020 (UTC)
What will this do to memory use on large pages? Vox Sciurorum (talk) 09:09, 28 December 2020 (UTC)

Japanese sort keys vs. Chinese sort keys[edit]

(Notifying Eirikr, TAKASUGI Shinji, Atitarev, Suzukaze-c, Poketalker, Cnilep, Marlin Setia1, Huhu9001, 荒巻モロゾフ, 片割れ靴下, Onionbar, Shen233): I'm looking at removing the manually-specified Japanese sort keys in {{charactercat}} and using the automated ones in Module:zh-sortkey. In the vast majority of cases, the manually-specified sort keys are the same as the automated ones. See the sample below, which represents about 1500 characters; only 29 of them had a manual sort key different from the automated ones. Most of the time, the manual and automated sort keys have the same radical and differ by one or two strokes, but in a few cases the radical is different. Could some Japanese speakers take a look at the sample below and let me know if these differences are significant? I suspect they're not, but I want to make sure. Thanks! Benwing2 (talk) 23:45, 27 December 2020 (UTC)

  • Page 609 Category:Japanese terms spelled with 将: WARNING: Japanese/Okinawan category with manual sort key 寸07 != automatic 寸06: {{charactercat|ja|将|sort=寸07}}
  • Page 639 Category:Japanese terms spelled with 視: WARNING: Japanese/Okinawan category with manual sort key 見04 != automatic 示07: {{charactercat|ja|視|sort=見04}}
  • Page 649 Category:Japanese terms spelled with 故: WARNING: Japanese/Okinawan category with manual sort key 攴04 != automatic 攴05: {{charactercat|ja|故|sort=攴04}}
  • Page 689 Category:Japanese terms spelled with 奈: WARNING: Japanese/Okinawan category with manual sort key 凵03 != automatic 大05: {{charactercat|ja|奈|sort=凵03}}
  • Page 829 Category:Japanese terms spelled with 衛: WARNING: Japanese/Okinawan category with manual sort key 行10 != automatic 行09: {{charactercat|ja|衛|sort=行10}}
  • Page 851 Category:Japanese terms spelled with 黙: WARNING: Japanese/Okinawan category with manual sort key 黑11 != automatic 火11: {{charactercat|ja|黙|sort=黑11}}
  • Page 1003 Category:Japanese terms spelled with 充: WARNING: Japanese/Okinawan category with manual sort key 儿03 != automatic 儿04: {{charactercat|ja|充|sort=儿03}}
  • Page 1009 Category:Japanese terms spelled with 章: WARNING: Japanese/Okinawan category with manual sort key 立06 != automatic 音02: {{charactercat|ja|章|sort=立06}}
  • Page 1016 Category:Japanese terms spelled with 堅: WARNING: Japanese/Okinawan category with manual sort key 土09 != automatic 土08: {{charactercat|ja|堅|sort=土09}}
  • Page 1038 Category:Japanese terms spelled with 描: WARNING: Japanese/Okinawan category with manual sort key 手08 != automatic 手09: {{charactercat|ja|描|sort=手08}}
  • Page 1077 Category:Japanese terms spelled with 晩: WARNING: Japanese/Okinawan category with manual sort key 日08 != automatic 日07: {{charactercat|ja|晩|sort=日08}}
  • Page 1099 Category:Japanese terms spelled with 盛: WARNING: Japanese/Okinawan category with manual sort key 皿07 != automatic 皿06: {{charactercat|ja|盛|sort=皿07}}
  • Page 1103 Category:Japanese terms spelled with 蒸: WARNING: Japanese/Okinawan category with manual sort key 艸10 != automatic 火10: {{charactercat|ja|蒸|sort=艸10}}
  • Page 1182 Category:Japanese terms spelled with 幹: WARNING: Japanese/Okinawan category with manual sort key 十11 != automatic 干10: {{charactercat|ja|幹|sort=十11}}
  • Page 1184 Category:Japanese terms spelled with 聴: WARNING: Japanese/Okinawan category with manual sort key 耳11 != automatic 耳12: {{charactercat|ja|聴|sort=耳11}}
  • Page 1215 Category:Japanese terms spelled with 誠: WARNING: Japanese/Okinawan category with manual sort key 言07 != automatic 言06: {{charactercat|ja|誠|sort=言07}}
  • Page 1257 Category:Japanese terms spelled with 践: WARNING: Japanese/Okinawan category with manual sort key 足06 != automatic 足05: {{charactercat|ja|践|sort=足06}}
  • Page 1288 Category:Japanese terms spelled with 巡: WARNING: Japanese/Okinawan category with manual sort key 巛04 != automatic 辵03: {{charactercat|ja|巡|sort=巛04}}
  • Page 1334 Category:Japanese terms spelled with 禅: WARNING: Japanese/Okinawan category with manual sort key 示09 != automatic 示08: {{charactercat|ja|禅|sort=示09}}
  • Page 1438 Category:Japanese terms spelled with 餅: WARNING: Japanese/Okinawan category with manual sort key 食08 != automatic 食06: {{charactercat|ja|餅|sort=食08}}
  • Page 1450 Category:Japanese terms spelled with 級: WARNING: Japanese/Okinawan category with manual sort key 糸03 != automatic 糸04: {{charactercat|ja|級|sort=糸03}}
  • Page 1454 Category:Japanese terms spelled with 獄: WARNING: Japanese/Okinawan category with manual sort key 犬10 != automatic 犬11: {{charactercat|ja|獄|sort=犬10}}
  • Page 1481 Category:Japanese terms spelled with 睡: WARNING: Japanese/Okinawan category with manual sort key 目08 != automatic 目09: {{charactercat|ja|睡|sort=目08}}
  • Page 1524 Category:Japanese terms spelled with 免: WARNING: Japanese/Okinawan category with manual sort key 儿06 != automatic 儿05: {{charactercat|ja|免|sort=儿06}}
  • Page 1582 Category:Japanese terms spelled with 墨: WARNING: Japanese/Okinawan category with manual sort key 土11 != automatic 黑03: {{charactercat|ja|墨|sort=土11}}
  • Page 1633 Category:Japanese terms spelled with 忘: WARNING: Japanese/Okinawan category with manual sort key 亠04 != automatic 心03: {{charactercat|ja|忘|sort=亠04}}
  • Page 1772 Category:Japanese terms spelled with 些: WARNING: Japanese/Okinawan category with manual sort key 二06 != automatic 二05: {{charactercat|ja|些|sort=二06}}
  • Page 2040 Category:Japanese terms spelled with 嘩: WARNING: Japanese/Okinawan category with manual sort key 口10 != automatic 口12: {{charactercat|ja|嘩|sort=口10}}
  • Page 2086 Category:Japanese terms spelled with 繭: WARNING: Japanese/Okinawan category with manual sort key 糸12 != automatic 糸13: {{charactercat|ja|繭|sort=糸12}}
Radical classifications depend on each dictionary, especially for Japanese shinjitai. Some of them are differences between Chinese simplified characters and Japanese shinjitai at the same code point, such as:
  • : 寸07 (all characters containing instead of 𪧷)
  • : 行10 (all characters containing )
  • : 土09 (all characters containing )
  • : 手08 (all characters containing ) — it should be 手08 also in Mainland China while it is 手09 in Taiwan
  • : 足06 (all characters containing instead of )
  • : 示09 (all characters containing instead of )
TAKASUGI Shinji (talk) 01:35, 28 December 2020 (UTC)
@TAKASUGI Shinji Thanks. I think what you're saying is that at least some of the manually specified sort keys that differ from the Chinese ones are correct for Japanese. Are any of them incorrect? Also do you know of a machine-readable source for Japanese radical classifications? One thing we could do is fix Module:zh-sortkey to produce the correct Japanese sort keys when the language is specified as Japanese. The function in question (makeSortKey) already takes a language as its second parameter, but currently ignores it. Benwing2 (talk) 01:46, 28 December 2020 (UTC)
奈 must be 大05, 黙 must be 火11, and 聴 must be 耳11 (just like ) everywhere. — TAKASUGI Shinji (talk) 05:40, 28 December 2020 (UTC)
require("Module:zh-sortkey").makeSortKey(pagename, "ja")
doing this currently? -- Huhu9001 (talk) 11:29, 28 December 2020 (UTC)
@Huhu9001 It doesn't. It accepts a language parameter but ignores it; you get the same output regardless of language. I can make it produce Japanese-specific output when called with "ja", but I need a machine-readable source of Japanese radical/stroke analyses for all Unicode characters (or at least the relevant subset of them). Do you know of such a source? Benwing2 (talk) 04:52, 29 December 2020 (UTC)

Inflections of multi-word verb phrases[edit]

An anonymous editor frequently adds inflections to multi-word verb phrases, such as at bang one's head against a brick wall, which now reads:

bang one's head against a brick wall (third-person singular simple present bangs one's head against a brick wall, present participle banging one's head against a brick wall, simple past and past participle banged one's head against a brick wall)

To me this seems unnecessarily laborious, and I am tempted to just delete them. Didn't we have a discussion about this before? I can't seem to find it now. What did we decide? Mihia (talk) 01:56, 28 December 2020 (UTC)

@Mihia If there was a previous discussion, I missed it. I added support to {{en-verb}} to make it easy to add inflections to multiword phrases, and went ahead and fixed all the existing phrases missing inflections to include them. You'll notice that the headword is just declared as {{en-verb|*}}, so it isn't actually laborious to include them. So I am fine with what the IP is doing. Benwing2 (talk) 02:22, 28 December 2020 (UTC)
Thanks, I don't mean that it is laborious to code them, as I have indeed noticed the "*" syntax, but just that the output appears laborious and unnecessary in the article, in my personal opinion. I deliberately use the "head" template to suppress inflections in long multi-word cases such as this, but then someone comes along and puts them in. Mihia (talk) 02:28, 28 December 2020 (UTC)
Is it possible to link only to the verb forms?
  • bang one's head against a brick wall (third-person singular simple present bangs one's head against a brick wall, present participle banging one's head against a brick wall, simple past and past participle banged one's head against a brick wall)
TAKASUGI Shinji (talk) 02:53, 28 December 2020 (UTC)
Why just have the verb inflection? What about noun plurals (heads) and (walls)? And what about other determiners or, at least, articles? DCDuring (talk) 03:34, 28 December 2020 (UTC)
@TAKASUGI Shinji Yes, this is possible. @DCDuring Not sure I see the point of your sarcasm. Benwing2 (talk) 04:05, 28 December 2020 (UTC)
Even with the (clever) template changes to make them easier to code, one could argue that they shouldn't then have separate pages created for them. I also feel they're a bit unnecessary. Equinox 11:54, 28 December 2020 (UTC)
Another potential issue with these: why is the past tense of hunt where the ducks are "hunted where the ducks are" and not "were"? Equinox 15:19, 28 December 2020 (UTC)
Perhaps because the ducks are still there? -- Huhu9001 (talk) 15:40, 28 December 2020 (UTC)
They might not be. I'm saying that the past tense could be either (and for me "were" is more natural). Equinox 15:43, 28 December 2020 (UTC)
@Benwing: What makes verb inflection so interesting a variation of forms in such predicates when variation in, say, number, determiners, prepositions gets neglected? If users need their hand to be held with respect to verb inflection, they must really need help with all the other variations attestable for such an expression. If they DON'T need help with these other variations, then why do we think they need help with verb inflection, especially when the verb inflection is just a click away. Variation in word selection (determiners, prepositions) is not available so conveniently. DCDuring (talk) 21:17, 28 December 2020 (UTC)
@Equinox, Huhu9001 Fixed tense of hunt where the ducks are. @DCDuring Verbs are a lot more complex in English than are any other parts of speech, so I think it's justified to show the inflections explicitly. I also don't really get your point about other variations being "neglected"; bang one's head against a brick wall even comes with a usage note indicating some common variations. Benwing2 (talk) 06:27, 29 December 2020 (UTC)
The problem with the partial inflection of elaborate predicates is not limited to this one. Having hundreds of character-long inflection (multi-)lines makes it harder to keep one's bearings when looking at the entry. Most of these elaborate predicate entries don't have usage notes discussing the range of variation. I wonder whether entering one of the variations other than inflection would even find our main entry for such a long predicate. And the ease of applying the template means that few are ever likely to consider whether the inflected forms occur other than rarely or even at all. In short I find these long inflection lines aesthetically ugly, distracting to users, likely to facilitate misleading impressions of the common usage of idioms, and unhelpful with respect to the actual range of variation. I could imagine a more helpful inflection line that showed possible or likely variations for each component term when the user hovered the cursor over the element show in the lemma inflection line. This has the flavor of something that is added because it was (relatively) easy, not because there is a user-based need. DCDuring (talk) 17:39, 29 December 2020 (UTC)
@Benwing2: I have re-added the alternative past tense form “hunted where the ducks are”, with a quotation of it. J3133 (talk) 15:26, 29 December 2020 (UTC) Also “hunting where the ducks were”. J3133 (talk) 15:35, 29 December 2020 (UTC)
@Equinox: I believe such potential issues in general, regarding there being more than one possible variation of a particular inflection, are solved by the amazingly detailed documentation at Template:en-verb/documentation#Multiword_expressions_with_irregular_verbs, and I think the last three example sentences of that section really show that this is okay (and so, @Mihia, it seems that inflections to multi-word phrases are a normal thing on Wiktionary): (1) rock and roll (verb); (2) reap what one sows; and (3) know which side one's bread is buttered on. Turns out, each verb in the phrase can be inflected separately as needed, and that's not a problem. Just my two cents though, I'm relatively new here, I might be mistaken. Whether or not it is necessary, beats me, because somehow it is and also isn't. (Also, to be honest, I have no idea about there being a previous discussion about inflections to multi-word phrases. I would like to read that discussion if anyone still remembers where it is.) --Bismabrj (talk | contribs) 16:33, 29 December 2020 (UTC)

Reorganisation of Slavey (den)[edit]

I propose that either the languages North Slavey (scs) and South Slavey (xsl) be placed as descendants of Slavey (den) [This follows how e.g. Cree languages are classified as of now on Wiktionary], or - perhaps even better - that Slavey also be re-organized as a proto-language or language family (since obviously any lemma of Slavey is either North Slavey [i.e. Bearlake, Hare and Mountain] or South Slavey). The only current lemma of Slavey (teh) should be moved to either NS or SS teh- in any case, following the provided source, so that shouldn't be an issue. Thadh (talk) 18:07, 28 December 2020 (UTC) If anyone knows any active Athabaskan contributors, feel free to ping them on my behalf

It sounds like you're saying that Slavey, North Slavey, and South Slavey are not three distinct languages, but only two. In that case, either (1) Slavey should be deprecated as a language and instead be made a language family, or (2) North Slavey and South Slavey should be deprecated as full languages and instead be made regional dialects of Slavey (perhaps also etymology-only codes if necessary). For me, one important factor in making the decision is how similar NS and SS are orthographically. If we had entries for, say, all Swadesh-list words in both lects, what percentage of them would be spelled the same? If there's a large overlap, I'd be inclined to treat Slavey as a single language with two dialects. If there's relatively little overlap, I'd be inclined to treat Slavey as two languages. —Mahāgaja · talk 08:47, 30 December 2020 (UTC)
From what I understand, Slavey consists of four major dialects (Bearlake, Hare, Mountain and (South) Slavey), which in turn have significant internal variation. Rice (1989) states that the outer ends of the dialect chain may not be mutually intelligible, which is an important factor here. I don't see much difference per se between South Slavey and the other dialects, so I wouldn't oppose splitting the three Northern dialects. I don't see much merit in merging the dialects however, because the variation seems large enough (especially for more complex words than dene (man)) to create a far too great amount of alternative forms and/or synonyms (as is the case with e.g. North Frisian) to be productive. Thadh (talk) 12:45, 30 December 2020 (UTC)
That does indeed sound like an argument for changing den to a family and recognizing only scs and xsl, or even for deprecating scs creating three ad hoc codes for Bearlake, Hare, and Mountain. However, since we apparently don't have any entries for North Slavey yet at all, that doesn't seem to be a particularly urgent priority. I notice that w:Slavey language mentions "Slavey proper" and distinguishes it from Bearlake, Hare, and Mountain, so I assume that "Slavey proper" means South Slavey? —Mahāgaja · talk 13:45, 30 December 2020 (UTC)
Slavey Proper is the same as South Slavey. I could add quite a lot of North Slavey lemmas following {{R:den:Rice:1989}}, but it may not be a good idea yet if the language is to be split. Furthermore, if I or anyone else am to add the etymologies and Proto-Athabaskan reconstructions, the question of Slavey being a family is more critical (for now, I have added it as if it were at Proto-Athabaskan *tuˑ, but that may need changing). Thadh (talk) 13:59, 30 December 2020 (UTC)
Speaking of the word for 'water', the only entry in CAT:Slavey lemmas is teh. Which dialect is that? It isn't listed at Proto-Athabaskan *tuˑ. As for whether Slavey is a family, is there any doubt that the NS and SS dialects are more closely related to each other than they are to other North Athabaskan languages? Or could this be a case like Northern Paiute and Southern Paiute, where the conventional English names are misleading because each have closer relatives than each other? —Mahāgaja · talk 15:08, 30 December 2020 (UTC)
NS and SS are undoubtedly closer to each other than to others, since they form a continuum and are often considered one language (namely Slavey).
As for teh, see my first message: no such word is mentioned in the presented source, rather the prefix given is teh- (related to water), shared by all dialects and used in multiple derivatives, such as Bearlake North Slavey tehwáa (mink) and South Slavey tehk’ái (muskrat). Thadh (talk) 16:44, 30 December 2020 (UTC)
Then I see no reason not to make den a family. —Mahāgaja · talk 20:55, 30 December 2020 (UTC)

Operation of "supermajority" voting rule[edit]

According to the vote at Wiktionary:Votes/2019-03/Defining_a_supermajority_for_passing_votes:

A vote passes if the ratio of supports to the sum of supports and opposes reaches 2/3 or more. A vote where that ratio does not reach 50% should be closed as "failed"; a vote that has at least 50% but less than 2/3 should be closed as "no consensus".

Suppose that we presently do X, but this is disputed, and, in fact, 15 people want to stop doing it, while 10 want to continue. Suppose we vote on whether to "Stop doing X". 15 supports, 10 opposes, no consensus, so no change, and we carry on doing it. Correct? On the other hand, suppose we vote on whether to "Continue doing X". 10 supports, 15 opposes, what happens then? Mihia (talk) 18:22, 28 December 2020 (UTC)

I came across this question here already. Can't remember who asked. It was something about a "negative vote" or "reverse polarity vote." People like me would call out the person setting up the vote on it. We'd say the status quo must never be threatened by default. We'd even go as far as changing the wording of the vote. Additionally, who starts a vote to find out if everything should stay the same? — Dentonius 19:49, 28 December 2020 (UTC)
There is no rule that I am aware of to say that a vote must be of any particular polarity. If this was intended then it should have been stated as part of the supermajority rule. There is presently no basis that I am aware of on which to "call out" someone who, let's say, in the situation of dispute about doing X, supports doing X and creates a vote on "Continue to do X" in the hope of resolving the dispute by its passing. Unless someone can point out some aspect of this that I have missed, it seems clear to me that the "supermajority" rule is fundamentally flawed and needs to be revised (possibly so as to also somehow stipulate polarity of vote, or require a majority to change the status quo, if that was the original intention, though this could also create an issue of who decides what is the status quo.) Mihia (talk) 20:00, 28 December 2020 (UTC)
I don't think it's flawed. I think it's perfectly fine. It makes it harder for people to impose their will by forming small collectives. Besides, in your recently concluded vote, didn't I comment on this aspect of your vote? Didn't we correct it together? I'd say the system works. — Dentonius 20:06, 28 December 2020 (UTC)
With respect, I think you fail to see or understand the problem. Mihia (talk) 20:07, 28 December 2020 (UTC)
I think you're making up a problem that could easily be resolved by rewriting a vote before it goes live. You can, of course, create a bureaucratic vote to clarify this issue, but I don't really see the point of it. —Μετάknowledgediscuss/deeds 20:09, 28 December 2020 (UTC)
"resolved" to whose benefit? The person who wants to do X or the person who wants not do X? I must repeat again the "unless I am missing something" caveat, but no, in the absence of that, I definitely am not making up a problem. The asymmetry of the supermajority rule, without any stipulation about the "direction" of "support" or "oppose", makes the rule purely nonsensical. Mihia (talk) 20:14, 28 December 2020 (UTC)
I understand what you're saying Mihia. But here are a few questions for you: (1) What kind of person would abuse it? (2) What would it take for such a thing to go unnoticed? (3) Would such a person even have support from the general community? — Dentonius 20:18, 28 December 2020 (UTC)
(1) It's not a question of "abuse". It is something that can happen even unwittingly, just on the vagaries of how someone phrases a vote. Look at my example. (2) Apparently not much, since the "supermajority" vote happened nearly two years ago, and no one has apparently noticed the "fatal flaw" until I did. Mihia (talk) 20:21, 28 December 2020 (UTC)
Dentonius is asking what it would take for the community not to notice that a vote was written with an unexpected polarity. —Μετάknowledgediscuss/deeds 20:31, 28 December 2020 (UTC)
Which vote in my original example is "unexpected polarity"? Mihia (talk) 20:38, 28 December 2020 (UTC)
The example is an abstract generic one. In other words, it is not an example. An example could be an attempt to formalize the lemming principle by something like “Do not delete terms that are included in at least three major dictionaries”. However, if such a vote was to be proposed in this negative form, it will politely be pointed out to the proposer that they should instead formulate a positive proposal to change the wording of WT:CFI. Rather obviously, I hope, the failure of the proposal as originally negatively formulated would not mean we should turn Wiktionary into a repository of obscure words hardly attested in any language by deleting all terms found in at least three major dictionaries. In general, a proposal to be voted on should have the form of “Effectuate some (concretely specified) change”, and not “Leave things as they are”. The failure of a proposal should always mean, “No change – leave things as they are”.  --Lambiam 03:24, 30 December 2020 (UTC)

CFI for appendix-only conlangs[edit]

Please take a look at this proposed vote. It aims to settle exactly what attestation requirements apply to appendix-only constructed languages, by setting a lower standard (one use) so that we don't have to lose that content, but can also avoid unused words. —Μετάknowledgediscuss/deeds 22:36, 30 December 2020 (UTC)

I would have suggested a different compromise between the criteria for WDLs and LDLs: either a mention in an official/authoritative source or three durable uses. The current proposal allows nonce creations singly attested on Usenet but prevents 'official' vocabulary from being included (note that "not durably used" does not equal "not used anywhere"). I don't think it is a good idea to exclude any of the 120+ official words of Toki Pona but include obscure fan coinages with fewer than three uses. I think a more restricted approach is okay in an extreme case like when a conlang's academy has published a dictionary of 10,000+ unused words, but I prefer to treat those as special cases. ←₰-→ Lingo Bingo Dingo (talk) 14:27, 31 December 2020 (UTC)
@Lingo Bingo Dingo: How would you recommend avoiding the "special cases" with your proposed rule? Can you find any official Toki Pona words that would be excluded? (I can't.) Why is 'official' vocabulary that's never used (i.e. nonce creations by a dictionary-writer) more valuable than fan coinages that are actually used? —Μετάknowledgediscuss/deeds 18:48, 31 December 2020 (UTC)
Heuristically it shouldn't be difficult to determine which languages have huge official wordlists; action can be taken on that basis (ideally by the editors active in a language).
Which Toki Pona words can be durably attested? When I search for '"akesi" toki pona' I don't see anything that seems durable.
Official vocabulary is more likely to be found and used by language users than a durably used coinage on a deserted newsgroup. The content of our appendices is somewhat odd stuff anyway (for instance there is one for unattested protologisms), so I don't mind it if the conlang appendices are less descriptive than the mainspace should be. Again, use and durable use are not identical. ←₰-→ Lingo Bingo Dingo (talk) 15:09, 1 January 2021 (UTC)
@Lingo Bingo Dingo: Re “Which Toki Pona words can be durably attested?”: Is Sonja Lang’s book Toki Pona: The Language of Good not durably archived? J3133 (talk) 16:00, 1 January 2021 (UTC)
@J3133 It probably is durable, but the uses should not be example sentences from a textbook. Use in longer stories like reading exercises is probably fine. ←₰-→ Lingo Bingo Dingo (talk) 20:01, 1 January 2021 (UTC)
@Lingo Bingo Dingo: The problem you raise with durable vs nondurable use is valid (and it's why we have e.g. English COLAtard but not some Twitter slang). Besides the exceptions that would need to be identified, a problem with your approach that has just occurred to me is the uncertainty in US law concerning whether conlangs can be copyrighted. If we copy a dictionary wholesale, this could be an issue, but if every word is supported by an actual use, I think we should be safe, though IANAL. —Μετάknowledgediscuss/deeds 20:32, 1 January 2021 (UTC)

Besides the problem of durability (which is, I think, broader than the conlangs problem and therefore a separate issue), there is the issue of who will track down quotes. It has been mentioned several times before that a great many if not most of the entries in some constructed languages may not survive RFV, but nobody bothers. So maybe instead of requiring the existence of durably archived quotes (as we do now), we should require those quotes to be present here on Wiktionary. That way there is no need for lengthy (and often interminable) RFVs, and entries without quotes could be deleted right away. (Although I guess some grace period should be allowed.) MuDavid 栘𩿠 (talk) 03:11, 4 January 2021 (UTC)

Switching from existence of cites to presence of cites would be a radical change in the way we do things here. If there is a problem with RFV, it is that relatively few people are willing to help out. I think the practice of sending entries to RFV rather than simply deleting them is fundamentally sound. —Μετάknowledgediscuss/deeds 04:15, 4 January 2021 (UTC)

January 2021

Transclude thesaurus pages to display synonyms[edit]

Module:thesaurus provides a tool to transclude thesaurus pages to display synonyms in all languages (hopefully). With this, editors will no longer need to repeat adding the same synonym list to each individual entry. They can just keep the list in a single thesaurus page. (This idea was inspired by Template:zh-syn-saurus.)

An example of how to use it is given here:

Please share your opinion of whether this new tool is worth a go or how to improve it. give up -- Huhu9001 (talk) 10:35, 1 January 2021 (UTC)

  • I prefer the one line format including the most common or closest synonyms, optionally ending with a link to the thesaurus. The examples take too much space. Vox Sciurorum (talk) 11:14, 1 January 2021 (UTC)
  • I agree with Vox, this is a step backwards. – Jberkel 09:39, 4 January 2021 (UTC)

Old Latin entries[edit]

Per Wiktionary:Votes/2019-08/Abolish the Old Latin header, the “Old Latin” header has been abolished on 14 September 2019. Nevertheless, there are still Old Latin entries (see Category:Old Latin language). J3133 (talk) 15:36, 1 January 2021 (UTC)

@J3133, Fay Freak In order to get rid of them, how should we do it? I propose at least (a) Old Latin should be an etymology-only language; (b) there should be an 'Old Latin' label. Words like duenos and deivos are pretty far from standard Latin and should clearly be distinguished as Old Latin, IMO. Benwing2 (talk) 04:50, 5 January 2021 (UTC)
Is 𐌃𐌖𐌄𐌍𐌏𐌔 seen in the head right? If the letters are mirrored, shouldn’t this be written right-to-left 𐌔𐌏𐌍𐌄𐌖𐌃?  --Lambiam 11:34, 5 January 2021 (UTC)
@Benwing: The label is already used, e.g. in Divana, and entries are added into Category:Old Latin similar how there's Category:Medieval Latin. -11:55, 5 January 2021 (UTC) —⁠This unsigned comment was added by 2003:de:373f:4000:4d99:f4d5:92d:4559 (talk).
Should Old Latin entries not have {{la-IPA}} because the pronunciation was different (most in Category:Old Latin use {{la-IPA}}, whereas those in Category:Old Latin lemmas have different pronunciations)? J3133 (talk) 13:07, 5 January 2021 (UTC)
 @Benwing2: The main reason I moved to abolish the Old Latin header was the noxious definition. Plautus is Old Latin, and what was aimed at was even older Latin, pre-Livius Andronicus Latin, Early Latin, mainly found in now hard to understand inscriptions, and calling this just Old Latin, as all pre-Classical Latin is called, is an understatement. I have no objection to correct labelling. Whereas I am not sure that Old Latin and Early Latin etymology-only language codes would be useful: For what would be derived specifically from the Latin when the Empire of Rome was still small? Nor would one use the designations Early Latin and Old Latin in descendant trees – although on the other hand, since we already have many codes for later Latin, Late Latin, Medieval Latin, Renaissance Latin and so on, it is logical to have codes for Classical Latin, Old Latin and Early Latin – but meseems nobody has deemed them needed.
@J3133: I can’t think of notable pronunciation differences from Early Latin to Classical Latin standard pronunciation, you would need to elaborate that. Of course one could restrict the template to not spit out ecclesiastic pronunciations, yet I have never found such pronunciation issues in Latin anyhow pressing since I always opined that the pronunciation section tells the reader how a word would be pronounced according to a certain imaginated standard not how it actually was pronounced – the reader would have to derive from date of use of the word which pronunciation is applied and it’s patronizing to rule out certain pronunciations which the 21st century reader would transmit a word in because it does not fit the period of use. We also have Modern Egyptological pronunciations in Egyptian entries, you see … Fay Freak (talk) 16:08, 5 January 2021 (UTC)
@Fay Freak: E.g., the entry linked above (duenos) has {{IPA|itc-ola|/ˈdwe.nos/}} (IPA(key): /ˈdwe.nos/) in its pronunciation section. Using {{la-IPA}} ({{la-IPA|duenos}}) instead would result in a different pronunciation:
J3133 (talk) 16:20, 5 January 2021 (UTC)
@J3133: I deem /dw/ correct, otherwise we would not obtain /b/ in Classical forms. So you pass to {{la-IPA}} dvenos or dwenos to get this result; as {{la-IPA}} expects u is a vowel and not a semiconsonant. Fay Freak (talk) 16:29, 5 January 2021 (UTC)
@Benwing2: I have now merged the bloodclat mess of entries. Some 400 uses of the code itc-ola are left, deployed mostly for etymologies copied without sense of proportion and probably no understanding what Old Latin would mean – this bit of removal now just strengthened my observation that the deletion of Old Latin as a header and as a code is right – and that should rather end at Latin, so you can perhaps replace these occurrences by bot, ending them at Latin with added {{dercat}}, whereas when it occurs in Latin entries one can replace the coded wording “from Old Latin blabla” with ”from older {{m|la|}} …”; we may then check the bot’s edited pages for nonsense and then one can remove the language code from the language module data, perhaps catching the rest with a list of all occurrences or with Cat:E. Fay Freak (talk) 20:33, 5 January 2021 (UTC)
@Fay Freak I would prefer to make itc-ola be an etymology-only language with Latin as its parent. No need to eliminate it entirely. Benwing2 (talk) 05:19, 6 January 2021 (UTC)
@Benwing2: Why, there is insufficient terminology. I distinguished between Old Latin and Early Latin when replacing, but now I find Early Latin also means even Terence. But it would be more needed to bring out that hard-to-understand inscriptional Latin than the 3rd to 1st century BCE which is not all that different from the Imperial-Era Latin that sometimes even imitated this Old Latin (Sallust). The intended thing is called in German Frühlatein as opposed to Altlatein from the mid 3rd century to the beginning of the 1st century BCE. If you don’t have certain names for the language states than you can’t have any codes. The Wikipedia article Old Latin is not helpful here and we have to wean from it. As always Wikipedia mushed together heterogeneous stories from different authors under a headword without understanding because thinking about the definitions would be POV or something like that – you know the ting, Wikipedia is not a dictionary and concerned with pointing at the objects more than the correct or unequivocal ways of designating them. You see I think that people cling towards this Wikipedia picture too much, and I didn’t, as we should first know what lects there are that we want to describe and then we can name them. Similarly I judged about the Aramaic question. It’s technically too much a lumping header but splittings proposed must be maintainable with consistency. Fay Freak (talk) 06:18, 6 January 2021 (UTC)
@Fay Freak As usual your writing is not a beacon of clarity :) but I think you're proposing splitting "Old Latin" into two periods, which I agree with. I would call them "Old Latin" and "Early Old Latin", which makes it clear that "Early Old Latin" precedes Old Latin. We can have two etymology languages, itc-ola and itc-eol, both of which have Latin as the parent. I can fix the inherit code so that a Latin term can inherit from itc-ola or itc-eol. We'd have labels Old Latin and Early Old Latin which categorize respectively into Category:Old Latin and Category:Early Old Latin. Benwing2 (talk) 07:25, 6 January 2021 (UTC)
@Benwing2: That sounds better already, although it would be problematic that now you still don’t have a proper name of Altlatein, or you actually call it Old Latin, I am not utterly sure how you mean it: anyway it’s ambiguous whether with Old Latin you mean the the mid 3rd century to the beginning of the 1st century BCE or anything from the 1st century BCE backwards of which then Early Old Latin is a part (which is suggested by the wording “Early Old Latin” containing “Old Latin”, so it is not clear Early Old Latin precedes Old Latin). I honestly don’t try to be stupid but it is important other editors do not confuse what we come up with. You would of course add a description to the category Category:Old Latin of what it is supposed to be used for but then people would reasonably complain it’s arbitrary and intransparent because the language names in the dictionary pages (which most readers read alone) shouldn’t be misleading in the first place.
I still uphold the notion that many etymologies now containing “Old Latin” should end at Latin, because that’s the first blue link and because the wording “Old Latin” was unreliable in what is being meant. Fay Freak (talk) 14:25, 6 January 2021 (UTC)

Extended mover right[edit]

Hello and a happy new year to all. I am seeing many entries with wrong title lately, I'm moving them with redirects, I'm bringing them to WT:RFD and tagging the left over redirects for imminent deletion. If I am given this right, it would really help as I'd be able to straightaway move the page without a redirect instead of moving it first and then requesting its deletion. Thanks and regards - द्विशकारःवार्त्तायोगदानानिसंरक्षितावलयःविद्युत्पत्त्रम् 16:51, 1 January 2021 (UTC)

I suggest that you personally address this matter to some administrator. inqilābī inqilāb·zinda·bād 19:48, 6 January 2021 (UTC)
@AryamanA Can I be given this right? Thanks, 🔥ब्दशोधक🔥 16:32, 7 January 2021 (UTC)
@शब्दशोधक: Sure, I don't see the harm. —AryamanA (मुझसे बात करेंयोगदान) 02:08, 9 January 2021 (UTC)
  • @AryamanA: I asked about this privately to you, would you consider re-granting me the right if I don't abuse it? Also, I didn't really do anything wrong because I deleted pages ( only marked by patrollers). Regards. 🔥𑀰𑀩𑁆𑀤𑀰𑁄𑀥𑀓🔥 05:35, 10 January 2021 (UTC)
@AryamanA, शब्दशोधक: I am seeing posts on शब्दशोधक‘s user talk page indicating that the user was recently blocked by @Chuck Entz (the reason was not evident from what was on the talk page), and concerns over a number of the user’s edits. I think further inquiry is required before any rights are granted. — SGconlaw (talk) 06:32, 10 January 2021 (UTC)
@Sgconlaw: You can, of course check the block log for the reason but I will tell it straightway - Abusing multiple accounts, block evasion : Impersonating an IP vandal. However, you should read User:शब्दशोधक/पुराचर्चापृष्ठम्#Block? to understand what actually happened - in short, someone else accessed my account and did it. Regarding the concerns about my edits - they are only about my Prakrit entries. 🔥𑀰𑀩𑁆𑀤𑀰𑁄𑀥𑀓🔥 07:31, 10 January 2021 (UTC)
Both the block logs for Dviśakāra and शब्दशोधक showed "No matching items in log" the last time I checked. Since @Chuck Entz knows more about what is happening, I will leave it to him to comment. I was just flagging up what I saw on your talk page. — SGconlaw (talk) 07:35, 10 January 2021 (UTC)
@Sgconlaw: See [2]. 🔥𑀰𑀩𑁆𑀤𑀰𑁄𑀥𑀓🔥 07:59, 10 January 2021 (UTC)
Thanks. I see that I filled in the log request form wrongly. — SGconlaw (talk) 09:38, 10 January 2021 (UTC)
I'm afraid I don't see any clear resolution of the matter from the discussion. I'll defer to @Chuck Entz who is more familiar with it. — SGconlaw (talk) 13:29, 10 January 2021 (UTC)
Well, in itself it's not much, but it's part of a long pattern of variations on "I'll never make that mistake again". This user tends to blithely launch out into new things without any thought about what could go wrong. What's more, they don't seem to notice any problem until it's pointed out to them. It's true that they will then take it to heart and very rapidly correct how they do things, but I simply don't trust them when they say they know what they're doing. Yes, they won't make the same mistake again, but there are an infinite number of ways to do things wrong, and they seem to have a knack for finding new and creative ways to unintentionally wreak havoc... Chuck Entz (talk) 06:31, 11 January 2021 (UTC)
@Chuck Entz: Would you please consider granting me this right? Thanks. 🔥𑀰𑀩𑁆𑀤𑀰𑁄𑀥𑀓🔥 17:14, 15 January 2021 (UTC)
@Sgconlaw: Please consider re-granting me this right, it won't be abused. 🔥𑀰𑀩𑁆𑀤𑀰𑁄𑀥𑀓🔥 11:16, 21 January 2021 (UTC)
No. You are not getting the right back. —Μετάknowledgediscuss/deeds 17:09, 21 January 2021 (UTC)

I, on the other hand, would like to get that extended mover tool. Seems practical. (AND no one's ever complained over any pages I've moved) Allahverdi Verdizade (talk) 17:24, 21 January 2021 (UTC)

Simplified form of 嗰 (and simplification by analogy in general)[edit]

@H2NCH2COOH has recently changed the simplified forms of words with 嗰 from 𠮶 to 嗰, making 𠮶 a nonstandard simplified form of 嗰. Their argument is that 𠮶 is not standard because it is simplified by analogy even though it is not allowed by 简化字总表 (predecessor of 通用规范汉字表). This has led to a bit of discussion on their talk page and mine. I'm wondering how we should proceed: (1) keep it as it is, with 嗰 being the "standard"/default simplified form and 𠮶 labelled as nonstandard, or (2) have both be shown as "valid" by having 嗰 in |s= and 𠮶 in |s2= of {{zh-forms}}. Pinging @RcAlex36, Suzukaze-c, Mar vin kaiser, Atitarev, 沈澄心, 恨国党非蠢即坏 for thoughts. — justin(r)leung (t...) | c=› } 08:29, 2 January 2021 (UTC)

I think both characters (嗰 and 𠮶) should be given equal, valid status as alternative simplified forms. --Anatoli T. (обсудить/вклад) 08:41, 2 January 2021 (UTC)
No particular opinion. —Suzukaze-c (talk) 08:46, 2 January 2021 (UTC)
I am the one who made this change. Explanation of why 𠮶 is nonstandard can be found on . --H2NCH2COOH (Talk) 09:16, 2 January 2021 (UTC)
Pinging @RcAlex36, Mar vin kaiser, 沈澄心 for response. If you don't have an opinion, like Suzukaze-c, please say so, so we kind of know what the community thinks. @H2NCH2COOH has been continuing to make other similar edits like at 𡅏. As I've said at before, the issue here is that we are privileging analogized simplified forms allowed by 简化字总表 even if they are not part of 通用规范汉字表, which may be problematic until we indicate in {{zh-forms}} whether a form is in 通用规范汉字表. — justin(r)leung (t...) | c=› } 05:15, 14 January 2021 (UTC)
@Justinrleung: I'm leaning towards option (1). However, we would have to add a special note that explains why these "non-analogizable" simplified forms are considered non-standard on Wiktionary. We would also have to note that 𠮶 is attested despite the fact that 嗰 cannot be simplified by analogy per 简化字总表. As I understand it, 無限類推 is undesirable and messy. RcAlex36 (talk) 06:28, 14 January 2021 (UTC)
No particular opinion too. -- 08:48, 14 January 2021 (UTC)
@RcAlex36, 沈澄心: Thanks for responding. When we come to some consensus, I think it's best that we put guidelines at WT:AZH so that we know what to do with characters that aren't found in 通用规范汉字表. — justin(r)leung (t...) | c=› } 22:42, 14 January 2021 (UTC)

"Schröderization" as WOTD?[edit]

The word Schröderization was nominated as a Word of the Day by @Illegitimate Barrister. I've done a Google Books search and it is verifiable. However, is it too controversial to be a WOTD? It has a derogatory sense, and refers to a living former politician (though it appears that his actions that led to the word have been widely criticized – and so tough luck to him?). If it is not too controversial, would it be inappropriate to feature the word on Gerhard Schröder's birthday, or should we definitely feature it on a different date? I look forward to your comments. — SGconlaw (talk) 08:31, 3 January 2021 (UTC)

I like featuring fringe words, but this one is a bit too obscure and specific, it doesn't seem to get used much outside of the initial context (Schröder's deals with Russia). I don't think there's a problem with it being too controversial. – Jberkel 09:33, 4 January 2021 (UTC)
Well, we have been featuring other words which are somewhat obscure (in the sense of not being in very common use). Since there aren’t many objections, I’ve gone ahead and listed the word as a WOTD on Schröder’s birth anniversary. — SGconlaw (talk) 06:35, 10 January 2021 (UTC)

German 2nd person past subjunctives[edit]

(Notifying Matthias Buchmeier, Kolmiel, -sche, Atitarev, Jberkel, Mahagaja): Not sure if this belongs here or elsewhere. I am cleaning up the German verb templates, which are a mess. So far I have created Module:de-verb and {{de-conj-table}} to replace the old {{de-conj}}. Eventually I will expand Module:de-verb to do automatic conjugation and replace the old flawed, half-written Module:de-conj. I have a question though about 2nd person past subjunctives. The forms as listed are e.g. du wärest, ihr wäret and du begäbest, ihr begäbet but I have come across also du wärst, ihr wärt and du begäbst, ihr begäbt. Are these latter forms standard? Should they be listed (possibly with a footnote)? Also what about composed forms like du wärest losgeworden and ihr wäret losgeworden? Should forms like du wärst losgeworden and ihr wärt losgeworden also be listed, possibly with a footnote (or listed as the only possibilities)? Benwing2 (talk) 19:39, 3 January 2021 (UTC)

One other question: For senden and derivatives, does the imperative send (du) exist and should it be listed (possibly with a footnote)? Duden says yes it exists, but our old templates sometimes purposefully omitted it. Benwing2 (talk) 19:41, 3 January 2021 (UTC)
To my fluent but nonnative ear, du wärst and ihr wärt sound completely normal (although I know Duden doesn't prescribe them), but du begäbst and ihr begäbt sound rare and rather poetic. If we're going to be writing footnotes about the past subjunctive anyway, though, we should probably mention that it is very rare in the colloquial language except for wäre, hätte and the modals (würde, könnte, wollte, dürfte etc.) and is usually replaced with the periphrastic construction with würde. So even du begäbest and ihr begäbet sound odd to me, as the usual construction would be du würdest begeben/ihr würdet begeben. —Mahāgaja · talk 20:00, 3 January 2021 (UTC)
@Mahagaja Thanks. Let's see what others say about adding a general past subjunctive note. One other question, about the new (post-1996) spellings kennen lernen, spazieren gehen and similar: Currently the tables have subordinate clause dass ich kennen lerne and zu-infinitive kennen zulernen. Are these correct (especially the zu-infinitive)? I learned German with the old spellings so I have no intuition here. Benwing2 (talk) 20:10, 3 January 2021 (UTC)
dass ich kennen lerne is right, but the zu-infinitive is kennen zu lernen. —Mahāgaja · talk 20:19, 3 January 2021 (UTC)
The past subjunctive is indeed used very rarely in spoken German, often by older speakers, or with some auxiliary verbs, this should be mentioned in the footnotes. It still gets some use in news reporting as indirect speech marker: "sie sagten, sie begäben sich..." The forms begäbt / wärt are acceptable and probably more common than the -et variants. – Jberkel 23:15, 3 January 2021 (UTC)
wärest/wäret/begäbest/begäbet should be labeled as archaisms. When these forms are used they mark a deliberate deviation from everyday language. --Akletos (talk) 09:14, 4 January 2021 (UTC)
@Akletos Thanks, I'll add that when I have a chance. Benwing2 (talk) 04:31, 5 January 2021 (UTC)
(Notifying Matthias Buchmeier, Kolmiel, -sche, Atitarev, Jberkel, Mahagaja): How are the following verbs conjugated? gegenbeschuldigen (ich gegenbeschuldige or ich beschuldige gegen?), endlagern (ich lagere end or ich endlagere? ich habe geendlagert per Collins? ich habe endgelagert per Wiktionary? ich habe endlagert?) Benwing2 (talk) 04:41, 5 January 2021 (UTC)
(Notifying Matthias Buchmeier, Kolmiel, -sche, Atitarev, Jberkel, Mahagaja): Another question, maybe more relevant, concerns stems ending in -s, -x, -z or -ß. dewikt [3] lists the 2sg preterite of e.g. lassen as either ließest or ließt, but the 2sg past subjunctive as only ließest. (We list the 2sg preterite as only ließt.) Are the two preterite forms ließest or ließt equally used, or is one archaic? Does there exist in this case a 2sg past subjunctive of ließt, and if so is the form ließest archaic per User:Akletos? BTW same appears to apply to strong verbs in -sen e.g. preisen and in -zen e.g. schmelzen. Benwing2 (talk) 06:36, 5 January 2021 (UTC)
Verbs that are back-formations from nouns like gegenbeschuldigen (< Gegenbeschuldigung) and endlagern (< Endlager) are often variable in German, with native speakers themselves sometimes being uncertain. Sometimes such verbs show separable-prefix behavior in only some forms (e.g. the past participle babygesittet is OK) but not others (*Ich sitte heute Abend baby is definitely not, it has to be Ich babysitte heute Abend). Sometimes the forms just don't exist: I read a linguistics article once about how the finite forms of uraufführen (< Uraufführung) simply cannot be used in main clauses: *Wir uraufführen heute Abend, *Wir aufführen heute Abend ur, *Wir führen heute Abend urauf are all equally ungrammatical, but Ich hoffe, dass wir heute Abend uraufführen is OK. —Mahāgaja · talk 08:19, 5 January 2021 (UTC)
@Akletos, Benwing2: wärest/wäret/begäbest/begäbet should not be labelled as archaisms, they are the current standard written forms. wärst/wärt/begäbst/begäbt are colloquial, of which wärst/wärt is less marked, as of an irregular verb anyway, but begäbst/begäbt could be marked as errors (A, Ausdrucksfehler) by schoolmasters (more likely than not). Also contrary to what @Jberkel says the past subjunctive is used often enough in spoken German, and I think particularly of moderately formal spoken German e.g. in university, before court and the like – this is the norm to be reflected. I guess in Berlin they don’t learn German anymore, they do Schreiben nach Gehör. Fay Freak (talk) 22:53, 5 January 2021 (UTC)
(Notifying Matthias Buchmeier, Kolmiel, -sche, Atitarev, Jberkel, Mahagaja): @Fay Freak OK, one more question about past subjunctives. I'm writing a module to do automatic German conjugation and I have added a footnote to this module for past subjunctives. It appears there are three categories of past subjunctives:
  1. Verbs where the synthetic form is preferred over würde + infinitive: haben, sein, können, müssen, dürfen, mögen, sollen, wollen, werden
  2. Verbs where both the synthetic form and würde + infinitive forms are frequent: brauchen, finden, geben, gehen, halten, heißen/heissen, kommen, lassen, stehen, tun, wissen
  3. Verbs where the synthetic form is rare compared with würde + infinitive, and highly formal: all the rest.
My questions are (1) are any verbs miscategorized here? (2) are any verbs missing from categories (1) or (2)? (3) what about compounds of the above verbs, e.g. spazieren gehen/spazierengehen, abkönnen, auslassen, wehtun, etc.? Do they behave the same as the base verb, or are they in category (3)? Benwing2 (talk) 05:29, 6 January 2021 (UTC)
@Benwing2: 3) They behave the same. 1) mögen because the meaning is different in the subjunctive which replaces wollen as a more polite form, so “würde mögen” is totally common. “würde haben” also does not sound odd, apparently only with the modal verbs it sounds unusual, brauchen, dürfen, sollen, wollen, müssen, and with werden because of the duplication; and even with those it is not too odd to use würde, so perhaps the distinction between (1) and (2) is unneeded. The synthetic forms are just rare and formal when they are identical to the preterite forms, that is in all weak verbs (also including those with Rückumlaut like kennen and brennen). Else, Berliners might not believe it, we Westphalians also use hülfe as well as stürbe (this latter of sterben does not sound archaizing at all, potentially only hülfe but it is occasionally used in speech). erklimmen, called highly formal here, would be well understood in the subjunctive II erklömme and not frowned upon, and so on with all that is in Category:German strong verbs: The subjunctive II can be used just like würde periphrasis, and even more, in formal speech the periphrasis would be doubtful style. So actually your category 2 should contain most or all all strong verbs and category 3 all weak ones, as stilted forms but none are archaic, in formal speech and writing every subjunctive II is expected. Fay Freak (talk) 15:51, 6 January 2021 (UTC)
@Fay Freak: Should we mention that bräuchte, though widespread in everyday use, is proscribed by prescriptivists and probably better avoided in formal written German? We do already have a note more or less to this effect at brauchen#Usage notes. —Mahāgaja · talk 16:24, 6 January 2021 (UTC)
@Mahagaja: Hö, this prescription is completely unreal. Maybe you read too many prescriptivists? I am not sure I have ever heard brauchte as a subjunctive II, though I have probably read it at some bloggers – it’s so rare that one can think somebody missed the Ä key and it is likely to be mistaken for just the preterite –, and it is now unlikely that bräuchte is ever marked as an error (if only because luckily correctors don’t read as many trashy language materials as you as a non-native speaker naturally have to encounter?). Although the usage without “zu” is likely marked to be wrong, in spite of being consequential with its status as a modal verb, such that I prefer to view the use with zu as pretentious. Fay Freak (talk) 16:41, 6 January 2021 (UTC)

compound vs. affix vs. univerbation[edit]

I created یڭیچری(janissary) as a {{compound}} of یڭی(new) + چری(soldier). @Fenakhay changed the template to {{af}}. Then @PUC changed the template to {{univerbation}}. Are there any guidelines on when to use each template? They all seem to mean the same thing in this case. Vox Sciurorum (talk) 12:56, 6 January 2021 (UTC)

@Vox Sciurorum: I probably shouldn't have meddled in, as I don't know anything about Turkish or Ottoman Turkish. I've simply followed the lead of @Fay Freak, who wrote that یڭیبهار(yeñibahar) is a univerbation. What does @Lambiam think?
However, I was actually just discussing this issue with @Inqilābī at Talk:double penetration. They mentioned the case of wasteland, which is currently categorised as a compound; but seeing that waste is an adjective (per [4]), and that [adjective + noun] phrases don't usually solidify in this way in English (as opposed to [noun + noun] phrases), I think it is best described as a univerbation. PUC – 13:07, 6 January 2021 (UTC)
Thanks for drawing me to this discussion.
@Vox Sciurorum: I think that it is indeed possible to have compound words having an adjective as a component word, and I support categorizing words like یڭیچری‎, wasteland, double uncle etc. as compounds. inqilābī inqilāb·zinda·bād 13:22, 6 January 2021 (UTC)
{{af}} categorizes things as compounds if none of the arguments contains a hyphen (which would indicate an affix), so the choice between {{compound}} and {{af}} is without significance in this case. The question is really whether this is a compound or a univerbation. Without knowing anything about Turkish, Ottoman or otherwise, I'd be inclined to call this a compound. For me a univerbation, unlike a compound, doesn't have a head, i.e. the part that determines both the part of speech and the semantics of the whole: in yeñiçeri, the head is çeri, as yeñiçeri gets both its noun status and its semantics (a kind of soldier specified by the adjective portion of the compound) from çeri. And wasteland is also a compound for the same reason; where did anyone get the idea that we don't have [Adj + Noun] compounds in English? —Mahāgaja · talk 13:30, 6 January 2021 (UTC)
@Mahagaja: I have reverted myself on that Ottoman Turkish entry.
As for [Adj + Noun] compounds in English: I may have been mistaken / not thought this through. But would you really describe items such as genuine article and double penetration as "compounds"? PUC – 13:42, 6 January 2021 (UTC)
This is more like blackbird and headland than those examples. It's not that you can't have Adj + Noun compounds, but that those particular examples aren't Adj + Noun compounds. Chuck Entz (talk) 14:25, 6 January 2021 (UTC)
@Chuck Entz: So what do you think of words like double dribble, double Dutch, true blue (noun), true love etc. These should certainly qualify as compound words. @Mahagaja. inqilābī inqilāb·zinda·bād 20:13, 6 January 2021 (UTC)
Well it probably was at one point just “new soldiers”, not “new-soldiers”. It’s written apart even, or with zero-width joiner or non-breaking half-space, in Redhouse’s dictionary linked under چری‎ as opposed to together at یڭیچری(janissary), both equally common. So if at some point it was adjective + noun, it later does not become a compound but an univerbation – that’s my understanding of an univerbation at least …
You are right to observe that in Turkish the distinction between derivation, compounding and univerbation is formally particularly intransparent; only luckily there are only few proper Turkish prefixes, but in Ottoman there must have been more Persian ones autonomously employed, where with some then one could doubt whether it is rather a compound with an adjective or adverb or an univerbation so there are three possibilities, and the varying spelling یكیچری‎ ~ یكی‌چری‎ seems to show that the Ottomans themselves looked varyingly upon this word. Fay Freak (talk) 14:49, 6 January 2021 (UTC)
The components are not of Persian origin. Originally, the term yeni çeri (“the new military corps”) must have been a completely transparent adj + noun combination, also (in spoken form) to illiterate speakers of kaba Türkçe. (For a collective sense of çeri, see e.g. here. The term probably underwent a similar sense development as English police, in which the collective term was re-interpreted as an unmarked plural of a count noun.) Neither component can reasonably be considered an affix. The primary stress on the first component (/jeˈni.t͡ʃe.ɾi/) is typical for adj + noun combinations that solidify to lexical units; cf. karakuş /kɑˈɾɑ.kuʃ/ vs. kara kuş /kɑˌɾɑ ˈkuʃ/.  --Lambiam 17:08, 6 January 2021 (UTC)
Let me add that in the Redhouse Çağdaş Türkçe-İngilizce Sözlüğü (Redhouse Contemporary Turkish–English Dictionary) (1983) the entry for çeri is simply “çeri  (hist.)  army, troops.”  --Lambiam 16:00, 7 January 2021 (UTC)

Yeniçeri is a compound, not a univerbation. {{af}} handles it correctly. On another note, I do not think diacritics such as three dots over the kaf should be used in the pagename to indicate the /ŋ/. This kind of spelling was found almost exclusively in dictionaries. It can be added as alternative spellings. The transliteration should feature /ŋ/, though. Allahverdi Verdizade (talk) 10:41, 13 January 2021 (UTC)

I followed the policy in Wiktionary:About Ottoman Turkish both for consistency and because I have no specialized knowledge of my own to bring. (I only add entries in obsolete languages when they are particularly interesting to me as sources of etymology, like the origin of the widespread word janissary, or due to subject matter, like the Germanic words for squirrel I added recently.) By that policy, "the ڭU+06AD ARABIC LETTER NG is used in the place of the old /ŋ/." But checking Redhouse's 1890 dictionary, I see he spells yeñiçeri without the dots. And I've seen vowel marks in some places but not in others. I don't have an opinion on what the rule on Wiktionary should be. Vox Sciurorum (talk) 14:24, 13 January 2021 (UTC)
That page is Fay Freak's essay on his views. Some things there are fine, others are just that, his personal views. Allahverdi Verdizade (talk) 14:40, 13 January 2021 (UTC)
@Allahverdi Verdizade: No, it isn’t. I continued what was started before. There had been entries with گ‎ and ڭ‎, and the page informs about a uniform practice. If I had made the first Ottoman entry on Wiktionary all would look differently. It is incorrect to claim I would be responsible for Wiktionary’s coverage not being “in accordance with the current state of the field”, and if you want a specific thing then you should go for it and tell it. There is nothing to “expect”. Fay Freak (talk) 15:21, 13 January 2021 (UTC)

Suggestion to deprecate Template:ko-syllable-hangul[edit]

An example at 강#Etymology 1.

These are not dictionary material, and they are not necessary because all of the (very little) relevant information is contained in Template:character info anyways. I think they should be automatically removed.--Karaeng Matoaya (talk) 03:00, 8 January 2021 (UTC)

(Notifying TAKASUGI Shinji, HappyMidnight, LoutK, Karaeng Matoaya, B2V22BHARAT, Quadmix77): In general, I agree with @Karaeng Matoaya's proposal. The info, which is somewhat useful is covered by {{character info}}.
Does it actually mean that all Korean entries, which don't have any PoS sections but ====Syllable====, will also be deleted? That should be covered by the proposal because there may objections or they could potentially be usefull. I actually think that perhaps we should have some (very basic) Translingual sections for each Hangeul syllables with {{character info}} at the very top where there is no other sense (no word exists). --Anatoli T. (обсудить/вклад) 05:44, 8 January 2021 (UTC)
I agree that they should be removed. They are not useful anyways. — LoutK (talk) 18:41, 8 January 2021 (UTC)
@Atitarev, I think we can leave entries for definitionless Hangul entries as they are for the time being.
@Benwing2, do you think this could be done automatically (delete all etymology sections which include {{ko-syllable-hangul}} in pages with multiple Korean etymology sections, and renumber the etymology lables)? Or should this be done manually?--Karaeng Matoaya (talk) 01:39, 14 January 2021 (UTC)

Are there any cases where Template:es-IPA shouldn't be transcluded?[edit]

I started adding it to some entries and I was concerned that maybe it wouldn't be able to handle ceceo/seseo or lleísmo/yeísmo, etc. but it seems like a pretty good, flexible template. Since Spanish has a pretty phonetic and reliable pronunciation system, this is going to be accurate 99.99%+, so can anyone tell me why a bot shouldn't add this to every Spanish entry? —Justin (koavf)TCM 09:43, 8 January 2021 (UTC)

Too soon: see Module:es-pronunc/testcases. PUC – 10:20, 8 January 2021 (UTC)
I added a few South American words borrowed from indigenous languages and declined to use {{es-IPA}} for two reasons. I don't know if the Spanish word retains any trace of the pre-Spanish pronunciation. I don't know how to suppress the Castillian pronunciation. Vox Sciurorum (talk) 12:01, 8 January 2021 (UTC)
Why suppress it? Surely even Castilian speakers are allowed to utter words that entered the language in Latin America, just as British speakers have their own pronunciations of English words borrowed from Native American languages. —Mahāgaja · talk 12:35, 8 January 2021 (UTC)
I prefer not to create unattested forms. If somebody from Spain knows how an originally Quechua word is pronounced there, go ahead and add the pronunciation. Vox Sciurorum (talk) 13:41, 8 January 2021 (UTC)
As someone who is not a native, nor a bilingual anglo/hispano, but who knows more than the average person about Spanish and other Romance languages, I've never experienced a Hispanic pronouncing an indigenous term with a phonology outside of standard Spanish. The only loanwords I know of that break this are a few aspirated hs, like in hip hop or sometimes pronouncing a w in words like Kuwaiti (rather than "koo-bay-tee"). Very anecdotal but I'd be interested in knowing if South American Spanish that butts up against living indigenous languages (e.g. Jopara Guarani) have non-Hispanic phonemes. —Justin (koavf)TCM 07:22, 9 January 2021 (UTC)
  • @Jonely Mash: Does the pronunciation that I just added at a dolor seem incorrect to you? —Justin (koavf)TCM 07:27, 9 January 2021 (UTC)
    a dolor's pronunciation is fine. That's why I weasel-worded "possibly" into my sentence :). Jonely Mash (talk) 11:02, 9 January 2021 (UTC)
  • But this does bring up a general consideration, which I don't have the solution for. How we could include LOADS of pronunciations in the template - from Cádiz, Buenos Aires, Uruguay, Chile, Asturias, Cuba, the different parts of México etc. which all have notably different pronunciations. Jonely Mash (talk) 00:51, 9 January 2021 (UTC)
  • While there are differences in pronunciation other than just ceceo/seseo and lleismo/yeismo (e.g. dropped -s in some Central American varieties), I think that Spanish has some fairly predictable pronunciations and the thing that would probably make this much easier than (e.g.) English would be the smaller amount of vowels. Even attempting this for English seems pretty daunting but for Spanish, it seems doable. Maybe I'm just too ignorant of Lua or Spanish phonology. —Justin (koavf)TCM 07:24, 9 January 2021 (UTC)
This module still has many problems. ununquadio is still wrong after I pointed out the error over 2 years ago on the talk page, as are many other issues raised there. I'm happy to do research and work with anyone who offers to refine the module. Ultimateria (talk) 07:55, 9 January 2021 (UTC)
Well, ununquadio was a simple fix. I'd also say we should be careful using the IPA template for obsolete terms, like huviesse, çarça, ortographía. Can we know for sure how they were pronounced? Do we care enough? Jonely Mash (talk) 11:07, 9 January 2021 (UTC)
Only if we take care of everything else first. That's still a temporary solution on ununquadio, but thank you for fixing it. Ultimateria (talk) 18:55, 9 January 2021 (UTC)
Would one of you like to add ununquadio to Module:es-pronunc/testcases so it can be tracked? Or is its issue already covered by an existing testcase? - -sche (discuss) 17:35, 10 January 2021 (UTC)
Yes check.svg Done. Ultimateria (talk) 19:05, 10 January 2021 (UTC)

@Benwing2: I know you already have a lot on your plate, but would you be interested in getting this module up to par? PUC – 17:39, 10 January 2021 (UTC)

@PUC I can take a look. I'm not sure some of the existing pronunciations e.g. of accidental are wrong, though. Wikipedia specifically gives [oβtiˈmista] for optimista, for example. Benwing2 (talk) 17:58, 10 January 2021 (UTC)

Some antonyms seem like a stretch or outrite wrong[edit]

E.g. misandry and misogyny are listed as antonyms. Hating men is not "the opposite" of hating women. In addition to the fact that this seemingly ignores the existence of anyone who is intersex, the opposite of hating [group] is loving [group]. It's not clear to me that these bigotries are complementary, graded, or relational antonyms. Am I just being dense here? —Justin (koavf)TCM 07:48, 9 January 2021 (UTC)

I agree they're not antonyms. I'd call them ====Coordinate terms====. —Mahāgaja · talk 08:24, 9 January 2021 (UTC)
Antonymy is a particularly easy concept to misapply, but coordinate terms isn't so easy either. In both cases there is question of opposite|coordinate with respect to what attribute(s) of the target term. Is brush, mop, or vacuum cleaner the best coordinate term of broom? What is the antonym of broom? Why not vacuum cleaner? It draws dirt in, instead of spreading it. DCDuring (talk) 21:02, 9 January 2021 (UTC)
Can't they all be coordinate terms? —Mahāgaja · talk 22:53, 9 January 2021 (UTC)
Or else cohyponyms: men-hate and women-hate are forms of hate. broom and vacuum are both cleaning utilities. -- 23:10, 9 January 2021 (UTC)
As are dust cloth, soap, sponge, washing machine, dishwasher, buffer, polish, detergent, lint brush, face cloth, carpet sweeper, whisk, swab, nail brush, pressure washer, feather duster, etc. DCDuring (talk) 00:57, 10 January 2021 (UTC)
"What is the antonym of broom?" It has no antonym; not every word has an antonym anymore than every word has a synonym. —Justin (koavf)TCM 00:51, 10 January 2021 (UTC)
I think it was a rhetorical question. PUC – 11:54, 13 January 2021 (UTC)

Use ISO 15919 for Hindi transliteration[edit]

There's an ongoing discussion here regarding updating the transliteration scheme that Wiktionary uses for Hindi (and Urdu) to be compliant with ISO 15919, which is the international standard and the one used on other Wiki sites. Let's continue the discussion there. Getsnoopy (talk) 01:21, 10 January 2021 (UTC)

t:ja-compound auto-categorize affixes[edit]

Just like t:affix, it can check whether a constituent begins or ends with a hyphen and then add categories like cat:Japanese words suffixed with める. Would you like this feature?

(Notifying Eirikr, TAKASUGI Shinji, Atitarev, Suzukaze-c, Poketalker, Cnilep, Marlin Setia1, 荒巻モロゾフ, 片割れ靴下, Onionbar, Shen233): -- Huhu9001 (talk) 13:03, 11 January 2021 (UTC)

Symbol support vote.svg SupportSuzukaze-c (talk) 13:24, 11 January 2021 (UTC)
Symbol support vote.svg Support ‑‑ Eiríkr Útlendi │Tala við mig 08:13, 16 January 2021 (UTC)

Added to Category by Mistake?[edit]

@Tommassammot [5] and [6] added Kyrgyzstan and Nepal to Category:en:Places in China --Geographyinitiative (talk) 01:04, 13 January 2021 (UTC)

I fixed those, but there are lots more with the same problem. Code like <<c/...>> is only for holonyms, that is, places that the subject of the entry is part of, not for coordinate terms, which are things of the same type and part of the same larger grouping. Neighboring countries should be made into simple links with [[...]] or a linking template like {{l}}. It looks like most of @Tommassammot's edits will have to be either fixed or reverted. Chuck Entz (talk) 04:34, 13 January 2021 (UTC)
After going through all of the ones with {{place}}, it turns out to not be as bad as I thought. They mentioned neighboring countries in only a few of them, and those are now fixed. Chuck Entz (talk) 15:10, 13 January 2021 (UTC)

Codifying Western Yughur[edit]

I would like to propose a codification of Western Yugur in order to enable its lemmatization. Western Yugur is not written and there is no standard orthography.
Right now, we have 6 entries in the language, but it could be expanded using Roos (2010)[1]. It is a great source, containing texts and a wordlist, also providing etymologies and cognate lists for most items. The entire work is written in a phonological notation. Using it to lemmatize WY is less desirable for the following reasons. 1) some characters are not really found in unicode, such as LATIN SMALL LETTER S WITH CURL; aspiration is indicated in an IPA-style, with an ascended h; 2) some characters cannot be found for upper case (true for most IPA-inspired characters). 3) some characters are not conventional from the IPA point of view either, such as <ɕ> for /c͡ç/ or <c̨> for /ʈ͡ʂ/.

Therefore, I propose the following system for lemmatization of Western Yugur. There you find a comparative table of characters in Roos (2000), their phonetic values and the characters under proposition. There is also a list of sample words in all three notations and a sample text in the proposed orthography. The benefits of the proposed system are the following:

  • Full phonematicity, which will make the construction of an IPA-module very easy.
  • Closeness to the "Common Turkic alphabet" where possible (this will make comparisons in etymology sections and reconstruction space more easily accessible).

I am open to discuss individual solutions to the different aspects of the system under proposition. If we can agree on a standard spelling, I will take on creation of a core bulk of entries. —⁠This unsigned comment was added by Allahverdi Verdizade (talkcontribs) at 11:12, January 13, 2021 (UTC).


The issue arises for many LDLs. I think that Wiktionary is not, and should not be, in the business of devising or promoting systems of orthography; if we include a term, it should normally be in a spelling that is attested (where the bar for attestation is lower for LDLs).  --Lambiam 16:33, 16 January 2021 (UTC)
As there is allegedly no spelling for Western Yughur - it is not written - we cannot record spellings for this language. The best we can do is record pronunciations! For pronunciations, we should use (uncased) IPA. Recording the lemmas in the IPA seems the most neutral option for recording an unwritten language. --RichardW57 (talk) 00:22, 17 January 2021 (UTC)
How are Wiktionary users most likely to encounter this language? If Roos's system is the most likely, then perhaps we should use his system, and naturally exclude words that are not written in the current repertoire of Unicode. --RichardW57 (talk) 00:22, 17 January 2021 (UTC)
I don't know how Wiktionary users are most likely to encounter this language. Roos (2000) is perhaps the most known work, but there is an important PhD-thesis on the language from 2019[2]. There are earlier dictionaries and collections of texts as well. If you visit glottolog, you will see a more complete list of references. All of them use different notations, even the several papers co-authored by Roos. Allahverdi Verdizade (talk) 08:13, 17 January 2021 (UTC)


  1. ^ Roos, Marti (2000) The Western Yugur (Yellow Uyghur) Language. Grammar, Texts, Vocabulary, Leiden: University of Leiden
  2. ^ Zhong, Yarjis Xueqing. 2019. Rescuing a Language from Extinction: Documentation and Practical Steps for the Revitalisation of (Western) Yugur. (Doctoral dissertation, Australian National University; xxxi+467pp.)

Pali Pronunciation[edit]

I am not keen on attempting to record this, but @Octahedron80 has requested it for citta. Firstly, the ancient pronunciation seems not to be certain - were orthographic clusters of resonant + h murmured or simply clusters as written? Secondly, there are a lot of present-day regional variations, and nowadays even variations due to inconsistent attempts to achieve a more authentic pronunciation.

For example, how do we accommodate the Sinhalese and English failure to sound aspiration and distinguish dentals and retroflexes?

Should we tie pronunciations to scripts, or where possible tie them all to the trans-script (in this case, Latin script) form. For traditional Tai pronunciations, Pali is a tonal language. Phonemically, it should have two tones (etymologically voiceless v. voiced), but the allophones will belong to different tonemes in the speakers' mother tongues, and irregular pronunciations may make some of these differences locally phonemic. How do we handle regional variation in the tones within countries - and do they occur?

We also have the issue that the citation forms do not always occur in the language, or, I suspect, in the script. --RichardW57 (talk) 15:09, 13 January 2021 (UTC).

Appendix:Japanese counters page[edit]

An apparently well-meaning user, Zenkaino_lovelive (talkcontribs), has created this page. I find it bafflingly organized. I think what they're trying to do already exists at Category:Japanese_counters.

@Zenkaino, could you please have a look at Category:Japanese_counters and see if that might already list up the various entries you appear to be collating at Appendix:Japanese counters? If the Category page already does what you need, we should delete your Appendix page. If the Category page doesn't do what you need, could you please explain what you were trying to accomplish with your Appendix page?

‑‑ Eiríkr Útlendi │Tala við mig 08:19, 16 January 2021 (UTC)

Likewise, I think the Appendix:Jōyō kanji by Kanten degree page might be re-creating content we already have somewhere else. @Suzukaze-c, Huhu9001, TAKASUGI Shinji, other Japanese editors, could you check? My bandwidth lately is very restricted, and I likely won't be able to spend any appreciable time on Wiktionary for a while. ‑‑ Eiríkr Útlendi │Tala við mig 08:23, 16 January 2021 (UTC)

@Eirikr: I made the appendices because I think that conjunction of numbers and counters is necessary for foreigners. Also, I think that we should divide Japanese kanji by Kanten degree. These are just my thought, though. Zenkaino lovelive (talk) 08:37, 16 January 2021 (UTC)

@Zenkaino lovelive: No, understanding and learning numbers and counters is necessary. Simply throwing them together in one place without explanation just creates an incomprehensible wall of Japanese characters. I challenge anyone not fluent in Japanese to figure out what information is being presented. Chuck Entz (talk) 08:57, 16 January 2021 (UTC)

Then what is the best? Zenkaino lovelive (talk) 09:00, 16 January 2021 (UTC)

I personally think that the best location is the entry for the counter itself ([7]), but I can't imagine what header would be good for it. —Suzukaze-c (talk) 09:02, 16 January 2021 (UTC)
I think that adding information (when to use the counters) is the best. BTW, @Suzukaze-c, could you correct my errors in Appendix:Japanese counters? I think that there is something incorrect. Zenkaino lovelive (talk) 09:05, 16 January 2021 (UTC)
Well, both "Classifier" and "Counter" are listed as permissible POS headers at WT:EL. Barring those, I would argue against "Noun", which we use for English measure words, because the classifier system is semantically more like the noun class system in many African languages. I would note that we tend to use "Particle" when we can't think of anything else. If you're talking about the header to use to house a list, that's trickier. They're definitely not "Derived terms" or "Coordinate terms", and none of the nyms fit. I guess we would be stuck with "See also". That said, maybe it would be better to have something along the lines of the subcategories of Category:Chinese nouns by classifier, except with information on the semantic characteristics the classes have in common. Chuck Entz (talk) 02:12, 17 January 2021 (UTC)

What's "Kanten degree"? Can't find it on Google. -- Huhu9001 (talk) 12:13, 16 January 2021 (UTC)

Kanten is "漢字検定". Degree is "級". Zenkaino lovelive (talk) 12:48, 16 January 2021 (UTC)
@Zenkaino lovelive: What? Romaji for 漢字検定 is Kanji Kentei. Where is this Kanten stuff? -- Huhu9001 (talk) 00:41, 17 January 2021 (UTC)
@Huhu9001:漢字検定->漢検->Kanken. I've corrected. BTW, could you correct my errors in Appendix:Japanese counters? Looks like there is something incorrect. Zenkaino lovelive (talk) 00:44, 17 January 2021 (UTC)
  • It is totally incomprehensible and meaningless. I would just delete it. SemperBlotto (talk) 12:19, 16 January 2021 (UTC)
Good intentions and efforts but it's not a very useful page. Delete. --Anatoli T. (обсудить/вклад) 05:02, 17 January 2021 (UTC)
Keep. —Suzukaze-c (talk) 07:02, 17 January 2021 (UTC)
Neutral. -- Huhu9001 (talk) 11:43, 17 January 2021 (UTC)
I think that if I add when to use the counters, the appendix will be useful. Zenkaino lovelive (talk) 05:41, 17 January 2021 (UTC)
I've written all when to use the counters. See: Appendix:Japanese counters. Zenkaino lovelive (talk) 08:02, 17 January 2021 (UTC)


Is the label uncountable applied correctly in the def 1.2.1 ("(uncountable, measure word for livestock and game) A single animal."; usage example: 200 head of cattle) in head? The label seems to be used to indicate that head doesn't take a plural-s. The question arose over German Stück, but could be similarly asked for other German measure words (Glas, Meter, and other units of measurement). How should these forms be classified? --Akletos (talk) 07:54, 18 January 2021 (UTC)

I see it as a plural, not uncountable. "100 million head of cattle are..." Equinox 08:22, 18 January 2021 (UTC)
snow (state of water) is an example for something being uncountable, there's no 1 snow, 2 snows, 3 snows. (Well, in technical language there could exist such a plural (Artenplural or Sortenplural) when there are different types of snows, but then it also has another meaning.) --幽霊四 (talk) 11:18, 18 January 2021 (UTC)
Would it be better to write {{lb|en|singular}} => (in the singular)? Vox Sciurorum (talk) 16:11, 18 January 2021 (UTC)
But Equinox's example shows it to agree with a plural verb. I would call it invariant, ie, plural form = singular form.
Snow is both countable and uncountable: "We only got three significant snows last year.". I suppose one could argue that the countable use is informal. DCDuring (talk) 16:19, 18 January 2021 (UTC)
[[head#Noun]] is a great example of the variety or English plurals and (un)countability. It has a conventional plural and an invariant plural for at least one sense. It has senses that are almost always countable and some that are both countable and uncountable. It is probably a mistake to put (un)countable labels on senses rather than subsenses. I am not so sure about the inflection line either, but we have have (un)countability labels there for single-definition nouns and for multi-definition words that are only one or the other. The prospect of reforming the presentation of countability and uncountability for polysemic terms that have some uncountable and some uncountable definitions seems unlikely to generate a consensus or enthusiasm. DCDuring (talk) 17:48, 18 January 2021 (UTC)

User:Liywy is mass-removing Japanese term written in katakana[edit]

@Eirikr, TAKASUGI Shinji: Hi. User:Liywy is mass-removing Japanese terms written in katakana from translations. Please review. --Anatoli T. (обсудить/вклад) 09:48, 18 January 2021 (UTC)

(copying response here:) I for one agree with Liywy that most of these katakana words can be omitted (perhaps not all of them— but some of these are obviously marginal/marked, like エンゼル and フッテージ). —Suzukaze-c (talk) 09:51, 18 January 2021 (UTC)
Individual terms can be disputed but mass-removing valid terms is bad. Even フッテージ (futtēji, footage) or エンゼル (enzeru, angel) can simply be labelled as rare. --Anatoli T. (обсудить/вклад) 10:37, 18 January 2021 (UTC)
Labelling marked/marginal/rare terms seems like the better way (if the terms do exist, of course). Alternatively, the usual term could give uncommon terms as synonyms, but firstly, that doesn't seem like a better way, and secondly, currently 天使 doesn't give エンゼル or エンジェル (both are in アルゼンチン) as synonyms. --幽霊四 (talk) 11:28, 18 January 2021 (UTC)
The ban seems a bit over-hasty. — Mnemosientje (t · c) 14:56, 18 January 2021 (UTC)
Well, they are given as synonyms for "angel", not for "Argentina" on that oage. You can also view some Japanese dictionary entries: https://ejje.weblio.jp/content/エンゼル and https://kotobank.jp/word/エンジェル-1847#E7.B2.BE.E9.81.B8.E7.89.88.20.E6.97.A5.E6.9C.AC.E5.9B.BD.E8.AA.9E.E5.A4.A7.E8.BE.9E.E5.85.B8 I only mentioned エンゼル as an example that the word does exist on my talk page, it's not the edit that I have undone. --Anatoli T. (обсудить/вклад) 22:25, 18 January 2021 (UTC)
These links are dishonest. Note that for the Weblio link, there are 26 example sentences in total, with the vast majority of them being about baseball and the rest featuring "エンゼル" in a compound word, while the Kotobank link primarily features encyclopedia pages on proper names "Angel", or angel investors, with only one (1) dictionary definition featuring 2 literary quotes from 1891 and 1907, and I encourage everyone to use Google Translate on the latter link to personally verify. —Suzukaze-c (talk) 02:36, 19 January 2021 (UTC)
Deletion of エンゼル" is not the translation that I have reverted. Not sure about dishonesty. The examples given in both dictionaries use are unhelpful for our CFI but the definitions/translations are. --Anatoli T. (обсудить/вклад) 04:16, 19 January 2021 (UTC)
@Atitarev, I also think it was a bit hasty to ban @Liywy, especially when they're a native speaker. If these gairaigo removed by Liywy are anything like their equivalents in Korean (and I freely admit they might not be, since I don't speak Japanese), many of them would be marked or unusual forms—purposeful Anglicisms, to some extent used precisely because of their foreignness—and if so, I see why Liywy might have wanted to remove them from the translation tables.
In addition, many of Liywy's edits were adding non-gairaigo equivalents into translation lists without removing established English loans (1, 2), which I don't see as disruptive. I think this should have been discussed more.--Karaeng Matoaya (talk) 15:16, 18 January 2021 (UTC)
Liywy has removed many attestable terms, I have only undone some of them. The disruptive edits were in the edit-warring that followed on some entries, not the edits themselves. --Anatoli T. (обсудить/вклад) 22:16, 18 January 2021 (UTC)
I can understand why we would want to stop @Liywy from making mass changes until they're discussed, but a sitewide block is overkill. They're not being disruptive in general, but (allegedly) in a very narrow context. I changed it to mainspace-only so they can participate here, and I think we can reduce it or remove it once we understand better what's going on. Chuck Entz (talk) 15:28, 18 January 2021 (UTC)
I have invited User:Liywy to this discussion on their talk page. DCDuring (talk) 17:55, 18 January 2021 (UTC)
A Japanese speaker should try to engage this user (e-mail, other projects, invitation to WT:AJA in case their Babel box accurately characterizes their English skills as non-existent. DCDuring (talk) 18:07, 18 January 2021 (UTC)
Their English is apparently fine judging by what they told me on my talk page.
My block decision was based not on the edits themselves or [opinion] but because of the edit warring. I have reverted some of their removals with an explanation and a link to Google books but they have reverted again with no explanation. --Anatoli T. (обсудить/вклад) 22:10, 18 January 2021 (UTC)
Their validity is highly disputable, and casually presenting them in a translation table on par with common terms is misleading. —Suzukaze-c (talk) 02:38, 19 January 2021 (UTC)
Which particular translations are highly disputable? So far I have reverted removal of Japanese loanwords from English for the following words: discount, pill, boyfriend, girlfriend, rival, sportsman, electronics. The existence and use of valid corresponding katakana words are easy to prove. I haven't gone through all removals, though. --Anatoli T. (обсудить/вклад) 04:16, 19 January 2021 (UTC)

Chagossian Creole[edit]

What could be the code for the Chagossian Creole? --Apisite (talk) 12:33, 19 January 2021 (UTC)

I'd think it's classified as part of the Mauritian Creole on Wiktionary, so mfe. Thadh (talk) 12:43, 19 January 2021 (UTC)
@Thadh: How different are the creoles from each other? --Apisite (talk) 12:54, 19 January 2021 (UTC)
@Apisite: No idea, I'm hearing of Chagossian for the first time; I just noted the probable answer to your question, since Wikipedia (and ISO apparently) classifies it as a dialect of Mauritian. Thadh (talk) 13:06, 19 January 2021 (UTC)

Turkish words derived from Old Turkic[edit]

I have seen Old Turkic used with {{etyl}} as if it were an ancestor of Turkish, but it is not configured to be one in the module data. It is unclear if the intention is to indicate inheritance from Old Turkic, borrowing from Old Turkic, or mentioning of the word as a contemporary cognate of an unattested ancestor. I wonder if Category:Turkish terms derived from Old Turkic and Category:Ottoman Turkish terms derived from Old Turkic should have as many entries as they do, or if the Old Turkic words should generally be listed as cognates. Vox Sciurorum (talk) 19:44, 19 January 2021 (UTC)

@Vox Sciurorum: Quote Allahverdi Verdizade at Wiktionary:Etymology scriptorium/2020/December § Moving Proto-Turkic words on /*g-, *d-/ to /*k-, *t-/: Nişanyan doesn't deal with Proto-Turkic (only Common Turkic) and obviously equals Old Turkic with Common Turkic, and views it as an ancestor of all modern Common Turkic languages […]. He has also said in one of his streams (in a series of youtube-videos called Dilbilim ve etimoloji, if the memory serves) that "Old Turkic is the ancestor of all modern Turkic languages", a view that we of course cannot support. Quote end.
And Nişanyan is the most accessable etymological dictionary of Turkish, so this is why Turkish editors treated the Old Turkic cognates, which Old Turkic words are only in relation to Turkish, barring rare cases were Old Anatolian Turkish may have borrowed from Old Turkic, given by Nişanyan as ancestors. So the derivations are wrong altogether and Old Turkic words are cognates. Fay Freak (talk) 20:15, 19 January 2021 (UTC)
I remove them when I see them, but I haven't gone through all entries systematically. Someone should do it, but it's a hell lot of work, 377 entries. Many Old Turkic cognates are moreover entered in Latin script... Allahverdi Verdizade (talk) 21:48, 19 January 2021 (UTC)
I suspect that Sevan Bey has a different understanding of the term Eski Türkçe (literally “Old Turkish”) than what we call “Old Turkic”. The latter name is a bit confusing; one would expect it to mean “an older version of Turkic”, a progenitor of the various branches of Turkic, instead of referring to merely one among several older versions of Turkic languages.  --Lambiam 01:02, 20 January 2021 (UTC)

Are there any cases where Spanish terms shouldn't have a link to the DLE?[edit]

Many of our entries have links to the DLE using {{R:RAE}} but some don't and I trying to add them whenever I see it missing (e.g. https://en.wiktionary.org/w/index.php?title=byte&diff=prev&oldid=61611329). Is there any good reason to not add this link as long as there is an entry in the DLE to point to for an entry? Seems like this is almost bot-like work and it seems obvious that it should be included without any real human discrimination but maybe there's something I'm missing. Thanks. —Justin (koavf)TCM 08:14, 20 January 2021 (UTC)

I think {{R:RAE}} should normally be used. I expect there are a few entries where it will not match our definition, maybe because there is a new or distinctly American sense that hasn't been recognized (yet) by the authorities in Spain. A bot would need to parse the HTTP response from dle.rae.es to see if it contains a definition, a pointer to an alternative form, or an error. Vox Sciurorum (talk) 15:10, 20 January 2021 (UTC)
This was done several years ago with links in French entries to the TLFI. I believe it was considered a success, even though there are still entries being discovered with bad links. It might help if we could track down discussions on that operation to see what lessons were learned (here is a search for mentions of it in the Wiktionary, Talk and User Talk namespaces). For reference, it was done by @Kc kennylau using User:Kennybot. Chuck Entz (talk) 15:37, 20 January 2021 (UTC)

Interface admin rights[edit]

I'd like to get the interface admin bit to add a bit of a WikiHiero related kludge to common.js. Since I am a bureaucrat, I'm technically able to add the right myself, but I'd like to first make sure that the community would agree with that decision. — surjection??⟩ 20:07, 20 January 2021 (UTC)

Before the introduction of the interface admin right, all admins could edit those pages. I oppose any bureaucracy limiting admins from becoming interface admins, and I would support a measure to give those rights to all admins by default. —Μετάknowledgediscuss/deeds 20:14, 20 January 2021 (UTC)
Seconded. If you don't trust admins' judgement, then why are they admins? Everyone makes mistakes but I think the community here is generally pretty conservative in its editing anyway and tends to stick to areas of competence as it is. —Justin (koavf)TCM 21:40, 20 January 2021 (UTC)
I’ll throw in a third support for extending this to admins in general. The current situation was only intended as a stopgap solution to begin with. Also chiming in with support for Surjection’s IA-ship (and WikiHiero-related changes) in any case. — Vorziblix (talk · contribs) 05:50, 21 January 2021 (UTC)
Makes sense to me. --{{victar|talk}} 08:12, 21 January 2021 (UTC)
It makes sense, and I agree to this individual request of course. But the Wikimedia guys made a general decision that admin rights should not automatically entail interface admin rights. So at least we had this small hurdle of somebody requesting this right so not all who don’t even need it have it, for security reasons. One could only argue that the supposed danger with en.Wiktionary in particular is not that great anyway because there are so few admins anyway so Wiktionary can give it to every admin anyway, but this is difficult to argue if even en.Wiktionary with its now seemingly few editors is in the tops of the most-edited Wikimedia wikis – I don’t know which are the most-edited wikis, when I search this I only get endless articles about the most-edited Wikipedia articles which is of zero interest as I’d like to know the largest wikis by frequency, but at least we have lists for total size, and en.Wiktionary takes the tenth place by total admin count, and that is only an eleventh of English Wikipedia’s total number of admins, so the assumption is likely that we are not allowed to just give interface admin to every admin. Fay Freak (talk) 17:32, 21 January 2021 (UTC)