Hello, you have come here looking for the meaning of the word Wiktionary:Beer parlour/2024/October. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Beer parlour/2024/October, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Beer parlour/2024/October in singular and plural. Everything you need to know about the word Wiktionary:Beer parlour/2024/October you have here. The definition of the word Wiktionary:Beer parlour/2024/October will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Beer parlour/2024/October, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
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:
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
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
makes pages with multiple language editions annoying to read
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)
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)
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)
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)
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, 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)
The adj utter means extreme and used with words with negative connotation; the adj. sublime also means extreme/complete, but used for positive connotations.
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)
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)
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)
@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. (parla con me)10:30, 9 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. (parla con me)22:13, 19 October 2024 (UTC)
@IvanScrooge98I 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. (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)
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)
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.
@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)
@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 . 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.
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)
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)
@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)
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. --Lambiam20: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
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.
@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)
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 . So I don't know if this is actually a problem, or if Vin is not letting go of past history . 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)
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)
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)
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)
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 could've cleaned them up myself. kwami (talk) 19:15, 15 October 2024 (UTC)
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.
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-.
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)
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.
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".
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-"
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 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)
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 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 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:
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 [email protected] with any questions you may have.
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)
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.
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)
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.
@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.
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.)
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.
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.
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)
Hey, thanks for sharing this problem with us. It's definitely solvable. You should be able to see the Appearance menu on the right side of the screen. In it, there's a section "width" with two options to choose between. If your screen isn't wide enough, the Appearance menu is at the top, as a glasses icon. SGrabarczuk (WMF) (talk) 22:59, 17 December 2024 (UTC)
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)
(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)
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).
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)
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. – Perhaps, but that could also be attributed to people who have migrated to different areas of the Punjab. Else, the standard infinitive/stem of Punjabi verbs is –ṇā, and is common in Majha areas. Elena Bashir has also stated this (as well as other authors, which I will try to reference). Punjabi Textbooks also have this standard.
Especially since the -ānā form is not listed heavily in Shahmukhi (and by extent Gurmukhi) dictionaries – the only two Punjabi dictionaries from Pakistani we use is {{R:pa:Iqbal}} (Waddi Punjabi Lughat, The Grand Punjabi Dictionary) – which evidently is influenced by Western Punjabi, and the second one we have is {{R:pa:Bashir}} (Kanwal Bashir) which is based on Lahori Punjabi – and uses the same stem/infinitive.
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)
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.
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? —AryamanA(मुझसे बात करें • योगदान)01:37, 21 October 2024 (UTC)
This has already been discussed a few times. For a related discussion see
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.
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)
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
I hardly see a difference
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
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
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)
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.
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
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
redlinks, bluelinks etc ... all appear the same. on both wiktionary and wikipedia
no Prefs setting can override it. its only on the tablet
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
honestly i think he should have posted to the BP before doing this
AryamanA — Yesterday at 11:53 PM i see!
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
that is one of the things that should've been brought up to BP
affecting every language without discussion is exactly something that I've brought up as frustrating before
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.
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. ). 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)
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: @Benwing2AG202 (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)
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)
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.?
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)
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 and 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.
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.
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.
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: 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.
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)
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?
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? - Jberkel11: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♫I12: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?
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.
@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)
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)
@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 😊
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).
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)
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)
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.8521: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)
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)
@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)
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 " 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)
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
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.
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)
@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)
"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)
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)
I looked at the whole edit history involving the two of you. My comments are this:
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).
You made a bunch of formatting mistakes, which User:Theknightwho tried to clean up. You should be more careful about this in the future.
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 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.
> 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.
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);
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?
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.
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.
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)
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)
Not a big English editor, but Support making it an official policy. However, in order to do that, I think there is a need to reword/restructure the text somewhat. Case in point: I think the issue Saph668 pointed out with tests 9 and 10 isn’t due to the tests themselves being bad — they’re very pertinent! Of course a word that originated as an adjective should be listed as an adjective. Rather, it’s due to ambiguity with how to interpret the tests: how many tests does a term need to pass? The tests clearly weren’t designed to be “if and only if”. A term passing test 9 indicates it’s probably an adjective, but a term failing doesn’t really say much. We need to formalize a minimum number of tests passed or something. Polomo47 (talk) 00:05, 29 November 2024 (UTC)
Right, I knew that but forgot to mention it: that section is really confusing right now! Like, what's the difference between Necessary condition and Sufficient condition? We should see if everything there is just as we want it to be, or if there’s anything in need of restructuring. Polomo47 (talk) 03:32, 29 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.
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)
@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.
@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)
@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)
@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)
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.
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.
@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)
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)
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)
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)
Vector legacy (current default)
Vector 2022
Vector legacy (current default)
Vector 2022
