Wiktionary:Beer parlour/2023/January

Hello, I have 2500+ edits and 420+ entry creations, and I also made many reverts and speedy deletion tagging for bad changes. Please allow me to ask if I can have rollback and/or autopatrol at here. I already have rollbacker rights at simple English Wikipedia and simple English Wiktionary, so I'm sure I know how to use it. Thank you. MathXplore (talk) 08:08, 1 January 2023 (UTC)(Updated edit count, withdraw autopatrol request per feedback, MathXplore (talk) 09:30, 3 January 2023 (UTC))

My reverts at this project can be seen at here, and a full record of my reverts can be seen at m:User:MathXplore#Reverts. MathXplore (talk) 06:14, 3 January 2023 (UTC)

I am not familiar with this user and I'm not completely sure what autopatrol functionality is and how it differs from rollback functionality but I don't think it's a particularly big deal to grant it. Any comments/objections? Benwing2 (talk) 07:37, 3 January 2023 (UTC)

@Benwing2 They've been reverting a fair amount of obvious vandalism, which is good, but they've also been nominating things for speedy deletion based on criteria that don't make all that much sense according to Wiktionary standards- I'm not so sure they're up to speed on Wiktionary standards, overall.

As for autopatroller status, that just means that all of their edits show as patrolled. That makes me a little nervous because sometimes reverting isn't enough- the perpetrators may need to be blocked, spam or personal information may need to be hidden, etc. The rollback tool marks the reverted edits as patrolled, so they drop off the radar for those of us who filter for unpatrolled edits in Recent Changes. If someone is both an autopatroller and rollbacker, both the reverts and the reverted edits disappear. Chuck Entz (talk) 08:25, 3 January 2023 (UTC)

Hello, thank you for the feedback. In order to respond to your concerns, I decided to withdraw the autopatrol request for now. I would like to keep the discussion open to hear comments about my rollback request. MathXplore (talk) 09:30, 3 January 2023 (UTC)

The current template {{uncertain}} is a definition line template that displays text something like The meaning of this term is uncertain. Possibilities include:. It is non-parallel with {{unknown}}, which is an etymology template for terms with unknown etymologies. In general, templates with plain names like {{uncertain}} are used for etymologies, and definition-line templates are often identified by additional text such as of, with or for (compare {{clipping}} vs. {{clipping of}}). Furthermore, {{uncertain}} is currently used on around 238 pages, while {{unk|title=Uncertain}} or similar is used in 1,588 instances on 1,553 pages. I propose therefore to rename {{uncertain}} to either {{defn-uncertain}}, {{uncertain defn}} or {{uncertain meaning}} and reuse {{uncertain}} (shortcut {{unc}}) for uncertain etymologies. The way I conceive of it, it displays Uncertain instead of Unknown (as {{unknown}} does) but otherwise categorizes the same, e.g. into e.g. Category:English terms with unknown etymologies. Possibly we should rename that category to Category:English terms with unknown or uncertain etymologies to better reflect the reality of these terms ("unknown" suggests we have no idea where a term comes from, "uncertain" suggests we have some guesses but we can't substantiate them, which is usually closer to the truth). But I would advocate not splitting the category into "unknown" vs. "uncertain" categories; there is too much uncertainty (so to speak ...) in the etymologies to be able to draw a clear line between the two categories. Thoughts? Benwing2 (talk) 08:32, 1 January 2023 (UTC)

I've seen templatized-"Uncertain" in enough etymologies that my initial reaction upon reading the section title was "isn't T:uncertain already for etymologies?", even though upon thinking about it I realize I have of course encountered it in its actual current use on definition lines — so that's a clear sign of where the naming format suggests it belongs, as you say! Hah. Yeah, it seems reasonable to give the name "Template:uncertain" to an etymology-section template, and name the current definition-line template something else. (And something in the vein of "defn-uncertain", though it feels odd to me because I'm not used to it, is upon consideration pretty intuitive.) - -sche (discuss) 09:52, 1 January 2023 (UTC)

Side note, the fact that the various {{clipping}}- vs {{clipping of}}-type templates you mention are so similarly named that people continually mix them up (most of the results of a search for insource:"Etymology acronym of" are using T:acronym of where they should have T:acronym: taser, supo, COBOL, ...) almost makes me wonder if all definition templates should be renamed to start with "definition:", e.g. {{definition:acronym of}}. But I'm loathe to make people type extra letters, especially when even spelling out "definition:" might not stop them using it in the wrong place. - -sche (discuss) 09:52, 1 January 2023 (UTC)

Support the main point. (To save a keystroke, and by analogy with {{defdate}} and {{rfdef}} (itself redone from {{defn}}), I'd prefer "def" to "defn", though.) I'm not sure unknown and uncertain need to be split at the category level, but I agree with the idea of making a shortcut for uncertain etymologies—I also tend to think the default should be uncertain rather than unknown anyway. The problem with splitting them rigorously is that I think the intuitive distinction is less clear-cut—IMO it's useful to call something where there are conjectures, but they're relatively weak and/or there are a lot of them, "unknown" rather than just "uncertain" (e.g. Latin -ensis). —Al-Muqanna المقنع (talk) 12:40, 1 January 2023 (UTC)

Yeah, I agree with you and Benwing about keeping one category. (And I like the clarity of Benwing's "Category:English terms with unknown or uncertain etymologies" as a category name.) - -sche (discuss) 19:50, 1 January 2023 (UTC)

Agree. Personally I think the system we have now is fine, but I can understand why people would want to make the change. Vininn126 (talk) 20:55, 1 January 2023 (UTC)

I went ahead and renamed {{uncertain}} to {{def-uncertain}} (following the name recommended by User:Al-Muqanna) and created a new {{uncertain}} for uncertain etymologies. (There are actually more than ~1500 uses of "uncertain" in {{unk}}/{{unknown}}, maybe more like ~2500.) The category still reads e.g. Category:English terms with unknown etymologies; I would like to rename this to Category:English terms with unknown or uncertain etymologies but will hold off a few days longer to see if there are any comments about this name. Benwing2 (talk) 06:54, 9 January 2023 (UTC)

Is this also catching instances of the words manually written in the etymology lines? Vininn126 (talk) 09:16, 9 January 2023 (UTC)

@Vininn126 Do you mean where they write out "Uncertain" or similar but don't use any template? I haven't dealt with those yet; to do that I need to look through a recent dump file. Benwing2 (talk) 19:09, 9 January 2023 (UTC)

I don't think "A toponym in ..." should be allowed as a definition. It's just a longer way of saying "place", but in a non-gloss way (so actually more like "name for a place"), and I think we would all agree that that is a very vague definition that should be avoided in favor of something specific like "neighborhood", "street", "fort", etc., except in extenuating cases like a place mentioned once in an ancient document with no further context. If a toponym is actually attested in multiple sentences, it should usually be possible to infer what kind of place it is. 70.172.194.25 09:13, 2 January 2023 (UTC)

Can't we use {{place}}? Vininn126 (talk) 10:19, 2 January 2023 (UTC)

Further to the discussion about some of these at Wiktionary:Requests for verification/Non-English#Oudorte, it seems these tend to be place names that are mentioned on a map but without any real significance (individual fields, clearings, copses, etc.) that shouldn't have entries anyway per WT:CFI#Place names. They're often just small labels on stretches of countryside on géoportail. If something like this can only be called "a toponym" there's a good chance it doesn't need an entry. —Al-Muqanna المقنع (talk) 10:27, 2 January 2023 (UTC)

@Al-Muqanna I completely agree. We already have lots of entries for unincorporated communities, which are generally in Wikipedia but many of which exist only in databases and on old maps. If you poke around Wikipedia you can find tons of them, e.g. (just randomly looking a bit) Hoover, Missouri. This one isn't in Wiktionary but under e.g. Florence you can see a bunch of them mentioned. If you look up the one in Stephenson County, Illinois in Wikipedia here: Florence, Stephenson County, Illinois, you see nothing but a stub, and you probably can't find much info on it in Google. If it has any significant population and cohesiveness it's generally called a "census-designated place" instead. Benwing2 (talk) 04:22, 3 January 2023 (UTC)

• The best of these French "toponym" entries might be on a par with Florence, Stephenson County, for which one can actually find several hits on Google Books, including in sentences. And to be clear, I'm relatively inclusionist and welcome the creation of entries for place names with that level of attestability, e.g. Roudoulous (see history). That place may only have 1,170 hits on Google (about twice as many as "Florence, Stephenson County"), but it has good citations available on Google Books. I would just prefer if 1. people were to check whether a place name is attested before adding it, 2. such entries were defined using a more specific term as appropriate (e.g. "hamlet") instead of the vague "toponym".
• The worst of these place names are infinitely less attestable, with no Google-indexed evidence that they exist. I challenge anyone to find a single mention of e.g. Arrominguerasse or Touteillac anywhere on the Web, let alone a use in a sentence in a durably archived source. Géoportail must have gotten them from somewhere, but I have no idea where. Maybe manual data entry or OCR from old maps, IDK. How do we know this database doesn't have typos/scannos, etc.? I don't like relying on it as the sole available source, not to mention that CFI doesn't allow us to do so. 70.172.194.25 01:25, 4 January 2023 (UTC)

I think it's just data from IGN, the French equivalent of Ordnance Survey (don't think there's an exact equivalent in the US). You can turn on the IGN map as an overlay on géoportail and the labels will be there. —Al-Muqanna المقنع (talk) 17:17, 5 January 2023 (UTC)

Rationale: Currently all our Classical Chinese quotations are transliterated into pinyin when {{zh-x}} is used. However there are several problems with this: 1) it is anachronistic as people from the ancient times obviously did not speak Mandarin; 2) the auto-generated pinyin is often incorrect, and in some cases the character is so rare that it is not in the data modules (see diff for example); 3) the Classical Chinese text can be equivalently read in many other Chinese lects or other languages, and there is no reason to always assume MSM by default.

Proposal: Transliterations would not be provided by {{zh-x}} when the third parameter is specified to be CL. Variants of CL (including a new CL-M for MSM) would only be used where appropriate, e.g. when the quotation in consideration uses certain features such that it would be possible to identify the lect in question, or when the author is known to speak a particular lect.

(Notifying Atitarev, Tooironic, Fish bowl, Justinrleung, Mar vin kaiser, RcAlex36, The dog2, Frigoris, 沈澄心, 恨国党非蠢即坏, Michael Ly, ND381): – Wpi31 (talk) 17:36, 2 January 2023 (UTC)

@Wpi31: Not providing any romanization would not be great because it would make it very inaccessible to the target audience, who we would assume is unable to read Chinese characters. In most scholarly work on Classical Chinese in English, Mandarin is the default romanization. I am not saying that this is necessarily the best thing to do, but it's not unprecedented. — justin(r)leung _{{ (t...) | c=› }} 17:46, 2 January 2023 (UTC)

@Wpi31: Outline of Classical Chinese Grammar by Edwin G. Pulleyblank gives Mandarin romanizations. RcAlex36 (talk) 18:02, 2 January 2023 (UTC)

@Justinrleung Obviously I do acknowledge that it is fairly standard in academia to provide Mandarin romanisations (well, since it's "standard Chinese" in modern times), but in my view this is a barely acceptable solution to the larger problem(s) of romanisation of Chinese, and the problem(s) caused by Wiktionary's approach of lumping Chinese together. Would it be possible to instead supply OC/MC reconstructions or Baxter's transcription that we are already providing on many pages, or even splitting Classical Chinese as a separate L2?

(TBH we really need to reconsider how we deal with Classical Chinese, it really deserves some love and attention. Only the written texts are attested, so theoretically all the existing OC/MC reconstruction stuff should be in the reconstruction namespace.) – Wpi31 (talk) 18:41, 2 January 2023 (UTC)

@Wpi31: I don't really know if OC or MC are necessarily better since OC reconstructions are highly controversial, and OC/MC reconstructions are also possibly anachronistic because they only represent particular points in the history of Chinese. — justin(r)leung _{{ (t...) | c=› }} 22:12, 2 January 2023 (UTC)

I support keeping pinyin for Classical Chinese. It is not perfect, but neither are reconstructions, which as Justin points out, are highly controversial. As editors, we will need to monitor pinyin transcriptions to ensure they are accurate, and edit in overrides where necessary. I also note that pinyin is used across the board in pretty much every Classical Chinese publication both in and outside of China, especially for obscure characters. The readings are meant as a guide to the modern reader, and are not taken to be historical readings. ---> Tooironic (talk) 00:58, 3 January 2023 (UTC)

@Wpi31: Template:ltc-l and Template:och-l may be useful to you. 恨国党非蠢即坏 (talk) 03:53, 16 January 2023 (UTC)

We do not have a consistent way of handling placeholder pronouns in the headwords and inflection lines of some multiword phrases, eg, leave someone to their own devices. Often the result is to have a form that doesn't include all possible pronouns (eg, 1st- and 2nd-person pronouns) as well as not allowing for the possibility of nouns in the expression and therefore not helping learners use the expression correctly. I understand that there is usually (always?) no perfect solution to the difficulty in presenting such expressions. Other lexical references follow a variety of practices.

In ], the use of their is more inclusive than his or her (what MWOnline uses) and, though imperfect, is adequate for 3rd-person use, though it could be taken as implying that his and her are wrong when used with a singular someone or what this placeholder stands in for. I think that most users understand that someone can be replaced by a plural, but I fear that fewer recognize that nouns (including some referring to certain things) and 1st- and 2nd-person pronouns can occupy the 1st placeholder position and fewer yet will be confident in selecting the proper occupant of the 2nd placeholder position.

1. Possible changes in presentation:
   1. Would it be an improvement to enclose the pronouns someone and their in parentheses to emphasize those pronouns' role as placeholders: leave (someone) to (their) own devices? At least one other OneLook reference (Fairlex Dictionary of Idioms) does just that. AHD and Random House omit the 1st placeholder and parenthesize the 2nd, as we did until recently.
      1. Should such a change appear in the headword as well as the inflection line?
   2. Some other references show placeholders unemboldened.
   3. Some references exclude placeholders entirely!: leave to own devices. Search engines may allow this to enable users to find the entry.
2. Should we facilitate the automated or semi-automated addition of hard or soft redirect entries with placeholders replaced by all possible personal pronouns (including no replacement)?
3. Should we have some kind of Appendix or Wiktionary page to explain in detail what usages placeholders indicate? To be useful such a page would need to be referenced, probably in a standard usage note.

DCDuring (talk) 17:14, 3 January 2023 (UTC)

On point 2, I am absolutely in favour of using redirects more widely in cases like this, for variations with other pronouns or verb conjugations; redirects are cheap and left you to your own devices, leave me to my own devices etc isn't going to be a valid entry in any other language so there's no conflict. (If it is, just have a proper entry for that language, and a soft redirect for the English L2 section.) Usexes and citations in the lemmatized form should try to show the range of possibilities.
Would it be useful to have a (semi-templatized?) usage note explicitly spelling out what substitutions are possible? Or does the fact that almost any phrase can (if rarely) be modified make that pointless? E.g., physician, heal thyself usually uses that second person, but sometimes the google books:"physician heals himself" / google books:"physician needs to heal himself"; you and whose army can be modified to ask about google books:"him and whose army", etc. - -sche (discuss) 02:43, 4 January 2023 (UTC)

(Notifying Ariamihr, Dijan, Mazsch, Qehath, ZxxZxxZ): Hi. Please review Special:Contributions/HAKHSIN. It seems they are adding made up words or unattestable neologisms. Anatoli T. ^{(обсудить}/^вклад) 04:54, 5 January 2023 (UTC)

I have created Wiktionary:Todo/Rare IA terms. So far I've only generated tables for entries starting with A-Z and a-c, checking about one third of English entries. It's turned out to be a good way to find terms that may not exist at all (like Afbachir), as well as real but rare terms deserving of quotations/referencing (like advowrer). If anyone finds these lists useful I can generate lists for the rest of the alphabet. 70.172.194.25 19:21, 5 January 2023 (UTC)

This is why we need more corpora research on this project. It's just so invaluable. Vininn126 (talk) 19:26, 5 January 2023 (UTC)

This seems useful. Clearly it's helping catch nonexistent terms. (I wonder, in the other direction, if we could figure out the most common words in the IA corpus that lack entries here are. That's probably harder to do.) - -sche (discuss) 20:17, 5 January 2023 (UTC)

The Topic Categories are underused for even basic things such as light or fire, I suggest a bot be created to go over the wiki and put pages that do not have a topic category on them to a hypothetical Category:Request for topic categories with a template/module made to populate each language

I brought up this in the discord and was pointed out a number of exceptions would need to be made, such as grammar words like of and to, and there are bound to be other considerations to be made Akaibu1 (talk) 20:58, 5 January 2023 (UTC)

@Akaibu1 Someone made a similar request a few months ago. I'm not quite sure what you're proposing; if it's to add all content pages that aren't in any topic to a language-specific Category:Request for topic categories page, there are far too many such pages, and the category would become useless. More useful maybe would be to do this selectively only for the top X pages of a language by frequency (e.g. the top 10,000). What was proposed a few months ago was to auto-add pages to categories based on words occurring in the pagetitle, which would lead to tons of issues. Anything like this ultimately needs to be at least reviewed manually; if I were to do this I would set up a procedure to auto-create a text file of potential pages to add and the categories to add them to, then manually edit the text file to fix issues, then run a script to auto-push the resulting categories. But this is hard to get working for people who don't have a bot; ideally you'd want a UI to do this, but that would take some (nontrivial) programming work by someone (e.g. User:Erutuon) who knows how to create UI's. Benwing2 (talk) 21:57, 6 January 2023 (UTC)

see Category:English_1-syllable_words

this is likely a template issue if this is not in fact intended Akaibu1 (talk) 21:02, 5 January 2023 (UTC)

• This is caused by {{IPA}}. It automatically determines the number of syllables in the pronunciation and, as long as the pronunciation does not contain spaces, it adds the term to the corresponding syllable category, even if the term is not a word. I (as ExcarnateSojournerBot (talk • contribs)) removed all terms containing spaces from these categories back in November by adding |nocount=1 to instances of the IPA template. For affixes I would like to see if we can make a change to the IPA template that will apply to all languages, rather than hardcoding |nocount=1. — excarnateSojourner (talk · contrib) 20:05, 11 January 2023 (UTC)
• It should be possible to fix this with a small change to Module:IPA, as long as I can find a way within the module to check if the current page is in the language's affixes category. I have tried and so far failed to find a way to do this. — excarnateSojourner (talk · contrib) 23:45, 5 February 2023 (UTC)

Can we have Quiet Quentin also support searching (and formatting citations from) Google Scholar, like it does Google Books? - -sche (discuss) 01:31, 6 January 2023 (UTC)

Wiktionary:Quotations#Quotation_gadgets Read that, there's a secondary gadget. It'd be nice to merge the code. I bet I could figure out a way to modify it to work with a certain Polish library website but that's not important at the moment. Vininn126 (talk) 01:40, 6 January 2023 (UTC)

Yeah, if we could either merge the code, or just house the code as a PREFS-enablable gadget rather than something people have to go outside of Wiktionary to turn on, it'd be great. - -sche (discuss) 01:44, 6 January 2023 (UTC)

I might be willing to work on this (merging / streamlining the code) someday if nobody else does. 70.172.194.25 01:45, 6 January 2023 (UTC)

It would be nice to have it work on Firefox. Its subwindow is currently unscrollable, which makes it unusable. --RichardW57m (talk) 12:35, 9 January 2023 (UTC)

The page currently at User:Dan Polansky/Thesaurus Benefits was placed by me at Wiktionary:Thesaurus/Benefits. The page ought to be moved back to Wiktionary namespace where it was created. The thesaurus project needs a fine description of its benefits and I have written one. The page I have written is a Thesaurus project asset, not a personal user page content. What I did was in keeping with Wiktionary common law, the practice by which Wiktionary namespace pages are written by initiative of individual editors and then developed together. Issues can be raised on the talk page and addressed. I will not provide examples now of other Wiktionary namespace pages like that since they are very easy to find, and all is on record. I even added a disclaimer at the top of the page: "This page reflects reasoning not necessarily shared by all editors." I am one of the few key contributors to the Thesaurus over many years, and have a natural role in stating the benefits as I understand them. Thesaurus project is better off with at least one description of its benefits; however, if someone thinks they can provide a better description of the benefits, we can use that content in Wiktionary:Thesaurus/Benefits instead. In the mean time, what I created ought to be moved back. Dan Polansky (talk) 07:13, 6 January 2023 (UTC)

You might have written the best thing in the world, and beaten us all, but unless there is community consensus, that's userspace. And you know it too. This isn't your personal blog. Equinox ◑ 07:15, 6 January 2023 (UTC)

That's not an attempt at argumentation, merely a statement of disagreement. The above does not say why the Thesaurus project ought not have a description of benefits by one of its main authors; it says that editors disagree with that. By that, the principle of the strength of the argument is violated and is replaced with numerical majority. --Dan Polansky (talk) 07:21, 6 January 2023 (UTC)

I assume you are able to read, Dan: the argument is - very obviously - that you lack consensus. Three different users moved it back to your userspace after you repeatedly edit warred to reinstate it, and had I not salted the page, I have no doubt you would have continued doing so. Just be thankful you didn’t receive another ban, because you’re on thin ice. Theknightwho (talk) 07:25, 6 January 2023 (UTC)

"Lack of consensus" is not an argument; to the contrary, on Wikipedia, what they call "consensus" is based on arguments. --Dan Polansky (talk) 07:33, 6 January 2023 (UTC)

It is an argument for why we don’t have to reinstate the page as some kind of status quo ante, which is what you seem to want. Theknightwho (talk) 07:37, 6 January 2023 (UTC)

I am not arguing "status quo ante"; I did not use the phrase. I am arguing the page is a good thing and those who oppose it have to explain why it is a bad thing; their saying "we oppose" ought alone have no force. --Dan Polansky (talk) 07:49, 6 January 2023 (UTC)

In the mean time, what I created ought to be moved back. Don’t lie. Theknightwho (talk) 07:55, 6 January 2023 (UTC)

Arguing against this level of argumentation stupidity or dishonesty is unproductive. I won't. If some editors want to see the benefits page restored, it's their call. --Dan Polansky (talk) 07:58, 6 January 2023 (UTC)

Threats against my user account belong on my talk page, not to this discussion. The above is unacceptable intimidation of a major Thesaurus contributor, which the above isn't. --Dan Polansky (talk) 07:33, 6 January 2023 (UTC)

I don't need an "attempt at argumentation" because, guess what, Wiktionary doesn't work on your rules (which are: "we argue until someone gets tired, and then Dan wins"), but rather on consensus. Go to sleep mate. Equinox ◑ 07:28, 6 January 2023 (UTC)

These are not my rules; these are Wikipedia's rules, viz that what matters is the strength of the argument, not the numerical majority. Therefore, it is required that at least an appearance of the search for strong argument is maintained. --Dan Polansky (talk) 07:33, 6 January 2023 (UTC)

This isn’t Wikipedia. Theknightwho (talk) 07:35, 6 January 2023 (UTC)

It was the above editor who claimed in another discussion that Wiktionary ought to decide by combination of strength of argument and numerical majority. My position is that Wiktionary ought to adopt much more of the Wikipedia principle that the strength of the argument makes a huge difference and that those who do not create at least an appearance of seeking strong arguments have no say. --Dan Polansky (talk) 07:37, 6 January 2023 (UTC)

I have repeatedly observed that the interjection PoS is applied very liberally on Wiktionary. The supposed interjections whose inclusion I disagree with are usually nouns that happen to be regularly uttered in isolation. I hold it that this is not sufficient grounds for inclusion; some sort of semantic or syntactic alteration has to be observed. Compare

• skill issue! = this is a skill issue
• bummer! = this is a bummer
• bullshit! = this is bullshit

with

• congratulations! ≠ these are congratulations
• hell! ≠ this is hell
• shit! ≠ this is shit

FWIW, Wikipedia describes a similar distinction: w:English_interjections#Interjections_vs._nouns. — Fytcha〈 T | L | C 〉 11:12, 6 January 2023 (UTC)

Cf. the discussions at WT:Requests for deletion/English#victory and bad. To summarise what I wrote on victory, my preference for a principle of exclusion is roughly similar to what you've suggested, that secondary interjections which simply amount to "this is X", "X has happened", "X is here", or vocatives ("Waiter!" etc.) should be excluded. However, I think common "hortative" interjections ("Freedom!") should be included. But note that Wikipedia's "interjections vs. nouns" section is not correct: its citation is discussing primary interjections, a distinction the Wiki article fails to make (the title of the cited journal article is even "From proper name to primary interjection"); nouns in isolation are still, linguistically, interjections even if there's nothing peculiar semantically about that form. If a word retains its function as another part of speech then it's a secondary interjection, even if there's something particular about what it means as an interjection (the point about "gee" in the journal piece is that it's lost those other functions completely). By the same token, if we only accepted primary interjections, as the Wiki section would suggest, then clearly congratulations, hell, shit would fail since they haven't been "bleached of their original meaning" as nouns. —Al-Muqanna المقنع (talk) 11:22, 6 January 2023 (UTC)

@Al-Muqanna: Thanks for the pointers. The primary/secondary distinction that you're describing is strongly reminiscent to me of the lexical-syntactic distinction drawn with respect to adverbs in German grammar: Wiktionary:Beer parlour/2022/July § (German) Categorically removing adverbially used adjectives, Adverb#Usage_notes. If we're going to contend that most if not all nouns can (at least syntactically) 'be' interjections (what has been referred to as a secondary interjection), then that's all the more reason for me to oppose their double inclusion for the same reasons that I've already laid out in that BP thread. As for hortatives, I haven't thought too much about them but at present I'm probably also against their inclusion.

if we only accepted primary interjections, as the Wiki section would suggest, then clearly congratulations, hell, shit would fail since they haven't been "bleached of their original meaning" as nouns I disagree. When someone says Oh, hell! I got another parking ticket., the noun senses of the word hell are not invoked. The semantics that the interjection hell adds to this utterance (frustration, discontent) can only be accessed when hell is used interjectionally. For words like bummer, the part of speech does not fence off special semantics; something is labeled a disappointment, regardless of whether bummer syntactically acts as a noun or an interjection. — Fytcha〈 T | L | C 〉 11:58, 6 January 2023 (UTC)

That might be argued for hell, but I think it's much harder to argue that congratulations, condolences, apologies aren't invoking their original noun senses. —Al-Muqanna المقنع (talk) 12:00, 6 January 2023 (UTC)

@Al-Muqanna: I would have to think more about these in particular (intuitively, they seem to contain more "meat" than, say, bummer but I can't articulate my intuition right now), but even if it turns out that they are indeed secondary interjections, that's a bullet I'd be willing to bite, considering that they aren't getting deleted anyway thanks to WT:THUB and perhaps also WT:PB. — Fytcha〈 T | L | C 〉 12:06, 6 January 2023 (UTC)

I've always considered nouns to be quasi-interjections at best. My idea of "true" interjection is "oops" or "ouch". I have no literature on those quasi-interjections and what to do about them, so these are just my 2 cents at this point. --Dan Polansky (talk) 12:36, 6 January 2023 (UTC)

I agree with the "this is" criteria for determining interjections versus nouns like victory. In the case of skill issue I could see it being reworked into a noun (although I've mainly seen it used as an interjection). Ioaxxere (talk) 13:40, 6 January 2023 (UTC)

(The problem there is that like I pointed out at RFD the "this is" criterion doesn't apply to victory, the OED's definition of the interjection sense is "an expression of triumph or encouragement" (hence my "hortative" category, which needs separate discussion).) —Al-Muqanna المقنع (talk) 13:48, 6 January 2023 (UTC)

Whom are we serving when we include the PoS in these cases? Any normal user, including language learners, hearing or reading an NP used in isolation thereby know that it is very probably being used as an interjection, an answer to a question, a question, a command, encouragement, etc. IOW, this is a matter or pragmatics and, therefore, it would rarely (never?) be lexical. I suppose that some kind of shift of lexical meaning might warrant an interjection PoS, but such shifts seem likely to be rare. DCDuring (talk) 16:26, 6 January 2023 (UTC)

Well, I think if it's an interjection, as you say, it should be listed as one. For example, grow up is defined as a verb, and one of the senses is described as being often used as an imperative interjection. If we agree that it's an interjection, why not break it out into its own section? That's just the argument from a rules-as-rules sense, but you asked about benefits ..... having a separate part of speech will give us more room to illustrate the range of meaning with quotes and use-examples instead of cramming it into a single sense under the noun definition where it might be easily missed. An interjection might have more variety of meaning than its parent noun or verb does. —Soap— 09:28, 16 January 2023 (UTC)

FYI, I've gone ahead reworked skill issue into a noun (referencing new quotations have become available since I created the entry back in October). Ioaxxere (talk) 19:18, 6 January 2023 (UTC)

There probably is such a list somewhere. Can anyone point me to it? Thanks in advance. DonnanZ (talk) 16:55, 6 January 2023 (UTC)

@Donnanz: Wiktionary:Administrators — Fytcha〈 T | L | C 〉 16:57, 6 January 2023 (UTC)

Special:ListUsers/sysop should do it on most any MediaWiki wiki. —Justin (koavf)❤T☮C☺M☯ 17:57, 6 January 2023 (UTC)

Sadly, some of the old guard seem to be inactive now, with their last contributions in 2022. DonnanZ (talk) 18:05, 6 January 2023 (UTC)

To be fair, we're only 6 days into 2023... and I personally find it quite refreshing that of the 34 admins elected before 2010, all have been active in the last 2 months or so (Internoob is the only exception). I guess we can't be too toxic a place, after all. Celui qui crée ébauches de football anglais (talk) 21:13, 6 January 2023 (UTC)

OTOH, 17 of our 108 human admins haven't edited after 2019, leaving more than 80,000 content pages per admin. It's a good thing we have more than 1,000 autopatrollers. DCDuring (talk) 23:04, 6 January 2023 (UTC)

@Thadh, Hythonia, Fenakhay, Sławobóg, Surjection but also this is very much a site-wide decision. I would like to establish a policy for words that were never recorded in parent languages but were inherited nonetheless. I see three options 1) do not list the unattested intermediate at all anywhere. 2) Create a reconstruction 3) list it but unlinked.

Option three seems like the best middle ground. Vininn126 (talk) 18:26, 6 January 2023 (UTC)

Option 3. PUC – 18:30, 6 January 2023 (UTC)

It should depend on whether the parent language has only one descendant or not. — SURJECTION ^{/ T / C / L /} 18:32, 6 January 2023 (UTC)

So option 3 if one desc, option 2 if 2? Vininn126 (talk) 18:38, 6 January 2023 (UTC)

Sounds good to me, or alternatively option 1 for one descendant (I don't have a strong opinion either way). — SURJECTION ^{/ T / C / L /} 18:38, 6 January 2023 (UTC)

My two cents:

• For languages that are well-attested (Old Polish, Old East Slavic for instance), reconstructing ancestors when both a parent entry and a daughter entry exists is fairly straightforward in most cases, and should just be done, linked and given.
• For more obscure languages where we can't yet reconstruct everything safely, I agree these should be skipped. But I can't even think of one such an example off the top of my head.
• For languages that only have a few inscriptions (Proto-Norse): Do we even want to have these separate from the parent language in many cases?

Realistically, for most attested intermediate languages I can think of (Old Lithuanian, Old Polish, Old Czech, Old Dutch, Old French, Old Swedish...) the corpus is more than large enough to be able to reconstruct a form for the era we're lemmatising under (and all these languages either already do or should normalise their entries at least to some extent), so we should do that and add them to the chain in my opinion. For reconstructed languages - if we're making entries for them at all, that means they should be based on some kind of model, and this model should allow for reconstructing from a parent language, provided that the daughter language is regular.

Now the only problem with any of this I can think of is irregularities in daughter languages - should we assume these irregularities are older or younger than the language we're reconstructing? In these - pretty rare - cases, I agree that we should either omit the term (so use an {{inh}} template and leave the second parameter empty) and explain the irregularities in the attested language's etymology. Thadh (talk) 23:52, 6 January 2023 (UTC)

All (1, 2, 3), but with mobility in certain conditions. Gnosandes ✿ (talk) 00:20, 7 January 2023 (UTC)

Strong 1. See User talk:Catonif#Does *farβātos exist? and User:Catonif/great-pit-cleanup, where I'm keeping the project. Proto-Italic is not the intermediate stage between PIE and Latin, it's the language reconstructible from comparison between the attested terms of Italic languages, and without any other IE data. (though if I'm not convincing enough, I can settle for 2 as well, I meant 3). Catonif (talk) 19:52, 7 January 2023 (UTC)

That sounds to me more like a Proto-Italic problem than a site-wide problem. I also disagree that it adds clutter to the pages, since ideally you'd only want Proto-Italic to be given at Latin, Umbrian, Oscan etc. entries, and it provides an intermediate form between 8000 BC and 1000 BC, which is quite a big gap. Thadh (talk) 21:01, 7 January 2023 (UTC)

Yes, it's very much a Proto-Italic problem (and I presume also Proto-Hellenic, though I don't meddle there), but it seemed like the problem was shared with this. Also, well, we seem to be going off two different definitions of Proto-Italic, for me it's the reconstructible language through internal reconstruction of the Italic languages. It might be a good thing to agree what Proto-Italic even is. Catonif (talk) 22:49, 7 January 2023 (UTC)

In an ideal world, the language we'd get through internal reconstruction would be identical to the one obtained through applying sound changes from its parent language. Sadly, we don't live in an ideal world, which is why our Indo-European etymological communities should actually work together on this rather than go by the individual sources, because an etymological dictionary that doesn't handle a single model for its etymologies is frankly useless. But yes, this is a quite broad issue and I think that it has little to do with, say, whether or not to reconstruct Old French based on Latin and modern French. Thadh (talk) 23:15, 7 January 2023 (UTC)

Proto-Italic is a good illustration of how not to handle reconstructions. There's a notoriously bad IP who gelocates to the Pays-de-Loire region of France that treats all the world's languages as their private conlang, and who is especially fond of playing with Proto-Italic. I expanded an abuse filter that I had created to keep them out of the Reconstruction namespace in October of 2021, but there are lots of edits from before that and they've gotten around it on occasion when their IPs have changed. Some of their ranges: 89.225.181.102/14 (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks), 90.12.53.215/16 (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks), 109.211.233.154/24 (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks), 2A01:CB05:8B96:E000:A5:89DF:5351:CDCD/32 (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks). They've also used the accounts Inkbolt (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks) and Dim Blob (talk • contribs • global account info • deleted contribs • nuke • abuse filter log • page moves • block • block log • active blocks). See Proto-Italic *leɣʷis for one of their creations that no one has touched.

At any rate, they may be fairly knowledgable in some areas, but they don't bother with references and they make stuff up to fill in the gaps. For every possible way to go wrong with insufficient data, I'm sure you can find an example in their contributions (8 of the first 14 deletes on your page are theirs, for instance). Chuck Entz (talk) 22:19, 7 January 2023 (UTC)

It seems the general consensus is to avoid reconstructions. Can we generate a list of possible entries to clean up? Vininn126 (talk) 21:48, 14 January 2023 (UTC)

@Vininn126: Did you just base that on three supports and two opposes? Because I'd argue we need a little more than that. Thadh (talk) 22:04, 14 January 2023 (UTC)

Option 1, in some rare cases option 3. Delete everything in Category:Proto-Albanian lemmas. Ban Proto-Armenian. These things are magnets for charlatans. --Vahag (talk) 10:30, 20 January 2023 (UTC)

@Vahagn Petrosyan: Why not just delete Proto-Armenian and Proto-Albanian and then do option 2? Thadh (talk) 13:19, 20 January 2023 (UTC)

@Thadh: I would like to be able to mention Proto-Armenian (without linking) in rare cases like *ɣwino-. Vahag (talk) 13:42, 20 January 2023 (UTC)

Maybe change it to Pre-Armenian? Like Pre-Germanic? Thadh (talk) 14:12, 20 January 2023 (UTC)

To be clear: This proposal was only for languages that we have a code from (if I understand Vininn correctly), so intermediate forms may still be given without having to link to them according to option 2 and option 1 alike. I doubt anyone's actively proposing creating Pre-Germanic entries or removing them altogether Thadh (talk) 14:15, 20 January 2023 (UTC)

Yes. Vininn126 (talk) 14:23, 20 January 2023 (UTC)

This user is adding unattested "Old Prussian" neologisms as descendants of Proto-Balto-Slavic (e.g., astars), which is preposterous because those terms have only been invented/"reconstructed" in the 21st century based on the other descendants! They're also adding attested ones but using non-attested orthography from the conlang site twanksta.org instead of actual historical primary sources (e.g., awwins instead of awins). 70.172.194.25 23:29, 6 January 2023 (UTC)

They're even changing attested terms to non-attested ones, and are obviously ignorant of Baltic morphology. E.g. this edit which changed the Prussian descendant of the agent noun *arˀtāˀjas ("ploughman") from the attested word artoys with the same meaning, to the twanksta.org neologism artuwan meaning the instrument plough (itself based on the attested form preartue). 70.172.194.25 23:38, 6 January 2023 (UTC)

Thanks, let me know if you want this IP blocked. Benwing2 (talk) 00:41, 7 January 2023 (UTC)

Well, they seem to have stopped for now, so it may not be necessary. I'll leave them a message on their talk page, and if they continue to make questionable edits after that then maybe a block would be in order. 70.172.194.25 00:44, 7 January 2023 (UTC)

Is there a procedure for this? E.g. see Æscleah, which has corresponding entries on the Northern Kurdish and Polish subdomains. 70.172.194.25 02:10, 7 January 2023 (UTC)

Unfortunately no, as each Wiktionary has its own RFV guidelines (ex: some entries on fr.wiktionary would not pass RFV here but have passed their guidelines there). Though you could maybe reach out to an editor there to get it removed. At the same time, some smaller Wiktionaries may take even longer to delete the entries as there's little moderation. AG202 (talk) 08:53, 17 January 2023 (UTC)

There is fairly wide consensus that we shouldn't have affix templates on nonlemma forms. What about if there is an adverb, particle, etc. that contains case suffixes? They are etymologically case forms, but are not inflected (outside of possible alternative forms which may have different case endings). An example of such a case is seinemmälle. It is etymologically an allative singular inflection (-lle) of a comparative form of seinä (despite it being a noun, as usually only adjectives have comparative forms, but the comparative form *seinempi does not exist outside of the case forms used as adverbs).

Possible options:

1. Simply write out "(from?) (the) allative singular of {{m|fi|...}}" in the etymology.
2. Implement a template like {{inflection of}} that is meant to be used in etymology sections (like {{initialism}} for etymologies, {{initialism of}} for definition lines).
   1. The template does not categorize anything.
   2. The template only categorizes into a single category per language.
   3. The template categorizes by form (and language, naturally).
3. Use affixation templates. Write out the case that is represented either in the text, or use |posN=, |qN= to mark the case ending specifically.

Apparently Arabic has {{adverbial accusative}} for something like this.

(Bonus question: loitommalle is a case where all three external locative forms (i.e. a subset of all possible case forms for nominals) exist, but none other do. seinemmälle only has two of the three. Finnish has quite many of these - perhaps there is a case for avoiding duplication/redundancy with etymologies?)

@Vininn126, Thadh, Theknightwho, Fenakhay as users who were involved in the original Discord discussion. — SURJECTION ^{/ T / C / L /} 21:25, 7 January 2023 (UTC)

I personally would prefer a template, if it were to categorize it should categorize into one category. The reasons for this are:

1) if we allow for affixation categories of just an ending, then people will wonder why we might categorize non-lemmas and ask why we don't add the affixes to each non-lemma. I recognize this is probably my weakest argument, since we can add a rule saying "don't add etymologies to non-lemmas", but I still foresee some sort of issue.

Vininn126 (talk) 21:32, 7 January 2023 (UTC)

When discussing how to mimimise duplication when documenting non-lemmas, it was agreed that non-lemmas could have etymologies. An example is mice. --RichardW57m (talk) 13:30, 11 January 2023 (UTC)

2) It gives a sort of weight to these terms, which I believe the other methods don't. These are lemmas after all, and something special is happening with their lexicalization, that should be represented somehow, and I feel an affix template or something else doesn't quite get the job done. Also, I don't think these categories will be overly populated, but I'm sure some language out there might prove me wrong. Until then, I think it makes a certain sense.

Vininn126 (talk) 21:32, 7 January 2023 (UTC)

So far, I have approached this with the first option (cf. Ingrian alemmaal, hyvin), and I'm quite happy with it.

I don't think categorisation is a good approach here, but I would be fine with a non-categorising template.

Alternatively, categorisation is fine by me, as long as we try to keep these forms to a minimum - i.e. categorising loitommalle as inherited from Proto-Finnic *loit'omballek, which is morphologically regular and expected from a reconstructed lemma form, and reserving the categorisation for such cases like seinemmälle, where it appears there was no regular counterpart at any point in time. Thadh (talk) 21:38, 7 January 2023 (UTC)

We have a precedent with -es, which is referenced in the etymology of once. --RichardW57m (talk) 13:30, 11 January 2023 (UTC)

This user is hard to work with. He ignores rules, he edit wars, he doesn't want to cooperate. I don't know what to do.

Proto-Slavic:
*rarog - he pushed fringe theories that are ignored by 95% of modern etymologists. He didn't mention single source stating that etymology, he warred even after I added like 4 sources (9 at the end) for fixed etymology. We spent few hours on discord explaining to him why it his etymology doesn't make any sense, didn't work.
*grimati - another absurd edit warring without single word of explanation. He stated that etymology is unknown even tho all dictionaries explain etymology of that word. Again, we spent few hours talking about it without good result. We even emailed {{R:sla:ESSJa}} to make sure...
He just reverted my change at *voľa - he pushes his own rules against our rules: for Proto-Slavic we accept accent paradigms (a), (b) or (c) only and we have templates supporting only these, other paradigms are not very popular in scientific community and we should use traditional ones (WT:ASLA). Again, he doesn't care.
Polabian
I started editing this language some time ago and my goal I want to make WT have all its words. About was missing so I made WT:APOX, also to standardize our alphabet. I proposed the most popular one used by {{R:pox:SejDp}} with small changes. The author of this alphabet is perhaps the most significant researcher of this language, and the alphabet I have proposed is used in his last work ({{R:pox:Polanski:2010}}). However, Gnosandes keeps ignoring that and use simplified alphabet used in {{R:pox:Polanski:1967}} which is not that popular. Additionally, a few days ago I made a template ({{R:pox:Olesch1983}}) for dictionary that Gnosandes published on webarchive, and this researcher also uses the alphabet I proposed, which Gnosandes also ignores. Additionally I mentioned more sources that use my ortography, that also was ignored. "Problematic" letters: ʒ vs dz (always preffered ʒ), i̯ vs i (diphthong, usually prefered i̯), u̯ vs u (diphthong, usually prefered u̯), χ vs x (variously). Additionally ʒ, i̯, u̯ and χ are used in Slovincian, and these letters are also used by uk.wikt and pl.wikt (only 2 wiktionaries with a lot of Polabian words), changing the alphabet so it fits his weird ideas will break interwiki.
So that is it. Sławobóg (talk) 21:47, 7 January 2023 (UTC)

@Sławobóg This is not the first time people have complained about this user. He has been blocked several times in fact, as you can see here: Not only does he seem to believe in and push fringe Slavic theories but he has several times injected political commentary into usage examples (and been blocked for doing so). I'm not sure what the correct response is, maybe we need to block him again. User:Atitarev can you comment as you've dealt more directly with him? Benwing2 (talk) 02:22, 8 January 2023 (UTC)

@Sławobóg, Benwing2: My personal negative experience with Gnosandes was mostly limited to his pushing some political garbage in usage examples you can hear from pro-Putin channels, his failure to stay neutral and his whataboutist responses. That was back in July, though. I haven't checked or noticed anything since then. I also dislike his failure (in some instances) to apply normalisation and standards accepted by the community to Slavic entries and share your dismay. Anatoli T. ^{(обсудить}/^вклад) 02:40, 8 January 2023 (UTC)

My experience with the user is a general lack of a want to cooperate and instead focuses on what he believes I am saying rather than actually responding ot what I am saying. Either there is a language barrier or a lack of willing to cooperate, either way, it's nigh impossible to get anything done. Vininn126 (talk) 10:42, 8 January 2023 (UTC)

It's both but more the latter. Should have been perma-blocked a long time ago. -- Skiulinamo (talk) 10:51, 16 January 2023 (UTC)

(Continued from Module talk:quote#Archiveurl and Archivedate, pinging @Sgconlaw) I would like to be able to edit and preview changes for Template:cite-meta. I haven't touched templates for the most part so far, but I have made edits on Module:quote which were well-received and I plan to do more template edits in the future. If there are criteria I haven't yet met, please let me know. Ioaxxere (talk) 17:47, 8 January 2023 (UTC)

• Support. — Sgconlaw (talk) 18:09, 8 January 2023 (UTC)
• Support. Competent editor, and I like not having to type out dates for archiveurl's. 70.172.194.25 08:05, 10 January 2023 (UTC)

@Sgconlaw does this pass? Ioaxxere (talk) 01:07, 3 February 2023 (UTC)

Mervat (WMF) (talk) 13:12, 10 January 2023 (UTC)

I asked a question about scatenatosi that led to a wider discussion about such forms. I'm moving it here to get a broader perspective.

(begin copied discussion)

(Notifying GianWiki, SemperBlotto, Ultimateria, Jberkel, Imetsia, Sartma, Catonif): I was under the impression that past participles with enclitic -si were archaic, but I can find many examples of scatenatosi, scatenatasi etc. in recent texts. Is this a special case or is it relatively common? Are there other reflexive past participles like this? Benwing2 (talk) 02:20, 9 January 2023 (UTC)

@Benwing2 Not a special case. Participles with -si are archaic when being participles (i.e. we now say si è scatenato and not è scatenatosi) but are still in use as adjectives (or other specific formations), eg:

• La guerra, scatenatasi nel 1500 in Germania, giunse finalmente al termine. — The war, unleashed in 1500 in Germany, finally came to its end.
• Scatenatosi, si calmò. — having gone wild, he calmed down.

Catonif (talk) 08:32, 9 January 2023 (UTC)

@Benwing2: Not a special case (and pretty common indeed), as per Catonif's explanation. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 10:35, 9 January 2023 (UTC)

@Benwing2: I believe Catonif explained it pretty well. — GianWiki (talk) 17:41, 9 January 2023 (UTC)

@Catonif, Sartma, GianWiki Hmm. I presume that not all reflexive past participles can randomly be used as adjectives ending in -si (similarly to how only certain past participles in English can function as adjectives). If so, then where can I find these reflexive past participles (functioning as adjectives) in dictionaries? Treccani, for example, has scatenato listed under scatenare but not scatenatosi. Hoepli and Olivetti similarly have entries for scatenato but not scatenatosi, and none of these entries give any examples containing scatenatosi. Can you give some other examples of adjectives ending in -atosi, -itosi and -utosi? Benwing2 (talk) 19:05, 9 January 2023 (UTC)

@Benwing2 If a verb can take the -si, so can the participle: trovatosi, tramutatosi, credutosi, mangiatosi, etc. It's probably more rare and literary if the -si is reciprocal: *conosciutisi sounds very old-book-ish, and might not even exist. As said above, no *andatosi can exist (since there can be no *andarsi) but andatosene can (because andarsene). Dictionaries don't have them because they're non-lemmas. Catonif (talk) 19:36, 9 January 2023 (UTC)

@Catonif: andatosi can exist, though, if the si is borrowed from another verb: «Così dopo pochi giorni il Brutto Anatroccolo si svegliò, ed andatosi a specchiare nello stagno vide che tutte le sue piume erano diventate bianche come il latte, e la sua goffaggine si era trasformata in un portamento elegante ed aggraziato: era diventato un cigno!». — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 11:10, 10 January 2023 (UTC)

Aha, you're right! Catonif (talk) 15:17, 10 January 2023 (UTC)

Maybe it's worth noting that the -si is -mi for first person singular.

• Credutomi spacciato, mi arresi. — Believing I was done for, I surrendered.

Formations with -oti (2s), -ici (1p), -ivi (2p) and -isi (3p) on the other hand all sound old to me. Catonif (talk) 19:55, 9 January 2023 (UTC)

@Catonif OK. I'm asking because awhile ago I deleted a bunch of such forms that were auto-generated, on the theory that they were obsolete and needed individual attestation. One such example of many is amatosi; you can see the deletion message, including the old content. conosciutosi also was auto-generated and later deleted. andatosene still exists. This leads to a bunch of questions, e.g. for reflexive verbs we currently display the past participle without any clitics, e.g. andarsene just lists its past participle as andato. Should the clitic-full forms be listed instead, or in addition? And how do we know automatically (maybe not possible) whether a given reflexive verb has such a form? For example, conoscersi does exist, and for this reason SemperBlotto auto-generated *conosciutosi. Benwing2 (talk) 20:59, 9 January 2023 (UTC)

BTW in your examples Scatenatosi, si calmò and Credutomi spacciato, mi arresi, the participle is behaving like what in Russian would be called an adverbial participle (which has a distinction between adverbial and adjectival participles, each of which can be active or passive and if adjectival can also be distinguished as present or past). (In Latin they would likely use an ablative absolute in these circumstances.) Not sure how to gloss such usages in Italian. Benwing2 (talk) 21:10, 9 January 2023 (UTC)

Yes, "ablative absolute" is exactly how I would describe it. Catonif (talk) 15:17, 10 January 2023 (UTC)

Related question ... present participles? I find recent examples of scatenantesi, is the situation the same with these as with past participles or are there some extra nuances here? Under scatenarsi the present participle is given just as scatenante, should it be scatenantesi instead or in addition? Benwing2 (talk) 06:59, 10 January 2023 (UTC)

@Benwing2: I personally think that in cases like andarsene we should give andatosene as a past participle; I find it clearer, and if I was a learner that's what I'd prefer.

Participles are indeed used like the ablative absolute in Latin, to form what in Italian are called "implicit relative clauses" (proposizioni relative implicite), and can use both past and present participles. (See for example: Relativa implicita > Participio)

Our attestation principle doesn't go well together with grammatical forms like the one we are discussing, since any native speaker could come up with something "never said or written" any time, as long as it is allowed by Italian grammar. Whatever is grammatically possible might be written or said, the fact that you can't find it online doesn't mean it's not Italian or that it cannot exist. I believe dictionaries should also give you "possible" forms, not only "attested" ones, but I do understand that this is a different, and much bigger topic.

So, when it comes to participles with pronouns attached to them, as long as we keep our criteria for inclusion the way they are, the job of determining what should be given and what not is going to be colossal... — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 11:29, 10 January 2023 (UTC)

@Benwing2: Random comment, but I wouldn't consider conosciutosi wrong. It's usually found in the plural conosciutisi or conosciutesi, but since we always give the masculine singular as a citation form, we have to go with conosciuto here. This doesn't mean that the past participle of conoscersi doesn't exist, though. It's only rare to find a context that would require that form, but nonetheless not impossible at all: «e via via, conosciutosi il suo valore, egli entrò in relazione con dotti e illustri uomini» (Here, for example. A bit old, but still modern Italian. In this case the si is not reflexive, but impersonal, but still). I could say "Conosciutosi meglio, Giovanni fu finalmente in grado di modificare il suo comportamento". It's unusual, but neither impossible nor wrong. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 11:44, 10 January 2023 (UTC)

@Benwing2: Same goes for amatosi: «I due, amatisi a Roma, avevano deciso di divorziare dai rispettivi consorti per unirsi in matrimonio.» From here — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 11:46, 10 January 2023 (UTC)

@Benwing2 I'd discourage the presence of these forms as entries here, as they don't mean anything more that what they are formed by, just like I'd discourage conoscerla, trovarci, saperne, etc. and as I would also discourage conjugation boxes on verbs with particles attached to them, like andarsene, trovarsi, andarci, comprami, etc. These particles dance around a sentence without a single care (even more so in older texts), and the fact that there's no space between them and the unlucky word they'll stick on is mostly an orthographical matter, and shouldn't distact the learner into thinking that these are "new" words. Having all the possible combination of particles on top of every verb form (because yes, nothing stopped Dante from saying fécemi or trarròtti) of every verb really doesn't seem ideal. They might have occasionally helped learners but it would take us all the way to fàbbricamicene. These are the problems that arises with this current system, and I have no good solution if not just ditching it and 1) removing conjugation boxes from particled verbs and 2) removing combined forms. Of course I realize this would take time and thought and discussion. Catonif (talk) 15:17, 10 January 2023 (UTC)

(end copied discussion)

Several users e.g. User:Catonif and User:Sartma make some very good points. My personal take is it's fine to include conjugation tables esp. of reflexive verbs (e.g. ritenersi) and probably also verbs with attached particles (e.g. andarsene) but I don't see the point of creating combined forms like aggiustarmela or agitali except maybe in a few cases where there are irregularities or archaic forms involved, e.g. andovvi and the above-cited trarròtti. I also don't see the point of including combined forms in verb conjugation tables in most cases. (We do this for Spanish but not Italian; it makes a certain amount of sense in Spanish because the rules for accent placement are somewhat complicated and get messy when you have particles attached, but this doesn't apply to Italian.) However, we have 15,000+ entries currently in Category:Italian combined forms. Per our WT:CFI, I'm not sure I can just mass-delete them (as I'd like to do) and nothing prevents an energetic user with a bot from creating a zillion more. I wonder if we need to rethink or at least clarify the rules for such combined forms in Italian. See also Wiktionary:Requests for deletion/Non-English#essersi, where User:Fytcha enumerated some potential rules for situations like this. Benwing2 (talk) 03:00, 11 January 2023 (UTC)

I've just implemented this template/module. The rationale behind this is that our English entries usually have better categorization, labels and {{place}} arguments than their non-English counterparts. By using this template, we ensure that the non-English entries get all these nice things, too, without editors having to tediously copy-paste the senses over. Furthermore, changes or fixes to the English sense automatically propagate to all non-English entries. Note that this template may only to be used for terms that have perfect translations between languages. Terms that have perfect translations are predominantly those that are "accepted to be prescribed", in practice they are mostly proper nouns (especially toponyms) or scientific vocabulary (taxonomic names, units, mathematical objects etc.).

For this template to work, the English donor sense has to be annotated with {{senseid}} (right after the #). If there is no {{senseid}} present and if you're about to add it, please briefly check whether Wikidata has an entry for the referent and if so, use Wikidata's Q... code as the senseid.

For the categories to propagate, they have to occur in the definition line, too. This style is not that common on Wiktionary at present but I'd argue that it is the most sensible thing to do anyway, even if it weren't for this template. IMO, the best place to put them is between {{senseid}} and {{lb}}.

If there is interest in this template, I'll write the documentation and fix the sortkey shenanigans that are currently going on. Ideally, I'd also want it to propagate the "firstness" (the property that that entry appears as the first one within a topical category, see e.g. koira in Category:fi:Dogs) because firstness is invariant under perfect translation.

It currently doesn't work with United States of America due to some interference between {{,}} and {{place}}: {{,}} appears outside of {{place}} in the English entry but {{transclude sense}} moves it inside in non-English transclusions (compare English Belgium / Romanian Belgia to see why). I've looked at the template code generated by {{transclude sense}} and it looks fine so the issue is on {{place}}'s end (i.e. {{place}} misinterprets the HTML generated by {{,}}).

For examples of this template in action, see Romanian Belgia, Romanian hidrogen, Portuguese Atari. Any feedback welcome. — Fytcha〈 T | L | C 〉 14:53, 11 January 2023 (UTC)

I have been thinking about a template like this for a long time - it's more easily machine readable and easy to link definitions. In theory this template can be modified to link to the given definition, no? The sameway senseid's work.

I think we could potentially add a bunch of senseid's to defs from WikiData automatically, particularly pages with one def, and check other pages (I'm thinking of things like boring adverbs and such), potentially check trans boxes and also pages with only one defline and convert them. Vininn126 (talk) 15:06, 11 January 2023 (UTC)

@Vininn126: In theory this template can be modified to link to the given definition, no? The sameway senseid's work. It already does that. It generates a link to the correct English entry and sense and then displays the English definition as the gloss (which can be turned off using |nogloss=1 but I'd argue should be left as is for almost all entries). Check out the three examples I've provided. — Fytcha〈 T | L | C 〉 15:16, 11 January 2023 (UTC)

That's definitely ideal, then. Obviously my suggestion is for words with one def, and this is better for words with many defs. If it's things like chemical compounds or elements or such, then we're in luck. Vininn126 (talk) 15:19, 11 January 2023 (UTC)

Like {{desctree}}, this depends a lot on the details of another entry without any indication visible at the other entry. That makes me nervous. It also reads the wikitext of the other entry into Lua memory, which is the kind of thing that makes Han-character entries such memory hogs. I can see how this might cause problems in pages where there are lots and lots of languages with the same spelling for the same thing. Used in the right entries in the right way, it will be good- but we have no control over that. Chuck Entz (talk) 15:48, 11 January 2023 (UTC)

That's a double edged sword - there will be times where making mass updates will be good, and itmes where the defs don't exactly line up. In the second, the template should not have been deployed in the first place. Vininn126 (talk) 16:13, 11 January 2023 (UTC)

@Chuck Entz: Those are two valid concerns. When I considered implementing the template, I just thought the benefits outweigh the downsides.

As for memory: This template, of course, increases the memory consumption on pages it is used on, no question. To give some figures: revision 70798354 (10 {{transclude sense}}) uses 14.1±0.013MiB, revision 70439449 (no {{transclude sense}}) uses 12.8±0.028MiB (N=10). However, this is overly pessimistic because we'd need to compare the consumption of two visually identical pages as the former revision displays more information than the latter. Another point is that this template still has a lot of potential in terms of memory-efficiency; during development, I managed to reduce its memory consumption to about half of what it initially was. I still don't understand all the nuances behind how much memory frame:preprocess and frame:expandTemplate consume but I firmly believe there is more to be squeezed out of them than what I arrived at by more or less trial and error. Furthermore, comparing Fenakhay's and my revision on (history) Belgia, it is clear that the module doesn't memoize at all (between invocations on the same page), even though the entire parsing phase is wholly language-independent (i.e. is identical among all invocations of {{transclude sense}} on Belgia). I don't know if there is a solution to this but if there is, this is going to be another huge improvement on pages with many languages and one common referent.

As for inadvertently causing errors in another article à la {{desctree}}, that is true and it is a problem, but I'd say it becomes less of a concern the more robust and mature {{transclude sense}} grows. Moreover, carelessly changing the {{senseid}} in an article is already an error (in that it causes dangling links) even if it is not currently a Lua error, so this template converts this kind of silent error into loud (and thus fixable) ones (which is good). — Fytcha〈 T | L | C 〉 16:29, 11 January 2023 (UTC)

• "I don't know if there is a solution to this but if there is, this is going to be another huge improvement on pages with many languages and one common referent." I don't think there's any way to pass/store data between different module invocations. This is an intentional choice on the part of the Scribunto developers, because it would interfere with Parsoid's design goals. Even if there were a way around this, it would be considered a defect to be removed and therefore couldn't be relied upon.
• From a few experiments (invoking Module:Sandbox/43 in WT:Sandbox with various parameters), it seems like there might already be some kind of caching between calls to mw.title.new(...):getContent() for the same title, so that doing so over and over "only" adds a constant amount of memory each time (~82 KB) that seemingly doesn't depend on page size, but calling it with previously unseen titles adds more. The processing itself could not be cached, though. 70.172.194.25 06:21, 13 January 2023 (UTC)

I'm not persuaded that a Lua function is better than a system of templates. I think a family of templates (one per sense maybe plus some general templates) would be better:

(1) It avoids the problem of running out of memory for Lua.

(2) Quite possibly quicker.

(3) Already tooled up for tracking usage, e.g. when we find that technical words have multiple meanings in English but not in other languages.

--RichardW57m (talk) 16:12, 12 January 2023 (UTC)

Many languages have a different focus than others on what a country is, or what hydrogen may signify: I'm sure your average Ingrian speakers doesn't care that the Netherlands are "the main constituent country of the Kingdom of the Netherlands, located primarily in northwestern Europe bordering Germany and Belgium", they just care that it's a country in Europe, so giving all this encyclopedic information is completely useless, and also lexicographically not faithful to the speakers' world view. As such I'm not sure how useful this template is, since it essentially reduces definitions to a kind of machine code, whereas our entries should ideally aim to describe the definitions with relation to the speakers' world views. Thadh (talk) 17:08, 11 January 2023 (UTC)

Although that's a fair point in principle, I'm not sure that in practice having "Budapest (the capital city of Hungary)" manually duplicated 10 times at Budapest provides much insight into Weltanschauungen. Fytcha did say "this template may only to be used for terms that have perfect translations between languages", which seems like an adequate proviso to me. —Al-Muqanna المقنع (talk) 17:23, 11 January 2023 (UTC)

As long as it is, that seems fine; I'm just saying it shouldn't be used indiscriminately and added by people that don't know the language. Thadh (talk) 18:05, 11 January 2023 (UTC)

Yeah, I kinda agree that the benefit of having an explicitly written gloss for common words is unclear to me, especially when repeated over and over on the same page, even if the fact that we can do it is technically cool. For example, Fytcha put this on hidrogen#Romanian, but I'm not sure I actually find that any more aesthetically pleasing, or useful, than the simpler definitions above. I can also imagine that someday someone feels like adding more detail to the English entry, which will then make the already long gloss even longer. Ultimately this is basically a stylistic preference, I suppose. 70.172.194.25 06:51, 13 January 2023 (UTC)

Thanks for the feedback. Maybe it is indeed ultimately a stylistic preference but I think there are some (perhaps underappreciated) objective facts that should at least inform our perception of this matter. For instance, I don't find it particularly satisfying if an entry such as Nullvektor contained nothing more than what is basically a soft-redirect to the English entry zero vector because if a reader who is unfamiliar with both Nullvektor and zero vector looks up Nullvektor, we force additional cognitive workload on them by only telling them the meaning of the German term by transitivity (i.e. we force them to learn the English middleman and only then do we allow them to figure out the meaning of the German term). We also force them to visit one more page. It's particularly bad if the reader is interested in different aspects of the German word (e.g. first the meaning, then the gender) because they are then forced to jump back and forth. All this is solved by just having the mathematical definition in the German entry as well.

Intuitively, many editors seem to dislike it if non-English entries contain more than a simple soft-redirect. I share this intuition but I'd say it mostly stems from a desire to reduce redundancy which this template takes care of without having to sacrifice self-sufficiency. I strongly disagree with the notion that non-English entries don't have a right to self-sufficiency; I understand Wiktionary as a multilingual dictionary, not as an English dictionary with some (bidirectional) translations. — Fytcha〈 T | L | C 〉 12:04, 16 January 2023 (UTC)

I, too, share this feeling. I really hate synonym listing and gloss-less defs. Vininn126 (talk) 13:03, 16 January 2023 (UTC)

@Thadh: If it doesn't fit, don't use it. This doesn't take away from the fact that there are cases where it is fitting. Additionally, the gloss can be suppressed using |nogloss=1 which still gives you the benefit of labels and categories being propagated (which less well documented languages usually direly lack). In the case of a non-English term linking to Netherlands, I disagree that the gloss is encyclopedic, it serves to disambiguate the polysemic English translation. Even if it weren't for that, I would, while reading a dictionary, never take the degree of verbosity of a gloss to be a reflection of the average native speaker's attitude towards the referent; I would have never taken the presence or absence of |nogloss=1 as a documentation of how much the average Ingrian speakers cares about the legal minutiae of the Netherlands. — Fytcha〈 T | L | C 〉 17:51, 11 January 2023 (UTC)

I'm sure there are plenty of cases where two groups share the same reality and view of a word in which case it completely makes sense to link them, as we already do with senseid. If they are different, we shouldn't link them, as mentioned in the original post. Vininn126 (talk) 17:58, 11 January 2023 (UTC)

I love this! I was recently lamenting the lack of something similar when editing the entry maguey that English has borrowed from the Spanish. It seemed unfair (although perfectly understandable) that the Spanish definition of maguey was maguey while the English contained a full gloss. This is a great solution. Could it also be used as a replacement for {{syn of}} for words that are perfect synonyms within the same language for something like condicionado? What about some sort of {{transclude lemma}} for forms? JeffDoozan (talk) 17:56, 11 January 2023 (UTC)

This is an interesting idea but I fear it might be TOO broad sweeping - there might be times where a word is expanded and has some new senses not shared by other languages. Vininn126 (talk) 17:59, 11 January 2023 (UTC)

I meant for transcluding senses/lemmas within the same language, to avoid duplicating the sense text between synonyms or for showing the lemma's senses on the form's page. I agree it would not be ideal for transclusions between languages for the same reason you stated. JeffDoozan (talk) 18:08, 11 January 2023 (UTC)

That makes sense, sorry. Vininn126 (talk) 18:12, 11 January 2023 (UTC)

@JeffDoozan: Thanks. An analogous template for terms within the same language could be implemented but I'd be very wary of that; perfect synonymy is much rarer and much harder to identify than perfect translationhood. — Fytcha〈 T | L | C 〉 13:18, 12 January 2023 (UTC)

I can't support it for the same technical reasons that were pointed out above, and Thadh's concerns also make me feel like this isn't really a good idea in practice. — SURJECTION ^{/ T / C / L /} 18:24, 11 January 2023 (UTC)

Agreed. The idea is good, but the implementation (inevitably) hacky. We need a real datastore, not more regular expressions. – Jberkel 20:18, 11 January 2023 (UTC)

@Jberkel: I'd argue, if you like the idea but not the current implementation, having (and using) this template is still a big plus. Once we figure out a better implementation, the information of what is a perfect translation of what will already be here (in the form of {{transclude sense}} invocations). — Fytcha〈 T | L | C 〉 13:18, 12 January 2023 (UTC)

I like the idea of having a single place for the meat of the definitions, but i do not like the idea of using templates to make a kludge like this. If anything, we should be tearing down as many of our existing kludges as possible, or we will never get rid of eternal grievances like Lua memory errors. The correct solution for consolidating data is to complete restructure the dictionary into something machine-readable instead of the semiformatted wikitext we have now, but WIktionary would stop being Wiktionary at that point. — SURJECTION ^{/ T / C / L /} 15:21, 12 January 2023 (UTC)

Hear, hear!, to the idea of reducing kludginess.

Note sure I agree that doing so would un-Wiktionarify Wiktionary. I refuse to accept that kludges are any inherent part of our identity as a community of editors. 😄 ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:48, 12 January 2023 (UTC)

This seems OK only when used for the lack of anything better. But what we call synonyms in English are often merely near-synonyms. I doubt that the situation differs in other languages. I would expect that meanings would evolve differently in different languages and that different levels of detail and different nuances/connotations are appropriate for different languages. I don't think this should ever over-ride an existing definition that consists of more than a single term. It also has no bearing on a one-word gloss in any language where the one English word is polysemic. DCDuring (talk) 19:00, 11 January 2023 (UTC)

Meh. This seems like it could work for placenames; I'm not sure what else would be so perfectly synonymous, so I might be wary of having it as a general template people are liable to widely misuse, since people are already, in this thread, floating using it for things like synonyms within the same language, which {{synonym of}} or just defining Barfoo as "# ]" is for.
There are a few things it might be helpful if we could store in a more database-like structure which multiple entries could pull from, perhaps most famously etymologies (so that if it's thought English borrowed foo from Hindi, which borrowed it from Tibetan, and this gets propagated out to every other language which borrowed foo from English so they all say they got it "from English, from Hindi, from Tibetan", but we later find the English word is actually from Persian, from Arabic, we don't have a zillion still-wrong entries after someone fixes the English one), but also this kind of thing (recording in one place that City X is in Area Y). (I suppose, technically, this type of thing would also allow displaying the definitions of flavouring / flavoring in two places at once...) - -sche (discuss) 22:17, 11 January 2023 (UTC)

@-sche: I'm not sure what else would be so perfectly synonymous Scientific vocabulary (at least in the hard sciences); I've just created Nullvektor using this template. — Fytcha〈 T | L | C 〉 13:18, 12 January 2023 (UTC)

There are plenty of situations where there is an exact translation. Vininn126 (talk) 13:52, 12 January 2023 (UTC)

Yeah, I'm a bit confused by the comments about how no/very few words have exact translations etc. There's a huge domain of technical vocabulary with objective referents, terms that are typically either shared as internationalisms or translated via calques. What might be useful is to have the template add entries to a hidden maintenance category that can be monitored for abuse. —Al-Muqanna المقنع (talk) 16:03, 12 January 2023 (UTC)

Not only that but also certain things like specific colors or even everyday vocabulary like "dictionary" or "guitar"... Or even everyday verbs. A maintenance category could be good. The concern raised earlier about a change to an English page radiating to many other pages is a real concern. I'd still like to get a bot to assign ID's to definitions, however. Vininn126 (talk) 16:12, 12 January 2023 (UTC)

Can you give examples of reliable colours? Basic colours are notoriously linguistically variable. Verb equivalences tend to be inexact. --RichardW57m (talk) 16:37, 12 January 2023 (UTC)

These tend to be the fancier ones, like alabastrowy and alabaster. Vininn126 (talk) 16:44, 12 January 2023 (UTC)

How would we handle the sudden recognition of a difference between English homomorphism and French homomorphisme. It's only in French that I've seen the requirement that such functions be open mappings, i.e. map open sets to open sets. --RichardW57m (talk) 16:20, 12 January 2023 (UTC)

I assume the same way we would handle it now, by either a usage note or by changing the gloss (and removing the template). Such a difference is not mentioned in the existing entry either. Someone with more maths knowledge like @Fytcha can probably comment. —Al-Muqanna المقنع (talk) 16:38, 12 January 2023 (UTC)

Ah, I overlooked that the proposed system still generates a link to the English term. Sorry. --RichardW57m (talk) 16:55, 12 January 2023 (UTC)

I personally find this neat. Nonetheless, all the technical concerns mentioned above are more or less valid. They're not unique to this template, and would also apply to a host of widely used CJK templates (including but not limited to {{zh-see}} and {{ja-see}}), {{desctree}}, {{senseno}}, and probably lots of others. For the Lua memory issue in particular, it probably won't be much of a problem if one simply refrains from using this on pages near the memory limit (e.g., it's fine to use on something small like Nullvektor, we obviously wouldn't want to use it on a). Along the lines of Chuck Entz's comment, the issue of senseids potentially getting out of sync comes to mind. I definitely don't think this should (at least for now) be adopted as a standard or that we should have a bot mass-convert entries to use this, but small-scale experimentation seems alright. Then we can see how it empirically works out in practice with all the potential issues people are raising here, vs. the potential benefits. 70.172.194.25 06:21, 13 January 2023 (UTC)

Perhaps not convert, but mass ID assigning is going to be a pain in the tuchus. Vininn126 (talk) 11:31, 14 January 2023 (UTC)

Over the years, we've dealt with challenged reconstructions in different places: WT:RFDO, the Etymology scriptorium(s), and currently WT:RFVN. I think we should have a dedicated page for these. Reconstructions are different from regular entries because they're an outgrowth of the etymologies and because they are, by definition, not attested. Also, RFVN is seriously overloaded due to how much longer it takes to verify entries in many languages.

I propose we create a page called "Requests for verification/Reconstruction" with an alias of "WT:RFVR".

We should create it using the method we use for the monthly forum pages: move the latest Etymology scriptorium page to that name, then move it back and replace the redirect with the appropriate content for an rfv page. That will add it to the watchlists of everyone who has the Etymology scriptorium page watchlisted. I'm suggesting that because the closest thing to the new RFVR is the requests for verification of etymologies (tagged with {{rfv-etym}}). The only difference is that this involves an entry which is proposed for deletion rather than an item in an etymology. The people involved and the methods of resolving the request are basically identical.

The rest of the tasks for setting this up are pretty straightforward: changing the code in the modules behind the {{rfv}} template to point to RFVR instead of RFVN when the entry is in the Reconstruction namespace, changing the display for that template, and changing the documentation for the template and in whatever WT-namespace pages deal with reconstructions, verifications and discussion pages, and perhaps a maintenance category or two. Chuck Entz (talk) 19:30, 13 January 2023 (UTC)

Perhaps the page should be *Requests for verification/Reconstruction with a star At this point, anything to reduce the RFV pages would be nice. I agree that reconstructions are special. Vininn126 (talk) 19:49, 13 January 2023 (UTC)

Support. 70.172.194.25 20:01, 13 January 2023 (UTC)

Support as above (and yeah, anything to trim WT:RFVN) —Al-Muqanna المقنع (talk) 20:11, 13 January 2023 (UTC)

Support. BTW Maybe it's time to implement the split of RFVN for Italic or Italic+Greek (or just Romance). This was discussed when I split CJK out of RFVN but never implemented. Thoughts? Benwing2 (talk) 07:29, 14 January 2023 (UTC)

@Benwing2 Yes, sorry for not replying there, but let's do it! AG202 (talk) 13:50, 7 February 2023 (UTC)

Support. — Fenakhay ^{(حيطي · مساهماتي)} 08:50, 14 January 2023 (UTC)

We don't "verify" reconstructions, as they are by their nature unattested. The RFV process is irrelevant to reconstructions. The page should be called Wiktionary:Requests for deletion/Reconstructions. Definitely support the idea though - I've considered raising this myself. This, that and the other (talk) 06:20, 15 January 2023 (UTC)

Support Sławobóg (talk) 13:16, 19 January 2023 (UTC)

Support. Thadh (talk) 13:32, 19 January 2023 (UTC)

Support. Gnosandes ✿ (talk) 08:56, 20 January 2023 (UTC)

Support. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:55, 24 January 2023 (UTC)

This has clear widespread support, and RFV NE is nigh unusable. Can we move ahead with this? What is the next step we need to take? Vininn126 (talk) 18:19, 31 January 2023 (UTC)

@Chuck Entz I will even help as I can. Just need to know what to do! Vininn126 (talk) 13:47, 7 February 2023 (UTC)

Wiktionary's current policy requires that for words with multiple etymologies, the headers be nested with Etymologies be L3, the words be L4, and additional notes be L5. By itself this is a very good idea, however L5 headers do not seem to be supported by Wiktionary. On PC L5 headers are not visually different from L4 headers and, even worse, on Mobile L5 headers completely break and turn the header into plain text. This completely defeats the purpose of nesting by making it difficult to find usage notes, synonyms, etc. (You can test this by visiting beat on a mobile device and a computer) as such I think it would be best to limit headers to L4. As L5 headers are either the same as L4 or break the layout, I dont believe there's any benefit to having them.

However, I am only requesting this due to L5 headers not being supported. If Wiktionary is working on a fix (I haven't seen any announcements) then I DO NOT want this to go into effect.

Edit: as for replacements maybe we could make all L5 headers indented L4 headers? at least that way they'd be visible. Sameerhameedy (talk) 03:23, 15 January 2023 (UTC)

Completely disagree. L5 headers are everywhere (for good reason) and the fix is to figure out how to make them show up better esp. on mobile, and not to disallow them. Benwing2 (talk) 07:27, 14 January 2023 (UTC)

But haven't L5 headers been required by policy for a few years now? I don't know exactly when it became required but Wiktionary started about 2 decades ago, It doesn't seem like they have and plans to add in L5 headers anytime soon. Since it's a problem with the website and not the policy, there's really nothing us users can do to make it show up better. It seems like this is a backend problem.

Perhaps all current L5 headers can become indented L4 headers? that way they'd be visibly different and won't break on mobile. Sameerhameedy (talk) 03:23, 15 January 2023 (UTC)

Thanks for bringing this up. I've been frustrated by the limited nesting ability too, and on a private wiki I switched to using indentation instead, like with discussion threads, so I could have unlimited nesting. I doubt that solution will catch fire here, though .... I've never seen it used anywhere else at all.

Anyway, the formatting is the same on Wikipedia ... there aren't too many articles that get that deep, but I've seen it from time to time where a section title just appears as a normal word. On Wikipedia, I dont think it's so bad, since the header is always on its own line, and Wikipedia has very few content sections that are just one word or even sentence long.

I hadnt known about L4 and L5 headers appearing the same .... I've been using custom color highlighting, and so for me they're distinguished by color and not by size. I doubt that solution will catch on here either, and like my indentation idea, I've never seen a wiki that uses color to distinguish headers from content and from each other.

It seems that the L4 and L5 headers are just written in the code of <h4> and <h5>, which surprises me a bit ... in theory, if this thread doesnt come up with any good ideas, we could offer a custom CSS snippet just a few lines long that would make the headers more distinct, perhaps by magnifying all of them, and then if it's popular it could be added to the default skins. —Soap— 21:27, 14 January 2023 (UTC)

The bigger type on L2 and L3 is too big, wasting vertical screen space. Smaller type can be hard to read on phones. Indentation and possibly bold/italics would be good ways to differentiate the other levels of headings. Color is an accessibility problem for the color-blind, though we might be able to reduce the scale of the problem by addressing the needs of the red-green colorblind. DCDuring (talk) 21:44, 14 January 2023 (UTC)

In theory, since we don't currently use L1 in entries, we could move everything up a level (language names at L1 instead of L2, numbered etymology sections at L2 instead of L3, etc), making the headers which are currently L5 into L4 headers. In practice there is probably a better idea. Our whole system of headers involves a lot of empty whitespace, e.g. giving "Noun" its own line all to itself, with nothing else on that line, and then the headword line beneath it: it would be more compact to have "Noun: headword (plural: headwords)". This is especially noticeable on mobile. - -sche (discuss) 05:12, 16 January 2023 (UTC)

I actually don't know why L1 headers aren't used, I tested it and it seemed to work great in the preview. However that's just the preview, maybe on the actual page it would cause issues. If there's no technical reason for it, I would be in favor of adopting L1 headers.

I do disagree with the compaction thing though, I personally think it's better that everything is spaced out.-Sameerhameedy (talk) 06:24, 18 January 2023 (UTC)

I've created User:ExcarnateSojourner/beat as a copy of beat with all headings promoted one level, if anyone is interested in seeing how it looks and feels. — excarnateSojourner (talk · contrib) 02:33, 5 February 2023 (UTC)

Content boxes make L5s worth it. As Benwing says, we should fix what it looks like, not ignore the issue. Thadh (talk) 09:37, 18 January 2023 (UTC)

• Can someone do a mock up of the appearance of a radical vertical-screen-space-saving reduction of whitespace by reducing font size and moving some headers (eg, PoS per -sche) next to content lines? Even if there is a (near-?)consensus on the mockup, we would need to make sure that there were no major adverse interactions with all the the templates and modules, and widely used tools. I would expect that font-size- and vertical-whitespace-reduction are fairly easy and low risk. (Could they be implemented in Custom CSS and JavaScript?) I'd expect other changes to be more problematic. DCDuring (talk) 18:42, 18 January 2023 (UTC)

@Sameerhameedy: This is not a structural problem, this is a styling problem.

L5 headers are correctly marked up in the rendered HTML as H5. Here's an excerpt of the source from that same ] entry, specifically the ] section header (pretty-printed for legibility).

<h5>
    <span class="mw-headline" id="Derived_terms">Derived terms</span>
    <span class="mw-editsection">
        <a href="https://en.wiktionary.org/w/index.php?title=beat&action=edit&section=5" title="Edit section: Derived terms" data-section="5" class="mw-ui-icon mw-ui-icon-element mw-ui-icon-wikimedia-edit-base20 edit-page mw-ui-icon-flush-right mw-ui-button mw-ui-quiet">Edit</a>
    </span>
</h5>

This is taken from the mobile version.

From what I can glean from dev tools in Firefox, it looks like the style is coming from the "Minerva" skin. Experimenting just now in my laptop browser, if I go to Special:Preferences, click Appearance, and select MinervaNeue, I get the same bad styling in my laptop -- L5 headers are still <h5> in the markup, but they are now visually indistinguishable from regular text.

In my iOS Safari, I can click the hamburger icon in the upper right (the three horizontal lines) and go to Settings, which offers me the solitary option of changing the font size -- this only affects the size of text that isn't indented.

I think the MinervaNeue default skin for mobile is broken, from an accessibility and usability standpoint.

I've tried a few things, but I cannot figure out how to force the mobile UI to use any skin other than MinervaNeue.

If anyone has advice on how to change the skin in mobile, and even better how to change it for users who aren't logged in, I would be very interested to hear it. ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:42, 24 January 2023 (UTC)

We currently don't support the Old Tibetan language, which was the Tibetic language spoken prior to the development of Classical Tibetan, but after (the unattested) Proto-Sino-Tibetan. It is the ancestor to numerous Tibetic languages, some of which diverged before the Classical Tibetan period, and is the oldest attested ancestor to modern Tibetan.

Old Tibetan is attested from around the 7th century onwards, and (notably) uses a considerably more complex orthography that reflects a much earlier period of the spoken language; one which seems to have been dated even at the time of the earliest transcriptions still extant today. The reform of that orthography, starting in the 9th century, marked the period of transition to Classical Tibetan, which was unambiguously in use from the 12th century onwards. One example of this was the abolishment of the "da drag" (a ད (da) used as a second suffix), which - for better or worse - still lingers on in an indirect form in modern Tibetan pronunciation, despite the fact it hasn't been written in over 1,000 years. For example, the Old Tibetan word དབྱརད (dbyard​, “summer”) developed into the modern word དབྱར (dbyar, “summer”), but still declines as though it had the old spelling. As such, adding Old Tibetan would be of benefit both for its own sake (as a distinct period of the language), as well as for the etymology sections of numerous terms we already have.

For what it's worth, Old Tibetan has its own ISO language code, too: otb. I suggest we use it. Theknightwho (talk) 00:37, 15 January 2023 (UTC)

Support. AG202 (talk) 07:52, 16 January 2023 (UTC)

Support. Three cites, for all senses.

Welp, it's my turn to ask one of these questions.

How durable are we to consider something like an online National Corpus, such as NKJP (National Corpus of the Polish Language). It includes many internet citations, mostly from UseNet, but the main issue with internet citations has always been their durability. For a while UseNet was considered durable, but this has been called into question as we have SEEN the deletion of certain threads by Google.

I would assume a resource like this would be considered highly durable, and therefor any citations from it would count toward CFI, no? Vininn126 (talk) 11:05, 15 January 2023 (UTC)

I’m inclined towards calling these durable. Theknightwho (talk) 21:23, 15 January 2023 (UTC)

If this is true, we need to consider the status of other corpora such as COCA. Vininn126 (talk) 22:04, 15 January 2023 (UTC)

A corpus whose access is funded by a national government with stable institutions deserves special consideration. COCA is not in that position. DCDuring (talk) 22:54, 15 January 2023 (UTC)

Sometimes an extinct language - be it due to their small corpus or topical bias - may have a sense that is unattested, but can be reconstructed based on the descendants and ancestor; My question is: How should we handle these? Currently, I have implemented a less-than-ideal solution on 𐍒𐍩𐍠𐍢, but maybe a more durable solution can be found? Thadh (talk) 14:07, 15 January 2023 (UTC)

If that categorized, I think that would be a huge improvement. Vininn126 (talk) 14:26, 15 January 2023 (UTC)

Let me be clear what I mean:

I think modifying {{label}} to include a reconstructed link and categorization would be best. Vininn126 (talk) 17:07, 15 January 2023 (UTC)

Latin focus has the label "vulgar Latin" for the sense "fire". I'd propose in descendants as a label. One could also say rare|chiefly|in descendants, in case the sense is, or close to, a hapax, but is the one main meaning in all of its descendants. Catonif (talk) 14:40, 15 January 2023 (UTC)

We need a template for it, a kind of stylized star that links to an explanation, being obvious enough since the ASCII asterisk is insufficient also for its Wikisyntax employment. What also occurs is that a sense can be assumed for a dialect but it is only attested for another, as for زُوم (zūm). Fay Freak (talk) 17:23, 15 January 2023 (UTC)

I think I’d find this label confusing. I’d prefer (reconstructed), perhaps with some kind of formatting that distinguishes the sense in some way. Theknightwho (talk) 20:50, 15 January 2023 (UTC)

I agree "reconstructed" would be better than "unattested", definitely. Vininn126 (talk) 20:53, 15 January 2023 (UTC)

As you know, the newest entry feature of categories malfunctions when you mix attested and reconstructed entries. I'd like to keep the "newest entry" list functional so that it's easier for editors to watch over newly created entries in a given proto-language, and see how/if the creation of entries in the language is active.

The problem with the malfunction is obvious when dealing with Uindiorix inscription. Editors can't decide between assigning it to Proto-Brythonic or elsewhere; anywhere it's assigned, it causes the "newest entry" feature to break.

AFAIK the only workarounds I can think of to get the "newest entry" feature to work again are:

• Give the language of the Uindiorix inscription a separate language code from both Proto-Brythonic and Proto-Celtic. It can't be Proto-Brythonic (nouns have case endings in the inscription; which were already all lost at the late stage we reconstruct it) and it can't be Proto-Celtic (Proto-Celtic is dated much earlier than this Roman-era inscription), so it's probably warranted to treat it separately from both.
• Move the entry into Reconstruction space, restore reconstruction-only status, and write notes stating that the term is attested without creating an attested-form entry.

— Ceso femmuin mbolgaig mbung, mellohi! (投稿) 03:37, 16 January 2023 (UTC)

I can't speak to the category issue but it would seem very strange to me to give it a special language code. The Proto-Brythonic reconstructions may represent a late stage of the language, but if a word is attested from a different stage then it makes sense for it still to be noted as Proto-Brythonic, with an appropriate note about the period it is attested from, rather than inventing a new ad hoc language category for it. —Al-Muqanna المقنع (talk) 03:54, 16 January 2023 (UTC)

Would solution 2 (move to Reconstruction namespace but state that it's actually attested and it's only in Reconstruction: for software reasons (possibly with a banner template?) work for you? — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 04:08, 16 January 2023 (UTC)

As far as I can tell, the dynamic page list can only pull from one namespace if any namespace is specified. The code in the category page is

<dynamicpagelist>category=Proto-Celtic lemmas
namespace=
count=10
mode=ordered
ordermethod=categoryadd
order=descending</dynamicpagelist>

You can get the wikitext generated by {{auto cat}} by plugging the wikitext of the category page into "Input wikitext:" in Special:ExpandTemplates and setting the title to Category:Proto-Celtic lemmas. It shows only mainspace entries because of namespace= (that is, namespace is an empty string, mainspace). namespace=,Reconstruction doesn't work. If namespace= is removed, both main and Reconstruction namespaces will be shown, but so will User and Wiktionary and Appendix namespaces, if someone is testing headword-line templates elsewhere and they end up categorizing.

Lines starting with line 284 in Module:category tree control the inclusion of namespace=. The dynamic page lists on the category page show pages in the Reconstruction namespace for solely reconstructed languages (namespace=Reconstruction), Appendix for appendix languages (namespace=Appendix), main for others (namespace=).

In theory we want the list (whatever use it is) to show main and Reconstruction namespaces always. If a reconstructed-only language has mainspace entries (which it shouldn't), we'd want to see them. A non-reconstructed and non-appendix language can have reconstructed entries and those should be shown. An appendix-only language should show Appendix pages, but it doesn't hurt to show main and Reconstruction pages because there shouldn't be any in any case. But there's no way to do that without allowing all namespaces, which means non-entries will sometimes show in there.

No good general solution, but in this case there could be some kind of exception for Proto-Celtic that makes the dynamic page lists show Reconstructed entries only. I hardcoded it in Module:category tree (diff), since it's such an exception that I don't know a better place to put it. — Eru·tuon 01:51, 17 January 2023 (UTC)

I extended the exception to other languages whose code ends in -pro except for Proto-Norse (gmq-pro) because Proto-Brythonic (cel-bry-pro) was in the same boat as Proto-Celtic and most others will be as well if they get any non-reconstructed entries. Suggestion of Chuck Entz on my talk page. It would be more scientific to do some kind of census, but unnecessary at this point. — Eru·tuon 02:37, 17 January 2023 (UTC)

This entry contains directly attested terms in a reconstructed language. Even though the term is attested, the term is in the Reconstruction namespace for technical reasons.

@Skiulinamo Your move (which switched Proto-Celtic to allowing attested entries) is causing technical problems with categorization amenities, since they cease to function properly when attested and reconstructed entries are mixed. I would like to move Uindiorix into Reconstruction but mark the fact that they're attested with a banner template as a workaround. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 04:21, 16 January 2023 (UTC)

Uindiorix is obviously attested and shouldn't be moved to a reconstruction. What "categorization amenities" are you referring to? --Skiulinamo (talk) 04:35, 16 January 2023 (UTC)

@Skiulinamo: The "Newest pages ordered by last category link update" function. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 04:36, 16 January 2023 (UTC)

Link. --Skiulinamo (talk) 04:37, 16 January 2023 (UTC)

@Skiulinamo: This box on the top-right of the category page. (I circled it in red.) It cannot display newly-added reconstructed entries if an attested entry is also part of the category. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 04:39, 16 January 2023 (UTC)

@Erutuon --Skiulinamo (talk) 04:44, 16 January 2023 (UTC)

Until it's fixed if you just want to track new entries you can do the same thing by filtering the related changes—this also shows removals from the category, which the box doesn't. It looks like there are two other attested entries at Proto-Brythonic in any case (which is presumably where Uindiorix should be, not Proto-Celtic, given that the dating is nowhere near the Proto-Celtic era), Artognou and Ἀργεντοκόξος. —Al-Muqanna المقنع (talk) 05:02, 16 January 2023 (UTC)

At this point I'm waiting for Erutuon to comment, which might take a couple of days (since he might be sleeping for a while, who knows). — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 05:05, 16 January 2023 (UTC)

Alright, Erutuon switched the newest pages list box up so that only reconstructed entries are displayed, partially fixing my concerns. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 02:19, 17 January 2023 (UTC)

We shouldn't be putting terms in the wrong namespace "for technical reasons". Theknightwho (talk) 04:57, 16 January 2023 (UTC)

Where is the best place for me to lodge a complaint about Wiktionary's completely inaccurate and idiosyncratic use of the term "Proto-Brythonic" for what should properly be termed (Common) Neo-Brittonic (or, as some more Welsh-centric scholars prefer, Neo-Brittonic)? Proto-Brittonic/Brythonic should (obviously!) be the ancestor of Brittonic, the ancient British Celtic language of Britain attested from the 4th century BC through the mid-6th century AD, after which it gave way to (Common) Neo-Brittonic (the immediate ancestor of Welsh, Cornish, Breton, and Cumbric). Proto-Brittonic would be a daughter of Insular Celtic, itself a daughter of Proto-Celtic, and would roughly date to the early Iron Age. Any attested or reconstructed ancient British Celtic name/word dating from circa the 4th century BC through the mid-6th century AD should be labeled here as Brittonic and anything dating to the mid-6th century through the 8th century should be labeled Neo-Brittonic (or one of its variants, such as John Koch's Common Archaic Neo-Brittonic).M.Aurelius.Viator (talk) 16:04, 18 January 2023 (UTC)

I know Schrijver uses "Late Proto-British" for the stage Wiktionary deals with. He also uses "Proto-British" for the stage of the proto-language more in line with the Uindiorix description. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 18:30, 18 January 2023 (UTC)

Yes, but few other scholars use this term and Schrijver even admits that his use of the term is unusual and "requires elucidation"; Common Neo-Brittonic/-Brythonic (Archaic Common Neo-Brittonic for John Koch) is the preferred term among most Celticists for post-apocope, post-syncope, pre-dialectal British Celtic of c. mid-6th century AD through c. 8th century AD. Also, for anyone who hasn't read Schrijver, you can see his explanation of the term in his book Studies in British Celtic Historical Phonology , p. 12. M.Aurelius.Viator (talk) 18:53, 18 January 2023 (UTC)

Specifically Schrijver says there that using it to refer to an earlier stage needs elucidation, i.e. what you are claiming Wiktionary should adopt exclusively, and that proto-languages generally refer to "the final stage of common development of a number of languages", i.e. how Wiktionary in general uses Proto-Brythonic at the moment. —Al-Muqanna المقنع (talk) 18:59, 18 January 2023 (UTC)

I don't know how many times I need to repeat it (have already mentioned it several times on the other page where this was being discussed) but no one other than Schrijver calls post-apocope/post-syncope British Celtic of the early medieval period "Proto-British" and certainly no one (outside of Wiktionary!) calls it "Proto-Brythonic"; the latter is inaccurate, confusing for non-specialists in Celtic linguistics, and out of line with the academic consensus today. It needs to be changed. M.Aurelius.Viator (talk) 19:51, 18 January 2023 (UTC)

My point was to point out the irony in that Schrijver's late-stage reconstruction is equivalent to "Proto-Brythonic" on Wiktionary even though he himself did not actually call it that... — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 20:24, 18 January 2023 (UTC)

@M.Aurelius.Viator: Schrijver says, clearly, and in line with standard linguistics, that a proto-language is in general the last common ancestor of a group of languages, i.e., in this case, the Brittonic/Brythonic languages. This is what is being reconstructed on Wiktionary. You've already been told by @Chuck Entz elsewhere that continual appeals to your own authority are not going to impress anybody, so do you have any specific reference or point to make beyond asserting it over and over? —Al-Muqanna المقنع (talk) 20:32, 18 January 2023 (UTC)

But is there a scholarly consensus calling this specific stage (with all grammatical endings destroyed by apocope and umlaut in full swing) "Proto-Brythonic"? I do not believe it exists, and I provided a major source that specifically avoided the word "Proto-Brythonic/Proto-Brittonic" for the post-apocope stage. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 20:54, 18 January 2023 (UTC)

No one that I'm aware of - and I am very well read on this subject - refers to post-apocope, post-syncope British Celtic - i.e., the language of the mid-6th century AD through the 8th century AD - as "Proto-Brythonic". Most call this stage of the language Neo-Brittonic/-Brythonic. After this period we are in the Old Welsh/Cornish/Breton/Cumbric periods. M.Aurelius.Viator (talk) 22:11, 18 January 2023 (UTC)

But he is right, I don’t understand why everyone is so dead against using proper terminology? Doesn’t make sense. Why would you not use the same common terminology as people who study the field and people who have a profession in the field. Seems like an ego thing, just don’t want to admit all the entries that have been submitted this far are incorrect.

also what do I do if I want to make an entry for Brittonic but not the stage of Neo-Brittonic? What if I want to make entries for forms of Early Brittonic, Late Brittonic and Neo-Brittonic? I can’t because you are lumping all of these together under one term “Proto-Brythonic”. I can’t make sense of any of this, why not allow us to make enteries based on what is best for people who study or want to study these languages. I want to create enteries on the Brittonic verbs ‘to know’ for instance, let’s take the 1.sing.pres. first I want to create a Proto-Celtic. *wintnua, then Early Brittonic. *winnua, then Late Brittonic. *wunnoa, then Neo-Brittonic. *gwnn. I can’t do this because 2 stages of Brittonic and Neo-Brittonic are all lumped together? Why? Senseless, absolutely senseless… Silurhys (talk) 21:31, 18 January 2023 (UTC)

Exactly - it's completely bizarre that there is so much pushback against a very common sense proposal - at least for those of who have actually studied Celtic historical linguistics! M.Aurelius.Viator (talk) 22:07, 18 January 2023 (UTC)

@Al-Muqanna المقنعI can provide ample sources to back up my statements here - can you provide even a single one to back up yours? Do you have any background whatsoever in Celtic historical linguistics? I have almost 40 years experience, have run/moderated several academic mailing lists on the subject, and have been consulted by and cited as a reliable source by numerous well known scholars in the field (Delamarre, Stifter, et al.); what have you done in this field? M.Aurelius.Viator (talk) 22:16, 18 January 2023 (UTC)

@M.Aurelius.Viator, Al-Muqanna I don't know much about the timeline of Brythonic linguistic stages but we definitely need to use proper terminology, and from what I know about Celtic, I would be highly skeptical of treating something as late as 8th century AD as Proto-Brythonic. There is a lot of text written up above but it seems only User:Mellohi! is objecting to using proper terminology, is that right? If so I think we can ignore their objections given the number of people in this discussion. Can you enumerate what exact changes need to be made? I may be able to help with the technical aspects. Benwing2 (talk) 01:13, 21 January 2023 (UTC)

@Benwing: I oppose using "Proto-Brythonic" and in fact agree with you and Viator it's "Proto-Brythonic" that's the incorrect terminology. The current "Proto-Brythonic" should be renamed to something else. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 01:23, 21 January 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Benwing2, Mellohi!: There are two distinct discussions, I think, I'm not sure to which Benwing was referring to when saying you don't support standard terminology. First, I 100% agree that Uindiorix should not be listed at Proto-Celtic, which is about a millennium off the mark. What it should be is a bit more complicated. The reason not to split these stages into separate languages is pretty simple from a comparative linguistics standpoint; there are no additional languages from which to reconstruct them, and the "Proto-" standard is also uniform with our use e.g. of "Proto-Slavic" rather than "Common Slavic" (also used in literature) for the common ancestor of the Slavic languages and the like. It seems to be an accepted guideline that reconstruction pages are not created where there's only a single descendant, which would obviously be the case for various stages of a reconstructed language. Many languages (e.g. obviously Latin) have period-specific labels, which could be useful in this case. I think generally speaking the reconstruction entry should be at the last stage, following standard comparative practice, and extra info listed there; the few terms that are actually attested like Uindiorix could be handled with labels.

The renaming of Proto-Brythonic is a separate issue (and a derail of the original discussion IMO), which I'll deal with below.

@M.Aurelius.Viator: You've already been provided a "single source" in the RFV discussion, but to write two recent sources out, 1. "Around 800 AD, Late Proto-Brittonic branched into West-Brittonic, which then became Old Welsh, and Southwest-Brittonic, which further sub-divided into Breton and Cornish from about 1100 onwards." (Irslinger 2014, "The Gender of Abstract Noun Suffixes in the Brittonic Languages", p. 65); 2. Anders Richard Jørgensen 2022, "Celtic", in The Indo-European Language Family: A Phylogenetic Perspective, has "Proto-Brittonic" and "PBrit." for the phase of the language before Old Welsh etc., thus "a Proto-Brittonic suffix *-ɪnn" (p. 145, i.e. our Reconstruction:Proto-Brythonic/-ɨnn). Now, you've repeatedly been asked to provide sources yourself specifically treating Proto-Brittonic/Brythonic as an early stage in the language, and, from what I can tell, have still not done so despite abundant assertions that you can.

I don't personally object at all in principle to changing the name to something else with greater currency, e.g. Common Brittonic, but I do object very strongly to doing so simply because a new editor is stamping their foot and demanding it on their own authority, which is being lent to the obviously false claim that no Celticist has ever used the term Proto-Brythonic/Brittonic for this stage of the language; it sets a pretty terrible precedent. There should be a serious discussion of the merits, and what the sources actually say, rather than arguing the toss over unverified credentials. This is to me a "governance" issue independent of the matter at hand. (Maybe @Skiulinamo has a perspective on this as well.) —Al-Muqanna المقنع (talk) 02:26, 21 January 2023 (UTC)

@Al-Muqanna, Mellohi! Blah. My apologies for getting confused about what was going on; upon rereading I realize I totally misread some of what was written. Let me know if you need any technical help; otherwise I'll refrain from further comments. Benwing2 (talk) 04:08, 21 January 2023 (UTC)

What's annoying about all this is that instead of asking a good question, like "should we rethink how we reconstruct Proto-Brythonic?", it's a pedantic and silly one of "why are you idiots calling it this? what should we call it?". If there was a vote to reconstruct PB in an earlier form, with case endings and internal thematic vowels, I would support that, same as I did 6 years ago. -- Skiulinamo (talk) 07:03, 21 January 2023 (UTC)

Let’s take a vote then to split Proto-Brythonic into two stages; Brittonic and Neo-Brittonic. It would certainly make entries easier, more reasonable and closer in line with modern academia. Silurhys (talk) 12:11, 21 January 2023 (UTC)

@Silurhys: I'm not sure if you're intentionally being obtuse, but I promise you, a vote to split PB would fail horribly and be a waste of time. -- Skiulinamo (talk) 23:09, 21 January 2023 (UTC)

How am I being obtuse, all I’m doing is trying to improve the situation, you have to put attested Brittonic names under Proto-Celtic because the system thats in place is a mess. I can’t understand the thinking here, why would it fail? Why don’t people want to do what’s best. I want to make Brittonic entries on words that may not have existed in Proto-Celtic. What am I to do in that situation? A reasonable answer would be nice but nobody has one. Sad that it’s like this, people can’t rely on Wiktionary to have accurate information. Silurhys (talk) 23:38, 21 January 2023 (UTC)

@Silurhys Your proposal is exactly what is needed and it's bizarre that people are arguing against it! M.Aurelius.Viator (talk) 16:59, 22 January 2023 (UTC)

> the obviously false claim that no Celticist has ever used the term Proto-Brythonic/Brittonic for this stage of the language; it

You don't have clue as to what you're talking about. No one uses this term for Common Neo-Brittonic. The closest you have come is Schrijver's idiosyncratic Late Proto-British, which is not the same thing. Brittonic (aka Brythonic) is the ancient language of Britain, attested from the 4th century BC through the mid-6th century AD, after which it became Common Neo-Brittonic. Proto-Brittonic would be the ancestor of Brittonic, not its descendant, LOL! Yet this is the ridiculous way that it is being used on Wiktionary. M.Aurelius.Viator (talk) 17:04, 22 January 2023 (UTC)

John Koch, Celtic Culture, ABC-CLIO, 2006, p. 305, "In contemporary Celtic studies, ‘Brittonic’ and ‘Brythonic’ are interchangeable terms with precisely the same meaning. ‘Brythonic’ has been adopted in this Encyclopedia, since it has the advantage of resembling the Welsh terms from which it is derived, namely Brython ‘Britons’ and Brythoneg ‘Brythonic’, thus reminding the generalist reader of the languages to which it refers, and avoiding potential confusion owing to the similarity of ‘Brittonic’ and the name of the modern nation state of Britain (i.e., the UK) and of the British Empire, whose chief language is the non-Brythonic (and non-Celtic) English. In Jackson’s highly regarded scheme as set out in Language and History in Early Britain, ‘Brittonic’ is used in the same sense as ‘Brythonic’ here. ...(T)his Encyclopedia follows Jackson’s usage in Language and History in Early Britain, using ‘British’ only for the ancient form of Brythonic as found in documentary evidence from the Iron Age and the Roman period in Britain. In linguistic terms, ‘British’ therefore refers to Brythonic as long as it retained its Proto-Celtic (and ultimately Indo-European) syllable structure; for example, the Brythonic name written in ancient sources as British Cunobelinos is written in the early Middle Ages as an archaic Neo-Brythonic (or early Old Welsh) Cunbelin, revealing the loss of two unaccented Proto-Celtic syllables. Using ‘British’ to refer only to the ancient form of Brythonic (the ‘Cunobelinos stage’) has the advantage of using ‘British’ only for a period at which this language was actually the most widely spoken language of Britain; this avoids the confusions discussed above with reference to later periods when English had become the predominant language of Britain and then the British Empire, for which periods ‘British’ might be misunderstood as shorthand for ‘British English’ in contrast to ‘American’ or ‘Indian English’, &c."

M.Aurelius.Viator (talk) 17:27, 22 January 2023 (UTC)

Review of Patrick Sims-Williams, "Dating the Transition to Neo-Brittonic: Phonology and History, 400-600" in: "Britain 400-600: Language and History". Ed. by Alfred Bammesberger and Alfred Wollmann (Anglistische Forschungen 205) by Poppe, Erich.  Amsterdamer Beiträge zur Älteren Germanistik; Amsterdam Vol. 34, (Jan 1, 1991): 194: "In his closely argued contribution Sims-Williams sets up criteria for neo-Brittonic (loss of final syllables , syncope , Second Spirantization , new quantity system) and then examines the relevant developments in detail." M.Aurelius.Viator (talk) 17:33, 22 January 2023 (UTC)

: Kenneth Jackson, Language and History in Early Britain, Edinburgh, 1953, pp. 4-5: "In this book British (Brit.)1 is used as a general term for the Brittonic language from the time of the oldest Greek information about it (derived from Pytheas of Marseilles, c. 325 B.C.) down to the sub-Roman period in the fifth century and on into the sixth. Where it is necessary to be more precise, a distinction is made between Early British, during the Roman occupation and as far as the coming of the Saxons in the middle of the fifth century, and Late British (Late Brit.), from that time until and including the earlier half of the sixth century. As we shall see, the earlier period of British coincides with the oldest dateable Brittonic sound-changes, beginning in the first century B.C. and the first to second century A.D., and consisting mainly ofcertain modifications of vowels and diphthongs ; and Late British covers a number of important transitional phonetic developments, from lenition through final vowel affection down to the loss of final and unstressed internal syllables. Since some of the special features of the separate modern languages reach right back into the British period, it is necessary to postulate a West British dialect, that of Wales and the Midlands (and Late West British, Late W.Brit.), and a South-West British (and Late South-West British, Late SW.Brit.), that spoken in the peninsula of Devon and Cornwall. Romano-British (Rom.-Brit.) is confined to forms of the language reported by Roman writers in Latinised spelling; and the term is stretched to include those given by Greek authors, chiefly derived from Latin sources, in Greek spelling, e.g. by Ptolemy. British Latin on the other hand is something quite different, the variety of Vulgar Latin spoken in Britain during and for some time after the Roman occupation."

"With the drastic changes which occurred during the Late British period we reach an entirely new stage; the ancient language, with its final syllables, its case terminations, and the rest, gave place to what is really a mediaeval one, and to the rise of what will be called here the Neo-Brittonic tongues, Welsh, Cornish, and Breton. From the middle of the sixth century we can begin to speak of these as separating languages, and from the end of the century as separate. In this period, and down to the time of their earliest written records (other than inscriptions and a few names in sixth- to eighth-century Latin sources}, the new terms Primitive Welsh (Pr.W.), Primitive Cornish (Pr.C.}, and Primitive Breton (Pr.B.) are used here. With these written records we enter upon the stage of Old Welsh (OW.), beginning with the later eighth century, Old Cornish (OC.), from the late ninth century, and Old Breton (OB.), from the early part or middle of the ninth century. M.Aurelius.Viator (talk) 17:50, 22 January 2023 (UTC)

Richard Coates, "Rethinking Romano-British *Corinium", The Antiquaries Journal, Cambridge, 2013, "Before we embark on the discussion, we need to attend to some terminology for the languages of Britain in antiquity and later. The main native language of Britain in the Roman period was British Celtic, recorded almost exclusively in a latinized form called Romano-British (RB), for which the main evidence is personal and place-names. In the period after the collapse of Roman rule, this language evolved through a stage called in this article Brittonic (roughly 450-550 C. E.), for which there is little direct evidence, and from this into the distinct modern languages Welsh, Cornish, and Breton (collectively called the neo-Brittonic languages; 550 C. E. onwards). The earliest stages of these, before written texts appear (550-750/800 C. E.), are called e.g. Proto-Welsh and Proto-Cornish, and the earliest texts are described as being in e.g. Old Welsh and Old Cornish." M.Aurelius.Viator (talk) 18:03, 22 January 2023 (UTC)

Martin J Ball and James Fife, The Celtic Languages, Routledge, 1993 (2005 repr.), p. 75-77: "P-Celtic and Q Celtic: sources and transition in the neo-Celtic languages of the British Isles. P-Celtic, Brythonic, Old Brythonic or Common Brythonic was spoken in Britain south of the Rivers Forth and Clyde down to the middle of the sixth century AD. Before the rise of the neo-Brythonic languages, from the middle to the end of the century, we observe the formation of dialects..."

"In dealing with the emergence of the neo-Brythonic languages from Common Brythonic, three facts must be taken into consideration. First, the breakdown of Late British (450-550) which, according to Jackson (1973: 121), probably started in the Lowland Zone and was 'the consequence of violent social disturbances and the disappearance of a linguistically conservative class' (ibid.). Among the phonological changes which mark the end of Late British, four transformations are particularly important: (a) the dropping of final syllables (as well as of interior ones) caused by the penultimate stress access and resulting in the change of inflection type (from synthetic to analytic)... (b) lenition of consonants in intervocalic position... (c) vowel affection, e.g. umlaut... (d) quantity collapse with the lengthening of short stressed vowels before short consonants..." M.Aurelius.Viator (talk) 18:23, 22 January 2023 (UTC)

There seems to be a class of editors who have a penchant for mass-adding translation in languages they don't know without taking proper care. Usually they just copy Wikipedia titles and leave behind a mess of unattested terms and missing qualifiers/genders/noun classes/... Recent cases include StuckInLagToad, VGPaleontologist, Numberguy6, Hippietrail and Sgconlaw (the first two have left the project after being reprimanded for this behavior, the last two have stopped doing it on their own accord AFAICT) along with a number of IP editors. From my experience, translation boxes contain the lowest quality content on Wiktionary and I wouldn't trust them except in the case of a few select languages. It seems that bad content goes unnoticed the longest in translation boxes. It doesn't have to be this way and that's why I'm suggesting that we crack down on low quality translation content. Cracking down would mean to me that recent changes patrollers revert all such mass-additions and that previous contributions of this sort are converted to {{t-check}} by a bot. Opinions?

(As a side note, I've also done this once but I have learned from it since then.) — Fytcha〈 T | L | C 〉 12:36, 16 January 2023 (UTC)

I also propose including Rajkiandris to the list, who added tons of incorrect translations in his time here. I agree that we need to do something about the translations, even though I don't like editing them myself... Thadh (talk) 12:53, 16 January 2023 (UTC)

Toad and VGP were the same person. He more or less confessed to it in his last message here. I think he really wanted to help, and like you, I hope he decides to come back, but at a much slower pace. Translation is difficult, and we can't rely on our fellow project. Wikipedia often will link to the most appropriate article, even if it's not an exact translation. So even knowing the basics of the grammar of a certain language often isnt enough. As I learned just recently, bubble bath and hot tub are two entirely different things in English, but in many languages, such as Dutch, they are covered by one word, in this case bubbelbad, but with the second meaning more common (schuimbad is the word that specifically means a bath with bubbles). Wikipedia cannot link one article to two, so at some point we decided to go with the literal translation of bubble bath, and I had to ask a native speaker to figure out why things didnt seem to line up. —Soap— 14:24, 16 January 2023 (UTC)

I'm a native speaker of Hungarian and will still generally double-check every translation I add, by checking Hungarian dictionaries and/or by searching to make sure it's actually attested. On the other hand there are a small number of translations I've added for languages I'm not fluent in but can understand source material for, where they're straightforward and I've made sure they're properly attested (e.g. the Spanish indulgencia plenaria at plenary indulgence). So IMO it's not just a fluency issue, it's about taking proper care and not just porting over stuff from Wikipedia and the like. —Al-Muqanna المقنع (talk) 14:48, 16 January 2023 (UTC)

Well it's not necessarily a lack of fluency, but a lack of even being able to understand the material in the first place. Vininn126 (talk) 15:20, 16 January 2023 (UTC)

Translations require knowledge of both languages and often of the subject matter. There are also a lot of cases where there's only partial overlap semantically, grammatically/morphologically, sociolinguistically, etc. An English word may correspond to a grammatical case or an SOP phrase in another language, and vice versa. The English word or the translation may be more general, or may be everyday speech vs. absolutely taboo. The default sense in English may require a qualifier in the other language, and vice versa. There may be regional variation in one or both languages. There are a million ways to go wrong.

On top of that, there a lots of easily available bad sources: Google (or Bing) Translate, Wikipedias, general translation websites, etc.

There are specific red flags I look for: isolated and less studied languages such as Basque, Albanian, and Khmer. Dead languages with limited corpora that people are trying to revive, such as Gothic and Old Prussian (even Old English, to some extent). Regions such as Africa, the Americas and parts of Asia that are only known by people from the region and specialists (and even those are too diverse for mastery of an entire region). There are people who are qualified to add translations to any one of those, but combinations of more than a couple are suspect. Chuck Entz (talk) 19:30, 16 January 2023 (UTC)

To raise a connected issue: at least one editor in that list has added thousands of bare lemmas on the basis of translation boxes alone. In some cases these have required correcting or simply deleting.

Also, I propose a mass delete of every translation added by Rajkiandris. There are thousands and thousands of them, and they're often of extremely low quality due to catastrophic competency issues. One example I remember was him misunderstanding the difference between vessel (boat) and vessel (container), leading to a slew of incorrect entries. Theknightwho (talk) 02:42, 17 January 2023 (UTC)

This is a really good idea. Mass-additions cannot be trusted and should be reverted on sight. Megathonic (talk) 07:03, 17 January 2023 (UTC)

I agree. Part of my TODOs is going through the mess that was Yorùbá translations before our recent group effort started. There might also need to be a way to cite where translations are found, as currently there's no way to do so. Also, seeing the case of User:Rajkiandris, as a project I think we need to be much more proactive about blocks unfortunately. Personally, I used to lean more on giving people more chances, as with User:Spacestationtrustfund, but clearly doing this only causes more harm to the project and creates more issues that have to be corrected in the end, and most active editors don't have the time to parse through all their good and bad edits, leading the bad ones to remain for much longer than they needed to. AG202 (talk) 08:51, 17 January 2023 (UTC)

@Fytcha, Soap, Rajkiandris, AG202, Thadh Completely agree about both the need to be more proactive about blocks of repeat-offending users and the wisdom of mass-removing bad translations. Some users do tons of harm adding stuff that at first looks semi-reasonable but is revealed to be garbage as soon as you scratch the surface. This is much more harmful than obvious vandalism, which usually gets reverted quickly. If we agree, for example, to remove all of Rajkiandris's translations, I may be able to write a bot script to do this; same with User:Fytcha's proposal, although the specifics of how to do that need to be ironed out. Benwing2 (talk) 01:05, 21 January 2023 (UTC)

As said above, I support removing all translations added by Rajkiandris. It's better to not give any translation than risk giving a wrong translation, and nobody has the time to go through the thousands upon thousands of translations this user has added and fix them.

On a different note, it would also be useful for me with Ingrian (and maybe for others, like AG202, with the languages they edit) if a list could be generated for all pages featuring translations in the language. Of course this isn't feasible for bigger languages, but for languages under a few thousand entries it's possible, surely? Thadh (talk) 01:17, 21 January 2023 (UTC)

In case anybody else needs this, this can be achieved with a simple CirrusSearch query: — Fytcha〈 T | L | C 〉 12:40, 21 January 2023 (UTC)

I've had a version that looks only for language codes bookmarked since you first shared it with us. While looking through the results for Old Prussian (prg), which is a language that died centuries ago and left a very limited corpus, I found a dubious translation for passport, which led me to this. Aside from 1 edit by Wingerbot to the Derived terms section, everything is the same IP: a solid block of ~ 107 translations added over 4 days from every inhabited continent except possibly Australia. How many people know all of Ojibwe, Yoruba, Cornish, Scots Gaelic, Samoan, Dzongka, Tarifit, Venetian, Chuvash and Cantonese well enough to add translations? Chuck Entz (talk) 06:10, 23 January 2023 (UTC)

I'm wondering if there should be a different way to handle translations, because they're completely impossible to trust at the moment. Theknightwho (talk) 19:27, 23 January 2023 (UTC)

It may just be the case that translations are inherently hopeless for a Wiki-like passive review system (by that I mean the system where the hope is that somebody knowledgeable will eventually come across nonsense and delete it). We have more English entries than the English Wikipedia but only a fraction of their active users. To make matters worse, any given user can only verify so many languages on a page. To make matters even worse, unlike Wikipedia, most of our stuff is not sourced. These three factors make the Wikipedia-style passive review paradigm incredibly ineffective for Wiktionary translations.

Cracking down on edit patterns that are known to lead to many errors is a good first step but may just be a drop in the bucket at this point. Bflanzekùnd has been up for 9 years, Sauerstoff for 14 (this doesn't even show up in the headline for me because it is incorrectly formatted, making it essentially undetectable), a Turkish swear word was up as a supposed Quecha translation for over 15 years. Perhaps we need a role along the lines of "translations approved" but then we'd have laughably few translations. I see no way around either sacrificing quality or quantity and we're currently sacrificing quality. — Fytcha〈 T | L | C 〉 23:41, 23 January 2023 (UTC)

(Not to say 'I told you so', but I proposed making sourcing obligatory a while back and everybody said no) Thadh (talk) 00:19, 24 January 2023 (UTC)

Your proposal only pertained to entries, no? In that case, I fail to see how it solves the issue of bad translations considering that they almost never point to any entries. Or did you envision that translations must be backed up by sources, too? — Fytcha〈 T | L | C 〉 15:01, 24 January 2023 (UTC)

We are not hopeless, we do our best, also by attracting and retaining valuable editors by rigidly showing, verbalizing good editing standards. There is not too much quality sacrified, have you searched together your bucket of junk? It’s not like we are standing in the muck. Fay Freak (talk) 00:29, 24 January 2023 (UTC)

The severity of the problem strongly depends on the language, of course. German translations are mostly fine, Finnish (I'd imagine) must be pretty good, but when it comes to smaller languages or languages with smaller editor communities such as gsw, I really don't have to search much to find obvious nonsense. I don't even have to search much to find nonsense that stood for over a decade. I can't help but think that this is the reality for most smaller languages (which make up most languages). My point was also rather that the usual Wiki "self-fixing mechanisms" aren't really effective under these circumstances. — Fytcha〈 T | L | C 〉 15:01, 24 January 2023 (UTC)

Yoruba translations until the recent effort were by and large problematic and stood for years as well. There's so many issues that I've seen pop up, but as mentioned, I'm only one person, and there's so much that needs to be done. This is part of why I'd been more adamant about creating a more welcoming environment in this project so that more people feel welcome to come contribute and learn, especially for smaller languages. But unfortunately, it has seemed to me (which is part of why I took a break from participating in discussions like these) that there's a very vocal portion of editors that want to maintain the status quo and protect "the traditions" of the website, pushing away new editors and not wanting to be more accessible, even though it's supposed to be collaborative. It seriously negatively affects the quality of the project as a whole. AG202 (talk) 15:57, 24 January 2023 (UTC)

Equating "traditions" developed over years of experience with exclusionary gatekeeping is not at all fair. If we allow people to come here and do anything and ignore all the rules, will you accept the enormous burden of cleanup? Equinox ◑ 16:06, 24 January 2023 (UTC)

@BigDom @Hythonia @Benwing2 @Thadh @Sławobóg Most Slavic languages declension template use blue where as the templates for the languages in the title use gray. Any strong opinions if we switch them over to blue? Vininn126 (talk) 18:06, 17 January 2023 (UTC)

The Kashubian one is already blue. And I support the change to blue, seems reasonable to have all Slavic languages in one colour. Thadh (talk) 18:07, 17 January 2023 (UTC)

I just changed it to our dank grey West Slavic color. :V Sławobóg (talk) 18:15, 17 January 2023 (UTC)

If anything, we should use red, as red is stereotypical for Slavic. Plus, we could actually use family colors from Wikipedia for all languages and standarize all templates, some of them look crazy. Sławobóg (talk) 18:18, 17 January 2023 (UTC)

@Vininn126 I support using blue. I'd be opposed to red as it would look gaudy. Benwing2 (talk) 00:55, 21 January 2023 (UTC)

I vote blue. Vininn126 (talk) 11:12, 21 January 2023 (UTC)

I’ll go a step further, and say we should use the same blue for all declension templates. Kyrgyz and Mongolian also use it (and a few other non-Slavic languages, too, I think). Theknightwho (talk) 14:36, 21 January 2023 (UTC)

No. This should be a decision per branch, and I like my purple and green templates, thank you very much. Thadh (talk) 15:06, 21 January 2023 (UTC)

Hello all,

The voting period for the revised Universal Code of Conduct Enforcement Guidelines is now open! Voting will be open for two weeks and will close at 23:59 UTC on January 31, 2023. Please visit the voter information page on Meta-wiki for voter eligibility information and details on how to vote.

For more details on the Enforcement Guidelines and the voting process, see our previous message.

On behalf of the UCoC Project Team,

JPBeland-WMF (talk) 00:23, 18 January 2023 (UTC)

For the derived terms-section in Ancient Greek entries, how shoud their size be judged? Is it preferable to have derivatives with (presumably) multiple steps between them on page of the main verb (a-la: λύτρον > λυτρωτός) for ease of use, or to split up more to one-step removed (a-la: λύτρον > λυτρόω> λυτρωτός) for the sake of size? Is there a standard (written or unwritten) for this? AntiquatedMan (talk) 15:05, 18 January 2023 (UTC)

Working with Latin, I only specify direct derivatives, leaving any indirect one for the entry for whatever form they directly derive from. Otherwise we'd have a nightmare on our hands for entries for 'prolific' base verbs. Nicodene (talk) 17:50, 21 January 2023 (UTC)

A proposal has been made on RFDO to delete the Westrobothnian lect: WT:RFDO#Category:Westrobothnian language, on the grounds that it is actively misleading. This seems quite important so I thought I would cross-post it here for wider visibility and input.

Let's continue the discussion at RFDO. This, that and the other (talk) 22:19, 18 January 2023 (UTC)

I propose that we use a different template for collapsible cognate sections in etymologies. {{rel-top}}'s documentation states that it is intended for the "Related terms" section of an entry, not the etymology section, which would also have been my guess based on its name. The issue with abusing {{rel-top}} for cognates is that it makes it harder to customize these boxes separately (with user CSS/JS). In my case, I want to completely remove the cognate boxes (i.e. show the contents without the box) because it's a waste of both time and space considering that most boxes (e.g. see, cold, ship) contain content that easily fits on a single line on my monitor (even despite using tabbed languages which takes away horizontal space).

Pinging @Benwing2 who has done some work on these templates. — Fytcha〈 T | L | C 〉 12:32, 21 January 2023 (UTC)

I abuse {{rel-top}} for hiding a long list of references like in խմորուկ (xmoruk). We need a general-purpose content hiding template. Vahag (talk) 17:17, 21 January 2023 (UTC)

@Vahagn Petrosyan It exists at {{box-top}} and {{box-bottom}}. Benwing2 (talk) 20:53, 21 January 2023 (UTC)

@Fytcha Yeah I agree with not collapsing cognates in most cases. Benwing2 (talk) 20:54, 21 January 2023 (UTC)

@Fytcha Rather than having a proliferation of such box templates I'd rather have a single template with a param that abbreviates both the title and the CSS class, maybe something like {{box-top|}} for cognates, {{box-top|}} for related terms, etc. The param can also be arbitrary text. Benwing2 (talk) 22:24, 21 January 2023 (UTC)

@Benwing2: While that seems reasonable and logical, I think in practice it would necessitate some heavy botting because I can't imagine the Wiktionary editor base correctly using these tags, seeing how often {{der-top}} and {{rel-top}} are currently being used misused. Just abbreviating and pasting the parent L3/L4 header into the box header seems to be very easily bottable, though. I would also encourage editors to stop putting cognates into boxes so much; the cognate line in, for instance, cold is merely ~1500 pixels long but I guess the argument is going to be that we should also take mobile users into consideration. — Fytcha〈 T | L | C 〉 09:50, 22 January 2023 (UTC)

Confer WT:RFDO#remove lesser-used column templates. As stated there, I'm supportive of the effort to consolidate this confusing proliferation of templates. Benwing2 proposed a {{ctop*}} family of templates, {{ctop2}} through {{ctop5}}; is that still your current thinking, Ben? Or was that superseded by {{box-top}}? The intended outcome of the changes proposed at RFDO needs a little more clarity imho.

As far as cognates are specifically concerned - I have never seen an entry that benefited from the hiding of cognates in a collapsible box. Where we link to high-quality proto-language entries that have complete lists of descendants, it should not be necessary to list all imaginable cognates in the etymology section - just selected ones from key languages. This, that and the other (talk) 08:07, 22 January 2023 (UTC)

@This, that and the other I'm thinking {{box-top*}} because some people objected to {{ctop*}} as being too ambiguous. I'm open to better names though. Maybe just {{box}}, {{box2}}, etc. in place of {{box-top}}, {{box-top2}}, etc., and {{-box}} in place of {{box-bottom}}, to save typing. I do need to clean up the table in WT:RFDO#remove lesser-used column templates now that some of the changes have been made, and clarify the remaining changes. Benwing2 (talk) 08:57, 22 January 2023 (UTC)

Thanks This, that and the other, I was not aware of this RFD but I'm fully in support of it. — Fytcha〈 T | L | C 〉 09:50, 22 January 2023 (UTC)

Excuse my ignorance @Benwing, Fytcha. I have always wondered. What is the difference of so many col templates? I have only used one: {{col2}} or col3 or col1 under all kinds of headings. At el.wikt we only have template ( and ) for separated thematic columns as in el:πείθω and templates (( and )) for continuous columns (but we do not have sort by lang) (++for Translations el:Template:μτφ-αρχή). Also have box. Thank you. ‑‑Sarri.greek ^♫ I 18:35, 22 January 2023 (UTC)

@Sarri.greek No ignorance here, you are completely right that there are too many of them, and we're trying to fix this. Benwing2 (talk) 21:57, 22 January 2023 (UTC)

Since I've had to manually override this in quite a few entries now I think it'd be helpful to have an in-built option in the declension module to suppress the "pre-Augustan" -ī genitive singular form for these nouns which is unhelpful for terms from Late/Medieval/etc. Latin. (A particularly bad example is caeliscalpium "skyscraper", where the non-lemma entry caeliscalpi was actually created by a well-meaning editor.) I tend to think this ought to be opt-in as well, especially since the wording "Found in older Latin" implies the form actually is attested for the entry it's displayed on, but that might be too much of a hassle at this point. @Benwing2 —Al-Muqanna المقنع (talk) 06:48, 22 January 2023 (UTC)

Can't you already do this by changing the <2> to <2.-ium>, etc.? 70.172.194.25 06:53, 22 January 2023 (UTC)

I guess you can! I wasn't aware of that since I've never seen it in use (and I've had to change a fair number of entries like this at this point). The opt-in point might be worth considering, though. —Al-Muqanna المقنع (talk) 07:09, 22 January 2023 (UTC)

@Al-Muqanna At one point I went through and edited all the Neo-Latin chemical elements, plus various Neo-Latin toponyms, etc. to add .-ium or .-ius, so I understand the issue can be annoying. (If this isn't properly documented, my fault.) Changing everything to opt-in can be done by bot without too much difficulty if the Latin editors agree; essentially you just need to add another flag with the opposite sense, something like .+ium or .+ius, and then flip all the terms ending in -ium or -ius. Not sure who works on Latin entries these days, maybe User:This, that and the other, User:Nicodene, User:Fay Freak? Benwing2 (talk) 07:22, 22 January 2023 (UTC)

I agree that this would be better as an opt-in flag, rather than opt-out as it is currently. Also ping @Urszag. This, that and the other (talk) 08:00, 22 January 2023 (UTC)

If it's easy to do, I would support changing it to an opt-in. While there are a fair number of words where it may apply, I think words with the short nominative singular in -ī are more of a closed category. I'd imagine that at this point, new Latin nouns that are added to Wiktionary are more likely to be from post-Classical Latin rather than early or Classical Latin. Incidentally, would there be any way to generate a list of which words are currently displayed with both -ī and -iī to facilitate auditing these entries?--Urszag (talk) 08:28, 22 January 2023 (UTC)

This search query seems to work. 70.172.194.25 08:32, 22 January 2023 (UTC)

What I can probably do is generate a page containing all the nouns displayed one way or the other along with their definitions, for easy auditing. The auditing can potentially be done by editing that page, and then a bot script will make the appropriate changes. It also sounds like there's a consensus to switch to opt-in short genitives. Benwing2 (talk) 08:53, 22 January 2023 (UTC)

@Al-Muqanna, Urszag, This, that and the other Please see User:Benwing2/la-noun-ius-ium and User:Benwing2/la-proper-noun-ius-ium. These include all Latin nouns and proper nouns in -ius/-ium, along with their declensions, defns, a column identifying whether the short genitive is suppressed, and a column in which a "yes" or "no" should be entered to indicate whether the noun is currently wrong in this regard (i.e. whether the value of the "Suppress Short Gen" column is wrong). This last column currently has a ? in it for all nouns and proper nouns but should be changed to a "yes" or "no" (or blank for "no"). Once this is done I will fix all the nouns and proper nouns with "yes" in the Wrong column. Benwing2 (talk) 11:05, 22 January 2023 (UTC)

@Urszag Thanks for starting on auditing the terms. Given the number of them, it might make more sense if you just identify all of the ones that you think do have a short genitive, and I'll have them opt into having a short genitive while all the others opt out. That way you don't have to spend a lot of time looking up the not-sure cases. Benwing2 (talk) 00:44, 23 January 2023 (UTC)

Sure, I can do that! I got distracted just now into looking into whether quō is ever really used as a feminine form of quis, but identifying the words that definitely do have a short genitive should be fairly simple (I can just check PHI and PedeCerto and if I see the genitive, that's done) so I'll work on that now. Thanks!--Urszag (talk) 00:49, 23 January 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I updated the list manually with some common words found in Plautus and other early Latin authors. I just found a book with tables on this subject, "On the Contracted Genitive in I in Latin" (William Augustus Merrill, 1969); while I can transcribe the information manually, I'm now wondering whether there's some way to pull the list from the existing scan.--Urszag (talk) 02:52, 23 January 2023 (UTC)

I got a plain text version of the list, so I will clean that up now and then post it on a userpage of my own.--Urszag (talk) 02:59, 23 January 2023 (UTC)

OK, I'll keep working on this tomorrow or later this week, but if anyone else wants to work on it, I put up the list I got from Merrill here: User:Urszag/genitive-ius-ium Somewhat annoyingly, Merrill lists the words by the genitive form.--Urszag (talk) 03:57, 23 January 2023 (UTC)

@Urszag Thanks for the info! Let me know when you feel it's in a relatively final form and I'll get to work fixing up the module code and the individual terms. Even if we make uncontracted-only the default, we can support a (redundant) indicator to specify this explicitly in case we want to surface this info (e.g. a note above the declension table saying "Only uncontracted genitive singular attested" or something). Benwing2 (talk) 23:11, 23 January 2023 (UTC)

@Benwing2 Thanks! I've finished marking all the words on that list that Merrill says are attested with a contracted genitive form. I haven't marked all the ones where he says that only the uncontracted form is attested. I think that information is not significant enough to warrant a note, and is likely to not be entirely certain. For example, one doubtful case that I ran into is "acatium": Merrill says only examples of acatii are attested, but some editions print "acati" where others have "acatii" in Pliny's Natural History. So in my opinion, it would be better to include it as a possible form. Working on this project also made me think a bit more about the reasons why we ought to include contracted forms. I think one fairly good reason, perhaps the best, is so that if a certain contracted form is reasonably likely to be encountered in reading by a Latin student, we can tell them what it means and direct them to the lemma: I think all of the most common attested contracted genitive forms are now marked, although some may have been omitted from Merrill's list.

Another, separate reason might be if we are trying to give an accurate picture of what forms are likely to have been used, regardless of whether we happen to have them attested or not. The value of this is I think a bit less clear: for example, scholars who are working on deciphering newly found documents surely would not need our help to point out that this kind of contracted form could have been used. However, perhaps listing the contracted form on some words, but not others might give a naive reader a misleading impression as to how common contracted forms were in the time period when they were used. For example, I think it seems pretty certain that words like amasius, used by Plautus, would have had in Plautus' time genitive forms like *amasī despite the fact that this form does not happen to be attested. That said, every other dictionary I've seen (L&S, Gaffiot, OLD) just gives the genitive of amasius in -ĭī, so I think it's fine for us to default to that as well; I would expect it to be declined this way if any modern author made use of it, and a reader isn't ever going to come across any examples of the hypothetical early Latin form *amasi.

So in the end, I still support changing to make the contracted forms an opt-in rather than opt-out for common nouns, and I think that should be ready to go forward now. (I haven't gone through proper nouns yet: I've read that for personal names, at least, -i is supposed to have continued to be used for a notably longer time period.) But I think the wording of the note "Found in older Latin (until the Augustan Age)" should be revised. Sturtevant 1902 writes that "the form with -i was the only one in use in early Latin for substantives. Adjectives, however, ended in -ii. the ending -ii is seen already in Propertius, and in Vergil, if one accepts Aen. III. 702 with its genitive fluvii. Ovid and most of the later poets use -ii prevailingly, but Manilius, Persius, and Martial use -i with a very few exceptions. The use of -ii on inscriptions dates from the end of Augustus's reign, but -i is the prevalent form throughout the empire. Proper names are especially conservative in the retention of -i" (Contraction in the case forms of the Latin io- and ia stems...). That is, it sounds like the Augustan Age is closer to being the start of the use of forms in -ii rather than the end of the use of forms in -i (for common nouns). I propose the wording "Found in early Latin; usual before the Augustan Age" to describe contracted forms.--Urszag (talk) 02:42, 24 January 2023 (UTC)

One other thing I thought of: if it does still seem useful to have an option to explicitly suppress the contracted form (for example, if we don't want to lose that information in case there's a decision in the future to change the default behavior back) I think it would be more helpful for the criteria and note to be based not on attestation of the genitive form, but on the age of the term itself. E.g. we could add a note saying "This word is first attested after the contracted genitive singular in -ī had passed out of regular use." on "New Latin" nouns with these endings.--Urszag (talk) 02:54, 24 January 2023 (UTC)

@Urszag Awesome, thanks! I'll go ahead and make the opt-in change. I agree with you that it would be more useful to specify the age of a term than simply that the contracted genitive is unattested; having this info specified should help for a whole range of reasons. We sort-of specify this now by notating words as Late Latin, Medieval Latin, New Latin, etc. but not consistently, and some places it's indicated may be wrong. This sort of info best goes in the Etymology section, though. Benwing2 (talk) 04:13, 24 January 2023 (UTC)

I recall that such a tool existed, but I cannot find it. Does anyone know of this? 70.172.194.25 01:36, 23 January 2023 (UTC)

What do you mean "words in passage not on Wiktionary"? Benwing2 (talk) 01:51, 23 January 2023 (UTC)

Given a passage (block of text), the tool would output the words contained in the passage that do not exist on Wiktionary. The version I remember was a Lua-based template that I think just checked each word (sequence of letters separated by spaces), without trying to normalize to a lemma form, to see if it was a redlink. But if anyone knows of another tool already written to accomplish this, I would be interested. 70.172.194.25 01:58, 23 January 2023 (UTC)

Palaeolithic method: copy-paste into a text file. Using search and replace in a text editor that can recognize control characters, convert everything that's not alphanumeric into "]]

Yeah, I was hoping someone else had already done the work. FWIW, here is a Unix one-liner to accomplish this:

grep -o -E '\w+' | sort -u | awk '{print "]"}'

You can add | tr '' '' to the end to make everything lowercase. A more complicated way of handling that is to output both the original and lowercase forms:

grep -o -E '\w+' | sort -u | PERLIO=:utf8 perl -lne 'print m|\p{Lu}|?"](}]])":"]"'

You can wrap the whole output in

{{l|en|2=}}

to support OrangeLinks and entry name normalization for languages where that's relevant. The first regular expression can be changed if you want a different definition of a word, e.g. '(\w|-)+' will make it count pseudo-science as one word instead of breaking it into "pseudo" and "science". 70.172.194.25 01:11, 24 January 2023 (UTC)

I see, I have a script to find red and yellow links on a given set of pages (among the 559 Wiktionary scripts I've written in the last 8 years or so) but presumably you're looking for something interactive? Benwing2 (talk) 02:38, 23 January 2023 (UTC)