Wiktionary:Beer parlour/2024/May

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@-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)[reply]

@-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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

@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)[reply]

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

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

Plurals on head lines and declension tables

Is there any point in having both plurals on the head line and a declension table 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)[reply]