Wiktionary:Beer parlour/2024/May

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← April 2024 · May 2024 · June 2024 → · (current)

---

Arabic and Hebrew transliteration

Wiktionary currently transliterates the glottal stop in both Arabic and Hebrew as ʔ and the voiced pharyngeal fricative in both languages as ʕ. Would it be possible to correct these to respectively transliterate the glottal stop as ʾ and the voiced pharyngeal fricative as ʿ so they would be in line with Wiktionary's transliteration of other Semitic languages, which all use ʾ and ʿ?

Wiktionary also currently transliterates the Arabic voiceless velar fricative as ḵ. However, an alternate transliteration as ḫ is also used for this sound. Since ḫ is used for the transliteration of voiceless velar fricative for most Semitic languages except for Hebrew and Aramaic, I would like to request that Wiktionary's transliteration of the Arabic voiceless velar fricative be changed from ḵ to ḫ as well. Antiquistik (talk) 13:08, 1 May 2024 (UTC)

@Antiquistik: No, we switched the other day. As for ḵ to ḫ, I don’t know, perhaps it’s better if you want to make an etymological statement that ḵ is fricativized k which we keep in begadkefat affected languages while ḫ organic. Fay Freak (talk) 18:08, 1 May 2024 (UTC)

@Fay Freak In this case, I will add my opposition to the discussion regarding that change.

Concerning ḵ to ḫ, should I make another request, or should I add it to this one itself? Antiquistik (talk) 18:55, 1 May 2024 (UTC)

@Antiquistik IMO the opposite change should happen and other Semitic languages should use ʔ and ʕ. The problem with the forward and backward quotes is that they're too small and too easily confused in many fonts. I also think ḵ is better than ḫ; ḫ is easily confused with the pharyngeal fricative. Benwing2 (talk) 23:49, 1 May 2024 (UTC)

Personally, I agree with Benwing, although I am sympathetic to the idea that we should use whatever is most widely used, and I am also sensitive to the issue of words being findable by people who search for them using other transliteration systems. I would like us to implement having the templates/modules produce (but then potentially set to be invisible / display:none by default) other common transliterations so the entries can be found if people use our site search or Google and search for ʾiʿlān etc, as discussed in the 2022 discussion, unless that would cause problems. Then we could probably also set different CSS classes for the different transliterations so people could select whether they see ʾiʿlān or ʔiʕlān, similar to the way people can choose to see or not see {{,}} (and we could debate which one would be most helpful to have on by default for the average lay reader). - -sche (discuss) 02:33, 2 May 2024 (UTC)

@-sche I think this is a good idea. AFAICT it would require some changes to Module:languages (which handles transliteration) so that a given transliteration method can return multiple transliterations rather than just one, each transliteration associated with properties such as CSS class, with one of them identified as "canonical" (meaning it is displayed while the others aren't). The only tricky thing here is manual transliterations; ideally, there would be method to convert a manual transliteration in the canonical system into each of the other systems, so that users have to specify only one transliteration rather than multiple. In the examples here, that conversion isn't hard, but sometimes it may not be possible (e.g. the current Hebrew transliterations are based on modern Hebrew pronunciation, which has several mergers compared with Biblical Hebrew, so we couldn't convert modern to Biblical Hebrew transliterations). Benwing2 (talk) 02:45, 2 May 2024 (UTC)

@Benwing2: I believe that some of the existing manual transliteration entries may need to be reviewed in order to see whether their use was actually justified in the first place. Some of them are there only to workaround various technical issues, which ceased to exist. For example, this manually added transliteration for a Belarusian quotation became unnecessary after this fix. And I definitely support the idea of having multiple transliteration schemas, because this would allow introducing Belarusian Łacinka in addition to the current WT:BE TR scholary transliteration. As @-sche mentioned, the primary motivation is that words should be preferably searchable via Google or via the search box from the Wiktionary front page. Belarusian entries currently solve the searchability problem via manually added "Alternative forms" sections with red links, but this isn't ideal. So the proposed improvement has uses even beyond Arabic and Hebrew. --Ssvb (talk) 16:41, 2 May 2024 (UTC)

Yes, I'm also in favour of having multiple transliteration schemes for this reason. Theknightwho (talk) 11:44, 8 May 2024 (UTC)

@-sche This is a good proposal.

@Benwing2 I understand that ʔ and ʕ are more visible than the small half-rings, but I question how useful using them would be for the average reader since they are barely used in current transliteration schemes. If it hinders readers' ability to find these entries, we should avoid using them. Additionally, when is ḫ confused with the pharyngeal fricative? Antiquistik (talk) 05:42, 2 May 2024 (UTC)

@Antiquistik I'm not sure what you mean by "barely used in current transliteration schemes". Are you referring to transliteration schemes outside of Wiktionary? If so, why do you think the average reader will be familiar with them, but won't be familiar with IPA? As for using ḫ, my point is that this is easily confused with ḥ (the transliteration for pharnygeal fricative), and having all three of h ḫ ḥ is going to make for endless confusion. Benwing2 (talk) 05:47, 2 May 2024 (UTC)

@Benwing2 While I don't think that the average reader will be more familiar with the IPA signs, I doubt that they will be searching Arabic terms with signs from the current standard transliteration schemes substituted by IPA signs that are rarely used for Arabic transliteration.

And, as pointed out by @Ssvb, the entries need to be searchable. Using the more widely employed transliteration is the better option for this.

As for the transliteration of /x/, I strongly disagree with your position. The transliterations for other Afroasiatic languages like Old South Arabian, Ugaritic and Ancient Egyptian use both ḫ and ḥ without any problem, and I don't see why should the organic /x/ in Arabic be represented through a character used for sounds affected by begadkefat. Antiquistik (talk) 11:19, 3 May 2024 (UTC)

@Antiquistik: Your premise of the signs being but used in IPA transcriptions before having been adopted by Wiktionary is wrong. We realized that there are lots of linguistic books, more or less traditionally Semitist, with them as their editorial choice for transcription. I have doomsurfed the philologies enough in the last 1½ decade to know that this is by far not so uncommon as to be stunting someone’s dictionary use. I also want to raise your attention towards pertinent languages without native writing system that can only be entered in an academic transcription, the Modern South Arabian languages, which have suffered some variations in transcription styles over the decades and native countries of researchers but I think are amenable as written down at أَيْدَع (ʔaydaʕ), whereas with all their diacritics the rings would strain the readers’ tempers. Fay Freak (talk) 11:37, 3 May 2024 (UTC)

@Fay Freak How prevalent are Arabic transliterations using the IPA signs compared to the half-rings? Antiquistik (talk) 13:06, 3 May 2024 (UTC)

@Antiquistik: No one, or at least not me, can do stats on such thing. There’s is also a qualitative difference in the kinds of resources that use them. In purely Semitist sources due to tradition the rings hold their ground. I have clicked around in my Semitics folder for you. I wanted to say that Leonid Kogan uses MODIFIER LETTER GLOTTAL STOP ˀ a lot, which is a bit more conspicious and between the two extremes, but the second work by him I opened ({{R:tig:Kogan:2011}} after {{R:sem-pro:GC}}), goes the whole hog and uses ʔ for Arabic and the other Semitic languages. {{R:sqt:CSOL}} and {{R:sem-pro:SED}} uses ˀ, anything published in the Journal of Semitic Studies such as →DOI the rings, we may see it as a publisher decision, in more relaxed journal pieces he seems to prefer the IPA letters? In the old and long series Perspectives on Arabic linguistics you got the IPA letters all around. There is a lot of socialization behind letter choices, you just need to get used them, but not lose aesthetic sense. University docents may teach something specific but there is a point where one shan’t believe other people. Younglings learn and adults function by imitation but science by organized skepticism, a dilemma.

The complicated part: I can hold you a lecture how it is has to do with spatial-temporal memory, again the first chapter of the handbook of memory, ASD and the law I mentioned. Everything normal in the head, you guys tribally react to relations previously experienced with and from other people, in spite of the meatspace effecting the worst selection bias, contrary to universalism of science. You underestimate the psychological background behind all this. I did hardly positively respond to what teachers required or expected from me in terms of organizing a treatise, by some internal logics which aren’t strictly rationally evident, writing points of a paper in this and that order and not missing out a super-influential fashionable nonsense in the field I mean, which is detrimental to exams, and self-portrayal in job applications, however exquisitely able to judge the merits of the matter in isolation, and I am now very aware how strong feelings about signs come about, without sustaining them myself. We don’t just count voices together to let the loudest party win, this is not how creating good stuff works, only a working hypothesis. Fay Freak (talk) 14:09, 3 May 2024 (UTC)

@Fay Freak I would still suggest that we should use the most prevalent system, but given your explanation, I am willing to accept the present status quo while still maintaining my opposition in the original change proposal. Antiquistik (talk) 08:28, 26 May 2024 (UTC)

Descendant tree design

Here's my idea for a horizontal tree style that could be generated by {{etymon}}. I've switched up the colour scheme, since this is a descendants tree rather than an etymology tree. We can also include question marks or labels just as in the etymology tree. Let me know what you think! @Vininn126, Equinox, Sławobóg, -sche, 0DF Ioaxxere (talk) 21:24, 1 May 2024 (UTC)

How would you represent borrowings and morphological reshaping in this format? Also I think I prefer Design 2, because in Design 1 the single right-branching node might be interpreted as somehow different from the below-branching nodes (and in addition, in Design 1 someone might e.g. interpret the juncture where Proto-Italic branches off as its own node, a daughter of PIE rather than just an artifact of the design). However, even better than either IMO would be one where the parent is centered vertically among all of its children rather than being at the top. Benwing2 (talk) 02:55, 2 May 2024 (UTC)

@Benwing2: Probably with the same label system that {{etymon}} already uses. I like your idea for centering the node, although for trees with a huge number of lines it might lead to the ultimate ancestor being far down the page. Possibly the ultimate ancestor could be given some kind of special status where it always goes at the top left of the page. Ioaxxere (talk) 05:31, 2 May 2024 (UTC)

I think Design 2 is also my preference, at least on desktop. Vininn126 (talk) 13:25, 3 May 2024 (UTC)

Design 1

Proto-Indo-European *ph₂tḗr	Proto-Germanic *fadēr	Proto-West Germanic *fader	Old English fæder	Middle English fader	English father
					Scots faither
				English faeder
	Proto-Italic *patēr	Latin pater	Old French pere	Middle French pere	French père	English père
			English pater	Tok Pisin pater
	Proto-Celtic *ɸatīr	Old Irish athair	Manx ayr	English ayr

Design 2

Proto-Indo-European *ph₂tḗr	Proto-Germanic *fadēr	Proto-West Germanic *fader	Old English fæder	Middle English fader	English father
					Scots faither
				English faeder
	Proto-Italic *patēr	Latin pater	Old French pere	Middle French pere	French père	English père
			English pater	Tok Pisin pater
	Proto-Celtic *ɸatīr	Old Irish athair	Manx ayr	English ayr

Design 3

Proto-Indo-European *ph₂tḗr	Proto-Germanic *fadēr	Proto-West Germanic *fader	Old English fæder	Middle English fader	English father
					Scots faither
				English faeder
	Proto-Italic *patēr	Latin pater	Old French pere	Middle French pere	French père	English père
			English pater	Tok Pisin pater
	Proto-Celtic *ɸatīr	Old Irish athair	Manx ayr	English ayr

Design 4

Proto-Indo-European *ph₂tḗr	Proto-Germanic *fadēr	Proto-West Germanic *fader	Old English fæder	Middle English fader	English father
					Scots faither
				English faeder
	Proto-Italic *patēr	Latin pater	Old French pere	Middle French pere	French père	English père
			English pater	Tok Pisin pater
	Proto-Celtic *ɸatīr	Old Irish athair	Manx ayr	English ayr

Design 5

Proto-Indo-European *ph₂tḗr

Proto-Germanic *fadēr

Proto-West Germanic *fader

Old English fæder

Middle English fader

English father

Scots faither

English faeder

Proto-Italic *patēr

Latin pater

Old French pere

Middle French pere

French père

English père

English pater

Tok Pisin pater

Proto-Celtic *ɸatīr

Old Irish athair

Manx ayr

English ayr

At the risk of stating the obvious, only a small fraction of the descendants are being shown here. Is this focussed on English? Nicodene (talk) 21:49, 1 May 2024 (UTC)

@Nicodene: This is just a mockup. I created all the HTML by hand, but the full (automatically-generated) tree will have all the descendants. Ioaxxere (talk) 22:11, 1 May 2024 (UTC)

How would they all fit? Some of the ‘nodes’ have dozens of direct descendants. Nicodene (talk) 22:16, 1 May 2024 (UTC)

@Nicodene: The tree would be extremely tall in that case. Either way, it would still be significantly more readable than something like what we currently have at Reconstruction:Proto-Sino-Tibetan/s-la#Descendants. Ioaxxere (talk) 22:19, 1 May 2024 (UTC)

I have to agree with Nicodene. With etymology trees and the vertical format, it makes more sense to me because the tree will be much more compressed, but for descendants, I can't really see it working as well. It'll get really unwieldy and fast. The list you've pointed too isn't good either, but I don't like replacing one problem with another one. Looking at the link you've sent, how would this interact with etymology-only languages or the situation with Chinese? AG202 (talk) 03:06, 2 May 2024 (UTC)

Etymology-only languages shouldn't be too difficult to handle in general. For Chinese, I feel like including dozens of dialectal pronunciations in Reconstruction:Proto-Sino-Tibetan/s-la is excessive and we should reduce that to only those forms which were borrowed into other languages. It's also possible that descendants trees will end up having less automation than etymology trees in general. Ioaxxere (talk) 05:31, 2 May 2024 (UTC)

One thing that needs to be addressed is alternative forms. In Middle English, there are loads of them for everything. They can't always be ignored, because there are enough cases like catch and chase from Old French: chacier, chacer (chiefly Anglo-Norman), cachier (northern), flour and flower from Middle English: flour, fflour, fflowr, fleur, flor, floure, flower, flowr, flowre, flowyr, flur or even morrow and morn from Middle English: morwe, morewe, morowe, morow, morrou, morue, morw, morȝe, morewen, morowen, morȝen, morwen, morwyn, morwhen, morwoun, morun, moron, moryn, morn, morgen, marhen, mareȝen, morghen, moruwe, where different alternative forms have different descendants. Chuck Entz (talk) 18:31, 3 May 2024 (UTC)

Love it. After a quick glance at the HTML, is the only difference alignment? I think that since this could appear early on in a number of entries that have right-floating tables of contents, I think left-alignment makes the most sense to avoid some of the inevitable bunching. —Justin (koavf)❤T☮C☺M☯ 22:14, 1 May 2024 (UTC)

@Koavf: No, the difference is whether there are connectors on the bottom of the boxes. I have no idea why the alignment is different, actually... Ioaxxere (talk) 22:16, 1 May 2024 (UTC)

Ah, I see that now. —Justin (koavf)❤T☮C☺M☯ 22:17, 1 May 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Ioaxxere: Please excuse the lengthy delay in my response. I prefer design 4, with design 3 a close second for me. Thanks for asking. 0DF (talk) 17:11, 21 May 2024 (UTC)

get rid of noun and adjective plural form categories once and for all

There appears to be consensus established here, here and here, as well as in this diff, to not categorize noun and adjective non-lemma forms in separate 'noun plural forms' and 'adjective plural forms' categories. Yet when I made such a change for newly added Chadian Arabic terms, my favorite editor User:Fenakhay went on a revert spree. By longstanding consensus, we do not in general categorize non-lemma forms as e.g. Category:Russian noun prepositional case forms etc., so I don't see why an exception needs to be made for noun plural forms. However, I'd like to get clear consensus here to remove all such categories and delete the entries from Module:category tree/poscatboiler/data/non-lemma forms that allow such categories to be recognized. We have already done this for some languages; for example, there is intentionally no Category:English noun plural forms, and that page is protected against re-creation by bots or non-admins.

The alternative is to outline a clear rationale for why we need such categories and a rule for which situations they are allowed and which situations they aren't allowed. Either way, the current haphazard situation, where some languages have such categories and some don't, and the categories are incomplete, is unmaintainable.

Benwing2 (talk) 23:45, 1 May 2024 (UTC)

And a stronger consensus at Wiktionary:Requests for deletion/Others#Category:Adjective plural forms by language. It seems that Fenakhay is the only editor who supports the retention of these categories. Consensus is against them. This, that and the other (talk) 02:55, 2 May 2024 (UTC)

I support getting rid - trivial category intersections like this are a waste of time. Theknightwho (talk) 03:24, 2 May 2024 (UTC)

I don't see any rationale for this kind of category either and so am in favour of deleting them. Nicodene (talk) 14:13, 2 May 2024 (UTC)

I agree as well. Ioaxxere (talk) 17:57, 2 May 2024 (UTC)

Support deleting these. Ultimateria (talk) 17:21, 6 May 2024 (UTC)

If we have this kind of thing, it should be with a clear rationale for when/where and why (as Benwing says) and it should be added automatically, probably by whatever headword- or definition-line templates we're using to declare something as a noun plural form, paucal form, etc in the first place — I say this because as far as I saw in the prior RFDs, the categories were populated haphazardly and manually with handfuls of entries, which is not useful. The usefulness of categorizing non-lemma forms by their specific non-lemma-ness seems small (though not nonexistent) to me; I suppose if I wanted to know what kinds of endings Foobarian noun plural forms had, a category would be useful, but the array of endings which Foobarian noun plural forms have could alternatively be mentioned on the About Foobar page, or on the Foobarian equivalent of Appendix:English grammar. Can anyone articulate something these categories would be useful for? (Absent that, I have no objection to deleting them, and indeed voted to do so in some of the prior RFDs.) - -sche (discuss) 19:21, 2 May 2024 (UTC)

Personally, I find these categories very useful from a navigational standpoint, so I'd like to see them kept. That said, they should be added automatically as part of templates like {{infl of}} and {{plural of}}, not added manually by users. Binarystep (talk) 11:26, 5 May 2024 (UTC)

@Binarystep Do you realize this is simply an intersection category? In general we don't usually include intersection categories because you can search for any combination using the Search feature. In this case, e.g. to do the equivalent of CAT:Chadian Arabic noun plural forms, you can search for the combination of category CAT:Chadian Arabic noun forms and template Template:plural of. Adding them automatically using templates like {{infl of}} and {{plural of}} has already been tried, but it turns out to be difficult from a programmatic standpoint in some cases and a maintenance headache, which is the reason I want them removed. Benwing2 (talk) 20:02, 5 May 2024 (UTC)

template similar to Template:alt or Template:desc for Derived terms, Related terms, etc.?

Hi. User:Fay Freak and I have been having a discussion about using {{alt}} or {{desc}}, or a creating a similar template, for Derived terms and the like. This came up because Fay Freak has been using {{desc|nolb=1}} in Derived terms sections. (Note: |nolb=1 disables the language name at the beginning. FF proposes renaming |nolb= to |nolang= to avoid confusion with |lb= for labels and because what's being suppressed is a language name, not a label.) Both {{alt}} and {{desc}} let you specify a series of terms along with per-term properties plus overall labels for the whole set of terms, although the syntax of the two templates is different and {{desc}} has some extra features specific to descendants. Note that we also have {{syn}}, {{ant}}, etc. for inline synonyms/antonyms/etc., which likewise have support for specifying a series of terms with both per-term properties and overall labels. The current syntax for Derived terms, Related terms and such involves manually listing each term with {{l}} and using {{q}} to add qualifiers as needed, but compared with {{alt}} and {{desc}} this is both more cumbersome and less standardized, meaning that different people format things differently. I think we ought to have some way for Derived terms sections and the like of specifying a list of terms plus labels, similar to {{alt}} and {{desc}}. The question is, should we just reuse e.g. {{alt}} for this purpose, or create another template? (If the latter, I'd maybe call it {{terms}}.) Potentially we could rename {{alt}} to {{terms}} or something similarly generic and keep {{alt}} as an alias, since there isn't really anything about {{alt}} that is specific to Alternative forms.

I'm omitting mention of {{col3}} and the like; while these are useful especially for long lists of similar terms, they don't provide the ability to specify a set of labels at the end of the list of terms, as {{alt}} and {{desc}} do.

Benwing2 (talk) 05:22, 2 May 2024 (UTC)

That'd be quite nice. All I have to add is that it'd help to have the option to split derived terms into columns or put them in collapsible boxes, as people have been doing with a variety of other templates (cf. cado). Nicodene (talk) 14:01, 2 May 2024 (UTC)

I think we'd be able to scrape this to be honest. All it'd need is an etymology section for most terms... Vininn126 (talk) 16:20, 5 May 2024 (UTC)

@Vininn126 I don't quite understand what you mean, can you clarify? Benwing2 (talk) 20:03, 5 May 2024 (UTC)

Sorry, misinterpreted. Not sure I have a strong opinion. Vininn126 (talk) 07:17, 6 May 2024 (UTC)

I'm having trouble understanding the need for such a template beyond stringing multiple {{l}}s together. Can you give an example? I'm also confused by the association being made between Derived terms and Alternative forms. They're pretty distinct in my mind. -- Sokkjō 03:41, 11 May 2024 (UTC)

@Sokkjo User:Fay Freak gave the example in Sittenstrolch of using {{desc|de|Sittich|lb=prison slang|nolb=1}} under Derived terms in order to get the label functionality; it displays as

• Sittich — prison slang

You can get a somewhat similar effect using {{alt|de|Sittich||prison slang}}:

• Sittich (prison slang)

Here, only one term is listed but you can easily imagine listing multiple terms and multiple labels, which are supported in both syntaxes. Note that you couldn't so easily just use a qualifier because the labels autolink like {{lb}} labels, but don't categorize. I suppose you could write

* {{l|de|foo}}, {{l|de|bar}}, {{l|de|baz}} {{lb|de|prison slang|Austria|nocat=1}}

which displays as

• foo, bar, baz (prison slang, Austria)

much like writing

* {{alt|de|foo|bar|baz||prison slang|Austria}}

but as you can see, the former is much more awkward.

The reason I brought this up is that there's not a lot of functionality (and arguably no functionality) that's specific to {{alt}}; that's why I mentioned generalizing (or simply renaming) {{alt}} so it can be used outside of Alternative forms sections. Benwing2 (talk) 07:10, 11 May 2024 (UTC)

In the example Sittenstrolch, there is no reason a usage label would belong there -- that should be left to the entry page. If I saw a user add that, I would delete it. -- Sokkjō 07:27, 11 May 2024 (UTC)

Obviously not everyone agrees with you, because qualifiers and labels are extremely common in derived terms, synonyms and the like. I would tread lightly and think twice before deleting such a label. Benwing2 (talk) 08:39, 11 May 2024 (UTC)

What other users are putting usage labels in the derived terms section?! -- Sokkjō 05:07, 12 May 2024 (UTC)

It's useful if it's only a derived term in one particular (uncommon) sense, and you want to make that clear, but that's quite a rare scenario. Theknightwho (talk) 22:52, 19 May 2024 (UTC)

Being able to string together multiple {{l}}’s is all I ever wanted for Christmas. Nicodene (talk) 05:56, 12 May 2024 (UTC)

• As the bulk Derived terms adder, I use {{col-auto}}. I'm going through Wiktionary:Todo/compounds not linked to from components/2024-01/page 1 slowly and (mostly) surely. If anyone wants to help, or program a bot to do it, go ahead. P. Sovjunk (talk) 22:16, 19 May 2024 (UTC)

  Column templates, like {{col-auto}}, are often overkill, as seen here, and I do not support bot action. -- Sokkjō 05:01, 20 May 2024 (UTC)

  There's nothing detrimental about it, so I see no reason why it matters. Theknightwho (talk) 05:12, 20 May 2024 (UTC)

@Benwing2 Any chance it could be done using not {{alt}} – which was objected to above – but rather a clone of it named something like {{dt}} (for derived terms)? Nicodene (talk) 02:45, 6 June 2024 (UTC)

@Nicodene This could be done, although if we call it {{dt}} rather than e.g. {{terms}}, someone will soon find a use for it in ==Related terms== or other sections. Benwing2 (talk) 08:23, 6 June 2024 (UTC)

@Benwing2 {{terms}} sounds good to me. Nicodene (talk) 01:02, 7 June 2024 (UTC)

@Benwing2 Any chance we can go ahead with this? Sorry for the repeated ping. Nicodene (talk) 23:26, 20 June 2024 (UTC)

Myself, and I assume others, do not support this. -- Sokkjō 23:39, 20 June 2024 (UTC)

@Sokkjo I believe banning labels and qualifiers from derived or related terms sections would require community consensus since they are currently possible/allowed. For the record I'd support such a ban and tend to delete examples on sight. Nicodene (talk) 00:22, 21 June 2024 (UTC)

@Nicodene Victar doesn't seem to support any changes to anything; unless there are cogent objections from others I will go ahead and create the template in a few days. In any case, in general I don't believe merely creating a template requires a vote or even strong consensus; consensus should rather be about usage. Benwing2 (talk) 01:06, 21 June 2024 (UTC)

@Benwing2: Using a template other than {{l}} for Derived terms and Related terms is breaking with style guides and would absolutely require a consensus from the community. I'm honestly surprised you think it's OK just to take it upon yourself to make that change unilaterally. -- Sokkjō 01:14, 21 June 2024 (UTC)

First of all that's not what I said; you're putting words in my mouth. Second, what you say about Derived terms and Related terms sections isn't even true; people routinely use things like {{der3}}, {{col-auto}} etc. in those sections. Benwing2 (talk) 01:19, 21 June 2024 (UTC)

Phish, c'mon, those are column templates. That's a cheap argument fallacy. -- Sokkjō 02:09, 21 June 2024 (UTC)

Well unless they speak up, it doesn't really matter. We can also assume others who haven't spoken up here support it based on this. Vininn126 (talk) 08:15, 21 June 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'm not really understanding the rationale for yet another template. Why can't {{l}} be used? — Sgconlaw (talk) 02:28, 21 June 2024 (UTC)

@Sgconlaw Because

* {{l|en|A}}

* {{l|en|B}}

* {{l|en|C}}

* {{l|en|D}}

* {{l|en|E}}

* {{l|en|F}}

* {{l|en|G}}

is a PITA to write out compared to

* {{terms|en|A|B|C|D|E|F|G}}

Edit: and also the latter displays a nice compact

A, B, C, D, E, F, G

rather than something like

A

B

C

D

E

F

G

Nicodene (talk) 04:37, 21 June 2024 (UTC)

That’s why we have the column templates like {{col3}}. Not seeing a need for this, honestly. — Sgconlaw (talk) 04:56, 21 June 2024 (UTC)

And I'm not seeing a need for 58 templates for basically listing words. Nicodene (talk) 05:31, 21 June 2024 (UTC)

Yes the column templates are a huge mess and people keep creating more :( ... there's of course the existing WT:RFDO#remove lesser-used column templates topic from Dec 2022 that got partially done but is currently stalled. BTW {{terms}} is conceptually different in that it just makes it easier to list multiple terms on a single line, something that's already done a lot but awkwardly. Benwing2 (talk) 08:24, 21 June 2024 (UTC)

Just for the record, I'm also in favor of reducing the number of these and instead opting for a more versatile option. 08:25, 21 June 2024 (UTC) Vininn126 (talk) 08:25, 21 June 2024 (UTC)

@Nicodene: I guess if there are, say, five or fewer terms it is all right to list them horizontally separated by commas (though I am perfectly fine for them to be shown vertically in a bulleted list), but if there are any more than that it really makes much more sense to use the column templates. For example, I think it would be difficult to read a list of hyponyms like those at sengi all listed out in a single line.

Moreover, the problem with displaying terms in a single line using commas as separators is that alternative forms can't be conveniently together (e.g., "petshop, pet-shop, pet shop"), unless in these cases commas are used, and semicolons are used to separate terms which are not alternative forms. However, this would still be difficult to read. — Sgconlaw (talk) 21:02, 21 June 2024 (UTC)

Alternative forms shouldn't be displayed next to each other. Choose one of them and then list the other derived terms. Vininn126 (talk) 21:18, 21 June 2024 (UTC)

@Vininn126: I don’t have a strong feeling about whether multiple alternative forms should be listed or not (I guess it only makes sense to do so if there are a handful of them), but I’ve seen this being done in various entries. — Sgconlaw (talk) 21:29, 21 June 2024 (UTC)

{{terms}} will support semicolon separators (as well as tilde separators, which could be used to separate alternative forms, although I'm inclined to agree with User:Vininn126 that in most cases at least, esp. with trivial variations like pet shop vs. petshop vs. pet-shop, it's better to just list one of them). I agree that the hyponyms under sengi should be listed vertically. The advantage of listing things horizontally as well as vertically is it gives you a way of grouping more closely related items together horizontally while less closely related items can be listed vertically. For example, for Slavic languages, it is nice to be able to list an imperfective verb and its corresponding perfective(s) on the same line. Even with sengi, I see that black and rufous sengi and its synonym zanji sengi are listed on the same line, which IMO makes sense. Benwing2 (talk) 22:30, 21 June 2024 (UTC)

I don't object to the notion of columns/rows but rather to having so many different templates for something that can simply be handled by taking the code of {{alt}} and adding optional parameters like rows=X, columns=X, collapse=1. (Thoughts, @Benwing2?)

I don't see why one would put multiple altforms in a derived/related terms section instead of just the lemma. Nicodene (talk) 22:46, 21 June 2024 (UTC)

Yeah we could potentially have items on the same row separated by commas in a single argument and items in different rows in different arguments. Benwing2 (talk) 23:12, 21 June 2024 (UTC)

@Benwing2, Nicodene: if the intent is not to force all "Derived terms", etc., sections into a horizontal format but to use this new template in conjunction with a column format where it makes sense, then I guess that's OK. I would say that most of the time if there are more than five terms, a column format is to be preferred. By the way, it would be good if there was some way to add qualifiers using |q1= parameters or <q:...>. — Sgconlaw (talk) 05:15, 22 June 2024 (UTC)

@Sgconlaw There will be support for qualifiers in this fashion. Benwing2 (talk) 05:17, 22 June 2024 (UTC)

Plurals on head lines and declension tables

Is there any point in having both plurals on the head line and a declension table showing the plural for a noun lemma? I would be inclined to omit the plural(s) when there is a declension table. --RichardW57m (talk) 16:36, 2 May 2024 (UTC)

@RichardW57m it would perhaps help to specify which language you're thinking of and give an example. This, that and the other (talk) 03:07, 6 May 2024 (UTC)

The specific language where this has come up is Lithuanian, avìdė, which currently only displays the plural through the declension table. A similar specific is with the Lithuanian adjective headword template, where until recently many ordinals' neuter form was wrong and contradicted the following declension table. --RichardW57m (talk) 11:27, 7 May 2024 (UTC)

IMO it depends on how regular the inflections in question are. If they serve as something like principal parts, I think it's useful to put them on the headword line as well as in the declension table, because then someone with some familiarity with the language will know how to inflect the term without needing to look through the whole declension table to figure out what the most important parts are. This is similar to how we list the past historic and past participle for Italian verbs. OTOH if they are largely predictable, putting them in the headword line is less useful. Benwing2 (talk) 23:27, 8 May 2024 (UTC)

As Benwing suggested, I would say the answer is language-specific. For example, in German, plurals seem to be the most unpredictable declined form of a noun, so it makes some sense to give the plural in the head line.--Urszag (talk) 22:38, 9 May 2024 (UTC)

A way to more easily connect with readers: a follow-up

Following Wiktionary:Beer_parlour/2024/March#A_way_to_more_easily_connect_with_readers, I wrote to WMF in an attempt to figure out how to best resolve this issue. @Johan Jönsson replied and has given us an option, I think. He suggests we create a new mailing list for admins and for us to put enwiktionary in the name somehow. What do people think of this solution? Vininn126 (talk) 16:03, 3 May 2024 (UTC)

Support Ioaxxere (talk) 16:56, 3 May 2024 (UTC)

Support This, that and the other (talk) 08:30, 5 May 2024 (UTC)

Support Binarystep (talk) 12:45, 5 May 2024 (UTC)

Support Thadh (talk) 11:09, 6 May 2024 (UTC)

Okay, I'm going to move forward with this. See phabricator:/T364731. Vininn126 (talk) 10:38, 13 May 2024 (UTC)

Update, we have a private mailing list for admins (please open phabricator thread for details). Any active admins may sign up. Ladsgroup mentioned we may also open a public general use mailing list if we want. I'll leave that discussion for another time. Vininn126 (talk) 07:20, 14 May 2024 (UTC)

Volga Türki language

Greetings, I'd like to propose giving Volga Türki an L2.

It is a significant member of the Middle Turkic literary languages, and is as important as Ottoman Turkish, Chagatai and Karakhanid, all of which already have their own Wiktionary categories: Category:Ottoman Turkish language, Category:Chagatai language, Category:Karakhanid language. Volga Türki is considered a descendant of Karakhanid, together with Chagatai, however they all are roughly contemporary.

It was in wide use in the Volga-Ural region from 15th century (if including Qissa-i Yosof poem by Qul Ghali, then from 12th century) until adoption of Cyrillic and Latin scripts for Tatar and Bashkir languages under Soviet rule. Even though before Soviet rule, at late 18th-early 19th century the written languages for Tatar and Bashkir started to slightly diverge from Volga Türki, it remained a common standard for international affairs, especially between other Turkic groups.

Its addition would not only help with etymological sections, but also help connect the cognates with other Turkic languages, similarly to other Middle Turkic literary languages' sections.

As for Unicode characters, numerals and readings, I already have prepared all of this, and will work on adding them as soon as the category is created. The sources of lemmas are going to be taken from books, dictionaries and other written resources from that time period. I will try to list a source for each lemma whenever possible.

The only issue, however, is that the language does not have its own ISO 639-2 code yet. I propose one of the following codes to be used for the language: iut (for İdil-Ural Turkic); tui (Turkic of İdil-Ural). I deprecate codes like vut (Volga-Ural Turkic) and ott (Old Tatar) firstly due to the name Volga not being used by the locals, especially during the era of Volga Türki, and secondly due to the name Volga/İdil/İdel Türki being neutral, and Old Tatar primarily referring to the diverged variant of Volga Türki that was used specifically for Tatar. Bababashqort (talk) 16:06, 3 May 2024 (UTC)

What is the Volga Turki corpus and how accessible is it? Qissa-i Yosof poem by Qul Ghali should definitely not be included, as it is covered by Khorezmian Turkic [1]. Allahverdi Verdizade (talk) 20:40, 3 May 2024 (UTC)

Support BurakD53 (talk) 17:57, 4 May 2024 (UTC)

Its corpus mostly isn't digitalised, but practically all Bashkir and Tatar literature from at least 16th century until late 19th century is written in Volga Türki. The books, manuscripts and magazines are still preserved in a lot of libraries in Tatarstan and Bashkortostan. As for Qissa-i Yusuf, that is somewhat debatable, but given the timeframe it probably suits Khorezmian, as one of the ancestors of Volga Türki. Bababashqort (talk) 07:24, 5 May 2024 (UTC)

@Bababashqort: for the last issue, we generally make up our own codes using the code for the group it belongs to (probably "trk") followed by a hyphen ("-") followed by some sequence of letters that's not already in use by us. That way there's no chance of our code conflicting with an ISO code. Since this is strictly for internal use and our modules and css/jss code convert everything for browsers, we don't have to use existing ISO codes. Chuck Entz (talk) 18:24, 4 May 2024 (UTC)

Yes, I've been told that wiki uses a placeholder, but didn't exactly know how it worked. Thank you for explaining!

In this case I'd suggest trk-iut Bababashqort (talk) 07:25, 5 May 2024 (UTC)

@Bababashqort We try to use the first three letters of the lect in the second part of names like this. What do you think of trk-idi or trk-vol? Benwing2 (talk) 08:04, 5 May 2024 (UTC)

trk-idi includes only the Volga part, as well as trk-vol. The name itself, however, is taken from the most widespread naming of the language, which unfortunately is shortened to Volga Türki, omitting Ural. And speaking of İdil, it is actually spelled as İdel in Tatar itself, İdil is just more Common Turkic. Therefore the only solution seems to be trk-iut, it's not that hard to deduce I think. Bababashqort (talk) 11:54, 5 May 2024 (UTC)

@Allahverdi Verdizade suggested to make a Turki category instead, which I'd very much prefer. It would remove the need to add more distinct subvariants of it, such as North Caucasian Turki, Nogay Turki and others. This would also allow to use derivation template for all languages that used it: Crimean Tatar, Kumyk, Nogay, Bashkir and others. Bababashqort (talk) 13:21, 5 May 2024 (UTC)

@Bababashqort Sure, that works. What language is this a category of? Benwing2 (talk) 19:56, 5 May 2024 (UTC)

I think he meant he wants Türki as a language code, not specifically Volga Türki Bortkastningskonto (talk) 07:01, 6 May 2024 (UTC)

@Bortkastningskonto @Bababashqort OK, I need more information then. Is "Türki" supposed to be an L2 language? This is an awfully generic name for a language, and I would likely oppose this name for this reason. And I will repeat my assertion that the code for Volga Türki should be 'trk-vol' in keeping with the name. The code should reflect the first three letters of the lect name barring extraordinary circumstances (usually due to ambiguity when there are multiple lects sharing the first three letters, which is not an issue here). @Allahverdi Verdizade can you weigh in here? I am not qualified enough to tell whether this should be an L2 language, an etym-only language or just a label of some other language (the last two being rather similar). Benwing2 (talk) 07:11, 6 May 2024 (UTC)

I didn't actually suggest making Türki a L2, rather I wondered whether it wouldn't be better to do so depending on how different Volga Türki is from, say, North Caucasian Türki. I can't answer that question myself, and I think, in general, very few people can give a well-informed opinion on that. Reading this book on North Caucasian Turki (in Russian) might help a little. Considering that Bababashqort is likely only going to work with sources written in the Volga variety, maybe it is the safest to create a Volga Turki L2, in which case you would circumvent the problem with "awfully generic name". Documents in North Caucasian Turki are terribly inaccessible (not digitized or normalized), so I don't think anyone is going to work with them.

In any case, there is also the problem of classifying "literary languages" and fitting them into genealogical tree schemes. It is often said that this or that language "is moslty X, but also incorporates elements of Y", at the same time as it "continues the literary tradition of Z". I can't exactly tell you what it means that "Volga Turki continues the tradition of Khorezmian Turki", which in turn "continues the tradition of Karakhanid", as it oftentimes is put in Russian books on the matter. Too much arbitrariness for my taste. So my opinion is that these "literary languages" maybe should not have ancestors and descendants. Allahverdi Verdizade (talk) 17:35, 7 May 2024 (UTC)

Support Yorınçga573 (talk) 20:23, 9 May 2024 (UTC)

Request for a new language

Yet again, I request for Old Lombard to be listed separately, as for now Old Lombard is listed as a dialect and not a language. That Northern Irish Historian (talk) 17:30, 4 May 2024 (UTC)

I notice that Old Italian is currently an etym-only variant of Italian. Why can't Old Lombard be the same? How different are Lombard and Old Lombard? Benwing2 (talk) 18:59, 4 May 2024 (UTC)

Old Lombard:

• Faremo preg a Deo a Questi cominzament
• et a la soa mather ke preg l’omnipotent.
• Ke n’des a dir et a far tute l so placiment
• Ço ked is la scritura si se conven a dir
• De la pasin de Christ a ki ne plas hodir
• La qual per nu katif je plase sostegnir
• Bene questi paroli de panzer e da stremir
• Qui longa fis e dis del pasio del fy de la rayna.
• La qual si m’dia gratia et a mi sia vesina
• Ke parlo dritament de la pasion divina
• St’apreso si me scampo da la infernal pena.

Modern Lombard:

• Ambiaróm con ‘na preghiéra a Dio
• e a sò madèr che la préghes l’Onipotent
• Che nómes a dì e a fa töt de so gradimènt
• E per bontà sò el vègnes a compimènt
• Chèl che la dis la Scritüra isé come l’è giöst a dìl
• De la pasiù de Cristo a chi che öl sintìl
• Pasiù che per notèr pecadùr la sèrf a soportà
• Con rasegnasiù chèste parole de pianzer e dè dulùr
• Ché se parla e se dìs del fiöl de la regina
• Che la me dàghes gràsia e la me stàghes vizìna
• ‘Ntat che parle drit de la pasiù divina
• Semài che scamparó de la pena infernal.

That Northern Irish Historian (talk) 22:35, 8 May 2024 (UTC)

@That Northern Irish Historian That's not what I was looking for; you have pasted in two different translations which naturally will be different. If you try to match up the corresponding words, they are IMO marginally different enough to maybe be considered different L2's (although they differ less e.g. than the current Occitan dialects). I notice however that there are 0 lemmas currently listed as Old Lombard; are you actually planning on adding some? Benwing2 (talk) 23:16, 8 May 2024 (UTC)

Yes, but see zinqui, Jesu, and other pages. It is not working. That Northern Irish Historian (talk) 23:24, 8 May 2024 (UTC)

Words attested as Oghuz in DLT (Wiktionary:Beer parlour/2023/January#Oghuz language again (continuation of Wiktionary:Beer parlour/2022/December#Oghuz language))

That's how we enter these words. If you have any objections, please write here. BurakD53 (talk) 14:29, 5 May 2024 (UTC) words

lol. Yes, I have objections. Allahverdi Verdizade (talk) 16:11, 5 May 2024 (UTC)

As I said before, I want the {{trk-ogz-pro}} code to be removed and replaced with {{trk-ogz}}. Since we have already reconstructed them all under the {{trk-pro}} pages, Proto-Oghuz is quite unnecessary. If anyone still wants to reconstruct Proto-Oghuz, you can reconstruct it using the * sign on the Oghuz page. (Which is quite unnecessary) Likewise, {{trk-klj}} can also refer to the Arghu language, but the data in this language consists of a few words. {{trk-ogz}} is the direct ancestor of all Oghuz languages, in short, it is the same as Proto-Oghuz {{trk-ogz-pro}}. However, we cannot enter these Oghuz or Proto Oghuz words recorded in the Diwan into the site as entries. It requires reconstruction in order to be entered to us. However, these Proto Oghuz words, also Proto Khalaj words, are not a reconstruction. I think that both of them should be entered as input on the site, the biggest reason is that these languages cannot be assumed to be dialects of other languages. But since the Arghu language consists of only a few words, it can be entered under the name Proto. Oghuz language is mentioned many times in the Diwan and even information about its grammar is given. A few Proto Khalaj, i.e. Arghu, words may be added as exceptions. But since this is the case for Oghuz, there is no need to create a language code called Proto-Oghuz. This is my opinion. I firmly reject the addition of these Oghuz words to Old Anatolian Turkish. Not every word mentioned in the Diwan has been witnessed in Old Anatolian Turkish, and the place where Kashgarî shows the Oghuzs on the map in the period he mentions is not Iran, but Central Asia. Also the words here are more archaic than the form in which they are found in Old Anatolian Turkish. BurakD53 (talk) 18:22, 5 May 2024 (UTC)

Support Yorınçga573 (talk) 20:10, 9 May 2024 (UTC)

Lemma categories

Discussion moved from WT:Beer parlour/2024/April#Lemma categories.

I've been cleaning up Special:UncategorizedPages, and I've run across a number where @Nicodene has disabled categorization for alternative forms. My understanding is that all mainspace entries should be in either Category:[Language] lemmas or Category:[Language] non-lemma forms. While an alternative form is supposed to be a stub that links to the main form, as far as the categories are concerned, it's a lemma. It's certainly not a non-lemma form, because it has its own non-lemma forms. Leaving it out of both categories raises the question of why we have the entry at all, if we feel we need to hide it: if we don't link to it in the main entry, there's no way to navigate to it.

This has come up before over the years, and we've more than once decided to do it this way. As far as I can tell, Nicodene is the only editor who's doing otherwise. Has anything changed? Chuck Entz (talk) 03:13, 6 May 2024 (UTC)

Why should Category:Franco-Provençal lemmas be clogged with twelve different renditions of ôtro, seventeen of ôtrament, and ten of solament? Why should Category:Old French lemmas (not to mention Category:Old French adverbs) be clogged with two hundred seventy one renditions of iluec? The whole point of a lemma is to provide a citation form to cover the variants. That is how altforms and altspellings are handled by the vast majority of dictionaries. Nicodene (talk) 03:23, 6 May 2024 (UTC)

I'm of two minds here. Yes, we generally include alternative spellings and forms as lemmas; otherwise, for example, we'd end up including only one of oxidi{s,z}e as a lemma, and the other would go nowhere. At the same time, however, including 171 alt variants of iluec seems like serious overkill. Maybe we need a separate policy for non-standardized languages vs. standardized ones. Benwing2 (talk) 07:16, 6 May 2024 (UTC)

At a minimum, every entry should be in some category. As far as how that's been accomplished up to now, my understanding matches Chuck's, that every entry is supposed to be categorized as either a lemma or a nonlemma (or both) and that alternatively-spelled nouns are still nouns (and lemmas, from the category / grammatical perspective). We could change that, e.g. add a parameter which, instead of turning categorization off, moves the entries from "Category:Foobarian nouns" to at least a POS-agnostic catchall "Category:Foobarian alternative forms and spellings", or something more specific like "Category:Foobarian alternative forms and spellings of nouns", "Category:Foobarian alternative forms and spellings of lemmas", but I do think we should continue to regard a completely uncategorized entry—an entry that cannot be accessed from any part of our category tree—as a problem.
There was support for not putting just any alternative spelling into topical categories in this 2022 discussion, but that didn't leave the entries categoryless.
FWIW, the issue of terms having tons of spellings isn't strictly limited to overall-nonstandardized languages, e.g. English has lots of spellings of kinnikinnick, Muhammad, voivode... but I think Benwing's suggestion of handling this on a per-language basis (and just accepting that the English categories will have a few cases like Muhammad where there are a bunch of spellings) is probably more workable than e.g. trying to decide (in a way that can be maintained over time with any consistency) on a per-spelling basis what counts, in a mostly-standardized (but standards-body-less "ungoverned") language like English, as a "standard" spelling. (E.g., several of the alternative spellings of Muhammad are used mainly in scholarly works, so dismissing them as nonstandard seems hard; and in the other direction, for a largely dialectal word, determining why any one spelling should be considered more standard than another seems hard.) - -sche (discuss) 13:54, 6 May 2024 (UTC)

We could change that, e.g. add a parameter which, instead of turning categorization off, moves the entries from "Category:Foobarian nouns" to at least a POS-agnostic catchall "Category:Foobarian alternative forms and spellings"

I would be quite happy to use that if it were available as an option.

My main concern is keeping the categories clear and usable. When I look up 'Foobarian feminine nouns', for instance, I'd rather not have to wade through 5–10 (+) duplicates for every distinct noun. That is a serious headache with languages like Franco-Provençal or Romansch. Nicodene (talk) 07:54, 7 May 2024 (UTC)

@-sche: I would like this to be implemented for English as well. Having full-fledged entries for minor spelling variants was a bad idea. Ioaxxere (talk) 03:08, 10 May 2024 (UTC)

I disagree. All words should be given equal status, at least when it comes to categorization. I don't think Wiktionary should be treating variant spellings as inferior forms of the main entries. For starters, every spelling is (or was) the "default" spelling to someone. Using the example of Muhammad, for instance, there are plenty of people named Mohamad, Mohamed, Mohammad, Muhamad, Muhammet, etc. and it seems weird to claim that their names are merely lesser variants of the single "canonical" spelling. There's also the fact that some spellings carry unique etymological information, have slightly different pronunciations, or are used primarily by certain groups (regional spellings, for instance, or spellings used primarily by non-native speakers). Frankly, I find it troubling that there have been so many recent attempts lately to get us to reduce our coverage rather than expand it. At this rate, I won't be surprised if someone starts a proposal to convert alternate spellings into hard redirects. Binarystep (talk) 19:20, 11 May 2024 (UTC)

Edit with "username removed"

This edit has the user name removed. How can one see (if not who the user is), which user removed it and why? [2] Equinox ◑ 09:33, 6 May 2024 (UTC)

I removed it because it was an accidental IP/logged-out edit by an editor (the same as did a similar change to unrapable). — SURJECTION ^{/ T / C / L /} 10:17, 6 May 2024 (UTC)

I'm officially saying: don't do that. You can revert, delete, but do not wipe content unless it's real serious stuff like child porn. Thank you. Equinox ◑ 23:01, 7 May 2024 (UTC)

Re how to see which admin performed the revdel: it's technically in the "View logs for this page" link on the edit history page, [3]. If there were a lot of revdels and they did not follow so closely after the time the edits themselves were made, e.g. if I now went to the page and hid a revision from two months ago, and then Surjection hid a revision from one month ago as well as your edit just now, it might be hard for non-admins [who don't have "diff" links] to discern from that log who hid which thing... I guess in that case they'd just have to say "hey, who revdel'd X" and admins could check.) - -sche (discuss) 14:28, 6 May 2024 (UTC)

@Surjection: I want you to understand how it looked to me: I saw that someone had made an edit, they had no name, I couldn't see them, or talk to them, or discuss, it was like a GHOST DID IT. And I couldn't see who removed their name either. If you ever spent time on WP:OFFICE then ...well. Equinox ◑ 22:50, 7 May 2024 (UTC)

I would, personally, be happy to see text like "edit made by a user whose name is hidden by this admin: Surjection". What I think is wrong and bad and goes against our free openness is just that MYSTERY NO-NAME. Equinox ◑ 22:51, 7 May 2024 (UTC)

Side point: I know Chuck Entz (for example) likes to "clean the graffiti wall" so that vandals can't see their names. But I don't like that. The wiki should be a public space and we should only hide the history in real serious situations like "doxxing" (real name-addresses) or... am I wrong? @-sche @Chuck Entz @Surjection (and even worse, are there Wikipedia rules we are supposed to obey as children.) Equinox ◑ 22:55, 7 May 2024 (UTC)

AFAIK it's global WMF policy to suppress this kind of thing (the IP addresses of users who've accidentally edited logged out), and indeed to suppress it way harder than a mere revision-deletion like Surjection did: "oversighters" have (or had?) database access to delete the information so hard that not even admins can see it. (But it also takes time to contact them, so it's fine for admins to revdel it in the meantime, like this.) This is precisely because of doxxing concerns, because many IP addresses identify the person's real address. (Other IP addresses, of course, merely send you to that one farm in Kansas.) If you ever see an edit where you think the content of the edit is wrong, just undo the edit... as you saw in this case, the username being suppressed doesn't prevent you from undoing the edit. - -sche (discuss) 01:39, 8 May 2024 (UTC)

Would there be an issue if contributors were to hide their IP address with their screen names after, say, a week? CitationsFreak (talk) 03:46, 8 May 2024 (UTC)

I should clarify that AFAIK such hiding only happens when someone requests it—usually the person who made the edit, though plausibly someone else who simply noticed what was going on. Last I heard, WMF folks were trying to roll out something that automatically obfuscates all IP addresses by making them show up in edit histories as e.g. incrementing numbers that change periodically or on request (so anytime someone thinks their current [non-]IP is getting too much attention from admins, they can hit "refresh" and start doing vandalism under a new identity, just like logged-in users can by creating multiple accounts), which will probably remove the need to do this in the future, if it gets implemented. - -sche (discuss) 05:12, 8 May 2024 (UTC)

Would there be an issue if contributors could request that their IP address be hidden by their screen name? CitationsFreak (talk) 05:42, 8 May 2024 (UTC)

Tangent: Is there a way to "claim" an edit you made while accidentally logged out? Caoimhin ceallach (talk) 21:51, 12 May 2024 (UTC)

The issue of Old Kashubian (Old Pomeranian?)

I came to a recent realization about the {{R:zlw-opl:SPJSP|Old Polish dictionary}}: it contains texts from Pomerania with Pomeranian features, as it was made during a time when Kashubian was considered a dialect of Polish. However, typologically, this is very, very wrong. Pomeranian is considered North Lechitic, and anything "Polish" and (Masovian, Upper Polish, Lower Polish, and Silesian) are considered East Lechitic, therefor anything Old Kashubian should not be considered Old Polish. I propose a split; I intend to add the location of creation for any Old Polish documents anyway for a future dialectal project (for Old Polish this means categorizing somehow location of attestation by dialect) and separating any texts from Pomerania for "Old Pomeranian" with a code zlw-opm, or perhaps "Old Kashubian" zlw-ocb with Kashubian and Slovincian as the children. These codes seem clunky to me and I am open to others. I have also corroborated this by emailing the editors of the Old Polish dictionary, who have told me that it indeed is "Old Kashubian", which they accept in their framework of Old Polish. Gorazd also holds the same view. @Thadh @Sławobóg @Rakso43243 @Benwing2 @Mahagaja @Silmethule. Vininn126 (talk) 10:50, 6 May 2024 (UTC)

Alternatived are if we accept Kashubian and Slovincian as the descendants of Old Pomeranian, then we could set them both to be descendants of Old Polish. However, the argument for this is one could accept "Old Kashubian" as a constituent of Old Polish - not a dialect, but constituent. This is what the editor of the Old Polish dictionary told me, quote " Nie napisałam, że to dialekt. Napisałam, że to element składowy języka staropolskiego. To duża różnica. Język starokaszubski to element składowy języka staropolskiego." The alternative is also we ignore this, which seems wrong to me as well. Vininn126 (talk) 11:42, 6 May 2024 (UTC)

Another solution: give Old Kashubian an etycode and make it an alt of Old Polish and if a term is attested in Pomerania, we could set the Kashubian and Slovincian reflexes as inherited from that? Otherwise directly from Proto-Slavic. Vininn126 (talk) 14:36, 6 May 2024 (UTC)

@Vininn126 I think this last solution is maybe the best. This is similar to what is done with Old Northern French, which is considered an etym-only variety of Old French even though Old French as normally construed refers to the Old French of the Paris area whereas Old Northern French refers to the Old French of Normandy, and neither is an ancestor or descendant of the other. The two differ significantly in phonology, e.g. Old French chacier /tʃatsiɛr/ -> English "chase" vs. Old Northern French cachier /katʃiɛr/ -> English "catch". Anglo-Norman and modern Norman are both descendants of Old Northern French (although we currently list Norman as a descendant of Middle French, which is wrong) and modern French is a descendant of Old French per se. Benwing2 (talk) 18:38, 6 May 2024 (UTC)

I know @Silmethule also mentioned a similar situation with Ancient and Mycenean Greek and also Old Norse and Swedish/Icelandic. See also my question on WT:About Old Polish. Related to that, I'm unsure how to handle labels for all of this. I think we'd want to list Kashubian/Slovincian in the Old Polish entries if and only if a text from Pomerania has an attestation. And any Kashubian/Slovincian words should still have "inherited from Old Kashubian/Pomeranian". Vininn126 (talk) 18:49, 6 May 2024 (UTC)

@Nicodene As our resident Romance expert, do you agree with changing the ancestor of Norman to be Old Northern French instead of Middle French? This will cause the 5 terms in CAT:Norman terms inherited from Middle French to throw errors, I think. Can you fix up those 5 terms? Also I notice there are 30 terms in CAT:Norman terms inherited from Medieval Latin, which seems impossible and probably need to be cleaned up. Benwing2 (talk) 19:54, 6 May 2024 (UTC)

I've just cleared out the categories in question. Αgreed on removing Middle French as an ancestor of Norman. As for its further ancestor, I would leave it as just Old French, which includes ONF as-is. I think the latter are best treated as one overall language.

I've been meaning to eliminate '[Romance] terms inherited form Medieval Latin' in general, reassigning them to '...inherited from Early Medieval Latin' or '...borrowed from [later] Medieval Latin'. That will take some time. When it's done, perhaps we can make {{inh|romance language|ML.|...}} throw an error message and a brief comment. Nicodene (talk) 00:50, 7 May 2024 (UTC)

@Nicodene Thanks! I think the basic advantage of setting the ancestor of Norman to be Old Northern French is it more clearly shows the ancestry (when you go CAT:Norman language and look at the Ancestors panel) than just setting it to Old French. Since Old Northern French is an etym-only variant of Old French, I don't think it will make any difference in terms of what Norman terms are allowed to inherit from. What do you think? Benwing2 (talk) 01:44, 7 May 2024 (UTC)

Oh, so setting it to ONF won't disallow inheritance from Old French. In that case it sounds fine to me. Nicodene (talk) 01:50, 7 May 2024 (UTC)

Yeah that's right. Benwing2 (talk) 01:56, 7 May 2024 (UTC)

@Nicodene @Benwing2 Here's how it works. If you set a variety (etym-only language) as an ancestor, the descendant can inherit from:

• That ancestor and any (sub)varieties of that ancestor (in this case, Old Northern French, and any varieties it might have).
• The parent (in this case, Old French) unless the ancestral variety is also explicitly ancestral to its parent (read: the thing it's a variety of), which doesn't apply here. This is for situations like Tajik having Classical Persian as an ancestor: Classical Persian's set as a variety of Persian, but is also set as its ancestor. Since Tajik's ancestor is also Classical Persian, it's only possible for it to inherit from Classical Persian (and any varieties thereof), not Persian in general.

It can't inherit from:

• Any other varieties of the parent which aren't in the direct lineage of its ancestor (i.e. it wouldn't be able to inherit from other varieties of Old French, unless they're ancestral to/descended from/a subvariety of Old Northern French). To use an Italic example: if we set the proto-language of Romance to be Vulgar Latin, instead of simply Latin, the Romance languages could also inherit from Classical Latin (its ancestor), Latin (the general parent) and Old Latin (set as the ancestor of Latin), but they wouldn't be able to inherit from varieties like Medieval Latin or New Latin, since they aren't in the direct lineage.

It sounds complicated, but it seems to line up pretty neatly with most people's intuitions in practice. Theknightwho (talk) 15:40, 10 May 2024 (UTC)

So it would be possible to set Old Kashubian as an etym-only variant of Old Polish and then set Kashubian and Slovincian as the children of Old Kashubian but not Old Polish? Vininn126 (talk) 15:43, 10 May 2024 (UTC)

@Vininn126 Per the rules just outlined, we could definitely make Old Kashubian an etym-only variety of Old Polish and set the ancestor of Kashubian and Slovincian to Old Kashubian, but people would still be able to "inherit" Kashubian and Slovincian terms from Old Polish. It'd be like the situation with Old French. If you wanted to avoid that, either we'd need a new flag or rule of some sort, or we'd need to change the name of Old Polish to e.g. "Old Lechitic" and make Old Polish an etym-only variety of Old Lechitic. @Theknightwho Here's a thought though. If we set the explicitly set the ancestor of Old Kashubian to Proto-Slavic, would that make it impossible to inherit Kashubian terms from Old Polish? That would be like a slight generalization of the special-case rule for ancestral-to-parent etym languages. Benwing2 (talk) 21:18, 10 May 2024 (UTC)

I've dreamed of "Old Lechitic", but it doesn't encompass Polabian. Vininn126 (talk) 22:08, 10 May 2024 (UTC)

@Vininn126 Sorry, why does Polabian matter here? It can just be excluded from Old Lechitic just as it would be excluded from Old Polish. Benwing2 (talk) 08:41, 11 May 2024 (UTC)

@Benwing2 I have actually tossed the idea of "Old Lechitic" around before with @Sławobóg and @Silmethule. I suppose since it contains Old Kashubian as well there is more precedent for the name. Vininn126 (talk) 08:45, 11 May 2024 (UTC)

@Benwing2 So far I think the name change and etycodes might be the best solution. I'd like to see if anyone else has any thoughts. If we agree, we can make this change, maybe once I finish adding location information to the quotation templates (or maybe that's not necessary...). Vininn126 (talk) 12:03, 13 May 2024 (UTC)

Also pinging @KamiruPL as the other main Old Polish editor so he can be aware of the goings-on and give his opinion. Vininn126 (talk) 08:34, 11 May 2024 (UTC)

I wouldn't like this. This is almost akin to handling Old East Slavic as an Old Church Slavonic variety. Pomeranian and Polish are two distinct branches, and the fact that an earlier stage was highly influenced in their literary variety by the other doesn't make them one and the same. Thadh (talk) 20:43, 6 May 2024 (UTC)

There's actually a similar issue with texts from Pomerania from {{R:pl:SXVI}} and {{R:pl:SXVII}} but I think we can safely nest these under modern Kashubian with a label, as I have done with Middle Polish. Vininn126 (talk) 19:43, 6 May 2024 (UTC)

Absolutely no to changing name of Old Polish to Old Lechitic or something. Since Kashubian belongs to different group, it should be separate Old Pomeranian L2 language. It would work better as Proto-Pomeranian too. Having etym-only code would be an alternative solution too, but then we are not consistent with our system (that made BG and MK descendants of OCS :)). Sławobóg (talk) 13:12, 14 May 2024 (UTC)

@Sławobóg As to your second point: are you saying we could set Old Pomeranian as an etycode within Old Polish? What about the issue where people would be able to give type e.g. {{inh+|csb|zlw-opl}} with no issues? Vininn126 (talk) 13:30, 14 May 2024 (UTC)

Having Kashubian as descendant of Old Polish is just wrong. Having "Old Pomeranian" as etym-code for Old Polish would be better, but still not as good as having separate lang, but it might make editing easier. Sławobóg (talk) 13:44, 14 May 2024 (UTC)

Would you be able to 1) assist in establishing spelling norms? 2) Dealing with the texts? 3) Understanding the grammar? 4) What about the fact that there are very few texts? 5) What about the fact that all of Old Polish already is a collection of dialects? Vininn126 (talk) 13:54, 14 May 2024 (UTC)

1-3) Probably not. 4) We have languages like that. 5) Pomeranian being part of it is wrong. I'm not gonna fight here, you asked be about opinion, I gave my opinion. And if you plan having Middle Kashubian, having Old Kashubian/Pomeranian as L2 would be a good thing. Sławobóg (talk) 14:48, 14 May 2024 (UTC)

I'm not arguing, I'm just asking questions. I have no problem if you question the points I raised earlier! Vininn126 (talk) 14:50, 14 May 2024 (UTC)

@Vininn126 I think we can fix the issue of {{inh+|csb|zlw-opl}}, if that would help. Benwing2 (talk) 14:54, 14 May 2024 (UTC)

@Benwing2 That could be a good compromise. Vininn126 (talk) 14:55, 14 May 2024 (UTC)

@Benwing2 @Sławobóg also mentioned a solution where we create a Kashubian label old "Old Pomeranian" and not place that information in the Old Polish article. I'm not sure how I feel about this considering how close Old Pomeranian was culturally and even linguistically to Old Polish at the time. Do you have any thoughts? Vininn126 (talk) 11:46, 17 May 2024 (UTC)

@Vininn126 Hmm, I'm not so versed in the ins and outs of Old Polish but given how close Old Pomeranian and Old Polish apparently were, along with the fact that (I assume) there will be relatively few lemmas under Old Pomeranian specifically, I think it might make sense to keep them under the same L2 and just fix the inheritance issue to prevent people inheriting from Kashubian directly to Old Polish instead of Old Pomeranian. I don't think fixing the inheritance issue is such a big deal; we just have to change the logic here Module:languages#L-869 that computes the ancestors of a given language. Benwing2 (talk) 00:02, 18 May 2024 (UTC)

Okay. I'm going to think on this issue a bit more. Vininn126 (talk) 08:18, 18 May 2024 (UTC)

Old Polish regional categorization

As a sort of continuation of Wiktionary:Beer_parlour/2024/May#The issue of Old Kashubian (Old Pomeranian?) and Wiktionary talk:About Old Polish#Regional Old Polish, I'm trying to figure out the best way to handle regional information for Old Polish. I have a document explaining the origin of most texts in Old Polish so it should be easy to figure out which of the 5 lects currently considered Old Polish (those being Masovian, Greater Polish, Lesser Polish, Silesian, and Pomeranian/Kashubian). I think it would be useful for readers to know which region a definition/term has been attested, as Old Polish wasn't a single entity and ultimately is the source of those modern dialects today, so we can see more clearly regional features and the like. My concern about using labels is that they would imply that a term might have been limited to a given lect, which we can't know for sure. What do others think? Vininn126 (talk) 19:17, 6 May 2024 (UTC)

One solution could be to use {{lb}} but print the text {{lb|zlw-opl|attested in|Masovia|Lesser Poland}} etc. @Benwing2, would this be technically bad? Vininn126 (talk) 15:56, 8 May 2024 (UTC)

@Vininn126 No, I don't see why that would be an issue. attested in isn't currently a recognized label but could easily be made one, so that it suppresses the following comma. Benwing2 (talk) 23:21, 8 May 2024 (UTC)

@Benwing2 Alright, that would be fine, and I think that's a good solution. Vininn126 (talk) 07:32, 9 May 2024 (UTC)

@Benwing2 Another solution would be to have the quotation templates categorize by dialect when added to a page. This probably would be a bad idea? Vininn126 (talk) 07:44, 9 May 2024 (UTC)

@Vininn126 Yeah the quotation templates do take a label but I feel uncomfortable categorizing based on that label. You could for example imagine someone illustrating a general-use term with a sentence written in a dialect, and labeling the quotation with the dialect in question; that doesn't mean in this case that the term is in the dialect. Benwing2 (talk) 08:24, 9 May 2024 (UTC)

@Benwing2 Alright so for now I'm going to add the location of creation of the documents and a note saying what label the quotation template should count toward, see {{RQ:zlw-opl:AcCas}}, and I'll add the labels and regions manually from there. Unless it'd be possible to do a bot job after. Vininn126 (talk) 08:26, 9 May 2024 (UTC)

@Vininn126 Might be possible, depends on how regular everything is and you making a list of all the quotation templates and associated lect/labels. Benwing2 (talk) 08:36, 9 May 2024 (UTC)

@Benwing2 I think it might be possible to try. Would it be possible to generate a list of text given in the {{{location}}} parameter? From there I could say which label should be given whenever that region appears under a definition and we could have a bot add those labels. (I might also want to update the output display of a few of the locations). Vininn126 (talk) 11:23, 26 May 2024 (UTC)

I also think this will help me make a decision with Old Pomeranian. Vininn126 (talk) 11:24, 26 May 2024 (UTC)

Finally, and sorry to dump a bunch of bot requests - could we remove any text within parentheses in quotations? They're not part of the original text, but used for things like clarification on the editor's end. Vininn126 (talk) 11:57, 26 May 2024 (UTC)

@Benwing2 Can we add this to the labels module? I'm slowly working through these sources and I think this is the best solution. Vininn126 (talk) 12:01, 13 May 2024 (UTC)

Continental Celtic

We have Continental Celtic as a family, but my understanding is that the consensus among Celticists is that is CC isn't a clade but just a term of convenience for Celtic languages other than the Insular Celtic ones. Isn't our custom at Wiktionary to have only actual genetic families, not convenient groupings? —Mahāgaja · talk 11:28, 7 May 2024 (UTC)

@Mahagaja Yeah we should get rid of this. BTW the Wikipedia article on Continental Celtic was in a terrible state due to a bunch of crap added a month ago, which I reverted. Benwing2 (talk) 22:06, 7 May 2024 (UTC)

Yeah, agreed. Theknightwho (talk) 04:09, 10 May 2024 (UTC)

@Mahagaja @Benwing2 I've done this, given there were no objections after nearly 3 weeks. Theknightwho (talk) 11:01, 27 May 2024 (UTC)

@Theknightwho Thanks! Benwing2 (talk) 18:36, 27 May 2024 (UTC)

Ban one-descendant Proto-Italic and Proto-Hellenic redlinks

There are already far too many one-descendant Proto-Italic and Proto-Hellenic entries, and adding one descendant redlinks to, for example, a descendant tree or an etymology section is only going to encourage more of these entries being created. These redlinks should be banned. -saph 🍏 13:31, 7 May 2024 (UTC)

Right, there should be above-average incentive to create such a page, so unless it is already decided to have one, bots should neutralize these links. Fay Freak (talk) 13:51, 7 May 2024 (UTC)

In practice, what does a 'ban' on making certain kinds of redlinks mean, and what is the alternative it is supposed to incentivize? I guess mentioning the same form but not linking it would be slightly better, as it doesn't encourage creating an entry, but I'm not totally happy with that either in some cases. E.g. if the reconstructed form is itself doubtful, I wouldn't want it to be mentioned anywhere.--Urszag (talk) 15:44, 7 May 2024 (UTC)

For example:

From Proto-Italic *fworom, from Proto-Indo-European *dʰwor-om (“enclosure, courtyard, i.e. something enclosed by the door, or the place outside, i.e. through the door”), from *dʰwer- (“door, gate”).

With the Proto-Italic word displaying as just plain text, rather than what we currently have (forum). As for the reconstructed form being doubtful, we should just list the hypothesised PIE form, e.g.:

• Usually held to derive from Proto-Indo-European *swer-yo-s, from the root *swer- (“heavy”). Cognate with Old English swǣr (“heavy, grave, grievous”), German schwer (“hard, difficult, heavy”), Lithuanian sverti (“to weigh, balance”), svarùs (“heavy”). More at sweer.

As opposed to the current etymology given at serius. -saph 🍏 15:58, 7 May 2024 (UTC)

The alternative it is supposed to incentivize is not creating such entries. You would have to have a more serious motive than ticking off a removed red link, since they are not apparent in the first place. Fay Freak (talk) 16:03, 7 May 2024 (UTC)

Agreed. Down the line it may also be worth discussing a general ban of reconstructions (and their associated redlinks) that have only one descendant and no derived terms. Nicodene (talk) 22:49, 9 May 2024 (UTC)

Could someone run a bot to do this? -saph 🍏 19:50, 10 May 2024 (UTC)

One-descendant Proto-Italic entries could be useful for "internal reconstruction", i.e. comparing different Latin words, though; like how Latin verbs change their stem vowel when a prefix is added (e.g. faciō > interficiō). --kc_kennylau (talk) 13:39, 3 June 2024 (UTC)

Add "Muslim", "Hindu" etc. labels?

Proposal to add labels for lemmas used by people of specific faiths (which are not necessarily religious terms, rather they're only used by certain groups. Case in point মিঞা (mĩa) which has a Muslim gloss, but the Muslim label is an alias for 'Islam', though it's not an 'Islamic' term, just used by Muslims. Urdu dictionaries, which I concern myself with, have used these labels for centuries without prejudice. I know this would be useful for languages in the Indian subcontinent, as well as European languages (especially English). نعم البدل (talk) 20:55, 7 May 2024 (UTC)

@نعم البدل There are (at least) two possibilities here. One is to disentangle the labels 'Muslim' and 'Islam' in a language-independent fashion, and the other is to do it for specific languages. I suspect the aliasing of 'Muslim' and 'Islam' was done with English entries in mind, where on the surface it makes a certain amount of sense (e.g. we have 'Muslim finance' as an alias of 'Islamic finance' and 'Christian' as an alias of 'Christianity'). A third possibility is to create a separate label, something like 'Muslim usage' or 'Muslim speakers', which makes it clear that the term is used by particular speech communities. Note that the advantage of doing it in a language-specific fashion is we can create associated categories, such as Category:Muslim Bengali, to categorize such terms, which wouldn't make so much sense if done language-independently. Finally, the adjective-noun issue you're bringing up isn't limited to this case; there is for example the issue of 'British India' (English terms formerly used in British India) vs. 'British Indian' (English terms currently used by Brits of Indian background).

BTW if you think the terms should be disentangled language-independently, you can see all current uses of the label 'Muslim' here: Special:WhatLinksHere/Wiktionary:Tracking/labels/label/Muslim (there are only 9 of them). Benwing2 (talk) 21:58, 7 May 2024 (UTC)

@Benwing2: I think the 'Muslim' (etc.) tag should be detached from the 'Islam' label and made into an independent label and placed under the Module:labels/data/topical so that, as you say, it can generate associated categories, something like Category:Bengali Muslim speech (similar to Category:English women's speech terms, a minor difference between 'Muslim Bengali' as the label I'm proposing should be shed of its religious connotations as much as possible).

• you can see all current uses of the label 'Muslim' here – Thank you for this! As far as I can see, apart from marabout, all of the other terms should be placed under my proposed label, as that's what was probably implied. Note how the 'Muslim' tag in মিঞা (mĩa) was encapsulated with Template:a (added by an IP), not the 'Muslim' label – likely because the 'Muslim' label appends the lemma to Category:Islam which doesn't fit. نعم البدل (talk) 02:21, 8 May 2024 (UTC)

@نعم البدل OK, let's see if there are any objections/comments, and if not I'll make this change in a few days. Benwing2 (talk) 03:04, 8 May 2024 (UTC)

Yeah no worries! نعم البدل (talk) 17:34, 8 May 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Benwing2, نعم البدل For a while there was a category named CAT:Musalman Gujarati, which is now empty. The handful of terms that were in it were moved to CAT:Gujarati dialectal terms. It would be helpful if there is a category named something like CAT:Gujarati Muslim speech as a replacement for CAT:Musalman Gujarati.

There is a phenomenon known as being a Cultural Muslim, but not a practising Muslim, who might use the terms in a category such as CAT:Muslim speech but not necessarily identify with the terms in CAT:Islam. The same would probably be applicable to other faiths.

Would greetings such as salaam alaikum that are associated with a Muslim context but may or may not be intended to be Islamic be in the proposed CAT:Muslim speech alongside CAT:Islam? For this particular term, it says on Wikipedia that it is ‘common among Arabic speakers of other religions (such as Arab Christians and Mizrahi Jews)’. The usage notes section of नमस्ते says ‘it is often considered gracious to greet someone in their religion’s greeting’ [even if that differs from their own religion]. Kutchkutch (talk) 03:44, 10 May 2024 (UTC)

@Kutchkutch: I might be drifting away from the subject a little since I'm a little in interested in this :) The case with salaam alaikum is slightly complex, though. In Arabic, it's a common greeting, and used by people who follow Abrahamic faiths. I'm not really sure about the exact perception of that phrase in Arabic but in Urdu, it's sometimes the same, people who speak Urdu, regardless of their faith, might use that term, but some hardliners might be of the opinion that it's even forbidden to say 'Salam' to a non-Muslim, while other Muslims might not even bat an eye to the other's faith, and a label might not even be considered. Generally, I would say it applies to a CAT:Muslim speech (but not Category:Islam) because of alternatives like آداب (ādāb) being considered more 'neutral'. Is नमस्ते (namaste) considered to be inherently an Hindu phrase, as is generally the perception of Urdu speakers – even when it comes it to Hindi, or is it somewhat neutral? نعم البدل (talk) 01:44, 11 May 2024 (UTC)

@نعم البدل: Thanks for the clarification about سَلام عَلَیکُم (salām 'alaikum).

• Is नमस्ते considered to be inherently an Hindu phrase, …when it comes it to Hindi, or is it somewhat neutral?

• With respect to this proposal, नमस्ते and नमस्कार could go in CAT:Hindi Hindu speech. However, there is inherently nothing Hindu about the words नमस्ते and नमस्कार in of themselves other than Sanskrit being the liturgical language of Hinduism (similar to how Arabic is the liturgical language of Islam). What may considered inherently Hindu/Buddhist/Jain/Sikh about नमस्ते and नमस्कार is when the the salutation (and related hand gesture 🙏) is toward a deity rather than actual person.
• Although the words नमस्ते and नमस्कार are found in Vedic literature in the context of worshipping Hindu deities, the words themselves are formations derived नमस्, which is cognate to نماز .نماز was probably associated with Zoroastrianism rather than Islam before the Islamic conquest of Persia, and this is indicative that the term was not inherently bound to a particular religion.
• Even though नमस्ते and नमस्कार are considered Hindu greetings, it seems to be neutral when speaking Hindi because it may only be inappropriate to use them if both the speaker and listener belong to a community that has its own community-specific greeting such as सलाम अलैकुम (salām alaikum) among Muslims, जय जिनेंद्र (jay jinendra), among Jains and सत श्री अकाल (sat śrī akāl) among Sikhs. The reason for this may be that India is 79.8% Hindu (according to the 2011 census). If there are no overt indicators to guess the other person’s religion when talking to strangers, using the Hindu greetings (alongside the English greetings) may be considered as neutral since there is an 80% probability that the other person is a Hindu.

• Under this proposal, would title of CAT:Judeo-Urdu remain the same or would it be renamed to CAT:Urdu Jewish speech? Kutchkutch (talk) 11:23, 11 May 2024 (UTC)

  @Kutchkutch That is a very good question; maybe User:-sche would have some thoughts about this. Often the Judeo-Foo varieties are their own dialects rather than just consisting of extra terms added to the language and writing the language in the Hebrew script (most famously "Judeo-German" aka Yiddish and "Judeo-Spanish" aka Ladino, each of which has its own L2). In other cases however, it is more comparable to the distinction between Hindi and Urdu, and in some situations there is even less of a difference; I'm not sure about Judeo-Urdu. Benwing2 (talk) 18:34, 11 May 2024 (UTC)

  @Kutchkutch: My opinion would be to keep Category:Judeo-Urdu as it is as it's a separate variety. نعم البدل (talk) 19:15, 12 May 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Thinking about the "Judeo-Urdu" vs "Urdu Jewish speech" question has me wondering how sensible labels/categories for "Jewish speech", "Muslim speech" etc really are...though I don't know what a better alternative is.
In theory, if we add a "Jewish speech" label, all of our entries in any Judeo-X lect, whether we treat it as a distinct language ("Judeo-Italian", "Judeo-Tat") or a dialect ("Judeo-Arabic"), could simultaneously gain this new "Jewish speech" label, by definition, no? Arguably a bulk of our Hebrew and Yiddish entries would also gain it. But is that useful? (So maybe, for such languages, we forgo the label? But where is the line? Do we have a Hindu-speech Hindi category, or do we assume the default for Hindi is Hindu and exceptions must be specified? But even more Bangladeshis are Muslim than Indians are Hindu...)
On a practical level, I worry that users will not grasp or maintain a distinction between "Muslim" and "Islam", because "it's mostly Muslims who use [such-and-such Islamic-religion-related word]" → "I'll label it 'Muslim'" is just too logical a train of thought, as is "only people who believe in Islam use this word" → "I'll label it 'Islam' [even if the word just means 'man' and not a per se religious concept]", so it'll be a perpetual maintenance task to keep the labels straight. I also wonder... would nonreligious people from 'traditionally Muslim' areas not use (e.g.) মিঞা? Is using মিঞা really bound up in being Islamic, something only Muslims do—and if so, why is it not then a {{lb|en|Islam}} term? I wonder if this is not better handled (like also the ostensible "English women's speech terms")* by usage notes, that a particular term is typically used by people from "culturally Muslim" communities...? But I concede that even usage notes imply that if there are many such terms, they could be in a category (and if something is a dialect, even a cultural dialect, well, we do often have labels for that), even if I wonder if it would be possible to find clearer wording ("culturally Muslim"?)...
Does Judeo-Urdu, in particular the spoken form, have a lot of words in common with "general" Urdu? Is the main distinction that Judeo-Urdu is Urdu written in Hebrew script, or are there pervasive "dialectal" differences e.g. in how vowels are pronounced or how words inflect? If, in speech, lots of words are held in common between Jewish speakers' Urdu and other people's Urdu, then it might be weird to call those common words "Jewish speech" words solely because Jews tend to use a different script in writing, no? (Conversely, if lots of words are different and Judeo-Urdu is its own lect, whether an independent language like Judeo-Italian or a dialetc like Judeo-Arabic, is there much benefit to categorizing things as both "Judeo-Urdu" and "Urdu Jewish speech"? But as I said above, I suppose we could set it up so that the labels that would generate "Urdu Jewish speech" and "Judeo-Urdu" were aliases for Urdu and only generated one of those categories no matter which one was entered...
This all seems...thorny.
(*Re "English women's speech": "Women's speech" does not seem to be a distinct lect in English the way it is in e.g. Sumerian ... but until very recently, the nature of our label- and category- system meant that any label that a single small language needed, had to be put into the singular big mishmash everyone saw presented as "labels that are available to all languages", so various people tried to find ways to apply myriad Sumerian-and Chinese- etc- specific labels to English... so I am tempted to change the few entries that use that label in English to instead have usage notes, where such notes/label would even be accurate, saying mostly women use it... and to restrict the label to only those languages which actually have distinct women's speech registers...) - -sche (discuss) 19:25, 12 May 2024 (UTC)

@-sche You've made a lot of good points. I agree with you about converting the terms in CAT:English women's speech terms into Usage notes. Interestingly, all but one are primarily used in foreign contexts; possibly the native languages in those contexts do have a women's register. And the one remaining (bestie) seems questionable; it has a cutesy feel to it, which is probably why it's being considered "women's speech" but I'm sure you can find examples of men using it. As for Judeo-Urdu etc. I think any variety that is predominantly used by a particular ethnic community should probably not be redundantly tagged using that community's speech tag. Hence you could have e.g. "Sikh speech" or "Jain speech" in Hindi but not "Hindu speech". Same goes e.g. for Yiddish and Ladino being tagged as "Jewish speech". Benwing2 (talk) 21:31, 12 May 2024 (UTC)

Sure we should have the labels. In other cases they are or have been even L2, as Christian Palestinian Aramaic and Jewish Palestinian Aramaic, the situation with information exchange in the past was of course more seclusive. For Arabic we agreed that the separate codes were exaggerated, but there were cases where I had to label Moroccan Arabic terms as Jewish-only, and even for Serbo-Croatian we have terms only working for Muslims.

Having to label most Hebrew, Yiddish and Ladino terms as Jewish is a strawman, Arab Israelis do great, of course etymologically many terms used by the minority will have foundation in the historical religion of the majority, the question is whether the respective frequency differs significantly. Fay Freak (talk) 21:51, 12 May 2024 (UTC)

Englishman picture

So User:Shoshin000 (among other trollish activities) has been insisting on adding a picture of an angry football hooligan as the picture of "Englishman". I reverted it once, he restored. I mention this because I know the modus operandi and soon I'll be accused of being a badmin. Check out the entry and you know the previous picture was nicer. Equinox ◑ 22:47, 7 May 2024 (UTC)

I personally think your picture is better (although I wonder, do we need a picture to illustrate this?). Benwing2 (talk) 00:00, 8 May 2024 (UTC)

Honestly, I like Shoshin's pic, as it's more stereotypical.[1] There's nothing inherently Englishman-y about Eq's pic, besides the depicted person being English.

[1] Then again, that's a good argument against the pic. CitationsFreak (talk) 03:25, 8 May 2024 (UTC)

It could be argued that pictures of nationalities, if they exist at all, should show someone of that nationality in characteristic clothing (although that is probably more appropriate for nationalities that actually have characteristic clothing that most people wear on a day-to-day basis). OTOH it's in general very hard to capture a nationality in single picture (for this reason, Wikipedia usually supplies a whole collection of pictures to illustrate a nationality), and in any case this is more encyclopedic than dictionaric (a real but rare word). Benwing2 (talk) 04:06, 8 May 2024 (UTC)

Yeah, I was thinking that a college would be best. I'm not sure what a recognizable British outfit would be, and having one person stand-in for Britain could imply that British people all are X. Highly unlikely, but possible. CitationsFreak (talk) 04:12, 8 May 2024 (UTC)

I don't think nationalities should have photos at all, but I also disagree that File:ENG-BEL (6).jpg is "a picture of an angry football hooligan". The person in that photo doesn't look angry, nor is he doing anything hooliganish. His Englishness is clearly shown by the St George's Cross painted on his face. He arguably does illustrate [[Englishman]] better than the photo of Greg Rutherford, since Rutherford is representing the entire UK (not just England) in his photo. All that said, however, it is probably better to leave such entries unillustrated to avoid stereotyping. —Mahāgaja · talk 08:07, 8 May 2024 (UTC)

I agree, this is not an image that requires an image. Vininn126 (talk) 08:09, 8 May 2024 (UTC)

Aren't photos appropriate where there is an attestable, probably dated and often derogatory or demeaning, definition of a stereotype? Eg, Bavarians with lederhosen, Prussians with spiked helmets, Mexicans with sombreros and/or serapes.

There is no such definition here, nor would I expect us to attest any such definition. DCDuring (talk) 17:34, 8 May 2024 (UTC)

I don't really see this picture as a problem, really, even though I wouldn't pick it myself. It'd probably be fine as part of a collage. Theknightwho (talk) 17:51, 8 May 2024 (UTC)

Fixing Telugu rhymes

For years now, User:Rajasekhar1961 has been adding Telugu rhymes written in Telugu script instead of IPA. There is a special hack in Module:rhymes to deal with this, but IMO Telugu should (obviously) use IPA for rhymes, just like all other languages. Does anyone object to this? Can anyone out there read Telugu script well enough to tell me if the rhymes listed under Rhymes:Telugu (e.g. Rhymes:Telugu/రం) and Category:Rhymes:Telugu are even salvageable, or should just be nuked? I don't know much about Telugu but scripts are generally not 1-to-1 mappable to IPA, so I don't know what it means to have a rhyme listed using Telugu script. Benwing2 (talk) 00:40, 8 May 2024 (UTC)

Strongly agree. Theknightwho (talk) 11:40, 8 May 2024 (UTC)

@Benwing2, Theknightwho Rajasekhar1961 has certainly put effort into creating CAT:Telugu rhymes. However, unless the definition of a rhyme in a Telugu or Dravidian context differs from

‘the second part of a syllable, from the vowel on, as opposed to the onset’

you are correct in pointing out that these do not appear to have been done correctly. From an orthographic perspective, the final consonant (or consonant cluster) followed by the final diacritic (or the inherent schwa) of a word written in Telugu script (which is a Southern Brahmic abugida) does not constitute a rhyme. The entries in CAT:Telugu rhymes categorise words by word-final syllables rather than rhymes because the onset is included.

A Telugu editor could probably rectify the words mentioned on the entries in CAT:Telugu rhymes. However, even if there is a user with the appropriate background to do so, it would be a lot of work, and it would be the equivalent of deleting the entries currently in CAT:Telugu rhymes and starting over again. Kutchkutch (talk) 11:13, 10 May 2024 (UTC)

@Kutchkutch Thanks. User:Rajasekhar1961 can you comment on why you did this? If I don't hear from you in a few days I will go ahead and delete all the Telugu rhymes. Benwing2 (talk) 14:50, 10 May 2024 (UTC)

Kwami is messing with translingual entries, again

Just want to make sure there are some eyes on Kwami, as they've been making mass edits to Translingual entries that seem... worrying. After being reverted by @Theknightwho and @Benwing2 for deleting the translingual section, Kwami has recently begun deleting all the definitions from the translingual section instead.

I reverted all (but one) of the single character edits they've made today. However, they've been editing hundreds of TL entries and I have no idea how many entries are affected, as I've been very busy recently and can't check.

I'm not sure how bad the situation is so I don't want to "call out" Kwami. Just want to make sure people are aware before it becomes out of hand, like the last time this was discussed on here. — Sameer ^{﴾مشارکت‌ها・بحث﴿} 23:54, 8 May 2024 (UTC)

@Sameerhameedy Thank you. I have blocked him for a month this time; I am getting seriously sick of this. I think he has used up all his lives; next time we should consider a permablock. Benwing2 (talk) 00:38, 9 May 2024 (UTC)

Thank you, I'm also a bit annoyed since Kwami has gotten so many warnings and continues to do the same action. Now, Kwami has indicated that they will actually start a discussion on this issue before acting. There's no way to know if Kwami will actually follow through on that statement, but hopefully they do, so we don't have to do this every month. — Sameer ^{﴾مشارکت‌ها・بحث﴿} 00:51, 9 May 2024 (UTC)

Just to clarify, these weren't random articles. I went through the whole Latin Extended Additional block and replaced physical descriptions (e.g. "the letter N with a line below") with requests for definition. I didn't delete actual definitions that would tell the reader what the letter meant or what it was used for.

Sameer, the discussion is the next thread. kwami (talk) 06:16, 10 May 2024 (UTC)

@Kwamikagami That is exactly the issue. You are continuing to fail to see that there is no consensus for doing what you did, after 10+ times that you've been asked to get consensus *BEFORE* doing mass changes. If you're not seeing this now, I doubt you will ever see it, and if you're not willing to defer to and respect consensus, you're in for a permablock. Benwing2 (talk) 08:01, 10 May 2024 (UTC)

@Benwing2, Sameer was concerned that there may be many more such edits, so I clarified what edits I had made. That included the category of articles I had edited, and the kind of edits I had made on them. I thought they might find that helpful.

As to your point, I wonder how possible it is to get consensus to do anything here. Hopefully the discussion below will produce consensus. My hopes aren't high, given that previous discussions got nowhere, but you never know. kwami (talk) 09:06, 10 May 2024 (UTC)

I've been at Wiktionary for almost 20 years and have never yet seen a Beer parlour discussion result in consensus, so my hopes aren't high either. —Mahāgaja · talk 09:16, 10 May 2024 (UTC)

You can't have read many Beer Parlour discussions, then. Kwami is simply trying to convince themselves that what they're being asked to do is impossible, because they can't ever accept they're wrong about anything, ever. It's not complicated. Theknightwho (talk) 10:57, 10 May 2024 (UTC)

@Mahagaja I have seen plenty of Beer Parlour discussions that result in consensus; not sure what you're referring to. Benwing2 (talk) 14:53, 10 May 2024 (UTC)

I guess ironically there's no consensus if there's consensus? And while I think us Wiktionarians like to bicker and we often disagree over certain details and such, I do think there's enough cooperation, compromise, and agreement to say that plenty of threads end inn consensus. Vininn126 (talk) 15:10, 10 May 2024 (UTC)

If I decide that "q" is not a proper English letter unless followed by "u" and I want to get rid of all the English entries with a "q" not followed by "u", there is no way that I can get consensus for that via any process. That doesn't mean that I can go ahead and remove the English entries for words like Qatar and Iraq or even BBQ (it's not a proper abbreviation) because the usual process doesn't work. It means I should find something else to do. The unwritten question underlying all of this is "how can I get my way when I'm right and I can't get people to say they agree with me". Yes, the process isn't perfect, and sometimes doesn't work- but rejecting it entirely won't fix it. Chuck Entz (talk) 16:16, 10 May 2024 (UTC)

That's why I'm here. The question is straightforward: do we have standards for what counts as a definition? If so, what are they? Where can I find them?

In this case, does a graphic description count as a definition? Quite a few editors have said they do not, but there seems to be difficulty in implementing that.

Also, should we have a translingual section without providing evidence of translingual use? Especially when there is no definition in that translingual section?

Do we have consensus that such things should be tagged with RFDef or RFD, and how should I respond if I tag them and someone goes through and deletes the tags without discussion because they don't like the extra work?

It's fine to say 'go to RFD', but why spend months doing that if it should be obvious from the outset that they're not going to pass? That's a waste of everyone's time. That's why I'd like some concrete standards to follow. I assume Wikt must have standards; if you could just show me where they are (I don't see anything in the help pages), I could add a link to my user page and refer to them when making edits. Then instead of arguing over every edit, I could point to the standards and show that I've been following them, or they could point to them and show that I've been violating them. I don't mean about the RFD process, but about the content of our articles. kwami (talk) 19:37, 10 May 2024 (UTC)

An example to provoke thought is zebra. A definition as 'an equid with prominent black and white stripes' would be an accurate description, and would work even if they were not a clade. (An early cladistic study concluded that they were not - morphology is a poor guide to details of relationships.) For Unicode characters - and Unicode provides an important high level classification of glyphs - the general principle is that combining marks are distinguished on the basis of shape. Therefore, graphic descriptions are quite relevant for 'precomposed' characters.

If there's an objection to a claim of translinguality, then raise a request for verification.

If tags are deleted without reason, then complain to the Beer Parlour if you can't find a helpful admin.

What may seem obvious to you is not necessarily even true. There are some very obscure characters around, quite possibly restricted to expensive books.

Wiktionary has a general disdain for wikilawyering, so don't expect everything to be laid down. Wiktionary also seems quite bad at documenting things - I'd love a guide on the anatomy of a definition. --RichardW57m (talk) 12:56, 13 May 2024 (UTC)

@RichardW57m For physical objects, a physical description is fine. And I think it would be fine if we had "the letter a with an acute accent, used for ...," where we went on to give its use or meaning. And a short description without definition would be fine under a 'description' section or even 'etymology', assuming it's accurate (many Unicode names are not, they're just labels that need to differ from all others). But these cases are like defining 'zebra' as "a word spelled Z-E-B-R-A", and placing it under 'translingual' because there are multiple languages that have such a word, even if they mean different things (maybe some languages use it only in the sense of a crosswalk, others only for the equid), and give it only the English pronunciation /ˈziːbrə/ because English is the most important language. (Yes, we have characters listed under 'translingual' even though we give them the pronunciation of a particular language.)

Many people have now said that the Unicode name of a character or emoji, or similar sum-of-parts description, is not appropriate on its own as the definition. The problem I've had is trying to implement that. I've been told to take it to RFD, but that generally doesn't work. It would be nice to have some agreement as to what counts as a definition. kwami (talk) 18:19, 13 May 2024 (UTC)

"the letter a with an acute accent, used for ...,"

I don't know how many languages change the meaning of an accent per character. It would much more efficient to say "the letter a with an acute accent" with the page acute accent explaining what the diacritic does. — SAMEER (؂・؄・؏) 18:49, 13 May 2024 (UTC)

I'd be fine if we had consensus on doing that, but would think we'd want something more. Such a description often wouldn't say anything more that the Unicode name, and conflicts with our sum-of-parts criterion. Plus, people often just use the Unicode name even when it's not an accurate description. Another problem is that it creates a blue link that make it look like we have a definition when we don't have a functional one. For people like me who use red links as a guide to creating missing articles, that can be a problem. Also, not all Unicode characters actually exist, some are errors. And some are rare enough that giving a graphical description as a definition doesn't do much for the reader, who may still not know what the character is used for or what languages it appears in. kwami (talk) 19:10, 13 May 2024 (UTC)

The problem I've had is trying to implement that. I've been told to take it to RFD, but that generally doesn't work. - the small problem with this is that you didn't take things to RFD, though, and it won't become any more true just because you keep repeating it. It's very clear that Kwami will never, ever understand why their approach is wrong. Theknightwho (talk) 18:53, 13 May 2024 (UTC)

I've taken dozens, possibly hundreds, of articles to RFD, or at least tag them so that the people at RFD respond to them. I don't know why you keep denying that. You repeating things over and over doesn't make them true either. Repeated false accusations like this are one reason I have a hard time accepting that you act in good faith. kwami (talk) 19:01, 13 May 2024 (UTC)

@Kwamikagami I've found one, plus this which isn't relevant. Are you referring to all those entries you mis-tagged with {{d}} (speedy deletion), which exists to avoid doing the RFD process for routine deletions? I've just remembered that, after I found this comment where you try to bullshit about that, as well. Good grief. Theknightwho (talk) 19:22, 13 May 2024 (UTC)

Yes, the POV of anyone who disagrees with you is "bullshit", while your POV is "truth". Again, arguing in bad faith and you habitually do.

I don't recall which abbreviation of which template I used for which article. Some of them were probably speedies. Some were RFD. Some later on were RFDef (which I know you think is somehow illegitimate, but I maintain is still a valid use of process). kwami (talk) 20:17, 13 May 2024 (UTC)

@Kwamikagami Saying I've taken dozens, possibly hundreds, of articles to RFD after taking two is bullshit, yes. Theknightwho (talk) 20:23, 13 May 2024 (UTC)

@Kwamikagami Replacing a definition with {{rfdef}} is not a valid process. In general you should never delete content even if you don't like it. Benwing2 (talk) 20:40, 13 May 2024 (UTC)

I understand that. I meant that rfdef itself is a valid process. kwami (talk) 20:48, 13 May 2024 (UTC)

RFDef is not a process - it's just the request template {{rfdef}}. It can't be used instead of RFD, and what you've just said makes absolutely no sense when the only times you used RFDef were in an attempt to circumvent the RFD process. Theknightwho (talk) 20:55, 13 May 2024 (UTC)

If RFD doesn't work, then RFDef is another possibility. If no-one can furnish a definition, then there's an argument that the entry should be deleted. How is that "circumventing" the process? Again, you attribute bad faith to anything you don't like, which simply shows bad faith on your part. kwami (talk) 21:01, 13 May 2024 (UTC)

@Kwamikagami If RFD doesn't work You've only ever taken two things to RFD, and one of those wasn't an entry, so you cannot possibly make that claim. You also seem to be under the bizarre impression that you're entitled to delete entries in other ways if you don't get what you want out of the RFD process.

I'm out of patience with this complete and utter refusal to understand the problem, and it's pretty clear other people are as well. Theknightwho (talk) 21:08, 13 May 2024 (UTC)

A few dozen articles were deleted, so somehow your count is off.

Not deleting entries in other ways, requesting completion or deletion in other ways. I didn't delete these entries I was blocked for. I replaced non-definitions with requests for definition -- and I won't do that again -- but the entries remained. kwami (talk) 22:02, 13 May 2024 (UTC)

@Kwamikagami There's nothing wrong with my counting: you only brought two things to RFD. It's not difficult to understand. Theknightwho (talk) 22:13, 13 May 2024 (UTC)

To clarify, it looks like @Kwamikagami only brought two articles to RFD, but tagged a bunch of articles for speedy deletion, which were deleted before the admins realized those speedy deletions were bogus. RFD is in general the correct process for requesting deletion of pages you believe ought to be deleted that don't meet the speedy deletion criteria; but IMO if you are going to request deletion of a large number of articles, you should not tag every article with RFD, just make a post in RFD with a title "all articles meeting such-and-such criteria" and give your reasons. Or alternatively, bring it up in the Beer Parlour if it's controversial and merits being seen more generally. Benwing2 (talk) 22:31, 13 May 2024 (UTC)

Precisely. Theknightwho (talk) 22:32, 13 May 2024 (UTC)

Okay, so that's what I'm doing: bringing it up at the Beer Parlour, as I was advised to do.

But if it's better at RFD than here, I can start a thread there.

As for "bogus", the opinion I got from other editors at the time was that, if an article had no real content, then it met the criteria and it should be deleted. That specifically included articles that consisted of nothing but the character box and Unicode name in the definition section. I didn't start this, but picked up from where I saw others acting. This has been happening for years, especially with emojis, where someone would go through and create batches of emoji articles defined simply as their unicode names, then someone else going through and deleting them, then someone else recreating them, etc. You can see that in their deletion histories. Less common with non-emoji characters, but there's a history of this there as well. So not only did I have no reason to think this was inappropriate, I was told it was appropriate and was something Wikt needed to keep on top of. kwami (talk) 00:45, 14 May 2024 (UTC)

Yes, and those people would have expected you to take any entries like that to RFD, instead of unilaterally deleting them, as there needs to be consensus that they contain no content. How are you still failing to understand such a simple concept? Theknightwho (talk) 10:42, 14 May 2024 (UTC)

And adding {{rfc|mul|Need meaning rather than graphical description}} to an existing entry is a valid process. --RichardW57m (talk) 14:12, 16 May 2024 (UTC)

Thanks. kwami (talk) 19:41, 16 May 2024 (UTC)

What he wrote was "I've taken dozens, possibly hundreds, of articles to RFD, or at least tag them so that the people at RFD respond to them". Bickering about numbers is not constructive. The issue is whether or not he (or anyone) should be wholesale deleting translingual definitions and it seems pretty clear that the answer is no. —Justin (koavf)❤T☮C☺M☯ 23:20, 13 May 2024 (UTC)

I didn't see that as deleting definitions. I replaced Unicode names with requests for actual definitions. I won't do that again. kwami (talk) 00:47, 14 May 2024 (UTC)

I appreciate that you're acting in good faith and trying to do what you think is best, but it's not clear to me that you're correct and I'm honestly very surprised that you keep on doing things that seem like big unilateral changes without consulting others first because this kind of complaint has come up repeatedly. —Justin (koavf)❤T☮C☺M☯ 00:59, 14 May 2024 (UTC)

Yes, it has. I need to be more careful. I could've just tacked the RFDef tag on the end of the description. kwami (talk) 03:31, 14 May 2024 (UTC)

@Kwamikagami That's not the right thing to do either. IMO you need to get consensus *BEFORE* making changes to large numbers of pages, even just adding {{rfdef}}; if you can't get that consensus, don't make the changes. Benwing2 (talk) 03:44, 14 May 2024 (UTC)

Okay. We'll see how the question below pans out. kwami (talk) 03:45, 14 May 2024 (UTC)

The letter 'a' with a grave accent is a translingual description. The particular meaning of the grave obviously varies from language to language, and sometimes it may merely be an arbitrary diacritic, perhaps even just a word diacritic as in French. Translingually, the accent part is often used as a tone mark, but I think it can also be a symbol used as an input to stress assignment rules (though I may be being confused by my own private invention). Perhaps we need a vote on whether precomposed characters can be dismissed as sums of parts.

We even have some interesting language assignment questions. For example, 'ṉ' denotes the alveolar nasal of Tamil and Malayalam, but I think it's arguable that it isn't a letter of those languages. I'm a bit bothered by a pair of Lithuanian diacritics which don't seem to be any part of standard Lithuanian. --RichardW57m (talk) 12:41, 14 May 2024 (UTC)

Yes, we define 'ṉ' as the Latin transliteration of letters in Tamil and Malayalam scripts, and place that under a translingual heading rather than under Tamil or Malayalam headings. I think that's appropriate. For á, we don't have a translingual heading, as no-one has come up with a translingual use/definition. Not saying one doesn't exist; e.g. there's IPA [a] with high tone, but as you say that's SOP. Again, I think that approach is appropriate. The question then is whether we want to make this our general approach, and reserve the translingual section for definable translingual uses. (Perhaps if we had a translingual use of 'á', we might also give the SOP use in IPA for clarity, but that wouldn't be enough to create the translingual section in the first place.) kwami (talk) 18:12, 14 May 2024 (UTC)

In favor of this. Vininn126 (talk) 09:41, 10 May 2024 (UTC)

Do descriptions count as "definitions"?

I'm not being facetious here. This is a serious question for something I haven't understood for a long time.

For instance, in the article á, would "the letter a with an acute accent" be a valid definition? If so, should such descriptions be added to all letters? If not, should they be removed (perhaps placed under a "Description" heading instead)? And if not, and the only material for an article is such a non-definition, should the entry be tagged as needing a definition, or the article tagged for deletion for having no content?

I suspect that if I were to add a definition to cat as "the word spelled C-A-T", I would be blocked for vandalism. I don't see any meaningful difference between that and defining á as "the letter a with an acute accent". I've been told this is a straw-man argument, but I really don't understand what's appropriate in our entries if graphical descriptions are allowed as actual definitions.

The same applies to emojis, of course. Should an emoji of a face with tears be defined as "a face with tears", or should the definition be what it means and what it's used for? kwami (talk) 00:29, 9 May 2024 (UTC)

@Kwamikagami I agree that "the letter a with an acute accent" is not a good definition. If á had a translingual section it should at least explain how the letter is typically used across languages. I assume it usually represents some kind of /a/? Ioaxxere (talk) 01:43, 9 May 2024 (UTC)

A definition that depended on users understanding IPA, however, would be unsatisfactory. DCDuring (talk) 01:56, 9 May 2024 (UTC)

Personally, I don't see the point of a translingual section, except for things like the IPA or IAST transliteration, and this particular case would only be sum-of-parts in such cases.

But my question is what should be done with articles that have such non-definitions. Since starting this discussion, I was blocked for pasting [rfdef] tags yesterday on a bunch of articles in place of such descriptions.

So,

1. since it is not a good definition, can it be removed?
2. should it be replaced with a request for definition, or should the empty section be deleted?

kwami (talk) 01:56, 9 May 2024 (UTC)

@Kwamikagami: I think it's better to improve the definition rather than adding a ton of {{rfdef}}s as this creates lots of work for other editors. Ioaxxere (talk) 02:09, 9 May 2024 (UTC)

I agree, and I've been doing that where I can. But how do I improve the definition when there is no definition? What is the translingual definition of a letter that does not have translingual use? What is the definition of a letter that has no evidence of any kind of use? What I've been tagging are cases where I can't find any definition to provide.

The reason I've been adding rfdef tags is that I'm not allowed to delete empty entries.

So, if there's an empty article or section, one that has no content except a character box, and no definition of what's supposedly being defined, what's the solution? Do we leave it as a joke, or do we try to improve it? If we want to improve it, how do we do that, when there's no available data to improve it with?

If someone added a bunch of articles, all with the definition being "it's a word", shouldn't we at the very least tag them as needing actual definitions, even if that creates work for people? kwami (talk) 02:17, 9 May 2024 (UTC)

I've gone through and added definitions to hundreds of these articles. The ones I've tagged are ones where I can find to definition to give. It's a choice of adding a tag or leaving Wikt looking like a joke. kwami (talk) 02:24, 9 May 2024 (UTC)

Clearly, most definitions are simple descriptions, prototypically, for nouns, having a hypernym and differentia. The descriptions are also supposed to be useful to users. "The word spelled C-A-T" is not useful being redundant to the graphic representation of the headword itself, thus a straw-man. For a Latin letter with a diacritical mark it might be useful for some that the definition explained how the so-marked letter differs from the Latin character without the mark or those with other marks in each relevant character set.

A definition of a word naming an emoji might include a description as well as what the emoji is understood to mean, like a good definition of green light. The entry might also have the appropriate image, too, constituting an ostensive definition, redundant to the headword in the case of Latin characters diacritically marked. DCDuring (talk) 01:56, 9 May 2024 (UTC)

> "The word spelled C-A-T" is not useful being redundant to the graphic representation of the headword itself"

But "the letter a with an acute accent" is equally redundant to the graphic representation of the headword itself. So no, it's not a straw-man, it's reductio ad absurdum.

Because our users include many people who are not familiar with diacritical marks on Latin letters we give them an explanation of what they are looking at. Those descriptions also help those who, like me, don't have great vision and can't necessarily discriminate among the various diacritical marks and don't necessarily know the names of those marks. DCDuring (talk) 12:29, 9 May 2024 (UTC)

I have no problem with that. That's what the 'description' section is for. But it's not a definition.

We also have a pronunciation section for people who don't know how to pronounce a word. But again, the pronunciation of a word is not its definition.

In many cases I've moved the description to a description section, and tagged the definition section as needing a definition. But then people get annoyed that I'm creating work for them, because now they're expected to treat Wikt as an actual dictionary.

Much of the opposition to improving articles seems to center around it being more important for Wikt to be correctly formatted and to look good, than for it to actually contain any content or be useful as a dictionary. kwami (talk) 21:58, 9 May 2024 (UTC)

Definitions of nouns are not descriptions of the word, but of the meaning of the word. Orthography and pronunciation belong in other sections: they are not the definition itself. Why should graphemes (incl. emojis) be different? Many have (graphical) description, etymology and pronunciation sections. Those cover the description of the letter as a mark on paper or as said. A definition concerns itself with meaning. If no meaning is provided, so the reader can't tell what the symbol is for, then we're not providing a functional definition. kwami (talk) 02:00, 9 May 2024 (UTC)

BTW, we also have cases of 'translingual' sections with zero evidence of translingual use. Sometimes letters are specific to a particular language, yet they have a translingual section with no definition. All that does is push the actual definition down lower on the page, where you can't see it without scrolling. That is a minority situation, but we do have hundreds of articles with "the letter a with an acute accent"-type descriptions as their 'definition'. kwami (talk) 02:10, 9 May 2024 (UTC)

I guess my question is, if it's not acceptable to add these fake definitions, and it's not acceptable to tag them for improvement, why is it not acceptable to delete them? kwami (talk) 02:29, 9 May 2024 (UTC)

@Kwamikagami What's not acceptable is deleting them without going through RFV or RFD. Come on, we've said this many times by now. Theknightwho (talk) 02:36, 9 May 2024 (UTC)

We have the similar precedent of ligatures, an explicitly permitted 'part of speech'. Now, for त्र (tra), we have the reasonable definition "In Devanagari an irregular ligature of त and र". For characters, we sometimes benefit from having the composition pointed out. Of course, it's rarely as useful as that of ģ (“g with cedilla”). --RichardW57m (talk) 14:51, 16 May 2024 (UTC)

In the case of त्र, since we have a Translingual entry, what is the point of the Dhivehi, Hindi, and Marathi entries that don't say anything different? —Mahāgaja · talk 14:56, 16 May 2024 (UTC)

I suspect it's that nastiest of translingual issues, pronunciation, which differs between languages. --RichardW57m (talk) 17:24, 16 May 2024 (UTC)

I agree that in cases like त्र, a translingual entry makes the most sense. In many cases we will have language-specific material to add as well, but here even the pronunciations are sum-of-parts. Though the reader might not be sure of that if we don't spell it out. kwami (talk) 19:56, 16 May 2024 (UTC)

Divergent pronunciations can be seen with the ligature ज्ञ (jña); we have documented the divergence. --RichardW57m (talk) 14:06, 23 May 2024 (UTC)

That and ksh are special cases, and are unpredictable graphically and well phonetically. Most consonants + r are just sum-of-parts /Cr/. But that's the opposite question, on whether we should add predictable language-specific entries. kwami (talk) 20:58, 23 May 2024 (UTC)

@Kwamikagami The claim is that त्र is also unpredictable graphically. In some writing systems, the corresponding ligature is also not SoP phonetically, though no examples of both simutaneously came to mind. --RichardW57m (talk) 14:18, 28 May 2024 (UTC)

That makes sense. kwami (talk) 19:01, 28 May 2024 (UTC)

DCDuring, I Kinda agree. People may not know what the diacritics are called + I find it helpful that translingual sections show variations of the same character across all languages. Kwami has, in many cases, moved the character variations template to a specific language. Which is problematic as it makes no sense to put translingual latin character variations under, say, Latvian as Kwami decided to do here. Since, y'know, I doubt Latvian has every Unicode variation of 'g' and every unicode character with a cedilla in its alphabet. — SAMEER (؂・؄・؏) 17:52, 16 May 2024 (UTC)

Our lack of explicit consensus licenses some aspects of the bad behavior being complained about. I'd favor the not-so-radical solution of keeping each letter (with diacritics) only under a Translingual header, with links to language-, language-family-, or script-specific appendices that cover the complete alphabets of each language etc. in which they are used. If there is language-specific content that doesn't fit in said appendices, I would try first to make it fit by expanding the Appendix and only then allow language-specific L2s for the letter. DCDuring (talk) 18:15, 16 May 2024 (UTC)

off-topic thread on RFD

I have gone through RFV and RFD, many times. The result tends to be that ppl get annoyed because I'm making more work for them. So you're saying that if I added a definition line saying "this is a word" to thousands of articles, you couldn't revert me without going through RFD? That seems implausible. I put a bunch of empty articles and sections up for deletion, and someone started deleting them, but then there was an objection and the process stopped, never to continue because there was no clarity on what should be deleted. So, what are the criteria for deletion? When does some verbiage formatted like a definition count as a definition? That's what I'm trying to get clarity on. When should I bother putting something up for RFV or RFD, and when should I write it off as a lost cause? kwami (talk) 03:44, 9 May 2024 (UTC) @Kwamikagami You removed hundreds of entries without going through any process, and never restored them, and a few threads about a handful of entries doesn’t change that. If you still can’t understand this is why everyone got annoyed with you, you may as well get a permanent block right now, because I - and many others - are sick of your shit. Theknightwho (talk) 13:51, 9 May 2024 (UTC) @Kwamikagami the problem is that you edit like a poorly programmed bot. You just start making mass changes without thinking things through or discussing them properly. You're not always wrong, but when you are you do damage on a massive scale. I have no idea how you could think that large numbers of "translingual" entries using language codes and templates for specific languages was a good idea, for instance. Chuck Entz (talk) 14:51, 9 May 2024 (UTC) As usual, when I come here with a question of what we should do, I get no answer, only complaints that I don't come here to work out what to do. So why not answer my question when I do ask instead of constantly complaining that I don't ask? kwami (talk) 21:53, 9 May 2024 (UTC) @Kwamikagami Your question was I guess my question is, if it's not acceptable to add these fake definitions, and it's not acceptable to tag them for improvement, why is it not acceptable to delete them?, which I did answer. If you want a discussion on whether we should delete them, the forum for that is RFD, and if you wanted a discussion on whether we shouldn't add any more, then you asked the wrong question. Usually I'd be more understanding, but I won't be if you're going to keep trying to spin your out-of-policy mass removals as a reasonable course of action. Theknightwho (talk) 00:10, 10 May 2024 (UTC) So you won't collaborate, but complain if I don't collaborate. I'm not claiming it's a reasonable course of action, I'm asking, and have repeatedly asked, what the consensus course of action is. What's so difficult about this? Should we do X, or should we do Y. It's a simple question, but the answers I repeatedly get are some people saying X, some saying Y, so we can do neither. If I go to RFD, it's argued I shouldn't have done that that because it wastes people's time, and that it's inappropriate to delete items that don't meet our criteria when we apparently can't agree on what our criteria are. Is that why I never get a coherent answer? kwami (talk) 00:35, 10 May 2024 (UTC) @Kwamikagami Nobody argued that it wastes people's time to go to RFD. Theknightwho (talk) 01:34, 10 May 2024 (UTC) Someone just argued that I shouldn't RFDef because it creates a bunch of work for people. kwami (talk) 05:02, 10 May 2024 (UTC) @Kwamikagami RFD always refers to WT:Requests for deletion, which is the appropriate forum to nominate and discuss potential deletions. It has nothing to do with {{rfdef}}, which is for requests for definitions. And before you pull the "how could I have known?" card (as I'm familiar with your MO), I did say If you want a discussion on whether we should delete them, the forum for that is RFD, and you've engaged in discussions there before. Theknightwho (talk) 05:15, 10 May 2024 (UTC) I'm aware of the abbreviations. (Yes, I must be acting in bad faith. That's the only explanation for my not being satisfied with your non-answers.) I've tagged entries for both RFD and RFDef, and people have objected to both. The most recent case was for RFDef. That's why I mentioned it as a recent example. If the most recent example had been for RFD, I would've mentioned that. Doesn't really matter, the response from (some) people is the same: don't tag bad articles for improvement, it increases their workload. So far I've had one short answer to this question, by Ioaxxere. The rest has been mostly complaints. Really, I don't understand the complaining rather than explaining what the consensus is, or how we should approach if there is no consensus. kwami (talk) 05:25, 10 May 2024 (UTC) To summarise: You: If I go to RFD, it's argued I shouldn't have done that that because it wastes people's time Me: Nobody argued that it wastes people's time to go to RFD You: Someone just argued that I shouldn't RFDef because it creates a bunch of work for people Me: RFD always refers to WT:Requests for deletion, which is the appropriate forum to nominate and discuss potential deletions. It has nothing to do with {{rfdef}} You: I'm aware of the abbreviations. (Yes, I must be acting in bad faith. That's the only explanation for my not being satisfied with your non-answers.) Are you for real? For months people have been saying you need to use the RFD process, so as an excuse this simply comes off as ridiculous. Theknightwho (talk) 05:30, 10 May 2024 (UTC) Can you not answer a fucking question? Must it always be sidestepping and innuendos and dodging responsibility? Last time I asked, I was told the proper place for this discussion was the Beer Parlour. So here I am at the Beer Parlor. You say one thing, someone else says something else. Do your opinions take precedent over anyone else's? The question isn't just about deletion, but what should be done with fake definitions. Should they be tagged, or deleted, or are they what we want for all articles? I could shuffle back and forth between here and RFD, but if people like you refuse to answer in good faith, that won't do any good. Why can I never get a simple answer to a simple question in this place? People ask why I don't get consensus before making a change. Well, this is why: a bunch of quarreling and refusing to engage in the question at hand, so that nothing gets accomplished. kwami (talk) 05:37, 10 May 2024 (UTC) @Kwamikagami To repeat myself: if you want to nominate existing articles for deletion, then they need to go through RFD. If you think we shouldn't have any entries like that at all, then let this discussion play out, and people will comment on it - it's obviously not a question I can unilaterally decide, and I don't have particularly strong opinions on it. What I do have strong opinions on is the way you repeatedly try to make your messes everyone else's fault, but I have better things to be doing with my time right now. Theknightwho (talk) 05:43, 10 May 2024 (UTC) If you think I should let this discussion play out, well, that's what I'm here for. I'm collapsing this thread as it doesn't address the question I posed. kwami (talk) 05:53, 10 May 2024 (UTC)

English anagrams

English anagrams haven't been updated in a while. Could someone run a bot to update them? Maybe @Kiril kovachev, Benwing2 Ioaxxere (talk) 01:43, 9 May 2024 (UTC)

@Ioaxxere I can try, but I'm not sure if I trust myself to do it properly. Specifically the part of which characters (like punctuation) should be removed when comparing two words. Kiril kovachev (talk・contribs) 12:41, 9 May 2024 (UTC)

@Kiril kovachev: It doesn't matter too much, since the vast majority of English terms don't have any special characters. Punctuation (periods, commas, etc.) as well as different casing should definitely be ignored, but I have no preference with respect to diacritics. Ioaxxere (talk) 15:45, 9 May 2024 (UTC)

@Ioaxxere Okay, I've updated the word list I am using, so it should be ready to run, but I've run it a bit to get some sample edits. Should it consider e.g. lork and kröl to be anagrams? Or Nº and no etc.? In the case of diacritics I also don't have much of a preference, and it can be configured to not remove them if we want. I can make it run as-is if this seem ok. Kiril kovachev (talk・contribs) 13:11, 15 May 2024 (UTC)

@Kiril kovachev: Looks good. Will the bot be running continuously or on a schedule, e.g. updates every 3 months? Ioaxxere (talk) 14:22, 15 May 2024 (UTC)

It's based on what words are currently on Wiktionary (I got the parsed data from kaikki.org, which is updated ~every month), so I can make it run every time the words are substantially different. I can run it every 3 months if you like, as long as we don't spot any obvious problems. Kiril kovachev (talk・contribs) 16:24, 15 May 2024 (UTC)

@Ioaxxere (forgot ping) Kiril kovachev (talk・contribs) 16:25, 15 May 2024 (UTC)

Sounds good. Ioaxxere (talk) 16:32, 15 May 2024 (UTC)

@Ioaxxere We had a bit of a stall, since there's a little problem with the code when the entry contains a "/" in it, but I'll be working on a fix these few days. Actually it shouldn't be too complicated so hopefully we'll be back soon :) I don't know how long this is gonna take though, as it was going for a few hours already before it even managed to crash. I'll let you know again when I figure out how long it'll be... Kiril kovachev (talk・contribs) 15:41, 22 May 2024 (UTC)

@Kiril kovachev: Is there any update on this? The bot hasn't been running for over a month. Ioaxxere (talk) 21:33, 29 June 2024 (UTC)

@Ioaxxere Sorry, I was thinking about it again today. I just finished with school for now. I kind of forgot, thanks for reminding me... I don't know why I made such a fuss about it, as the fix only actually took about 2 minutes! It's off running again now, but who knows how long it'll take. I haven't figured out anything like a progress bar or whatever, so I'll let it go for as long as it needs for now :) Sorry for all the delay. Kiril kovachev (talk・contribs) 22:23, 29 June 2024 (UTC)

@Ioaxxere Ugh, it crashed on another ridiculous page name, $$$, for some reason. I'll have to figure it out. In the meantime, I will also fix the fact that it hasn't been sorting the anagrams in alphabetical order in each anagrams section (I will make another script to fix that on existing entries). Kiril kovachev (talk・contribs) 22:24, 30 June 2024 (UTC)

becocked, and whether we want Trivia sections

Recently, Trump used the word becocked, which attracted some attention because it's an unusual word, and quite a lot of people thought he'd made it up (even though he didn't). Is this the kind of thing we want to note in trivia sections? To me, it seems like the kind of thing no-one will care about in a month, and that it adds pointless clutter. Pinging @Ioaxxere, who originally added it as a usage note, but later changed it to the little-used Trivia heading. Theknightwho (talk) 02:12, 9 May 2024 (UTC)

His use of the term attracted some media coverage ([4] [5]) making it probably the most notable event in the history of becocked. Does a single sentence about this really add so much clutter? Ioaxxere (talk) 02:18, 9 May 2024 (UTC)

Ask yourself this: in two years' time, if someone came across this in an entry, would they feel like this addition was the cringeworthy result of terminally online recency bias? Almost certainly yes. It's basically just celebrity gossip. Theknightwho (talk) 02:21, 9 May 2024 (UTC)

"X said this word" should never go in Trivia/Useful Notes. It can go as a quote, however. CitationsFreak (talk) 03:08, 10 May 2024 (UTC)

I agree completely. I think trivia sections should chiefly be used for things like noting that a word is thought to be the longest in a particular language, has no vowels, doesn’t rhyme with any other word—that sort of thing. — Sgconlaw (talk) 11:35, 10 May 2024 (UTC)

I agree too. PUC – 19:24, 11 May 2024 (UTC)

Manipuri vs Meitei language (moved to RFM)

Discussion moved to WT:RFM#Manipuri vs Meitei language.

Performing bulk edits for Bengali/Bangla

Discussion moved from Wiktionary talk:Beer parlour/2024/May.

I'm a NLP researcher who uses Wiktionary to collect pronunciation data. As part of this effort we have noticed various inconsistencies in phonemic transcription. For example,

1. According to various sources (Khan, 2010; Dasgupta, 2003, Ferguson & Chowdhuri, 1960; Chatterji, 1970), Bengali have only one voiceless glottal fricative /h/, so /ɦ/ > /h/. E.g.: অকৃতোদ্বাহ 'bachelor' /ɔ.kri.t̪od̪.ba.ɦo/ > /ɔ.kri.t̪od̪.ba.ho/. This IPA symbol is not correctly represented in Wiktionary Bengali transliteration guide. Therefore, I propose to edit the guide.

2. The correct phonemic transcription (ref. Dasgupta, 2003, Ferguson & Chowdhuri, 1960; Chatterji, 1970) for affricates should include the tie-bar, so /tʃ, t͡ʃʰ, dʒ, d͡ʒʱ/ > /t͡ʃ, t͡ʃʰ, d͡ʒ, d͡ʒʱ/. E.g.:চরম 'extreme' /tʃɔɾom/ > /t͡ʃɔɾom/, ছায়াছবি 'film' /tʃʰae̯atʃʰbi/ > /t͡ʃʰae̯at͡ʃʰbi/, জল 'water' /dʒɔl/ > /d͡ʒɔl/, ঝিনুক 'sea shells' /dʒʱinuk/ > /d͡ʒʱinuk/. This tie-bar is not included in Wiktionary Bengali transliteration guide. I proposed to include this tie-bar for affricates symbols.

3. According to various sources (Khan, 2010; Dasgupta, 2003, Ferguson & Chowdhuri, 1960; Chatterji, 1970), Bengali doesn't have palatal plosive /c and ɟ/. Instead it has post alveolar affricates (ref. https://en.wiktionary.org/wiki/Wiktionary:Bengali_transliteration). Therefore, /c/ > /t͡ʃ/ and /ɟ/ > /d͡ʒ/. E.g. : অগোচর 'beyond one's knowledge' /ɔɡocɔr/ > /ɔɡot͡ʃɔr/, অগ্নিযুগ '(figurative) the age of revolution' /oɡniɟuɡ/ > /oɡnid͡ʒuɡ/.

Does there exist any tool or API that could allow us to apply bulk edits? If this sounds right, I will start to make corrections. Arundhatisgupta (talk) 16:06, 9 May 2024 (UTC)

I relocated this post because it was in the wrong place. — Sgconlaw (talk) 16:20, 9 May 2024 (UTC)

The IPA has long held that the tie bar is not necessary when transcribing languages that don't distinguish affricates from stop-fricative sequences. If Bengali doesn't distinguish /t͡ʃʰ/ from ?/tʃʰ/, then our current transcription convention is fine.

In describing the phonetics of a language, you want to be as precise as possible, so the ties are a good thing. But with a key like we have, they're not necessary.

The tie bars clutter a transcription and can make it more difficult to read. If we did implement them, it would probably be better to use the under-tie, ⟨t͜ʃʰ⟩. That's generally more legible because our eyes pick up details better at the top of a symbol, so the under-tie is less distracting. kwami (talk) 05:12, 10 May 2024 (UTC)

While "the tie bar is not necessary", it is good practice to include it and most languages on Wiktionary do. I don't see why Bengali would be an exception. Thadh (talk) 11:36, 10 May 2024 (UTC)

I agree with @Thadh.

@kwami It is not necessary for English as well. Why did you included it in English? Also, there is no consistency. If you think it is not necessary then make sure that you maintain that consistency. E.g.: অগচ্ছিত 'not entrusted to anyone' /ɔɡot͡ʃt͡ʃʰit̪o/ has the tie bar but চরম 'extreme' /tʃɔɾom/ doesn't. What do you think about that? Arundhatisgupta (talk) 16:37, 10 May 2024 (UTC)

Whichever convention is chosen, it should be consistent, and should match the key. kwami (talk) 19:19, 10 May 2024 (UTC)

There will be a confusion when /t/ and /ʃ/ occurs together but they are not affricate. E.g. কুৎসা 'slander' /kutʃa/ and বচসা 'contention' /bɔtʃoʃa/. Without a tie-bar they seems like having similar pronunciation for /tʃ/ but the correct pronunciations are - /kutʃa/ and /bɔt͡ʃoʃa/. Arundhatisgupta (talk) 16:51, 10 May 2024 (UTC)

That can be handled as ⟨kut.ʃa⟩ and ⟨bɔtʃoʃa⟩ or as ⟨kutʃa⟩ and ⟨bɔt͜ʃoʃa⟩ -- or, for maximal clarity, as ⟨kut.ʃa⟩ and ⟨bɔt͜ʃoʃa⟩. Just as long as we're consistent, or people will get really confused. kwami (talk) 19:22, 10 May 2024 (UTC)

I personally think there should be a tie bar and it should go above, which is the more common practice. Benwing2 (talk) 21:06, 10 May 2024 (UTC)

@Kwamikagami 1. If you are introducing a syllable break (indicating with a dot), then it should be applied consistently for all words in Wiktionary.

2. According to Wikipedia, undertie is used to represent linking (absence of a break) in the International Phonetic Alphabet. E.g.: /vuz‿ave/ (Ref. https://en.wikipedia.org/wiki/Tie_(typography)#cite_note-6) Arundhatisgupta (talk) 21:34, 10 May 2024 (UTC)

Linking is used to override the orthographic spaces we insert between words in transcription. In that example, the words are //vuz ave// but the pronunciation is /vu.za.ve/. The /za/ forms a single syllable. That tie is not the same thing as the 'slur' tie used for affricates, which comes from musical notation (slurred notes). kwami (talk) 21:56, 10 May 2024 (UTC)

I think that there should be tie bar and it should go above, which is the more common and establish practice for phonemic/phonemic transcription. It is important to maintain the consistency within language and across Wiktionary.

Is there any objection regarding other inconsistencies mentioned in the proposal? Arundhatisgupta (talk) 09:52, 11 May 2024 (UTC)

@Arundhatisgupta No objections from me although I don't know enough about Bengali phonology to say whether e.g. the use of palatal plosives or affricates is correct. IMO the best way to go about making these changes is either manually or through AWB or JWB, which let you quickly do semi-manual changes based on regexes. Benwing2 (talk) 18:15, 11 May 2024 (UTC)

@Benwing2 Could you please add me to Wiktionary:AutoWikiBrowser/CheckPageJSON ? Arundhatisgupta (talk) 14:39, 14 May 2024 (UTC)

@Benwing2 I tried to sign in AWB and it's saying that my username is not enabled to use AWB. Could you please help me? Arundhatisgupta (talk) 13:52, 22 May 2024 (UTC)

@Benwing2 Thank you for adding me on CheckPageJSON. I am able to edit the IPA pronunciation for some word where the pronunciation is given as- * { {IPA|bn|/IPA/} }, for example, গহির but I'm not able to edit the pronunciation where it is given as - " *{{ bn- IPA} }", for example, ছায়াছবি or '{{ bn-IPA } }', for example. গহনা. Could you please suggest me how can I edit those pages? If they are linked to any database, is there a way to access or update that database? Arundhatisgupta (talk) 12:54, 25 May 2024 (UTC)

@Arundhatisgupta Pages that use {{bn-IPA}} are backed by a module, which auto-generates the pronunciation. In general it's preferred to use {{bn-IPA}}, possibly with respelling, instead of directly specifying the pronunciation using {{IPA|bn|...}}, because it ensures more consistent results. If you want to change the way the module works, you have to edit the Lua code that implements the module, but before doing that you should get consensus from other Bengali editors that this is the right thing to do. Benwing2 (talk) 17:53, 25 May 2024 (UTC)

@Benwing2 I want to do that. Please let me know if anyone has any objection for the changes that I proposed specially 1 and 2. 71.168.227.237 16:59, 28 May 2024 (UTC)

You need to look around to see who the Bengali editors are, and ping them. Benwing2 (talk) 18:40, 28 May 2024 (UTC)

@Benwing2 Where/how should I look for them? Arundhatisgupta (talk) 14:25, 30 May 2024 (UTC)

@Arundhatisgupta Look at the history of various Bengali language pages and see who created and/or edited them. Benwing2 (talk) 22:54, 30 May 2024 (UTC)

Pinging recently-active users from Category:User bn-N: do any of you have opinions on the changes proposed above, in particular changing /ɦ/ to /h/ in notations of Bengali pronunciation, adding tie bars, changing /c/ to /t͡ʃ/, and changing /ɟ/ to /d͡ʒ/? @Syzarn, Smartiphone7, Shaiwala, Sbb1413, Ash wki, AlZawad26. - -sche (discuss) 23:11, 30 May 2024 (UTC)

Adding @Asm sultan, @Deepon,@শরদিন্দু ভট্টাচার্য্য, @Tanweer Morshed, @BrightSunMan,@Countincr, @Hermitage17, @Intellectual Bookworm, @Laser Victor 2017, @Lira Rakshit, @Lira Rakshit, @Sbb1413, @Tanweer Morshed, @Vyutpatti, @Wikispeedier Arundhatisgupta (talk) 01:26, 31 May 2024 (UTC)

@Benwing2 As there is no objection/opinion, can I proceed with Lua module correction? How can I be an "autoconfirmed user" to make any changes in bn-IPA module? Arundhatisgupta (talk) 14:16, 3 June 2024 (UTC)

Yes, you may proceed, and I apologize that we've made you wait only for no-one else with Bengali-specific knowledge to actually weigh in (I had hoped more people (or even any people) knowledgeable of the topic would be able to express informed opinions about it). Are you getting a message that you can't edit that module because of the protection, or is it just warning you that you are editing a protected page? (If it were actually stopping you from editing, you wouldn't see an "edit" button, just a "view source" button.) If you're being stopped by the protection, I'm not sure why... it's set to "autoconfirmed users" (not even "autopatrolled", just "autoconfirmed"), and my understanding based on Wiktionary:Autoconfirmed users is that accounts older than 4 days with at least 10 edits are automatically autoconfirmed; your account is years old and has thousands of edits, so if you actually can't edit the module because of the protection, I guess either Benwing or another 'crat could grant you the "confirmed" group (which I as a mere admin can't grant, but I'm guessing bureaucrats can?), or I or another admin can just temporarily unprotect the module. All of this is assuming you understand how the module works well enough to edit it, yes? If not, one of our technical editors can help. Btw, personally I am inclined to agree with Kwami that if there are cases of tʃ across a syllable break which are specifically not t͡ʃ, it would be useful to explicitly indicate this not only by giving t͡ʃ its tie, but by marking the break in t.ʃ. - -sche (discuss) 01:54, 4 June 2024 (UTC)

Yes, I can turn on the "confirmed user" setting, but Special:UserRights/Arudhatisgupta says you're already an implicit member of Autoconfirmed users, so if somehow you're not able to edit the page, something else is going on and we should investigate. Other than that, I agree with User:-sche about adding both a tie bar and a syllable break in cases where the tie bar isn't appropriate. Benwing2 (talk) 03:29, 4 June 2024 (UTC)

@-sche@Benwing2 It was warning me that I am editing a protected page. It would be great if I get help from one of the technical editor as I am not quite familiar with the the module and I don't want to mess up. Regarding the corrections, I agree all around. Arundhatisgupta (talk) 14:37, 4 June 2024 (UTC)

@-sche and @Benwing2 Update: I updated the module for the proposed changes. I didn't added a syllable break because for Bengali dental consonant is transcribed as [t̪]. Therefore, we don't have any conflict between [t͡ʃ] and [t̪ʃ], for example, বৎসর and বছর. Arundhatisgupta (talk) 15:31, 6 June 2024 (UTC)

@Arundhatisgupta OK, sounds good to me. Benwing2 (talk) 08:11, 9 June 2024 (UTC)

How should we present Latin adjectives that inflect like nouns (or that are really appositive nouns?)

A few times now, I've been puzzled about how to handle showing the inflected forms of certain Latin third-declension adjectives that don't fit well into any of the usual adjective inflection patterns, because they show the endings typical for a noun instead. Currently, these seem to mostly be treated in our entries as third declension adjectives of "one ending", but I think there are some issues with the accuracy of this in terms of showing forms and usage.

A particularly clear case is certain rare words that are attested with adjectival function but that have the form of feminine nouns, such as silvicultrīx, -trīcis and Nīlōtis, -tidis (which have the forms respectively of Latin and Greek feminine agent nouns). The masculine counterparts would presumably be *silvicultor and *Nīlōtēs, but these do not to my knowledge occur, and in any case, we normally treat agent nouns as noun lemmas (distinct for masculine and feminine) rather than combining the masculine and feminine versions under one adjective lemma. Should we lemmatize such words as nouns and include a usage note saying that they're used appositively? Or should we put them as adjectives (as many dictionaries do) but include some kind of special headword and declension table coding to avoid showing masculine or neuter forms, which I think aren't accurate in this case? For example, Gaffiot marks silvicultrix as "adj. f".

Not quite as clearcut are cases like senex, iuvenis, mās that generally have the form of nouns, commonly function as either nouns or as adjectival or appositional modifiers of masculine or feminine nouns, but are extremely rare or unattested in the neuter. (I've found some neuter forms attested in some cases in New Latin.) Functionally, I think there isn't much difference between how mās and fēmina are used, but we treat mās as a noun or adjective and fēmina as only a noun. Urszag (talk) 02:49, 11 May 2024 (UTC)

@Urszag We have a whole category Category:Latin first declension adjectives for words like amnicola and indigena that don't seem so different from the words you've cited, and there are unquestionably third-declension non-i-stem adjectives (e.g. vetus, concolor) that "show the endings typical for a noun", so I don't see an issue treating these as adjectives. Benwing2 (talk) 05:33, 11 May 2024 (UTC)

Yes, we have that category for first-declension adjectives. The full inflection of those words as adjectives is actually a bit questionable also (there was an RFV that I closed based on New Latin examples, but I added some notes in Appendix:Latin_first_declension discussing how the neuter plural nominative/accusative/vocative forms in -a and dative/ablative forms in -īs are rather hypothetical and ambiguous, as they've often (at least since Priscian's time) been interpreted as belonging to a second-declension paradigm instead (e.g. that of indigenus).

Third-declension non-i-stem adjectives such as vetus exist, but are rare (aside from comparative forms). When there are attested neuter forms distinct from the masculine/feminine forms (such as vetus in the accusative singular, or vetera in the nominative/accusative plural), this establishes that a word is formally distinct from an appositive noun (and also establishes whether the neuter plural ends in -ia or -a, which can't always be predicted from the forms of the ablative singular or genitive plural). But I think that such neuter forms are often unattested (except sometimes in very late periods of the language) and in that case it's arguably misleading to just present a single full declension table. E.g. I found iuvenia once in Medieval Latin and occasionally in New Latin, and a couple of New Latin cases of iuvena (both from the same author), but I think it's more misleading than not to present either of these as established or standard Latin forms: a late imperial-era grammarian says that this word simply lacks neuter plural forms. In cases like this, there's an existing parameter to mark an adjective as lacking neuter forms, so I ended up using that and mentioning other forms in usage notes. But in cases like silvicultrīx and Nīlōtis, I don't know how to best present the fact that they occur only as adjectival modifiers of feminine nouns: for now I've just removed the declension table from the second word (since several forms are unattested, or only attested in post-Classical texts, and the Greek origin makes it tricky to actually infer what missing forms would be), but for silvicultrīx it seems fairly clear that it would simply inflect like victrīx. If we continued to categorize these as adjectives, does it sound reasonable to establish a parametric way to mark them as feminine-only?--Urszag (talk) 06:33, 11 May 2024 (UTC)

@Urszag Yes, I think so. We have done that for some other languages, e.g. French adjective headwords have an |onlyg= parameter that you can set to a gender (m or f), a number (s or p) or a gender-number combination (e.g. m-s, f-p). Now mind you, some of the terms that make use of this (e.g. enceinte) would IMO be better treated as conventional adjectives that are simply rare in other genders or numbers; there's even a usage note for enceinte that says

The masculine form enceint is occasionally used with regard to transgender men, for species with male pregnancy such as seahorses, as well as in metaphorical, jocular, or fantastic contexts.

And indeed you will find that in Spanish, the corresponding words like encinto, embarazado and preñado are given in the masculine, with quotes establishing that such usage does exist. But if the term is indeed unattested in some genders, I would definitely support adding a flag to suppress those genders in the declension table and make sure that the title next to the declension table reflects this. Benwing2 (talk) 06:53, 11 May 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Benwing2 Thanks for the feedback! After looking over words of this type some more, here are the categories that I would propose adding for now:

• Category:Latin defective adjectives (like Category:French defective adjectives.)
  • Category:Latin adjectives used only in the feminine
    • Category:Latin third declension adjectives used only in the feminine: e.g. Nīlōtis, silvicultrīx, dēlētrīx, cantātrīx, accelerātrīx
    • Category:Latin fourth declension adjectives used only in the feminine: anus (not sure if a category is needed just for this one word)
  • Category:Latin third declension adjectives used only in the masculine: e.g. victor, altor, ultor (“avenging”)
  • Category:Latin third declension adjectives used only in the feminine and neuter: e.g. victrīx, altrīx, ultrīx, peccātrīx
    • These differ in having attested neuter plural nominative/accusative forms in -trīcia. Grammarians say they lack neuter singular forms ("omnia nomina a verbo venientia cum in 'or' exeunt, masculina sunt, ut victor; cum in 'trix', feminina sunt, ut victrix; neutra vero non faciunt, nisi tantum ex numero plurali: unde est victricia", Servius).

The ones starting with Category:Latin third declension adjectives ... would be subcategories of Category:Latin third declension adjectives, since they don't really fit into any of its existing subcategories (Category:Latin third declension adjectives of one termination, Category:Latin third declension adjectives of two terminations, Category:Latin third declension adjectives of three terminations). The alternative of treating adjectival victor and victrīx as one lemma seems undesirable to me since a) -trīx is otherwise a derivational, not an inflectional morpheme and b) for some words, such as silvicultrīx and dēlētrīx, the corresponding masculine -tor forms do not even seem to be attested yet in Classical Latin, which makes it seem wrong to list them as inflected forms of a *-tor lemma. I still think it might make sense to simply avoid lemmatizing any of these -tor/-trīx forms as adjectives: it's a bit hard to draw a bright line separating adjectival use from appositional use of a noun, and there are quite a few masculine forms in -tor and feminine forms in -trīx that can be used as either nouns or adjectives (Neue mentions a long list including aedificator, bellator, bellatrix, amator, infector, praedator, creatrix). That said, some of the rare or hapax forms like silvicultrīx and Nīlōtis are only attested in adjectival use, and it might be odd to treat their part of speech as a noun. And a small number have neuter nom/acc plural forms in -trīcia. Furthermore, the use of these forms is a bit more like an adjective because you do generally need to match the gender of the modified noun, unlike words like flūmen which are freely used in apposition with non-neuter nouns. For words like victor and cantātrīx that are attested with both noun and adjective uses, but don't have any attested neuter forms, it might make sense to use an intermediate format something like I did currently at anus: include a separate adjective header, but no separate declension table when the forms are identical to those of the noun.

Aside from the creation of the above categories, Template:la-adj would need to be modified to have some kind of parameter, like onlyg=, that would make it display an appropriate gender marker and put the adjective in the right gender category. It would also make sense to have a way to list and link to a corresponding masculine or feminine form using a parameter like |m= or |f=, just as with nouns like altrīx. If we go with the route of not showing a separate declension table for the adjective when it is identical to the noun, then the only modification I think that would be needed to Template:la-adecl is to add some way to replace Masc./Fem with Fem alone in the table for adjectives like peccātrīx. Relatedly, I would like it if I could replace Masc./Fem. with Masc. in the table for the pronoun quisquam, since the forms quōquam and quīquam are I think attested only for the masculine and neuter, and other forms, although attested in certain circumstances in the feminine, are fairly exceptional and seem better mentioned in usage notes rather than in the table.

Do these proposed categories and names for them sound good?--Urszag (talk) 05:15, 23 June 2024 (UTC)

@Urszag This is a lot to digest but here are my thoughts:

1. I'd prefer to use category names like Category:Latin feminine-only adjectives, Category:Latin third declension masculine-only adjectives, Category:Latin third declension feminine and neuter-only adjectives (for the latter maybe Category:Latin third declension feminine- and neuter-only adjectives or some other hyphenation), etc. These are consistent with e.g. CAT:English comparative-only adjectives, CAT:Russian short-form-only adjectives, CAT:Dutch predicative-only adjectives, etc.
2. As for "list and link to a corresponding masculine or feminine form", can you give some specific examples of template calls as you envision them? That will make it easier for me to see what you mean. Benwing2 (talk) 05:36, 23 June 2024 (UTC)

Those names seem fine to me too. For the template calls in the headline, I was basically envisioning something that looked and functions like la-noun|victrīx<3>|m=victor (at victrīx; likewise at victor) but for la-adj, so we would have something like la-adj|victrīx<3>|g=f|m=victor producing "victrīx f (genitive victrīcis, masculine victor); third declension feminine- and neuter-only adjective"--Urszag (talk) 05:48, 23 June 2024 (UTC)

@Benwing2 I looked at more examples, and I am now fully in favor of categorizing these uses of -tor/-trīx words as genuine adjectives as they can be modified by adverbs. I have found no evidence so far of masculine adjectives in -tor being inflected differently from the corresponding nouns, whereas -trīx words show some additional inflected forms (I updated the declension table at victrīx and I think it is currently accurate).

Here are some more detailed examples of the types of calls I would like to be able to make to la-adj that Module:la-headword can't currently handle. For the ones that can be two genders, I don't know whether using a comma as in "f, n-pl" and "m, f" is best, or something else like "f/n-pl" and "m/f".

For words like Nīlōtis:

• • {{la-adj|Nīlōtis/Nīlōtid<+.-I>|onlyg=f}}
  • producing the following headword line: Nīlōtis f (genitive Nīlōtidis); third-declension defective adjective (feminine-only, non-i-stem)
  • and adding it to the following categories: Category:Latin third declension feminine-only adjectives, Category:Latin third declension adjectives, Category:Latin feminine-only adjectives, Category:Latin defective adjectives

For words like victor:

• • {{la-adj|victor<+.-I>|onlyg=m|f=victrīx}}
  • producing the following headword line: victor m (genitive victōris, feminine victrīx); third-declension defective adjective (masculine-only, non-i-stem)
  • and adding it to the following categories: Category:Latin third declension masculine-only adjectives, Category:Latin third declension adjectives, Category:Latin masculine-only adjectives, Category:Latin defective adjectives

For words like victrīx:

• • {{la-adj|victrīx|onlyg=f, n-pl|m=victor}}
  • producing the following headword line: victrīx f (genitive victrīcis, masculine victor); third-declension defective adjective (feminine- and neuter-only)
  • and adding it to the following categories: Category:Latin third declension feminine- and neuter-only adjectives, Category:Latin third declension adjectives, Category:Latin feminine- and neuter-only adjectives, Category:Latin defective adjectives

For iuvenis:

• • {{la-adj|iuvenis<3-1+.-I>|onlyg=m, f|comp=iūnior|comp2=iuvenior}}
  • producing the following headword line: iuvenis m or f (genitive iuvenis, comparative iūnior or iuvenior); third-declension defective adjective (masculine- and feminine-only, non-i-stem)
  • and adding it to the following categories: Category:Latin third declension masculine- and feminine-only adjectives, Category:Latin third declension adjectives, Category:Latin masculine- and feminine-only adjectives, Category:Latin defective adjectives

For anus:

• • {{la-adj|anus<4>|onlyg=f}}
  • producing the following headword line: anus f (genitive anūs); fourth-declension defective adjective (feminine-only)
  • and adding it to the following categories: Category:Latin defective adjectives, Category:Latin feminine-only adjectives, Category:Latin defective adjectives

Default font size for polytonic Greek

Does anyone else think the default font size for polytonic Greek should be increased? It looks small to me, especially in SBL Greek, which is the font with the highest priority in the CSS. Weylaway (talk) 19:55, 12 May 2024 (UTC)

It seems OK to me; can you post screen shots showing how it looks for you? BTW I do notice when comparing polytonic Ἀριστοτέλης (Aristotélēs) to non-polytonic Αριστοτέλης (Aristotélis) that the latter seems relatively ugly because it uses a sans-serif font. Benwing2 (talk) 21:17, 12 May 2024 (UTC)

FWIW, this is what it looks like for me (top is the level of zoom I usually use, bottom is 100% zoom). - -sche (discuss) 22:13, 12 May 2024 (UTC)

Interesting; your polytonic looks sans-serif, while your non-polytonic looks more serif, which is the reverse of what I see. Benwing2 (talk) 22:19, 12 May 2024 (UTC)

For non-polytonic, it's using Gentium for me, the second font in the list (because I don't have Athena, the first font in the list). For polytonic it was using DejaVu Sans (the third font in the list, because I didn't have SBL Greek or Athena). Now that I've downloaded SBL Greek, it looks like this, displaying polytonic in SBL Greek, which is heavily (IMO distractingly) serifed and slanted and handwritingesque. SBL Greek polytonic text is indeed smaller than other text, though not unreadably so IMO. (But I do think SBL Greek looks worse than other fonts in the list, so I might be tempted to move it down in the ranking... but perhaps it is first because it has the best diacritic support?) - -sche (discuss) 06:56, 13 May 2024 (UTC)

@-sche Hmm. I checked using the Computed tab in Chrome and, if it's correct, my polytonic font is using Times (postscript name "Times-Roman"), which is way down the list, and my non-polytonic font is Arial Unicode MS, which is likewise way down the list. Maybe this is because I'm on a Mac, although I'm surprised there aren't more fonts installed by default. BTW here is what it looks like: [6] Benwing2 (talk) 07:25, 13 May 2024 (UTC)

I personally think SBL Greek looks the best and I use a custom style to display it at 130% size. I was just thinking of learners who may find the default hard to read – in -sche's example the x-heights of the Greek letters are smaller than those of the Latin letters next to them. But clearly there is variation across operating systems and difference in personal preference, so maybe it's better for me just to use my custom style. Weylaway (talk) 17:46, 13 May 2024 (UTC)

Thank you @Weylaway for your question. Greek (script Grek, polyonic and monotonic alike) look miserable and small at en.wikt. I have no idea what the default font is for this site (as in sc=Latn), or what the designers wish their readers to view. Default looks much beter. Or perhaps an equivalent making sure that grave accent is shown (not a vertical accent). User:Sarri.greek/fonts#default. Ancient Greek inflectional tables, which should have a 110%, are even smaller. Even the prosody marks look better with normal default fonts. Thank you again, for putting this. ‑‑Sarri.greek ^♫ I 21:38, 13 May 2024 (UTC)

Blottoism

Don't let him die forgotten. Talk:upput. I hope my gastric bad temper will also survive. True story: our librarian/researcher has asked me why our system contains some non-existent records. It's because Artefactual's API is wrong. But I've got half a day of billable debugging before I can prove it. Equinox ◑ 02:00, 13 May 2024 (UTC)

Old Pskovian

I propose to add an etymological code for Old Pskovian (~zle-ops?), as part of Old Novgorodian (zle-ono) in the branch of East Slavic languages. Cases of mention of Old Pskovian. This is a dialect and variety of Old Novgorodian, which was in ancient Pskov and its environs (https://ru.wikipedia.org/wiki/Древнепсковский_диалект). What do you think @Thadh? AshFox (talk) 04:29, 13 May 2024 (UTC)

Don't see any issue with this. If nobody opposes, I'll add it in a week or so. Thadh (talk) 19:23, 13 May 2024 (UTC)

No objections. Benwing2 (talk) 20:32, 13 May 2024 (UTC)

@Thadh it seems good, no one is against it. A week has passed. Please add Old Pskovian when you have free time. AshFox (talk) 09:55, 20 May 2024 (UTC)

Should we split up multi-language pages?

Currently, a user trying to get to da#Zhuang on desktop has to:

1. Type "da" into the search bar.
2. Wait for the massive page to load (this could take a while on older devices or on slower connections).
3. Scroll for a very long time until reaching "Zhuang" in the table of contents.
4. Click it.

On mobile, the situation is even worse since in fact there is no table of contents.

Maybe a better option would be to have da function as a sort of disambiguation page which lists all of the available languages in a compact table. In this case, the user would quickly be able to locate and click "Zhuang" which would take them to da/Zhuang. Also, since da and da/Zhuang would both be very compact, the loading times would be practically instantaneous.

Also, doing this would also solve all of our Lua-related problems (at least for the near future). What do we think @Chuck Entz, Benwing2, Theknightwho? Ioaxxere (talk) 05:50, 13 May 2024 (UTC)

@Ioaxxere This has been proposed various times but it would be an enormous undertaking and would (of course) have some downsides, such as requiring more clicks to view anything and not so easily being able to see the similarities among different languages that share the same spelling. Maybe a less radical solution for the time being would be, as Chuck proposes, to move letter information out of letter pages into an Appendix or something. Benwing2 (talk) 05:58, 13 May 2024 (UTC)

(Not saying I think we should split pages, but) something I suggested in past discussions which would address the "more clicks to view anything" problem is : if we split, transclude the subpages back onto the 'main' entry, so someone looking up e.g. the main sender page rather than sender/da still sees all the languages. Transclusion could be the default, and for the few pages with excessively many language sections where it wouldn't be feasible (particularly because I think transcluding a page causes it to count 2x against the PEIS limit? and causes any templates it transcludes to thus count 4x? and even Tim Starling has said that raising the PEIS limit is not something the devs will do), we could fall back on having a table like Ioaxxere suggests. BTW I think the usual proposal is to use language codes in naming the subpages, rather than language names, which may be long and contain untypable characters. Either way, we have to watch out for conflicts with pages that actually contain slashes, e.g. s/he.
In this case, I'm inclined to agree that moving the letters to alphabet appendices is a solution to most of the immediate problem. Let something like Appendix:Dutch alphabet give the names and pronunciations of all the Dutch letters in one place, rather than giving them on a, b, etc. Just have a ==Translingual== entry on a and maybe categorize all the Appendices that use a into a category like "Category:Alphabets that use Latin a" or something and then have a link in the Translingual entry to that category...? - -sche (discuss) 06:31, 13 May 2024 (UTC)

@-sche: I'm very confused as to why letter entries are being mentioned? The initial page mentioned is da which isn't even about a single letter. There's only one "letter name" entry on it being Tagalog da. mi is one of the worst pages, if not the worst, when it comes to this, so again, trying to focus on letters is not the way to go about it. This type of proposal was proposed in 2020 and was not passed then either. Also, as I mentioned on said vote, most of the bytes on a aren't from letter entries either. Let's focus on finding a solution that actually fixes the overarching problem, rather than throwing us into the issue of letters again. AG202 (talk) 14:13, 13 May 2024 (UTC)

Additionally, the notion of moving letter entries comes from a clear, whether intentional or not, Latin script language-bias. As I mentioned in the vote, entries like ㄴ (n) should not belong in an Appendix or Translingual just because some other languages on Wiktionary do their letter entries poorly. AG202 (talk) 15:24, 13 May 2024 (UTC)

@AG202: It's definitely not a Latin-script bias. The same applies to Cyrillic, Greek, Perso-Arabic, Georgian... The fact that certain writing systems are slightly more complex and language-specific doesn't mean that all those that aren't deserve an entry for every language and every grapheme.

By the way, I don't see a Jeju entry for ㄴ, and something tells me that if you were to duplicate this content three times (Middle Korean, Korean, Jeju) you will not be such a fan of keeping the three entries on one page. Thadh (talk) 16:36, 13 May 2024 (UTC)

I would be. Just as I am with every other letter entry. The only reason I haven't created them myself is because I haven't had the time to. Also, even if it's not from a Latin-script bias, I still do not think that several smaller language communities are being considered.

That being said, this still doesn't address my main point that this doesn't actually fix the problem. If you don't want letter entries that's fine, that's another conversation, but let's not pretend that it's going to fix this current lua memory issue. It's not even a solution to "most" of the immediate problem at pages like a, nor does it fix anything at all at pages like da or mi or la. AG202 (talk) 17:21, 13 May 2024 (UTC)

For reference at a: there are 170 L2s, and 64 letter entries (with the header "Letter"). So not even half of the L2s there have letter entries. It's frankly overblown. That's not even considering the L2s that have significantly much more content in their non-letter entries compared to the letter entry such as English a. AG202 (talk) 22:17, 13 May 2024 (UTC)

@AG202 Not sure it's overblown, since a is the article causing the most headache in terms of Lua and parser limits. a is currently at 1.887MB out of an allowed 2.097MB in post-expand include size, and removing all the letter entries would bring that down noticeably. People are also thinking ahead to the fact that there are 5,000+ languages that use the Latin script, and we can't possibly have an entry for the letter a in every such language; whereas the number of languages where a is a word (excluding those where it's the name of the letter a) is much more limited. (Note also that when I just previewed a, I got a CPU timeout. User:Surjection may have inadvertently made this worse by lite-ifying a bunch of the templates again; the preview showed 43 seconds of CPU time and 53 seconds of real time, vs. 23 seconds of CPU time and 30 seconds of real time when previewing a slightly earlier version not using the lite templates. YMMV though, as there is a lot of variation in the CPU times.) Benwing2 (talk) 22:44, 13 May 2024 (UTC)

@Benwing2: "Removing all the letter entries would bring that down noticeably", can we actually get the numbers for this? Because when I tested that back in 2020, that wasn't the case. CC:@Surjection

"Whereas the number of languages where a is a word (excluding those where it's the name of the letter a) is much more limited": I also don't think that's the case. Again, looking at what's on the ground right now, there are significantly more non-letter entries that are taking up "space". There are only 64 L2s with letters or letter names, out of 170. Clearly the focus should be elsewhere.

Letter entries don't even take up that much space relatively; they don't have quotations like Sassarese a and they don't need usage notes like Serbo-Croatian a. I'm much more worried about 100 more L2s with non-Letter POSs as that's more realistic and takes up significantly more space, instead of a very rare possibility of 5000+ letter entries. Hell, the English entry at a has twelve etymologies outside of the letter entry, and is itself equivalent to several languages' letter entries.

Let's focus on actual long-term solutions, like the TOC option being discussed below, rather than taking out information that users like myself and others find useful. AG202 (talk) 23:18, 13 May 2024 (UTC)

User:Thadh/a I've removed all noun senses for letter names (except for the Norwegian figurative ones) and letter senses. I don't know how to measure whether the page loads better, but at least there are no lua errors anymore. Thadh (talk) 13:47, 14 May 2024 (UTC)

Thank you! Yeah looking at the page you've linked, removing the letters (and letter names which I thought were a separate issue) only removed 27225 bytes, which may seem like a lot, but that's out of 197738 bytes initially. That means that letters & letter names only account for ~14% of the bytes on the page, which is exactly what I was talking about. Letters on their own account for even less. We'd reach the max byte limit again in no time even if we barred letters from being added. (Also by my count only 14 L2s have solely a letter and/or letter name entry out of 170) AG202 (talk) 14:19, 14 May 2024 (UTC)

«no table of contents»? What do you mean? Tollef Salemann (talk) 06:19, 13 May 2024 (UTC)

Are the pages titles "Appendix: Variations of the letter [LETTER]" complete? Could they be made to include all the languages that use the given letter? If they could, that would eliminate one advantage of the current letter-page structure: comparison of letter use across languages. DCDuring (talk) 12:00, 13 May 2024 (UTC)

At the moment, the "Variations of" appendices are language-neutral. We could agree to change that, but I think a separate set of appendices would probably be the better approach. —Mahāgaja · talk 12:38, 13 May 2024 (UTC)

That's not what those pages are for - those are to list confusable/similar terms so that we don't clutter {{also}} with massive lists at the top of a page. Theknightwho (talk) 12:39, 13 May 2024 (UTC)

Right, I am wondering about extending their purpose to overcome a short-coming of off-loading letters to language- or script-based appendices: that one loses the ability to compare across languages. If we need to create something additional to preserve their purity of their current purpose, I would not object. It just seems that their current narrow purpose could be broadened to make them more effective even at achieving their current purpose. DCDuring (talk) 13:52, 13 May 2024 (UTC)

I suppose, but I'm not sure how useful it'd be (especially with letters like "a"). It'd make more sense with less common letters, though. Theknightwho (talk) 14:01, 13 May 2024 (UTC)

Based on the persistence of this problem over at least a decade, it seems that we are forced to use incremental solutions. Not all incremental solutions have to be technical. As was observed above, letters (and symbols) are not like the rest of our content, so perhaps we can use a different content model for them. If the different content model allows us to reduce the number of module-error pages, our attention will be led to a somewhat different set of violations, requiring or suggesting different partial solutions. A different content model for letters may lead to a better (more comprehensive) handling of letters. There are more than 60 Letter L3/4 headers on a. That does not seem a negligible amount of content to offload, but it seems likely to be smaller than the number of languages likely to use the letter a. DCDuring (talk) 17:19, 13 May 2024 (UTC)

• The problem isn't just individual letter pages, though. A page like [[an]] is also difficult to navigate around and could benefit from being split up. On the other hand, at [[bachall]] I find it very convenient to have the Old Irish entry and its homographic Irish and Scottish Gaelic descendants all on the same page. —Mahāgaja · talk 12:34, 13 May 2024 (UTC)

@Benwing2: Well, the number of clicks is equal if you count the table of contents. Also, it seems like splitting the letter entries off doesn't address the Lua issue since letters make up only small proportion of the content at a.

@Tollef Salemann: If you don't have a phone handy, go to https://en.m.wiktionary.org/wiki/da and resize your browser to make it narrow — the table of contents disappears.

@Mahagaja, -sche: Yes, there could be some kind of controller template on da that would automatically transclude the pages if the number of languages is under a certain reasonable value (say 5), otherwise display the disambiguation table. Ioaxxere (talk) 13:32, 13 May 2024 (UTC)

What I find convenient about having all three languages at [[bachall]] is not so much being able to read them all at once as being able to edit them all at once, and if they're transcluded from three separate pages named "bachall/ga", "bachall/sga", "bachall/gd" or the like, then that's not convenient anymore. —Mahāgaja · talk 14:30, 13 May 2024 (UTC)

No, it doesn't want to disappear on my handy. Not on my neighbors' either. We both use Apple handy (iphone). What do you all mean it disappears? It just being smaller, so you must touch on it, so it becomes bigger and you easily can navigate, like in Wikipedia. Are you all talking but non-Apple devices? Tollef Salemann (talk) 17:44, 13 May 2024 (UTC)

How about only splitting up pages over a certain size? At the moment when I look up a short word I type "da#Zhuang" in the search bar to get me straight to the entry I need, but that's still annoying. —Caoimhin ceallach (talk) 13:52, 13 May 2024 (UTC)

I don't like the idea of splitting pages. Is there any way to personalise the table of contents? Being able to collapse language names per letter of the alphabet would go a long way. Thadh (talk) 14:03, 13 May 2024 (UTC)

@Thadh This may be possible with CSS. I know for example that User:Sarri.greek has been experimenting with different layouts for the TOC. If not, and you can create a clear plan for what functionality you'd like, the MediaWiki devs might be amenable (e.g. if you contact Tim Starling directly; he's the one who increased our memory and timeout limits). Benwing2 (talk) 20:32, 13 May 2024 (UTC)

@Thadh See [7] for an example of what Sarri did. Benwing2 (talk) 21:16, 13 May 2024 (UTC)

That looks good! Maybe this at least solves the issue of navigation. Thadh (talk) 21:17, 13 May 2024 (UTC)

I agree - it does look good. Theknightwho (talk) 21:19, 13 May 2024 (UTC)

Not bad. Is this intended as a default for certain types of pages (What kind?), opt-in, or only in custom JS/CSS? DCDuring (talk) 01:38, 14 May 2024 (UTC)

@DCDuring I think we could clean it up a bit and use it for long pages where we'd otherwise compress the TOC by omitting subheadings. Benwing2 (talk) 01:59, 14 May 2024 (UTC)

@Benwing2, Thadh, Theknightwho: I rewrote the template: {{minitoc}}. Maybe it can be automatically added to any entry with more than (say) ten languages. Ioaxxere (talk) 05:14, 14 May 2024 (UTC)

@Ioaxxere Looks good to me but let's solicit more comment first. Also it would be great if there was a way, after you expand it, to further expand it to show the subheadings. Some people (maybe User:RichardW57?) have complained about the shortened TOC's that you can't so easily navigate to the subheadings of a particular language. Benwing2 (talk) 05:19, 14 May 2024 (UTC)

M @Ioaxxere, thank you for your Template:minitoc! and your help for [8], [9], [10], [11],[12], ... Also, perhaps variations for few (1-5) languages by L2 something like this? For related language periods like this? (Reconstruction of the magic word __TOC__ because it might be taken away from us in future skins like vector22? (e.g. discussion@el.wikt for modifications) Thank you, thank you! ‑‑Sarri.greek ^♫ I 05:36, 14 May 2024 (UTC)

@Sarri.greek: Yes, a multi-column TOC is certainly possible. You can add the following into your commons.css:

div.toc > ul { display: flex; flex-direction: column; gap: 0 20px; flex-wrap: wrap; overflow: auto; max-height: 30em; /* change max-height as desired */ }

div.toc { width: 100%; }

I can't promise you that it'll look very good, though. Ioaxxere (talk) 06:08, 14 May 2024 (UTC)

@Ioaxxere @Sarri.greek I've rewritten Module:minitoc somewhat to take advantage of the pre-computed list of L2s that is already calculated by Module:headword/page, since it can cope with a bunch of weird edge-cases that can't be dealt with by a simple Lua pattern (and it's also faster, since it means we don't need to parse the page again). Theknightwho (talk) 14:00, 14 May 2024 (UTC)

Re complaining when TOCs are collapsed, FWIW I have also complained that when TOCs are collapsed you can't easily navigate to subsections of a given language section, but as long as we're only deploying that on entries with a truly excessive number of L2s, like a, I'll live with it. If we're deploying it on tons of pages, e.g. cat—11 L2s—I'm less happy. Maybe if we're only deploying it on mobile, that's better than also deploying it on desktop, OTOH someone was just complaining in another discussion that entries are hard to navigate because TOCs are collapsed or sometimes hidden(?) on mobile. So maybe the ideal would be to make it a gadget/pref, whether opt in or opt out, so people who wanted collapsed TOCs could get them—maybe even on all entries, if they wanted—and people who wanted uncollapsed TOCs on all entries could keep them. Or to make it possible to expand the collapsed TOCs (all at once or on a per-L2 basis) as mentioned above.
Not directly relevant to this specific concern, but relevant to the general topic is Wiktionary:Grease_pit/2021/June#Experience_on_mobile which also links a number of other prior discussions; see also some history at Wiktionary:Beer_parlour/2021/April#collapsed/minimized_language_headers. - -sche (discuss) 15:37, 14 May 2024 (UTC)

I can understand why __NOTOC__ has been included, since it avoids having two TOC with Vector, but with Vector 2022 it's a bit detrimental since it means there's now no longer a TOC in the left-hand sidebar, which can normally be used even if you're scrolled halfway down the page. Theknightwho (talk) 15:46, 14 May 2024 (UTC)

@Theknightwho: That's a good point. It's actually possible to specify by-skin behaviour by changing MediaWiki:Vector-2022.css and similar, so maybe we could use that to override __NOTOC__ in Vector 2022 since the TOC doesn't take up space in the document flow anymore. Ioaxxere (talk) 16:04, 14 May 2024 (UTC)

Instead of moving the Zhuang entry for da to da/Zhuang, we could move it to Zhuang/da, and we could move all the Zhuang entries that way and add a specialised search bar searching only in entries starting with “Zhuang/”, like we do with the search bar on top of the beer parlour here. That would reduce the scrolling and the clicks for people interested in Zhuang. MuDavid 栘𩿠 (talk) 01:54, 14 May 2024 (UTC)

Iff we split (which I am not saying I'm in favor of), I like the idea of putting the language first so people can make language-specific searches. But what do you think of using language codes rather than language names? Language names can be very long (e.g. "Southern Valley Yokuts") and can contain many hard-to-type characters (how likely is it that the average user can type "ǃXóõ"?)... although I concede we do name reconstructed entries using language names. - -sche (discuss) 02:06, 19 May 2024 (UTC)

@-sche Personally I wouldn't use Reconstruction sections as an example of good UI design; I find it annoying to have to type out the whole language name (not to mention the word "Reconstruction"; is there an abbreviation for this namespace?). As for putting the lang name or code first, I see advantages and disadvantages. Assuming we have a page at the bare word that links to all the lang-specific pages, the advantage for experienced users is that the lang specific pages won't so easily show up in autocomplete; but this may be a disadvantage to new users, who will see the lang-specific pages autocompleted if the lang follows but not if it precedes, and who are unlikely to be familiar with Wiktionary lang codes.Benwing2 (talk) 03:07, 19 May 2024 (UTC)

Re abbreviation: RC, e.g. RC:Proto-Germanic/-janą. (As you probably recall, people objected to past proposals to set up RC entries like regular entries i.e. put all languages that have a word *jab on one page, because reconstruction orthographies are language-specific and what j or a or b means in the notation for one language is different from what it means in another. I...can't say I find that persuasive, because what non-reconstructed orthographies mean by j, a, b also differs—Hmong uses b to represent a tone, vs other languages using it for /b/, /β/, etc—but...) - -sche (discuss) 03:39, 19 May 2024 (UTC)

@-sche Thanks. Yeah I don't find that argument persuasive either for the reasons you give. Benwing2 (talk) 03:51, 19 May 2024 (UTC)

I understand the logic between separating languages in this case but I agree that it's extremely annoying to search for and definitely unintuitive for new users. Maybe we should go as far as to treat reconstructed terms the same way as attested entries, i.e. have Reconstruction:Proto-Germanic/-janą and a term with the literal spelling *-janą on the same page or (under the proposal) page group. Ioaxxere (talk) 04:01, 19 May 2024 (UTC)

(@Benwing) If we display all the language-specific subpages on the bare entry (i.e. transclude the Zhuang da subpage onto da), then I am not concerned about whether new users see the subpage (whether "da/Zhuang" or "Zhuang/da") in the search bar when they type "da...", because I wouldn't expect such users to know/care about subpages, and I figure it's enough that they can type "da" and get to the "da" entry, where they can see the Zhuang content. However, it occurs to me that an advantage to "da/Zhuang"-style naming might be : if whatever template we use at [[da]] can just pull and display all subpages of whatever page it's on (and we would only need special handling for a small number of pages, e.g. s/he is not a subpage of s)... whereas if we use "Zhuang/da"-style naming, it seems like it would have to go through a list containing all of the thousands of possible languages we include, to check which exist for a given page. (No?) Would there be a difference in which approach is faster, Zhuang/da vs da/Zhuang...? I do think the ability to type "Zhuang/..." into the search bar and thus narrow whatever you next down so that you're only searching in Zhuang would be a benefit to that ordering — say I want to quickly check whether any Zhuang entries start with str-, I could type "Zhuang/str" into the search bar and see what results autocomplete suggests/finds — but not if there are drawbacks, like if it would complicate or slow down the 'transclude all subpages onto the main page' template. And I'm still not actually in favour of splitting entries onto subpages at all, although if it came to a vote I don't know if I'd oppose or just abstain.) - -sche (discuss) 04:05, 19 May 2024 (UTC)

@-sche: No, the pages can't be transcluded since that would lead to the massive pages we were trying to avoid in the first place. More realistically there would be a {{minitoc}}-like navigation table which could dynamically transclude pages through JavaScript (of course, there would be a less-convenient alternative for users not running JavaScript). By the way, I prefer da/Zhuang over Zhuang/da since it makes it easier to autocomplete queries. A user only has to type "da/z" for da/Zhuang to be the only valid completion. Ioaxxere (talk) 04:29, 19 May 2024 (UTC)

@-sche I didn't even think of that; my assumption was that adding a new language would entail both adding a split lang-specific page and modifying the combined page to know about the language in question, which is definitely a drawback to the split-lang approach. But if we put the lang name or code last, yes is should be possible to use the prefix-pages functionality to automatically find the split-lang pages. Benwing2 (talk) 04:29, 19 May 2024 (UTC)

@Ioaxxere It should still be possible to transclude in most cases, e.g. only not transclude if there are more than say 20 or so languages. Benwing2 (talk) 04:31, 19 May 2024 (UTC)

Yes, to clarify, because two ideas were discussed earlier and I get the sense Ioaxxere and I may be talking about different ideas(?)... I was saying it'd make sense to have a template automatically find any subpages and transclude them, rather than making users manually add new subpages to a list (since we already see how often users tag but neglect to list RFVs, RFDs, etc!), if we split all pages. But if we only split the large, Lua-memory-error-having or PEIS-limit-reaching pages that need splitting, Ioaxxere is right that it doesn't make sense to transclude anything. I haven't run the stats, but I would hazard a guess that the majority of pages on Wiktionary have only 1 L2 (maybe 2), so splitting all our millions of pages just because a few are too large to display does have obvious drawbacks, letting a tiny tail wag an enormous dog. It would be a lot less disruptive to only split the handful of pages that need it. - -sche (discuss) 06:34, 19 May 2024 (UTC)

100% agreed. Benwing2 (talk) 07:25, 19 May 2024 (UTC)

On the other hand, the overwhelming majority of pages for English lowercase 4-letter nouns starting with 'ta' have pages with entries for more than one language, and many of our inflection tables are littered with orange links. --RichardW57m (talk) 14:40, 23 May 2024 (UTC)

Enabling categories for logged-out users

Tracked in Phabricator
Task T365323 Resolved

Currently, categories are hidden on mobile unless a user is logged in and has "advanced mode" enabled. I don't think there's any good reason to do this since categories are a pretty important part of the site. Apparently we need to get community consensus and then open a Phabricator request to set $wgMinervaShowCategories['base'] = true; Would you support this? Ioaxxere (talk) 14:16, 14 May 2024 (UTC)

@Ioaxxere Support I had always assumed there was some reason for not doing so already such as:

• not making entries look too cluttered
• categories are too technical for viewers of Wiktionary who do not edit
• or there are technical difficulties involved

Kutchkutch (talk) 14:27, 14 May 2024 (UTC)

Support. Binarystep (talk) 14:42, 14 May 2024 (UTC)

I assume this would slow things down a bit for all users. How much? DCDuring (talk) 14:49, 14 May 2024 (UTC)

Support. Benwing2 (talk) 14:55, 14 May 2024 (UTC)

I don't think this would cause any noticeable slowdown, even on very large pages. Theknightwho (talk) 14:57, 14 May 2024 (UTC)

Support — SAMEER (؂・؄・؏) 18:01, 14 May 2024 (UTC)

Support, and I wish Wikipedia would follow suit but alas. lattermint (talk) 23:38, 14 May 2024 (UTC)

Support - -sche (discuss) 01:32, 15 May 2024 (UTC)

Support Fay Freak (talk) 01:55, 15 May 2024 (UTC)

Strong support — SURJECTION ^{/ T / C / L /} 12:48, 15 May 2024 (UTC)

Support CitationsFreak (talk) 16:45, 15 May 2024 (UTC)

Support Vininn126 (talk) 17:23, 15 May 2024 (UTC)

Support Theknightwho (talk) 17:26, 15 May 2024 (UTC)

Strong support AG202 (talk) 06:14, 16 May 2024 (UTC)

Strong support Thanks for proposing this. I too had always assumed there must have been some kind of technical/UX reason for not implementing this already, but none has been forthcoming. Voltaigne (talk) 07:59, 16 May 2024 (UTC)

It seems the consensus is overwhelming. Has a Phabricator request been opened yet? — SURJECTION ^{/ T / C / L /} 19:45, 18 May 2024 (UTC)

@Surjection: phab:T365323. Ioaxxere (talk) 01:29, 19 May 2024 (UTC)

This has been merged into the next MediaWiki release, so it should start working relatively soon. Theknightwho (talk) 08:47, 21 May 2024 (UTC)

it looks like it was just deployed an hour ago. It seems to be fully functional when testing it in private-browsing mode. — SAMEER (؂・؄・؏) 20:22, 21 May 2024 (UTC)

Sign up for the language community meeting on May 31st, 16:00 UTC

Hello all,

The next language community meeting is scheduled in a few weeks - May 31st at 16:00 UTC. If you're interested, you can sign up on this wiki page.

This is a participant-driven meeting, where we share language-specific updates related to various projects, collectively discuss technical issues related to language wikis, and work together to find possible solutions. For example, in the last meeting, the topics included the machine translation service (MinT) and the languages and models it currently supports, localization efforts from the Kiwix team, and technical challenges with numerical sorting in files used on Bengali Wikisource.

Do you have any ideas for topics to share technical updates related to your project? Any problems that you would like to bring for discussion during the meeting? Do you need interpretation support from English to another language? Please reach out to me at ssethi(__AT__)wikimedia.org and add agenda items to the document here.

We look forward to your participation!

MediaWiki message delivery 21:23, 14 May 2024 (UTC)

New TOC scheme

After thinking about our TOC issues a bit more I feel like it's impossible to have a one-size-fits-all system that's convenient for every user. Instead, I think we should have a different scheme for different skins. What do you think about this proposal? Pinging those who participated in the discussion above: @-sche, Benwing2, Theknightwho, DCDuring, Thadh.

	1-4 L2s	5-9 L2s	10-19 L2s	20+ L2s
Vector (and other old skins)	default TOC			mini TOC
Vector 2022	default TOC		Both
Mobile	default TOC	mini TOC

Ioaxxere (talk) 14:31, 15 May 2024 (UTC)

Testing would be good, especially if the system is to be imposed on IPs as a default, as we have very little information about how normal users use our entries, even basic facts like how many use English L2s only. I assume that other users will be able to override the defaults. DCDuring (talk) 14:56, 15 May 2024 (UTC)

@DCDuring: Users would be able to override the table with some simple CSS settings (see User:Ioaxxere/common.css for an example). The code is admittedly ugly but this comes with the benefit of virtually complete control over the output. As for what normal users think, maybe this is a good opportunity to "connect with readers" @Vininn126? Ioaxxere (talk) 16:30, 15 May 2024 (UTC)

We probably need a larger followership before we start making questionnaires. Vininn126 (talk) 10:29, 17 May 2024 (UTC)

Sounds good to me in principle. Thadh (talk) 15:08, 15 May 2024 (UTC)

@Ioaxxere Like @Thadh I would say "sounds good in principle"; I have no specific objections but I think there should be a period of testing before committing to particular numbers of L2's for controlling the TOC appearance. Benwing2 (talk) 00:04, 18 May 2024 (UTC)

Could we have numberings? (too difficult to count without them), possibly 'show' the frame default? & trial examples also at pages like this one? (probably with not centered text)? Thank you ‑‑Sarri.greek ^♫ I 00:32, 18 May 2024 (UTC)

@Benwing2: For testing, here are the current pages which use the template: a (169 L2s), da (91 L2s), rock (13 L2s), small (8 L2s), and fish (2 L2s, so no effect). The L2 numbers can be edited at any time here: Module:minitoc/styles.css. Ioaxxere (talk) 03:40, 18 May 2024 (UTC)

Should entries categorized according to speculative etymologies?

If a word’s etymology is sufficiently disputed or uncertain to merit an {{uncertain}}, should that word be categorized as coming from the proposed sources? For instance, should Vulgar Latin *tīrāre be categorized as coming from Old Persian, from Proto-Germanic, and from Greek according to the various competing theories? I’m inclined towards ‘no’, since we know for a fact that at least two of the three categorizations will inherently be wrong. (And in all likelihood all three of them are.) Yet I often find entries where this sort of categorization has been done anyway. Nicodene (talk) 03:39, 16 May 2024 (UTC)

I agree — the entry being in a category called "terms derived from Y" misleadingly implies a level of certainty that doesn't exist. FYI, {{etymon}} lets you explicitly specify whether a derivation is "confident" or "uncertain" so maybe we could use that to generate better categories. Ioaxxere (talk) 05:02, 16 May 2024 (UTC)

On the other hand, if one is looking for Latin words coming from Old Persian, I'd want it in that category rather than having to also look at the category of Latin words possibly coming from Old Persian. One usually has to at least look for the etymology section because of the possibility of Latin homographs. --RichardW57m (talk) 13:55, 16 May 2024 (UTC)

That’s doable by searching for Latin terms of uncertain origin, along with the keyword ‘Persian’. I’d really rather not have such a word be part of the actual category in question since it almost certainly doesn’t belong. Nicodene (talk) 14:30, 16 May 2024 (UTC)

So what is the search URI? Is it not obscure and prone to false detections? It's also a second search specification, and nothing like as simple to type as https://en.wiktionary.org/wiki/cat:Latin_terms_derived_from_Old_Persian. (I only need to type the scheme and underscores to make it look good on this page!) --RichardW57m (talk) 17:07, 16 May 2024 (UTC)

This, and his argument can be inverted: He can search entries containing the category but not {{uncertain}}. Overall both and either is easier. 😃 Fay Freak (talk) 20:59, 16 May 2024 (UTC)

Categories have no inherent truth value. They as well have the issue of containing surface analyses, affixations from previous chronolects: intended to have utility value. Fay Freak (talk) 20:59, 16 May 2024 (UTC)

I don't see what's so confusing. The search is as follows: incategory:"Latin terms with unknown etymologies" "Old Persian". If an argument is to be made that the command in question is obscure, so is the notion of someone wanting to find Latin (~Proto-Romance) words of unlikely Persian origin. Nicodene (talk) 02:07, 23 May 2024 (UTC)

"undo" has become "cin gbere le" on History tab

The "undo" button on the edit history is appearing for me as "cin gbere le". I don't know what language this is (if it is a language) but I guess something has gone wrong somewhere in the Wiktionary backend. Smurrayinchester (talk) 12:14, 16 May 2024 (UTC)

Still says "undo" for me. —Mahāgaja · talk 12:15, 16 May 2024 (UTC)

@Smurrayinchester: See w:Wikipedia:Village_pump_(technical)#'Undo'_button_now_says_'cin_gbere_le'. —Mahāgaja · talk 12:17, 16 May 2024 (UTC)

Thanks! Smurrayinchester (talk) 13:08, 16 May 2024 (UTC)

@Mahagaja: That link doesn't work (no such section). Any chance of a permalink? I don't have this problem but I am really curious what "cin gbere le" means. Equinox ◑ 03:30, 23 May 2024 (UTC)

It's Nupe language: translatewiki:MediaWiki:Editundo/nup. See the archive w:Wikipedia:Village pump (technical)/Archive 212#'Undo' button now says 'cin_gbere_le'. Vriullop (talk) 05:57, 23 May 2024 (UTC)

Creoles using "inh" template for words from lexifier language?

The whole time, I've been using the "der" template for Macanese words that derive from Portuguese, but I've seen some Kabuverdianu entries that use "inh" instead, as well as Solombala English entries that also use "inh" for words from Russian and English, and that's not even a creole. On the other hand, Haitian Creole uses "der" for words from French, and I believe Papiamentu also uses "der" for words from Portuguese and/or Spanish. So is there a specific preferred template for these kinds of things? Are creoles really considered to be "inheriting" words from their lexifier languages? Insaneguy1083 (talk) 17:56, 16 May 2024 (UTC)

@Insaneguy1083: Old, unresolved issue: Wiktionary:Beer parlour/2018/May#Lexifier etymology template? Fay Freak (talk) 21:02, 16 May 2024 (UTC)

Chinese: how should we display alternative readings?

(Notifying Atitarev, Benwing2, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, ND381, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): Currently we have a lot of ways to separate alternative readings (e.g. thâng / thóng). I have compiled the currently covered Chinese lects and displayed them here:

• In the input, / and , are used to separate alternative readings.
• In the input, ; and / are used to separate different sub-lects. (Hakka specifies them using = while Wu specifies them using :.)
• In the collapsed output (before you click "more"), ,, ;, and / are used to separate alternative readings.
• In the expanded output (after you click "more"), ,, ;, and / are used to separate alternative readings. Different lects are also displayed in different sections. One thing that is consistent is that , is used for IPA, because / would be confusing. (Note that in Hokkien, Pe̍h-ōe-jī and Tâi-lô use / but Phofsit Daibuun uses ,.)

While it would be harder (though not impossible) to unify the inputs, what is more realistic is to unify the outputs. Can (and should) we come to one standard for this? (Obligatory XKCD 927) --kc_kennylau (talk) 18:48, 18 May 2024 (UTC)

I'm not a Chinese editor, but FWIW my instinct would be to use commas like e.g. {{alter}} and other "lists", but... do we anticipate ever needing to list alternative readings of a phrase that contains commas (like 一枝草，一點露)? Because commas would become confusing there. Of course, that is a general issue, also hitting {{alter}} et al (in all languages). If anyone has the energy to code this feature, maybe all these templates (not just for Chinese) that use commas could default to commas, but switch to separating items with semicolons when the lemma form or alt forms / alt readings contain commas? Or provide a parameter someone could set to make the item-separating commas switch to semicolons in such cases? - -sche (discuss) 19:12, 18 May 2024 (UTC)

Yes, that situation does occur, in e.g. 潮州音樂——自己顧自己 which currently displays as ciu4 zau1 jam1 ngok6, zi6 gei2 gu3 zi6 gei2 / ciu4 zau1 jam1 ngok6, gi6 gi1 gu3 gi6 gi1 (with superscripts). --kc_kennylau (talk) 19:14, 18 May 2024 (UTC)

Personally, I consider it suboptimal for the Chinese version and the transliteration/reading/etc to use different punctuation there (dash vs comma) and would prefer if the transliteration/reading also used a dash (or if the Chinese used a comma). (But as long as some Chinese entries like 一枝草，一點露 do use commas, I take the point that the situation does occur.) - -sche (discuss) 01:31, 19 May 2024 (UTC)

Coming from a predominantly Northern Wu editing basis I would prefer for us to go with what we do with |w= to be adopted in all other lects. However, one thing I would like to ask about is ;, as it can be very confusing (see prev. discord convo about 吳. Currently I think there should be some sort of case-by-case arbitration regarding ; usage rather than fully depreciating it, though if anyone thinks otherwise do speak out — nd381 (talk) 19:46, 18 May 2024 (UTC)

Yes, thank you for bringing that up, I think that would be very relevant to this thread. Basically, to summarize for other people, Wu currently covers more than 10 lects all in one parameter that corresponds to "Northern Wu" (aka "Taihu Wu"), and we still don't quite have a consensus on what to do under a situation such as:

• Lect A: Reading P, Reading Q
• Lect B: Reading Q, Reading R
• Lect C: Reading P, Reading Q, Reading R.

What is clear is that in such a situation, the collapsed display would most certainly be P / Q / R, but anything beyond that is unclear:

• Should the input be A:P,Q;B:Q,R;C:P,Q,R (group by lect), or A,C:P;A,B,C:Q;B,C:R (group by reading)? Or should we allow both?
  • Grouping by lect would be inefficient if it happens that a lot of lects share the same reading P (which actually, the Wugniu romanization takes great care to prioritize compatibility between different lects).
  • Grouping by reading would make it hard to see at first glance what readings a given lect has, which would arguably be an important information (say for someone who is only learning a single lect).
  • Allowing both inputs is also not ideal, because standardized inputs are easier to monitor and track (and bot).
• I think it should also be noted that to my knowledge Hokkien seems to be grouping by reading.
• Similarly there is an issue of how to group the expanded display.
• And when it scales up, for say a word of 4 characters, we would definitely run into issues where the listed readings are all very similar, because say Lect A would have a slightly different reading of the first character, while Lect B would have a slightly different reading of the third character, and so on. (See 世界 for an example.)

--kc_kennylau (talk) 21:11, 18 May 2024 (UTC)

I think we should use slashes, and also put all readings on new lines (currently Mandarin gets new bullets for each reading, while for Cantonese everything is crammed into one line). New lines should nullify confusion with IPA slashes.

(also. shilling User:Fish bowl/p/mul#Chinese for consideration. —Fish bowl (talk) 22:10, 18 May 2024 (UTC))

Chinese: Spaces around ellipsis in transliteration?

(Notifying Atitarev, Benwing2, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, ND381, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): Apologies for the double ping. 一面……一面…… has pinyin as yīmiàn ... yīmiàn ... (with spaces), while 關……屁事 has pinyin as guān...pìshì (without spaces). Both pinyin are currently created. One can see from the synonyms of these two pages respectively that their synonyms follow the same rule as the pages themselves. The Cantonese module has recently been updated to explicitly only allow the variant without spaces. What should the standard for this be? --kc_kennylau (talk) 18:53, 18 May 2024 (UTC)

spaces look cleaner — nd381 (talk) 19:46, 18 May 2024 (UTC)

also consider: one space, only on the right side of the ellipsis —Fish bowl (talk) 22:15, 18 May 2024 (UTC)

Ditto. Anatoli T. ^{(обсудить}/^вклад) 00:14, 19 May 2024 (UTC)

I prefer spaces on both sides of ellipses. — justin(r)leung _{{ (t...) | c=› }} 18:23, 20 May 2024 (UTC)

With spaces only after the ellipsis. – wpi (talk) 15:06, 23 May 2024 (UTC)

Copyright of definitions

An organization with a partnership with Wikimedia Foundation wanted wiki editors to translate a definition of theirs. They did release the definition with an open copyright license. WMF's position is that sometimes this works.

They are currently getting more information but I wanted to ask here - what is copyright status of definitions, and what is the copyright status of translations? While WMF legal has a project for definitions this could be a good time to talk.

• meta:Talk:International_Museum_Day_2024

Bluerasberry (talk) 18:56, 18 May 2024 (UTC)

@Bluerasberry: if you look at the bottom of every page here, you will see the following sentence: "Definitions and other text are available under the Creative Commons Attribution-ShareAlike License; additional terms may apply." In addition, every time an editor submits text, it is also irrevocably released under the GNU Free Documentation License—there is also a message to that effect. Does that answer your question? — Sgconlaw (talk) 22:34, 18 May 2024 (UTC)

@Sgconlaw Thanks, but no it does not.

The Wikimedia Foundation legal team has made a soft legal assertion that translation of definitions are not subject to copyright. In the current WMF project a definition claims a conventional copyright, but since copyright does not apply to translations of definitions, that definition can be directly translated into Wikimedia projects.

I get the Wiktionary policy. My surprise here is about the official WMF position of the copyright of translated definitions. If anyone wishes to press for clarity then getting a WMF commitment to legally back this theory for Wiktionary could be interesting. Bluerasberry (talk) 14:18, 19 May 2024 (UTC)

@Bluerasberry: with respect to the WMF, that makes no sense. A definition is licensed under CC-BY-SA-4.0. This means people are free to "remix, transform, and build upon the material for any purpose, even commercially"—which would include a translation—but subject to properly attributing the material and distributing any new material based on the original material under the same licence as the original. Obviously, then, translations of CC-BY-SA-4.0 material cannot possibly be "not subject to copyright" but must be released under CC-BY-SA-4.0 as well. The position is the same under the (more or less superseded) GFDL—any modified version (which includes a translation) must be released "under precisely this License". — Sgconlaw (talk) 18:30, 19 May 2024 (UTC)

@Sgconlaw At meta:International Museum Day 2024/Translation call the WMF organized the translation of a definition as an outreach program. The talk page the gives a rationale why. They requested time to sort things.

I share your perspective on all these things, and think that what you are saying is conventional but that this WMF outreach program is surprising. I appreciate the outreach and partnership. I wish that their programs matched Wikimedia editor practices.

The conversation there links to this conversation, and I think that is as much as I wish to react. Bluerasberry (talk) 15:46, 21 May 2024 (UTC)

@Bluerasberry: I read the discussion at "meta:Talk:International Museum Day 2024" and now have a clearer understanding of what you are asking. You weren't specifically asking about the copyright status of definitions here at Wiktionary, which are clearly licensed under CC-BY-SA-4.0 and GFDL, and not free of copyright. You were referring to a definition of the word museum published by the International Council of Museums (ICOM) at https://icom.museum/en/resources/standards-guidelines/museum-definition/. It's not a very long definition, but I don't think it is short enough to be de minimis so it is plausible that it is subject to copyright. ICOM is based in France, so French copyright law would presumably apply. I don't know what that law says about WMF's arguments on "functional language" and fair use. If English copyright law applied, I'm not sure there would be any "functional language" copyright exception. If ICOM is collaborating with the WMF in a project, ideally it should just clarify that it is licensing the text in question under a free licence for the purpose of the project. — Sgconlaw (talk) 16:34, 21 May 2024 (UTC)

• I once published a Catalan-English dictionary, entirely copied from en.wiktionary. But I was at the time the third-biggest contributor to the site, and the ninth-biggest Catalan one, so figured it was fair game. I made 70 euros from it. P. Sovjunk (talk) 21:25, 19 May 2024 (UTC)

That is fair. In that case you are going Wiki -> off wiki, selling free content in book form for a fee. In the case above, content is going off-wiki -> wiki. Bluerasberry (talk) 15:46, 21 May 2024 (UTC)

User:Ioaxxere/minitoc.js

I've created a gadget that allows users to specify "preferred languages" for {{minitoc}}, similar to the preferred languages system for our translation tables. These preferred languages are linked to on the header with the goal of allowing users to navigate to languages they're interested in faster (as requested in e.g. [13]). If anyone wants to try it out, go to User:YourName/common.js and add the line importScript("User:Ioaxxere/minitoc.js");

If we adopt {{minitoc}}, could we add this script as a default gadget so it can be used by logged-out users? Pinging interface administrators who participated in the previous discussion: @-sche, Benwing2. Ioaxxere (talk) 02:16, 19 May 2024 (UTC)

@Ioaxxere Hmm, I think this is useful. I note that after changing your preferred languages, you have to refresh the page for them to display; not sure if this is fixable. Benwing2 (talk) 04:41, 19 May 2024 (UTC)

@Benwing2 That's strange — so what happens when you press "save"? Is there an error? Ioaxxere (talk) 05:00, 19 May 2024 (UTC)

@Ioaxxere Hmm. I couldn't reproduce it, even after clearing my cookies, so I commented out the import, cleared my cookies again and uncommented the import, and now I don't get the functionality at all. Benwing2 (talk) 05:13, 19 May 2024 (UTC)

BTW no JavaScript errors coming from your gadget, only from the PreviewPopup gadget and complaints about Wiktionary using third-party cookies to access enwiki and mediawiki.org. Benwing2 (talk) 05:14, 19 May 2024 (UTC)

Infrastructure: Southern Pinghua vs. Nanning Pinghua

(@Benwing2) Recently we've added Nanning Pinghua to zh-pron (e.g. 捱更抵夜). Nanning Pinghua is a variety of Southern Pinghua, which is either a branch of Sinitic directly, or a sub-branch of the Yue branch. However, there is a problem with the categories. Currently zh-pron by default categorises them to Category:Southern Pinghua lemmas, but there is also a dialectal label {{lb|zh|Nanning Pinghua}} which categorises entries independently into Category:Nanning Pinghua (by complete accident I discovered that Category:Southern Pinghua is also populated as a label category), and these two categories are not directly connected:

• Category:Southern Pinghua lemmas ← Category:Southern Pinghua language ← Category:Pinghua languages ← Category:Sinitic languages
• Category:Nanning Pinghua ← Category:Pinghua Chinese ← Category:Dialectal Chinese ← … ← Category:Chinese language ← Category:Sinitic languages

If you ask me, I think "Pinghua languages" / "Pinghua Chinese" shouldn't exist at all, because Northern Pinghua and Southern Pinghua do not form a linguistical sub-branch by themselves. In User:Wpi/zh-dial-list we can also see that "Northern Pinghua" and "Southern Pinghua" are treated as their own branches in Module:zh/data/dial.

Actually, upon more exploration, it seems that this issue is not unique to Nanning Pinghua. There are also Category:Cantonese Chinese and Category:Cantonese language which are also not directly related, but they seem to have "solved" the issue by using a "See also" right under the header. --kc_kennylau (talk) 08:24, 19 May 2024 (UTC)

@Kc kennylau Yes, this is unfortunate and a known issue. I would like to eliminate the 'Foo Chinese' categories in favor of 'Foo lemmas', whenever possible. Benwing2 (talk) 19:09, 19 May 2024 (UTC)

@Benwing2: Can we make "Nanning Pinghua" (the label) instead point to a dialect of "Southern Pinghua" (the language csp)? --kc_kennylau (talk) 20:48, 19 May 2024 (UTC)

@Kc kennylau Sure. I didn't mean to imply that dialects are forced to categorize directly into lemma categories, but rather that we should eliminate the parallel hierarchy underneath Category:Dialectal Chinese in favor of a more conventional hierarchy that categorizes either directly into 'Foo lemmas' or into dialectal subcategories. So for example the label Cantonese should categorize into Category:Cantonese lemmas not into Category:Cantonese Chinese, and specific varieties of Cantonese go into their own categories, which are subcategories of Category:Regional Cantonese. So the label Nanning Pinghua would categorize into Category:Nanning Pinghua, which would be a subcategory of Category:Regional Southern Pinghua (which doesn't seem to exist yet). BTW there is an open WT:RFM topic under WT:RFM#Ramifying/filling out Yue Chinese on cleaning up the Yue branch, which is currently a hopeless mess. Benwing2 (talk) 21:02, 19 May 2024 (UTC)

@Benwing2: I didn't forget about that discussion. In fact, we are discussing that amongst ourselves, and it is also a bit of a mess right now. --kc_kennylau (talk) 21:06, 19 May 2024 (UTC)

Giving Appropriate Credit for Critical Semi-Anonymous Works

Here (diff), I used Wiktionary to highlight one of what is probably the earliest appearances of the word 'Haidong'. I use Foreign Broadcast Information Service translations frequently for some words which rarely appear elsewhere, or only appear decades later. I had recently seen some discussion about the appropriateness of the use of citations/quotations that do not name specific authors. Are citations/quotations that are semi-anonymous legitimate targets for a Wiktionary citation/quotation? They can be used to meet a goal like Wiktionary:Quotations#Choosing_quotations vision to "Extend the time range that we have quotations for, or fill long time gaps;" and/or "Show the variety of genres, regions and registers that a term is used in."? There is a critical area of cultural heritage for any word that is written semi-anonymously. Here, in the above cite, we have an anonymous propaganda author and an anonymous propaganda broadcaster (at "Xining Provincial Service"), with an anonymous propaganda transcriber and an anonymous propaganda translator (at Foreign Broadcast Information Service). It would be calamitous to the project of documenting actual usage if this citation/quotation were deleted on the basis that we don't know the name of the translator who would have been "creating" this English language loan word. (Please feel free to review the materials and find any relevant names. But I didn't see any.) Have I given appropriate credit to everyone involved in that text, as far as practically possible? Is that quotation a proper subject for a Wiktionary citation/quotation? Thank you. --Geographyinitiative (talk) 20:41, 19 May 2024 (UTC)

@Geographyinitiative I don't see any issue whatsoever in citing "semi-anonymous" sources, as you say, as long as you include whatever bibliographic information is available. Has anyone threatened to delete them? AFAIK these are well-accepted. Benwing2 (talk) 20:53, 19 May 2024 (UTC)

I just want to give everybody appropriate credit, but the genre of "spy reports", which is very useful for some of the vocabulary I'm looking at, is super opaque. --Geographyinitiative (talk) 20:59, 19 May 2024 (UTC)

Interslavic language

As the Interslavic language have got the ISO 639-3 code, is it welcomed now on the en.wikt? There is an online dictionary containing around 18,000 words ([14]), that can be used as a base for introducing it here. Wojsław Brożyna (talk) 01:27, 21 May 2024 (UTC)

Typically, constructed languages are in the appendix namespace, especially ones that don't have a long history with actual speakers, etc. In principle, I'd be okay with Interslavic in the appendix namespace. —Justin (koavf)❤T☮C☺M☯ 02:02, 21 May 2024 (UTC)

See the recent Wiktionary:Beer_parlour/2024/April#CFI_for_constructed_languages. The general attitude is most editors don't want more mainspace conlangs, as Justin mentioned. Appendix seems fine. Vininn126 (talk) 07:31, 21 May 2024 (UTC)

We would still need to add a language code for it, but I don't really see the issue with doing that if it's appendix-only. Theknightwho (talk) 08:46, 21 May 2024 (UTC)

• Thanks for the replies. I hope that the code would be quickly included on the WT:LL. At the meanwhile - as the words itself should be added in appendix, it is acceptable to link them from the mainspace? For example, as the descendants of the Proto-Slavic words in the reconstrucion namespace? --Wojsław Brożyna (talk) 14:00, 21 May 2024 (UTC)

  No, it is not acceptable to link them from mainspace, with the exception of terms in mainspace languages that derive from that language - so if a mainspace language has borrowed a word from Interslavic, then it can be linked, otherwise not (not as a translation, not as a descendant in mainspace or reconstruction space, etc.). I've now added the isv code as an appendix-only language code. — SURJECTION ^{/ T / C / L /} 14:07, 21 May 2024 (UTC)

  To be sure that I properly understood: the reconstruction namespace is treated also as a part of mainspace, yes? --Wojsław Brożyna (talk) 14:10, 21 May 2024 (UTC)

  Essentially, yes. Theknightwho (talk) 14:11, 21 May 2024 (UTC)

To be perfectly honest, I don't really see the point. When I look at Category:Appendix-only constructed languages, I see mostly languages with little or no practical use. The only possible outcome of Interslavic in an appendix-only construction would be duplicating stuff that can already be found here and/or here, an additional risk being that we might end up with divergent versions. So it's not clear to me what the value would be. For the record, Interslavic is not some hobby language, and its community is at least ten times bigger than that of Ido and Interlingua — language for which apparently an exception has been made. IJzeren Jan (talk) 14:51, 21 May 2024 (UTC)

@IJzeren Jan I think it was a mistake to include Ido and Interlingua in the mainspace; these should be moved to the Appendix, as we already did with Novial for example. They should not be considered precedents. Benwing2 (talk) 19:02, 21 May 2024 (UTC)

We might want to eventually take this to a formal vote or perhaps a a thread in WT:RFM. We have enough BP threads to do so. Vininn126 (talk) 19:05, 21 May 2024 (UTC)

I would much rather have a vote as to what the criteria for conlangs being included in mainspace is, which would conveniently decide this question as well. I personally favour "has or has had a native speaker", but it'll need to be more fleshed-out than that to be rigorous. Theknightwho (talk) 22:28, 21 May 2024 (UTC)

Some objective criterion would certainly be helpful. However, native speakers won't do, because auxiliary languages are not even meant to have native speakers. Even in the case of Esperanto it's not the ultimate fulfilment of its goals but merely a side effect of its usage. And note that even though Esperanto reportedly has about a thousand native speakers, it still does not have any monolingual native speakers. If anything, I'd argue that a criterion like "has or had a user community of at least 1,000 people" (or whatever other number you prefer) would be more suitable, although I'll admit such figures are not without issues either. IJzeren Jan (talk) 07:14, 22 May 2024 (UTC)

That's assuming people want more conlangs; I'd say most editors don't based on the thread I linked above. Vininn126 (talk) 07:17, 22 May 2024 (UTC)

You don't seem to get my point. First of all, native speakers are gravely overrated. Although Esperanto is probably the only constructed language with native speakers, it's not like they set any linguistic standards, and as far as there is any form of natural development at all, that's done by L2 speakers. Besides, there are many languages here that never had native speakers. Let me just mention Old Church Slavonic and Rumantsch Grischun. To go even further, it's questionable whether classical Latin ever had native speakers in the form it's being presented. Secondly, it's wrong to assume some kind of binary distinction between natural and constructed languages. Languages show various degrees of deliberate human intervention, which goes especially for artificially created standardisations (like Nynorsk, Rumantsch Grischun, Euskara Batua, Limba Sarda Comuna) and revived languages (like Modern Hebrew, revived Cornish). At last, I don't really understand where that "allergy" to languages that were created at some point in history comes from. Nobody complains about some obscure language with very few speakers, so what's the problem with a few constructed languages with a lot of speakers? IJzeren Jan (talk) 10:56, 22 May 2024 (UTC)

I have a feeling you didn't read through the thread. Vininn126 (talk) 11:02, 22 May 2024 (UTC)

Those first counterpoints are questionable. And secondly it is meaningful to have native speakers - they have a natural intuition for what should or shouldn't be correct. Vininn126 (talk) 11:06, 22 May 2024 (UTC)

@IJzeren Jan: When we record languages like Latin or Old Church Slavonic, we don't simply record the written language, but we simultaneously record the spoken language associated with it: Vulgar Latin and Pre-Bulgaro-Macedonian. For auxlangs, you don't have a natural counterpart that is recorded together with the written one. Thadh (talk) 08:12, 23 May 2024 (UTC)

In the meantime, do you think that it'd be worth it to have a vote to remove Interlingua, Ido, and Volapük? I honestly don't see a criteria for constructed languages being agreed upon in the near future, and as is, the only constructed language that'd fall under any criteria that's been mentioned is Esperanto anyways. AG202 (talk) 14:12, 22 May 2024 (UTC)

I'd rather do that only if a vote to have a general criterion fails. Otherwise, it might end up being a lot of work for nothing. Theknightwho (talk) 15:00, 22 May 2024 (UTC)

I am fine with having a vote about Interlingua, Ido and Volapük in the near term, as I think User:AG202 is right that it will be difficult to find a criterion that everyone agrees on and I don't think it will be a waste of effort to have this vote. Benwing2 (talk) 18:02, 22 May 2024 (UTC)

It should be simple enough to set the entry barrier for a given conlang as ‘there exists a consensus on Wiktionary to admit it’. I imagine only Esperanto will clear that hurdle. Nicodene (talk) 23:24, 22 May 2024 (UTC)

We, more precisely, have to ask ourselves whether it would probably be child abuse if the conlang were taught to children as a native language. In Esperanto it wasn’t because the parents met and spoke it organically. In Interslavic it would be, because why don’t you teach the bairn your native harder Slavic language if you are proficient in it? No reasonable person … In Klingon the children also became weird. Were it to suffice that a native speaker has existed, one would set perverse incentives. I maintain my position that conlangers are suspect to suffer personality disorders. Fay Freak (talk) 12:40, 23 May 2024 (UTC)

@Fay Freak: Is it child abuse if you raise your kid as a native speaker of both a natural tongue and some constructed language? I do agree that having a conlang as one’s sole native language is wrongheaded, but speaking a conlang as a first language would make someone a good Wiktionary editor working on that conlang, and is harmless as long as they continue speaking in a natural language. Inqilābī 16:59, 1 June 2024 (UTC)

@Inqilābī: I have been clear enough. Probably. I don’t find an article about a neckbeard father who raised his child bilingual with an artlang which she then suppressed just right now, perhaps it was a Reddit story and they swept it under the carpet. Maybe this hypothetical is difficult at your age, since personality development is not finished, myself I would not have been able to follow this line of thought half a decade ago. Fay Freak (talk) 19:01, 1 June 2024 (UTC)

@AG202: I support creating a vote to determine the status of those three languages although I'm undecided myself. Ioaxxere (talk) 22:00, 22 May 2024 (UTC)

Are there easily accessible objectively measurable activity stats for these conlangs? Such as the number of edits per month or the rate of adding new lemmas? Just to see the current situation. That said, any activity stats can be gamed and artificially propped by certain individuals via tons of low quality edits if this criteria were to become a part of the official policy. --Ssvb (talk) 07:49, 23 May 2024 (UTC)

@Ioaxxere, @Benwing2, @Theknightwho, @Koavf, @Nicodene: Wiktionary:Votes/2024-06/CFI for mainspace constructed languages has been created. There's no set start date yet, so feel free to leave comments either here or (preferably) on the talk page. AG202 (talk) 22:19, 4 June 2024 (UTC)

Feedback invited on Procedure for Sibling Project Lifecycle

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear community members,

The Community Affairs Committee (CAC) of the Wikimedia Foundation Board of Trustees invites you to give feedback on a draft Procedure for Sibling Project Lifecycle. This draft Procedure outlines proposed steps and requirements for opening and closing Wikimedia Sibling Projects, and aims to ensure any newly approved projects are set up for success. This is separate from the procedures for opening or closing language versions of projects, which is handled by the Language Committee or closing projects policy.

You can find the details on this page, as well as the ways to give your feedback from today until the end of the day on June 23, 2024, anywhere on Earth.

You can also share information about this with the interested project communities you work with or support, and you can also help us translate the procedure into more languages, so people can join the discussions in their own language.

On behalf of the CAC,

RamzyM (WMF) 02:26, 22 May 2024 (UTC)

‘Surface analysis’: The end of an era?

As tired as we all are of the matter, the previous discussion ended in a possibly promising proposal: replacing all current usages of {{surf}} with a new template {{af+}}, a clone of {{af}} with the accompanying text ‘derivable from X + Y’.

It seems to me that this is the first proposed phrasing to feature all three of the following:

• Precision: word-derivation is actually a ‘thing’ in linguistics, unlike ‘surface analysis’ (edit: and also unlike “X is equivalent to Y + Z”)
• Comprehensibility: any educated person should be able to understand it
• Compatibility: it works with all (valid) usages of {{surf}}

Thoughts? Nicodene (talk) 02:44, 23 May 2024 (UTC)

Can we not just do this by a hard redirect of {{surf}} to {{af+}}? So doing would avoid notifications of change being sent out for the pages modified. --RichardW57m (talk) 10:27, 23 May 2024 (UTC)

I do not like the idea of {{af+}} printing "derivable from". I would prefer a different name. Vininn126 (talk) 10:46, 23 May 2024 (UTC)

Me neither, it is not explicit about mere non-diachronic derivability.

I avoid schematic phrasing anyway, for literary style: writing sometimes “analyzible as”, sometimes “equivalent to” etc. Fay Freak (talk) 12:29, 23 May 2024 (UTC)

@Fay Freak As far as I can tell it is inherently synchronic. I cannot think of a non-synchronic way to read the statement “quickly is derivable from quick + -ly”.

As for those other phrasings, they are not precise, which is what leads to silliness like “month: equivalent to moon + -th”.

@Vininn126 I understand that the proposed phrasing doesn’t actually contain the word that af stands for, but I’m not sure there is any that does which fits the scope of {{af}} / {{surf}}. We can’t well say **affixable from X + Y, and even if we could, it would be inaccurate for compounds like greenhouse, which fall within the current scope of {{af}} / {{surf}} but do not involve any actual affixes.

The mismatch between template name and description could be fixed another way: by renaming {{der(+)}} to {{ult(+)}} “ultimately from”. If anything that is actually a better description than “derived from”, such that many editors (myself included) have found themselves manually writing out ”ultimately from {{der|…}}”. Once that is done, {{af}} can be renamed to {{der}} and {{surf}} to {{der+}} “derivable from”.

With bot assistance it would be fairly straightforward to implement this, I think. And the resulting system would be a good deal simpler/more transparent than our current one. Notably {{compound}} could finally be retired, since “derivable from” is applicable for compounds, while af is technically incorrect. Nicodene (talk) 19:52, 23 May 2024 (UTC)

I'm fine with the concept; like I said, it's the naming I don't like. {{der+}} is also not ideal. {{ult}} is so far the best I've seen, but it feels clunky. Vininn126 (talk) 19:53, 23 May 2024 (UTC)

Clunky in what way? Nicodene (talk) 04:18, 24 May 2024 (UTC)

Well to be honest it's not less clunky than {{surf}}. Vininn126 (talk) 09:10, 24 May 2024 (UTC)

I've got no strong opinion as to what it should be replaced with, but I too would like to get rid of this template; I never liked the wording. PUC – 15:04, 24 May 2024 (UTC)

We should first agree on the wording, and then consider the best way to implement it.  --Lambiam 16:57, 24 May 2024 (UTC)

What about "analysable as"? I'm not sure it's a good idea to use derive as it's already doing a lot of heavy lifting—we already use it in etymologies to refer to a term being derived from other languages, as well as in the "Derived terms" heading (and it was pointed out in an earlier discussion that these two uses are already possibly inconsistent). — Sgconlaw (talk) 19:07, 24 May 2024 (UTC)

As a bonus we could switch from {{surf}}'s up to {{anal}}. Vininn126 (talk) 19:10, 24 May 2024 (UTC)

Yes, instead of just scratching the surface let's go deep with {{anal}}. PUC – 19:51, 24 May 2024 (UTC)

Are we done with sniggering and drawing penises on the toilet stall door? — Sgconlaw (talk) 22:23, 24 May 2024 (UTC)

I have no idea what you're referring to. Vininn126 (talk) 22:23, 24 May 2024 (UTC)

@Sgconlaw Vague formulations like ‘analysable as’ (or per @Sokkjo ‘equivalent to’) are as mentioned problematic in that they result in users claiming synchronic impossibilities like “month = moon + -th” or “again = on- + gain”.

The use of “derived” in derived terms sections is actually an argument in favour of this proposal, now that you mention it, as there’d be an increase in symmetry here. The derivation of quickly from quick is already mentioned on both entries; why not use matching language in both places?

As for the (unrelated) use of the template der, that is as mentioned fixable by renaming it to {{ult(imately)}}, which seems more descriptive really, and then renaming af/surf to der/der+. Nicodene (talk) 22:58, 24 May 2024 (UTC)

@Nicodene: I would not be comfortable with changing {{der}}/{{der+}} to “ultimately”. We have been using “derived” in etymology sections to denote derivation from one source language to another, and now suddenly repurposing it to mean something else is, I feel, a step too far. Moreover, “ultimately” suggests to me the omission of intermediate steps of derivation to some remote source language like Proto-Indo-European. (For example, term X is derived from Old French, which is derived from Latin, which is ultimately from Proto-Indo-European (skipping over Proto-Italic).) — Sgconlaw (talk) 23:18, 24 May 2024 (UTC)

(Edit: see below.) Nicodene (talk) 05:00, 25 May 2024 (UTC)

Oppose The only verbiage I support is equivalent to in areas where people instead use {{surf}}. I also do not support users going around changing From {{af}} to {{af+}}, as creating {{af+}} would promote. -- Sokkjō 21:11, 24 May 2024 (UTC)

@Sokkjo: I guess I'm OK with "equivalent to" as well if there's consensus for that. — Sgconlaw (talk) 22:23, 24 May 2024 (UTC)

I would also prefer "equivalent to" over any specific template, and I'm using it regularly. Thadh (talk) 23:03, 24 May 2024 (UTC)

(Edit: see below.) Nicodene (talk) 05:00, 25 May 2024 (UTC)

Would this be a thread to take to a wider audience? Vininn126 (talk) 23:11, 24 May 2024 (UTC)

Certainly. Nicodene (talk) 23:40, 24 May 2024 (UTC)

Support Theknightwho (talk) 21:39, 24 May 2024 (UTC)

@Theknightwho: thoughts on the wording? — Sgconlaw (talk) 22:23, 24 May 2024 (UTC)

"Equivalent to" is fine, though @Nicodene raises a good point about the difference between long-range derivations which contain combinations of roots completely alien to a modern speaker (e.g. analysing health as whole + -th) versus readily apparent formations that just-so-happened to enter the language as ready-formed borrowings. The problem with "equivalent to" is that it could refer to either, so it would be helpful to establish an alternative to refer to one of them. Theknightwho (talk) 10:11, 25 May 2024 (UTC)

I’m not aware of any serious linguistic source that would publish a comment like “health is equivalent to whole + -th”, or the same equation using any of the other phrases mentioned above. Personally I don’t see the point of it. If one really feels the need to do that sort of thing, one can simply spell it out in words: “…from Proto-Germanic *hailaz + *-iþō, which correspond to the modern English whole and -th.” I don’t see why this should need a template. Nicodene (talk) 11:52, 25 May 2024 (UTC)

Here is my revised proposal.

At the moment we handle distant etymological relations like "surgical: ultimately from Ancient Greek χειρουργία" using the template {{derived}}. This is a bit strange given that our "derived terms" sections never feature these words, instead having only language-internal formations like cuteness (< cute + -ness), for which we do not use the template {{derived}} but rather {{affix}} and its various "children" like {{compound}}.

My solution is to replace the current template {{derived}} with {{etyl}} and then rename the current {{affix}} to {{derived}}. Hence, finally, {{derived}} will match "derived terms".

(Also we'll avoid the awkwardness of using a template called {{affix}} for compounds like greenhouse, where there is no affixation going on at all. And, perhaps, we can one day retire {{compound}} and other such templates, replacing {{blend|en|emotion|icon}} with {{der|en|emotion|icon|blend=1}} and so on. Cutting down the absolute jungle of ety templates to a more modest size.)

Following this the infamous {{surf}} can be renamed to {{der~}} with the displayed text changed to "derivable from". This is the only phrasing proposed thus far which is understandable to just about anybody yet precise enough to discourage nonsense like "health: analysable as whole + -th" or "husband: equivalent to house + bond".

Thoughts? (Pinging @Benwing2.) Nicodene (talk) 08:22, 25 May 2024 (UTC)

Categories of child languages also be a subcategory of parent language

Currently, when I would like to look at "Tagalog terms borrowed from Spanish", terms from category: "Tagalog terms borrowed from Mexican Spanish" do not show up. I would like to propose that "Tagalog terms borrowed from Mexican Spanish", "Tagalog terms borrowed from Early Modern Spanish" be a subcategory of "Tagalog terms borrowed from Spanish".

Of course, should be applicable in the entire Wiktionary categorization:

• Borrowed from Chinese

Subcategories:

• • Borrowed from Mandarin
  • Borrowed from Cantonese
  • Borrowed from Hokkien

[…]

Similar to currently implemented in;

• Derived from Latin
  • Derived from Vulgar Latin, Ecclessiastical Latin, Medieval Latin […]

Seems to me it's already working in derived terms but not in borrowed terms. Ysrael214 (talk) 12:41, 23 May 2024 (UTC)

Chinese isn't a good example here, as it works differently for reasons that aren't worth going into in this thread. I agree that it makes sense to subcategorise borrowings like this in general, though, but we shouldn't have categories like "Tagalog terms borrowed from West Iberian languages" and so on, even though Category:Tagalog terms derived from Spanish is in Category:Tagalog terms derived from West Iberian languages. Theknightwho (talk) 13:32, 23 May 2024 (UTC)

I agree that "X terms borrowed/calqued/etc. from [language variety]" should be a subcategory of "X terms borrowed/calqued/etc. from [language]" (in a similar manner to "X terms derived from [language variety]" being a subcategory of "X terms derived from [language]"). Einstein2 (talk) 19:11, 23 May 2024 (UTC)

The pos= parameter

This is widely used in links as a way to give non-glosses (e.g. Jeju (island in South Korea)), because giving the definition as a gloss would be incorrect (e.g. Jeju (“island in South Korea”) is incorrect, because "Jeju" does not mean "island in South Korea" in general). @Fenakhay has decided today that this is "misuse" of a parameter, which is something that came up at the entry Dagelet. I have no idea why this is a problem, how this is misuse of anything, or what they are hoping to achieve by objecting to this, really, but given this is clearly proving of some difficulty should we rename the parameter? Theknightwho (talk) 01:21, 25 May 2024 (UTC)

Never used the parameter myself, but it sounds confusing in the use that you describe. Support renaming it. CitationsFreak (talk) 03:01, 25 May 2024 (UTC)

We could introduce |q=. It'd make sense to harmonize the "comment" parameter across different templates. Nicodene (talk) 04:23, 25 May 2024 (UTC)

I don’t really see why it is a “mistake” to use the |t= parameter in cases like that, with the gloss enclosed in quotation marks. Don’t we define geographical places and other proper nouns (e.g., names of languages) without any special type of formatting anyway? If so, why should they be treated unlike other definitions here? — Sgconlaw (talk) 04:28, 25 May 2024 (UTC)

@Sgconlaw Leaving aside place names specifically, there needs to be a way to express non-gloss definitions that doesn't use quote marks, since quote marks imply it's a gloss. Theknightwho (talk) 04:30, 25 May 2024 (UTC)

Yes. I find it a bit jarring to encounter non-glosses placed in quotation marks as if they’re glosses. Not a terribly urgent thing, but still. Nicodene (talk) 13:29, 25 May 2024 (UTC)

q= seems like a qualifier, rather than a non-gloss 'definition', so people would surely end up using it for things like "archaic" or "British English", and then it'd be inconsistent if {{m|...|q=...}} generated (like pos= does) an unitalicized qualifier while {{m|...}} {{q|...}} generated an italicized one... so I think we'd need to make it italicize for consistency... and then the question is, do we consider that "archaic" and "island in Korea" are or should be treated (and formatted) as the same type of information? (If so, then no problem, I guess! OTOH, if we consider them different kinds of thing, and iff we don't want to keep using pos= for "island in Korea", another idea is ngd= or ng= (taking inspiration from {{ngd}}/{{ng}}). - -sche (discuss) 15:38, 25 May 2024 (UTC)

I'd prefer ng= for brevity, which is another one of its aliases: {{ng}}. Theknightwho (talk) 15:42, 25 May 2024 (UTC)

Here and there I’ve found myself wanting to specify things like “archaic” or “with silent ⟨f⟩”. But I don’t mind either way. Nicodene (talk) 16:16, 25 May 2024 (UTC)

If we want non-glosses we should have a parameter for that. I use the POS parameter a lot for designating part of speech. Vininn126 (talk) 14:02, 25 May 2024 (UTC)

I agree that in links |pos= should be limited to specifying parts of speech and shouldn't be used for formatting purposes. I also have no objection to the introduction of a separate |ng= (non-gloss definition) parameter, with the text italicized in line with {{non-gloss definition}}. However, we need to ensure consistency between how glosses and non-glosses are indicated in entries and within links. As I mentioned above, at the moment we seem to treat definitions for geographical terms as glosses. For example, one sense of Jeju is "An island, province, and city in South Korea", and this is not enclosed within {{non-gloss definition}}. If this is so, then we should not treat this definition as a non-gloss within a link. — Sgconlaw (talk) 16:47, 25 May 2024 (UTC)

@Sgconlaw To explain my thought process: "island in South Korea" is a truncated definition (given for the purpose of clarification) which unambiguously isn't a gloss, as "Jeju" is not a generic term for South Korean islands. Whether the output of {{place}} should be treated as a gloss or non-gloss is a separate question, really. Theknightwho (talk) 21:15, 25 May 2024 (UTC)

I'm fine with a new param |ng= (although on a practical level it will take significant work to implement it everywhere; to future-proof this, we might want a put a list of pass-through link params somewhere convenient, like in Module:headword/data or Module:links/data, and rewrite the places that have pass-through link params to use the list instead of hardcoding the set of params). I'm not sure whether it makes sense to italicize it; keep in mind that currently |pos= is often used for arbitrary text like "all meanings" that aren't necessarily non-gloss definitions. Benwing2 (talk) 22:09, 25 May 2024 (UTC)

An edge case here is what exactly counts as a “part of speech”, especially with affixes. I’ve often used and seen pos used to give descriptions like “verb-forming affix”, “suffix forming agent nouns”, “diminutive suffix”, etc. These are not solely confined to part-of-speech information, but they are basically a concise way of stating what the part of speech is along with what the affix is used for.--Urszag (talk) 05:39, 26 May 2024 (UTC)

If this proposal includes changing the formatting of what is currently output using the pos param in templates like {{m}}, then I must oppose, as we have used this extensively in JA entries as a way of including non-transliteration, non-translation information that is still within the parentheses, and reworking that will be a sizable PITA.

If this proposal is just about adding a parameter that will have identical output as pos currently does, I fail to see the point; quibbling that pos is "supposed" to mean "part of speech" seems rather silly to me. How params are used changes, much as how words are used also changes. That said, I would not be opposed to an additional parameter, provided that there is no compulsory need to rework existing content. ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:05, 31 May 2024 (UTC)

Don't you find the naming to be... inconvenient? Imagine if we took a {{{gloss}}} and used it to provide a transliteration or something, and several people did it cause they didn't have a translit parameter simply. Vininn126 (talk) 20:08, 31 May 2024 (UTC)

Shouldn't Wiktionary:No personal attacks be official?

Is there any good reason why that draft policy isn't official? Should we go about starting the process to make it official? Purplebackpack89 15:19, 25 May 2024 (UTC)

It's unnecessary. PUC – 15:30, 25 May 2024 (UTC)

Why is it unnecessary? What good can come of allowing personal attacks? Purplebackpack89 19:36, 25 May 2024 (UTC)

I didn't say we should allow personal attacks, I said having an official policy about it is unnecessary and I don't see what good is going to come of that. Common sense and common courtesy are enough; things might derail every once in a while but I see no need for all that time-intensive Wikipedia-style lawmaking. PUC – 22:07, 25 May 2024 (UTC)

As I see it there are really only two alternatives: 1) enacting a Wikipedia-style policy, or 2) this place becoming or staying the Wild West where users are allowed to harass and bully editors off the project. You say common sense and courtesy are enough but it's been my experience that some of the supposedly most-trusted editors on this project see no need to be courteous to other editors. Purplebackpack89 22:17, 25 May 2024 (UTC)

+1, I'd support it becoming official policy. AG202 (talk) 23:07, 25 May 2024 (UTC)

They don’t need to see a need. I believe in them to strive towards the optimal results rather, quite different from that which is “needed”. Sometimes it is making their stance clear of how low they esteem the opinions of certain editors in certain respects. Not needed for you, since you don’t have insight either way. Or for me, since I know I am retarded. I even make personal attacks against myself, what does the policy proposal say about it? Does it get your nose out of joint? Why does it happen when your pseudonymous internet identity is disrespected at some particular point in time? It’s not like we harass and bully you. Look at Kiwifarms, that’s bullying. Consistency is key. Fay Freak (talk) 23:12, 25 May 2024 (UTC)

The question is rather what good comes from a formal policy-page, save your personal stickling. The page has been added in February 2006, not changed since, when everyman has had made his experiences with the WWW for three years on 800 x 600 monitors via AOL CD-ROMs. Internet users have lost their virginities and even endured the MAGA era. There is extensive documentation how bad arguments and campaigns work over this medium; we call them out, and infer attributes of parties from their behaviour, sometimes also spanning decades, and vice versa, inasmuch as the factual argument is supported thereby.

Purplebackpack89 does not even understand the policy proposal he cites, which creates a false dichotomy by bidding to abstain from that but “discuss the facts”, which are quite different a thing in Wikipedia ~ early 2000s Richard Dawkins ideology of internet nerds: we also ignore “the facts”, as opposed to “the language”, and the audience having to make out its stance on it.

Behavioural addiction is a concept only paradigmized in this decade, our sensitivities of it, doomscrolling and other internet-related individual obsessive-compulsive behaviours conceptualized towards the end of the last. We should address people personally we suspect to have problematic behaviours; sometimes even to the point of remote diagnostics. If you read User talk:Surjection#what is wrong with you, or otherwise are attentive to the eccentricities added to Wiktionary and its discussions, you know that there is nothing left over, than perhaps refer to the psychiatrist; if there is data for this, an editor will get his personal homework. You see, some IP attacked me personally very heavily but I won. Nothing became better from a ban or something preventing a specific mode of discussion. Fay Freak (talk) 23:12, 25 May 2024 (UTC)

I think we need a vote to make it official. CitationsFreak (talk) 15:55, 25 May 2024 (UTC)

No objection if there's consensus to make it official. I agree it needs to be formally voted on. — Sgconlaw (talk) 16:38, 25 May 2024 (UTC)

• I have drafted the vote at Wiktionary:Votes/2024-05/Make No personal attacks an official policy Purplebackpack89 21:21, 25 May 2024 (UTC)

agreed — SAMEER (؂・؄・؏) 01:01, 26 May 2024 (UTC)

Agree with PUC: We don't have a policy forbidding murder either; does that mean murder is allowed on Wiktionary? No of course not. National laws prohibit murder, and basic human decency prohibits personal attacks. MuDavid 栘𩿠 (talk) 04:28, 26 May 2024 (UTC)

How can one murder on wiktionary? Word0151 (talk) 21:23, 26 May 2024 (UTC)

I agree with User:PUC that this policy seems unnecessary. It's not as though anyone is under the impression that personal attacks are allowed... Ioaxxere (talk) 04:57, 26 May 2024 (UTC)

For folks that state that we don't need a policy, I'll point to Wiktionary:Beer parlour/2023/July § How to report a user? and how even though there was a consensus to take action against said user, there has yet to any taken. CC: @bd2412 I would hope that we wouldn't need a policy like this, but it will at least force more action vs handwaving it away as we've seen happen here again and again. It doesn't look good on the community as is currently; we have too many instances of personal attacks, even in more public places like Beer parlour, for a userbase with this few active editors. (As seen by where this proposal came out of) AG202 (talk) 08:41, 26 May 2024 (UTC)

Reading back through that discussion, I'm truly disappointed that several admin and many active users said that something should be done but yet nothing was done. If that doesn't show why we need more explicit policy, I don't know what does. It just shows pure favoritism at this point, almost like an old guard. AG202 (talk) 08:50, 26 May 2024 (UTC)

@AG202 In that particular case, I don't see how an official policy would have made any difference, unless it mandated that specific things must happen under certain circumstances. The current proposal doesn't do that, and any that did would need to be formulated very carefully. Theknightwho (talk) 23:35, 26 May 2024 (UTC)

I agree. We must have some way to punish those who break the rule, or it's worthless. CitationsFreak (talk) 02:43, 27 May 2024 (UTC)

I support updating the policy to have an enforcement mechanism, but if I'm going to be real, I'm disillusioned with the whole thing. Even if we had a policy at that time, knowing how little enforcement goes on around here, I doubt anything would've been done anyways. ¯\_(ツ)_/¯ AG202 (talk) 17:43, 28 May 2024 (UTC)

@AG202: Having an official policy should make it harder to sweep violations under the rug, at least in theory. That being said, most of the abusive behavior I've witnessed here came from the same user, so I wouldn't be surprised if it naturally becomes less of an issue from here on out. Binarystep (talk) 11:03, 29 May 2024 (UTC)

I support this. I didn't know it wasn't policy already. —Caoimhin ceallach (talk) 17:04, 27 May 2024 (UTC)

Wu lects

With current Yue subdivision discussions underway, I would like to ask for a parallel discussion regarding the exact same subject but for Wu. Similar discussions have already happened and the consensus is as follows:

• wuu Wu Chinese 吳語
  • wuu-nor Northern Wu 北部吳語 (alias: Taihu Wu 太湖片)
    • wuu-sha Shanghainese (Shanghai Wu) 上海小片
    • wuu-sji Sunan Wu (Suzhounese) 蘇嘉小片 (Sunan: 蘇南)
    • wuu-sdc Shadi Wu 沙地話
    • wuu-pil Piling Wu 毗陵小片
    • wuu-txh Tiaoxi Wu 苕溪小片 (Huzhounese 湖州小片)
    • wuu-lsx Linshao Wu 臨紹小片
    • wuu-nby Yongjiang Wu 甬江小片 (Ningbonese 寧波小片/明州小片)
    • wuu-hzn Hangzhounese 杭州話
  • wuu-tzo Taizhounese 台州片 (Taizhou Wu)
  • wuu-wzh Oujiang Wu 甌江片 (Wenzhounese 溫州片)
  • wuu-jhw Wuzhou Wu 㜈州片 (Jinhua Wu 金華片)
  • wuu-lsc Chuzhou Wu 處州片 (Lishui Wu 麗水片)
  • wuu-sqx Xinqu Wu 信衢片 (信 Xin = Shangrao)
  • wuu-xww Xuanzhou Wu 宣州片 (Western Wu 西部吳語)

Notes:

1. Shanghainese and Taizhounese adopted as their respective concepts encompass most if not all lects within the branch they describe. In particular, "Shanghainese" can also refer to urban-like suburban lects, or even all suburban lects in general, and there is no representative lect for the Wu spoken in Taizhou prefecture

2. Hangzhounese is an isolate within the Northern Wu family; it has significant Northern Mandarin influence and has even so far as to have been classified as a Mandarin language by some

3. Inland Wu subdivisions (much like some Yue areas) is highly contentious and the scheme adopted here is one that the Wu editors stick to, and is essentially a slightly modified version of the 1987 Atlas subdivisions

4. Northern Wu will be a family code, like the potential future Yuehai code. Its further subdivision is purely practical as both active Wu editors tend to focus on Northern Wu, and is not a value judgement regarding the significance of Southern Wu sub-subbranches

5. Southern Wu is highly likely to be areal and thus will not have a corresponding code

If there are no objections, we shall follow through with this and implement these codes as soon as possible. @Musetta6729 (Notifying Atitarev, Benwing2, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): — nd381 (talk) 21:14, 25 May 2024 (UTC)

@ND381 This is overall fine with me and seems suitably conservative and flat. My main concern is with the codes; I'd prefer to use codes that are less arbitrary and use the first three letters of the lect name whenever possible, otherwise using the first two letters of the first part along with the first letter of the second part. Benwing2 (talk) 22:03, 25 May 2024 (UTC)

The codes already for the most part adhere with what you want.

• Northern
  • Shanghai
  • (ISO 639-6 code for Sujiahu)
  • Shadi, Chongming (Shadi is a place name)
  • Piling (no representative lect)
  • Tiaoxi, Huzhou (Tiaoxi is a place name)
  • Linhang-Shaoxing (Linshao is an abbreviation of these two place names; Shaoxing is a prefecture whereas Linhang is a county)
  • Ningbo, Yongjiang (spoken only in Ningbo prefecture and the tiny Zhoushan prefecture)
  • Hangzhounese
• (ISO 639-6 code for Taizhounese)
• (ISO 639-6 code for Wenzhounese)
• Jinhua, Wuzhou (spoken only in Jinhua prefecture)
• Lishui, Chuzhou (spoken in Lishui prefecture)
• Shangrao-Quzhou, Xinqu (Xinqu is an appreviation of these two prefecture names; X included at the end to signify the historical abbreviation)
• Xuanzhou Western Wu (Western Wu is a common name for the branch)

Some of these could have their letters shuffled around but for the most part they are already, in fact, two letters from one name and one letter from another name — nd381 (talk) 10:29, 26 May 2024 (UTC)

After some consideration and discussion amongst the Wu editors the codes have been revised and normalised to the following version: all add-on codes (except the ones for Northern Wu and Shanghainese) now start with two letters from the first syllable and one from the second syllable of the name. The codes have been devised already a while back but for archival purposes I feel it's sensible to repost them here.

• wuu Wu
  • wuu-nor Northern Wu 北部吳語 (Taihu Wu 太湖片)
    • wuu-sha Shanghainese / Shanghai Wu 上海小片
    • wuu-suj Su-Jia Wu 蘇嘉小片 (Sunan Wu 蘇南片)
    • wuu-shd Shadi Wu 沙地話
    • wuu-pil Piling Wu 毗陵小片
    • wuu-tix Tiaoxi Wu 苕溪小片 (Huzhounese 湖州小片)
    • wuu-lis Linshao Wu 臨紹小片
    • wuu-yoj Yongjiang Wu 甬江小片 (Ningbonese 寧波小片/明州小片)
    • wuu-haz Hangzhounese 杭州話
  • wuu-taz Taizhou Wu / Taizhounese 台州片
  • wuu-ouj Oujiang Wu 甌江片 (Wenzhounese 溫州片)
  • wuu-wuz Wuzhou Wu 㜈州片 (Jinhua Wu 金華片)
  • wuu-chz Chuzhou Wu 處州片 (Lishui Wu 麗水片)
  • wuu-xiq Xinqu Wu 信衢片 (Shangrao-Quzhou Wu)
  • wuu-xuz Xuanzhou Wu 宣州片 (Western Wu 西部吳語)

— Musetta6729 (talk) 16:51, 4 August 2024 (UTC)

Luwian hieroforms template

Some Hieroglyphic Luwian lemmas have multiple spellings. Therefore I need a template similar to {{egy-hieroforms}} for Hieroglyphic Luwian for them. Can this be done? Antiquistik (talk) 08:49, 26 May 2024 (UTC)

Latin pronunciations in English entries

There are some unadapted Latin borrowings in English that were given Latin pronunciations by Doremitzwr along with English ones. They are (at least): argumenta ad populum, argumentum ad populum, opere citato, operibus citatis, pactum de non petendo, simpliciter. It seems to me such pronunciations don't belong, so I'm going to delete them. I also found an Aramaic entry מלכתא with an Ashkenazi Hebrew pronunciation, which I suspect doesn't belong either, but I'm leaving it for now. Bringing this up here in case people have other thoughts. Benwing2 (talk) 09:18, 26 May 2024 (UTC)

BTW the Latin pronunciation was the only one given for pactum de non petendo. Can someone supply an English pronunciation? Benwing2 (talk) 09:23, 26 May 2024 (UTC)

Done. This is almost never said aloud in English, as far as I can tell. Theknightwho (talk) 21:47, 26 May 2024 (UTC)

Guy has done so because they are not English, notwithstanding the header and templates. Save for simpliciter, everyone of them should be moved to Translingual according to my correct custom of viewing the things. I mean you already admitted it for op. cit., so why is opere citato “English”? Both can have both English and classicizing Latin pronunciation under a Translingual header. The linked terms are used in German as well but German dictionaries would not include them and claim them to be German, less propense to see foreign terminology as integrated. Fay Freak (talk) 22:48, 26 May 2024 (UTC)

@Fay Freak You are probably right. Benwing2 (talk) 22:50, 26 May 2024 (UTC)

I think that's a misunderstanding of what it means to be Translingual: if something is Translingual, then it very much can still part of English, but it's convenient to avoid having tons of duplicate entries all with the same spelling. There's also the issue of differing pronunciations, which has come up before in relation to Translingual A4 (paper size) (which is part of everyday English in the UK, even though we only have a Translingual entry for it). Theknightwho (talk) 22:52, 26 May 2024 (UTC)

Just FYI, we can have Pronunciation sections in Translingual entries with the pronunciation in multiple languages. An example where this occurs with several languages is Homo sapiens. I just created {{IPA+}} to make this a bit easier; it prefixes the output with the langname, similar to {{m+}}. Benwing2 (talk) 23:49, 26 May 2024 (UTC)

And the paper size, which we etymologize as from a German standard, is interestingly in German speech DIN A4 [dɪn ʔaː fiːɐ̯], as the regulatory authority is die DIN f [diː ˈdɪn]; A4-Papier is also a word, but we can form compounds even from a third language + section language via |langN=, not only translingual + section language. And yet it does not completely outrule that even this, DIN A4, is translingual.

It is a bit like with family names and other stuff, we had nasty votes about, that is not subjected to normal language rules by the community (Verkehrsanschauung, the jurist says). I ask whether something is intended to be translingual in the beginning: as certain now famous units, the meter, Kelvin and what not, which started in the monolingual scientific communities of certain countries.

For the bejel disease I added Latinate translingual translations in 2018 some of which were only ever found in German medicine works—because the common microbial identity of the diseases of various countries was only later recognized when hygiene ousted them.

As for pactum de non petendo, this is in turn one of the kind of terms that has been left over from the Middle Ages or so when they spake Latin in college, and ius commune and hence Latin as a law language was superseded only by the German Civil Code in 1900, with not every dogmatic term translated however. I probably have heard pactum de non petendo, but this is practically not so important so I bring forward more entropic examples like venire contra factum proprium also connected to § 242 BGB, and a long baggage around the law of unjust enrichment such as condictio indebiti, condictio ob rem, datio ob rem, datio obligandi causa, condictio ob turpem vel iniustam causam etc., which are mentioned and said to be found in a provision of the German Civil Code if the individual jurist likes so, by how much he is instilled by knowledge of the legal system’s historical background (the most illustrative example of this is the student book by Hans Josef Wieling on unjust enrichment last edition 2020), which also counterindicates all these terms being German or English.

Science and academia, whether debating arguments, for which it refers to known terminology about fallacies and cognitive biases, or just teaching, has to explain loan formations and intellectual history as contrasted from outside languages and debates, and hence carries forward terms and creates false impressions of regular inclusion of a term within a language.

Where in Arabic or Indian classrooms some scientific fields are difficult to discuss in the local native language at all, we are better in England and her former colonies and Germany to translate all education, but some Latin terms have been left over for centuries, and in a German psychology paper, not to speak of IT, there is a whole lot of untranslated English because you just got to know it anyway to get the grades.

It happens in all classes; practically you can’t understand this German drill I quoted at rambizzy without also being proficient in English. For law students they publish booklets like Latein für Jurastudierende; guess for some sciences you technically have to have some limited proficiency in a foreign language, morphology knowledge + basic stems, again indicative of these terms not being German.

Guess this is intuitive for me because I have atypical attention to details rather than to absorb every word-string as a social feedback integrating in the language community where it has been encountered; I don’t blame editors for not having thought around the corner so much when their language, English, has a low threshold of integrating foreign terms; and I had to illustrate the problem with German to mark the contrast of foreign vs. borrowed; and I know people don’t have the same propensity to systematize, or even the capacity, without both hyperpolyglottism and interdisciplinary excursions at play, even though it actually happen most closely to how I have described it. Fay Freak (talk) 00:17, 27 May 2024 (UTC)

I feel like it's the same level of difficulty for translating in non-European-language classrooms. People who want to discuss science topics without the words needed to do so coin them, either by borrowing them (as you say), calquing them, or describing what the term refers to.

Also, that German quotes does not belong in an English entry. The song is a German song which uses code-switching. I don't think that a random English entry is the best place to demonstrate the fact. Maybe an appendix page? CitationsFreak (talk) 08:10, 27 May 2024 (UTC)

It would not be completely unreasonable to call all Latin-derived expressions that retain inflection used in learned and not-so-learned writings (eg, "scientific", medical, and legal Latin) Latin. But here our rules against including SoP expressions as well as the pronunciation differences work against it, despite the administrative simplicity that would result.

It would also not be unreasonable to call such expressions Translingual, once there is evidence of use embedded in running text in multiple (2, 5, 10?) languages. This violates few of our firm rules, I think, merely requiring that we allow pronunciations for multiple languages. A problem is the one of evidence of use in multiple languages. As a practical matter, it would be sufficient IMHO to start an entry for such an expression in whatever languages had sufficient evidence, typically including English. Once there were 2, 3, or more L2s, the L3s could be merged. Another demonstration of Translingual use might be single (ie, not triple) instances of use in a number of languages: eg, one use in Chinese, one in Japanese, one in Arabic, one in Spanish. DCDuring (talk) 14:48, 27 May 2024 (UTC)

What concerns me is that this will make attestation requirements more complicated, since by merging them into one “language” it’s only necessary to find 3 uses in any language at all, which is not particularly difficult. For example, pactum de non petendo is comparatively hard to attest in English, since it’s not terminology used in English law or any of its descendants, from what I can tell (the equivalent term used in such situations being estoppel, at least in England). Edit: I forgot about Scots Law, but the general point still stands. Theknightwho (talk) 15:02, 27 May 2024 (UTC)

IMO three uses, not all in the same language, should suffice the CFI criterion.  --Lambiam 16:33, 27 May 2024 (UTC)

Urgh. I've just spotted that Translingual isn't in the list of well-documented languages, which technically makes it a limited documentation language (i.e. only one citation is required). This obviously doesn't reflect actual practice, but we should probably correct that for clarify; particularly if there's consensus that we want to put more kinds of terms under the Translingual heading. Theknightwho (talk) 16:42, 27 May 2024 (UTC)

Stalking/harassment by User:Theknightwho

User:Theknightwho is an admin, but a controversial one. Last year, he faced a de-sysop vote. While he was allowed to retain his admin privileges, people on both sides expressed concern about his combative behavior, with comments such as, "he seems to not know when to stop and distance himself from a fight.", "Maybe Knight is a hothead, maybe Knight broke the rules" and "I have my issues with User:Theknightwho...and I agree with the statement that he's a hothead and argues way too much"

I'm afraid he's up to his questionable behavior again. I believe he is targeting me, stalking me, harassing me. And on top of that, some of the edits he made in targeting and harassing me...

1. On Saturday, he modified or undid my edits on three different pages in a fairly short amount of time. Per the "quacks like a duck" test, it is unlikely those
   • I told him that those edits were inappropriate. He refused to see any problem
2. Later that day (it was either Saturday night or Sunday morning), he undid an edit I made to hot dog
   • His edit was so bad it had to be modified only a few minutes later.
3. And today, he deleted seven redirects I created over the years. Some of them are acceptable redirects...for example, he deleted busted my neck, which as a conjugation of bust one's neck

What is to be done about Knight's stalking/harassment of me? Can somebody tell him to cut it out? Purplebackpack89 15:58, 27 May 2024 (UTC)

Keeping an eye on a newly active (even returning) user, especially one making questionable edits, is not stalking or harrassing. Vininn126 (talk) 16:12, 27 May 2024 (UTC)

It's acceptable to a point. Knight is beyond that point. He's following me around hither and yon after I told him it bothered him. It's likely he's following me around BECAUSE it bothers me. If the edits were that questionable, somebody else would've undone them. And please also address the fact that, in his haste, Knight himself has made questionable edits Purplebackpack89 16:16, 27 May 2024 (UTC)

This accusation seems silly, to be honest. Vininn126 (talk) 16:20, 27 May 2024 (UTC)

I reviewed your contributions, changed a small number of them, and deleted some (unused) redirects you created a long time ago because we don't tend to have redirects in mainspace. None of this is out of the ordinary, and it's something that lots of admins do as a form of quality control. It's not anything personal, and the overall aim is to guide you to being a better editor, which is why I tagged you with explanations of the changes I made when I edited don't tread on me.

Since then, you have posted on my talkpage multiple times trying to pick a fight ([15] [16] [17]), as well as that of another admin ([18]). I explained to you that I review the edits of lots of other users, and @Equinox also told you that it is perfectly normal for admins to review the edits of users who are potentially making mistakes. I'm not going out of my way to target you, I'm not drawing lots of attention to the changes, and I'm not being mean; what I mostly care about is making sure that entries are up to standard.

Accusing someone of "harassment and stalking" is quite a serious thing to do (and I'm not sure you've really grasped how serious an accusation that is), and quite honestly I'm mostly just baffled at this level of reaction to some pretty basic oversight. That being said, I'm not going to reply to this thread any further, because I don't think there's much point: you've made up your mind that everyone is out to get you, and that's just how it's going to be. Whatever your motivations here, I don't see this discussion going anywhere productive. Theknightwho (talk) 16:18, 27 May 2024 (UTC)

Knight, Where it needs to go is you need to a) understand that the way you're going about this bothers me, b) admit that some of your edits themselves were problematic and c) disengage from me

Even though making a claim of harassment is serious, I stand by it 110%. The fact is, AFTER I said that your "monitoring" bothered me, you went out and "monitored" my edits some more, even though a) some of the things you changed or deleted had been that way for months or years, and b) you KNEW that it was likely to bother me. Many other editors would have stepped away in that situation and it's surprising that you didn't. And, as witnessed from your behavior last year, this isn't the first time you've been combative like this Purplebackpack89 16:55, 27 May 2024 (UTC)

So we shouldn't monitor editors and let them make quesitonable edits, like on sandwich? No thanks. Vininn126 (talk) 17:01, 27 May 2024 (UTC)

If the edits were that necessary, somebody other than Knight would make them. As for hot dog and sandwich, see below about why sandwich had to go Purplebackpack89 17:03, 27 May 2024 (UTC)

That's ridiculous. Monitoring edits is monitoring edits, whether it's one editor or not. This is making a mountain out of a molehill. Memifyed classyficaiton can be presented neutrally in definitions, if you're not aware of that I'm glad someone is keeping an eye on you. Vininn126 (talk) 17:06, 27 May 2024 (UTC)

There's two parts to this here. It's not only (a) should my edits be monitored, but (b) should Knight be the one doing it, and (b1) doing it in the manner he's doing. Just because my edits MIGHT need monitoring doesn't mean that it has to be Knight specifically doing it. Please also note another editor has expressed concerns with Knight's editing Purplebackpack89 20:16, 27 May 2024 (UTC)

I saw. I also saw the "hounding" that was happening and I'd say it's an overstatement. Vininn126 (talk) 20:17, 27 May 2024 (UTC)

I'm gratified to hear I'm not the only editor whom TKW stalks, harasses, and tries to intimidate. —Mahāgaja · talk 17:05, 27 May 2024 (UTC)

Please don't make personal attacks - I have done no such thing, as you well know. If you have grievances, raise them, but what you've just said is a pretty clear-cut attempt to poison the well. Theknightwho (talk) 19:53, 27 May 2024 (UTC)

Anyone who wants to see how you interact with me is welcome to peruse User talk:Mahagaja/Archive 28#Link templates in etymologies and User talk:Mahagaja#+ templates. In both cases, you went into my contribs to revert or re-edit my edits to bring them into conformance with your preferences, and in the first one you threatened to "report" me to the Beer Parlour for not editing the way you want me to. I consider that stalking, harassment, and an attempt at intimidation. —Mahāgaja · talk 20:17, 27 May 2024 (UTC)

It's one thing to change a plus template to its non-plus equivalent, it's another to switch it to {{der}}. Vininn126 (talk) 20:19, 27 May 2024 (UTC)

@Mahagaja could you link to this discussion, or at least give the approximate time it occurred?

@Vininn126 Irrelevant. This isn't about being right or wrong. That doesn't give an editor carte blanche to be unkind. Purplebackpack89 21:32, 27 May 2024 (UTC)

@Purplebackpack89 how can you comment when you haven't even seen the conversation? Vininn126 (talk) 21:36, 27 May 2024 (UTC)

@Purplebackpack89: The links are in my comment above. —Mahāgaja · talk 06:59, 28 May 2024 (UTC)

@Mahagaja Alright, let's go over things, shall we? Aside from this thread, we've only properly interacted twice:

• On the first occasion, what I took issue with was the fact you have been replacing many instances of {{inh}} with {{der}} purely because you're worried someone might change it to {{inh+}} ([19]). Leaving aside your view that {{inh+}} "is an abomination of a template that makes me angry every time I see it" (truly the Olympus Mons of all molehills), what you were doing - and may still be doing, for all I know - is genuinely detrimental to entries, because it reduces the accuracy of categorisation. This is something that I ([20]) and later Thadh ([21]) told you, and at no point (even now) have you made it apparent that you even understand this is what I (and others) are taking issue with, nevermind say you'll stop doing it. Instead, you ignored me, carried on doing it anyway, then asserted that there's no policy saying you can't add {{der}} instead of {{inh}} ([22]) - which was never the issue - so I told you that I would start monitoring and reverting your edits, given that you'd made it very clear you had no intention to stop ([23]). This is not intimidation, harassment or stalking: it's a statement that the issue will be raised in a public forum for dispute resolution, and that harmful edits will be reverted; a very standard escalation of an issue in response to someone making it clear they have no intention of backing down. And let's be absolutely clear, here: the issue is not - and has never been - an issue of personal preference, because the display outputs of {{inh}} and {{der}} are identical. You are obviously a very intelligent person, so I find it extremely unlikely that you didn't understand precisely what the problem was, but evidently you didn't care: your worries about the plus templates took priority over the quality of entries, in your view, and that's all that mattered to you.
• On the second occasion, Vininn126 reached out to you to try to compromise with you, since they added a plus template to a Lower Sorbian entry, which you then reverted. This wasn't a problem in and of itself, but I (and Vininn126) took issue with you saying "Even if I'm not doing a lot with Lower Sorbian at the moment, I did put in a lot of work on it when I created the entries, and it upsets me to see my hard work ruined." ([24]), which (a) was a pretty clear attempt to claim ownership, and (b) is just a completely ridiculous thing to say under the circumstances, really, which is what I said to you then ([25]); obviously this was not said in my capacity as admin. But... let's be frank, here: what is there in that thread which constitutes harassment, stalking or bullying? It's a firm conversation, where you gave as good as you got. No more; no less. Theknightwho (talk) 21:43, 27 May 2024 (UTC)

You don't get it, do you, Knight? You say, "you gave as good as you got". NOTHING justifies you going low. NOTHING. And the fact that you're an admin now means you should be behaving BETTER, not worse. Purplebackpack89 23:36, 27 May 2024 (UTC)

"A firm conversation" is not "going low". We're well beyond the looking-glass at this point, judging by the state of this thread. Theknightwho (talk) 23:47, 27 May 2024 (UTC)

I'll pile on here as someone who didn't see this conversation before: replacing {{inh}} or {{bor}} with {{der}} just so people won't change it to another template later is something I can only describe with two words: abject stupidity. People who willingly make stupid edits and proudly proclaim that they're making stupid edits have no right to complain when people look over their edits to make sure they haven't done anything stupid. — SURJECTION ^{/ T / C / L /} 16:24, 29 May 2024 (UTC)

ALL editors are entitled to dignity. They shouldn't be hounded or attacked. And Knight and Equinox have a rather sordid history in that regard. Purplebackpack89 16:26, 29 May 2024 (UTC)

In this particular case, i.e. with regard to that template monitoring, it's safe to say that that did not happen. The complaint is not based in anything that happened. Vininn126 (talk) 16:31, 29 May 2024 (UTC)

Just to clarify: stupid edits that the editor is expected to know are stupid, especially after multiple people have pointed out to them why they are stupid. — SURJECTION ^{/ T / C / L /} 16:51, 29 May 2024 (UTC)

Sometimes you have a point (Equinox shouldn't have called you a moron the other day), but those reverts of Theknightwho's you talked about are unobjectionable. (entree instead of sandwich to describe a hot dog manages to be both obscure and ambiguous.) —Caoimhin ceallach (talk) 16:55, 27 May 2024 (UTC)

Sandwich is actually more controversial than you might think: there's actually widespread disagreement about whether or not a hot dog is a sandwich. Entree probably wasn't perfect but Sandwich is questionable as well, albeit for different reasons Purplebackpack89 17:02, 27 May 2024 (UTC)

@Purplebackpack89: TKW actually faced two desysop votes last year, the second being initiated by myself. Beyond that, I'm tired. There's a reason that I don't edit Wiktionary any more. WordyAndNerdy (talk) 22:43, 27 May 2024 (UTC)

I also see Equinox is still grinding his idealogical axe around here. Threw a transphobic insult at me out of the erroneous presumption I'm a trans woman. He ought to have remembered I'm a cisgender woman given he used misogynistic language in reference to me ("abused wife") last year. Whatever. This nonsense is the exact reason I don't contribute any more. Wiktionary collectively refuses to do anything about toxic editors and there's only so many times I can keep butting my head into the same wall. WordyAndNerdy (talk) 23:30, 27 May 2024 (UTC)

It's experiences like yours, @WordyAndNerdy that make it paramount to have real "no personal attacks" and "harassment" policies on this project Purplebackpack89 23:34, 27 May 2024 (UTC)

Does collecting password-protected dossiers about Wiktionarians you don't like count as hounding or doxxing? WordyAndNerdy (talk) 15:32, 28 May 2024 (UTC)

What does something Equinox did have to do with this thread? Theknightwho (talk) 15:48, 28 May 2024 (UTC)

TKW's sudden unfamiliarity with indentation aside, can an uninvolved admin please look at this? Equinox releasing what appears to be a Pastebin doxx file is extremely concerning. WordyAndNerdy (talk) 17:13, 28 May 2024 (UTC)

@WordyAndNerdy: This is going to be my first and hopefully only comment in this thread. If I'm going to be real, most folks here don't care. Compare the response to the announcement below, even some of the same users agreed that he should be sanctioned for his behavior and previous racist & anti-LGBTQ comments. It's disappointing but not surprising. The amount of negative experiences (especially for queer & BIPOC folks) the project is willing to overlook just because someone is active is baffling. It's an old guard in the truest sense, and that's why I'm trying to focus more on making sure that the work I do here is as silo-ed as possible, for better or for worse, though I understand why you wouldn't want to contribute at all. AG202 (talk) 17:40, 28 May 2024 (UTC)

@WordyAndNerdy Yes it's concerning to me, although I can't read the files to know what's in them (they appear to be mostly screenshots of some sort?) and I'm not sure what can be done at this point since Equinox is already de-sysopped. In light of this and previous behavior, it might make sense to require a vote if Equinox decides to come back. Benwing2 (talk) 19:09, 28 May 2024 (UTC)

Perhaps it would have been best to check they were password-protected before throwing around accusations of doxxing. Nobody has any idea what they are, and there is no way for any of us to find out. To be clear: I'm not saying it was a good idea - it's not, and it concerns me a lot - but WordyAndNerdy is not helping by fearmongering either. Let's try to keep our heads. Theknightwho (talk) 19:11, 28 May 2024 (UTC)

@Benwing – Voluntary relinquishment of one's admin tools is not "de-sysoping." There has been no formal sanction against Equinox, nor does there seem to be any desire to take a critical look at the repeated, sustained policy transgressions on his part. Every few years the WMF launches another inquiry into the Wikimedia gender gap. The answer is quite simple, I'd hazard. How many women, POC, and LGBT people want to stick around in an environment that's become a toxic boys' club? Where it's seemingly acceptable for an admin in good standing to call people "abused wife" and the F-slur? Where pointing out a missing stair means being bullied, ostracised, and gaslit? "Information about Wiktionary's so-called Vanguard Party" isn't some incomprehensibly cryptic reference. Equinox has demonstrated a personal animus against users who called out his anti-LGBT axe-grinding on multiple occasions. WordyAndNerdy (talk) 21:21, 28 May 2024 (UTC)

I agree that there is a problem with a lack of contributions from non-male, non-white etc. people, just like the huge imbalance in the wider software industry. And there seems little appetite to address problematic but productive contributors, partly because there are so few such people who are both competent and willing to put in the time and partly because many people are conflict-averse (I admit to being one of them). People have been blocked in the past for racist etc. behavior (e.g. I permablocked Dan Polansky for this), but it often takes much longer than it should. At the same time, do you think it makes sense to hold such an inquiry now for Equinox? It seems to me a bit like closing the barn door after the horse has escaped. This should clearly happen if/when Equinox decides to return (and you can see from Special:UserRights/Equinox that this happened once before, along with a de-sysopping for deleting the main page, followed by a later vote to restore his adminship), but I doubt there is an appetite to do anything now. Benwing2 (talk) 22:03, 28 May 2024 (UTC)

I do wonder if we could change the culture here, make people less conflict-adverse. (And also get some new faces in here.) CitationsFreak (talk) 22:23, 28 May 2024 (UTC)

I agree - I think much of the issue comes from having no structured conflict-resolution mechanism. That cuts both ways, of course: accusations made to harass other editors also go unpunished, which is a perennial problem we encounter as well. It's obviously no coincidence that WordyAndNerdy chose now - of all times - to reappear after many months. Theknightwho (talk) 22:36, 28 May 2024 (UTC)

@Theknightwho What does the last sentence mean? Are you saying that User:WordyAndNerdy is somehow harassing Equinox by calling out examples of his prior bad behavior? That seems patently unfair, to say the least; she was on the receiving end of (what to me certainly looks like) abuse, and doesn't seem to have reciprocated the abuse. Benwing2 (talk) 05:39, 29 May 2024 (UTC)

@Benwing2 I'll be completely clear: I think WordyAndNerdy saw this thread as an opportunity to start bashing me in a public forum again, which is why she picked this thread to make her first edit in over 8 months ([26]) and why 6 of the 12 edits she's now made have been here. She has had a grudge against me for a long time, which is no secret.

Let's take a step back for a second and actually look at what's going on here: Purplebackpack89 has made some very serious allegations with absolutely no basis in reality, Mahagaja saw this as an opportunity to do the same (and - surprise surprise - has mysteriously disappeared once I gave a thorough rundown of what actually happened), and WordyAndNerdy has decided to crawl out of the woodwork to pour fuel on the fire. If anything's harassment, it's threads like this, which I've had to put up with time and again because there are never any consequences for lying about other users, and some users have clearly figured that out. We're not Wikipedia, but I'm pretty certain all three users would have been sanctioned there for their conduct in this thread - potentially quite severely - since stalking, harassment, bullying and intimidation are all serious things to accuse someone of, and should not be done lightly.

I'm not going to defend Equinox's transphobic comments, but that happened after WordyAndNerdy commented in this thread, so let's not kid ourselves about why she was here in the first place or what her intentions were. Theknightwho (talk) 05:57, 29 May 2024 (UTC)

@Theknightwho Thanks for the clarification; I do appreciate it. This deserves more discussion but I'm too tired now to write anything substantive, so it'll be tomorrow. Benwing2 (talk) 07:05, 29 May 2024 (UTC)

Exaggerating? Maybe. It's not lying. If this were Wikipedia, you'd have never been made an admin. And you need to approach this with some introspection about how you interact with other people, because it should be obvious from this AND ELSEWHERE that several people don't like the way you interact with others. Purplebackpack89 16:39, 29 May 2024 (UTC)

The examples you've taken are just correcting incorrect information. That's harrasing? Vininn126 (talk) 16:43, 29 May 2024 (UTC)

I didn't want to comment further. But I see that TKW's modus operandi hasn't changed. Namely, he habitually responds to every complaint about his conduct as an admin as if it's an isolated incident to obscure the long-term pattern, then shifts to deflection when he can't deny his problematic conduct but steadfastly refuses to be held accountable for it. So I become a bully "crawl[ing] out of the woodwork" in service of a "grudge" instead of a past target of admin abuse coming forward to offer factual information to a current target. The thing TKW conveniently left out here is that my reversion at febfem was three minutes after my first BP post ([27][28]), was undoing a months-old drive-by edit by an IP rather than something Equinox did ([29]), and wasn't the only belated edit I made to entries on my watchlist ([30][31]). There was little reason for Equinox to intercede at febfem and absolutely no justification for the transphobic insult he threw at me. But TKW is seemingly invested in the narrative that only bad-faith actors criticise his conduct and that of his personal friend Equinox ([32][33]). That's why TKW apparently felt it necessary to state "but that happened after WordyAndNerdy commented in this thread" as if this somehow explains or justifies Equinox's abusive remark. It's easy to make sweeping and largely unevidenced accusations. It's a lot trickier to rebut bad-faith smears while also presenting a serious and painstakingly evidenced case of your own. That, I'd hazard, is what TKW banks on. That his targets get too worn out to pursue redress. That they stay silent for fear of retaliation. That Wiktionary's collective attention moves on before it examines his conduct too closely. He's played this game with me. He's done it with User:Huhu9001 and User:LlywelynII. And now he's doing with PBP89. WordyAndNerdy (talk) 21:39, 29 May 2024 (UTC)

@Benwing2 This is the kind of comment I was talking about. It's largely irrelevant (I am not Equinox, and WAN's conduct after first commenting in this thread can't possibly explain away why she decided to post here in the first place), or simply untrue (I've condemned what Equinox did; I never tried to justfy it). WAN has also tagged users she knows have personal issues with me, as a way to draw them into this thread, and used her own previous attempt to harass me (the desysop vote) as a justification for doing it again here, which is probably the thought-process that explains why this keeps coming up, quite frankly: you can't just keep re-trying someone over and over until you get the result you want, while saying "well, this has happened lots of times before so it must be true!"

It's textbook harassment, and it needs to stop. Theknightwho (talk) 23:34, 29 May 2024 (UTC)

It is strange. User:Theknightwho has never been anything but civil and polite to me, and does all the right things: apologizes when he's wrong or makes a mistake, thanks me for contributions, etc. Yet, I see a pattern of fights happening between TKW and several other contributors that isn't the pattern for other admins. It's true that not everything User:WordyAndNerdy says is reasonable (e.g. just because TKW met Equinox once doesn't make them personal friends). It's also true that some of the contributors TKW has engaged in fights with are (IMO) either annoying, incompetent or generally hard to work with. But at the same time, TKW I think you need to ask yourself, is there a way I could have avoided low-level arguments with various users escalating into major personal conflicts? In any conflict or dispute, regardless of who's right or wrong, the onus is on both people to de-escalate; and this goes even if the other person isn't doing so. Not every provocation deserves a response; often, silence is golden, and will lead to the person who made the outburst ending up with egg on their face. Remember the Spanish proverb en boca cerrada no entran moscas. Benwing2 (talk) 00:43, 30 May 2024 (UTC)

To be honest, TKW is starting to sound like how he thinks PB6 sounds. CitationsFreak (talk) 01:00, 30 May 2024 (UTC)

I walked away last August as a form of de-escalation/self-care. That doesn't mean the matter was ever resolved. Nothing will ever change if TKW gets to keep shutting down any scrutiny of his pattern of problematic admin conduct by insisting it's "harassment" or a "grudge." This isn't the first time he's leveraged this get-of-jail-free card. He made similar arguments I was acting out of a "personal grudge" and "harassing" him during last year's second desysop vote. I could point to instances of Equinox/TKW leaping to the other's defence in disputes. But Equinox's departure probably makes that point moot from an enforcement angle. I do agree with the suggestions made in this thread that 1) another RfA should be required if Equinox wants his tools back, 2) Wiktionary needs an official user conduct policy, and 3) Wiktionary needs a formal dispute resolution process. WordyAndNerdy (talk) 01:24, 30 May 2024 (UTC)

@Benwing2 I don't disagree with you, but it doesn't address the larger issue that there is no way to properly resolve disputes on Wiktionary. Theknightwho (talk) 01:31, 30 May 2024 (UTC)

@Theknightwho That's not really a good enough response to what @Benwing2 said...you didn't admit any wrongdoing or room for improvement, instead trying to pawn off the issue on a lack of dispute resolution. You either DON'T seem to understand how to avoid escalation, or you don't care to. For example, when I expressed concern that you were targeting me, you could've stopped interacting with me and my edits for awhile. You literally did the exact opposite, digging deeper and deeper into my edits, knowing full well that I was unlikely to be happy about that. You instead could've waited awhile to dig into my edits, or let somebody else handle it. You need to remember that a) there is no deadline, and b) it's not necessary that any one edit make any one edit Purplebackpack89 01:44, 30 May 2024 (UTC)

Maybe the obvious answer is he just sucks up to you. And it surely worked. You showed up in disputes involving him, instinctly assuming he is right before any investigation. -- Huhu9001 (talk) 03:58, 30 May 2024 (UTC)

Apparently en.wikt has some structural problems within its administrative design. Sysop rights here are virtually unrestrained. Admins have little motivation to control theirselves or to confront their colleagues who share the same privilege. Victims of power abuses tend to leave, making desysop votes extremely difficult to succeed. And finally, someone who at least try to argue will soon be convicted of wikilawyering and made to shut up.

TKW is just another predictable result of en.wikt's failure to put admin rights in check. -- Huhu9001 (talk) 04:12, 30 May 2024 (UTC)

I don't know about "another" since they've been far more immature, abrasively hostile, and abusive of power than any other admin I've ever run into on a Wiki project but the other admins (a) obviously dislike me more and have no interest in my opinion on the matter and (b) presumably either see some good they accomplish that the rest of us don't and/or use them as a designated enforcer for 'troublemakers'. Hard to think of another reason they've ignored the apparently ongoing issues with the guy. — LlywelynII 10:10, 30 May 2024 (UTC)

Members of one social group usually have a preselected tendency to agree with each other unless there are strong reasons to not do so. Admins being "us", non-admins being "them" is enough to push them to downplay or justify abusing of sysop rights. What en.wikt displays here are typical symtoms of Internet forums with no restriction on its admins' behaviour.

I won't complain about those Internet forums because after all they can do whatever they want on their own private websites. But Wiktionary, which claims to be "the free dictionary", hmm. En.wiki is better in this aspect as it tried to design new policies or systems to alleviate this problem, while en.wikt just pretends everything is fine and TKW is the naughty boy everyone loves. -- Huhu9001 (talk) 00:40, 31 May 2024 (UTC)

@WordyAndNerdy: Hey, I've no stake in the "TKW stalking/harrassment" discussion (I mean, none of what Purple say looks like stalking or harrassment, but that's all I care to say), but for context some might not have access to, Equinox posted this sometime in 2022 on the Discord server:

anyway. basically i've realised that most editors are shit. so i thought, what if we create a group, for only GOOD editors? i am going to call it the Vanguard Party. PM me if you want in.

He did not follow that with anything, it was kinda out of nowhere, so I have no idea what that was about or whether anything really happened, but given that's all he said about a "Vanguard Party" there ever, I don't think there's anything to fear except for a potential furtive circlejerk. (If this reads like there is no cabal, it's not, I'm really not one to defend Equinox's bullshit. I don't think he'd want a cabal with me in it, anyway.) Hythonia (talk) 22:10, 28 May 2024 (UTC)

As an admin who has encountered unacceptable behavior on the part of other admins here and blocked for revdeled in the past, I have no problem blocking anyone for hate speech and have solicited that anyone who sees it, let me know. I also am not part of any cabal and am concerned about 1.) gross CHUDs ruining the Internet and 2.) encouraging marginalized populations to share free knowledge. —Justin (koavf)❤T☮C☺M☯ 22:34, 28 May 2024 (UTC)

It's a joke, clearly. Nicodene (talk) 05:55, 29 May 2024 (UTC)

Sure, my point was more so that even if it's not a joke, there's no need to ring the village bell in alarm. Hythonia (talk) 14:19, 29 May 2024 (UTC)

I probably would have called it a sandwich too. I didn't know it was controversial, but I'm grateful to learn that it is. I see we're having quite some difficulty defining hot dog. We've gone from sandwich to entree, back to sandwich, to snack, dish, and finally food item now! I must say I am thoroughly amused. Who knew American cuisine was so elusive. —Caoimhin ceallach (talk) 23:06, 27 May 2024 (UTC)

"Sandwich-style food item" could offer the best of both worlds. Includes "sandwich" early on in the definition for clarity. Remains agnostic on whether hot dogs qualify as sandwiches. WordyAndNerdy (talk) 23:57, 27 May 2024 (UTC)

Fwiw, Christ, no. (Standard) hot dogs have absolutely no relation to sandwiches or sandwich-adjacent food items whatsoever, except among linguists and intolerable middle schoolers who misunderstand reductio ad absurdum arguments against poor definitions of sandwich and treat it like a "fun fact" instead.

Anyway, to @Caoimhin ceallach, American cuisine isn't usually subtle about much and this isn't either. Hot dogs just happen to be a sui generis thing that falls into a lot of cracks. You can treat it as an main course (American "entree"), snack, or side dish depending on the setting and some people—particularly in the upper class—might never associate it with some of those (or, in the upper middle class, feel obliged pretend they never lived in a home where it was). Absolutely no one in the wild asks for a sandwich, gets a hot dog on a bun, and thinks the other person is sane and not trying to be obnoxious; but it is something that lexicographers needlessly struggle with because they don't want to take the time to define sandwich with all the cut-outs it actually has. — LlywelynII 10:33, 30 May 2024 (UTC)

Whether or not you consider a hot dog a sandwich, you have to withdraw from "hot dogs have absolutely no relation to sandwiches or sandwich-adjacent food items whatsoever". For starters, it fits our definition, to wit "dish or foodstuff where at least one piece, but typically two or more pieces, of bread serve(s) as the wrapper or container of some other food," perfectly. I am not expressing a view on the nature of a hot dog. I know it involves more than just coolly evaluating a definition. But what you said is absurd. —Caoimhin ceallach (talk) 10:54, 30 May 2024 (UTC)

My position is a hot dog is enough NOT a sandwich that we CAN'T use sandwich in a dic def. Purplebackpack89 12:16, 30 May 2024 (UTC)

• TKW is not hounding. But I'm happy to take on that role, and hound the hell out of Purple! Denazz (talk) 22:47, 27 May 2024 (UTC)

(I was going back and forth about whether to say anything, and find myself perhaps reassured to have been edit-conflicted by Benwing saying something somewhat similar.) I lament, not for the first time, that when disputes like this come up, it's usually two people who have each tended (in the specific case or in general) to behave suboptimally enough that it's hard to find consensus to take action to change anything, especially towards the more productive/powerful of the two. (Even in disputes involving me, like when I blocked Dan or AP295, it became clear in subsequent discussions that there are people who think I was misbehaving to do that.) Yes, TKW tends to think he's right and is combative (here's a less intense example from ~11 days ago). And as I remarked on Victar's talk page in a similar circumstance, (and as I see Benwing has observed above,) it does stand out just how many of the disputes like this that keep coming up TKW is part of. Yes, PBP's edits are often in need of being monitored and cleaned up (e.g. DONT TREAD ON ME). On a volunteer project, if no-one else is stepping up and saying 'I have time to monitor this', there does not seem to be appetite to tell the productive editor who is monitoring it (and doing myriad other useful things) to stop. (And some impatience when cleaning up edits from editors who keep making sub-par edits seems expectable; I myself lose patience sometimes, like here, where I undid an edit with a rude edit summary when I probably should, for formality's sake, have RFVed it.) There doesn't seem to be appetite for e.g. desysoping TKW (the votes on that had majorities opposed to desysoping). A temperament [TIL that word has an a and a whole extra syllable in it...] change also doesn't seem imminent. So I suspect we'll be having a discussion like this in another few months. I don't know what to do.
I do want to say, in my experience WAN and Mahagaja are both generally good editors (although I can't condone intentionally switching from a more specific to a less specific etymology template), and if they feel harassed (and I see why they do), I'm concerned. - -sche (discuss) 03:43, 30 May 2024 (UTC)

Yes, I agree with you 100% in everything you say, both about User:WordyAndNerdy and User:Mahagaja being good editors and more generally. It is somewhat heartening that both WAN and TKW are wanting a more formal dispute resolution process; OTOH I don't want this process to work like it does on Wikipedia, where there seems to be a great deal of wikilawyering and formality, and as a result resolving disputes seems to take enormous energy on the part of all involved. That's why I am preaching voluntary de-escalation so that disputes don't come to a formal mediation process; but TKW's response to my last comment shows he doesn't really get it (yet, I hope). Benwing2 (talk) 03:54, 30 May 2024 (UTC)

@Benwing2 Sometimes we do need to go over things in more detail, particularly when it boils down to whether someone is actually telling the truth. I do understand what you’re saying, and I don’t really know what else you expected me to say if you want me to be more hands-off in this discussion. Theknightwho (talk) 12:45, 30 May 2024 (UTC)

"it boils down to whether someone is actually telling the truth."

Letting things get to the point where the a dispute is about behavior is the mistake. Disputants should always ignore behavior in discussion and focus on the actual substance of how the substantive dispute relates to building a better dictionary. Behavior becoming the topic is a clear indication of a problem. When this happens the wise courses of action include taking time off (leaving (for a time) the last word to the other party), explaining one's reasoning on the substance at length based on agreed principles and values, etc. The foolish, destructive courses of action include continuing any discussion that is solely about behavior. I really hope that we do not end up with a legalistic approach to this kind of dispute. DCDuring (talk) 16:20, 30 May 2024 (UTC)

None of the mentioned actions taken by TKW, in my opinion, qualify as harassment or necessitate dragging this to BP. There's nothing wrong with going through a users edits to fix mistakes you think they have made, even if you think doing so is excessive. Unless TKW was publicly shaming you for your mistakes and making posts making fun of you, I don't really see an issue. And since there has been no mention of TKW doing anything like that, I'm going to assume nothing like that occurred.

The only thing mentioned so far that I found genuinely concerning is the mentioned behavior of Equinox. I would support requiring a vote for adminship should he return. — SAMEER (؂・؄・؏) 06:31, 30 May 2024 (UTC)

Let it be recorded that I have absolutely no confidence in User:Theknightwho. DonnanZ (talk) 10:14, 15 June 2024 (UTC)

@Donnanz And I’ve got no confidence in you either :) Theknightwho (talk) 13:30, 15 June 2024 (UTC)

That doesn't surprise me. However, it is you who is being discussed here. DonnanZ (talk) 13:42, 15 June 2024 (UTC)

Also concerned about User:Denazz

Above, User:Denazz says "I'm happy to take on that role, and hound the hell out of Purple!" Also...

• expresses an intent to stalk/hound me
• Says Kiss! My! Ass! in an edit summary

How is this behavior OK? Purplebackpack89 23:57, 27 May 2024 (UTC)

User:Denazz is Wonderfool. Is there bad history between you two? Benwing2 (talk) 03:17, 28 May 2024 (UTC)

I think he's trolling. CitationsFreak (talk) 03:57, 28 May 2024 (UTC)

This is stupid. Ioaxxere (talk) 22:34, 28 May 2024 (UTC)

• Yeah, that was a dumb comment by Denazz, TBF. They were drunk-editing again. WF needs to improve their diplomacy Denazz (talk) 07:11, 30 May 2024 (UTC)

• Also this... Purplebackpack89 12:09, 30 May 2024 (UTC)

  That is not harassment. Vininn126 (talk) 12:15, 30 May 2024 (UTC)

Adding etymology trees to English entries

Per the results of Wiktionary:Votes/2024-04/Allowing etymology trees on entries, I would like to apply these trees onto English entries for which the etymology tree has a depth of at least 3 (i.e., A -> B -> C) and a size (total number of terms) of at least 4. Ideally, as much as possible of this should be automated (probably necessitating help from @Benwing2, JeffDoozan). What do we think? Ioaxxere (talk) 19:39, 27 May 2024 (UTC)

Nowhere in that vote did it propose automation. Hard no support from me on that. -- Sokkjō 21:24, 28 May 2024 (UTC)

@Ioaxxere I think it's too early to automate roll-out, as there's still the chance of issues cropping up once we start using it more widely. Theknightwho (talk) 11:22, 29 May 2024 (UTC)

I'd say go ahead, but take it easy, so no automation. —Caoimhin ceallach (talk) 11:28, 29 May 2024 (UTC)

Perhaps we can come back to this in a month or two once it's on more pages - I think we should test it on some high-traffic pages to see how readers react, and also we should try it manually on a few pages to see if there are any other bugs to work out. Once that's done, I think we can raise the idea of automating it again. Vininn126 (talk) 11:31, 29 May 2024 (UTC)

@Vininn126: Will do. Ioaxxere (talk) 22:11, 29 May 2024 (UTC)

see you later, baked potato

Guys! I joined in 2008 and I will finally disappear in 2024. It is time eh. I'll try to avoid any secret IP address edits. I will fully fuck off. And no grudges or bad feeling. I made a lot of great entries, I argued with a lot of people, but I don't hate anyone. I'm just not a "team worker". lol. In real life I am a self-employed computer programmer and I have a terrible attitude but on the other hand I really like speaking with users and learning what they want, and implementing it. I can be nice.

Remember the purpose of the wiki, it's about the created, not the creator. Whatever I wrote (whatever you write) will be fixed, improved, massaged, and fed into the AI that will control our hearts and livers some day. Anyway: been a pleasure. And I'm not dead or anything, you can always dig me up in some awful 8-bit retro computing hole. But I think 16 years was enough. I will no longer read an Italian restaurant menu like "IS THAT AN ENGLISH WORD THOUGH".

I've shifted or deleted most of my user page stuff. I have (of course) a lot of other materials, and dictionary-derived things, on my hard disk (wait! it's an SSD! that's not technically a hard disk -- okay okay I grew up with those blue 3.5" floppies), that may be of interest. I will stick 'em somewhere eventually -- probably not here because of "grey" (cough black) copyright areas etc. When I have cleaned up that data I will send it to User:Lingo Bingo Dingo @Lingo Bingo Dingo, yes you lucky girl. Someone I could trust.

Been a pleasure and genuinely think I have liked you all, even the ones I fought with regularly. Special kisses to WF. Bye. Equinox ◑ 23:04, 27 May 2024 (UTC)

You've made a large number of helpful edits and those will always be appreciated. I hope it's all onwards and upwards for you. Let me know if there's anything I can do to help you exit. Should your admin rights be removed ASAP or should we wait until x weeks have passed? —Justin (koavf)❤T☮C☺M☯ 23:09, 27 May 2024 (UTC)

I totally forgot. Please revoke 'em immediately! And thanks for your kind comments. Equinox ◑ 23:10, 27 May 2024 (UTC)

Just to make sure this isn't missed, our bureaucrats are Benwing, Chuck Entz, EncycloPetey, Hippietrail, Paul G, Ruakh, SemperBlotto, and Surjection. No need to ping just yet (or spam mass-ping), but I'll contact someone if none of them manages to see this. Again, thanks to you, E. Be good and be well. —Justin (koavf)❤T☮C☺M☯ 23:14, 27 May 2024 (UTC)

All the best! — Sgconlaw (talk) 23:16, 27 May 2024 (UTC)

I have revoked User:Equinox's admin rights per user request, without prejudice. Benwing2 (talk) 05:40, 28 May 2024 (UTC)

@Equinox All the best, and drop me an email or something so we can meet up in real life again at some point. Theknightwho (talk) 23:18, 27 May 2024 (UTC)

o7. lattermint (talk) 23:52, 27 May 2024 (UTC)

Enjoy TheGoodStuff.zip [34] This is most of what I have been working on, for the past months and years. Do me proud, Wiktionarians! Equinox ◑ 23:53, 27 May 2024 (UTC)

Hmmm. Not sure how I feel about the password protected files in "information about Wiktionary's so-called Vanguard Party.zip", but I guess they are there and in that way for a reason, whatever it may be. Regardless, farewell and hope you remember to take care. —The Editor's Apprentice (talk) 11:09, 28 May 2024 (UTC)

For the record, since the above link is set to expire in four days and the Wayback Machine is unable to get past the "one time" warning and archive the file, I've opted to retain a copy. If anyone now or a later reader would like a copy, please leave me a message on my my talk page or shoot me an email. Either way, I will find a way to get the file to you. Take care. —The Editor's Apprentice (talk) 22:22, 30 May 2024 (UTC)

choosing to seethe about trans people as a swansong is bretty funny desu —Fish bowl (talk) 03:21, 28 May 2024 (UTC)

Farewell, legend. You will be missed. — justin(r)leung _{{ (t...) | c=› }} 05:47, 28 May 2024 (UTC)

In a while, crocodile. Nicodene (talk) 06:29, 28 May 2024 (UTC)

Best of luck, we'll truly miss you! Thadh (talk) 06:33, 28 May 2024 (UTC)

Bis später, alligator. — Mnemosientje (t · c) 07:45, 28 May 2024 (UTC)

I will no longer read an Italian restaurant menu like "IS THAT AN ENGLISH WORD THOUGH".

Was that your trigger for introspection? :-) anyways, I wish you good luck in all endeavors, including analyzing the emotions of football supporters. ;) Shoshin000 (talk) 07:57, 28 May 2024 (UTC)

The dictionary wouldn't nearly be what it is today without your work. Thank you Vininn126 (talk) 08:14, 28 May 2024 (UTC)

Thank you for your service! Allahverdi Verdizade (talk) 09:15, 28 May 2024 (UTC)

i will miss you as well. it's a volunteer project, so it can be a lot of fun one day and an aggravating chore the next, so i hope to see you back someday, but i understand if you decide to burn this bridge. best wishes, —Soap— 10:14, 28 May 2024 (UTC)

Goodbye Equinox! I thought you would one day achieve one million edits. Maybe Wonderfool is up for the task... Ioaxxere (talk) 13:03, 28 May 2024 (UTC)

Paul, even though you often cockblocked me from adding jokes to Wiktionary mainspace, I will miss you. Vahag (talk) 13:41, 28 May 2024 (UTC)

See you in the funny papers. o7 Binarystep (talk) 15:47, 28 May 2024 (UTC)

Sorry to see you go, Equinox. I'll miss having you around! Now who's going to add entries for all the missing words I've collected! Am I going to have to do it myself?? Andrew Sheedy (talk) 17:26, 28 May 2024 (UTC)

You and your valuable contributions will be missed.. you touched the hearts of many editors, and every article I ever created. o7 LunaEatsTuna (talk) 22:52, 28 May 2024 (UTC)

Best of luck in whatever you'll be up to from now on :) I must say, your leaving's left me feeling a big loss, even though I've rarely (or never) talked to you, because I know how much your absence will be felt now that your crazy work ethic isn't with us anymore! I must say I took that you'd be here forever for granted. Have another wonderful 16 years... even better if you do get hooked again and come back. :) Kiril kovachev (talk・contribs) 20:20, 29 May 2024 (UTC)

You've obviously made a lot of valuable contributions to Wikipedia...BUT...I am very concerned about the file you dropped on your way out... — This unsigned comment was added by Purplebackpack89 (talk • contribs) at 16:34, 29 May 2024 (UTC).

Farewell, Equi, thanks for your massive contributions and enjoy your new "free" time. We shall miss our MVP (guess which sense is meant, HUH?!). ←₰-→ Lingo ^Bingo _Dingo (talk) 21:41, 30 May 2024 (UTC)

I’m much saddened to see you go. You are the god of Wiktionary, and it’s been an honour to have interacted with you. Your contributions have inspired hundreds or thousands of editors to work tirelessly and ceaselessly. Given the astoundingly gigantic work you have accomplished, I will probably keep imagining that you would continue editing here for 16 decades more, haha. You are immortalized in the best lexicographical project on earth by dint of the greatest number of edits published on en.wikt by an individual (namely yourself). Fare you well. Happy retirement beloved Captain Eq.

P.S. Will make sure, when I am more active in future, to follow your example & edit/research 12 hours a day & sleep for the remaining duration! Inqilābī 14:08, 31 May 2024 (UTC)

I've been avoiding commenting because, given what you chose to do right before you left, it seems ill-advised to admit I'm sad to see you go. Based on a few comments you made at different times, I got the sense that you thought I didn't like you?, but in fact (as I tried to convey by thanking you for various helpful edits and joking with you about your post about the police helicopters and such), while we disagreed on some things, and I can't condone the times you strayed into unacceptable conduct towards others (which you did need to be reprimanded for), I appreciated and appreciate your many contributions to the dictionary. I want to say that, because I did also block you on 2. June (for 1 minute, because you already left so I didn't feel the need to work out what longer length would actually be proportionate) to put in the record—because recent BP discussions have shown that it needs to be made clear—that the conduct I referred to in my block summary was/is unacceptable for an editor and unbecoming of an admin. I hope you enjoy your wikiretirement, and if you ever return, I hope it's to do what you mostly did, and what we should all aspire to mostly (or even exclusively, if we're aspiring!) do, make copious useful contributions to Wiktionary's coverage of languages. :) - -sche (discuss) 01:55, 4 June 2024 (UTC)

Crikey, just saw this. You and I didn't cross paths all that much, but I've appreciated your attention to detail and passion for the project. Good luck in your further endeavors, and may they be at least as rewarding as bashing words together here! ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:14, 6 June 2024 (UTC)

How strange! We did meet a few years ago in Oxford. DonnanZ (talk) 23:33, 12 June 2024 (UTC)

Wonderfool leaving too

To start a new, better life. Denazz (talk) 23:23, 27 May 2024 (UTC)

Not exactly beating the "Equinox's secret identity" allegations... Binarystep (talk) 04:30, 28 May 2024 (UTC)

They’re retiring together to a life of marital bliss in a lovely old cottage in the Midlands. Nicodene (talk) 21:47, 28 May 2024 (UTC)

A new life without the kid? Vininn126 (talk) 08:14, 28 May 2024 (UTC)

You've been back before, so maybe this isn't goodbye—anyway, all the best to you as well! — Sgconlaw (talk) 17:37, 28 May 2024 (UTC)

I don't believe Denazz ever left, judging by the contributions at least :) Kiril kovachev (talk・contribs) 20:42, 29 May 2024 (UTC)

@Kirik kovachev: ha ha … — Sgconlaw (talk) 12:25, 31 May 2024 (UTC)

change the default caption of Template:audio to be "Audio"

The majority of uses of {{audio}} include an explicit caption that reads "Audio" or similar. I propose to make "Audio" the default caption and add support for accent qualifiers (à la {{a}}) so you can write e.g. {{audio|en|File.ogg|a=US}} to get a caption reading "Audio (US)" with appropriately linked "US". Benwing2 (talk) 23:16, 28 May 2024 (UTC)

No objection, provided there’s a way to override the default where required. — Sgconlaw (talk) 23:41, 28 May 2024 (UTC)

Yes, this is just the default. The caption param will still work (and I can support the use of - for no caption if there is demand for this, although IMO there should never be a missing caption). Benwing2 (talk) 23:42, 28 May 2024 (UTC)

Thanks. Actually I was wondering if there’s a way to use this template within {{WOTD}} so that a caption can be added in some manner, and perhaps even multiple audio files used. At present I recall that using {{audio}} within {{WOTD}} causes errors (though I haven’t checked). — Sgconlaw (talk) 23:48, 28 May 2024 (UTC)

Yeah this template is crying out to be revamped. Not sure what the issue is with {{WOTD}}. Benwing2 (talk) 00:44, 29 May 2024 (UTC)

Support, though I think there should be a colon for consistency with the other pronunciation templates. Binarystep (talk) 03:52, 29 May 2024 (UTC)

Support Ioaxxere (talk) 22:11, 29 May 2024 (UTC)

Ok, I have implemented this and revamped {{audio}}. There are now several new parameters to support accent and regular qualifiers, specifying the text of the snippet, specifying the IPA of the snippet, etc. The third param defaults to Audio and IMO should rarely be changed; use one of the new parameters to specify additional information. I will be cleaning up existing uses of |3= in a day or so (there are around 800,000 pages that transclude {{audio}}, of which about 600,000 actually call {{audio}} directly, so it takes about 35 hours just to download all the uses for offline cleanup). Benwing2 (talk) 06:45, 31 May 2024 (UTC)

Symbol of le day?

Let me cook for a second. I am very biased because I absolutely love semiotics, specifically symbols like pictograms, emoji, road signage etc., but I reckon a Symbol of the Day (or similar) could be pretty interesting.

Wiktionary has over 43,815 translingual symbols and slightly more when we include symbols from other languages (most symbols are translingual), unfortunately none of which are eligible for Word of the Day (or the Foreign Word of the Day) because they both exclude symbols from being featured, citing that they "cause problems for readers who lack the required fonts". I think this applies mostly to emoji, which have different designs (that subsequently influence their meanings) on every platform/operating system. And, while there are indeed less supported symbols, Foreign Word of the Day has nevertheless featured language using scripts that are not supported on a number of devices, like Gothic, Nastaliq, cuneiform and Aghwan (which appears as boxes on my phone). Regardless, the solution to this, while unfortunate, is to just exclude emoji and the more unsupported symbols altogether (which usually, albeit not always, tend to be rarer anyways); or to use images if necessary. We already appear to do this for Egyptian hieroglyphs instead of using their Unicode equivalents, so it is possible.

But the reason I would like them featured is because symbols are awesome and I think that including symbols would certainly add value and probably intrigue a few of our readers.. symbols include stuff like pictograms, emoji, emoji combinations, ideograms, icons, emoticons, letters and punctuation (when considered in isolation) and general symbols concerning astronomy, mathematics, currency, musical notation, computing, electronics, alchemy, packaging etc. I know there are quite a lot of people who really like symbols like the infinity symbol ∞, pi π or the heart ♥, and stuff like the tick ✓, smiley :) and pointing hand ☞ are near-universal and have a lot of cool senses. There is also etymological value: not many readers will know know the universal recycling symbol ♻ was created in 1970 for a competition, or that the power button ⏻ is (possibly) a combination of the universal on ⏽ and off ⭘ buttons. There is also punctuation that is pretty interesting, like ; or ⸻ which is funnily long and has three interesting senses.

The only downside I can think of having this (which is a valid concern) would be creating unnecessary whitespace on the main page, especially if this was to be added below Foreign Word of the Day. Anyways, what are y'alls thoughts on this? I will not pursue this further if there exists no enthusiasm for it, BTW, hence why I am asking for opinions here before attempting to formally propose anything. :3 LunaEatsTuna (talk) 23:36, 28 May 2024 (UTC)

Support. Binarystep (talk) 03:53, 29 May 2024 (UTC)

It’s okay. They specifically exist for marketing. The attention emojis atract cross-finances underprivileged script encoding.

We can also make an occasional expansion of our English and Foreign Words of the Day by a Symbol of the Day, say every Sunday; you won’t like the routine of an actually daily featured symbol. Fay Freak (talk) 04:08, 29 May 2024 (UTC)

Support Ioaxxere (talk) 22:11, 29 May 2024 (UTC)

Maybe a weekly symbol? I'm not overly enthused about a daily symbol. We can always do it more frequently later on if there's sufficient interest. Andrew Sheedy (talk) 16:35, 31 May 2024 (UTC)

That sounds reasonable enough! Fay Freak suggested this as well. I am happy to hear that there is support for this nonetheless :) LunaEatsTuna (talk) 23:44, 1 June 2024 (UTC)

Out-of-process deletions of rfv-quote

I'm broadcasting this as I don't know the capabilities and cliques of the administrators. Could someone please stop the out-of-process deletions of the {{rfv-quote}} notice at Sanskrit अमृत (amṛta). --RichardW57m (talk) 14:26, 30 May 2024 (UTC)

Richard, to begin with, your RFV tag was not valid. But I assumed good faith on your part, preferring to believe you were merely mistaken, in the way of the honest mistakes that everyone often makes. I tried explaining the matter to you; I and @Svartava took time to even show you evidence that the way of writing that you are calling illegitimate really exists. And you have flippantly ignored our points and have obstinately continued to stall this discussion through convulated reasoning. Were I to extend the same courtesy to you that you extended to us, I should have disregarded your concerns and blocked you from editing that page. Now, having dealt with you in the past, I know that trying to reason with you is futile as I know you will do anything but concede. Why are you decrying a mythical "clique" of administrators here at the Beer Parlor? Are you trying to mislead people who are not involved in this issue and have no knowledge of the subject matter? You are being disruptive at this point. -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 14:51, 30 May 2024 (UTC)

This is going too far than it should have. Please stop dragging this @RichardW57m, it is leading us nowhere since you fail to be convinced even after irrefutable proofs shown to you in the discussions already. Let's not argue in vain and rather go back to contributing. Svartava (talk) 15:09, 30 May 2024 (UTC)

Inflections of PIE terms

Inflections of PIE terms seem to be created inconsistently. For example, Proto-Indo-European *h₁me (accusative of *éǵh₂) is a redlink whereas *n̥smé (accusative of *wéy) has its own entry. Some inflections can also be redirects, such as *íh₂. I think for consistency there should be a system for determining which entries should exist. Here are a few options:

• Option 1: Always create the entry.
• Option 2: Either create the entry or redirect, depending on how many attested descendants there are (not sure what a good number is).
• Option 3: Always redirect.
• Option 4: No inflection entries at all.

Pinging @Saph668. Ioaxxere (talk) 15:11, 30 May 2024 (UTC)

Technically, is it possible to put the etymon template on a redirect page to continue the tree? If so, I say option 2. I also think that we should handle cases and gender differently. -saph 🍏 15:45, 30 May 2024 (UTC)

@Saph668: Putting templates on a redirect page is (for lack of a better word) cursed. But I think it is technically possible. Ioaxxere (talk) 15:50, 30 May 2024 (UTC)

We can keep the tree from displaying by keeping |tree= blank, right? Or is it just that templates generally don't go on redirects? -saph 🍏 16:15, 30 May 2024 (UTC)

@Saph668: It's just that redirects are not meant to have any content. Because as soon as you add content, it might as well just be a proper entry, right? Ioaxxere (talk) 16:30, 30 May 2024 (UTC)

Then let's do full entries for gendered inflections (with etymon templates) and redirects for case inflections (with etymon template on the lemma). For the latter, I think you can choose to override the display text of the hyperlink to show the inflected form. -saph 🍏 17:02, 30 May 2024 (UTC)

I'm not sure I agree that consistency is the most important priority. In the case of suppletive paradigms, like the examples you gave, it seems more reasonable to have an entry than when the only difference is an inflectional suffix.--Urszag (talk) 22:57, 21 June 2024 (UTC)

All of those options are bad and I assume it's because of more {{etymon}} silliness.
The most important thing is accuracy and the maintenance there of, and creating more fail points isn't a good idea, but in the end, it should me left to case-by-case. They should never be redirects though. --{{victar|talk}} 23:16, 21 June 2024 (UTC)

Middle Chinese links in etymologies.

There are many Japanese entries with Middle Chinese links in their etymology sections. One example is 獅子#Japanese. It says "From Middle Chinese 獅子." but 獅子 was linked to [[獅子#Middle_Chinese]]. We never have any Middle Chinese entries in our dictionary. Should we just link all Middle Chinese words to Chinese entries? 列维劳德 (talk) 14:43, 31 May 2024 (UTC)

We do have Middle Chinese, but everything Sinitic is grouped under the "Chinese" header. This is a special case, so causes problems with link targets. It shouldn't be too hard to solve. Theknightwho (talk) 15:44, 31 May 2024 (UTC)

TBH in this case the MC term should be linked to with {{ltc-l}} which would correctly link to the #Chinese section. lattermint (talk) 16:59, 31 May 2024 (UTC)

@Lattermint It would be good to do away with language-specific link templates if we can, because they cause problems when they need to be used in places like etymologies instead of the proper templates. Theknightwho (talk) 20:26, 31 May 2024 (UTC)

@Lattermint @Theknightwho Agreed. It seems it should be easy to implement this by adding a language-specific flag redirect_links or something that specifies a lang code that links to that language are redirected to. Benwing2 (talk) 08:25, 6 June 2024 (UTC)

The actual wikicode at 獅子#Japanese was this:

• {{der|ja|ltc|獅子|lit=lion + (diminutive suffix)|sort=しし|tr=ʃˠiɪ t͡sɨX}}

To resolve the linking issue, I'm changing that now to:

• {{der|ja|ltc|-}} {{ltc-l|獅子|lit=lion + (diminutive suffix)}}

If you all could update {{der}} and {{inh}} to obviate the need for such workarounds (so {{der|ja|ltc|TERM}} links to [[TERM#Chinese]] as appropriate), that would certainly be helpful. ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:11, 6 June 2024 (UTC)

I think what is needed here is for the automatic MC transliteration in regular templates ({{m}}/{{der}}/{{cog}} and so on, not sure what the exact module responsible for that is) to be able to replicate the exact behavior of {{ltc-l}} which first and foremost includes using the Baxter transcription, as right now the automatic transcription is not reconstruction-agnostic and uses the Zhengzhang Shangfang reconstruction by default, which is the first reconstruction listed in the MC sections in Chinese entries, as seen here. Another thing is that right now the transcription is only going to be shown if it is present on the Chinese entry in question (i.e. enabled with |mc=y), regardless of the existence of ltc-pron module data for the individual characters. Plus there is currently no way to specify different rime readings using |id= with anything other than {{ltc-l}}. lattermint (talk) 20:46, 6 June 2024 (UTC)