Wiktionary:Beer parlour

Wiktionary > Discussion rooms > Beer parlour

Click here to start a new Beer parlour discussion.

Wiktionary discussion rooms (edit) see also: requests

Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.

Tea room start a new discussion | this month | archives Questions and discussions about specific words.

Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.

Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.

Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

Welcome to the Beer Parlour! This is the place where many a historic decision has been made, and where important discussions are being held daily. If you have a question about fundamental aspects of Wiktionary—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list below (click on Start a new discussion), and it will be considered. Please keep in mind the rules of discussion: remain civil, don’t make personal attacks, don’t change other people’s posts, and sign your comments with four tildes (~~~~), which produces your name with timestamp. Also keep in mind the purpose of this page and consider before posting here whether one of our other discussion rooms may be a more appropriate venue for your questions or concerns.

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

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

Beer parlour archives edit
2024 January February March April May June July August September October November December 2023 January February March April May June July August September October November December
Earlier years 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 January February March April May June July August September October November December 2005 January-March April-June July-September October-December 2004 January-March April-June July-September October-December 2003 January-March April-June July-September October-December 2002 December

October 2024

The root boxes were a bad idea?

Is it only me who finds it hard to orient amoung the etymologies for the root languages? I mean, Hebrew and Arabic, not the bock saga. I understand that it is a linguistical tradition to use root system for Semitic etymologies, because of the nature of semitic languages themself, when they are root languages.

But all these root-boxes are placed in a weird corner, and many of them do not even created, while many of the words have both etymology AND the root (see for example all the mess at אדום entry). In the same time, many of these root entries have no etymology either (see ث ق ل having no etymology, while its derived word ثقل has both root-box AND etymology).

If everybody think we should only use the root boxes insted of normal etymology system, than am gladly will help to sort out the Hebrew words at least into a root-box etymology system or whatever. But in this case, what we should do with the "Related terms" sections? They are completely useless if we use these root boxes (and we are using them already anyway, so this paradox bothers me even more). Tollef Salemann (talk) 15:31, 1 October 2024 (UTC)

The related terms sections are useless, given that they clutter the page, though the benefit outweigh the burden in other languages, and the root system is a better system that centralizes Semitic related terms. The rootboxes are also necessary because otherwise the etymologies are trivial non-etymologies just having the purpose of stating a root. I do not share your impression of weird corners; אדום is a good example: the etymology sections contains actual words, the boxes the superficial structure by which we make relations and new words could be created. Fay Freak (talk) 11:08, 4 October 2024 (UTC)

Should the letters of phonetic alphabets be 'letters' rather than 'symbols'?

I've noticed this discrepancy for a while. I assume it's because phonetic alphabets are usually unicameral, and perhaps it's a pain to have two 'letter' entries under Translingual, one with case and one without. I bring this up because of Latin chi, ꭓ, which has a capital form in Unicode not because of any national orthography, but because it has a distinct capital in Lepsius's phonetic alphabet. We therefore need to link to the capital from the lower case and vice versa, which means that we now have symbols with orthographic casing.

If we have 'symbols' that are cased letters, and used to write languages, what's the difference between a 'symbol' and a 'letter'? Should IPA, NAPA, Lepsius and Teuthonista letters all be moved to under a 'letter' heading? And if so, should we have two separate 'letter' headings for casing and non-casing uses, or can that be handled with a usage note? Actually, IPA and NAPA are occasionally used with casing too, though that's uncommon where they haven't been adopted as the basis of a national orthography. For example, there's an IPA version of Alice in Wonderland that's printed with capitals, and because of it those were added to Unicode when they didn't already exist. But sometimes texts of otherwise unwritten languages are spelled out in a phonetic alphabet with casing.

Might it be possible to add a note of 'rare' after a capital variant we list in the heading for a phonetic alphabet? Something like this:

Letter

ꭓ (upper case (rare) Ꭓ)

kwami (talk) 23:04, 2 October 2024 (UTC)

IMO no. Logically, IPA symbols are symbols not letters. Some of them look like letters but not all. Some IPA symbols like ɔ are also letters in certain languages and then have cased forms, but IMO they should be treated separately. Benwing2 (talk) 00:00, 4 October 2024 (UTC)

But what's the difference? Shouldn't the difference be one of function? Are casing Lepsius letters also 'symbols', or are they an exception because of casing? If it's casing, what about Georgian? And if it's appearance, what about the Hawaiian okina and the nasalization mark of Pe̍h-ōe-jī? Those cover the full range of IPA letters.

I know dictionary definitions don't always make a good argument, but MW defines a 'letter' as a symbol usually written or printed representing a speech sound and constituting a unit of an alphabet. That would seem to include the IPA. kwami (talk) 01:10, 4 October 2024 (UTC)

BTW, when IPA letters are used in national alphabets, they don't always have cased forms. Some of the orthographies are unicameral. kwami (talk) 01:49, 4 October 2024 (UTC)

I disagree: a letter is a written character that represents a speech sound for spoken languages. While the "IPA" is not a language, the written characters do represent speech sounds, just like any letter in the Cyrillic or Greek or Latin alphabets do. —Justin (koavf)❤T☮C☺M☯ 01:43, 4 October 2024 (UTC)

Do not automatically expand all sections on mobile

Tracked in Phabricator
Task T376446

In phab:T63447 ten years ago, Wikimedia sysadmins made the decision to enable a feature on the mobile version of the English Wiktionary that automatically expands all sections when a page is opened. The stated reason for this was that it "is pretty rough" when a page only has a single section (like English) and it is collapsed, forcing users to open it manually. However, this feature does not only act when the page only has a single section, but always. This

1. makes pages with multiple language editions annoying to read
2. makes long pages very slow

With pages that only contain a single section, we can easily implement a JavaScript feature ourselves that expands the section if there is only one. This cannot be done the other way around (collapse all sections), because it interferes with other logic (e.g. #English expands English automatically) and does nothing to address the slowdown caused by the browser having to render everything.

Therefore, I propose we seek community consensus to overturn this decision, which by itself seems to have been taken based on a small group of editors (most of whom were never particularly active on Wiktionary), and without discussion, let alone consensus, here on Wiktionary. — SURJECTION ^{/ T / C / L /} 15:52, 3 October 2024 (UTC)

Earlier discussions: Wiktionary:Information desk/2021/March#Always minimize all sections (mobile version), Wiktionary:Grease pit/2021/March#Wiktionary:Information desk/2021/March#Always minimize all sections (mobile version), Wiktionary:Grease pit/2021/June#Experience on mobile. — SURJECTION ^{/ T / C / L /} 16:01, 3 October 2024 (UTC)

I don't think people use their mobile phones much these daysDenazz (talk) 18:51, 3 October 2024 (UTC)

Where are people not using mobile phones now? 77.18.59.30 20:36, 3 October 2024 (UTC)

Denazz was being /s. I must admit I LOLd (non-/s​ly) when I read Denazz's comment. BTW, I support this proposal (non-/s​ly). Quercus solaris (talk) 22:18, 3 October 2024 (UTC)

Strong support. Of course having everything collapsed isn't great either, so I propose to have entries only expand the first section, whatever it may be (or it could be a more sophisticated thing that accounts for the height of each section — point being that it should be in our control). Ioaxxere (talk) 21:33, 3 October 2024 (UTC)

Support. I could imagine for example a gadget that allows the user to customize which section(s) to open (e.g. open a specific language's section), but I agree this should be under our control. Benwing2 (talk) 23:55, 3 October 2024 (UTC)

Support It is a PITA to use Wiktionary on mobile. — Fenakhay ^{(حيطي · مساهماتي)} 01:49, 4 October 2024 (UTC)

Support This has always annoyed me. Stujul (talk) 10:08, 4 October 2024 (UTC)

Weak support Has rarely annoyed me, but the rationale for the present setting only applies to Wikipedia and some other wikis but not the dictionaries. Fay Freak (talk) 11:13, 4 October 2024 (UTC)

Strong support. This has annoyed me for a while. —Caoimhin ceallach (talk) 11:58, 4 October 2024 (UTC)

Support. per Ioaxxare, always expanding the first section until another more sophisticated tool is created. Juwan (talk) 21:22, 5 October 2024 (UTC)

Support. Theknightwho (talk) 23:41, 5 October 2024 (UTC)

Support —Aryaman^{A (मुझसे बात करें • योगदान)} 07:29, 6 October 2024 (UTC)

Strong support — सौम्य (talk) 14:31, 6 October 2024 (UTC)

Support. IMO it should not always be the first section that is expanded, but the English section if available, and the first section if not (i.e. English should have precedence over Translingual). This is how Tabbed Languages currently works. — Vorziblix (talk · contribs) 23:33, 7 October 2024 (UTC)

Support Binarystep (talk) 05:12, 14 October 2024 (UTC)

Show portlet links to logged-out users

Tracked in Phabricator
Task T377648

On the mobile site, portlet links ("Discussion", "Citations") are not shown at all to logged-out users. This seems unfair. I think this is something that can be changed on the WMF's side, so I'm aiming to get consensus here and create a Phabricator task. Ioaxxere (talk) 21:40, 3 October 2024 (UTC)

Support, seems a no-brainer. Benwing2 (talk) 00:00, 4 October 2024 (UTC)

Support. Also find a way to display Citations when it exists, without the need for a gadget. — Fenakhay ^{(حيطي · مساهماتي)} 01:51, 4 October 2024 (UTC)

Support, I've wanted this for some time (and it's been a discussed problem for some time: I recall it coming up in some long-prior discussions about the utility of ====Quotations==== headers, and I brought it up in the recent vote about them). Weirdly, it seems to be device dependent (?), because if I view the mobile version of a page from a computer, I do see a "Citations:" link at the top, but I don't see it if I view the page from an actual mobile device. (I did just find that if I click the "last edited..." link at the bottom of the page, and go to the page history, I do see a link to the Citations page at the top of that page, but having to click through to an intermediary page is a faff.) - -sche (discuss) 05:10, 4 October 2024 (UTC)

Support Fay Freak (talk) 11:09, 4 October 2024 (UTC)

Support —Aryaman^{A (मुझसे बात करें • योगदान)} 07:29, 6 October 2024 (UTC)

Support Binarystep (talk) 05:13, 14 October 2024 (UTC)

Support This would clearly be helpful. -BRAINULATOR9 (TALK) 04:48, 16 October 2024 (UTC)

Support Juwan (talk) 10:52, 18 October 2024 (UTC)

Opposite synonyms

The adj utter means extreme and used with words with negative connotation; the adj. sublime also means extreme/complete, but used for positive connotations.

Is there a label for this type of relationship? Should they be added under the section "synonyms? JMGN (talk) 11:34, 6 October 2024 (UTC)

Although utter is not used exclusively with negative connotation (e.g., utter joy, utter bliss), no doubt there are some adjectives that are exclusively positive or negative in this way. I can't think of any metalanguage for this particular phenomenon, but I wouldn't be surprised if linguists have a name for it, because it reminds me of things such as some#Determiner versus any#Determiner, either versus neither (which some call an "assertive determiner" versus a "negative determiner"), and positive anymore, all of which linguists have metalanguage for, albeit not carved in stone. I would say yes, they should be added under synonyms, because a short label can be appended to them such as "exclusively negative" or "exclusively positive", or "chiefly negative" or "chiefly positive", or "negative counterpart" versus "positive counterpart", which would be both clear enough and succinct enough. Quercus solaris (talk) 00:55, 8 October 2024 (UTC)

ârbros

Please take a minute to look at the Pronunciation section at ârbros. I am not sure if it is the greatest piece of amateur lexicography since Thesaurus:penis/translations, or a massive stinking piece of misleading shit. Thoughts? Denazz (talk) 20:30, 6 October 2024 (UTC)

I don't think this is garbage. This is @Nicodene's work in conjunction with @Kc kennylau, based on various dialect dictionaries. Benwing2 (talk) 23:43, 7 October 2024 (UTC)

I suppose I should be flattered. Nicodene (talk) 01:11, 8 October 2024 (UTC)

I wish that there was less pronunciation immediately shown, but damn. Should be FWotD based on that section alone. CitationsFreak (talk) 04:39, 8 October 2024 (UTC)

Wow! That's exactly what we need to get for Norwegian! Currently, we've only got only some few examples like Norwegian Nynorsk furu, and they are very far from being fullfilled, especially compared to this example. Tollef Salemann (talk) 16:43, 8 October 2024 (UTC)

Can someone explain what is going on here? I was under the impression that within a certain language community at a certain place and time the pronunciation of words was more or less fixed. Is my understanding wrong or is Franco-Provencal different? Say I want to know how to say the word for "trees" in the dialect of Valais, am I to conclude that I can pronounce it however I damn well please? —Caoimhin ceallach (talk) 07:41, 8 October 2024 (UTC)

The areas in question are highly mountainous, meaning essentially each village had its own pronunciation. Valais is not a village but a canton containing lots of villages, so you can't logically talk about a single "Valais" pronunciation. Franco-Provençal seems somewhat extreme in the variation you see, but a similar situation pertains to Rhaeto-Romance, where again each village tends to have its own pronunciation. I think that even within the 7 or so identified "dialects" of Swiss Rhaeto-Romance (which generally go per valley), there are further subvariations in different villages in the same valley. Benwing2 (talk) 07:58, 8 October 2024 (UTC)

Ok, that makes sense. Do you agree though that the way the section is organised makes it appear like those pronunciations belong to a single dialect? Maybe it's a work in progress and I imagine it's a tricky thing to sort out, but a long list of pronunciations that aren't tied to a specific time and place isn't very useful. —Caoimhin ceallach (talk) 09:24, 8 October 2024 (UTC)

They are tied to specific places, which can be displayed by clicking “more”. Nicodene (talk) 09:37, 8 October 2024 (UTC)

I see. Well, I'm impressed! —Caoimhin ceallach (talk) 09:40, 8 October 2024 (UTC)

Providing a wrapper for the whole content of the section, to allow show/hide (collapse/expand) with collapsed being the default state, would be reasonable. Another layer of "show/hide" toggle, at a higher level than the existing "more/less" toggle (which would be nested beneath it). I am not one to whine that such collapsibility is desperately needed or sorely missed, but some humans are sticklers about it. Quercus solaris (talk) 16:27, 8 October 2024 (UTC)

• So these linguists went round the Swiss villages with pictures of trees and stuff and asked the locals "what are these?". Not a bad job, really! Phacromallus (talk) 22:07, 8 October 2024 (UTC)

Revising the accent's behaviour in WT:AVEC

@IvanScrooge98, Sartma While editing I gradually came to the realisation that the compromise we reached appears a bit inconsistent. Since we removed the accents from mid vowels on piane, I was thinking we could remove it everywhere, because it stands as a weird situation, in my opinion, now that è ò and é ó are distinguished in sdrucciole but not in piane. So I propose amending the guidelines and removing the written accent from sdrucciole and also from the puina~bevuo kind of words, keeping it only on tronche and monosyllables. (Secondarily, this change would also get rid of the issue of whether words like cauxa should be considered piane or not, and headwords would look slightly less clunky.) Of course, IPA will get even more necessary, which is perhaps in a sense also a positive consequence. What do you think? Catonif (talk) 10:21, 9 October 2024 (UTC)

I’m not sure removing accent marks altogether is a good option. Regarding the distinction of é/ó and vs è/ò only in proparoxytones, somethimg similar happens in Catalan and Portuguese, which have very well established conventions for accents. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] _{(parla con me)} 10:30, 9 October 2024 (UTC)

True, though from my Italian viewpoint saying liéoro with an accent and lievro without it looks a bit weird. Also pinging @GianWiki, Nicodene, Imetsia for further input. Catonif (talk) 19:34, 10 October 2024 (UTC)

Personally I would favour an all-or-nothing approach. That is, either marking all stressed mid-vowels as low-mid (◌̀) or high-mid (◌́), or marking no vowel at all that way. The Standard Italian practice of using these diacritics in oxytones and proparoxytones, but not in paroxytones, has never made sense to me. Nicodene (talk) 21:54, 11 October 2024 (UTC)

I'm a bit concerned that we're essentially making up spelling rules. How are such words normally written "in the wild"? We should try to follow whatever is done there. Benwing2 (talk) 05:25, 19 October 2024 (UTC)

@Benwing2 Your concern is very legitimate, the thing is, as Sartma said in the previous discussion, Native speakers of Venetan dialects use any sort of spelling. [...] I have no issues tanking a bold approach here and go with what we prefer, given that the standardisation attempts are also multiple and often disagreeable in some regards. Note I am very careful to describe every spelling I encounter "into the wild" and place it under alternative forms as an alternative spelling, so in the end no information is lost, but lemmatising at those spellings would be a mess in the long run. Catonif (talk) 09:24, 19 October 2024 (UTC)

@Catonif I see. In that case yes we should use some sort of normalized spelling and make all the attested variants be classified as alt spellings. Ideally the normalized spelling should match the practice used in dictionaries (or in at least one of them if there are multiple standards). I would also not favor an approach that simply discards all accents. Generally I prefer having more accents rather than fewer, but would not be opposed to following the Italian practice of marking accents only in final-stressed words and monosyllables. Benwing2 (talk) 21:22, 19 October 2024 (UTC)

I second most of this. I would rather have ràntego and dexéna than rantego and dexena. Italian accent rules should not be part of this unless they are followed more or less consistently by reputable sources/dictionaries. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] _{(parla con me)} 22:13, 19 October 2024 (UTC)

All fine with me. Benwing2 (talk) 06:36, 20 October 2024 (UTC)

@IvanScrooge98 I would rather have [...] dexéna than [...] dexena. I'm a bit confused, didn't you say I’d go for accent on neither regarding ⟨e⟩ and ⟨o⟩ in the past discussion? That's why we ditched the unambiguousness the system had. But anyways, personally I believe that Italian accent rules do play a role in this since to Venetan speakers they would seem natural and clean, rather than drawing parallels in Iberian orthographies. Catonif (talk) 16:54, 20 October 2024 (UTC)

What I meant is, if we have to choose between accent marks in all cases and no accents at all other than for final vowels, I’ll go for the first option. The parallel with Catalan and Portuguese was merely to point out the current “mixed system” isn’t an outright invention and has a history among Romance languages. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] _{(parla con me)} 19:06, 20 October 2024 (UTC)

unhiding the hidden

I vaguely remember someone saying they'd got a list of all the hidden comments in WT. Does this exist? I'm intrigued how much nonsense users have inserted over the years. Denazz (talk) 15:27, 10 October 2024 (UTC)

It is WT:BJ. Svartava (talk) 10:37, 12 October 2024 (UTC)

@Denazz: check out https://paste.ee/p/pew4Z Ioaxxere (talk) 05:26, 13 October 2024 (UTC)

Hmm, thanks. It is, understandably, mostly very boring. P. Sovjunk (talk) 23:36, 14 October 2024 (UTC)

Suggestions for labels

I have made many proposals for labels at Module talk:labels/data/topical and would like others to check them and suggest improvements and implements, as I don't have the appropriate user permissions to do so. Juwan (talk) 11:43, 11 October 2024 (UTC)

Proposal: make all maintenance categories hidden

Specifically, every category under Category:Wiktionary maintenance. Hidden categories are opt-in, rather than being shown to every logged-out user who visits the page. Our long pages have a massive amount of categories, and I feel that categories like Category:English terms with quotations or Category:English terms with homophones drown out the ones that a casual user might actually be interested in. To be clear, the only change I'm advocating for is to make these categories hidden by default on the entry — the pages will still be in them. What do you think? Ioaxxere (talk) 03:40, 12 October 2024 (UTC)

@Ioaxxere: no objection if there is an option for logged-in users to change the default and make these categories permanently visible. As someone who regularly tidies up entries, it is useful to see the categories. — Sgconlaw (talk) 11:37, 12 October 2024 (UTC)

@Sgconlaw: You can check the box at Special:Preferences → Appearance → Show hidden categories. Ioaxxere (talk) 18:29, 12 October 2024 (UTC)

@Ioaxxere: cool, thanks. — Sgconlaw (talk) 19:29, 12 October 2024 (UTC)

Eminently reasonable idea. Casual readers don't care or need to see these. —Justin (koavf)❤T☮C☺M☯ 16:28, 12 October 2024 (UTC)

Support Binarystep (talk) 05:13, 14 October 2024 (UTC)

Not Category:Entry maintenance by language though. It contains all the requests for translations, pronunciations etc., and I have inferred that we gain new editors, sought for foreign languages, by this. The others seem technical.

Category:English terms with homophones is not even under Category:Entry maintenance by language (but Category:Terms by lexical property by language and then already Category:Fundamental) and hence not Category:Wiktionary maintenance, while Category:English terms with quotations is only there via Category:Entry maintenance by language. You are confused, @Ioaxxere.

Don’t decide this without typically foreign-language editors, anyhow. For now I oppose for inconsiderate reasoning. Fay Freak (talk) 08:54, 15 October 2024 (UTC)

@Fay Freak: My mistake, you're right about the homophone categories — in that case nothing would happen to it, but I still think it should be hidden. But I think you've gotten confused as well, since requests for translations and pronunciations are already hidden, so there would be no change. Ioaxxere (talk) 13:39, 15 October 2024 (UTC)

Looking through Category:Spanish entry maintenance, these are the categories that I would find useful as a casual reader: terms with audio pronunciation, terms with IPA pronunciation, terms with quotations. These have strong applications for language learning, especially for smaller languages; all the other categories are more geared toward editing. I almost included Terms with collocations/usage examples, but those are more "nice to see on pages" than "worth clicking through a category", especially compared to quotations. Ultimateria (talk) 04:42, 16 October 2024 (UTC)

@Ioaxxere Most of these maintenance categories are already hidden, and in general the category system hides or shows categories on a per-category (technically, per-category-prototype, or whatever) basis rather than through blanket rules like "anything under Category:Wiktionary maintenance should be hidden". I think it's important to enumerate all the specific categories you think should be hidden which aren't currently hidden, and we can decide which ones should be hidden. Benwing2 (talk) 04:59, 19 October 2024 (UTC)

Also, I think that some of the categories under e.g. Category:Spanish entry maintenance should be grouped into subcategories to reduce the number of categories directly visible. In particular, some of the categories are purely for cleanup purposes (e.g. Category:Spanish terms with redundant script codes), but some aren't (e.g. Category:Spanish terms with quotations). Benwing2 (talk) 05:02, 19 October 2024 (UTC)

@Benwing2: That's a fair point. Here are a couple of specific examples: X terms with quotations, X terms with usage examples, X terms with collocations, X terms with IPA pronunciation, X terms with audio pronunciation, X terms with homophones (that last one isn't a maintenance category). But I think my proposal was motivated on the more philosophical point that it doesn't make sense to show anons categories that *we* describe as being for "maintenance". Ioaxxere (talk) 05:40, 19 October 2024 (UTC)

Right, and I agree with that in general; in fact, as I mentioned, most of these are already hidden. Just keep in mind that sometimes whether a category is considered "maintenance" isn't always clear-cut and whether it's under a maintenance umbrella category or umbrella metacategory may be a historical accident as opposed to something well thought-out. Benwing2 (talk) 05:48, 19 October 2024 (UTC)

Automated addition of 1953–1993 Romanian forms

Forms belonging to the previous Romanian orthographic standard should be added to Wiktionary. This unchallenging operation involves creating an alternative spelling entry containing the letter î corresponding to every present entry that contains the letter â.

To this end I propose creating the template {{ro-î-form of}}, displaying 1953–1993 spelling of [term]. The alternative forms would correspondingly be linked from the main entry with {{alt|ro|term||î-form}}.

Romanian-speaking admin Robbie SWE has also been consulted. According to User:Kc kennylau, this measure would affect almost 5000 entries. Potential anachronistic alternate forms for terms which did not yet exist when the former standard was in effect are, I can assure, very unlikely.

A number of such forms as I am talking about have already been created and are found in Category:Romanian superseded forms. The greater part of them claim to have been introduced in the 1904 standard; this is false, as said standard is (in regard to î and â) largely identical to the present one.

To expand on the previous: a small subset of the superseded î spellings had already been in use since 1904. Correction: it is actually the 1899 standard. They are inflections (participles, gerunds and first person plural present forms) of fourth conjugation verbs ending in -î, a closed class.

Special treatment is also required for derived terms of român, which under a 1964 provision were reverted to the spelling with â, identical to the present standard.

The previous two exceptions should be accommodated via a parameter; I propose |var=, which would either take the value ro (for derived terms of român, displaying 1953–1964 spelling) or 4 (for fourth conjugation forms, displaying 1904–1993 spelling 1899–1993 spelling). These adjustments will have to be made manually. ―⁠K_(ə)tom (talk) 21:45, 12 October 2024 (UTC)

Support This appears to be a sensible proposal. Einstein2 (talk) 20:38, 15 October 2024 (UTC)

I think this is fine if forms are attested somewhat, I try to stick to old spellings for Polish mostly if they exist. They usually do, but I'm the type of person to check everything. Vininn126 (talk) 20:40, 15 October 2024 (UTC)

The Communist period saw scholarly editions of old texts, obviously edited in the then-current orthography, in large numbers. Anachronism in the opposite direction—old words given in this newer orthography they were never printed in—is, while never completely unavoidable, almost as unlikely as the other sort of anachronism I mentioned in my first post. Let’s also not forget that the most comprehensive dictionary of Romanian was, for the most part, also compiled in this period, with the headwords using î. ―⁠K_(ə)tom (talk) 08:12, 17 October 2024 (UTC)

Do you have actual proof of that for Polish? Just restating the claim that they did and then being unable to produce many texts for them is kinda the exact thing we're trying to avoid on this website. Vininn126 (talk) 08:56, 17 October 2024 (UTC)

I don’t really understand your comment, but, either way, I have my corpora. And we aren’t doing the three attestations thing for alternative spellings, right? ―⁠K_(ə)tom (talk) 10:03, 17 October 2024 (UTC)

Sorry, I confused my threads. Please disregard that, haha! Otherwise this looks very sensible. I don't always do exactly 3 attestations for certain spellings, but I do check if it's there. Since some words came after certain spelling reforms and as such never had that old spelling, if that makes sense. Vininn126 (talk) 10:05, 17 October 2024 (UTC)

@Ktom It looks like you're requesting two things, a template {{ro-î-form of}} (which seems completely unobjectionable) and a bot job to create î-spellings of word spelled with â. I'm not convinced, however, despite your claim, that there really are no words in â created in Romanian since 1993. I'm sure there have been tons of words that have entered the Romanian language since then, many referring to new technologies, social movements and such that didn't exist in 1993. Logically, many of these words will be formed from existing Romanian words, and many of those words have â in them, so it seems hard to believe that there are no terms in â created since 1993. This means you might need to manually go through the list of the 5,000 or so existing words in â, and pick out the ones created after 1993, so that the variant in î doesn't get bot-created. Benwing2 (talk) 05:23, 19 October 2024 (UTC)

Î/â is a letter exclusive to native Romanian vocabulary, and Romanian is not big on coining words based on native roots and stuff like that.

Additionally, mass Romanian addition to Wiktionary was an operation dependent on dictionary entry lists, and any word not found as a headword in a dictionary was unlikely to be added; and given that Romanian dictionaries are laggards when it comes to adding new words, especially non-technical ones, the likelihood that we have a word found in a major dictionary that contains â and did not exist before 1993 is too low for me to consider.

Additionally, the letter â does not even appear in any inflectionary suffixes.

However, as a potential safeguard against adding an anachronistic î-form to some novel slang expression we may happen to have—and also for general cleanliness and anti-pedancy purposes—I do think there should be no alternative spelling entries made for multi-word terms. That may already be the policy, I don’t know about that. ―⁠K_(ə)tom (talk) 10:31, 19 October 2024 (UTC)

@Ktom Does â occur in derivational suffixes? Also I don't quite understand your point about Romanian dictionaries being laggards when adding new words; this may be true, but presumably the list of î-alternative forms will be based on existing Romanian lemmas in Wiktionary, rather than in some major print dictionary, and Wiktionary tends to have quite good coverage of slang and neologisms, at least in many languages. As for "there should be no alternative spelling entries made for multi-word terms" I don't know if there is any such policy, but this seems reasonable to me. Benwing2 (talk) 20:27, 19 October 2024 (UTC)

The point about the dictionaries is that Wiktionary does not have good coverage of Romanian non-dictionary terms, so we should expect our list of Romanian entries to align closely to the list of headwords of print dictionaries, a list whose newest additions belong only to international vocabulary. And no, â does not feature in any affixes. ―⁠K_(ə)tom (talk) 20:41, 19 October 2024 (UTC)

@Bogdan: What is your opinion in regard to this concern? ―⁠K_(ə)tom (talk) 10:43, 19 October 2024 (UTC)

Post-1993 borrowings are almost all from Western languages (or through a Western intermediary), so they don't have the î/â sound. Neologisms are almost never created internally in Romanian, the only case could be a slang word, but I don't think there are any that fit this criteria in Wiktionary. In theory, it could happen, but I think it's very unlikely. Bogdan (talk) 08:39, 20 October 2024 (UTC)

Support. I've added î-form (or î), î-form-ro (or î-ro) and î-form-4 (or î-4) at MOD:labels/data/lang/ro, so that now {{alt|ro|cîine||î}} displays cîine — 1953–1993 spelling and {{altsp|ro|câine|from=î}} displays 1953–1993 spelling of câine. I don't think the creation of a Romanian specific alt form template is needed. Catonif (talk) 20:48, 24 October 2024 (UTC)

@Benwing2: In light of the qualified opinions presented, do you find your concerns eased? As for me, after considering the facts, I’m relieved at how auspiciously unencumbered this entire measure has aligned itself to be: I mean, from morphological lack of productivity to—unaddressed but personally considered—compatibility with any future historical spellings we may some time implement, this truly makes for a best case scenario. ―⁠K_(ə)tom (talk) 20:01, 24 October 2024 (UTC)

@Ktom Although I'm still a bit leery of blithely assuming there are no post-1993 terms containing â, I won't object if someone wants to do a bot operation to add the relevant entries, and I agree with User:Catonif's approach of using labels rather than bespoke Romanian-specific templates. Also, please be aware that this is not as trivial as you may think it is, because you have to account for the possibility that there's already a Romanian entry using the spelling you're trying to add, or a different-language entry using the same spelling. Instances of the latter can be handled by appropriate bot code, but all such cases of the former need to be skipped by the bot and handled by hand. Benwing2 (talk) 08:16, 28 October 2024 (UTC)

Of course. The already created entries in question are to be found in Category:Romanian superseded forms (along with a few that pertain to different facets of previous standards), as well as cînd, which was in Category:Romanian dated forms. As for the choice of dedicated template, I had simply modelled myself on {{fr-pre-1990}} et sim. ―⁠K_(ə)tom (talk) 10:22, 28 October 2024 (UTC)

alternative form of/synonym of

What is the difference between {{alternative form of}} and {{synonym of}}, and when should each be used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:45, 13 October 2024 (UTC)

Wiktionary:Entry_layout#Alternative_forms. This should help a guess. Tollef Salemann (talk) 16:19, 13 October 2024 (UTC)

The verb stay mum is defined as an “alternative form of” keep mum, but I think this is wrong. I’d only use it if the terms, read aloud by the same speaker, are pronounced the same or almost the same.  --Lambiam 20:03, 13 October 2024 (UTC)

Right, I wouldn't say the pronunciation needs to be exactly the same, but an "alternative form" should have the same or a similar pronunciation and an identical or nearly identical etymology. Synonyms are commonly etymologically unrelated, but an alternative form never should be. For example, I think fo'castle is appropriately marked as an alternative form of forecastle. I'm not sure what the precise line should be between "alternative form of" and "alternative spelling of" (as used at foc's'le). In the context of languages with more inflections such as Latin, I've used "alternative form" for words where the root is shared and the definition is identical but the endings (and thus, pronunciation) differ, e.g. cornupeta and cornupetus.--Urszag (talk) 20:24, 13 October 2024 (UTC)

Actually, am agree with it in a way, but sometimes I find or create entries with similar construction: to do X or N with Y, where N is alternative to X. In this case it is indeed an alternative form of the phrase, but not word-for-word. We have a lot of such examples in Swedish and Nynorsk, but i can now only remember my own which i recently created: заправлять арапа (literally, to fill a black noble servant). You see, in theory you can put almost any verb in it, even a verb which doesnt exist, and the meaning is gonna be the same. So the difference in verb is not important, and therefore it’s not just synonymous, but rather alternative form.

If not, I will gladly go thru all this kinda phrases in Russian, Swedish and Nynorsk and put alternative forms into synonyms. But in this case we should disvuss it in a more wider discussion with all the editors. Tollef Salemann (talk) 20:26, 13 October 2024 (UTC)

Regarding lines between "alternative form of" and "alternative spelling of", it is true that the latter is logically hyponymous to the former, but one facet of the whole relationship that to my mind is clear is that an alternative spelling is solely another orthographic method of writing the selfsame set of sounds, whereas an alternative form that is not an alternative spelling involves a morphologic difference. Thus, neurologic and neurological should be marked with "alternative form of" (not "alternative spelling of"), whereas homolog and homologue, or sulfur and sulphur, should best be marked with "alternative spelling of" (not "alternative form of"). As for what to call idioms that are clearly the same thing conceptually but with a mere substitution of vocabulary (such as "don't give up your day job" versus "don't quit your day job"), this is where people quibble between "alternative form of" and "synonym of", and neither one is wrong (from one viewpoint or another), but I would support Wiktionary standardizing on "synonym of" as a consistent convention even though the alternative option is not wrong either; this would probably accord with what Lambiam and Urszag said. Idioms of that class can take only certain vocabulary item substitutions, not a limitless range of them, so I guess they are probably a different class from the class that Tollef mentioned. Quercus solaris (talk) 05:27, 14 October 2024 (UTC)

I think I'm in agreement with everyone above when I say something is an "alternative (form|spelling) of..." when it's merely another spelling/form of what is basically ~the same word, with (roughly) the same etymology (and same meaning).
When only the spelling differs, but the pronunciation is the same, it's an "alternative spelling of..." like kinikinic vs kinnikinnick, whereas when the form is different enough that the pronunciation also differs, like killikinick vs kinnikinnick, it's an "alternative form of...". There's been a proposal to make the templates spell this out, and an alternative proposal to give up on making the "form"-vs-"spelling" distinction at all.
When you've got different words for the same thing, like living rock vs living stone, that's when one is a "synonym of..."... but sometimes, people forgo using that template and just define stone as "Rock." (Your question makes me realize how non-obvious and potentially arbitrary our distinction can be to anyone unfamiliar with it.)
There is a smallish grey area when it comes to closely related words: e.g. suppose hofoobar is the Belarusian-derived English word for apple-flavoured vodka, and gofoobar is the Russian-derived word for it: are these alternative forms because they're closely related words for the same thing, or synonyms because they have different etymologies, one coming from one language and the other from a different language? But in such cases, there's often also some semantic difference, i.e. in such a scenario, gofoobar would typically mean "Russian apple-flavoured vodka" or "apple-flavoured vodka, especially from Russia" and hofoobar would typically mean "Belarusian apple-flavoured vodka", so you might just make each of those its own entry with its own separate definition, and link them as related terms...
(BTW, @ Quercus, for my part I'd probably just define "neurologic" as "Neurological.", rather than listing it as either an "alt form" or a synonym"; I suppose it's a similar grey area, as I'd be tempted to say the extra suffix -al makes it not an alternative form but a separate, synonymous word... but I can also see the argument for it being a mere alt form...) - -sche (discuss) 01:47, 15 October 2024 (UTC)

Preliminary results of the 2024 Wikimedia Foundation Board of Trustees elections

Hello all,

Thank you to everyone who participated in the 2024 Wikimedia Foundation Board of Trustees election. Close to 6000 community members from more than 180 wiki projects have voted.

The following four candidates were the most voted:

1. Christel Steigenberger
2. Maciej Artur Nadzikiewicz
3. Victoria Doronina
4. Lorenzo Losa

While these candidates have been ranked through the vote, they still need to be appointed to the Board of Trustees. They need to pass a successful background check and meet the qualifications outlined in the Bylaws. New trustees will be appointed at the next Board meeting in December 2024.

Learn more about the results on Meta-Wiki.

Best regards,

The Elections Committee and Board Selection Working Group

MPossoupe_(WMF) 08:26, 14 October 2024 (UTC)

User:Kwamikagami making a mess again

@Kwamikagami has been using {{mul-letter}} for non-translingual entries and has refused to learn and apply proper formatting or case. The history on the page ə is an absolute mess and trying to figure out a solution for the letter entries which are nigh unusable from ones on the edge of usability feels like a futile task. This is not to mention the fact the user has added tons of ill-researched letters without regard for whether they were actually widely used or not, instead focusing on an obsession for Unicode. I'm not even sure how to begin approaching trying to fix this page. We need input from other mods, @Benwing2, @Chuck Entz, @Surjection as bureucrats and @Thadh as an admin who has dealt with the user in question. Vininn126 (talk) 23:18, 14 October 2024 (UTC)

My initial suggestion on Discord was to just revert all pages to the last known good version before Kwami's edits (bot edits can be redone) but would like to hear from others. Benwing2 (talk) 23:28, 14 October 2024 (UTC)

I also don’t know what to do about changes that he’s made towards even just Nigerian languages. And as I’ve said before, we need more enforcement. If we had indefinitely blocked Kwami as people have requested in the past, the damage would not be as bad as it is right now. We need to stop being lenient with repetitive problematic users that have shown that they’re refusing to learn. Kwami is not the first one, but hopefully he’ll be the last. AG202 (talk) 23:44, 14 October 2024 (UTC)

Please provide one example of a problem I caused since my May block, apart from the Efik letter 'ñ' where sources are contradictory. kwami (talk) 19:22, 15 October 2024 (UTC)

He definitely listens to advice from time to time, and seems to show good faith, but there's an element of randomness in his decision-making that combines with the sheer volume of his edits and with the periods when he doesn't listen to produce lots of sheer nonsense. There are parts of Category:Entries with incorrect language header by language, WT:Todo/Lists/Template language code does not match header, and WT:Todo/Lists/Entries with no headword line that I steer clear of because they're such a morass- he's used just about every combination of L2 header and language code in his single-character entries. Sometimes he does things right, sometimes wrong, but he seems to be compelled to keep going at high volume no matter what. Chuck Entz (talk) 00:29, 15 October 2024 (UTC)

I see I did use 'mul-letter' for the Osage entry of schwa back in January. I'd be curious if I've made that error more recently. I do know to use the ISO code for the language, but evidently I sometimes overlook it when I copy-paste from another entry or article. I copy-paste because I've found that I may omit critical things if I create an entry from scratch, or not use the proper formatting. It's best for me to copy an established framework.

If you just drop a note on my talk page that I made a mess of schwa or whatever, I'm happy to correct myself. Or that an a number of errors in some tracking cat are from me, I'll go through them. kwami (talk) 00:57, 15 October 2024 (UTC)

BTW, I'm currently blocked from correcting the schwa article.

I guess what I'm confused by, if I've made a 'shitty edit', or especially a number of them, why not just tell me so that I know to fix them? Certainly if you avoid a whole tracking category because of me, I should take care of it. Vin keeps saying I 'refuse to learn', but there's no refusal -- I need feedback. When I do things that inconvenience other editors, sure, you shouldn't have to clean up after me. Just tell me so I can clean up after myself. It's not intentional. Also, I'd be curious if I've made any errors of fact, or if it's all template and formatting errors. (P.S. In case you think I forgot, an editor did complain not long ago that I made an error of fact with the Efik alphabet and should have know better, but AFAICT the difference is a matter of user or publisher preference -- I followed curriculum materials and monolingual print publication.) kwami (talk) 01:00, 15 October 2024 (UTC)

AG202 specifically referred to problems with your edits of Nigerian languages, which (as can be seen from this thread on your talkpage) is a linguistic issue, not a formatting one. Vininn126 also said the user has added tons of ill-researched letters without regard for whether they were actually widely used or not, which is not about formatting either. Whatever the merits of those complaints, people clearly have more issues with your edits than merely formatting, so please take the time to read the threads you are replying to properly in future. Theknightwho (talk) 01:34, 15 October 2024 (UTC)

Yes, that's the Efik alphabet issue that I mentioned above. I did of course take the time to read it, and AFAICT my use of the letter n-macron was correct, though I did change it as requested. (AG, if you could respond to that thread, I'd appreciate it.) As for Vin saying saying I've added 'tons' of ill-researched letters, he hasn't provided any examples that I recall of anything I've done since my block. All specific complaints have been about cleaning up tracking categories. Someone once objected that it was inappropriate to create individual entries for Yoruba letters with diacritics, as I had done, but that was years ago and I don't know of any other mess I've made with Nigerian languages since.

Is it inappropriate to create Wiktionary entries for Unicode characters? I often come to Wikt to discover the usage of some obscure Unicode character that I happen across, and it can be frustrating when we have no information here, or when we only repeat the Unicode name. So yes, I have been fleshing out our coverage. If that's not acceptable, please let me know. kwami (talk) 01:50, 15 October 2024 (UTC)

"Officer, why didn't you warn me about the kid on the skateboard? I didn't see him until it was too late. And I'm truly sorry about the medians over that 5-mile stretch." As a responsible wiki editor, you shouldn't require constant supervision to keep you from veering off in the wrong direction, and you shouldn't be going so fast that mistakes turn into huge cleanup projects before anyone spots them. Chuck Entz (talk) 02:16, 15 October 2024 (UTC)

So, basically, the problem seems to be that I add too many quick entries, that I should slow down with my contributions. Well, a block will certainly accomplish that.

There are two kinds of complaint against me. One, that I make factual errors. Vin keeps saying that, but hasn't provided any examples of something I've done recently [e.g. since my block]. So I don't know if this is actually a problem, or if Vin is not letting go of past history [like the Yoruba letters with diacritics]. Two, that I make sloppy edits that cause problems with tracking categories. I've certainly done that. I copy-paste from existing articles to get the formatting and templating correct, but sometimes overlook adjustments -- such as missing a template when I change the ISO codes, or not re-indenting the subheadings. Or perhaps there are other adjustments I don't know to make. That's a problem. I thought it was something that I could fix by reviewing the tracking category when my errors crop up there, but I guess that's not going to work. kwami (talk) 02:47, 15 October 2024 (UTC)

You've been warned of making a mess before, and while you say you've done that, the fact you've been warned and still need to ask in this thread what you've done shows either you are playing dumb or can't learn from your mistakes while still leaving a massive mess. Vininn126 (talk) 08:22, 15 October 2024 (UTC)

This edit is from January, 4 months before my block! This isn't evidence I'm not being more careful since. kwami (talk) 17:49, 15 October 2024 (UTC)

For reference, this PetScan should have all the entries in question. It's most Osage letters and quite a bit more, not just the schwa. -saph668 (user—talk—contribs) 10:27, 15 October 2024 (UTC)

Thank you for that. If someone had notified me before my block, I would have cleaned them all up. kwami (talk) 19:07, 15 October 2024 (UTC)

I've gone through them, and where the error is mine, they're all old, from before my block. I don't see anything I've done since then. kwami (talk) 19:12, 15 October 2024 (UTC)

• Us Wiktionarians are renowned for making a mess. I make plenty, mostly accidentally. There's a fine line to tread between high-speed edits and high-quality edits. If one user, for example, churns out 98 decent audios in an hour, 2 unclear audios and 1 fart sound that they stick on the Pronunciation section of penguin, we have a net gain - the fart sound will get quickly reverted, while the unclears should get noticed eventually. Yes, it can be annoying to correct, but part of wikiculture is to clean up others' (and our own) shit. We all need supervision - even our bureaucrats! BenWing's bot has brought up plenty of errors (soon corrected) and Chuck Entz....well, he...that joker....err...well....actually that guy is an exception, having a basically untarnished record. By the way, I've not looked into kwami's case, this is just a general observation. P. Sovjunk (talk) 11:58, 15 October 2024 (UTC)

  Yes, we all make mistakes. I frequently make typos or other things, but the ratio of mess-productivity is what's important, and also I'm open to people asking me to clean it up, you can see my talkpage where Chuck frequently asks me to clean up my mess. Vininn126 (talk) 12:01, 15 October 2024 (UTC)

  Then why not have the same courtesy toward me, and notify me on my talk page when I make a mess, so that I have the same opportunity to clean it up? kwami (talk) 17:51, 15 October 2024 (UTC)

  I literally just explained that you've been warned multiple times. That's the courteousy. Vininn126 (talk) 17:54, 15 October 2024 (UTC)

  Since my May block, there have been 4 threads on my talk page.

  • One about fixing an error in arrow emojis.
  • One where I followed Chuck Entz's lead in moving Tahitian entries from an ASCII apostrophe to a proper okina, and he reverted me. He later said he didn't remember his earlier page moves.
  • One where someone informed me it wasn't appropriate to do the same for Old Tupi, and I corrected myself.
  • One for the Efik alphabet, mentioned above. Again, I corrected myself, though I doubt it was a correction.

  So, again, if I make an error, why don't you have the same courtesy Chuck has for you, and notify me that I made an error? I am also willing to correct myself. kwami (talk) 18:06, 15 October 2024 (UTC)

As I said before, I think it's time to re-do the the famous vote on this issue and if it passes we'll be done with the whole problem all together. As for specifically this incident, I do think Kwami has a long history of messing up, being told not to do it, and then continuing to do the exact same thing. Thadh (talk) 14:58, 15 October 2024 (UTC)

I will strongly oppose this once again. I would hate for people's legitimate work to go down the drain because of a user who was allowed a free rein of terror because you all refused to take appropriate action. It's disappointing. AG202 (talk) 15:42, 15 October 2024 (UTC)

Whose work has gone down the drain? Your only objection on my talk page is that I followed Efik print sources for the Efik alphabet, rather than online English-language sources. I changed the letters to match the English sources, though you have yet to answer my question as to why we shouldn't prefer professional Efik-language sources. Regardless, that's hardly a case of people's legitimate work going down the drain, since there was no Efik-alphabet template before I created it. kwami (talk) 17:57, 15 October 2024 (UTC)

And the constant denial begins again. It never changes. Vininn126 (talk) 17:59, 15 October 2024 (UTC)

I think you've misread AG202's comment: "I would hate for people's legitimate work to go down the drain" isn't about anything you did. It refers to the loss of useful information that would occur if Thadh's proposal to remove all letter entries not under Translingual passed (it failed, but Thadh is now suggesting trying it again as a way to avoid arguing about the entries you were working on).--Urszag (talk) 18:07, 15 October 2024 (UTC)

Ah, okay. Yes, I thought it was about me. kwami (talk) 18:10, 15 October 2024 (UTC)

That seems a strange solution. saph668 just provided a useful Petscan link above, and all my errors are old, predating my May block. I don't see any evidence this is an ongoing problem, and if I'd seen the Petscan results earlier [I had no idea such a thing existed], I could've cleaned them up myself. kwami (talk) 19:15, 15 October 2024 (UTC)

User:Victar and false citations

I have come across two instances of Victar citing sources in support for specific claims, in which if you actually checked the source he cited, the scholar actually said something else.

The instances are:

• On Latin rutilus, he cited this month two scholars who actually made the exact opposite claim to what Victar wrote: he wrote that original second vowel was *-e-, when the two sources cited actually said *-i-, and Victar wrote that this word was a diminutive when the two sources actually say that the -lus in this word was of non-diminutive origin.
• On what is now Proto-Brythonic *giow, Victar in 2019 cited two sources (EDPC and McCone) for a claim that this word came from a Proto-Celtic athematic root noun, when they actually both reconstruct thematic Proto-Celtic *gyos.

I have reminded Victar on his talk page to stop doing this, but he responded that he saw such a reminder as a "waste of time" and told me to "take it to the entries". Surely, false use of citations should not be condoned nor should it rest on the shoulders of other editors to correct after the fact? — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 03:41, 15 October 2024 (UTC)

So the whole etymology I cite that line is correct to the source, but because I used an *-elos in the Proto-Italic suffix instead of an *-ilos, the etymology is the "exact opposite"? The suffix *-elos is the correct Proto-Italic reconstruction of the suffix both according to {{R:ine:de Goede:2014|15}} and {{R:itc:EDL}}. We're not beholden to follow sources to the exact letter when they're outdated or wrong, otherwise our PIE reconstructions would look like *ərāu-.

@Benwing2, how about we make exaggerated and false accusations a "blockable offense", per your discord comment. --{{victar|talk}} 05:11, 15 October 2024 (UTC)

First of all, I don't appreciate the snark. Secondly while I do understand the principle of correcting notation to the latest scholarly consensus (although if you think *-ilos is outdated, it is strange that the citation is from 2019), you didn't respond to any of the other points made by User:Mellohi!. Third, why don't you respond on Discord directly if you're lurking in the background? Benwing2 (talk) 05:39, 15 October 2024 (UTC)

@Victar, how about we not make exaggerated and false accusations about someone else's accusations? Regardless of who's right here, throwing around accusations of bad faith and requesting someone be blocked because they questioned your actions isn't helping you at all. Chuck Entz (talk) 05:46, 15 October 2024 (UTC)

It's bad faith for @Benwing2 to threaten a block without even looking at the edit. --{{victar|talk}} 05:51, 15 October 2024 (UTC)

Benwing2 specifically said IMO falsely citing sources is a blockable offense. If this happens again, let me know. It is a blockable offence in my view as well, as it shows academic dishonesty, which is something we cannot tolerate on Wiktionary. This is not bad faith to point out. Theknightwho (talk) 16:19, 15 October 2024 (UTC)

There is an important difference between normalizing the spelling of a reconstruction to a different standard (the case of *ərāu-) vs. claiming that an author used one derivational pathway when they actually used a different one (as with rutilus).

• Prosper says that the adjectival suffix for rutilus is essentially lambdacized -idus - absolutely no diminutive *-elos involved.
• Schaffner specified *-i-los and not *-elos because he is not deriving with diminutive *-elos either; the word does not end in -ulus as one would expect from *-elos (only *-ilos can become -ilus in Schaffner's understanding), and the -los suffix (with no *-e-!) Schaffner derives rutilus with has possessive function (not diminutive function); the -i- is derived by Schaffner from base *rutis.

In neither case should these sources be cited for a claim that rutilus was derived with the diminutive suffix *-elos. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 06:28, 15 October 2024 (UTC)

Proto-Italic *-elos isn't just a diminutive suffix, see {{R:ine:de Goede:2014|15}}, where it lists its function as forming "desubstantival and deadjectival diminutive nouns", "verbal adjectives", and "desubstantival adjectives". Bare Proto-Italic *-los, as far as I know, was only ever appended to the root -- I don't know of any cases of *ROOT-i-los, or instances of an *-ilos suffix in Proto-Italic.

Additionally, rutilus is also attested as rutulus (Verg. A. 8.430), and Latin is no stranger to -ulus ~ -ilus ~ -illus variants, compare caupulus ~ caupilus ~ caupillus. According to Sen (2015) p22, the -i- in rutilus can be explained as a "dissimilation of lip-rounding from immediately preceding /kʷ/, or /u/ in the preceding syllable".

Again, this could have been discussed on the entry page. --{{victar|talk}} 07:38, 15 October 2024 (UTC)

The point is that you should not be attributing your own (or De Goede's, or Sen's, etc.) thoughts on a matter to another scholar who does not share the same thought process (Schaffner in this case).

• Why did you specify "diminutive suffix" in your edit citing Schaffner when Schaffner specifically invokes a non-diminutive function of Proto-Indo-European *-lós?
• Again, why did you cite Schaffner, who evidently does not share your line of thought that "Bare Proto-Italic *-los, as far as I know, was only ever appended to the root...", given he derives rutilus from stacking -los on top of a base *rutis in the first place?
• And why did you cite Schaffner for *rutelos > rutilus when he draws a phonological distinction between *rutelos > rutulus and *rutilos > rutilus?

You have also not explained your citation of Prosper to support a -los derivation when she outright dismisses such a notion in her paper that was cited. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 12:04, 15 October 2024 (UTC)

@Mellohi!: All you've managed to reply is "Schaffner reconstructs an *-i-", without addressing any of my argumenets or giving any counterexamples. Again, "we're not beholden to follow sources to the exact letter when they're outdated or wrong", and the sources I've given say Schaffner is wrong in reconstructing *-ilos, including Prosper. --{{victar|talk}} 20:08, 15 October 2024 (UTC)

Regardless of whether "we're not beholden to follow sources to the exact letter when they're outdated or wrong", citations must not be formatted in a way that suggests that the sources say something that they didn't, because this is false representation of the sources.--Urszag (talk) 20:25, 15 October 2024 (UTC)

It does not matter whether you or me, other scholars, or anyone else think Schaffner or Prosper are right or wrong; the point is that you cannot cite them to support a derivation from *rutelos > rutilus when these two do not posit such an etymology in the first place. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 20:40, 15 October 2024 (UTC)

And the references are there from Schaffner and Prosper to support the derivation from Proto-Indo-European *h₂rew-, which they do. If we had the ability to reference only certain sections of a sentence and not others, then there might be a point to be made about the source being in the wrong place, but we do not. --{{victar|talk}} 21:00, 15 October 2024 (UTC)

Nothing in this version of the page makes it clear that the citations only refer to the derivation from PIE, and not the derivation from Proto-Italic or the affixation, which (together) are the primary statement of the sentence those citations purport to cite. You could easily have provided a reference partway through the sentence, or clarified that the references only support the PIE derivation, but you did not. Theknightwho (talk) 21:10, 15 October 2024 (UTC)

Victar seems to still be failing to understand that the issue is not the accuracy or credibility of the sources themselves, but the fact that it is dishonest to misrepresent what they say. Frankly, the seriousness of the issue, the repeat offences, the failure to properly address the accusation and the baseless accusations of bad faith in return incline me towards a block. Falsifying sources simply cannot be tolerated on Wiktionary if we're going to have any credibility as a resource. Theknightwho (talk) 20:47, 15 October 2024 (UTC)

Just saying, but in case you missed this, there's also this. Relevant quote about *ȷ́ʰárati:

"Having the PIIr entry read "Rix derives the verb from Proto-Indo-European *ǵʰérm̥-ti ~ *ǵʰr̥m-énti / *ǵʰr̥m-tór ~ *ǵʰr̥m-n̥tór" is completely misleading." ... "What is actually given by LIV at p.178 is: Präsens *ĝʰR̥-né/n-H-"

(yes, that still needs to be cleaned up, but there are several roots to disentangle) Exarchus (talk) 19:11, 29 October 2024 (UTC)

There's also Wiktionary:Requests_for_deletion/Reconstruction#Reconstruction:Proto-Indo-Iranian/Háȷ́ʰāȷ́ʰaršt, where victar made it clear that despite this discussion, he sees nothing wrong with putting a citation at the end of a sentence that is not fully supported by the cited sources (and may even be contradicted by them). I can only assume victar is planning to keep at this practice.--Urszag (talk) 19:27, 29 October 2024 (UTC)

The fact that Victar still sees fit to do this even after this discussion is beyond the pale for me. @Benwing2 @Surjection @Chuck Entz I intend to block Victar for a week, pending any objections - please do let me know if you have any. Theknightwho (talk) 22:25, 29 October 2024 (UTC)

I don't have any objections, and in fact given what @Urszag said just above, I think a longer block might be in order. Misrepresenting cited sources is a serious issue and doubling down when confronted with the problem does not instill confidence. Benwing2 (talk) 22:43, 29 October 2024 (UTC)

I am also reminded of Victar once altering the vowel of a reconstruction given by two sources to a phonemically different vowel. Victar still retained the two citations to support his altered form *fellō even though the two sources explicitly said *fillō. Discussion of this incident did not find Victar's alteration of the reconstruction to be warranted. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 17:06, 15 October 2024 (UTC)

I also think Victar/Sokkjo should be more careful with references. Examples where I recently noticed that he used references to support reconstructions that are very far removed from what is actually in those references are *gʰrem- (which has been thoroughly cleaned up) and *ǵéwseti (which still has many problems). —Caoimhin ceallach (talk) 22:39, 16 October 2024 (UTC)

I should add that I generally think he does great work, but there are too many cases where he slips up and then refuses to admit a mistake. —Caoimhin ceallach (talk) 22:44, 16 October 2024 (UTC)

If a statement is followed by an inline citation, then that statement should be accurate to what the cited work says. It’s fine if an editor wishes to contradict some (or even all) the cited sources, but they should make it clear that they are doing so and, ideally, explain their reasoning. Nicodene (talk) 23:22, 16 October 2024 (UTC)

I will pile on and say that yes, it is important that we do not make claims that are not present in the sources, or ascribe to sources claims that they do not make, and would support a block if an editor refuses to abide by these principles. — SURJECTION ^{/ T / C / L /} 20:29, 29 October 2024 (UTC)

Generally, this should be obvious. There are times when certain information has to be extrapolated from sources, but as stated above, it should be clear, and Victar's work above is fairly clearly across the line for me. Vininn126 (talk) 20:32, 29 October 2024 (UTC)

I think he justly asserted that it is only to be taken to the entries, since it is obvious that he knows the lines. It is just quite challenging an art to clarify in each footnote and referenced sentence in what respect exactly, without also loosing the line of thought of what one actually wanted to do, the citation – which might not even be directly in view, amongst dozens of other ones in view and in mind – corresponds to the points made by the editor(s), suffocating his creativity, which does not arise from a dichotomic phenomonology differentiating conclusions experienced in references and additions to them assessed for Wiktionary, but on the contrary from the combination of all material. Fay Freak (talk) 20:47, 29 October 2024 (UTC)

I don't think it is obvious that he knows the lines, given the persistent evidence he is willing to cross them: this looks like a real disagreement to me. If it's too difficult to place inline citations accurately, there's no obligation to use them as opposed to citing relevant sources as general references in a "Further reading" section.--Urszag (talk) 21:49, 29 October 2024 (UTC)

This is a good summary. There's no need to becry a limitation of editors' creativity when we are first and foremost a scholarly source. Vininn126 (talk) 21:54, 29 October 2024 (UTC)

If one wishes to write a sentence that is only partly supported by a source, one can simply start the sentence with whatever is true to that source, add the inline reference at that point, and then for the rest of the sentence continue with one’s own ideas. Nicodene (talk) 17:20, 31 October 2024 (UTC)

FWIW, to me blocking Victar for a week seems mostly counter-productive, to solve this for the long run we should probably add a section to WT:REF, approved by community consesus through a formal vote, where we have a clear and specific description of where to place references in sentences, on the steps of w:WP:INTEGRITY which Urszag mentioned on the PII RFD discussion. Catonif (talk) 16:07, 31 October 2024 (UTC)

I wouldn’t have blocked Victar had they not decided to keep defending it in a current discussion at WT:RFDR, which makes it ongoing disruption; as Caoimhin ceallach put it there, It is ludicrous that we are arguing about this. If Victar had shown any kind of willingness to correct the issue it would be different, but the fact is that they haven’t, and instead they decided to keep defending it, wasting everyone else’s time.

I do agree with adding this as a formal policy, though. Theknightwho (talk) 17:19, 31 October 2024 (UTC)

I can't help mentioning that at Proto-Indo-European *yem-, I found Victar giving (six years ago) a "narten-type root aorist present" (?!?) with 4 'references' (counting all relevant languages), and then also a reference for Sanskrit yantúr contradicting Victar's reconstruction (although to be fair, the reference wasn't placed beside the reconstruction). Exarchus (talk) 13:28, 2 November 2024 (UTC)

I would support such a vote. — SURJECTION ^{/ T / C / L /} 18:26, 31 October 2024 (UTC)

I scribbled down two short paragraphs (stubs) which would cover this and was planning to open a vote about appending them to WT:REF#Etymologies, but I notice that it is not a formal policy and may be edited without a vote. So I could add it there and then run a vote for making WT:REF a formal policy, but I fear it may be problematic due to the part where it says it is necessary to mention the author/work, which sounds controversial (or unclear). What do you think is the best course of action? Catonif (talk) 21:11, 2 November 2024 (UTC)

@Catonif I wonder if we shouldn't create a separate policy page that contains only the formally voted-on text. Besides the potentially problematic text you called out, there's also the issue of the ==References== header itself, where there was relatively recently a whole (failed) vote on what it should be called and how to separate out References, Further reading, etc. Benwing2 (talk) 21:50, 2 November 2024 (UTC)

Seeking volunteers to join several of the movement’s committees

Each year, typically from October through December, several of the movement’s committees seek new volunteers.

Read more about the committees on their Meta-wiki pages:

• Affiliations Committee (AffCom)
• Ombuds commission (OC)
• Case Review Committee (CRC)

Applications for the committees open on 16 October 2024. Applications for the Affiliations Committee close on 18 November 2024, and applications for the Ombuds commission and the Case Review Committee close on 2 December 2024. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cst@wikimedia.org with any questions you may have.

For the Committee Support team,

-- Keegan (WMF) (talk) 23:09, 16 October 2024 (UTC)

• I'll do it! Erp1039 (talk) 23:22, 17 October 2024 (UTC)

Cleanup of interwiki links

I wish to request some cleanup for the appendices and Wiktionary namespaces relating to how interwiki links are handled. many of these pages have interwiki links still present at the bottom of the page. these should be moved to Wikidata, and I am dumbfounded how they managed to remain here in 2024.

if any experienced scripters know how to find all the pages that have these interwiki, please feel free to help! Juwan (talk) 10:50, 18 October 2024 (UTC)

To be clear, how interwiki links are created and stored at Wikidata is different from how it is at other sister projects. See d:Wikidata:Wiktionary. —Justin (koavf)❤T☮C☺M☯ 11:48, 18 October 2024 (UTC)

@Theknightwho I want to know what was the reasoning for this diff. the page remained fine because it was linked on Wikidata, showing other wikis either way. Juwan (talk) 17:53, 18 October 2024 (UTC)

@JnpoJuwan Alright, fair enough. My bad. Theknightwho (talk) 18:00, 18 October 2024 (UTC)

Changing the default skin to Vector 2022

Initial discussion

I've been personally using Vector 2022 for a little while and enjoying it a lot. I'm curious whether we can reach consensus to enable it as the default skin across the site, and reap a number of UX benefits — namely:

• The Vector 2022 TOC is objectively better than Vector's since it doesn't push the content down.
• Customizable text size and width.
• Dark mode is supported out of the box, and with MediaWiki:Gadget-Palette.css and MediaWiki:Gadget-AutoContrastFixer.js, it works pretty well with our templates.

That's a purely objective comparison, since I think both skins are very attractive in terms of appearance. What do you think? Ioaxxere (talk) 04:28, 19 October 2024 (UTC)

We had this discussion before and a bunch of people objected to Vector 2022. IMO the biggest problem is the waste of horizontal space taken up by the two sidebars. In comparison, Vector 2010 has only one sidebar of smaller width than either of the two Vector 2022 sidebars. You can hide the Tools sidebar on the right, but then, it seems, you don't have easy access to things like User contributions. And if you "hide" the table of contents on the left, the width doesn't get reclaimed; instead you just get a big blank space on the left. Benwing2 (talk) 04:41, 19 October 2024 (UTC)

@Benwing2: Actually, if you clear the sidebars, set the text size to "small", and set the width to "wide", you can get more horizontal space than you can in Vector. You're right that this comes at the cost of additional clicks for some things, but I personally haven't found that to be an issue. Ioaxxere (talk) 05:40, 19 October 2024 (UTC)

It isn't ready. The last point also comes across as a bit disingenuous to me, because the option to enable dark mode isn't even shown to users (when I last tried). — SURJECTION ^{/ T / C / L /} 06:39, 21 October 2024 (UTC)

Hey @Surjection, I'm Szymon from the Movement Communications team, also a member of the Web team which built Vector 2022. I wanted to clarify that dark mode is enabled for logged-in users in Vector 2022; it's either in the right menu under the label Appearance (if the menu is pinned), or under a glasses icon at the top of the page (if the menu is un-pinned).

Dark mode is not available for logged-out users and the deployment of Vector 2022 is a prerequisite, but the two things don't necessarily come together. Meaning, there needs to be few accessibility issues on a given wiki, and only then Web enables dark mode. We can talk about limiting the accessibility issues, but that may be a separate discussion. I think it would be easier for both your community and us since a talk about dark mode is way more technical than about the skin change. It's focused on CSS, templates and modules, this kind of stuff. I hope this makes sense. SGrabarczuk (WMF) (talk) 03:15, 6 November 2024 (UTC)

@SGrabarczuk (WMF) I am one of the three active bureaucrats here at the English Wiktionary (along with @Surjection and @Chuck Entz). I rather feel this is being forced down our throats. Vector 2022 was evidently designed with Wikipedia in mind and still has significant issues when it comes to Wiktionary, especially concerning wasted space with the added and increased-width left and right rails. As you can easily see in the screen shots posted below under "Update from the Foundation", there is a lot of wasted whitespace on both sides. This is an issue for Wiktionary because we have a lot of conjugation and declension tables that are of necessity wide due to the complexity of the languages in question. Redesigning all of them to deal with the narrower main area is not especially practical and would frequently result in a suboptimal user experience. I would strongly urge you to consider adding some features to Vector 2022 to reduce the wasted space, such as allowing individual wikis to turn off the (mostly useless) right rail by default and shrink the width of the left rail (if you take a look at our tables of contents, you will notice that we rarely have long headings, unlike Wikipedia, where the wide left rail was obviously designed for). Again and again I and several others here have been left with the feeling that MediaWiki treats anything other than Wikipedia as a red-headed stepchild, so to speak, and does not bother to take their issues into consideration. This is an opportunity for you to prove us wrong. Thank you for your time. Benwing2 (talk) 04:35, 6 November 2024 (UTC)

Also pinging @OVasileva (WMF) for visibility. Benwing2 (talk) 04:37, 6 November 2024 (UTC)

I personally agree with that this change seems forced and that the narrower viewport is going to cause issues. Inflection tables will likely overflow this area into the right rail. — SURJECTION ^{/ T / C / L /} 07:17, 6 November 2024 (UTC)

Hi @Benwing2 - thank you for your detailed feedback and for flagging your concerns around how space is used in Vector 2022. I wanted to point out that the new width and spacing can actually benefit reading across different Wikimedia projects, including Wiktionary, and not only Wikipedia.

Research shows that sentences or paragraphs with long line lengths, such as those often seen in Wiktionary definitions, are very difficult to read and fail standard accessibility criteria. The Web Accessibility Initiative (WCAG) guideline is about 80 characters per line. The current value on this project is frequently ~262 characters per line, which more than three times the accessible value. For more info on this, check out the project FAQ. White space in general is also not negative from an accessibility and design perspective - it helps to improve readability by giving the eyes a chance to rest, which is a key part of a better overall reading experience.

I also wanted to add that, from the start of the desktop improvements project in 2020, we have been working across different Wikimedia projects, including Wiktionary. One of the wikis in our first pilot wiki group was French Wiktionary, who have used the skin since 2020. This means we were in discussions with them and reviewing their feedback, along with other Wiktionary communities', as we built out the skin from the very early days. In terms of the timeline - like we mentioned in the first message - we’re now in a situation where our infrastructure can no longer support multiple default skins for logged-out users going forward. This means that the transition is necessary for logged-out users (logged-in users can still set their preferred skin whenever they want). We can pause the deployment or make changes for any significant breakages or usability or accessibility concerns, but we do not have any signs of any of these being present on English Wiktionary at this time. Similarly, we have not heard any significant concerns on the other Wiktionary projects, the large majority of which have been using the skin for a couple of years now.

Hope this is helpful and addresses some of your concerns. OVasileva (WMF) (talk) 10:37, 7 November 2024 (UTC)

@OVasileva (WMF), SGrabarczuk (WMF) Honestly, this does not really address my concerns and feels rather like "too bad, you're going to have to take this stuffed down your throat whether you like it or not". In fact, the site just forced everyone to switch to Vector 2022, and go through some effort to get it switched back. There is a lot of unhappiness about this on our Discord server. One of our longtime contributors, @Soap, with eye problems, notes that Vector 2022 is in fact WORSE from an accessibility standpoint:

my guess is that theyre trying to get people off of the legacy skins so they can streamline the UI

i need Vector 2010 for my custom CSS to work, which i need to make the site easy to read for my struggling eyes

if vec2010 is removed i'll pretty much stop contributing although i'll at least make an effort to get the custom CSS to work with vec22

i noticed a few weeks ago that all WMF sites suddenly turned all links blue and underlined on my tablet, and no Prefs setting could override it. but nobody else mentioned that, so it might be a browser issue

basically i need magnified text

but just zooming the browser window magnifies the sidebars too, making the site difficult to use

so i need to do it with CSS

i did try out vec22 a while back and im not 100% against it, but the giant sidebar is a huge problem

I have a hard time believing that 80 characters is really the recommendation; this is incredibly small and wasteful of space. It is probably something specific to mobile phones, not to desktops. 80 characters is bringing us back to the 1980's when monitors were on average 13 inches wide; the normal line width for programming is more like 120 characters, because 80 characters just doesn't allow you to fit enough information, especially for inflection tables (which for complex languages are very hard to fit into 80 characters, and which you haven't addressed at all). The solution for the desktop vs. mobile issue is to make *DIFFERENT* skins and have *DIFFERENT* CSS for desktop and mobile, not to force all desktop users to fit a tiny-screen mobile standard. I'm also rather surprised that, given your claim that you worked with the French and "other Wiktionary communities", you made no effort to reach out to English Wiktionary, which is by far the largest of all Wiktionaries. Your reaching out at the 11th hour feels half-hearted at best. Please do better in the future. I am considering escalating this up the WMF chain, as I'm not happy with the way this has been carried out, nor with the general lack of concern that WMF has shown for English Wiktionary. Benwing2 (talk) 23:04, 26 November 2024 (UTC)

When I've tried to use Vector 2022, drawn in by the prospect of dark mode (I have alternatively considered porting Wikipedia's Dark Mode gadget over to here...), assuming that I'll adapt to the new locations of things if I use it enough, the thing that most immediately made me switch back to Vector 2010 was that at the level of zoom I use, neither the TOC nor the Tools bars were visible, so the TOC and QQ were inaccessible. I see that if I zoom out, they become visible. It is annoying that this site does not just display differently in different skins, it also displays the same skin radically differently depending on your level of zoom and factors like whether you're accessing the mobile version of the site from a computer (where you get the Citations tab/link) or from an actual mobile (on which the Citations tab is absent). (Personally, I also like that in Vector 2010 the TOC is a different background/colour than the entry, whereas in Vector 2022, at least in dark mode, the TOC and the Tools and the entry all have the same unseparated black background. I assume some custom css or even an improvement to the skin itself could make the TOC have a slightly lighter background or clearer border on Vector 2022?) - -sche (discuss) 19:26, 21 October 2024 (UTC)

Using Vector 2022 zoomed out enough to see the TOC and Tools bars, I'm not impressed with the amount of wasted space (although wasted space is an issue on every version/skin of our site); if I hide the "Tools" bar it is better, but then I lose the "QQ" button and have to click on the tools dropdown ever time to get to it. I would like to think this could be fixed by some css or js change to put the "QQ" link into the same top-bar as the "Read - Edit - View History" links, like is done in Vector 2010, but I don't know. - -sche (discuss) 21:30, 21 October 2024 (UTC)

to be fair I think I was catastrophizing up above, assuming that access to the other skins is going to be eliminated entirely rather than just made opt-in. just as importantly, ..... it seems now that zooming in to 125% or greater on Vec2022 removes the sidebar altogether, and the TOC goes into a button in the top left. i think this is a great idea and it resembles something i was trying to do a couple of years ago. personally i prefer the idea of keeping the sidebar width fixed regardless of zoom, which is what my custom CSS is doing, but the major flaw i objected to when i first saw Vec2022 two years ago was that the sidebar would grow at the expense of the main window with increasing zoom level, making the main content smaller and smaller. this seems to have been fixed in the current iteration of Vec2022, which i did not realize when i wrote that text last night. the other issues stand on their own and i dont have a strong opinion on them, but i dont want to be on record complaining about the sidebar width now that that problem has been fixed. best regards, —Soap— 07:58, 27 November 2024 (UTC)

Update from the Foundation: deployment in the week of November 25

A two-minute video about Vector 2022

Hello. We are the Wikimedia Foundation Web team. We are here to announce that the Vector 2022 skin will become the default desktop skin on this wiki by the end of November, most likely in the week of November 25 We will gladly answer your questions, concerns, or additional thoughts! We will also help you adjust things which Vector 2022 may not be compatible with. Check out our FAQ – you will find many useful answers there.

After the change, logged-in users who currently use Vector legacy and have not selected it as their global preference, as well as all logged-out users, will have Vector 2022 as the default. If you are using Vector legacy skin, you may find yourself receiving the Vector 2022 skin. Logged-in users can at any time switch to any other available skins, or stay with Vector 2022 and enjoy choosing between its light and dark mode. Users of other skins will not see any changes.

Logged-in users can at any time switch to any other available skins, including the current version of Vector legacy, Timeless, and Monobook. No changes are expected for users of these skins.

• Top of an article
• 
  Vector legacy (current default)
• 
  Vector 2022

• A section of an article
• 
  Vector legacy (current default)
• 
  Vector 2022

Why are we changing the skin now

For technical reasons (listed below), we need to deploy the skin soon. After deployment, we will continue discussing issues and questions about the skin, and we'll be ready to work with you on various issues like gadget compatibility. We may hold off deployment for a brief time if there are easily noticeable bugs that make reading or editing impossible or very difficult like the infobox pushing content down the page. We will focus on fixing such bugs before changing the skin. This changes will be made on many wikis at the same time.

If you're curious about the details on why we need to deploy the skin in three weeks, here's more information

• Due to releases of new features only available in the Vector 2022 skin, our technical ability to support both skins as the default is coming to an end. Keeping more than one skin as the default across different wikis indefinitely is impossible. This is about the architecture of our skins. As the Foundation or the movement in general, we don't have the capability to develop and maintain software working with different skins as default. This means that the longer we keep multiple skins as the default, the higher the likelihood of bugs, regressions, and other things breaking that we do not have the resources to support or fix.  
• Vector 2022 has been the default on almost all wikis for more than a year. In this time, the skin was proven to provide improvements to readers while also evolving. After we built and deployed on most wikis, we added new features, such as the Appearance menu with the dark mode functionality. We will keep working on this skin, and deployment doesn't mean that existing issues will not be addressed. For example, as part of our work on the Accessibility for Reading project, we built out dark mode, changed the width of the main page back to full (T357706), and solved issues of wide tables overlapping the right-column menus (T330527).
• Vector legacy's code is not compatible with some of the existing, coming, or future software. Keeping this skin as the default would exclude most users from these improvements. Important examples of features not supported by Vector legacy are: the enriched table of contents on talk pages, dark mode, and also temporary account holder experience which, due to legal reasons, we will have to enable. In other words, the only skin supporting features for temporary account holders (like banners informing "hey, you're using a temp account") is Vector 2022.

How to request changes to the skin

We understand that some of you might still have feature requests and reports for the skin that continue prior to and after deployment. We are still actively improving and building new features for the Vector 2022 skin and reviewing all bugs and feature requests that come in. If you have a feature request and bug report, we encourage you to open a ticket in Phabricator. We will prioritize these requests alongside our regular process after deployment.

About the skin

Global preferences

We encourage you to try out the new skin by going to the Appearance tab in your preferences and selecting Vector 2022 from the list of skins. Getting used to it may take a few days, and that's the standard for interface changes.

More about the skin

Vector 2022 is the modernized version of the currently default skin Vector legacy. It is the default on almost all Wikimedia wikis (more than 1000 out of 1030+ wikis). This accounts for approx. 13 billion human page views per month (in total, across all wikis, there are approx. 15 billion per month). Most of the active editors use it and do not opt out of the skin at statistically noticeable rates despite easy access to the opt-out link. (Check the source here.)

[Our 2022 answer to why is a change necessary] When the current default skin was created, it reflected the needs of the readers and editors as these were in 2010. Since then, new users have begun using the Internet and Wikimedia projects in different ways. Although there were changes to features the skin supported, the structure, navigation, visual layout, and overall readability of the skin did not change. The old Vector does not meet the current users' needs.

[Objective] The objective for the Vector 2022 skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It introduces a series of changes that aim to improve problems new and existing readers and editors were having with the old skin. It draws inspiration from previous user requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. We reduced PHP code in the other available skins by 75%. The project has also focused on making it easier to support gadgets and use APIs.

[Changes in a nutshell] The skin introduces changes to the navigation and layout of the site. It adds persistent elements such as a sticky header and table of contents to make frequently-used actions easier to access. It also makes some changes to the overall styling of the page. The analysis of the data collected concluded that these changes improve readability and usability, and save time currently spent in scrolling, searching, and navigating – all of which can be interpreted to create an easier reading experience. The new skin does not remove any functionality currently available on the old Vector skin. On wikis with this skin as the default, there are no negative effects to page views, account creation, or edit rates. On our project pages you will find findings and results in a nutshell.

A summary of findings and results

• On average, 87% of logged-in users on our early adopter wikis (incl. French Wikipedia) continue to use the new skin once they try it.
• The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
• The new table of contents makes it easier to navigate to different sections. Readers and editors jumped to different sections of the page 50% more than with the old table of contents.
• The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis we tested on.
• The skin does not negatively affect page views, edit rates, or account creation. In fact, there is observational evidence of increases in page views and account creation across partner communities.

How can editors change and customize this skin?

• We make it possible to configure and personalize our changes. We are happy to work with volunteers with technical skills who would like to create new gadgets and user scripts. So far, many gadgets and user scripts have been built by community developers. These aspects include making the background gray, turning off sticky elements, bringing back the old table of contents, and more. We encourage you to check out our repository for a list of currently available customizations and changes, or to add your own.
• In Vector 2022, logged-in and logged-out users can change the font size and color scheme based on their individual needs. Dark mode is now available for logged-in users of Vector 2022, and we would like to make it available to logged-out users as soon as most articles are dark-mode friendly.

How will we go through the change

Even though the deployment itself is just one step, we may take more steps before and after deployment together with you to minimize confusion among readers and community members:

• Wiki-page: you may want to create an equivalent of w:Wikipedia:Vector 2022 based a page written by English Wikipedians in collaboration with us. It explains how to opt-out from the skin or customize it, lays out some history, and gives useful links shared in this very announcement.
• CentralNotice banner for logged-in users: before and shortly after deployment, we will display a banner announcing the change. It will link to the above-mentioned wiki-page or this very discussion. This should limit the confusion and the number of newbies' questions about the change.

If you think there are any remaining significant technical issues, let us know – perhaps we've missed something. We're looking forward to your comments and positive reactions from readers after deployment. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 03:40, 6 November 2024 (UTC)

Punjabi Infinitives

Pinging Punjabi group (Notifying AryamanA, Kutchkutch, Svartava, AryamanA, Kutchkutch, Notevenkidding): and @RonnieSingh, عُثمان, OblivionKhorasan, ChromeBones (and others are welcome to comment on this).

Hi everyone, I wanted to have this discussion on Punjabi infinitives, and just understand everyone's thoughts.

Currently there is a difference between Punjabi infinitives with verbs which end in -ā in Gurmukhi and Shahmukhi. From my view, in Pakistani Punjabi (based on Lahori Punjabi), such verbs have the infinitive -āṇā آݨا (āṇā) / ਆਣਾ (āṇā), whereas Indian Punjabi tends to employ the infinitive –āuṇā آؤݨا (ā'oṇā) / ਆਉਣਾ (āuṇā). There is also another infinitive stem which ends in -āvaṇā آوَݨا (āvaṇā) / ਆਵਣਾ (āvaṇā) which is quite common in Pakistani Punjabi. How should this be dealt with?

It's also important to mention that the because of this, Shahmukhi and Gurmukhi conjugation templates currently have differences. نعم البدل (talk) 10:27, 19 October 2024 (UTC)

I would use ਆਉਣ / آوݨ since this form is used in most dialects (it is not always the same form, in Western dialects it can be the direct case form but in Eastern dialects it is oblique case). It is also consistent with the form used in Salahuddin’s dictionary and the PILAC dictionary. عُثمان (talk) 13:42, 19 October 2024 (UTC)

I believe that maintaining the difference in the two scripts is necessary so as to emphasise the pluricentricity of Punjabi. A usage note can be provided to better explain this. Having consistency between scripts erases the actual conventions the different groups follow. I vote to keep the separate templates and to add a suitable usage not on both sides. RonnieSingh (talk) 16:17, 19 October 2024 (UTC)

I should add that if the two scripts use predominantly the same forms, it is generally better to use a single module and have it conditionalize as appropriate. Otherwise you have a lot of duplicated code. This has been discussed before in the context of how to avoid duplication of definitions. Benwing2 (talk) 20:49, 19 October 2024 (UTC)

Wait so how exactly are you supposed to avoid duplication of definitions? —Aryaman^{A (मुझसे बात करें • योगदान)} 01:38, 21 October 2024 (UTC)

See Wiktionary:Beer_parlour/2024/April#Punjabi_vs._"Western_Panjabi". This was the BP thread where this was discussed in detail. Benwing2 (talk) 03:06, 21 October 2024 (UTC)

I second this, yes. Just to conditionalise the same module. RonnieSingh (talk) 16:51, 22 October 2024 (UTC)

Is -āvaṇā آوَݨا / ਆਵਣਾ related to the double causative ending -ਵਾਉਣਾ as at ਬੁਲਵਾਉਣਾ (bulvāuṇā) and comparable to Hindi/Urdu -वाना (-vānā), or are they distinct? Kutchkutch (talk) 12:35, 20 October 2024 (UTC)

No, they are distinct عُثمان (talk) 12:56, 20 October 2024 (UTC)

(Sidenote: here, Western = Jhangli/Shahpuri dialects, Eastern = Majhi/Doabi/Malwai dialects)

The lemmas for Shahmukhi should end in آوݨا (āvṇā). In the case of آؤݨا (ā'oṇā), this is a pronunciation spelling which is technically incorrect, as ā'oṇā implies two separated vowels when they are not, i.e. āuṇā. I consider the u there to just be a dialectal allophone of the v version as this happens in all cases where v follows a long vowel and precedes a consonant. E.g. ساوݨ (sāvṇ) which is pronounced sāvaṇ /saː.ʋə.ɳə̆/ in the more conservative Western dialects and sāuṇ (which I usually transcript as /saːo̯.ɳə̆/ in IPA) in Eastern dialects. Thus, since one is just an allophone of the other I would prefer the original (آوݨا (āvṇā)). آوݨا (āvṇā) is also the standard form used in dictionaries.

Either is fine for Gurmukhi in my opinion; ਆਵਣਾ (āvaṇā) is found in dictionaries and is the original form whereas ਆਉਣਾ (āuṇā) is the Eastern pronunciation spelling and now has come to be the standard written form in India used by dictionaries like Patiala.

I don't think the ਆਣਾ / آݨا (āṇā) ending should be considered as this is a minority pronunciation (I have only heard it in Lahore), rather verbs with these endings can be listed as alternative forms. OblivionKhorasan (talk) 03:34, 26 November 2024 (UTC)

@OblivionKhorasan – I disagree.

• in the more conservative Western dialects – Western dialects on here, only includes Jhangli and Shahpuri, which is a small minority compared to majority. The rest of the Lahnda dialects are considered separate vernaculars on Wiktionary.
• I don't think the ਆਣਾ / آݨا (āṇā) ending should be considered as this is a minority pronunciation (I have only heard it in Lahore) – this is the common ending for the Majhi dialect. Gujrat, Sialkot, Lahore, Sheikhupura, Faisalabad etc. all use this ending. This would make it a issue of national standards (ie. Pakistani Punjabi vs Indian Punjabi).

نعم البدل (talk) 21:25, 26 November 2024 (UTC)

• this is the common ending for the Majhi dialect. Gujrat, Sialkot, Lahore, Sheikhupura, Faisalabad etc. all use this ending.

I have to disagree here as well. I know Gujratis, Sheikhupuris, Lahoris and Sialkotis (last two from my own family) who definitely use -āunā over -ānā, the Gujratis specifically using -āvnā. I do not think that this is an India vs. Pakistan thing at all. Especially since the -ānā form is not listed heavily in Shahmukhi (and by extent Gurmukhi) dictionaries. OblivionKhorasan (talk) 06:47, 27 November 2024 (UTC)

Category: adjectives with the same spelling as their corresponding adverbs (homographs)

I am referring to forms such as cowardly, but I am not knowledgable enough to do it myself. JMGN (talk) 11:27, 19 October 2024 (UTC)

What if only non-standard spellings are used?

What to do if non-standard spellings are there, but no standard spelled form is known in use? I came across this problem while creating entries for dialectal forms for ankle malleolus in Norwegian, and all of them are in standard spelling would be compounds of okle + kule. And this word itself (oklekule) is pretty normal to expect to find in some or another book or, in the worst case, in some random blog. But how surprised I were to find the word oklekule not attested nowhere! Tollef Salemann (talk) 20:13, 19 October 2024 (UTC)

@Tollef Salemann Ideally, pick one of the nonstandard spellings (whichever is most common) as the "canonical" form that hosts the definition, and make the other spellings be alternative forms using {{alt form}} (or {{alt spell}} if the pronunciations are the same, but it looks in this case like they aren't). Alternatively, you can host the same definition(s), if short enough, in more than one place and identify each one as having alternative forms using {{alt}} under an "Alternative forms" heading; but that risks duplication. If the prescribed ("standard") spelling is completely unattested, it probably shouldn't be present as a lemma, but if it's rare but attested, it can be defined as an alt form and given labels like {{lb|nn|prescribed|but|rare}} or similar. Benwing2 (talk) 20:56, 19 October 2024 (UTC)

The most common form is a good idea for simple words. This one is made of two words, both with very obvious standard spelling, which should only be oklekule. Maybe there are any other examples of such words in other languages? Tollef Salemann (talk) 21:23, 19 October 2024 (UTC)

Old English editors seem to have chosen to just use the standard form: if I'm remembering correctly, entries with "ie"-spellings such as ielfen have been created freely here on Wiktionary based on etymological/inter-dialectal correspondences regardless of whether that particular spelling is attested or not (this diphthong was only a distinct sound in early West Saxon).--Urszag (talk) 21:04, 19 October 2024 (UTC)

I agree with that practice for Old English but I think that extinct languages are a special case because we necessarily have gaps in attestation. For living languages that aren't LDL, if a word isn't attested it probably isn't accidental. Benwing2 (talk) 21:09, 19 October 2024 (UTC)

@Tollef Salemann: What about oklekul? Chuck Entz (talk) 22:13, 19 October 2024 (UTC)

The mystery is solved! Tollef Salemann (talk) 08:15, 20 October 2024 (UTC)

Users' Birthdays

Hello,

You are welcome to drop your birthday on User:Flame, not lame/Birthdays. Please do so in chronological order, and do not record others' birthdays without their permission.

Thank you Flame, not lame (Don't talk to me.) 22:56, 19 October 2024 (UTC)

It’s up to users, but to me this seems like an inadvisable idea for data protection and privacy reasons. — Sgconlaw (talk) 23:09, 19 October 2024 (UTC)

That is valid. I will not write about other users without their permission. Flame, not lame (Don't talk to me.) 00:43, 20 October 2024 (UTC)

What, you wouldn't support a user page where Wiktionary editors write their mothers' maiden names? — SURJECTION ^{/ T / C / L /} 10:52, 21 October 2024 (UTC)

Whenever a user submits an edit on Wikimedia, he or she irrevocably agrees to release his or her text under the CC BY-SA 4.0 License and GFDL. Flame, not lame (Don't talk to me.) 11:17, 21 October 2024 (UTC)

Cognates in etymologies for New Indo-Aryan languages

Pinging @Pulimaiyi, @Svartava, @Kutchkutch (and anyone else is free to chime in!). So, we have some NIA entries with massive cognate lists. When the ancestor of these NIA words (usually a Prakrit or Apabhramsa word) has a complete entry with descendants list, I believe the cognate list becomes redundant. I think then we should remove the long list in favour of centralising the information in the Prakrit/Apabhramsa entry. I just did this at Hindi बोलना (bolnā), see the edit history for an example. Is this acceptable for you all? —Aryaman^{A (मुझसे बात करें • योगदान)} 01:37, 21 October 2024 (UTC)

• This has already been discussed a few times. For a related discussion see

Talk:भावजय#Alternative_scripts_in_etymologies

The consensus seems to be that in most cases, if the ancestor has a complete entry with descendants list, then most cognates can be removed from the cognates list.

• Perhaps Early New Indo-Aryan languages should be exempt since it is helpful to have a comparison with other contemporaneous historical chronolects.
• If it is comparatively advantageous to have a small list of cognates to highlight certain important cognates, then that could potentially be allowable.

• Certain important cognates would be geographically nearby languages, cognates within the same subfamily or cognates that share a certain typological feature that most other cognates do not have.

A cognates list on a Marathi entry could be entirely omitted or be limited to show:

Varhadi & Konkani (to compare other Southern Indo-Aryan languages)

Gujarati (to compare the neighbouring state language)

Ahirani (which is transitional between Southern Indo-Aryan and Western Indo-Aryan)

or Hindi/Urdu (to compare with the regional lingua franca).

• Deciding which cognates are comparatively advantageous could possibly lead to some sort of bias.

Kutchkutch (talk) 02:21, 21 October 2024 (UTC)

Agreed, for pages like बोलना (bolnā) where the lists can be very long for NIA terms, we could remove all cognates since a complete list for that would be found on the ancestor page in that case.

I also agree with Kutchkutch that for Early NIA cognate lists could be exempt because that is a very interesting.

The listing of other "interesting" cognates on NIA entries could be on the editor's discretion but in general we could move towards completely avoiding long and regular/expected cognate lists since that would be completely available now in the centralized descendants section of the ancestor page. Svartava (talk) 03:39, 21 October 2024 (UTC)

change in color to nyms, usex, affixusex

@Ioaxxere It looks like you changed the color of usexes, nyms and such without a prior discussion. Lots of people commented in Discord, some liking it, some not. IMO in general these sorts of highly visible changes need discussion beforehand so they don't come as surprises. @AG202 asked me to revert it pending discussion, which seems reasonable to me, so I have gone ahead and done it. This revert is without prejudice to the change itself; it's just to encourage discussion to make sure there's a consensus in favor of this change. Benwing2 (talk) 05:31, 21 October 2024 (UTC)

The change in question was this: [1] Benwing2 (talk) 05:32, 21 October 2024 (UTC)

Thank you. I'd oppose such a change until we have ample discussion from other language communities, especially those that don't use the Latin script. Font color alterations aren't really that preferable for ex: Korean, especially when compared to the blue and red (and yellow/orange) text that often exists on the same line. Also, I'm concerned about accessibility. Let's please make sure to run major changes like this with everyone, as I've mentioned many times before. AG202 (talk) 05:35, 21 October 2024 (UTC)

I personally have no strong feelings. It's a small change and for me, barely perceptible. If it increases readability, why not? Vininn126 (talk) 09:15, 21 October 2024 (UTC)

OK, I copied some of the comments from Discord so far:

• Vininn126 (not Polish) — Today at 1:36 AM does anyone have an example what it looked like?
• User:LunaEatsTuna (*tablet*) — Today at 1:53 AM (posted screenshot)
• Vininn126 (not Polish) — Today at 1:57 AM Thanks
• [1:57 AM] I hardly see a difference
• [1:57 AM] I do, but hardly
• Svartava — Today at 1:59 AM As a user of eye comfort/night light, I also hardly see a difference and can't say which I find better
• User:LunaEatsTuna (*tablet*) — Today at 2:01 AM For me it is easier to ignore as the text is a different color Which I kinda vibe with since, at a glance, I can see and register all of the senses first Makes it less clutter-y for me
• >User:LunaEatsTuna (*tablet*) For me it is easier to ignore as the text is a different color Which I kinda vibe with since, at a glance, I can see and register all of the senses first Makes it less clutter-y for me
• AryamanA — Today at 2:02 AM yeah i liked this as well
• Soap — Today at 2:44 AM i've had usexes in red for about a year now. it makes them stand out
• [2:44 AM] so i like the idea of them being in a different color. maybe if we don't make it default, we can at least pass around an eaasily copied line of CSS code to do it
• hythonia — Today at 3:39 AM perhaps usexes could use the <marquee> tag

Benwing2 (talk) 09:18, 21 October 2024 (UTC)

OK, here is earlier commentary. Note, this (and the above commentary) is all in the #general channel.

• Stujul — Yesterday at 3:46 PM Usexes are grey now? (:open_mouth: emoticon)
• User:LunaEatsTuna (*phone alt*) — Yesterday at 3:50 PM I just saw that myself! (:sob: emoticon)
• [3:50 PM] I thought it was manual.
• >I thought it was manual.
• Stujul — Yesterday at 3:56 PM What do you mean manual?
• >Stujul What do you mean manual?
• User:LunaEatsTuna (*phone alt*) — Yesterday at 3:59 PM That someone specifically made it grey themselves.
• [3:59 PM] With a template or wikitext.
• Stujul — Yesterday at 3:59 PM Ohh
• User:LunaEatsTuna (*phone alt*) — Yesterday at 4:06 PM Honestly I love the grey text
• Stujul — Yesterday at 4:08 PM Yes I like it too
• Soap — Yesterday at 5:20 PM my css overrides it
• [5:21 PM] btw, i kept this quiet because nobody else is complaining, so it might be just me. but i noticed a few days ago that on m y tablet, all links are underlined and blue
• [5:21 PM] redlinks, bluelinks etc ... all appear the same. on both wiktionary and wikipedia
• [5:21 PM] no Prefs setting can override it. its only on the tablet
• [5:21 PM] that t ablet is old so it might be a browser issue
• AryamanA — Yesterday at 7:32 PM am i losing my mind or are usexes light gray now
• >AryamanA am i losing my mind or are usexes light gray now
• Ser be etre shi — Yesterday at 8:01 PM there's been plenty of comments about this change. yes it's a change (:thumbsup: reaction by AryamanA)
• benwing — Yesterday at 11:28 PM Ioaxxere changed it in [2]
• [11:28 PM] honestly i think he should have posted to the BP before doing this
• AryamanA — Yesterday at 11:53 PM i see!
• [11:54 PM] i think it's pretty good actually, just was wondering when it happened
• AG202 — Today at 12:27 AM can we please revert until discussion has been had
• [12:29 AM] that is one of the things that should've been brought up to BP
• [12:32 AM] affecting every language without discussion is exactly something that I've brought up as frustrating before

Benwing2 (talk) 09:50, 21 October 2024 (UTC)

• color is of course good, WT is very black and white. cnrtl uses color well. Anyway, I suggest going even further - using rainbow coloring, or flashing text, or making a ding sound when the cursor hovers over it, or having homonyms fly around the screen on a roflcopter, and hyponyms spiralling in from each corner of the screen to the tune of Bach's Orchestral Suite no. 1 in C major BWV 1066. P. Sovjunk (talk) 09:26, 21 October 2024 (UTC)

As seen in the Discord discussion above, I like the change. It helps differentiate the usexes from the definitions. Though, if it is possible, I would like it to be an optional change, as it may be hard to read for some users.

Stujul (talk) 12:17, 21 October 2024 (UTC)

Yeah this kind of stuff should really be discussed on-wiki rather than just on Discord; the Discordification of the community is an unfortunate development of the past couple of years. Major changes should always require on-site discussion. — Mnemosientje (t · c) 12:29, 21 October 2024 (UTC)

I don't have strong views about the colour change, but agree that this sort of change should be discussed on-wiki. (Updated: sorry, I thought the colour change referred to was the one relating to boxes. I didn't see the colour change in question, so I reserve comment.) — Sgconlaw (talk) 13:47, 21 October 2024 (UTC)

No worries. I'm glad everyone was able to try it out for the couple hours that it was live and form an opinion. We'll have to see whether anyone has strong feelings, although in my opinion it is barely perceptible but serves to emphasize the definitions a little bit more (it's inspired by M-W's site, e.g. [3]). Btw, @AG202, Stujul, with regards to accessibility, the text colour achieves a AAA WCAG rating as seen here so I don't expect that to be an issue. Ioaxxere (talk) 15:55, 21 October 2024 (UTC)

First of all, why wasn't this discussed on Wikt? Second, what about langs that don't have usexs like English (eg Chinese)? Are those accessible? CitationsFreak (talk) 17:15, 21 October 2024 (UTC)

No one should be making any sitewide changes without on-wiki discussion. It's incredibly poor judgement to even think that's a good idea. —Justin (koavf)❤T☮C☺M☯ 18:01, 21 October 2024 (UTC)

@CitationsFreak: Chinese has its own usex system through Module:zh-usex so it isn't affected. Interestingly, they have it so the text is black but the romanization is grey. The shade of grey used there is very hard to read in dark mode, so in that regard it isn't accessible, but that's straightforward to fix. Ioaxxere (talk) 18:26, 21 October 2024 (UTC)

@Benwing2: Thanks for starting this discussion. It doesn't seem like there is any opposition so I am going to restore my changes, but I apologize if my initial edit was too hasty. Ioaxxere (talk) 03:50, 12 November 2024 (UTC)

I'm honestly curious as to why you just did it, without editor consensus. CitationsFreak (talk) 04:22, 12 November 2024 (UTC)

Huh? I explicitly said I oppose this type of change. It looks very off with Korean text for example. Why did you go ahead and do it anyways? Please revert it back. This is something that needs to be officially formalized before you go and make this change to all languages. CC: @Benwing2 AG202 (talk) 15:55, 12 November 2024 (UTC)

Even some of the above users who supported it said that they'd prefer for it to be optional. Why do you insist on going around people with stuff like this? I would honestly suggest that this be brought to a vote at this point. AG202 (talk) 15:57, 12 November 2024 (UTC)

Blotto's game

User:SemperBlotto may be gone but I am negotiating with IFDB to store his zombie game forever [4]. Hint: don't go down the stairs at the beginning. 2A00:23C5:FE1C:3701:74C9:3FA9:762E:473D 18:20, 21 October 2024 (UTC)

Who are you, IP? P. Sovjunk (talk) 18:56, 21 October 2024 (UTC)

It's User:Equinox as the IP claims (and likely is IMO, but obviously it can't be proved without check-user). Svartava (talk) 19:09, 21 October 2024 (UTC)

Hmm, I thought Equinox retired. He should get a new account P. Sovjunk (talk) 19:14, 21 October 2024 (UTC)

The IPs who are actually good editors generally don't want to create account(s), and there is no way he has not thought about that yet... Svartava (talk) 19:41, 21 October 2024 (UTC)

So, how does one win the game? I wore the bikini, but it didn't help. P. Sovjunk (talk) 21:56, 21 October 2024 (UTC)

Isan Romanization

Should Isan be romanized as Lao (to which they are most closely related) or as Thai?. Rodrigo5260 (talk) 19:44, 21 October 2024 (UTC)

'Wikidata item' link is moving, finally.

Hello everyone, I previously wrote on the 27th September to advise that the Wikidata item sitelink will change places in the sidebar menu, moving from the General section into the In Other Projects section. The scheduled rollout date of 04.10.2024 was delayed due to a necessary request for Mobile/MinervaNeue skin. I am happy to inform that the global rollout can now proceed and will occur later today, 22.10.2024 at 15:00 UTC-2. Please let us know if you notice any problems or bugs after this change. There should be no need for null-edits or purging cache for the changes to occur. Kind regards, -Danny Benjafield (WMDE) 11:28, 22 October 2024 (UTC)

Appendix-only entries in categories

In my opinion, appendix-only entries (entries that do not meet the usual WT:CFI) in languages that are themselves not appendix-only should not appear in main categories, yet they currently apparently do. If these entries don't meet WT:CFI and have a spot in the main body of the dictionary, then they also shouldn't appear on category lists that ought to be dedicated to that main body. — SURJECTION ^{/ T / C / L /} 14:52, 22 October 2024 (UTC)

Not really supportive of this. The number of appendix entries in, say Cat:English lemmas is minimal (121 out of 778573, or less than 0.02%), and the vast majority are either snowclone entries, which are hard enough for our readers to discover as it is (so why make it harder?), and Minecraft jargon, which ought to be merged into a single glossary-style page at Appendix:Minecraft rather than being laid out as individual entries (and then they disappear from the categories anyway). This, that and the other (talk) 05:18, 23 October 2024 (UTC)

• Support: We have categories for appendixes; those should be sufficient. — excarnateSojourner (ta·co) 20:25, 12 November 2024 (UTC)

Linking Philippine place names

Followed through from User talk:Mlgc1998#Consensus on PH places:

I have introduced a way to link Philippine place name entires with each other, by utilizing {{meronyms}}, {{coordinate terms}}, and {{hyponyms}} on each definition line. Examples are in Camp One, Marcos, and Atok. This has numerous advantages:

• It is easier to see which is it referring to (not split up into different headings)
• It clearly states hierarchy (purok/sitio < barangay < (district, if applicable) < municipality/city < province) (sometimes, purok < sitio, like Gusaran)
• It can delineate from a general into a specific barangay (eg. Quirino Hill & Bayan Park)
• It fits neatly with other symantic relations like {{synonyms}} (eg. Pongayan)
• It is easy to just collapse them and make them hidden.

However, I was pointed out by @Mlgc1998 that these should go instead to the "See also" portion. Examples on how they arranged it are in Paco, Malate, and Port Area.

While I am open to accepting it, I have some reservations:

• Will it confuse readers that they are split up, especially on different places with the same names?
• What about the most commonly used name Poblacion? Will there just be endless scrolling under "See also"?
• How can it delineate hierarchy, knowing that people outside the Philippines doesn't instinctively know that barangays are meronyms of cities/municipalities, sitios are meronyms of barangays, some puroks are meronyms of sitios while others are meronyms of barangays, etc.?
• What about the name for a group of barangays (like Upper Bauko and Special Geographic Area)?
• How can it delineate from a general into a specific barangay?

Looking forward for input from others. — 🍕 Yivan000 ^view_talk 08:31, 24 October 2024 (UTC)

To streamline the process, I have made {{list:places in the Philippines/en}} which supports both options. It also eliminates the concern of upkeep, since all are editable in the module pages as opposed to each entry page.

For clarification, I am asking on which approach is better: (Camp Four used as an example)

The inline definition approach:

1. A place in bla bla bla

   Meronyms: Balococ, Benmetao, Camp 5, Camp 6, Canubas, Forestry, Gawad Kalinga, Goldstream, Lablab 1, Lablab 2, Liwliw, Manayon, Maramal, National Road — sitios of Camp Four

   Coordinate terms: Ansagan, Camp Four, Camp One, Camp Three, Nangalisan, Poblacion, San Pascual, Tabaan Norte, Tadiangan, Taloy Norte, Taloy Sur, Twin Peaks — barangays of Tuba

The 'See also' approach:

See also

• (sitios of Camp Four):
  • Balococ
  • Benmetao
  • Camp 5
  • Camp 6
  • Canubas
  • Forestry
  • Gawad Kalinga
  • Goldstream
  • Lablab 1
  • Lablab 2
  • Liwliw
  • Manayon
  • Maramal
  • National Road

   
• (barangays of Tuba):
  • Ansagan
  • Camp Four
  • Camp One
  • Camp Three
  • Nangalisan
  • Poblacion
  • San Pascual
  • Tabaan Norte
  • Tadiangan
  • Taloy Norte
  • Taloy Sur
  • Twin Peaks

   

Note also the aforementioned pros and cons from my earlier message. TY.— 🍕 Yivan000 ^view_talk 09:34, 28 October 2024 (UTC)

Towards a Standardization of Inflection Tables

Currently, there seems to be no policy on what inflection tables should look like on Wiktionary (the only thing I found was WT:Templates#Inflection-table templates, which only states they should preferably be collapsible). Looking through Category:Inflection-table_templates_by_language, this causes a great variety in how inflections are presented. This is not necessarily a problem, but some do pose some issues. I would like to propose a few points to improve the reading experience of readers, without inhibiting editors' freedom in choosing a table style too much.

• Inflection tables should not have a fixed width. This is mainly an issue for mobile users. Some templates use a fixed width, which can cause the table to exceed the screen size, making you able to scroll the entire page sideways. See for example {{lv-decl-possessive pronoun}}. Others set the width to be a percentage of the screen size, which often makes the table very narrow on mobile screens (for example: {{huu-decl-noun}}). This can be fixed by using max-width instead of just width.

Side-note: there are also some templates that use width:100%, such as {{da-noun-infl-base}}. I don't personally like it, but I suppose there is no problem with this.

• Inflection tables should comply with accessibility contrast requirements. Some templates use background colors that make the text quite hard to read. For example: {{eo-conj}} (see here). I believe we should strive for WCAG AAA compliance for black text, and WCAG AA for links (since AAA is then impossible). I made a table with the darkest colors one can use as backgrounds in several colors here. One can also use tools such as [5] and [6] to check compliance.
• Inflection tables should be readable in both light and dark mode. Most inflection tables currently have hard-coded colors. This is understandable, as dark mode is quite a recent development for Wiktionary, but it usually makes them very hard to read in dark mode. Editors should use colors from MediaWiki:Gadget-Palette.css (which, in my opinion, could use some more colors) or use a custom style sheet, so that the colors can be varied between the themes. I understand this is already being worked on.

I am hoping these points are uncontroversial, so that they can be made into policy. Please share your thoughts and opinions about this. Stujul (talk) 16:17, 25 October 2024 (UTC)

Proposal 1 feels uncontrovserial, and I support that.

There has been some discussion over the Discord over the inflection table colors. I know that @Theknightwho has expressed supprt in changing the inflection table due to accessibility, while @Thadh is against that due to the cultures that speak the langs having some sort of connection to the specific color of the table. CitationsFreak (talk) 17:21, 25 October 2024 (UTC)

Yes, as CF says, the second change is controversial. Having a defined set of colours to choose from means that the various templates cannot be distinguished as well, which in turn means various languages will be the same. This is a problem. Some people think it isn't, but people actually like to see their language distinguished in some way or another from the mass of tables, and usually this distinction is preferred in the colour of the template, which is then usually shared among related languages. Boo to uniformity! Thadh (talk) 18:11, 25 October 2024 (UTC)

To be clear: I am not pleading for full uniformity. I have not proposed a "defined set of colours to choose from", I only said that the colours chosen should comply with these contrast requirements. And this restriction is not as restrictive as it may seem: in fact, most templates I've seen already comply with these contrast regulations.

I do agree that the variety that we have is a good thing, but accessibility should never be compromised on.

Stujul (talk) 14:37, 26 October 2024 (UTC)

1. is not straightforward. The best solution I can come up with is making the table scroll horizontally instead of the entire page. Forcing the table to be narrow or wrapping words cannot be considered an acceptable solution.

2. and 3. are much easier if all inflection and other language-specific templates used TemplateStyles. Converting templates to use it is relatively straightforward, but tedious and highly repetitive, yet difficult to automate. I've ensured the Finnish, Ingrian and Votic inflection templates (unless I forgot some) use TemplateStyles and support dark mode correctly. The end result is much better than what can be done by sticking strictly to the palette. — SURJECTION ^{/ T / C / L /} 22:12, 25 October 2024 (UTC)

Generally I'm in favor of standardization in this respect. I would like to add that it would be nice to standardize the colors somewhat, because some colors (IMO) look nicer than others. I particularly like the blue theme used for Slavic and certain other languages, and I don't really like tables that use lots of different contrasting colors, rather than using shades of the same color (it looks gaudy and probably isn't accessibility-compliant for people who are colorblind). Benwing2 (talk) 08:12, 26 October 2024 (UTC)

Rather than uniformity, I personally would prefer to see some easily noticeable difference between the declension tables of different languages, which are co-located on the same page. It happened more than once that I landed on a weird looking declension table and looked at it in confusion for a few seconds, before finally realizing that it's just a different language. So I think that having slightly different background colors of at least the Belarusian, Russian and Ukrainian declension tables could help to resolve this at least for me. But I understand that the others are probably in favor of exactly the same uniform blue theme everywhere for the sake of uniformity. --Ssvb (talk) 00:25, 27 October 2024 (UTC)

I'm fine with different languages having different appearance, but CAT:Inflection-table templates by language currently has 397 subcategories (I hope it's just a beginning!), so there will be a point where having all of the languages easily recognizable by appearance will become too hard to achieve. Chuck Entz (talk) 01:19, 27 October 2024 (UTC)

I'm talking about closely related languages with many cognates and identical spelling of lemmas, which tend to share the same wiki pages. Such as the East Slavic languages group. It doesn't matter if any of the other nearly 400 languages outside of that group happen to share the same color, because they almost never clash in practice. For example, have a look at the pages гора or лук. Bulgarian and Macedonian have different styles of the declension tables and the number of cases is different, so any confusion is less unlikely. But Russian and Ukrainian have nearly identically shaped tables. And лось is a purely East Slavic page. Different background colors of the declension tables would help to visually differentiate them. --Ssvb (talk) 14:05, 27 October 2024 (UTC)

This is honestly a good argument for the controversial splitting of pages by language, as it shouldn't be necessary to be able to differentiate languages by how the inflection table looks haha. But let's not open that can of worms.

Stujul (talk) 16:27, 29 October 2024 (UTC)

It may not be straightforward or have an ideal solution, but anything is better than scrolling the entire page. I think it would be good to have a guideline with some "approved" examples of inflection tables with good styling practice so that things like this don't spread from people copying other templates.

Stujul (talk) 16:26, 29 October 2024 (UTC)

I would argue that forcing words to wrap is a worse solution than having the entire page scroll. Both are terrible, but the former is simply worse. — SURJECTION ^{/ T / C / L /} 20:06, 30 October 2024 (UTC)

Fully supportive of all points. To take one example relating to point 2, the Latin noun and adjective declension tables {{la-ndecl}} and {{la-adecl}} are notorious for using, well, questionable colour choices, but to me the bigger problem with them is the terrible contrast in the header cells. Not to mention that the look and feel is totally different to the verb conjugation table {{la-conj}}!

I feel that, even with a standardisation effort, there is definitely still room for individuality in terms of distinctive colour palettes for certain languages and language families, as Thadh mentions.

My suggestion is to come up with two broad "model layouts" for inflection tables: (1) a "narrow" layout for situations where there are few inflections (e.g. German {{de-ndecl}}, Celtic mutation boxes, Tocharian {{txb-decl-noun}}, ...) - this would not have a set width at all (simply adapting to fit its content), would likely use 100% font size, and may be non-collapsible when it only has a handful of rows; and (2) a "wide" layout which occupies the full width of the page on desktop devices (e.g. most Romance verb conjugations) - this may use 90% font size. This, that and the other (talk) 09:13, 26 October 2024 (UTC)

Yes, those tables would benefit from an overhaul. About the different look: it would probably make sense to encourage editors to keep the style the same across tables in the same language. I have seen multiple examples where this isn't the case, which goes against the idea of languages being recognizable through their table style.

The idea of your two layouts sounds good, but I'm not sure I completely follow it. How would these behave on mobile? Also, I'm not sure that changing the font size is a good idea.

Stujul (talk) 16:35, 29 October 2024 (UTC)

Support - I don't have much to add here, as these proposals all seem completely reasonable. Theknightwho (talk) 14:41, 26 October 2024 (UTC)

@Stujul: Thank you for pointing this out. I've already fixed dozens of inflection tables using hard-coded widths, but there are a lot of obscure ones left. When it comes to using NavFrames, there are only two sensible options: not specifying the width, which makes it take up the whole screen width, or setting max-width: 40em (or a similar number) which tries to do the same thing but stops early if it reaches the specified size (there's also the issue of overflow but that's another story).

As for colours: your table is really cool but I don't think we should ever use 100% saturated colours for backgrounds because they are blindingly bright. I would encourage everyone to use the Palette colours, for which you can see the accessibility information here. @Thadh, the goal is not uniformity but convenience, because I can write <span style="color: var(--wikt-palette-blue)">some text</span> and my text ends up blue and accessible everywhere with practically no effort on my part. Anyone is welcome to contribute new colours although ideally we should avoid having tons of almost-identical colours. Ioaxxere (talk) 15:38, 26 October 2024 (UTC)

@Ioaxxere: I think the main problem has never been light/dark mode but whether or not pastel colours should be mandatory. I think doing that would be a grave mistake. But other than that, I'm fine with there being light/dark mode variants of colours, as long as they are still recognisable as the intended colour. Thadh (talk) 15:43, 26 October 2024 (UTC)

Yes, it seems that using max-width together with style="overflow:auto" seems to work the best for most cases. Maybe also "white-space:nowrap" to prevent the wrapping as Surjection mentioned above, but I've not seen that in any template, so maybe there is a good reason to not use it.

Maybe my table is not as useful as I'd hoped it to be then haha. In any case, I like the convenience of the palette as you mention, but I don't really like the palette as it currently is. There seems to not really be any structure to the chosen colors. It could benefit from organizing the palette colors by use-case, as it seems to be on ru:w:MediaWiki:Gadget-common-site.css, on which it is based. In the context of inflection tables, this could mean specifying colors for the header and background.

Stujul (talk) 16:50, 29 October 2024 (UTC)

The palette is simply way too small for it to be used more widely in inflection templates. At the very least we need a graded color system where we have a hue + different levels of brightness, e.g. blue-1 to blue-5 where blue-1 has the least contrast (the lightest in light mode, the darkest in dark mode) and blue-5 has the most (the closest to a pure blue in both). — SURJECTION ^{/ T / C / L /} 20:11, 30 October 2024 (UTC)

@Ioaxxere: See WT:Information desk/2024/October#Request assistance in modifying the styles to accommodate dark mode where @Ryanlo713 has compiled quite a long list of candidates. Chuck Entz (talk) 00:24, 27 October 2024 (UTC)

Support I must support your proposal, as it has consistently been a source of annoyance for me. What are the steps we can take to implement this, and how can we proceed?

Σ>―(〃°ω°〃)♡→L.C.D.（-{に〇〇する}-） 14:52, 30 October 2024 (UTC)

@Stujul, CitationsFreak, Thadh, Surjection, Benwing2, Ssvb, Ioaxxere, Ryanlo713 I've had a red hot go at mocking up a standard design template. Take a look at User:This, that and the other/inflection table standardisation and share your thoughts, in particular, whether you prefer Style A or Style B. Surjection is right that the Wiktionary palette will need to be expanded, but I tried to do the best with what is currently on offer. (I might not have ready access to a computer in the coming week or so, so replies may be delayed.) This, that and the other (talk) 10:42, 31 October 2024 (UTC)

My two cents: we want some kind of cell borders, but their color should be relatively muted. I'm not convinced that text is better centered than not. — SURJECTION ^{/ T / C / L /} 10:47, 31 October 2024 (UTC)

Support Thanks for this. I'm working on extracting conjugation data for offline viewing, and it's a pain to adapt the parser to the various table formats. Having a more standardized format will help. But perhaps this proposal is mostly related to layout/colors, without touching the table structure itself? - Jberkel 11:10, 31 October 2024 (UTC)

I agree that we want cell borders; they strike me particularly necessary (or at least, their absence is particularly confusing) when tables have multiple cells (rows) in one column correspond to one (larger, merged) cell in another column, like this (apologies that I can't off the top of my head think of a local, Wiktionary example that does this in the "contents" as opposed to just the "labels" section of the table, but I think they exist): if the merged cell has multiple words in it, then without cell borders it may be impossible to tell they belong to one multi-row merged cell as opposed to separate cells/rows... - -sche (discuss) 18:00, 31 October 2024 (UTC)

@Ioaxxere, This, that and the other perhaps not appropriate, but relevant: I was trying to make a table with params for grk greek periods with lang params (to apply specials, like colours), number columns num=sg or num=pl genders (with outer and inner borders applied), dat=0 (no dative)... or acc=- or acc=0 to make every cell, every case visible or not, with dashes (for empty), grey expected but not attested, asterisks etc. notes= User:Sarri.greek/template4 (the first empty table Module:User:Sarri.greek/grk-nouns-decl). for forms: Template:User:Sarri.greek/lse. Sorry: I do not know how to write templates or modules. Thank you. ‑‑Sarri.greek ^♫ I 12:22, 31 October 2024 (UTC)

I prefer Style B as it makes it clearer which row and column a certain word belongs to, especially when there are multiple words in a single cell.

Your use of a lighter text color against a darker background is something I had not considered, and I do like the look of it. But it does bring me to another question: some templates use links in the headers to clarify their meaning (for example {{nl-conj-wk}} and {{sv-decl-noun}}). I think this is good practice as many readers will not be familiar with all the grammar terms, but it does make it harder to pick good background colors. How do you think we should handle this?

Stujul (talk) 13:44, 31 October 2024 (UTC)

I think it is okay to link the column and row headers even if they are in a light colour (so the links won't look any different from normal text, but can still be distinguished on hover or touch). It's not like the links are anything exciting - they only go to our glossary entries for "singular", "nominative" etc. If readers don't notice that these are links they're not really missing out on anything.

I tend to share a preference for Style B too. I'll see what I can do about developing an implementation ... but as mentioned, it may have to wait until after the next week-and-a-bit. This, that and the other (talk) 01:07, 1 November 2024 (UTC)

I mainly ask this because the Wikipedia manual of style states: "Refrain from implementing colored links that may impede user ability to distinguish links from regular text, or color links for purely aesthetic reasons." I know we are not Wikipedia, but it makes sense for such rules to also apply on Wiktionary, in my opinion. My worry is mainly that it would create inconsistency and unpredictability between tables, which is exactly what we are trying to avoid.

Stujul (talk) 11:29, 1 November 2024 (UTC)

@This, that and the other: I don't really like the inverted text in your first two tables. But I really like the current look of {{it-conj}}, {{la-conj}}, {{es-conj}}, etc. and I think we should have more of that (although they aren't dark-mode compatible just yet). BTW, I realize that there aren't a ton of Palette colours at the moment so please just let me know which ones you'd like to be added. Ioaxxere (talk) 00:29, 1 November 2024 (UTC)

@Ioaxxere what particularly is your concern with the inverted text? In my view, you're never going to get everyone to agree when it comes to colour, so I figure it's best to provide a wide range of options, including light text on dark backgrounds. Thadh was not in favour of enforcing the use of pastel colours, and I tend to agree with him. Some languages have long-standing colour schemes in place, with significance to national and cultural identities, and I think they would be reluctant to change them without a strong reason. This, that and the other (talk) 01:13, 1 November 2024 (UTC)

@This, that and the other I agree with @Ioaxxere about the inverted text. IMO it looks really amateurish compared with the others, and I'm not familiar with very many (if any) languages that currently use such a scheme. Benwing2 (talk) 01:21, 1 November 2024 (UTC)

Well, if there is opposition to using inverted text, I'm not going to insist on it. I do think that providing more colour options will prevent pushback on aesthetic grounds. This, that and the other (talk) 01:31, 1 November 2024 (UTC)

I would also add that my main motivation in creating the mockup of {{de-ndecl}} with light text on a dark background, was because the existing colour scheme seemed to me to be difficult to read, and I assumed it would not pass accessibility contrast standards. But to my surprise, the existing colour scheme of that template is fully WCAG AAA compliant (except for the blue links "indef." and "def.")! So perhaps there is less of a need for inverted text than I realised. This, that and the other (talk) 01:45, 1 November 2024 (UTC)

@Ioaxxere as far as palettes are concerned, I echo a suggestion made by Surjection earlier to have colour sets consisting of different shades of the same colour. For each available inflection table colour scheme, we need at least (1) a core colour (for header cell backgrounds), (2) a secondary shade (for use in tables like {{de-ndecl}} and {{la-adecl}} where there are two sets of headers) and potentially also (3) a harmonious, much darker shade to use for header text (in the case of light-on-dark, if we indeed want that) and perhaps for header or other cell borders (in the case of dark-on-light). This, that and the other (talk) 02:17, 1 November 2024 (UTC)

I've created User:Surjection/swatch with an initial idea for what the new set of palette colors could look like. — SURJECTION ^{/ T / C / L /} 23:40, 2 November 2024 (UTC)

User:Surjection/swatch2 may be better - it considers luminance/contrast. — SURJECTION ^{/ T / C / L /} 16:56, 4 November 2024 (UTC)

@Surjection thanks for these colours! A great selection. And by not providing any desaturated dark tones, you prevented me from implementing light-on-dark colour themes, which a few others in this discussion will be pleased about 😊

Anyway I have gone ahead and migrated a few tables over to the newly developed {{inflection-table-top}}, including the Celtic mutation templates like {{cy-mut}}, as well as {{la-ndecl}} and {{la-adecl}}. Until now, these templates have been partly or entirely unreadable in dark mode, but are now fully functional. This, that and the other (talk) 09:29, 11 November 2024 (UTC)

While I like the idea of this, I'm really not keen on implementing it via {{inflection-table-top}} and {{inflection-table-bottom}} unless these are implemented as proper module calls, because putting frame:expandTemplate into lots of modules adds a lot of inefficiency that will slow down large pages. Anything like this needs to be done properly, not as a bodge. Theknightwho (talk) 19:59, 11 November 2024 (UTC)

To be honest, I did not understand that you were planning to use this template on existing templates. I thought it was only for your own convenience in creating the mock-up tables. This goes beyond the three points in my proposal; I never wanted to change existing templates' inherent structure. (There would be some I would personally change, but I want that to be at the discretion of the respective language's editing community).

You mention in Wiktionary:Beer_parlour/2024/November#"Note:_Some_of_these_forms_may_be_hypothetical._Not_every_possible_mutated_form_of_every_word_actually_occurs." that you want this template to be easy to use in order for minority languages to be able to easily create new inflection table templates, which is great. But then why does it need to be used on already existing templates? Also, why deploy it in seemingly unfinished status?

Stujul (talk) 14:01, 12 November 2024 (UTC)

• Tentative strong oppose of enforcing any standardization through forcing every template to use things like {{inflection-table-top}} and {{inflection-table-bottom}}. I'm sorry @This, that and the other, but how does forcibly encasing the entire {{la-ndecl}} table around a border (that wasn't there before) and forcibly encasing the declension type text in this box (it was free-standing text previously) accomplish anything other than making the template look worse than before? I don't disagree with the principles of "use colours that render well in dark mode and have good contrast, also don't use fixed width anymore", but forcibly adding borders that weren't there before does not fly with me. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 00:11, 12 November 2024 (UTC)

  @Mellohi! the addition of a second border was an experiment. For context, virtually since the dawn of Wiktionary, most of our collapsible inflection tables have displayed two borders when expanded. Compare {{de-ndecl}} - for many years there was a gap between these two borders until recently, when Ioaxxere (presumably unintentionally?) removed the space between them so the two 1px borders collide and form a single 2px border. The double border can still be seen on {{box-top}}.

  However, when it comes to Latin templates, Urszag has rightfully pointed out some issues with the border at Module talk:la-noun/table. I am going to revert that aspect of the changes to the Latin templates later today, putting the title and footnotes outside the box again. (This is not a quick and easy revert, as it needs to be untangled from other changes).

  Personally I think the new double-border look looks very elegant! Of course I would; I designed it. But perhaps my aesthetic tastes differ from those of others. The double border can easily be removed without affecting the other aspects. This, that and the other (talk) 00:29, 12 November 2024 (UTC)

  @This, that and the other: What edit are you referring to? I don't recall ever having changed that template. Ioaxxere (talk) 02:50, 12 November 2024 (UTC)

  @Ioaxxere I believe you rewrote the NavFrame CSS in the past couple of months? Compare [7] with the current look of Krankenhaus. This, that and the other (talk) 04:28, 12 November 2024 (UTC)

  With regards to the above: it seems that the changes to the Latin templates mean that redlinks appear as black text, rather than red/green (if the accelerated links gadget has been turned on). Is this intentional? If so, I have to say that I am strongly against it. If the text is black, it looks like it isn't a link at all instead of a redlink. Vergencescattered (talk) 23:59, 12 November 2024 (UTC)

  @Vergencescattered no change to link colours was intended. Red links have always appeared black in inflection tables, and should still look green if you have the relevant gadget turned on. Can you identify an entry where this change has been seen? This, that and the other (talk) 11:27, 14 November 2024 (UTC)

  @This, that and the other Achivus would be one example; its the same for every Latin page I've seen. Vergencescattered (talk) 17:37, 14 November 2024 (UTC)

  @Vergencescattered should be fixed now, although it may take some time to percolate through all the entries. This, that and the other (talk) 00:51, 20 November 2024 (UTC)

English usage examples in Translingual entries

At "+" there are several usage examples, of which "3 + 2 = 5" is Translingual, but most of the others are in English. How do we handle this? Even though it's a bit odd, I could understand that Translingual usage examples are in English because this is the English-language wiktionary. Such a policy should be mentioned on the page wiktionary:About Translingual. A second question would be: What about things that are Translingual, but not found in English? Would they get usage examples in other languages? 92.218.236.85 21:15, 26 October 2024 (UTC)

Translingual is not a language, so the usage examples need to be in some language. I agree that it generally makes sense to use English, since this is the English Wiktionary, but there may be occasional reasons to depart from this principle (for example, terms that are not used in English). This, that and the other (talk) 23:35, 26 October 2024 (UTC)

Why are many English surnames labelled as countable and uncountable?

We list several thousand English proper nouns as being both countable and uncountable, most of which are surnames (e.g. Selby). Maybe I'm missing something here, but I really don't follow how that makes any sense. @Donnanz seems to have made this change on a number of entries, but I don't know how widespread the practice is. Could someone please fill me in? Theknightwho (talk) 22:23, 26 October 2024 (UTC)

It only happens with proper nouns that include surnames where someone has added the plural, I don't add those myself. Usually the plural would not apply to place names. DonnanZ (talk) 22:47, 26 October 2024 (UTC)

I have only done this in entries that include both surnames and place names. DonnanZ (talk) 23:39, 26 October 2024 (UTC)

Countable in some senses, uncountable in others is pretty much the default for proper nouns: very few are completely impossible to pluralize, but pluralization also generally necessarily involves a change in meaning, so you could say that some senses are "uncountable". From that perspective, you could question instead why there are any labeled as only countable (or only uncountable). Overall, I would have to say that treating the countable/uncountable distinction as a lexically specific piece of information in such cases doesn't make that much sense. (This came up previously with the RFV for Latin plural forms of Oedipus, which are in fact attested because in Latin, like in English, it's not impossible to add plural endings to a proper noun.)--Urszag (talk) 23:04, 26 October 2024 (UTC)

For example: "There aren't that many people with the surname Entz" (uncountable), vs. "There aren't that many Entzes" (countable). Chuck Entz (talk) 23:22, 26 October 2024 (UTC)

@Chuck Entz Surely by that logic "the word happy" is an uncountable use, which doesn't really make sense to me. Definiteness doesn't make it uncountable.

@Urszag I was always under the impression that "uncountable" was being used to mean "mass noun", but are we taking it to mean "the plural is not used"? I'm not really sure that's grammatical, is it? It's just a semantic quirk that we don't usually talk about more than one of a proper noun, even though we very much can. It's very different to information, where the plural can only refer to different kinds of information, and it's grammatically incorrect to use it in any other way: compare "he gave me a glass of waters" (ungrammatical use of an uncountable noun) to "we visited three Parises" (semantically bizarre, but grammatically correct). Theknightwho (talk) 23:40, 26 October 2024 (UTC)

Good point. I'm not sure whether this really falls under the definition of "uncountable". Also, on second thought, I'm not really sure whether it is ever useful to include the label "countable and uncountable" on a headword line for terms like this (or even for other terms: it seems to immediately raise the question "depending on what?"). I feel like the best thing to do is just mark any uncountable uses (if there are any) with a label on the relevant definition line. That is, I don't think there would be any loss of particularly useful information if "Russia (countable and uncountable, plural Russias)" was just replaced by "Russia (plural Russias)", although I guess you could argue that there's some small value in implying that the plural form might not be commonly used (but that would be better expressed by "usually uncountable" rather than "countable and uncountable", and it's kind of obvious from the definition of such terms that the plural might or might not be used depending on the context).--Urszag (talk) 23:48, 26 October 2024 (UTC)

@Urszag Yes, I'd agree with that, though I'd prefer "chiefly in the singular" or some other label implying the plural isn't usually required, even though it may be grammatically valid. I'm not sure that it's even possible to have a truly uncountable proper noun, as all nouns (countable or not) can be used uncountably in colloquial language:(e.g. "there's a piece of car over there", after a crash), and any uncountable proper noun uses I can think of fall under that usage. The thing that makes a noun uncountable (in a particular sense) is when it cannot be used countably at all, and I can't think of any examples of that. Theknightwho (talk) 00:06, 27 October 2024 (UTC)

Here's an example that has something to confuse everybody: I remember an old documentary on the US Civil War that made the point that the war changed the United States from an "is" to an "are". That is, we now say the United States "is" rather than the United States "are" when talking about the country. It changed the United States from a loose collection of entities that might secede at any time to a unified entity that had to be spoken of in the singular. I'm not really sure if that supports or refutes any of the above, since it's an ad hoc bending of grammatical categories to make a point. It does highlight the pitfalls of taking specific examples too seriously. Chuck Entz (talk) 01:00, 27 October 2024 (UTC)

Many more pages, like Kendall, have never had the plural added. DonnanZ (talk) 11:11, 27 October 2024 (UTC)

As an aside (not worth a topic), I now have to declare whether it's AI-generated or not when uploading an image to Wikimedia Commons. DonnanZ (talk) 09:47, 27 October 2024 (UTC)

FWIW, regarding Wiktionary's conflation of "uncountable" and "the plural is not used": this is an issue I recall Equinox bringing up several years ago, and which I have questioned at various times since then myself (one prior discussion: 2021, when someone seems to have used "uncountable" for lack of any way to display "[is countable but] does not usually pluralize"). I support the general idea of changing things to better distinguish "is (usually) a mass noun, "we have some water"" / "is (usually) a count noun, "we have a plan B if the launch fails" (not normally "we have some plan B if the launch fails", which makes it sound like you have some of the medicine)" from "(usually) pluralizes" / "(usually) doesn't pluralize", in whatever way we can agree on. I like "chiefly in the singular", but maybe we could go even briefer: "Russia (usually singular; plural: Russias)" or something? - -sche (discuss) 05:55, 28 October 2024 (UTC)

It's already done for headwater (chiefly in the plural). I guess they can be tailored according to circumstance, but what about the question "How many Washingtons are there in the US?" The answer would depend on whether people or places were meant. DonnanZ (talk) 15:17, 28 October 2024 (UTC)

• I have always thought that uncountable noun was synonymous with mass noun. One simple test for uncountability is attestable use with much. Much headwater doesn't make it, with our without an -s. Surnames don't meet the test, except in cases like In normal times four terms would have been too much Roosevelt. DCDuring (talk) 18:51, 28 October 2024 (UTC)

  Yes, agreed, and that's the kind of colloquial use which can take any noun (e.g. "too much house, not enough garden"). Theknightwho (talk) 18:58, 28 October 2024 (UTC)

Whitespace edits used to leave comments in history.

In sì, whitespace edits keep being used to leave comments in the history despite a talk page is already being used to discuss the comments.

28 October 2024 Theknightwho talk contribs  4,169 bytes +1  That usage note was already at the bottom, so please don't bullshit. undothank

28 October 2024 Emanuele6 talk contribs m  4,168 bytes −1  This is the lamest edit I have seen; I fixed a thing, you undid the fix. Please do not vandalise the page with whitespace edits since there is a discussion in your talk page. undo Tags: Manual revert Reverted

28 October 2024 Theknightwho talk contribs  4,169 bytes +1  Undo revision 82506619 by Emanuele6 (talk) Not vandalism. undothank Tag: Undo

https://en.wiktionary.org/w/index.php?title=s%C3%AC&diff=prev&oldid=82506654

Is it really acceptable to dirty the wikitext of the page with trailing whitespace just to leave such petty comments in history?

If it is acceptable, I am going to use this technique in the future to fixup mistakes I make in edit messages, in the future.

The wikitext is now left with a trailing space at the end of a line.

o/
 emanuele6 Emanuele6 (talk) 01:55, 28 October 2024 (UTC)

I don’t think this is a good idea as whitespace shouldn’t be randomly added at the ends to lines, etc. Use the talk page for comments. — Sgconlaw (talk) 04:48, 28 October 2024 (UTC)

If it's an undecided matter, my position on this matter is the same. There shouldn't be any trailing whitespace in pages, and you should not just add them and leave them only to leave a comment in the history.

In fact, I tend to clean up all the unnecessary trailing whitespace I notice in pages when I edit them on wikipedia.

---

Not exactly related to this, this is not the case here, but also note that some whitespace changes can actually change how the page is rendered on certain platforms.

I recall this edit I did on wikipedia https://en.wikipedia.org/w/index.php?title=TTNG&diff=prev&oldid=979390957

The newline in <timeline> was invisible on PC, but it was being displayed as a literal "\n" (backslash n) on the android Wikipedia app. Emanuele6 (talk) 05:09, 28 October 2024 (UTC)

Don't do this and don't leave anti-social, hostile edit summaries. —Justin (koavf)❤T☮C☺M☯ 05:07, 28 October 2024 (UTC)

I agree. — Sgconlaw (talk) 05:16, 28 October 2024 (UTC)

@Koavf Given that Benwing2 has pointed out no-one should have been reverting or making those whitespace changes, that also applies to you, so you should not have made any further edits to the page sì. Theknightwho (talk) 12:23, 28 October 2024 (UTC)

I'm not sure why you think that what someone writes seven hours later should apply retroactively, but I disagree and you shouldn't have done what you did, which is the actual point of this thread. Your distractions and irrelevant noise are not appreciated. —Justin (koavf)❤T☮C☺M☯ 18:01, 28 October 2024 (UTC)

@Koavf It doesn't take a genius to work out why it's relevant. Please take your personal grudge elsewhere. Theknightwho (talk) 18:34, 28 October 2024 (UTC)

"Please take your grudge elsewhere" is actually exactly what you should be doing. Please stop with this and listen to others telling you that your prior behavior was inappropriate. —Justin (koavf)❤T☮C☺M☯ 18:35, 28 October 2024 (UTC)

@Koavf Leaving whitespace to add points to edit histories is not something only I have done, not even particularly uncommon, and certainly does not constitute vandalism, as Emanuele6 mentioned. Benwing2 made some good points below about what should and should not have happened for reasons entirely outside of pedantry over whitespace in entries, but unless you can point me to some kind of policy on leaving whitespace in order to make comments in edit histories in particular (or even a guideline or past discussion), I'm not especially interested. Theknightwho (talk) 18:42, 28 October 2024 (UTC)

I don't recall anyone saying that only you have done this, so in case I was somehow mistaken, I will go on record: don't do this to anyone. Anyway, as I have written multiple times, this thread is about your problematic editing and multiple editors have told you to stop it. Since it seems like you understand that you shouldn't have done it in the first place and that you seem like you're saying you won't do it again, sounds good. Have a nice day. —Justin (koavf)❤T☮C☺M☯ 18:58, 28 October 2024 (UTC)

@Koavf Whether or not the comments were appropriate, this thread is not about my behaviour, but about whether we should be able to use whitespace to leave comments in edit histories. Two comments about that doesn't constitute a definitive consensus, I'm afraid. There are clearly situations in which it *is* appropriate, such as correcting a major mistake in an edit summary which would cause confusion. Theknightwho (talk) 19:06, 28 October 2024 (UTC)

The thread was actually begun by someone else and that person began it because of things you did. I've asked you to stop. Please stop. There is no reason for you to keep this distraction going and to keep pinging me. —Justin (koavf)❤T☮C☺M☯ 19:12, 28 October 2024 (UTC)

@Koavf Oh, well you'd better tell Wikipedia that w:Help:Dummy edits are a problem, despite being a widespread practice there. This thread was started with a question of whether they were appropriate, and the only mention of me was in the copied log, so no, this thread was about the question, and not about me. This is precisely why I said you were making this about your grudge, in which you have a long history of making mountains out of molehills whenever my behaviour is in question. Enough. Theknightwho (talk) 19:14, 28 October 2024 (UTC)

I told you to stop pinging me. Stop it. Your completely exhausting behavior is so wildly inappropriate I don't know why you think it's acceptable. Go away and do something else and quit making this a personality-based grudge and then acting like I'm making it a personality-based grudge. —Justin (koavf)❤T☮C☺M☯ 19:16, 28 October 2024 (UTC)

Well, you didn't, but what I'm actually doing here is preventing you from claiming some kind of false consensus against a well-established practice because you want excuses to call my behaviour inappropriate. Unsurprisingly, you've now found some other way to do it as a way to ignore the issue. Theknightwho (talk) 19:21, 28 October 2024 (UTC)

Edit summaries are for summarizing edits, talk pages are for talking about pages. What I initially wrote was not personality-based, but you made it so. Please be better. —Justin (koavf)❤T☮C☺M☯ 19:49, 28 October 2024 (UTC)

w:Help:Dummy edits have plenty of legitimate uses, as that page on Wikipedia helpfully points out. There isn't really anything else that needs to be said. Theknightwho (talk) 19:54, 28 October 2024 (UTC)

• mw:Help:Edit summary
• mw:Help:Talk pages
• This isn't Wikipedia.
• Have a nice day.

—Justin (koavf)❤T☮C☺M☯ 20:06, 28 October 2024 (UTC)

Haha - classic Koavf. I was pointing out those are legitimate uses, not claiming it's some kind of policy. Theknightwho (talk) 20:12, 28 October 2024 (UTC)

Please stop posting attacks against me and continuing this grievance. Have a nice day. —Justin (koavf)❤T☮C☺M☯ 20:49, 28 October 2024 (UTC)

What attack? Are you seriously trying to pretend that you thought linking to the MediaWiki help pages on edit summaries and talkpages was supposed to be a genuinely helpful response? Theknightwho (talk) 21:33, 28 October 2024 (UTC)

Both of you need to knock it off. Further continuing this discussion is going to lead nowhere good. Benwing2 (talk) 21:39, 28 October 2024 (UTC)

From personal experience, these two are as bad as each other. No love lost on the pair of them. DonnanZ (talk) 18:34, 30 October 2024 (UTC)

I looked at the whole edit history involving the two of you. My comments are this:

1. I agree that whitespace changes should not be used to leave comments like this, and in general there should not be trailing whitespace. Use the talk page if there's a disagreement (see point 3).
2. You made a bunch of formatting mistakes, which User:Theknightwho tried to clean up. You should be more careful about this in the future.
3. Both you and User:Theknightwho edit warred to some extent, which is not a good idea. It's much better to use the talk page at the first sign of disagreement.
4. I disagree that sì is a "particle". "Particle" is an extremely nebulous part of speech with no clear meaning, and it's best to avoid it. Portuguese, for example, defines sim as an interjection, which to me makes a lot more sense.

Benwing2 (talk) 08:08, 28 October 2024 (UTC)

> You made a bunch of formatting mistakes, which User:Theknightwho tried to clean up. You should be more careful about this in the future.

I don't think this is true; if you look at what actually change on the page; the only mistake I did is mistakenly using the it-adv head tag instead of head|it|particle. Instead of just fixing that, they undid my edit, moving information back to the wrong location and leaving it there.

---

> I disagree that sì is a "particle". "Particle" is an extremely nebulous part of speech with no clear meaning, and it's best to avoid it. Portuguese, for example, defines sim as an interjection, which to me makes a lot more sense.

The only reason why I chose particle is that both English "yes", and Spanish "sí" have this meaning under Particle. It is definitely not an advert. If it's something else that should also be changed on sí.

yes has both particle and interjection, if you look at the examples for particle, that definitely matches the use described by the "Usage notes" in sì; anyway it is also true that sì can be used as interjection, as well as a particle, so an entry for that could be added in addition.

---

> Both you and User:Theknightwho edit warred to some extent, which is not a good idea. It's much better to use the talk page at the first sign of disagreement.

I don't claim that I have performed the edit on sì cleanly, as I have used the wrong head template, and triggered an abuse warning, but 1) I fixed a thing about that page, and it was reverted; 2) I removed a whitespace added for no reason on that page, that has no right to be there as I always do on any wiki, and it was reverted.

I am discussing those decisions in talk pages.

---

Emanuele6 (talk) 08:33, 28 October 2024 (UTC)

In your edits you made several mistakes:

1. using {{it-adv}} instead of {{head|it|particle}};
2. your first edit left the ===Adverb=== header stranded with no corresponding headword template (hence the abuse filter that you seem to have ignored or misinterpreted; you must have gotten a warning and then saved anyway, because it left a no-head-temp tag indicating the missing headword template);
3. you made things worse by alphabetizing the parts of speech, instead of putting the most common usage first.

User:Theknightwho made three edits after your two edits, trying to correct these various mistakes. You then complained about the Usage note being in the wrong place, but as noted by Theknightwho, that's how it was previously, and the Usage note ending up in the wrong place again appears to have been a side effect of trying to correct the various formatting mistakes you made, not anything intentional. That's what Theknightwho's comment "That usage note was already at the bottom, so please don't bullshit." was trying to say; it definitely could have been phrased in a more polite fashion, though. Following that you accused Theknightwho of vandalism, which was not the case; you probably shouldn't have reverted his change and he definitely should not have reverted your change.

User:Theknightwho can sometimes be abrasive in his comments, which is regrettable, but at the same time IMO you should assume good faith when it comes to experienced editors trying to clean up your mistakes. Benwing2 (talk) 09:03, 28 October 2024 (UTC)

How is adding a random space, and readding it again, and then leaving it there not vandalism though?

I have no problem with them fixing my mistakes. Emanuele6 (talk) 09:09, 28 October 2024 (UTC)

Because it makes no difference to the rendered display, because final whitespace is eliminated from lines before being rendered. That’s simply not what vandalism is. Theknightwho (talk) 12:26, 28 October 2024 (UTC)

> Following that you accused Theknightwho of vandalism, which was not the case; you probably shouldn't have reverted his change and he definitely should not have reverted your change.

Benwing2 I don't understand how to interpret this. I should have left the whitespace because they used it to comment?

"Following that you accused Theknightwho of vandalism"? Maybe you misunderstood that I reverted the change adding of space twice.

I didn't. I reverted it once and then create this discussion after seeing them claiming "not vandalism" readding the space, to learn if it was really acceptable.

It was reverted a second time by another user who commented in this discussion, not me. Emanuele6 (talk) 09:33, 28 October 2024 (UTC)

Request for extended mover

following the advice from @Benwing2 on the Discord server, I wish to request permission for "extended mover" given my editing history. Juwan (talk) 07:49, 28 October 2024 (UTC)

Make Wiktionary:English adjectives an official policy

I suggest making Wiktionary:English adjectives an official policy. It'd forbid adjective senses of present participles and other English words that don't act as true adjectives.

Wiktionary:Votes/2022-01/Excluding trivial present participial adjectives isn't a good proposal, because it'd delete actual adjectives and dealign Wiktionary with other dictionaries. Davi6596 (talk) 13:55, 28 October 2024 (UTC)

WT:English adjectives is flawed, too. exciting, for example, passes most of the tests:

1. Modification by adverbs: very ___, too ___:

   This is so exciting!

2. Comparative and superlative forms: more ___, most ___; ___er, ___est:

   This is the most exciting thing that's ever happened to him.

3. Use after forms of "become":

   This is becoming exciting.

4. Use in attributive position:

   It's such an exciting ride!

5. Use in predicative position:

   This is so exciting!

6. Use with an implied noun:

   THEME PARK's most exciting.

   i.e., THEME PARK's most exciting [rides]. A bit of a stretch, I know, but it works better with other ptcps.

7. Requirement for a predicand:

   Exciting as it may be...

8. Base for formation of adverbs with -ly

   excitingly

Yet it's still technically excluded, because of test 9 and test 10. Test 9 is a little arbitrary, in my opinion: as at Appendix:English gerund-participles#Adjective use of -ing-forms I would say that a participle which meets the test for predicative use is (/has become) a true adjective (ngram of "is exciting"). And as for test 10 the phrasing "distinct meaning [...] that is not borne when it is used as another part of speech" is sort of impossible to fulfill because different parts of speech always bear different meaning. Also, we aren't other dictionaries. -saph668 (user—talk—contribs) 04:52, 17 November 2024 (UTC)

Thanks for your opinion. We can remove tests 9 and 10 if there's enough support for it. Davi6596 (talk) 16:16, 17 November 2024 (UTC)

So, as saph668 mentioned, what do y'all think of removing tests 9 and 10? I agree with it as they're arbitrary or bad. Davi6596 (talk) 12:19, 27 November 2024 (UTC)

Request for review of image policy

this request is regarding the two pages Help:Images and Wiktionary:Images. these policies are very poorly documented and are lacking in content for a prominent aspect for readers of the dictionary. it is unusual for the English Wiktionary which has several guidelines to follow for general entry layout, to lack anything for this. below I have outlined some points that I want to have discussed and added to policy.

• harmonisation: between multiple entries, there should be a layout by which entries should abide. what placement, what size (or lack of size marking), what letter capitalisation, what use of full stops, etc.
• multiple images: mention of the {{multiple image}} template
• senseno: with multiple definitions for a given lemma, it is useful to differentiation images with the given senseno.
• language tagging: as of now, images in different languages are not tagged at all for foreign text. in short, this is terrible for screen reader accessibility, as these would not know how to properly read the given text, see the rationale on Wikipedia.

I am aware that writing policy is hard, but over the coming days I will try to make a draft for others to review and further implement. Juwan (talk) 19:20, 29 October 2024 (UTC)

Sounds good to me. Both of the pages you cite are years and years old. I think the issue is that most Wiktionary pages aren't accompanied by images and (unlike Wikipedia) most editors don't make it a priority to add images, but I completely agree with having standards. Benwing2 (talk) 22:46, 29 October 2024 (UTC)

Choosing just one image to add to a page, like Lincoln, can be hard work... DonnanZ (talk) 10:38, 1 November 2024 (UTC)

I created a subpage at User:JnpoJuwan/Images. still an early draft, but it has what I want to say. Juwan (talk) 20:40, 1 November 2024 (UTC)

@JnpoJuwan: Thanks for looking into this. I don't think the sentence "The lemma word should be in boldface for scripts that have boldface" is necessary, because I don't think this is a necessary practice.

It may be worth pointing out that the caption should make as clear as possible which sense the image relates to. For example, in an entry with more than one sense section, instead of just (sense 1) it may be necessary to state (noun sense 1), and where there is more than one etymology section it may also be necessary to state (etymology 2, verb sense 2). I wonder if we should also mention on the updated help page the use of {{senseid}} and {{senseno}} in captions. It need not be mandatory.

As for "Most captions are not complete sentences, but merely sentence fragments, which should not end with a period or full stop", I guess I am ambivalent. I generally end all captions with a full stop, because it seems troublesome to decide whether a particular caption should be regarded as a sentence fragment or not. However, I guess it would be OK to align our practice with whatever is done over at Wikipedia.

Are you proposing to merge "Help:Images" and "Wiktionary:Images"? If so, what is the new merged page to be called? — Sgconlaw (talk) 12:41, 7 November 2024 (UTC)

@Sgconlaw thank you for your response! this draft is supposed to merge both pages into the Wiktionary namespace, help and tutorials can be just outsourced to Wikipedia and Meta-Wiki.

the sense IDs are important to acknowledge, I needed another pair of eyes to remember what was missing from the draft. however, currently there isn't any good way to indicate using the {{senseno}} template, so we have to deal with writing it outside and having the formatting not be as nice. there has been a BP discussion (pinging @Benwing2 and @Vininn126 to get back to it!)

for the punctuation and bolding, this was mostly taken from the current captions plus how we deal with sentence fragments on Wiktionary already (colloquations vs. uxes). a good rule-of-thumb I have for identifying sentence fragments is seeing whether there is a verb and predicate in the sentence. Juwan (talk) 20:42, 7 November 2024 (UTC)

another way that we can deal with separating meanings is by placing each image in their respective headers (images related to the noun senses under "Noun", same for verbs, same for etymology), see bat and queen for nice examples. Juwan (talk) 20:45, 7 November 2024 (UTC)

@JnpoJuwan: I'm opposed to using images with non-free licenses, because the presence or absence of images is not critical for the Wiktionary's mission. Or at least I would like to have a look at the existing practical examples, where this was deemed appropriate. --Ssvb (talk) 19:37, 7 November 2024 (UTC)

@Ssvb you can see Category:Wiktionary files (and their usages) to see the contexts where these non-free images are used, these are mostly for Internet memes or for images coined in a non-free medium. I don't have strong opinions either way. Juwan (talk) 20:49, 7 November 2024 (UTC)

@Ssvb: I am concerned about this too, but since at the moment only administrators can upload files to this wiki, at least we do not face a situation of editors uploading all sorts of non-free images. If this were allowed, I don't think we have enough volunteers at the moment to assess whether such files are acceptable under non-free content criteria. — Sgconlaw (talk) 21:24, 7 November 2024 (UTC)

@Sgconlaw, @JnpoJuwan: Thanks for the explanations! I think that the guideline could explicitly mention that such images are only to be added in extremely rare exceptional cases at the discretion of the administrators. The way how it is worded right now may be misinterpreted, unless people follow additional links and collect the information scattered across several different pages. Mediawiki supports linking images from external third-party sites in principle when such feature is enabled and, if the guideline is not clear enough, the Wiktionary editors may be tempted to look for loopholes to smuggle non-free images bypassing the administrators. --Ssvb (talk) 22:16, 7 November 2024 (UTC)

Or even worse, if the guideline is not clear enough, then some editors may be tempted to upload non-free images to Commons themselves, assuming that Wiktionary gives them a free pass and encourages such behavior. --Ssvb (talk) 22:29, 7 November 2024 (UTC)

I am opposed to placing images between a headword and senses, as the current wording implies ("after other templates (such as headwords ...)"). I'd much rather have them above or below both of them. — SURJECTION ^{/ T / C / L /} 11:02, 9 November 2024 (UTC)

that makes sense, I'll update that when I get around to it! Juwan (talk) 11:36, 9 November 2024 (UTC)

@JnpoJuwan, Surjection: perhaps the guideline can suggest that the best place for images is at the top of each etymology section. Where the first section in an entry is not an etymology section (for example, it could be a pronunciation section in an entry with multiple etymologies), then it is OK to place the image at the top of that section as well. — Sgconlaw (talk) 11:56, 9 November 2024 (UTC)

@JnpoJuwan The rule I've followed for (right-aligned) Wikipedia boxes is to place them directly after the Etymology header if they apply either to all POS headers or to the first one, and otherwise to place them directly after the relevant POS header. This ensures that they are approximately to the right of the relevant section(s). Something similar might be done with images. Benwing2 (talk) 23:26, 9 November 2024 (UTC)

pining users in this discussion: @Benwing2 @Donnanz @Sgconlaw @Ssvb @Surjection. sorry for the long wait, my computer was needing repair. I updated the policy with some feedback. Juwan (talk) 22:37, 16 November 2024 (UTC)

Do I understand it correctly that captions in English would only be allowed in English entries? I'm not sure that is productive. — SURJECTION ^{/ T / C / L /} 09:02, 17 November 2024 (UTC)

@Surjection I do believe that that's a good thing, unless you are talking about a very specific concept that does not exist in English, why would you need it to be in English? thinking about this, there's two scenarios that come to my head: either you want to add a translation or otherwise add an explanation to the term. Juwan (talk) 13:33, 17 November 2024 (UTC)

@JnpoJuwan: this is the English Wikipedia, where English-speaking users come to find out about non-English languages. Why should image captions be wholly not in English, even if in non-English sections? At most, only the entry word in such a caption should be in the foreign language, for example, “A piece of fromage (cheese) on a plate”, and not “Un morceau de fromage sur une assiette”. — Sgconlaw (talk) 14:08, 17 November 2024 (UTC)

@Sgconlaw @Surjection (responding to this and the comment below): I don't think about outright ban English sentences altogether but suggesting that these should be in the native language. for most entries, this works well: I am have been conceptualising these as another place to add usage examples (unsure where you are allowed to use templates like {{ux}} and {{co}} inside images) or just to add the word + optional sense info (like most non-English captions do, sadly).

the entry at hautajaissaattue is special in the sense that it is a about a specific concept that doesn't have an English entry, the same could happen with cultural-specific topics, items, foods, places, etc. the caption for that entry could very much be as following:

• Presidentti Urho Kekkosen hautajaissaatto ― Funeral cortege of President Urho Kekkonen

this, in my opinion, is also way better than: "A piece of fromage (cheese) on a plate". it sets out a lot: it adds a caption in English for English-speakers, it adds a caption in the given language to contextualise how the given word is used (plurals, case marking) which would be lost with the "fromage"-style examples, avoids language mixing. it adds a good caption. Juwan (talk) 15:21, 17 November 2024 (UTC)

@JnpoJuwan: I have no objection if there is always an English translation of an image caption in a non-English language. — Sgconlaw (talk) 16:02, 17 November 2024 (UTC)

What would it add to ban English-language captions like the one currently used on hautajaissaattue? Or rather, what would it add to require the caption to be in Finnish instead? — SURJECTION ^{/ T / C / L /} 14:09, 17 November 2024 (UTC)

I should also note on the page that audio files are permitted, as used on tweet and toot, and probably other onomatopoeia. Juwan (talk) 18:11, 17 November 2024 (UTC)

removing inactive autopatrollers

The purpose of being an autopatroller is, more than anything else, to reduce the burden on people who patrol Special:RecentChanges by excluding "known good" contributors. In addition, sometimes being an autopatroller gives you the ability to modify an otherwise-protected page, on the theory that autopatrollers generally know what they're doing and can be trusted, at least to some extent, to not mess things up. (Although in practice, I think most pages are either protected at the autoconfirmed level, i.e. below autopatrol protection, or at the template editor or admin level, i.e. above autopatrol protection.) An inactive autopatroller no longer serves the primary purpose of reducing the volume of Special:RecentChanges, and over time autopatrollers are likely to lose the knowledge of how Wiktionary works, both due to simply forgetting over time and due to the gradual evolution of Wiktionary templates, practices and standards. In addition, inactive accounts present a potential security risk, as the account might get compromised by someone whose bad or even malicious changes might then slip under the radar due to the autopatrol status. It's true that an individual inactive autopatroller account presents less of a security risk than an individual inactive admin account, but contrariwise there are a lot more inactive autopatroller accounts than inactive admin accounts.

So I propose that autopatrollers automatically lose autopatrol status after some amount of time. Specifically, I propose:

• Inactive accounts (defined by having no "actions" where an action is any change to the site, such as an edit) lose their autopatroller status after one year (maybe two years).
• Inactive accounts that later become active again may regain their autopatroller status without prejudice as long as some amount of time has not passed (e.g. five years). "Without prejudice" means a request to restore autopatroller status will automatically be granted barring some good reason to the contrary, and in addition any admin may freely restore autopatroller status for such accounts without any consultation (e.g. if the admin is patrolling Special:RecentChanges and sees a previously inactive account become active again). For reference: you (anyone, admin or not) can see what rights a given user has, along with the full history of changes to these rights, by going to Special:UserRights.
• Inactive accounts that have been inactive for sufficiently long (e.g. five years), became active again, and wish to regain autopatroller status will need to go through the normal nomination/approval process for this; see Wiktionary:Whitelist. (FWIW we should IMO consider renaming this, both because its purpose is not obvious from its name and because there is a recent dispreference for the terms "whitelist" and "blacklist". I would suggest something very obvious like Wiktionary:Autopatrol nominations.)

For reference, there are currently 1,063 autopatrollers but only 219 of them have been active within the last 30 days. I'm not sure how to get the list of those active within the last year; if someone knows how to do that, please post the relevant query along with the number of such users.

Benwing2 (talk) 07:38, 30 October 2024 (UTC)

No objection to this. — Sgconlaw (talk) 11:56, 31 October 2024 (UTC)

No objections to any of this as well. However, wouldn’t there need to be a vote to make this a policy? Kutchkutch (talk) 12:14, 31 October 2024 (UTC)

@Kutchkutch Good question. @-sche, @Surjection, @Chuck Entz do you think we need a vote here? I know we had a vote Wiktionary:Votes/pl-2017-03/Desysopping for inactivity for the related removal of administrative privileges, but it seems that recently there's been a trend towards consensus rather than formal votes except for things like giving admin or bot privileges to a specific user. (Obviously more consensus is needed than just two votes in support.) Benwing2 (talk) 05:37, 1 November 2024 (UTC)

IMO I would be inclined to say no, as autopatrol rights are also granted without votes. — SURJECTION ^{/ T / C / L /} 14:02, 1 November 2024 (UTC)

Yeah, if we get a decent number of users weighing in here, I doubt we need a formal vote. - -sche (discuss) 06:17, 2 November 2024 (UTC)

I support the general idea of removing the autopatroller bit from inactive users. I wonder if a longer time (2+ years) might be better, to reduce how often we're having to re-autopatrol users who e.g. mostly edit Wikipedia and only come over here occasionally. Does anyone have experience with a user being made autopatroller, being inactive, coming back, and making problematic edits, that could help us get a sense of how quickly (or often) that happens? - -sche (discuss) 06:17, 2 November 2024 (UTC)

I have no objection to making the inactive period be two years instead of one. If you start going down the list of autopatrollers you can see tons who were granted that status in the early days of Wiktionary and haven't been active since 2009 or so, and who would be removed regardless. As for users who mostly edit e.g. Wikipedia and only occasionally contribute to Wiktionary, does it matter if their autopatrol status is lost? The most relevant case would be someone who contributes in spurts separated by over a year (but less than two years) of total inactivity. I'm not sure that happens very often, but I may be wrong. Benwing2 (talk) 20:09, 2 November 2024 (UTC)

Support (two years), and I would propose the same for other non-admin rights given through WT:WL with inactivity = no use of the given tools for them (like inactivity = no edits in case of autopatrol, no reverts in case of rollback, etc). It can be argued which right is more powerful or so, but for symmetricity and less complicatedness I think the two year standard is good. – Svārtava (tɕ) 14:24, 12 November 2024 (UTC)

Sicilian, stripping the dot from ḍ in page titles

To give context for interested people passing through, Sicilian has a phoneme /ɖɖ/, distinct from /dd/, both having most often been written as dd. Recent standardisation proposals have come up with the orthographic mean ḍḍ to distinguish the former from the latter. Pretty ingenious, but still quite artificial and, although seemingly has grown in popularity especially on the Internet, still far from being the most common way of writing down the phoneme.

This is phenomenon is nothing new, and usually we handle it with the entry_name at Module:languages. I propose we make it so ḍḍ can be used in links, headwords, etc. and keeping dd in page titles. The stripping from links would be automatic, like Latin macrons and Russian accents.

@Hyblaeorum, Nicodene. Catonif (talk) 09:33, 30 October 2024 (UTC)

@Catonif Are we sure we want to do this, as opposed to simply using ḍḍ in pagenames? There are already a lot of page titles using ḍḍ, such as aḍḍumari. All of these would have to be renamed and head= added to all of the headwords. This is similar to our use of ё in Russian headwords even though it isn't usually written in the wild (following dictionary conventions). Benwing2 (talk) 23:14, 30 October 2024 (UTC)

I would guess that most speakers simply use Standard Italian orthography to write the sounds of their particular dialects, with frequent interference from the spelling of Italian cognates.

We could follow this practice in our lemmas, but I don’t see a problem with adopting a standard Sicilian orthography instead, such as that of the Cademia Siciliana. There’d be more coherence to it (one standard form as opposed to a spectrum of ad-hoc choices by speakers of various dialects) and it would presumably be better-equipped to handle sounds or contrasts that are alien to Standard Italian (like the one that inspired this thread). Nicodene (talk) 00:20, 31 October 2024 (UTC)

All these are good reasons why the dot should stay, but why on page titles? It only makes searching harder, and /dd/ is not so common anyway.

As for There are already a lot of page titles using ḍḍ, there are only 45 entries with ḍḍ. On the other hand, there are 99 entries with dd standing for /ɖɖ/, and 7 entries with dd standing for /dd/. Anyways, the number of entries involved is not a big concern. Catonif (talk) 21:09, 1 November 2024 (UTC)

I would rather ask, why do you not want ḍ on page titles? It seems strange to purposely leave out phonemic information. What do typical Sicilian dictionaries do? Benwing2 (talk) 21:16, 1 November 2024 (UTC)

{{R:scn:Pasqualino}}, {{R:scn:Mortillaro}} and {{R:scn:Traina}} are the three main traditional dictionaries for Sicilian. Given they're from the 19th century, they all write it as dd. The masterpiece Vocabolario Siciliano in five volumes (1977–2002) uses ḍḍ (remember, most Italian dictionaries employ ṣ ẓ while we obviously don't) alongside ç for /ç/ instead of c which not even we do (we could, stripping the cedilla as well). All literature, of which there is by no means a shortage, uses dd, or less often, more recently, ddh ddr etc., while some of the only places where ḍḍ is used in running text are the Sicilian version of the UNESCO Courier, disgustingly full of Sicilianised Italianisms, and apparently Reddit.

And anyways, I'm not proposing to remove the dot, leaving out phonemic information, the only place where the dot wouldn't appear is at the top of the page and in the URL. Everywhere else there would still be the dot. Catonif (talk) 21:44, 1 November 2024 (UTC)

FYI the "it makes searching harder" doesn't appear to be the case; typing "addevu" for example automatically brings up aḍḍevu (addevu doesn't exist). Benwing2 (talk) 22:58, 1 November 2024 (UTC)

The focus should be on A. what speakers use now and B. what's standard now. 19th century dictionaries aren't the best reflection for what is still a living language. I wouldn't worry about it making searching harder as Benwing mentioned. And personally, I'm not the biggest fan of stripping things that are considered a part of the "standard orthography" from page titles. Ex: with Yoruba, we stripped tones (before I started editing here), and it's made finding specific entries harder (take a look at: ọkan, but it'd be too much work to change it now. AG202 (talk) 15:51, 12 November 2024 (UTC)

I'm not a Sicilian editor, but this proposal seems reasonable to me. It will eliminate the need to have alternative spelling entries for all of the ḍḍ spellings.--Urszag (talk) 22:48, 1 November 2024 (UTC)

Not sure this saves effort (even if this is a valid argument, which I'm not sure it is); in that case all the words with ḍḍ will need head=, more work is required in the pronunciation module, etc. Benwing2 (talk) 22:56, 1 November 2024 (UTC)

Those things could be more work for us, but from a user's perspective, it's more useful to get directed immediately to the page for the word you're interested in rather than having a soft redirect that you have to click through. I guess you could also avoid having soft redirects if making pages for "dd" spellings was forbidden, like using "æ" spellings in Latin words, but that doesn't seem good to me based on the facts Catonif described.)--Urszag (talk) 23:47, 1 November 2024 (UTC)

Well by that argument we should dispense with ё in Russian headwords, leave out accents on Spanish headwords, etc. And as I pointed out, there isn't necessarily a need for soft redirects anyway because the software automatically directs you to the ḍḍ version if it exists and the dd version doesn't. Benwing2 (talk) 00:05, 2 November 2024 (UTC)

I wouldn't say Russian ё is exactly the best example of how things should be handled in general. Spanish accents are... actually used (or am I misunderstanding that point?). Automatic redirection doesn't happen if the dotless page exists for other languages, e.g. beddu, padda, etc. The strategy of dotting links but not page titles is already in place in some places, e.g. jaddu, puddastra (and other places which were later changed over to a dotted page title). But sure. Catonif (talk) 16:40, 7 November 2024 (UTC)

November 2024

"Note: Some of these forms may be hypothetical. Not every possible mutated form of every word actually occurs."

This label appears in the bottom of some Celtic mutation templates, such as {{ga-mut}}, {{cy-mut}} and {{gd-mut-cons}}:

Mutated forms of Beer parlour

radical	lenition	eclipsis
Beer parlour	Bheer parlour	mBeer parlour

Note: Certain mutated forms of some words can never occur in standard Modern Irish.
All possible mutated forms are displayed for convenience.

Mutated forms of Beer parlour

radical	soft	nasal	aspirate
Beer parlour	Feer parlour	Meer parlour	unchanged

Note: Certain mutated forms of some words can never occur in standard Welsh.
All possible mutated forms are displayed for convenience.

Mutation of Beer parlour

radical	lenition
Beer parlour	Bheer parlour

Note: Certain mutated forms of some words can never occur in standard Scottish Gaelic.
All possible mutated forms are displayed for convenience.

But I've always felt the wording is somewhat ambiguous. (Also, the warning makes the template far wider than it needs to be.)

I assume the intended meaning of this disclaimer is that not all of the mutated forms are necessarily attested, even though, for every listed form, it is possible to construct a valid sentence that uses that form. If this is the intended meaning I don't think the warning label is required at all and it should be removed. We regularly include declension and conjugation tables for rare verbs in German, French, Latin etc. where some inflected forms may be unattested, but we still list them in the declension template with no disclaimer.

I also note that the Breton and Cornish templates don't include this warning:

Mutation of Beer parlour

unmutated	soft	aspirate	hard	mixed
Beer parlour	Veer parlour	unchanged	Peer parlour	Veer parlour

Mutation of Beer parlour

unmutated	soft	aspirate	hard	mixed	mixed after 'th
Beer parlour	Veer parlour	unchanged	Peer parlour	Feer parlour	Veer parlour

Any opinions on removing this message? (Notifying Mahagaja, Mellohi!, Silmethule): This, that and the other (talk) 02:28, 1 November 2024 (UTC)

Yep, agree with this. The warning always felt odd, because it makes it sound like we're including grammatically-invalid forms. Theknightwho (talk) 02:33, 1 November 2024 (UTC)

On a separate point, could we possibly unify the layout of these? I like the Welsh one, but the others just look awful. Theknightwho (talk) 02:42, 1 November 2024 (UTC)

Support removing the note; it is unhelpful. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 02:36, 1 November 2024 (UTC)

I agree with TKW, the warning always read to me as suggesting that some of the forms might be wrong: iff it in fact only means they're not attested (but they're perfectly grammatical), then I agree with removing it; as you say, we don't bother with such notes on the declension tables for German adjectives where perhaps the mixed declension neuter genitive singular is not attested, or is only attested twice and not thrice. (If, on the other hand, some forms are actually avoided by speakers, in the same way that we don't list a plural when one simply doesn't occur, then I think we need a way of suppressing the form and/or providing a clearer note, like "for words starting with xyz, speakers avoid using t-prosthesis and instead use [whatever]".) - -sche (discuss) 02:48, 1 November 2024 (UTC)

They're dictated by what comes before, so all mutable forms are possible in theory; arguably, they're sometimes not even phonemic, but that's a whole separate discussion, and doesn't change the fact that they're an established part of the orthography, so therefore deserve entries. Theknightwho (talk) 02:57, 1 November 2024 (UTC)

Support removing the note and also Support using the Welsh layout for all the languages. Would like to hear from Mahagaja, Mellohi! and Silmethule, each of whom have contributed significantly to various Celtic languages. If there is agreement for this, I can make the changes as I've rewritten some of the headword modules in question (esp. the Welsh one). Benwing2 (talk) 05:30, 1 November 2024 (UTC)

I find unifying the layout for the Celtic mutation templates unnecessary. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 05:44, 1 November 2024 (UTC)

The layout is less of a problem than the colour scheme. The Welsh table matches far more of the recommended accessibility guidelines, and as a result is much easier on the eye. Theknightwho (talk) 05:52, 1 November 2024 (UTC)

@Mellohi! IMO the current styling of the non-Welsh templates looks amateurish, something straight out of early-2000's harcoded HTML tables. Exact unification isn't necessary but I'd like the overall look to be more similar to the Welsh template: get rid of unnecessary cell borders and shadows, etc. Benwing2 (talk) 06:35, 1 November 2024 (UTC)

I included this note because some mutated forms genuinely don't exist. For example, in Irish, adjectives never undergo eclipsis, so a form like gcairdiúil (eclipsis of cairdiúil) can never appear. (The only exceptions are the handful of adjectives that precede their nouns, like príomh-, whose eclipsed form bpríomh- does appear.) Most finite verb forms never take h-prothesis: I can't think of a context in which the form himíonn (h-prothesis of imíonn) would appear. I'm pretty sure only the imperative and the autonomous past indicative are the only verb forms that undergo h-prothesis. In the standard language, only nouns and preposed adjectives like sean undergo the special lenition of s to ts, because it only occurs after the definite article. The {{ga-mut}} template already has |1=msn to restrict t-prothesis to masculine singular nominative nouns (the only context where it occurs), but the {{gd-mut-vowel}} template doesn't, even though t-prothesis in Gaelic is restricted in the same way as it is in Irish. So yes, these templates generate forms that are not grammatically possible, which is why the disclaimer is there. As for its width, I originally put a line break in the text so it would be two lines long and less wide, but someone removed it years ago. {{sga-mutation}} still has the line break. —Mahāgaja · talk 07:28, 1 November 2024 (UTC)

So IMO this sort of disclaimer is kind of a cop-out; instead the templates should be modified to not generate truly impossible forms, and the disclaimer removed. Having this disclaimer there adds no useful information; if a learner of the language doesn't know which forms are impossible and which are possible but rare, they certainly won't learn that (or anything else) from such a disclaimer. But it's important to distinguish between things that are truly impossible and things simply so rare that they are not likely to be found in any corpus. An example is vocatives in Ukrainian, Czech or other Slavic languages that preserve the vocative; it's very rare that someone will use the vocative case when addressing an inanimate object, so for most inanimate objects you won't ever find the vocative in any given corpus, but examples do exist and there's nothing theoretically preventing someone from addressing an inanimate object (esp. in poetry or poetic language). And in general we don't add any disclaimer by Ukrainian or Czech vocatives of inanimate objects stating that they are rare; this is something we assume the reader can figure out. In your example of cairdiúil, is it truly syntactically impossible for it to precede a noun, or merely rare? In the latter case, I would argue we should keep the mutation and remove the disclaimer; in the former case, fix the code to not overgenerate the mutation, and once again remove the disclaimer. Similarly for restricting t-prothesis to the masculine singular nominative forms. Benwing2 (talk) 08:24, 1 November 2024 (UTC)

To the best of my knowledge, it's syntactically impossible (or, in linguistics jargon, ungrammatical) for cairdiúil ever to precede the noun it modifies, but I'm not a native speaker. I also don't think it's possible for it to be substantivized (used like a noun), but again, I'm not a native speaker, and for all I know it's possible in poetry or other exceptional circumstances. Making the templates powerful enough not to generate impossible forms is a great idea in principle, but in practice, going through all existing uses of all templates included in Category:Mutation templates by language and marking them for which mutations are grammatically possible and which are not would be an overwhelming task, and while some of it could possibly be done by bot, I think most of it would have to be done by hand. —Mahāgaja · talk 08:42, 1 November 2024 (UTC)

This should have been done years ago with manual overrides instead of papering over the issue with an unhelpful disclaimer, in my view. Not everything has to be automatable to be implemented. Theknightwho (talk) 13:53, 1 November 2024 (UTC)

Adjectives used to be eclipsed in the genitive plural, e.g. ar bruach innbhir na n-éigne mbán, an example from a text called Aisling na Binne Buirbe from 1679. I don't know when this stopped being the case and whether this usage justifies our templates showing such forms. —Caoimhin ceallach (talk) 19:32, 1 November 2024 (UTC)

That's true; in Old Irish adjectives were also eclipsed after neuter singular nouns. Both types of adjective eclipsis might well be found in place names and possibly fossilized phrases. In my opinion, this is an argument in favor of overgenerating mutated forms. It's probably better to have the template produce forms that are predicted to be nonexistent but might simply be very rare or archaic or nonstandard (since you never know what might be lurking in the darkest corners of a language) than to tailor it to avoid them. —Mahāgaja · talk 20:06, 1 November 2024 (UTC)

Does this also apply to colloquial mutations? I'm particularly thinking of Welsh tsips → jips, but this can theoretically apply to any term starting with ⟨tsi⟩, even though they're rarely written that way as it's not part of the literary language. (t)siec → jec is another common one in speech (or used to be when people still used cheques, anyway). Theknightwho (talk) 00:36, 2 November 2024 (UTC)

I think a case could be made to include ts → j as a colloquial mutation in the table, especially if it's found in writing, but this thread isn't the place for that discussion. —Mahāgaja · talk 07:42, 2 November 2024 (UTC)

@Mahagaja thanks for the insights. I can see I was wrong! It's clear to me that, if nothing else, the message needs to be reworded. Here's my attempt: "Certain mutated forms of some words can never occur in standard Modern Irish. All possible mutated forms are displayed for the convenience of the reader." (broken over two or three lines as needed). This, that and the other (talk) 10:01, 2 November 2024 (UTC)

Well, it would be more honest to say, "All possible mutated forms are displayed because customizing the template to show only the truly extant mutated forms of every single word is beyond our technical capabilities," but your version is more concise. More concise still: "All possible mutated forms are displayed for convenience", without specifying whose convenience. —Mahāgaja · talk 10:44, 2 November 2024 (UTC)

I'm not sure this kind of disclaimer is necessary at all, really. It's up to the reader to determine whether a form can or can't be used in a given situation. Theknightwho (talk) 14:30, 2 November 2024 (UTC)

By the way, in some Munster dialects ná is used instead of nach and it causes h-prothesis. So you could very well have Ná himíonn sé go moch? “Doesn't he leave early?” —Caoimhin ceallach (talk) 10:49, 2 November 2024 (UTC)

True; thanks for the reminder! —Mahāgaja · talk 13:49, 2 November 2024 (UTC)

Is there anything to be said for setting up the templates so they only generate a link if there is a pre-existing entry for that form? I don't mean the current situation where a link appears in black text - I mean literally not creating one unless an entry exists.

I don't really see the utility of including either an entry for ddyddiau or a link to it, as it doesn't really mean anything in itself. It's a different matter for terms that do often exist in mutated form without a "trigger" (like bob as a form of pob) or are homophonous with another term (like bâr being both its own lemma and the soft mutation of pâr, or foch being the soft mutation of both boch and moch).

The status quo also seems to prompt some users to mass-generate mutated forms of a word, but not quite all of them. Which leads to mutated forms, imo needlessly, filling up Jberkel's "wanted terms" lists. Generally I don't like to use editor convenience as a rationale, but in this case I don't see how having lots of mutated forms helps anyone outside the situations I mentioned. Arafsymudwr (talk) 20:44, 2 November 2024 (UTC)

Having entries for mutated forms is very helpful to learners, especially in a language like Welsh where the radical form is often not easy to recover from the mutated form. Someone just learning Welsh may encounter a word beginning with f and not know if the radical starts with b or m, or a word beginning with l or r and not know if the radical starts with ll/rh or gl/gr, or a word beginning with a vowel and not know if the radical starts with that vowel or with g. In Irish and Scottish Gaelic it's a little easier, since the spelling of the mutated form almost always gives a clue to the spelling of the radical. I would not be happy with a template that doesn't show mutated forms unless a Wiktionary entry exists, since most valid mutated forms do not currently have entries. I don't object to removing the disclaimer, though, if most people feel it does more harm than good. —Mahāgaja · talk 13:22, 3 November 2024 (UTC)

I can see it for words beginning with f-, -l, -r or a vowel. Less so for words beginning with dd-, nh- and so on where I find it hard to believe anyone interested in Welsh would not recognise these as mutations with an obvious radical form. But I'm getting the feeling I might be alone in thinking this. Arafsymudwr (talk) 16:30, 3 November 2024 (UTC)

I'd be strongly against only showing the mutated forms that we have entries for. That would just lead to a entries having a hodge-podge of mutations of no use to anyone, because you wouldn't be able to trust if the table was complete or not. The fact that mutations aren't always regular means that there is value in having these, just as there's value in having all the -s plurals in English. Theknightwho (talk) 16:57, 3 November 2024 (UTC)

@Mahagaja: While I agree in general that the templates do generate some forms impossible in the language, a note regarding adjectives: that’s not true. Even if not according to the caighdeán rules, adjectives definitely get eclipsed in more traditional texts (19th century, early 20th century, and even in modern books when more archaizing style is employed, I know people writing like that sometimes) after genitive plurals (things like na bhfocal ndeacair, na mban bhfionn, etc.), you also get old accusatives like leis an bhFear nDubh in some Peadar Ua Laoghaire’s books (20th century!) – and we do consider those to be very much Modern Irish. But it’s true that some finite verbal forms will never get h-prefix (like regular non-autonomous past verbs), though note the mentioned above Munster ná that does prefix h- to other forms in Munster. // Silmeth ^@talk 14:25, 4 November 2024 (UTC)

All the more reason to allow the template to continue to generate all mutated forms, including unexpected/rare/nonstandard ones. But the question at hand is, do we (1) eliminate the disclaimer, (2) rephrase the disclaimer, or (3) keep the disclaimer as is? —Mahāgaja · talk 14:49, 4 November 2024 (UTC)

@This, that and the other These recent changes are a downgrade for the Welsh mutations. Could you please explain why you did this? Theknightwho (talk) 16:21, 11 November 2024 (UTC)

@Theknightwho Here are my motivations and explanations:

• The previous iteration of {{cy-mut}} occupied a fixed percentage of the page's width, which doesn't make sense. People view Wiktionary pages at many different widths, so a lot of users saw vast amounts of blank space around the mutations, while for others it was cluttered. The table now adapts to the width of its content, no smaller or larger. Of course this could have been fixed by simply changing the existing inline CSS of the previous table design, but see the next point.
• There was a desire expressed by a few users to create a standard look for inflection tables. In that discussion, there was general agreement that borders should be used to delineate entries in tables like this. Rather than continuing to maintain various pieces of custom CSS in different locations around the wiki, I felt it would make more sense to work from a single basic template, of which I shared a prototype in the discussion above, WT:Beer parlour/2024/October#Towards a Standardization of Inflection Tables.
• The Celtic mutation templates had wildly different looks despite conveying the same information. Benwing above pointed out that it would make sense to unify the visual appearance - although he did express a preference for the previous design of the Welsh template. But it's impossible to please everyone!

Could you expand on what you mean by "downgrade"? This, that and the other (talk) 22:43, 11 November 2024 (UTC)

What was your reasoning for the choice of appearance for the unified template? IMO it looks worse than before, at least for Welsh, and clashes with the general tendency that tables have been moving towards. Benwing2 (talk) 23:55, 11 November 2024 (UTC)

@This, that and the other Getting rid of fixed width and unifying the appearance are both fine, but at the risk of this being spread across two different threads, my big issue is what @Mellohi! pointed out in Wiktionary:Beer parlour/2024/October#Towards a Standardization of Inflection Tables, which is the intrusive and unnecessary border, as well as what @Benwing2 points out about this clashing with the general appearance templates have been moving towards. I'm also not keen on your approach of using top and bottom templates, when declension templates by their very nature are individual templates that can be wholly encased within another template call, which would give us a lot more control, so I don't really understand why you've taken that approach either. For instance, you've added a provisional |tall=yes parameter, but that's something we should be able to determine automatically. Theknightwho (talk) 00:19, 12 November 2024 (UTC)

@Benwing2 I'm curious about "the general tendency that tables have been moving towards". Could you share some examples? I certainly haven't observed any movement in one direction or another. I do see some pushback regarding the double border, which I can certainly look at suppressing.

@Theknightwho my number one aim is to make this template easy to use, so that those working in minor languages who need to create simple inflection tables can do so without needing to use raw HTML elements like <div> or direct CSS syntax in their wikitext. This is why I made it so that users can use standard wikitable syntax. Of course it does create limitations - the template not knowing how many rows it contains is chief among these. However, if you feed the entire table contents into Lua, you lose the ability to use the standard table syntax without at least some modification (e.g. replacing = with {{=}}). Plus, I don't have the hours to devote to writing such a complex module! This, that and the other (talk) 01:37, 12 November 2024 (UTC)

@This, that and the other If you look at the general tendencies in UI design over the years, there's been a clear trend towards more and more minimalistic design. If you remember or have seen pictures of old Mac OS and Windows UI design, it was filled with borders, shadows etc. to give a more 3-d look. Now everything is flat 2-d and even borders have tended to go away in favor of simple rectangles of different color. (FWIW this mirrors a trend in art from c. 1800-1950, going from the lush Neoclassicism of artists like Ingres to the utter minimalism of Donald Judd. Since then, artistic styles have fragmented, with no single dominant style at least in painting; I wonder if this will eventually happen to UI design as well.) Benwing2 (talk) 04:57, 12 November 2024 (UTC)

@Benwing2 since I started converting the Irish declension templates to the new system just now, I figured I should respond to your points. I thought you were making a specific point about Wiktionary, but I can see your observation was more general - and I definitely see where you're coming from.

I'm not at all wedded to the use of borders in the inflection tables - in fact, one of the great things about standardising inflection tables is that the overall look can be changed in one place. But there are a couple of reasons why borders are in use as of this moment:

1. In the October BP discussion I presented two options: Style A without borders and Style B with borders (User:This, that and the other/inflection table standardisation). No-one said they liked Style A; those who expressed a view all preferred Style B.
2. if you don't have borders, you need lots of negative space between the rows and columns to guide the eye. This means your inflection tables start to get bulky very quickly. The Romance verb conjugation templates like {{la-conj}} try to do this, but to be honest, they don't pull it off very well. I find it quite difficult to follow the rows along, without any borders to guide my eye. Sometimes I find myself counting off the rows to work out which one I'm looking at! (I suppose another alternative solution would be row banding or striping - namely, a slightly darker background colour on every second row - but there doesn't seem to be a lot of precedent for using this technique on Wiktionary.)

And even if borders continue to be used, the borders themselves can be tweaked, for example, made paler, if that would be helpful. This, that and the other (talk) 13:04, 21 November 2024 (UTC)

Proposal: Adopting Inflectional Tables Based on Modern Morphological Views for Japanese

Hello, I would like to inquire whether it would be appropriate for Wiktionary to consider adopting the inflectional tables based on morphological views proposed by Russell, Vovin, and others, particularly with regard to both Middle and Old Japanese.

In Russell's work, "A Reconstruction and Morphophonemic Analysis of Proto-Japonic Verbal Morphology," it is stated:

As for morphophonemic analyses, the traditional (kokugogaku) style of analysis tends to be hindered by Japanese orthography, and is not helpful to the present study. The problem that Japanese orthography introduces is that since one kana equals one syllable, and since morpheme boundaries often occur mid-syllable, it is not possible to indicate where morpheme boundaries are.

As far as I know foreigners learning Japanese generally do not use kokugogaku grammar (while native Japanese people have been being taught). Additionally, there exist works aimed at linguists that introduce the grammar of Japanese (whether modern, middle, or old). However, these works tend to focus primarily on modern linguistic analysis, often addressing kokugogaku analysis only in a supplementary manner.

It is important to clarify that this proposal does not advocate for the complete replacement of existing traditional tables. I believe that the optimal scenario is one of coexistence, where each approach serves its distinct purpose.

Therefore, would you be open to the possibility of incorporating additional table templates?

Thank you for your consideration. Σ>―(〃°ω°〃)♡→L.C.D.（-{に〇〇する}-） 14:48, 2 November 2024 (UTC)

(Notifying Eirikr, TAKASUGI Shinji, Atitarev, Fish bowl, Poketalker, Cnilep, Marlin Setia1, 荒巻モロゾフ, Shen233, Cpt.Guapo, Sartma, Lugria, LittleWhole, Chuterix, Mcph2, Theknightwho): lattermint (talk) 14:59, 2 November 2024 (UTC)

Support; see also: Wiktionary talk:About Japanese#Conjugation table, Wiktionary talk:About Japanese/Conjugation? —Fish bowl (talk) 22:33, 2 November 2024 (UTC)

Rhymes in Welsh

As with most languages, we are able to add rhyme information to the pronunciation in Welsh.

Currently the policy is to follow Northern Welsh rhymes, as Northern Welsh makes more distinctions - with the exception of following Southern Welsh in contrasting /s/ ≠ /z/ and /ŋ/ ≠ /ŋɡ/.

I would like to propose changing this policy so we also follow Southern Welsh wrt vowel length, as in this respect too, Southern Welsh makes more distinctions than Northern.

E.g. there is no 100% reliable way of knowing if a stressed vowel is long before /l/ and /n/ in Southern Welsh (classic examples are celyn /ˈkeːlɪn/ and calon /ˈkalɔn/).

Pinging @Llusiduonbach and @Linguoboy for their thoughts. Arafsymudwr (talk) 20:22, 2 November 2024 (UTC)

I support the suggestion. When I started the Welsh rhymes pages, I ignored the vowel length distinctions of Southern Welsh because I don't have much info beyond the spelling to go on, but if people who are more familiar with Southern Welsh pronunciation want to introduce the distinction, go for it! —Mahāgaja · talk 13:38, 3 November 2024 (UTC)

Thanks. To be honest the functional load of vowel length is very low even in Southern Welsh, so not much is likely to change anyway! How can I set up a vote on this? Arafsymudwr (talk) 16:25, 3 November 2024 (UTC)

@Arafsymudwr IMO you don't need a vote for this. You just need to get consensus among the Welsh-language editors. Benwing2 (talk) 07:35, 4 November 2024 (UTC)

OK, having got support for this, it's quite a big task to do without a bot, and I don't know how to use bots.

For example, basically all the rhymes followed by a voiced consonant in Category:Welsh_rhymes/a- (other than /m/, and sometimes /l, n, r/) or a fricative (other than /ɬ, s/) would need to be shifted to rhymes in Category:Welsh_rhymes/aː-. Any exceptions (tens of them at most, and mostly very transparent loanwords) could be moved case-by-case back to the short vowel category.

Rinse and repeat for other vowels. Arafsymudwr (talk) 21:31, 7 November 2024 (UTC)

@Arafsymudwr Maybe AWB or JWB could help you automate this. Benwing2 (talk) 23:33, 9 November 2024 (UTC)

Seems like a reasonable suggestion to me, but I don't know Southern Welsh length distinctions well enough to contribute. Linguoboy (talk) 16:11, 4 November 2024 (UTC)

Support 0DF (talk) 23:33, 12 November 2024 (UTC)

Presentation of Middle Chinese and Old Chinese readings

At present, the way we present Middle Chinese and Old Chinese transliterations is kind of weird. See, e.g. the etymology at Zen. The "MC"/"OC" being in italics and part of the brackets is confusing - it looks like MC is part of the pronunciation. Do we really need the MC in there at all (can't we get away with just having the "derived from Middle Chinese" label before the character itself?), and if we do can we at least edit Module:ltc-pron and Module:och-pron to make the label clearer?

So instead of:

禪 (MC dzyen)

maybe something like

禪 (MC: dzyen)

I don't know anything about Chinese, so if this is standard formatting for Old Chinese/Middle Chinese transliterations, just ignore this. Smurrayinchester (talk) 17:21, 6 November 2024 (UTC)

Funnily enough I had been thinking about this recently too. The convention in the literature appears to be to write "MC" in roman (not italic) but not to use a colon, like so:

禪#禪 (MC dzyen)

The Chinese workgroup is very large but I will ping it anyway to get further insights: (Notifying Atitarev, Benwing2, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, ND381, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): This, that and the other (talk) 08:49, 10 November 2024 (UTC)

Agreed that the current format is a bit confusing. I think there's a tooltip for "MC" currently, but that's not very easily accessed. We should format it with "MC/OC" not italicized, and the link definitely would help. — justin(r)leung _{{ (t...) | c=› }} 06:18, 11 November 2024 (UTC)

Adding (many) new colors to the palette

In Wiktionary:Beer parlour/2024/October#Towards a Standardization of Inflection Tables, one of the concerns I raised (and some other editors agreed with) is that MediaWiki:Gadget-Palette.css is currently too small to be practically used to support e.g. inflection templates.

I've come up with a possible set of colors to add. This is not a small addition; there would be a total of 160 new colors, which can be grouped into 16 base colors and 10 contrast levels for each color. The most recent version of this can be seen in User:Surjection/swatch2.

These new colors are designed with contrast restrictions in mind. All colors with numbers 0 through 4 meet WCAG contrast requirements at an AAA grade, with a contrast ratio of at least 7.5:1 against the default text color in both light and dark modes. All colors with numbers 0 through 6 meet them at an AA grade, with a contrast ratio of at least 4.5:1.

cc @Ioaxxere as the creator and main maintainer of the palette. — SURJECTION ^{/ T / C / L /} 10:45, 7 November 2024 (UTC)

Thanks for your efforts. Feedback: if I view that page from a mobile device (in dark mode) all of the text is legible; however, when I view that page in either light mode or dark mode (Vector 2010 or Vector 2022) on a computer, the most extreme 1-2 cells are illegible. In the first table (black text on a coloured background), level '9' is illegibly dark (in some colours, such as blue, level '8' is also very hard to read); similarly, in the second table, (coloured text on a white background) level '0' is impossible to read and level '1' is difficult. In the third table (white text on a coloured background), level '9' is hard to read, and in the last table (coloured text on a black background), level '0' is impossible to read (even if I turn my screen's brightness way up), and level '1' is also impossible to read unless I turn my screen's brightness way up. (Level '2' coloured text on either a white or dark background is not very easy to read, either, although I can make it out.) - -sche (discuss) 22:46, 7 November 2024 (UTC)

This is a known issue. Anything past -6 is never really meant to be used as a background color, and anything below maybe -4 or so as a text color (with default text and background colors, respectively, anyway). They are there mostly for completeness' sake. — SURJECTION ^{/ T / C / L /} 13:09, 8 November 2024 (UTC)

Support Thanks for this. I was thinking of doing something similar, but wasn't sure about the best way to execute it, so I'm glad you did it instead. I do have similar concerns as -sche above. I understand only numbers 0-6 are meant to be contrast compliant, but then I do wonder what the use-case would be for the darker colors? I also wonder what this addition would mean for the colors already present in the palette. Would these colors be added alongside the current ones or in place of them?

Stujul (talk) 10:08, 8 November 2024 (UTC)

The darker colors could be used with inverted text colors, for decorative elements that have no text at all or as border colors. — SURJECTION ^{/ T / C / L /} 13:08, 8 November 2024 (UTC)

User:Surjection/swatch3 has lighter colors (on light mode, darker on night mode), since it tries to adhere to the stricter APCA contrast. I chose 75 for -4, as it is the minimum requirement for body text according to APCA-RC Bronze Simple Mode. -0 to -2 has 90 which is 'preferred'. — SURJECTION ^{/ T / C / L /} 12:58, 10 November 2024 (UTC)

 Done See Wiktionary:Palette/numbered. — SURJECTION ^{/ T / C / L /} 15:10, 10 November 2024 (UTC)

Very much support, thanks for helping expand the palette. Ioaxxere (talk) 03:25, 12 November 2024 (UTC)

Dative reflexive verbs

(Notifying Matthias Buchmeier, -sche, Jberkel, Mahagaja, Fay Freak, Fytcha, Helrasincke): Despite this being a feature (whose examples are few in number but greater in frequency) of (as far as my knowledge goes) German and Romanian, our system has never accomodated these verbs with a category and a label. I think it uncontroversial to create Category:Dative reflexive verbs by language as a subcategory of the one for reflexive verbs (unless a language-specific approach will be preferred). Would a ‘dative reflexive’ label be equally as uncontroversial? ―⁠K_(ə)tom (talk) 11:57, 9 November 2024 (UTC)

This is not specific to these two languages. French has it too, as well as Polish, and many other European languages as well I'd wager. It depends on whether the base verb is direct transitive or prepositionally transitive (compare se suivre < suivre quelqu’un vs. se succéder < succéder à quelqu’un). PUC – 12:11, 9 November 2024 (UTC)

Of course it’s not exclusive. I must say, however, that I fail to see how the French example relates to the phenomenon I have in mind. Just to clarify: to take German vorstellen as an example, regular (accusative) reflexive use would literally be ‘to present oneself = to introduce oneself’, whereas the dative reflexive would be ‘to present to oneself = to imagine’. ―⁠K_(ə)tom (talk) 12:55, 9 November 2024 (UTC)

The label category would be useful. The concern of PUC partially applies, as I look at examples of alleged reflexive verbs in dative. sich etwas vorstellen, sich etwas überlegen can hardly be used with another person than the subject as the patient, but sich einen runterholen obviously can and is already labelled as dative reflexive however: Qehath authored it thus comprehensively in 2009 already. The most of the other examples for “reflexive verbs in dative“ in the linked lists and others are presented for didactic rather than lexicographic conclusion, to teach collocations, pragmatics, and fluency, I warn, not being fain to discern merits of separate sense lines in them, for the case that anyone is to step up to gather them, which until this point has been fulfilled accurately in individual cases by virtue of the intuitions of our excellent editors. Fay Freak (talk) 16:43, 9 November 2024 (UTC)

@Ktom: This change would make sense to me.

@Benwing2: Is this something that would be made obsolete by the object template you have in the pipeline? — Fytcha〈 T | L | C 〉 21:00, 20 November 2024 (UTC)

@Fytcha The object template has actually been deployed and is in pretty heavy use, see {{+obj}}. I think they are somewhat orthogonal; you could potentially use {{+obj}} to flag something as having a dative reflexive but it doesn't (currently) categorize. I'd be in favor of adding a category like LANG dative reflexive verbs but we'd have to think of the best way to get such verbs properly categorized; probably the best way is through a label. Many Slavic languages already have labels like reflexive-si for dative reflexive verbs (see e.g. Module:labels/data/lang/cs), which can easily be modified to categorize appropriately. Note also that {{de-verb}} and {{de-conj}} has special support for notating accusative and dative reflexive verbs; you can see an example of the former in the documentation for {{de-verb}} by searching for "accpron" (the example is of sich auf seinen Lorbeeren ausruhen). Benwing2 (talk) 23:07, 20 November 2024 (UTC)

srn-IPA

@Kaartje, Rakso43243, Appolodorus1 Looking for consensus before this gets deployed. Template is at {{Template:User:Saph668/srn-IPA}} right now. -saph668 (user—talk—contribs) 18:30, 9 November 2024 (UTC)

Looks very impressive!

• To generate IPA for pre-1986 ("Dutch") spellings seems a bit redundant to me as we ideally don't have those spellings as lemma forms.
• My knowledge of IPA is rudimentary but the way people pronounce dy/dj also often sounds like ɟ to me.
• How would one generate the geminated consonant in mama, wowoyo etc?--
• Would this be added automatically everywhere with a bot? Because there is a question what to do with elisions in phrases and some univerbations like for instance sanede and no kosi kaiman mama fosi yu abra liba --Appolodorus1 (talk) 00:30, 10 November 2024 (UTC)

1. We already have some existing Dutch entries (at CAT:Sranan Tongo superseded forms) and I'd like to have compatibility for those.
2. I can add that - it's a little hard to find information online about phonetics outside of WT:ASRN.
3. Those are inputted as {{Template:User:Saph668/srn-IPA|m'ma}}, {{Template:User:Saph668/srn-IPA|w'woyo}} which output these:
   • Template:User:Saph668/srn-IPA (though, I just noticed there's an issue adding the stress in the first one there, I'll have to fix that)
   • Template:User:Saph668/srn-IPA
4. I'm not sure how possible deploying automatically is; from the looks of it there are only 64 total multiword terms and univerbations so someone could just go over all of those manually.

-saph668 (user—talk—contribs) 11:59, 10 November 2024 (UTC)

From this PetScan there are 1220 pages excluding multiword terms + univerbations, then filtering that down to exclude ambiguous syllable boundaries there are 1187 pages which it can be added to automatically (i.e. about 92% of all our entries). -saph668 (user—talk—contribs) 13:34, 10 November 2024 (UTC)

Sounds great!

Re: 2 @Lambiam I see that you transcribed dy as dʑ and dʲ in dyugudyugu, what do you think?

Here is an example of how R. Dobru pronounced anbegi https://youtu.be/7h6FMvuK2a0?feature=shared&t=23

@Lingo Bingo Dingo any thoughts? Appolodorus1 (talk) 14:19, 10 November 2024 (UTC)

Even though we list a pronunciation /ɟo.ɡo/ for dyompo, I don’t think I’ve ever heard anything like that, at least not with a [ɟ] like that in the pronunciation of Turkish gece. (One problem with the IPA symbols as used to represent phonemes in different languages is that the actual phones and their relations are not absolute in some phonetic space but language-dependent.)

I often hear a palatalization or lenition of /k/ and /ɡ/ before /e/ and /i/. For /k/ this can range (next to remaining /k/) from /c/ to /t͡ʃ/. For /ɡ/ we may get to hear [ɟ] to, rarely, [j]. As far as I can tell these are always merely allophones; the degree of lenition may depend on the informality of the register. I’m not at all an expert, though, neither of IPA nor of Sranantongo, and my exposure to spoken Sranan has been limited both in the amount of material and in the range of speakers.  --Lambiam 17:54, 10 November 2024 (UTC)

If there aren't any objections I'll go ahead and start deploying it from the PetScan when I wake up tomorrow. -saph668 (user—talk—contribs) 09:59, 17 November 2024 (UTC)

Animacy of Slovak nouns

(@Benwing2 @Atitarev @Chihunglu83) I noticed that Slovak masculine nouns are split into personal, animal and inanimate nouns (with an error appearing if one tries to set the animacy to simply animate)... I would like to discuss this, as there are groups of nouns which don't fit into this system. Animal nouns are just one group of nouns that (not even always) have mixed animacy and there are fully animate nouns that are not personal nouns:

1. pieces of art and scientific works are fully animate (Havran),
2. names of ships, trains, etc. are animate (Lietajúci Škót),
3. names of magazines and newspapers are often partially animate (Korzár),
4. names of hotels, restaurants, etc. named after persons or animals have both animate and inanimate (or mixed) declensions (Jánošík, Jeleň),
5. names of competitions, prices, etc. are partially animate and inanimate (Zlatý Slávik),
6. names of mountains are often animate (Tulák),
7. names of feasts or seasons named after people are partially animate and inanimate (Ján),
8. toys are often fully animate (šarkan),
9. card games, cards, confectionery, plants, etc. are often animate in singular and inanimate in plural (žolík, starček),
10. chessmen are fully animate, etc (pešiak).

These are often named after people or animals, but still, I can't imagine categorising a mountain, a toy or a card game as a personal or animal noun. I would propose returning to the animate/inanimate system, while adding a new mixed animacy category (if there is only one set of forms from which some are animate and some inanimate). We could possibly keep animal nouns as a separate subtype of the mixed category given their frequency. I would like to know your opinion on this. Should anyone like more details or other examples, I can do that. TomášPolonec (talk) 22:06, 10 November 2024 (UTC)

@TomášPolonec Hi Tomáš. Can you clarify what you mean by "fully animate" and "mixed animate"? Is your objection mostly to the terms "animal" and "personal" or to the categories themselves? These names are meant to be paradigmatic in the same way that "masculine", "feminine" and "neuter" are paradigmatic and do not necessarily refer to actual males, females and objects (and for that matter, "animate" and "inanimate" themselves are paradigmatic, and inanimate objects often have animate declension; i.e. this issue would not go away if we had only a two-way animate/inanimate distinction). I would rather not use a separate set of animacy names for Slovak than for all other Slavic languages. Keep in mind that in Czech, which has only a two-way animate/inanimate distinction, a lot of inanimate objects have animate declension (e.g. mushrooms, chess pieces), sometimes only optionally (e.g. certain types of sausages, etc.). Polish also has similar mismatches where inanimate objects have "personal" or "animal" animacy (cf. @Vininn126). Benwing2 (talk) 00:25, 11 November 2024 (UTC)

@TomášPolonec: I second @Benwing2's question. Anatoli T. ^{(обсудить}/^вклад) 05:18, 11 November 2024 (UTC)

To answer your question, when I say (fully) animate/inanimate or mixed, what I mean is that these words have forms that are either exclusively taken from the animate declension patterns (i.e. chlap, hrdina), exclusively taken from the inanimate patterns (i.e. dub, stroj) or mixed, meaning that some cases or numbers use forms from one group, others from the other. Usually it shows in these cases: dative/locative singular (anim. -ovi vs. inan. -u/-e/-i), accusative singular (anim. -a vs. inan. -0), nominative plural (anim. -i/-(ov)ia vs. inan. -y/-e) and accusative plural (anim. -ov vs. inan. -y/-e). I think this is the only thing that matters - if all the forms are animate, the word itself is animate, just as you said, we are not talking about whether the object is "animate" itself. There are cases where all the forms are inanimate, but the accusative singular form is animate, or the singular is animate, but the plural is inanimate (but the word doesn't describe an animal).

Even if we say that these terms are paradigmatic, starček (a plant) is not an animal noun and Havran (a poem) is not a personal noun. So I guess, my objection is towards the terminology used. "Personal" and "animal" are unnecessarily specific and not used in this way in the Slovak linguistics (these categories exist, of course, but not as a part of a three-fold personal/animal/inanimate system, the two-fold system is used always). I don't see how using the two-fold system would create a discrepancy between the Slavic languages, I looked through some entries and Czech, Russian and Slovene also have an animate category. So my objection stands and I don't see why we couldn't use the (for Slovak) usual system. TomášPolonec (talk) 06:08, 11 November 2024 (UTC)

You seem to be confounding two issues: (1) the terminology, (2) the linguistic facts. Fundamentally, from what I can tell, Slovak is not like Czech but is like Ukrainian and Polish in having a three-way animacy system. Some nouns (paradigmatically but not exclusively nouns referring to inanimate objects) have acc = nom in both singular and plural in nouns and corresponding adjectives, while other nouns (paradigmatically but not exclusively nouns referring to people) have acc = gen in both singular and plural in nouns and corresponding adjectives, while a third class (paradigmatically but not exclusively nouns referring to animals) has acc = gen in the singular but acc = nom in the plural in nouns and corresponding adjectives. We cannot use a two-way animacy system to describe this. My comment about creating a discrepancy is about using terms like "mixed animate" and "fully animate" in place of "animal" and "personal". Slovak grammars from what I can tell have a strange way of handling this that involves distinguishing between "animacy in the singular" and "animacy in the plural" but fundamentally from what I can tell, the actual situation is not so different from other Slavic languages with a three-way animacy system. If we were to follow the Slovak grammar system we'd have to have two distinct animacy categories, one for the singular and one for the plural, and if you collapse this down to a single animacy category, you simply cannot properly express the facts related to animal nouns and other nouns that inflect and agree in the same fashion.

As for terminology, I'm not sure why you're prepared to accept the usage of "animate" to refer to inanimate objects but simultaneously object to "animal" and "personal" to refer to inanimate objects. We could rename them "animate-paradigm", "animal-paradigm" and "personal-paradigm", which would emphasize that these are merely paradigmatic, but IMO that wouldn't accomplish anything except to make the terminology more verbose. Benwing2 (talk) 06:40, 11 November 2024 (UTC)

Keep in mind also that Wiktionary tries to adopt a cross-linguistic attitude where possible and emphasize the similarity across languages. Sometimes this involves deviating from native grammar traditions if the native grammar tradition does things in an idiosyncratic way that would obscure the similarities with related languages. Benwing2 (talk) 06:44, 11 November 2024 (UTC)

I see where you are coming from, but it's still not that simple. Also, I think you misunderstood my proposal: I don't want to use terms like mixed/fully animate, that's was just me describing nouns with fully or partially animate paradigmata. I propose using simply animate/inanimate with animal nouns as a separate subcategory of "mixed" animacy as well.

Other cases of mixed animacy are exactly why the three-way system does not solve anything, as there are e.g. nouns that use inanimate forms everywhere except for accusative singular (e.g. categories 3, 4, 5 and 7 from my first post). In Slovak, specific endings are strongly tied to the concept of animacy, but this connection is stronger with the ending -ovi (dative/locative singular), which is used only with animate nouns with very few exceptions, than with the (typically animate) accusative ending -a, which is used with inanimate nouns more often, but still rarely. This is what you cannot express with the three-way system, it's simply about the (in)animate nature of the paradigmatic endings (from what I understand, at least Polish uses -owi with both animate and inanimate nouns).

The plural endings -i/-ovia and -ov for nominative/accusative plural are also connected with the idea of animacy, which is why animal nouns take these forms when they are used to describe people and nowadays the animal paradigms are generally shifting towards animate (some animal nouns have exclusively animate forms in modern usage with inanimate plural forms becoming almost inacceptable). So the "animal" animacy is slowly disappearing anyway.

As for terminology, I feel like the terms "animate"/"inanimate" are mostly tied to linguistics, whereas "personal" and "animal" are commonly used outside of linguistics as well, which creates more specific connotations. I don't know much about Ukrainian or Polish animacy system, but if "personal"/"animal" works for these languages, I can't object to the usage there. What I do know is that it doesn't feel right for Slovak to me. My main arguments are in the paragraphs above. TomášPolonec (talk) 08:06, 11 November 2024 (UTC)

In Polish, masculine animal nouns are nouns of mixed animacy, showing more animate declension (and agreement, which is the more important element in gender) in the singular and inanimate in the plural. Person/animal are also widely used terms in linguistics for this specific concept. Vininn126 (talk) 08:23, 11 November 2024 (UTC)

@TomášPolonec Again I think you are mixing up two different concepts, which in this case are agreement and declension. Let's take the situation with gender e.g. in Latin. Gender (masculine, feminine, neuter) reflects the agreement pattern with adjectives. Some declension patterns are strongly correlated with gender (e.g. most first-declension nouns in -a are feminine and most second-declension nouns in -us are masculine), but there are exceptions in both directions: e.g. agricola (“farmer”) is a first-declension masculine, which is shown by the agreement (bonus agricola NOT #bona agricola), and similarly mālus (“apple tree”) is a second-declension feminine, against shown by agreement (bona mālus NOT #bonus mālus). This means that things like the dative/locative singular ending in -ovi vs. -u/e/i should be ignored for the moment, as they are detracting us from the main issue, which is adjectival agreement patterns. AFAIK, in such agreement patterns there is a clear three-way pattern: (1) acc=nom in sg and pl; (2) acc=gen in sg and pl; (3) acc=gen in sg but acc=nom in pl. Given this, we need to make a three-way distinction in animacy, and making a two-way distinction will just confuse things. Please correct me if I'm wrong about the adjectival agreement facts. Again, the fact that certain noun endings are correlated with animacy is not probative for determining the actual animacy of the noun. The fact that the third class of adjectival agreement may be gradually disappearing is again not relevant, because we reflect the way things are today, and especially in the literary language, which is likely to be more conservative, rather than hypothetically in a future colloquial language. Benwing2 (talk) 08:35, 11 November 2024 (UTC)

BTW the way to reflect something like a difference in animacy in literary vs. colloquial Slovak is through gender qualifiers, which are supported; you could say a given noun is (literary) m animal or (colloquial) m pers. Benwing2 (talk) 08:39, 11 November 2024 (UTC)

I would disagree that adjective agreement is the main criterion for determining animacy in Slovak. Some otherwise purely inanimate masculine nouns use the animate adjective ending and the ending -a in accusative singular, while in all the other cases they have inanimate forms (the already mentioned categories 3, 4, 5 and 7 from my first post). Since it's the only case of masculine adjective endings diferring based on animacy, you would say that it's an animal noun, but the declension doesn't reflects that. The ending -ovi in dative/locative on the other hand is a really strong indicator of animacy, as it's used exclusively by animate nouns and by all of them. If a noun doesn't have it, it's not animate, which means that the abovementioned categories of nouns would count as inanimate with this criterion, which would better convey how the Slovak language uses the phenomenon of animacy.

What I wanted to say with the animal nouns disappearing is that any animal noun also has a full animate paradigm as well for the noun and the agreeing adjectives and not just colloquially. Which would mean long double gender notation with qualifiers for almost every animal noun probably :) TomášPolonec (talk) 09:23, 11 November 2024 (UTC)

w:Grammatical gender "Genders are classes of nouns reflected in the behavior of associated words". It is about agreement. That is not an opinion. Vininn126 (talk) 09:26, 11 November 2024 (UTC)

I agree that's how gender works. But animacy is not really about gender in this case. And since there is only one case where the agreement can be distinguished and some nouns have an exceptional ending right there, which is associated with animacy and therefore uses the corresponding animate adjective ending, there must be another criterion. TomášPolonec (talk) 09:36, 11 November 2024 (UTC)

Animacy is part of gender. Vininn126 (talk) 09:40, 11 November 2024 (UTC)

I have to agree with @Vininn126 here. BTW @TomášPolonec the situation with "any animal noun also has a full animate paradigm as well for the noun and the agreeing adjectives and not just colloquially" is in fact exactly what we now see in Ukrainian. You will find for example that this is explicitly shown in the declension tables of Ukrainian animal nouns such as миш (myš, “mouse”); see [8]. This means there is no need to double-indicate the gender; it simply is indicated as m-anml, and implicit in this is that declension and adjective agreement in the accusative plural can go with either nom or gen pl, just like in Ukrainian. Benwing2 (talk) 09:51, 11 November 2024 (UTC)

Hmmm, миш (myš) is feminine so maybe not the best example. See also вуж (vuž, “grass snake, water snake”) and its declension here: [9]. Benwing2 (talk) 09:53, 11 November 2024 (UTC)

Thanks for the information about Ukrainian. In Slovak, you have two sets of plural forms - one for the inanimate plural, one for the animate plural. So for the nom-acc agreement, you would have a different nominative than the one you would use for the animate version. E.g. orol: inanimate plural is orly for both nom and acc, animate plural is orli in nom and orlov in acc. Which gives you two separate plural declensions that are not interchangable or combinable (you can't use the animate orli nominative to create the inanimate accusative). So if you say that starček (a plant) is an animal noun as well, there would indeed have to be an extra qualifier for each animal noun that describes a real animal, because what I described happens only with these, starček doesn't have an animate plural in this sense. I still think it's simpler to just say that starček is inanimate with an exceptional animate accusative form and animal nouns are those that behave the same way as orol. TomášPolonec (talk) 10:41, 11 November 2024 (UTC)

Sure, I agree, but I still think this is oversimplifying the situation in Slovak. If an inanimate noun keeps the -a ending in accusative from the original animate form, the adjective automatically takes the corresponding animate form as well. This is basically the case with these anomalies that I listed above. Unfortunately, there is no difference between animate and inanimate adjectives in dative or locative, so there is no difference that would confirm for you that a noun is (in)animate based on these cases.

If you just want to put a category on every noun based on some universal criteria, that's fine, but for this specific language, it doesn't really reflect how animacy is perceived and used by native speakers. I think, our ultimate goal should be to give users useful information while reflecting the particularities of each language. I believe there should be as few discrepancies between Wiktionary and other dictionaries and grammar/morphology guides as possible, even if we want to keep things as consistent as possible. TomášPolonec (talk) 10:28, 11 November 2024 (UTC)

If it's causing adjectives to take animate declension, then it's not inanimate. Vininn126 (talk) 10:45, 11 November 2024 (UTC)

If the ending stays animate in accusative, the adjective stays also animate, even though every other ending is changed to inanimate. As I've said, the animacy connected with the ending -a is not so strongly perceived as with the ending -ovi, which goes first when the noun is losing its animacy with the change in meaning (things named after someone/something, etc.). Out of 12 forms, 11 are the same as for the normal inanimate nouns. You still haven't convinced me that Ján ("John", meaning the feast of St. John) would be an animal noun, just because it keeps the animate accusative :) At least call it nonpersonal or something like that, that's also the official term used in Slovak. TomášPolonec (talk) 11:08, 11 November 2024 (UTC)

Ongoing wrong audio from Flame, not lame

Bit concerned about this user adding hundreds of audios which seem to be guesswork half the time, or based on highly unreliable auto-generated "how to pronounce" spam sites. See prior discussion at Talk:igasurine. She's still guessing, I think: since then, I've seen hydrogeniferous pronounced like it has "Jennifer" in it (I think these words are always stressed IFerous); and I am doubtful about aminimide (compare imide's IPA). Such additions could do significant damage to the project over time. 2A00:23C5:FE1C:3701:49E0:B9B8:114:7472 12:33, 11 November 2024 (UTC)

@Flame, not lame: courtesy ping. —Justin (koavf)❤T☮C☺M☯ 12:36, 11 November 2024 (UTC)

yes? Flame, not lame (Don't talk to me.) 12:39, 11 November 2024 (UTC)

Just letting you know that others are talking about you. No one else alerted you to this, so I figured it would be appropriate to let you know. —Justin (koavf)❤T☮C☺M☯ 12:47, 11 November 2024 (UTC)

If a native English speaker is given a text to read aloud and the text in question contains some obscure unfamiliar words, then how does this work in practice? Do people never utter anything that isn't a part of their active vocabulary? As for how to deal with that in Wiktionary, would labeling suspicious audio samples as "nonstandard" be a useful solution? The patrollers, who are native English speakers, could keep an eye (or an ear) on the correctness of the audio samples too.

There's a long backlog of words to be recorded, and it won't go away unless more people start contributing more actively: https://lingualibre.org/wiki/List:Eng/Lemmas-without-audio-sorted-by-number-of-wiktionaries --Ssvb (talk) 19:26, 11 November 2024 (UTC)

1. • That backlog, by default, will never go away! Whalespotcha (talk) 23:53, 11 November 2024 (UTC)

People often make their best guess if they're reading an unfamiliar word aloud. In many contexts, that's fine, but a "best guess" pronunciation is not good enough for a dictionary. I agree with 2A00[...] that we should discourage adding audio without doing a reasonable amount of work to check that it is correct. There is no urgency to the task of adding audio for obscure words, so opting for speed over accuracy has minimal upside.--Urszag (talk) 20:34, 11 November 2024 (UTC)

I will certainly record audio for familiar terms on the Lingua Libre list. when I am unsure how to pronounce a certain word, first I search for IPA or another recording. AI voices are less efficient. I was focusing heavily on chemistry vocabulary because a considerable quantity of these terms did not have pronunciations examples, and I will slow down as needed. Flame, not lame (Don't talk to me.) 22:24, 11 November 2024 (UTC)

This is exactly the same issue as former (usually neurodivergent) users who have added "translations" by putting individual words into Google Translate, and it's just as pernicious. If the user's goal is to "create lots of entries" and they don't care about whether they are correct or not, this is what happens. It must be stopped at source. I love Flame's honey-smooth voice as much as the rest of you, but any single wrong or guessed audio is serious damage that will multiply (because once it's on "the wiki" it's borrowing our reputation, which those spammy faked machine voices didn't have: this also, for now, has an impact on SEO). Why is this not obvious? 2A00:23C5:FE1C:3701:95E9:81C2:6E59:5EE1 23:23, 11 November 2024 (UTC)

Adding "usually neurodivergent" was totally unnecessary, really. Theknightwho (talk) 23:31, 11 November 2024 (UTC)

Agreed. It is inappropriate to assume neurodivergence.

Either way, I am going to focus on words within my familiarity, and I am using Oxford Languages' human audios as resources. Flame, not lame (Don't talk to me.) 23:32, 11 November 2024 (UTC)

You may ignore the lack of tact of the IP address. But whether I added it or not (and whether it's true or not, which I think we could prove with statistics, but not today), the entries are correct or incorrect. I assume Wiktionary believes there is a difference between correct and incorrect (can we still say that?), in which case you should lean toward the former, and weed out the latter. 2A00:23C5:FE1C:3701:95E9:81C2:6E59:5EE1 23:38, 11 November 2024 (UTC)

I wasn't disputing the underlying point. Theknightwho (talk) 11:38, 12 November 2024 (UTC)

And this is precisely why, folks, intersectionality matters. No wonder the "IP," a known transphobe, is also bigoted against neurodivergent people. 2600:6C5D:6040:67:3D7:FBD8:BA17:E5E4 01:15, 13 November 2024 (UTC)

• The IP address should get a usernameWhalespotcha (talk) 23:51, 11 November 2024 (UTC)

  absolutely! yes! Flame, not lame (Don't talk to me.) 23:55, 11 November 2024 (UTC)

  @Flame, not lame: Keep doing what you're doing, but Equinox is right that you should only add pronunciations that you know the pronunciation for. Your contributions are highly valuable on the whole, just try not to guess when you aren't sure. Andrew Sheedy (talk) 00:45, 12 November 2024 (UTC)

  You can review my recent audios. I double checked with Oxford Languages. I knew the IP address was English! Flame, not lame (Don't talk to me.) 00:51, 12 November 2024 (UTC)

  I’ve brought it up to them several times on discord, I wish they’d follow it, but it seems that issues are continuing. I’ve stopped patrolling the audios because there are simply too many. AG202 (talk) 01:07, 12 November 2024 (UTC)

  I made an honest effort to improve. I use my resources such as IPA, Merriam-Webster, and Oxford Languages now. Flame, not lame (Don't talk to me.) 01:20, 12 November 2024 (UTC)

  Thanks, I’ve seen that but again please do not add audios for words you’ve never seen or heard pronounced IRL before. That’s just the best practice for you to do right now. AG202 (talk) 03:01, 12 November 2024 (UTC)

  This also goes for everyone. I've corrected some of the unusual ones I really do know (mostly legal stuff where the stress was wrong), but I don't know a lot of these words, and don't want to guess at them either. As a general rule, it's better to not add anything if you don't know what's correct. Theknightwho (talk) 11:37, 12 November 2024 (UTC)

  I expect to continue my high-quality audio contributions, and I will use resources such as IPA, Merriam-Webster, and Oxford Languages. I will avoid terms with obscure resources, and I plan to focus on fulfilling Lingua Libre's daily audio requests. I will work within my comfort zone.

  If consensus has an issue with one of my audios, then somebody can certainly remove it and let me know what needs improvement, given the language is not hurtful. Flame, not lame (Don't talk to me.) 02:33, 12 November 2024 (UTC)

General comment: As mentioned I’ve brought this issue up many, many times to said user on Discord, but unfortunately the number of audios has ballooned to almost 12,000 audios added by the same user in a very short amount of time. There is simply not enough time nor energy for anyone to patrol the audios added, so at this point I’ve accepted that there will always be incorrect English audios here and there that I’ll simply never run into. (And I remove the ones that I do run into) I suggest that folks at this point do the same, unfortunately. This is why I really emphasized more action and fixing this problem much earlier, but alas, in typical Wiktionary fashion, we let it slide in favor of quantity over quality and lack of direct action. I’m tired. AG202 (talk) 03:06, 12 November 2024 (UTC)

How about this: We shut down audio pronunciations for a little bit, and then people review all of them, make sure they're right and that it's all what people would expect (maybe making a game out of it.) CitationsFreak (talk) 06:58, 12 November 2024 (UTC)

@CitationsFreak: Making a game is a good idea. If the QA process can be automated, then go for it. But shutting down is a bit too extreme without a really solid plan and commitment. --Ssvb (talk) 07:32, 12 November 2024 (UTC)

@AG202: Do you count the total number of recorded audios or those that are linked from Wiktionary articles? Certain undesirable asymmetry definitely exists, because recording audio is very fast and easy in Lingua Libre. After a new contributor figures out the ropes, they can be incredibly productive. Recording around 100 audios in an hour is perfectly normal. That's even not the peak speed bounded by technical limitations, but also includes the review phase and merciless discarding of bad samples.

Is the IP user's claim about every second @Flame, not lame's audio sample being problematic actually grounded in reality, or was it more of a hyperbole? What is the actual rate of errors? I don't think that it's possible to 100% safeguard against errors even for the native speakers. A clip from How I Met Your Mother illustrates this: https://www.youtube.com/watch?v=-Fy_NYCtSgw (Ted pronounces "Chameleon" to his class). That's why it's up to the patrollers and reviewers to provide the necessary safety net and ensure quality. But the process definitely needs to become much easier for the patrollers. Expecting them to submit requests for audio samples removal on Commons and forcing them to go through various time consuming bureaucratic procedures is very much unreasonable.

I have two possible suggestions to improve the process:

• Use the |bad= property of the {{audio}} template instead of just commenting it out, removing the audio sample from the article, contacting the uploader via their talk page or requesting file removal at Commons. Because this (a) saves time and (b) puts the bad audio samples into their own wiki category, where they can be tracked and handled.
• Have one native English speaker do the recording of the audio samples in Lingua Libre. And have another different native English speaker actually adding them to Wiktionary articles. That second person is expected to check its correctness and share the burden of dealing with the angry lynch mob if anything goes wrong.

--Ssvb (talk) 07:13, 12 November 2024 (UTC)

I have added a |bad= property to hydrogeniferous, now it shows up in https://en.wiktionary.org/wiki/Special:WhatLinksHere/Wiktionary:Tracking/audio/bad-audio/en

Now @Flame, not lame or any other Lingua Libre contributor of audio samples can monitor this list of known bad audio and do something to address the problem on case by case basis. This process converges, because after a correct sample becomes eventually available in a Wiktionary article, we are done with it. Rinse and repeat to fix similar problems everywhere else.

Compared to this, just removing audios doesn't work. Because random bots or editors would add the incorrect pronunciation back and the cycle repeats. Another disadvantage of such approach is that those, who are able to do something to fix the problem, are just unaware of it. --Ssvb (talk) 08:23, 12 November 2024 (UTC)

Also pinging @Aquild as another recent English audio samples contributor, who can possibly help or may be interested in this topic. --Ssvb (talk) 08:39, 12 November 2024 (UTC)

Thanks for the ping, I'll take a look. Aquild (talk) 03:48, 14 November 2024 (UTC)

I will pay attention to that list. Flame, not lame (Don't talk to me.) 10:48, 12 November 2024 (UTC)

The user themselves on Discord stated: "last time I checked, Wonderfool made 18,852 audios, and I made 11,911 audios. this vandal challenges me to beat him. 🔊" That's the number I'm going off of. And yes, from the reviews I've done, the error rate is higher than we'd like. I remember having to comment, along with others, on their additions to words with the super- prefix because most of them had the wrong stress. (I don't know if all of them have been fixed yet and I don't have the time to go through them).

As for bots, there was a previous discussion where there was a consensus to limit allowing bots to add audios without some kind of review process for this exact reason. I can find the discussion later. AG202 (talk) 15:25, 12 November 2024 (UTC)

How do you know I sent that on Discord? Flame, not lame (Don't talk to me.) 17:47, 12 November 2024 (UTC)

@AG202: Let me first explain how Lingua Libre works. A user gets a list of let's say 300 words and starts recording them, spending no more than 5 seconds on each of the words. After the recording phase is finished, all these words are presented in a big list. It's possible to replay words and remove any of them from the list if the quality is undesirable. Doing this, the list of 300 words may shrink to even merely 100 due to various reasons (possible pops, clicks, breathing or slurping noises in the audio, abrupt cutoffs in the beginning or end, if it's too quiet or muffled, if the intonation doesn't feel good, or just because of any other reason). With this extra review phase and discarding bad audios, the average time spent on one audio sample may increase from 5 seconds to maybe even 30 seconds. But in my opinion it's still very fast. Producing 500-1000 audios in one weekend is perfectly doable without any quality sacrifices. So ~18K or ~12K audios created over the span of a few months isn't anything particularly unusual or suspicious. That's just a normal productivity enabled by the Lingua Libre tool.

Now if a Wiktionary patroller spots a bad audio (e.g. a mispronounced "chameleon"), how many seconds have to be spent to resolve the problem? My suggestion is to add the |bad= property and move on. This way only a few seconds are spent, and the ball is on the audio recorder side again, who can re-upload a better audio and remove the |bad= property. Or start a dispute if they believe that everything is already fine as-is.

For comparison, the @Derbeth's suggestion and the old bot policy was to make requests for bad audio samples removal from Commons, which is non-workable, because it's too labor intensive. That's the reason, why there was that consensus to suspend the bot. In my opinion, anything longer than 30 seconds per one bad audio is too labor intensive for the patrollers. --Ssvb (talk) 05:11, 13 November 2024 (UTC)

@Ssvb: The problem is the amount of time for a single audio, it's the amount of time to do a quality check for thousands of them. Using your estimate, even a hundred audios would take about an hour, and frankly, I've found it to take longer. Up that to the thousand range and it'd take 10 hours for a single person. I personally am not going to dedicate my time like that to reviewing audios, especially when I've already had discussions with the user in the past and when audios continue to be added at a rate faster than I can review them. It's just unrealistic, and my life does not center around this project. I wish we had more patrollers, but even if we had say 10 actively working on this, it'd still take way too much time. That's why I said that I've basically given up. It was more realistic when there were around 1000 audios, but now it's infeasible. AG202 (talk) 05:33, 13 November 2024 (UTC)

Maybe just have a pron-checker lab, like Lingua Libre. It would be slow, but hopefully faster than "100 per hour". CitationsFreak (talk) 05:50, 13 November 2024 (UTC)

@CitationsFreak: I don't quite understand what is "pron-checker lab". Could you elaborate? --Ssvb (talk) 06:49, 13 November 2024 (UTC)

A system like Lingua Libre, but for verifying that the pronunciations are accurate. CitationsFreak (talk) 07:18, 13 November 2024 (UTC)

@AG202: The patrollers only need to take action when audio samples are incorrect. And hopefully only a small fraction of these ~12K happens to be incorrect. Yes, you mentioned some the systematic problems with the "super-" prefix, but hopefully the total number of them was not large enough to significantly contaminate the whole set and everything is not so dramatic. --Ssvb (talk) 06:39, 13 November 2024 (UTC)

@Ssvb: It was significant. I am one of the few who's actually taken the time to listen to a significant chunk of them, by going through the contributions list, and there were many issues. There's no way to know which ones are incorrect without listening to all of them. Calling it "dramatic" when you don't know the amount of time and effort I've put into this the past few months is an easy way to have me check out completely. CC: @Theknightwho AG202 (talk) 14:18, 13 November 2024 (UTC)

@AG202: I understand your frustration. But this topic had been created by a cowardly anonymous IP user, who was up to no good and never intended to suggest anything constructive, thus stirring an unnecessary "drama". It was pretty transparent, especially considering the added sexist insinuations that allegedly only simps would raise objections, etc.

Wiktionary is a collaborative effort. Both the contributors of audio samples and patrollers need to work together. Patrollers can't assume that all audios are going to be perfect. This is normal, especially when they are contributed by a teenager, who naturally has a smaller vocabulary due to younger age. Of course it would be nice to have more contributors from the older age group, but they tend to be more cynical and less enthusiastic. Some of them already had experience with the "dramas" like this and learned the hard way to avoid being in the spotlight. The current situation is unhealthy. It became so ridiculous, that even foreigners are trying to "help" by recording English audios themselves and even synthetic robotic audio samples are seriously suggested in BP discussions from time to time.

It's more productive to have a more friendly environment, which attracts more contributors, rather than scares them away. Good tutorials and sane policies help. Some of the commenters here have the same opinion. I think that Help:Audio can to be extended to mention the usefulness of dictionaries, best practices for the patrollers how to deal with problematic audio, describe the |bad= property of the {{audio}} template and maybe other things. If we don't do this, then this discussion is a yet another nothingburger. Should I post a new topic with concrete proposals and initiate voting?

And again, I understand that you are fed up with this stuff and don't feel like patrolling audios anymore. And maybe I'm acting out of line proposing policy changes in this domain. I think that it's okay for you to maybe take a break until it becomes clear what works and what doesn't. --Ssvb (talk) 02:51, 15 November 2024 (UTC)

Honestly, I do believe that the IP had good intentions in starting this thread, and good things are coming out of this thread (like your suggestions). CitationsFreak (talk) 00:04, 16 November 2024 (UTC)

Wonderfool made a sexual comment about me yesterday. He lost all of my respect. Flame, not lame (Don't talk to me.) 10:29, 13 November 2024 (UTC)

@Flame, not lame: The OED gives the pronunciation of hydrogeniferous so there was no need to guess for that one. Ioaxxere (talk) 03:25, 12 November 2024 (UTC)

It is crucial on my part to further analyze my resources beforehand, and I agree to focus on creating audio for words I know well. Flame, not lame (Don't talk to me.) 03:36, 12 November 2024 (UTC)

@Ioaxxere: Would you (or anyone else) extend the Help:Audio_pronunciations guidelines to add the missing information about the necessity of consulting reputable orthopedic orthoepic dictionaries prior to uploading audio samples, even for native speakers? And list OED as an example of such dictionary for English. BTW, is there or isn't any danger of succumbing to prescriptivism? --Ssvb (talk) 06:02, 12 November 2024 (UTC)

Sadly, even the OED has to be taken with a grain of salt / native-speaker-knowledge these days, because they've embraced "many American /t/s are phonemically /d/" and a few other quirky ideas. (Initially I thought they were only using /d/ in cases where Americans flap /t/, but I came across at least two cases where their IPA had /d/ where Americans pronounce an unflapped [t]. If I relocate them or find more, I'll edit this comment to mention/link them.) No large source is perfect. - -sche (discuss) 21:07, 12 November 2024 (UTC)

@Ssvb: It's probably just a typo, but the right word is orthoepic, not orthopedic. PUC – 18:49, 13 November 2024 (UTC)

@PUC: Thank you. It looks hilarious indeed. A spellchecker "corrected" me this way and I didn't notice. --Ssvb (talk) 19:34, 13 November 2024 (UTC)

I agree with others that the recording of pronunciations is important work - I would do it if my voice were more suited to the task, and it's clear that FNL's voice is ideal for the job. But it must be done right. Having looked through a few pages of [10], I found definite errors in electrophoresis and tubercle, and likely errors (or possibly legitimate variant pronunciations?) of emend and precocity. I flagged them all with the |bad= parameter - I think we could definitely improve the way that parameter is handled, perhaps with a call-to-action similar to {{rfp}}. Courtesy ping to Flame, not lame, who might like to look into re-recording these words.

@Ssvb YouTube is a great resource for checking how words are pronounced "in the wild". I was going to criticise the recorded pronunciation of dairyman for wrongly stressing the last syllable, but I searched YouTube and found various Americans discussing "Tevye the Dairyman", all of whom pronounced it the same way as our recording! This, that and the other (talk) 09:32, 12 November 2024 (UTC)

"FNL" is disrespectful, so please address me as "Flame, not lame" or "Flame".

Electrophoresis and tubercle matched IPA, and ememd and precocity were meant to align human recordings from other online dictionaries. Flame, not lame (Don't talk to me.) 10:42, 12 November 2024 (UTC)

FWIW our current dairyman audio does put the stress on the initial syllable. AG202 (talk) 15:25, 12 November 2024 (UTC)

I would guess This, that and the other was commenting not on the position of the primary stress, but on the use of an unreduced vowel in the final syllable versus a schwa.--Urszag (talk) 17:50, 12 November 2024 (UTC)

Quite correct, yes. This, that and the other (talk) 00:43, 13 November 2024 (UTC)

Ahh yes, then in that case, yeah I'd expect a number of Americans to pronounce it the way Flame did, including myself (though I don't use dairyman in everyday speech). AG202 (talk) 02:52, 13 November 2024 (UTC)

Everyone makes mistakes and I've uploaded some audio that was wrong and others corrected me. It's not that big a deal and it's weird and discouraging that there's so much noise about a constructive user who has been an asset to the community. (And as an aside, who has a far more pleasant voice to listen to than mine.) —Justin (koavf)❤T☮C☺M☯ 04:00, 13 November 2024 (UTC)

To be fair, it's that she makes some bad edits in a sea of good edits, in an under-patrolled area. Although I do think she's improving. CitationsFreak (talk) 04:29, 13 November 2024 (UTC)

Several times I informed these people I planned to do my research and redirect to audio for words I know well, so their persistent condemnation brings my hopes down. Flame, not lame (Don't talk to me.) 10:27, 13 November 2024 (UTC)

Automatically generated etymology texts

I've noticed that Category:Entries with etymology texts by language has been organically growing and it doesn't seem to be causing any issues. Maybe we can remove the scary "[EXPERIMENTAL]" label in the documentation and officially allow editors to use the |text= parameter. While setting up the IDs is admittedly a bit of a hassle, it comes with the benefit of guaranteed synchronization between entries, so I hope we can use the template more widely in the future. Ioaxxere (talk) 03:46, 12 November 2024 (UTC)

Questionable use of suffix template without root

"See {{suffix|en||illion}}" → "See +‎ -illion" looks wrong. zillion is not from see +‎ -illion. That would be *seeillion. This problem is with many terms in the entire Category:English terms suffixed with -illion. I changed these to {{m}} but was reverted. Would "See {{af|en|-illion}}" → "See -illion" be better? @Binarystep, Einstein2: courtesy ping.

Should we also make {{suffix}} show an error if the root (second) parameter is empty? Category:English terms suffixed with -illion and Template:prefix/documentation say that {{af}} is preferred anyway. 76.71.3.150 11:24, 12 November 2024 (UTC)

“See -illion” (i.e., See {{af|en|-illion}}) seems better, without the ⟨+⟩ denoting “and”. J3133 (talk) 11:34, 12 November 2024 (UTC)

Just fixed that mistake Davi6596 (talk) 14:40, 12 November 2024 (UTC)

@Davi6596: I restored the category. J3133 (talk) 14:52, 12 November 2024 (UTC)

Thanks, I didn't mean to remove the category. Davi6596 (talk) 23:28, 12 November 2024 (UTC)

Hmmm, should I or should I not quit Wiktionary?

I might give up Wiktionary. Not the best idea. Flame, not lame (Don't talk to me.) 18:34, 12 November 2024 (UTC)

The mods here aren't particularly considerate, many of them are quite confrontational... Purplebackpack89 20:07, 12 November 2024 (UTC)

@Flame, not lame: I hope you won't, despite #Ongoing wrong audio from Flame, not lame. 0DF (talk) 23:24, 12 November 2024 (UTC)

Second. Making mistakes is part of the learning process. Sometimes people are a bit too blunt in their criticism, which isn't good and ought to be called out too. —Caoimhin ceallach (talk) 23:34, 12 November 2024 (UTC)

I second this. Davi6596 (talk) 23:38, 12 November 2024 (UTC)

You should not. —Justin (koavf)❤T☮C☺M☯ 23:30, 12 November 2024 (UTC)

@Flame, not lame Why? You've been contributing a lot. No one is perfect: if there's anything to improve or fix, do so. But, if an audio is right, you shouldn't be afraid of defending yourself. Davi6596 (talk) 23:32, 12 November 2024 (UTC)

From what was brought up in the discussion above, I gather that the insatisfaction towards you is actually due to Wiktionary’s convoluted audio review process. It’s normal to make the mistakes you’ve made, and your readiness to correct them is remarkable!

Hopefully everyone will realize that the path to take is not by attacking you, but by bettering the project’s policies. Polomo47 (talk) 16:54, 13 November 2024 (UTC)

Agreed with the others above. Valuable contributions. And already improving methods to reduce any occasional flaws. Good work! Quercus solaris (talk) 20:34, 14 November 2024 (UTC)

I listened to rainstorm. It is very clear, but as you would expect, it's not the British pronunciation I would use. DonnanZ (talk) 17:38, 15 November 2024 (UTC)

The OED gives /ˈreɪnstɔːm/ as the UK pronunciation (which we would give as /ˈɹeɪnstɔːm/), and I agree. Do you really say /ɹeɪnˈstɔːm/, which is what you added to the entry? That sounds odd to me, and I speak British English. Theknightwho (talk) 13:01, 17 November 2024 (UTC)

Audio whitelist

I propose moving User:Metaknowledge/audiowhitelist to the Wiktionary namespace. Currently it is our only source for bot-imported Lingua Libre audio pronunciations (through User:DerbethBot). LL is now an enormous source of audio files but we are importing them at a trickle. That said, there's a lot of garbage on LL because it's so accessible, and that's why Metaknowledge didn't widely advertise this page. I suggest that we set up a system similar to Wiktionary:Whitelist with nomination by one user and approval by another. Because the stakes are lower than user right status, maybe the nominator could be anyone and the approver must be an admin.

Let's also consider the title of this page bearing in mind Benwing's comment on an above discussion that the terms "whitelist" and "blacklist" are falling out of favor. Ultimateria (talk) 02:39, 13 November 2024 (UTC)

Support —Justin (koavf)❤T☮C☺M☯ 03:57, 13 November 2024 (UTC)

Category: words with different stress patterns

I suggest creating a category for words that show different stress patterns in different didalects, such as ballet (BrE /ˈbæleɪ/ vs AmE /bæˈleɪ/) or peanut butter (BrE late-stressed vs AmE early-stressed.) JMGN (talk) 01:36, 14 November 2024 (UTC)

Orthography of Istro-Romanian

Should Zvjezdana Vrzić's or August Kovačec's orthography of Istro-Romanian be used or should both be employed? The former is modeled after Serbo-Croatian, whereas the latter is modeled after Daco-Romanian. Native speakers and heritage speakers only use Vrzić's orthography. Does each variant, based on one of these orthographies, have to be attested in the chosen orthography? HeliosX (talk) 03:32, 15 November 2024 (UTC)

To search or compare attestations in the respective other othography is too much effort, more importantly would make Wiktionary inconsistent in its headwords. So just pick the Croatian orthography and convert Daco-Romanian spellings to it, you will have to cite the applied references to be accurate anyway. Fay Freak (talk) 04:24, 15 November 2024 (UTC)

I think both deserve to be included. The question is whether only one should be lemmatized (with the other altform-ified) or both should be treated as equals (like Latin and Cyrillic spellings of Serbo-Croatian). Does either enjoy any kind of official or “semi-official” support over the other? Nicodene (talk) 20:02, 15 November 2024 (UTC)

Ban of Denazz

A few days ago, User:Koavf banned User:Denazz for ever, ostensibly by request. User:Vininn126 was also involved, but did that user request a ban? Maybe not. The question remains, isn't this ban far too harsh? Should we ban Koavf instead? DonnanZ (talk) 13:01, 15 November 2024 (UTC)

So I was right regarding User talk:Donnanz § Sockpuppet! PUC – 13:04, 15 November 2024 (UTC)

No, you were wrong. Two different people. DonnanZ (talk) 13:07, 15 November 2024 (UTC)

"Involved" is a strong word. I commented it looked like the vandalism had been cleaned up. A ban on vandalism seems appropriate. Without any real counterarguments, it sounds like admins should be banned for banning vandals. Vininn126 (talk) 13:07, 15 November 2024 (UTC)

According to the block log, you banned Denazz for 1 day, and again for 1 hour. That's way short of Koavf's lifetime ban. DonnanZ (talk) 13:22, 15 November 2024 (UTC)

I have very little interest in interacting with you on this matter. I rarely find it to be coherent or productive. In this issue I see a similar trend already, you've provided no actual arguments and only seem to wish to stir the pot. Good bye. Vininn126 (talk) 13:26, 15 November 2024 (UTC)

Calm down. I don't consider you as the villain here. DonnanZ (talk) 13:31, 15 November 2024 (UTC)

And who is "the villain"? Is it the person who by his own admission was vandalizing this site for the lulz and wanted to be blocked? If so, we agree. —Justin (koavf)❤T☮C☺M☯ 13:32, 15 November 2024 (UTC)

Yes, the user explicitly requested to be banned. No, this is not too harsh. No, I should not be banned instead. If any other admin thinks that it's a really brilliant idea to let this user be unbanned so he can do things like this again, I'm all ears.

Honestly, why did you start this thread? You think that an admin who bans a user for a rash of vandalism which he himself says is for the explicit purpose of being banned is itself bannable? Is this a joke? —Justin (koavf)❤T☮C☺M☯ 13:29, 15 November 2024 (UTC)

I didn't think of looking there! DonnanZ (talk) 13:36, 15 November 2024 (UTC)

None of that answers my questions. Are you saying that you didn't even think to look on the user's talk page before starting this thread? If so, I'm honestly amazed. —Justin (koavf)❤T☮C☺M☯ 13:37, 15 November 2024 (UTC)

I looked at the user page, it didn't occur to me to look at the talk page. Employing hindsight, the wording should have been "per request by Denazz". That would have avoided the topic being created. DonnanZ (talk) 13:46, 15 November 2024 (UTC)

The facts that you didn't do the mildest due diligence, came here with the preposterous premise that admins should be blocked for blocking vandals, and you seemingly have no serious interest in discussing this are in no way my fault. This thread should not have been started and it shows incredibly poor judgement on your part. At a bare minimum, you could have posted to my talk or asked me via email, but coming here suggesting that I should be banned for blocking a spree vandal who explicitly asked to be blocked is frankly stupid and you should feel bad. I hope that my harsh language is well taken and that you are discouraged from posting such inane wastes of the community's time in the future. As Vininn pointed out (and V, please forgive me if I'm putting words in your mouth), you came here with such a ridiculous pretense that you should have known better. Please be better. —Justin (koavf)❤T☮C☺M☯ 13:51, 15 November 2024 (UTC)

Space has been wasted due to your all-too-economical editing. Let that be a lesson to you. That's the end of the matter. DonnanZ (talk) 14:00, 15 November 2024 (UTC)

kthxbye —Justin (koavf)❤T☮C☺M☯ 14:01, 15 November 2024 (UTC)

• Denazz should never have been unbanned. Did we forget how much trouble he caused when he was Wonderful? Or the trouble he caused under his current name? Support ban, regardless of whether requested or not. Oppose any action against Koavf. Purplebackpack89 17:09, 15 November 2024 (UTC)

I imagine Denazz will reincarnate himself. He was presumably fed up with that name. DonnanZ (talk) 17:42, 15 November 2024 (UTC)

Just for the record, banning a WF sock when they do things like this is perfectly appropriate. I've done it myself more than once. Chuck Entz (talk) 17:49, 15 November 2024 (UTC)

For the record, the block from a few days ago was directed at Whalespotcha, who clearly deserved it. Whalespotcha (WS) is WF and she likes WS (Wikisaurus), Denazz (DZ) is WS/WF, and likes Drz (the rapper). Donnanz (Dz) isn't WF but sounds like DZ and dislikes Drz (the rapper). DZ's WT is WF, as is PS (P. Sovjunk). PS, PS is I, WF. OK? P. Sovjunk (talk) 18:03, 15 November 2024 (UTC)

Oh, and remember, FNL doesn't like being called FNL. P. Sovjunk (talk) 18:05, 15 November 2024 (UTC)

Suggestions for improving the Help:Audio pronunciations guideline

I propose to:

1. Remove the old guide section about the Audacity and uploading OGG files. It only makes the page much bigger and contains labor-intensive obsolete instructions, which are a liability today as they are prone to recording quality and categorization problems.
2. Structure the page and have two separate parts: (1) for the contributors, who are recording audio and (2) for the patrollers, who are ensuring that only correctly pronounced and cleanly recorded audios end up in Wiktionary entries.
3. Recommend to consult the reputable dictionaries, such as the OED.
4. Mention the |bad= parameter of the {{audio}} template, which can be set by the patrollers. And the https://en.wiktionary.org/wiki/Special:WhatLinksHere/Wiktionary:Tracking/audio/bad-audio/en list, which should be preferably prioritized by those, who are recording audio.

As an example, take a look at orange. It's a common word, but it's currently stuck with some low-quality noisy OGG audio samples squatting the space in Wiktionary. Meanwhile, there are 7 audios in https://commons.wikimedia.org/wiki/Category:Lingua_Libre_pronunciation-eng?from=orange to be evaluated as possible replacements. I used the |bad= parameter to flag the problematic audios and now the problem is visible. Not all of the Lingua Libre audio samples are good, but it's still useful to have a sizeable pool of samples to choose from. It's similar to how there are many images available on Commons, but not all of them are necessarily suitable for use in Wiktionary. --Ssvb (talk) 22:40, 15 November 2024 (UTC)

Support. CitationsFreak (talk) 00:02, 16 November 2024 (UTC)

Support 0DF (talk) 00:18, 16 November 2024 (UTC)

Support Aquild (talk) 05:34, 17 November 2024 (UTC)

Instructions for OGG and Audacity are necessary in case Lingua Libre does not work for some people. Instructions for speakers and patrollers are useful. Suggest resources such as IPA, Oxford Languages, and Merriam-Webster, and add a disclaimer about AI voices. Encourage users to communicate on talk pages. PetScan and Lingua Libre's daily list of requests are worth mentioning, and allow users to remove inappropriate requests here. Flame, not lame (Don't talk to me.) 15:01, 17 November 2024 (UTC)

@Flame, not lame: Thanks for your feedback. More text is not always better than less text. Removing the obsolete information makes instructions much more clear. If Lingua Libre doesn't work for somebody, then they are encouraged to post a comment and ask for help. The existence of the alternative obsolete instructions is highly unlikely to help these people, they will only waste time for nothing instead of asking for help. There's apparently an alternative Spell4Wiki solution, which was used for uploading the audios discussed in Wiktionary:Beer_parlour/2024/September#I’m_not_a_TTS, but this doesn't look like a success story to me and I don't feel like recommending it as a viable alternative to Lingua Libre right now.

Encouraging users to communicate on talk pages about each and every problematic audio is inefficient and scales poorly. People quickly grow tired of that and annoyed, so they just stop paying attention to pronunciation problems in audio altogether. That's the situation we are in right now. And the |bad= parameter is expected to help us avoid exactly that in most cases. That said, communicating on talk pages surely makes sense when there's a dispute to resolve.

About the lists of words to record. A lot of common words have noise or other minor or major recording defects in them, such as orange, candle, chameleon or planet. --Ssvb (talk) 10:53, 18 November 2024 (UTC)

By "obsolete", do you mean it can't be done, or that it isn't the preferred way to do things? CitationsFreak (talk) 19:51, 18 November 2024 (UTC)

It's a combination of both. The old instructions had been written by @Dvortygirl back in 2006, they assume a computer-savvy person to install and configure the software, record clean audio with proper noise removal, do files uploading to Commons, adhering to proper naming conventions, categorization, etc. And even if someone has the right computer skills, the procedure is still unnecessarily labor-intensive by modern standards. So yes, it "can't be done" in practice by an average contributor and it "isn't the preferred way" because the results may have substandard quality. Today Lingua Libre automates most of these steps and it's a project under the Wikimedia umbrella. --Ssvb (talk) 23:52, 18 November 2024 (UTC)

I would say have something like "You don't need Lingua Libre to make audios, but it's easier. [explanation of LL] If you do decide to not use it..." and then we lost how to make 'em by hand, since it is possible (although it isn't a necessity). CitationsFreak (talk) 05:10, 19 November 2024 (UTC)

I'll put it bluntly: many aspects of the almost two decades old instructions have a real potential of causing harm. For example, the described bulk upload is an enabler for uploading large batches of synthetically generated robotic pronunciations. Whereas LL is not designed for recording non-human voices, and one needs to go out of their way to do that. Finally, the possibility of still "making 'em by hand" without LL is a liability, because this just provides more room for human errors and more annoyed patrollers, who would have to deal with this stuff. --Ssvb (talk) 06:13, 19 November 2024 (UTC)

I am opposed in principle on being dependent on an external project just to be able to add audio pronunciations. — SURJECTION ^{/ T / C / L /} 15:49, 19 November 2024 (UTC)

First of all, how do you define external project? Is https://commons.wikimedia.org an external project for Wiktionary? And second, if Lingua Libre stops satisfying the requirements of the Wiktionary project, then it can be replaced. --Ssvb (talk) 16:42, 19 November 2024 (UTC)

No, Wikimedia projects are not external, but the argument is inconsequent since we always depend on stuff in some git repo. CJK editors also depend on IMEs to add spellings. It does not matter really once the data is on Wiktionary or another Wikimedia project. If there are methods to internalize data more efficiently, go for it. Fay Freak (talk) 17:41, 19 November 2024 (UTC)

Commons is not external, Lingua Libre is. It's not hosted by the WMF, as far as I know. — SURJECTION ^{/ T / C / L /} 07:41, 27 November 2024 (UTC)

Lingua Libre is a project of Wikimedia France and they are not complete strangers. Per [11]: The Wikimedia Foundation and Wikimedia France are two separate entities working together to support Wikipedia and other free knowledge sharing projects. The Wikimedia Foundation works at a global level, providing technology support and support to volunteers and projects. As for Wikimedia France, based in Paris, it focuses more particularly on actions in France, content in French and French speaking communities.

Due to trademark reasons, I don't think that Wikimedia France would have been allowed to pick such a name for themselves without the Wikimedia Foundation's official approval.

That said, as a precaution, maybe we can add a recommendation to register a separate account specifically for recording audio? Because Lingua Libre performs uploads to Commons on user's behalf, facilitated by OAuth. --Ssvb (talk) 08:10, 27 November 2024 (UTC)

@Ssvb we can simply put the Audacity based instructions in a collapsible box. This, that and the other (talk) 22:51, 18 November 2024 (UTC)

Support. Thank you. AG202 (talk) 01:59, 21 November 2024 (UTC)

Bot flag for User:SaphBot

This would just iterate over all entries with AWB and normalise them with the regexes at User:Erutuon/scripts/cleanup.js#L-95--L-109. The regexes cover:

• Trailing space, on both empty lines and lines with content (deletes)
• Extraneous blank lines (deletes)
• Horizontal tabs (converts to spaces; general norm 3)
• Missing spaces in list items (e.g. #foo ==> # foo)
• Extraneous spaces in headers (deletes)

-saph668 (user—talk—contribs) 22:08, 19 November 2024 (UTC)

Updating COALMINE rule

I've created the vote Wiktionary:Votes/2024-11/Updating COALMINE rule and proposed a few changes to how the COALMINE rule applies. The main rationale for this would be that rare, non-standard, or barely attested closed forms of SOP open compounds may not necessarily force the keeping of the open form, and the application of this rule be decided by the RFD discussion for the entry. A concern may be there that if might lead to us having a rare closed form that passes CFI but not the common/standard open/hyphenated SOP variant of it, but that can be dealt by deciding to keep the open form at a RFD discussion, or alternatively mentioning the closed form as rare, nonstandard, etc. such as writing: {{nonstandard form of|en|[[non-]][[Canadian]]}} at the entry nonCanadian. Another concern might be that the passing of the vote could lead to deletion of potentially keepable/useful entries like non-existent but they would still need to go through RFD before getting deleted, and the COALMINE test could still be pointed to as an argument for keeping them, which arguably anyone can do at present too and discuss there keeping or deletion, such as Talk:heatresistant and Talk:heat-resistant, and these prefixed ones possibly do not even fully fit WT:COALMINE as they are not the significantly more common forms of attestable single words, but have not yet been considered for deletion, and I expect it to be the same even if WT:COALMINE is made non-binding. (As at Wiktionary:Votes/2019-08/Rescinding the "Coalmine" policy: Metaknowledge: I think it's healthy that we continue to relitigate this as a community every few years, Robbie SWE: it's good to have these types of discussions every now and again, it might be fine to bring this again now to see if the community would accept these changes.) – Svārtava (tɕ) 11:14, 20 November 2024 (UTC)

Your example nonCanadian isn't a good one, because the most common spelling non-Canadian is also not an open compound – it's not spelled *non Canadian. —Mahāgaja · talk 18:24, 20 November 2024 (UTC)

I don't understand why the coalmine rule exists. What bearing does the spelling have on whether it meets CFI? Whether it's one word or two just depends on how a particular language's orthography decides to handle compounds. It has nothing to do with idiomaticity. —Caoimhin ceallach (talk) 11:41, 21 November 2024 (UTC)

You are absolutely correct. This is a point that I have been banging my head against for years. Whether something is sum-of-parts has ABSOLUTELY NOTHING to do with whether someone happens arbitrarily to write it open, closed, or hyphenated. Unfortunately, translating this observation into a sensible system whereby people can look up what they perceive as "words" proves difficult. Still, we can surely address the most BLATANT cases such as "non", "anti", etc. Mihia (talk) 22:52, 26 November 2024 (UTC)

Appealing blocks without userpage or email?

Hi. Can someone tell me how (if at all) wiktionary handles blocks from users who are blocked without access to email and their user talk? Thanks, Barkeep49 (talk) 17:12, 20 November 2024 (UTC)

How would any wiki handle this, I wonder? (An e-mail list?) I don't think we have an official method; there are unofficial avenues, like pinging Wiktionarians on other projects (or Discord) the user isn't blocked on so someone can relay the appeal here (an avenue I recall at least one user using, despite his talk page access not being restricted), but in general it seems that if someone has managed to get blocked and have their talk page and e-mail access revoked, they've sufficiently obdurately abused their editing abilities, talk page, and e-mail that they're not going to be unblocked.
Someone who was a vandal ten years ago might be a different person now, but if they haven't acquired a new IP that they can edit or create a new account [to edit or post a block-appeal] from in that time, they may be such an edge case as to be out of official options, leaving them only the unofficial options aforementioned.
On rare occasion, particularly persistent bad users have pestered Wikipedia (or Metawiki, etc) admins to come here and appeal on their behalf (relatively soon after their block), but the two such users I can think of offhand (neither of whom had their talk page + email access restricted AFAICR) respectively had the appeal declined and ended up re-blocked because they continued blockworthy behaviour. - -sche (discuss) 20:01, 20 November 2024 (UTC)

Thanks sche. Your question of "How would any wiki handle this, I wonder?" is a good one. I know some projects allow appeals through their info VRT queue but yes I think many projects this size don't have great answers here. I appreciate the practical options you offered. Thanks, Barkeep49 (talk) 21:28, 20 November 2024 (UTC)

Word of the Year vote

Hello! I have just started a premature vote the for concept of a Word of the Year (WotY) for Wiktionary, which could perhaps be displayed on the main page for a few weeks in late December and January. Would appreciate feedback, of course :) The entries are all obtained from WT:WOTY/2024, where some of us have sporadically added trending words seen through this year. See also the original, unsuccessful 2023 WotY vote which was far too hastily prepared. Thanks, LunaEatsTuna (talk) 11:58, 21 November 2024 (UTC)

Publicizing discussions on watchlist

Similar to the {{smallest discussions}} box that used to be there in the watchlist till the revision Special:Permalink/64505126, I think it would be nice if we had another box appearing in the watchlist below the votes box for important discussions to be publicized to users on their watchlists. This would be very helpful for e.g. sitewide discussions that could get more input such as proposals related to (non-language specific) layout, templates or modules, etc. Discussions could be listed in the box by a page similar to Wiktionary:Votes/Active where users could add them. A notable example of a discussion with sitewide impact that didn't get sufficient input/comments is Category talk:Colloquialisms by language#RFM discussion: July 2021–January 2022 and had to be overturned later by Wiktionary:Votes/2022-01/Label for lower register. – Svārtava (tɕ) 12:01, 21 November 2024 (UTC)

Sign up for the language community meeting on November 29th, 16:00 UTC

Hello everyone,

The next language community meeting is coming up next week, on November 29th, at 16:00 UTC (Zonestamp! For your timezone <https://zonestamp.toolforge.org/1732896000>). If you're interested in joining, you can sign up on this wiki page: <https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/Community_meetings#29_November_2024>.

This participant-driven meeting will be organized by the Wikimedia Foundation’s Language Product Localization team and the Language Diversity Hub. There will be presentations on topics like developing language keyboards, the creation of the Moore Wikipedia, and the language support track at Wiki Indaba. We will also have members from the Wayuunaiki community joining us to share their experiences with the Incubator and as a new community within our movement. This meeting will have a Spanish interpretation.

Looking forward to seeing you at the language community meeting! Cheers, Srishti 19:55, 21 November 2024 (UTC)

Changes at inflection el tables

attn interface admin @This, that and the other and admin. director for Modern Greek @Saltmarsh. Dozens of inflectional tables are altered in some weird way. 2024.11.22 It has something to do with Wiktionary:Beer_parlour/2024/October#Towards_a_Standardization_of_Inflection_Tables, which, I understand, concerns languages with very simple inflections whose administrators have agreed to change. Dear Salt, have you worked with M This, that and the other for such changes? Not only colours look weird, but something is wrong with notes and width. Thank you. ‑‑Sarri.greek ^♫ I 08:29, 22 November 2024 (UTC)

As I wrote at User talk:Sarri.greek, I took it upon myself today to spend some time tidying up Greek noun and adjective declension templates, which had a number of visual issues, including

• lack of support for dark mode
• overly saturated colours and too little padding between the contents of table cells and the cell border, so that cell contents are hard up against the border (these are both very common issues across all our inflection tables)
• use of the nonstandard transliteration template {{el-link-ttip}}, which is not usable on mobile and was nominated for deletion (admittedly not the strongest consensus for deletion in the history of the project, but enough to act upon, I think)

I'm happy to reinstate the collapsibility of adjective tables if that is a particular concern.

As for the other changes, I'd invite community members to look at the παλιός entry, which (at the time I write this) contains a template using the new visual style and one using the old visual style, and comment on which one is better - being sure to check in dark mode as well as on your phone. This, that and the other (talk) 08:41, 22 November 2024 (UTC)

@This, that and the other: I've taken a look at παλιός (on my computer; I have no smartphone). I don't have a strong preference regarding the presentation of the tables in light mode, but in dark mode the comparative table's column headers and derivations and notes sections are unreadable, so the “old visual style” needs support for dark mode if it is to be the one to remain. But, other than that, I don't really mind which visual style prevails, as long as the style is consistent (i.e. let's not have a mix of styles). Even before your changes, however, there already existed a mix of styles, with Demotic/SMG being presented in the “old visual style” and with Katharevousa being presented in the same style as Ancient Greek (and, indeed, using that language's templates); this looks really terrible when both are used together, as in the case of Λεϊβνίτιος (Leïvnítios), which has both Demotic and Katharevousa declension. If there is to be a change in the appearance of Modern Greek tables, we should ideally take the opportunity to unify the visual styles of Ancient Greek and Modern Greek. 0DF (talk) 10:32, 22 November 2024 (UTC)

[from User:Sarri.greek] Thank you @This, that and the other for your notes and forgive this long note. The Wiktionary:Beer_parlour/2024/October#Towards_a_Standardization_of_Inflection_Tables is too technical for me to understand. Also ref to el-link-ttip deletion Talk and the nice colours by User:Surjection/swatch2. Speaking of inflectional tables in particular:

Standardisation and unification are two different things. Standardising inflectional tables in particular, with default best view at all browsers, all skins, white, dark, pink modes, for all media, for mobile, for desktop, for hologramme, for whatever, and despite any preferences of a reader, who may not have preconsidered inflectional tables and/or specific languages. Of course, some choices may be offered, but some output principles have to be there, always and everywhere.

These principles may differ from language to language. Assuming that we work in pairs, the ideal editing of templates could be done by a programmer & a language director who has all the previous templates in his/her mind. Which may be the result of laborious discussions, thousands of trials and applications, a procedure which may have lasted more than 12 months (e.g. for el)

_1 dark mode is about the page, I presume. The territory of the inflectional table, is separate and its backgrounds are set. At most, the forms-cell background (default ffffff to work on, with text colour black, or combinations of base+ending, could possibly be offered at dark mode with corresponding text colours/ But I would rather keep this territory as is.)

• colours for inflectional tables for languages with heavy infl.system need 4 colours (same for maps: Four color theorem), and probably 2 borders: soft inner borders to help the eye and strong separating sections or as outer borders (now, we have only strong borders). E.g. for lang=el then c(olor)_1=#XXXXX darkish, for hypertitles, c_2= for grammatical terms (usually horizontal like genders, aspects, tenses, or important notes, c_3= for grammatical terms (usually at left side like persons or cases) and c_4= for notes (very light). For a dead lang=la, these c_ params could be set somewhere.

Some >>saturated colours<< were chosen as characteristic, I think. e.g. Aegean blue for el

Are they different tones of the same colour? Not always. It becomes too pale and dull.

Some wiktionaries like de.wikt, fr.wikt decided on totally unified infl.table.styles (cf for both ancient and modern: wikt:en:καλός, wikt:de:καλός, wikt:fr:καλός base+ending system, wikt:el:καλός

_2 padding, borders etc (I do not understand very much what you are describing): Could someone design a super-table example of a best-view as help to copypaste from? float= show= paddings=likethat, etc. We need economic spaces; clear and not small font sizes for languages with diacritics.

width. Yes, tables may be large. There is no royal road to that. (wikt:el:συμπεριλαμβανόμενος) Mobile users can scroll, I hope, or use landscape view, which still cannot show all tables in the world.

_3 transliteration at Module:el-translit has to be reviewed (@Saltmarsh). Grek or Polyt fonts, font sizes and transliterations have to be reviewed too, hopefully together with @Erutuon.
The problem started in the old days of wiktionary with this confusion: Yes, we present Ancient Greek grc polytonic, Modern Greek el monotonic. But, all greek may be written (in quotations for example) polytonically in books before 1982. So, a el-translit should include Polyt too.

• Katharevousa under Modern Greek is polytonic. Ancient Greek tables need a little update for it ( if dial=el-kth, then prosody=notshown (oh, never mind, we can add a note), dual=- ) Λεϊβνίτιος by @0DF is exotic, but serves well as an example of juxtaposing tables face-à-face.

_3b tooltips are a powerful weapon of electronic dictionaries and text presentations. For Modern Greek, I would keep {{el-link-ttip}} (with the tooltip on a dot) and add underneath the ipa which is much more helpful (fr.wiktionary does this a lot). If {{el-link-ttip}} is to be expanded, where is a Templare:link vertical with all parameters vertically tr= ts= t= one under the other? I have tried to show outputs at Template:User:Sarri.greek/tlse but i have no help from any programmer who would make it properly. & small ideas: For dead languages, expected, unattested and rare styles could be considered. For contemporary, learned or high register, vernacular and rare.

PS As the technical things become more complicated, the interface programmers and the language editors have been drifting apart.

Language specifics are cut on the procrustean bed of the hegemonic English linguistic nomenclatura, foreign linguists are ignored and small language editors are mocked as ideoleptic (obsessive) maniacs —and by one of your best admins. The case study of Greek is an example. ‑‑Sarri.greek ^♫ I 15:14, 22 November 2024 (UTC)

@Sarri.greek: You seem to speak favourably of the unified inflection table styles used by the French, German, and Greek Wiktionaries. Do I interpret you correctly? Does that mean you'd be in favour of harmonising the styles of the Ancient Greek and Modern Greek inflection tables here on the English Wiktionary? Also, I had not heard of the word ideoleptic before, so needed to look it up, but the NED has no entry. It seems to be very rare; I could only find one use of it on Google Books. I have quoted that use at Citations:ideoleptic; is that the sense in which you meant the word? And is there a Greek ἰδεοληπτικός (ideolēptikós) from which you derived it? 0DF (talk) 22:56, 22 November 2024 (UTC)

@0DF:, _sorry for the 'greekism' ideo- + -leptic (obsessive is the word I should have used), (also ideo -lepsy), new compounds, not ancient. ιδεοληπτικός mostly in ModGr. _Standardising or unifying or harmonising... The story of infl.tables: back in 2000s an editor would know how to make easy-tables for his/her language. These were copypasted heavily, here and interwikily. Now, programmers tell us that things have changed. There are 3 things. Updates that are invisible to the reader (the output is the same). Updates that include radical visual changes. Lastly, updates that are difficult for editors to handle. New master.tables should be initially proposed. Then, the ultimate best view for each language, taking in accound the past tradition of its tables. But all this needs sessions with the directors of languages (en.wikt does not have directors of specific tasks/langs). The only specialty I know of, is interface administrator. ‑‑Sarri.greek ^♫ I 06:58, 23 November 2024 (UTC)

@Sarri.greek: No need to apologise for the “Greekism”; it was interesting. Re harmonising, let me put it this way: How would you feel about Modern Greek tables using the appearance of Ancient Greek tables? Or vice versa? 0DF (talk) 08:57, 24 November 2024 (UTC)

@Sarri.greek thank you for this considered and detailed response. You have made a lot of points here, many good, some I would need to think about for longer. I should say, in particular, that I would like to hope that I have not been seen to offend or mock any individual or group, or the hard work put in by any editor to this wiki. We are all seeking, in our various different ways, to advance the dictionary project.

In response to your point "Could someone design a super-table example of a best-view as help to copypaste from?" This is partly my intention with {{inflection-table-top}}. I say "partly" because it is not a resource intended to be copied and pasted from. However, it is a wrapper template that, when used as part of inflection table templates, is intended to be an example of best practice (although some may dispute that it achieves that intent!), in order that individuals do not need to muck around with the fine points of CSS styling to achieve an acceptable-looking inflection table.

When it comes to colours, Surjection has helped us by providing a range of colours that can be used in both light and dark modes (MediaWiki:Gadget-Palette/table). There is a type of blue offered here. If the particular shade of colour used in the template needs to be fine-tuned, further colours can be added (perhaps to the inflection table CSS, not to the global palette).

As for transliteration, I initially had the same thought as you, namely, that we need a new template that displays a terms' transliteration beneath it rather than beside it. Something like {{l-stacked}} or {{l-vertical}} as you say. However, as I considered this some more, it occurred to me that the main, if not the only, place where this style of display is called for is in an inflection table. The {{inflection-table-top}} template is able to "impose" this stacked format on all {{l}} templates contained within it, and this is now in effect in Greek adjective templates such as at κατσαρομάλλης (katsaromállis).

I would like you opinion on something, if I may ask. When there are two possibilities for a single inflection, would it be better to see

κατσαρομάλλα
katsaromálla
κατσαρομαλλούσα
katsaromalloúsa

or

κατσαρομάλλα /
κατσαρομαλλούσα
katsaromálla /
katsaromalloúsa

? Or do you like/dislike each format equally? There is a third form, of course, namely

κατσαρομάλλα / κατσαρομαλλούσα
katsaromálla / katsaromalloúsa

but this cannot really be used, as it would create difficulties with tables becoming too wide.

Thank you, This, that and the other (talk) 12:10, 23 November 2024 (UTC)

@This, that and the other:, you are very polite, and my PS above was about a general situation, in case bureaucrats read, like M Benwing, who follow Greek issues.

But your changes of 2024.11.22 on templates was so sudden, drastic and unexpected. These templates might be updated anyway some day, but differently. The tooltip for Greek transliterations with the template {{el-link-ttip}} discussed here is very helpful. Who wants a tr= for a hundredth time? Tooltips are also used for the grammatical terms. The English term is visible, the tooltip explains if needed, plus gives the term at the target language. e.g. Check the little arrows at παίζω#Conjugation. At el.wikt terms such titles are translated like at wikt:el:Template:ενικός.

table-top {{inflection-table-top}} is for the Hide/Show function, I guess, if the editor does not have one already. The {{inflection-table-bottom}}, which has only the closing |} things, never the param |notes= which mayyy be used already by the infl.template.

Mobile perhaps has to be considered separately: but I do not think that a verb's table can fit in a mobile, whatever way. Best view = desktop view. cf παίζω both langs. The French wiktionary puts them at separated pages. They are SO big. jouer (Vector2022 is not suitable)

Dark mode does not step IN the table at all, unless the creators of the infl templates chose to switch. I hope background=#ffffff protects the territory of infl.tables from switching?.

You ask about applications that are very specific to a language (Modern Greek) and a PoS (adjective) and a lemma κατσαρομάλλης (/⁠katsaromális⁠/) Why? Sorry, I cannot find where el-adj templates begin; I would need a month to discuss adjective templates with my admin. Obviously, preferably every word has tr and ts and t under it. eg ξανθομάλλης (xanthomállis) looks so cluttered! Could you show us both styles, previous and yours? And what about verbs?

Some of my tests when we were wikt:el:Template:table-test/1 choosing among colour.styles wikt:el:Template:table-test. Also, we discarded font variation. Because they come in slightly different sizes. We need good clear fixed sizes! Readers can zoom out if they want. Here at en.wikt, much more complicated with tr and ts at User:Sarri.greek/template4 and base+ending system with tlse & lse An instructions.master.table... a draft needed for editors to copypaste from and create infl templates with a note: what is in Common.css already. Thank you ‑‑Sarri.greek ^♫ I 17:31, 23 November 2024 (UTC)

@Sarri.greek To ensure dark mode compatibility, if you set the background, you also have to set the color (text colour). (This is the problem with the untouched, original templates - the text becomes white but the background is also very close to white, rendering them unreadable.) But if this is all you do, the table will appear "bright", even in dark mode, which is as distracting to dark-mode users as it would be if a black-background table appeared in the middle of an entry for a light-mode user. So you then have to use paletted colours, like background: var(--wikt-palette-blue-4) (MediaWiki:Gadget-Palette/table). {{inflection-table-top}} comes with this pre-baked, but of course you can incorporate this styling into pre-existing inflection tables if you wish.

As for my question to you, yes, I have posed it in the context of a specific example, but consider that it applies to any situation where a particular inflection of an adjective has two or more forms available. I'm still keen to hear which style you prefer.

And I am not touching the verb templates at this time! Too complex. This, that and the other (talk) 07:08, 26 November 2024 (UTC)

I am so sorry. Then, I will not do any tables. Thank you, M @This, that and the other ‑‑Sarri.greek ^♫ I 11:21, 26 November 2024 (UTC)

@This, that and the other Since @Sarri.greek hasn't weighed in on what looks best, my preference would be option number 1, where you show the transliteration after each variation. I find it easier to make the comparison that way and find it more visually appealing. But I'm happy to cede to anyone else's preference if they feel differently. Andrew Sheedy (talk) 06:07, 27 November 2024 (UTC)

Formatting of IPA in Pronunciation sections

(this discussion is following an exchange of diffs between me and @Sgconlaw) I wish to know how IPA transcriptions, and especially English IPA, should be formatted in the "Pronunciation" sections of entries. I have been following what seems most common in and outside English entries, however I want confirmation and consensus from others. I wish comments on the points below:

• broad and narrow transcriptions have syllable breaks between all syllables (disregarding English's weird hyphenation)
  • except before primary and secondary stress markers
• broad transcription for English follows the IPA key in the appendix and shouldn't contain more information. this includes:
  • tiebars for affricates (in languages where the distinction between afficates and plosive-fricative sequences doesn't exist)
  • rhotacisation using /ɹ/, not /ɚ, ɝ/
• all stressed words, including monosyllabic ones, should have a stress marker (in languages with lexical stress)
  • (this wasn't in the edits above, but I am throwing it in for discussion)

Juwan (talk) 13:01, 24 November 2024 (UTC)

As far as I am aware:

• We don't indicate syllable markers unless there is ambiguity or if required to ensure that {{IPA}} correctly indicates the number of syllables in the word.
• We indicate the consonant sound at the beginning of juice as /d͡ʒ/ and not /dʒ/. This is despite the fact that /d͡ʒ/ is not indicated at "Appendix:English pronunciation" (perhaps this should be changed), or in the titles of rhymes pages.
• We now use /əɹ/, not /ɚ/; and /ɜɹ/, not /ɝ/, as indicated at "Appendix:English pronunciation".
• We don't use stress markers for one-syllable entries, but do indicate if one-syllable words are stressed in entries that are multiword terms.

— Sgconlaw (talk) 13:11, 24 November 2024 (UTC)

Wait, when did we stop using /ɚ/? We were using it for years in entries. Was there a formal decision made? I do seem to recall some discussion, I just don't recall a decision. Andrew Sheedy (talk) 03:38, 25 November 2024 (UTC)

@Andrew Sheedy: there was a discussion on the talk page of that appendix, and it appears some consensus was reached among editors who regularly edit that page. (I did not take part in it.) Perhaps there should have been a wider discussion at a forum such as this page. — Sgconlaw (talk) 12:54, 26 November 2024 (UTC)

Oh, OK. I don't know enough about the finer points of phonetics/phonemics to agree or disagree, but I do find it hard to keep track of stuff like this, so hopefully there's some flexibility allowed. I'll try to abide by the decision so long as it stands. Andrew Sheedy (talk) 05:48, 27 November 2024 (UTC)

Inconsistency is basically inevitable anyway, so flexibility is not merely allowed, it's obligatory. —Mahāgaja · talk 09:28, 27 November 2024 (UTC)

For what it's worth, my own understanding is that there's no policy or consensus either mandating or forbidding syllable breaks (is there in fact one somewhere?); some people add them, some people remove them, and it's occasionally contentious. (Any unthinking mass removal would run into problematic edge cases as alluded to above; one class of edge case is New Zealand /i(ː)ə/ ear words vs two-syllable /i(ː).ə/.) I'm not sure there's a clear consensus for /ɚ/-not-/əɹ/ or for /əɹ/-not-/ɚ/, either, though it's been discussed before a few times; the appendix was changed in diff; here is one discussion, and another. Stress markers for one syllable entries have been discussed before too and I don't recall the outcome. - -sche (discuss) 07:11, 25 November 2024 (UTC)

Inflected verb forms for agglutinating languages

Is there any preference for how to define verb forms in agglutinating languages? (Not that I’m planning to create a gazillion, but some of them have idiomatic senses and I think it’s our policy to give the verb-form sense as well in that case.) Currently, a Swahili verb form like lililompeleka would be defined as

1. ji-ma class subject inflected singular relative m-wa class object inflected past of peleka

I think it’d be more informative to give the breakdown in morphemes:

1. li- (ji class_(V) subject) +‎ -li- (past tense) +‎ -lo- (ji class_(V) relative) +‎ -m- (m class_(I) object) +‎ -peleka (“to send”)

What are y’all’s thoughts? @Tbm as probably the most interested. MuDavid 栘𩿠 (talk) 03:02, 26 November 2024 (UTC)

I can't comment on Wiktionary policy but I agree your breakdown is much more informative! tbm (talk) 13:57, 26 November 2024 (UTC)

Yes, the first example falls squarely in the category of "technically correct but practically useless" - or at least, useless to all but a Swahili grammarian.

I'd still prefer to keep the form-of template with its boldface text:

1. form of peleka: li- (ji class_(V) subject) +‎ -li- (past tense) +‎ -lo- (ji class_(V) relative) +‎ -m- (m class_(I) object) +‎ -peleka (“to send”)

The other approach, of course, would be to place the breakdown in the Etymology section and keep the long string of grammatical terms on the sense line. This would be more in line with existing Wiktionary norms, but seems like a needlessly redundant way of presenting this information. I'd prefer this new approach. This, that and the other (talk) 23:15, 26 November 2024 (UTC)

Add the exclusion of political party names to CFI (proposal)

I suggest that we formally disallow the names of political parties on Wiktionary. We can add a bullet point noting this exclusion somewhere at WT:NSE.

Context: so, political parties are actually already de facto excluded from Wikt; nearly all recent political party names have failed at RfD, including Democratic Party and Republican Party (2011), Talk:Japan Socialist Party (2020), Talk:Arab Socialist Baath Party (2021), Talk:Transhumanist Party (2015 RfD-kept, 2023 RfD-deleted) and the ongoing RfD discussion for Communist Party of China is evidently leaning delete. A very short discussion for nine parties back in 2009 (see Talk:Liberal Democrats) yielded no consensus, but since then it seems that the majority of the community have decided that we do not need political party names on Wiktionary.

Most arguments against including them here include that they are more Wikipedia material (not dictionary-worthy per se, rather fit for an encyclopaedia) and SOP, though the latter applies only to non-proper nouns so admittedly that argument is somewhat flawed.

Since there has been a general consensus to exclude them for a few years and there are still ~40 such pages on Wikt right now, I think adding a specific policy excluding political party names would be appropriate and necessary so as to stop users from creating new entries for political parties. I mean, it would otherwise be super funny how Republican Party and Communist Party of China (arguably among the most powerful political parties in the world) are not allowed entries on Wiktionary but the small, satirical Official Monster Raving Loony Party de jure is.

This proposal would, of course, not apply to nicknames, clippings or abbreviations/initialisms.

(As a final note, with respect to RfD, I recommend that we do not immediately speedy-delete all political party entries; rather, they can all be nominated at RfD (individually or in bulk) with reference to this discussion and the hypothetical new policy at CFI, should it be implemented.) I would appreciate any arguments in favour of or against this proposal! Kindest regards, LunaEatsTuna (talk) 02:04, 27 November 2024 (UTC)

What is difference between political parties and business companies? I mean, in terms of inclusion. And what is a political party contra a political organization? Like, a hypotetical National Bolshevik Party of Eastern Udmurtistan having 1,5 members is not really a party, are they? So what the criterias for inclusion are have I never understood. Tollef Salemann (talk) 02:18, 27 November 2024 (UTC)

You make a valid point! WT:COMPANY already excludies business companies and, since political parties are not companies per se but most Wiktionarians feel that they should not be included on Wiktionary, I think making a specific exclusion for them too would be fitting. As for other political-ish organisations, like churches, armed forces, NGOs, militant organisations, airlines etc. I do plan on addressing them separately in other discussions here! I am just starting with the easiest (since most people already think parties should be excluded but not the others I mentioned). My plan is that hopefully we will be able to find consensus on why some should be included and others not, and the reasoning(s) why for each. :) LunaEatsTuna (talk) 02:35, 27 November 2024 (UTC)

• Mostly oppose: Entries that take the form "BLAH Party" probably need to go. Entries that are just "BLAH" without the party, but refer to a political party or members of same, probably need to STAY. Purplebackpack89 04:28, 27 November 2024 (UTC)

  I think the same about the churches as well. There is no reason to inlude names of all the thousands of American Evangelical churches, Ukrainian Orthodox churches, Siberian Old Rite communities, all the way to Norwegian Pagan school kid groups. Instead it is enough to just have entries about evangelism, orthodoxy, old ritualism, neo-paganism and so on - what we already have by the way. Tollef Salemann (talk) 12:00, 27 November 2024 (UTC)

Enable new-L2 tag for all

The new-L2 tag gets applied to an edit if a new level 2 ==Heading== is added in that edit to an existing page. This is at present disabled for edits from autopatrollers and admins, but I think it would be nice to have it enabled for all as it would be helpful in e.g. checking language specific recent changes, watchlist edits, etc. and maintain a record of new language entries added by a user (like new pages which can easily be viewed on the contributions page). – Svārtava (tɕ) 09:22, 27 November 2024 (UTC)