I would like to request adding a languliage code for Baltic German on this platform. A lot of Estonian terms (and Latvian terms) are derived from Baltic German and there's currently no real way of displaying that, other than Baltic {{der|et|de|<term>}}, which not only looks ugly, but is also wrong. It categorizes the term to [[CAT:Estonian terms derived from German]], which is incorrect, as there is a clear distinction (at least in Estonian) between terms derived from (High) German and the Baltic German dialect spoken here. As such, the code could also be etymology-only. In essence, the Baltic German dialect is a vernacular dialectal form of a mixture of High and Low German with a clearly recognisable regional flavour (Estonian and Latvian dialects) in pronunciation, morphology, syntax and vocabulary. EKI (Institute of the Estonian Language) has an online dictionary of Baltic German, with a myriad of sources for various terms: https://arhiiv.eki.ee/dict/bss/. I feel like having a language code for Baltic German is justified. Joonas07 (talk) 19:31, 1 August 2024 (UTC)[reply]
My comprehension of German is pretty rudimentary, but from my understanding, there is a distinction with Baltic German and central European German varieties, so I agree that this is justified. Joonas, do you know to what extent this is also true for Latvian or even Lithuanian? Danke. —Justin (koavf)❤T☮C☺M☯19:37, 1 August 2024 (UTC)[reply]
Lithuanian barely has any influences from Baltic German, if at all. Are you asking whether this distinction exists the same way in Latvian? I'm not extremely familiar with Latvian, but I believe both of these languages have been influenced the same way by Baltic German, as the history is the same. A quick look at [[Category:Latvian terms derived from German]] as well makes me believe that is the case. Joonas07 (talk) 20:21, 1 August 2024 (UTC)[reply]
vernacular dialectal form of a mixture of High and Low German with a clearly recognisable regional flavour – this is fiction. It is either Standard High German with Baltic characteristics in vocabulary (e.g. Burkane, but admittedly they suffice for whole dictionaries which maintain borrowings from Low German and the local Baltic language) or it is Low German, with Baltic-influenced accent. I also speak German with Slavic twang due to speaking Russian, doesn’t mean I have created a new dialect or creole. Most commonly it is High German like “Austrian German” is High German, or just German. w:de:Baltisches Deutsch knows that even around 1600 High German “setzte sich durch” prevailed over Middle Low German – which seems exaggerated to me, but perhaps only by half a century, and Middle Low German ends in 1650 precisely at the point of being supplanted by High German for cultivated and literary purposes –, and then around the first half of the 19th century the academic upper class was oriented towards “a trim Standard German”. But Baltic Germans were only upper class, so there is no third language for even diglossia to fit in.
Baltic German should be no more than a label of German and occasionally Low German for any traces of it remaining, a distinction between (High) German and the Baltic German dialect spoken [in Estonia, Latvia, in St. Petersburg or the Baltics in general] is incorrect, it was not present for speakers. It was like Euro-English in Brussels: behind it in Brussels there is Flemish and French, and in Reval now Tallin and Dorpat now Tartu Estonian and on another level Russian. Fay Freak (talk) 20:35, 1 August 2024 (UTC)[reply]
I would argue the Baltic German varieties developed enough from their High or Low German origins to warrant an etymology-only code. There is a noticable difference between you speaking German in a Russian accent, and German settlers in Estonia and Latvia speaking a variety of their language for hundreds of years. I definitely disagree that the distinction wasn't present for the speakers. Besides, that isn't even that important, as the distinction is present in target languages. Joonas07 (talk) 20:55, 1 August 2024 (UTC)[reply]
German settlers … variety of their language There you have it, their language of the mainland.
The distinction is not present in the remaining sources either. It must be in use and not merely by declaration in target languages. Its texts look like Standard German texts with peculiar words we of course seek. E.g. the sentences quoted in Wörterschatz der deutschen Sprache Livlands – there aren’t actual dialect dictionaries. And all quoted on w:de:Baltisches Deutsch.
Of course only a single word suffices for a Baltic Germans speech to be marked and ridiculized further west, which they themselves did not expect, since they only knew one German, Standard German, not a diglossic situation of local Standard German plus dialect as is now known from Switzerland and Arabic countries, hence the quoted Harry Siegmund from Liepāja writes about his stay in Königsberg, because of the sensitive nationalist climate in Germany: “Ich schwieg auch, weil ich fürchtete, mit meiner baltischen Sprechweise als Fremder aufzufallen und ihnen in jeder Hinsicht unterlegen zu sein.” – “I was silent for fear of raising attention as a foreigner due to my Baltic mode of speech and be outgunned in every way.” It was a mode of speech. This is the situation in its last 150–250 years. Going further back, the variance is within the standard variance of all Early New High German and Middle Low German. For a 16th-century text it is highly problematic to e.g. claim it specifically Swabian or Category:Alemannic German language instead of Early New High German, which was just developing as a standard. And then in the Baltics you don’t even have a solid basis of untarnished dialect speakers because the peasants spoke Estonian and Latvian, and “German” were those who worked in administration and churches and their language—occasionally also a Russian, an Englishman, or a Swede, your target language sources may generalize it—, quite different also e.g. from the Volga German situation, which were homogenous German societies with little if any Russian or Turkic etc. encroachment until Sovietization.
This also does not mean though we can’t have “Baltic German” as an etymology-only language. As I implied with the Austrian German we can have a code, I probably would have added it myself if I had cared enough about the variety. For your purposes you should know it is still German however. Reminds me a bit of the pendants amongst Hungarian editors who liked to be sure whether a Hungarian word is borrowed “from German”, “from Austrian German” or “from Bavarian”. Linguistic works vary in the declaration. There is no actual idea behind such questions. Fay Freak (talk) 22:28, 1 August 2024 (UTC)[reply]
Yeah, I didn't mean it in the sense that it has developed into a language of its own right, rather that the variety of Standard German that is Baltic German has developed far enough to be notable. Didn't quite understand what you're getting at in the second half of your third paragraph. Re: Hungarian, it doesn't hurt to be exact. I don't know what you mean by "there is no idea behind such questions". For Estonian, it is often significant whether a word was borrowed from German or Baltic German. Joonas07 (talk) 23:30, 1 August 2024 (UTC)[reply]
This significance I understand. It might be from the historical German there or it might have intruded into the standard from present Germany, or even its predecessor Reich. Similarly one judges whether a word entered Ethiosemitic from Egyptian Arabic or Yemenite or Ḥijāzi usage, but all under one Dachsprache. I feared that you tried to introduce a distinction that is impossible to make out, exaggerating diglossia. The Hungarian etymology statements are more fanciful than reliable in this respect. Fay Freak (talk) 23:52, 1 August 2024 (UTC)[reply]
I don't really know. de-bal maybe? ger-bal? The list you linked seems to indeed have various different formats (btw, I really enjoy the abbreviation WT:LOL): some are just three-letter codes, but I don't know if there's an intuitive one for Baltic German that's not already in use. Some start with gsw-, which I gather is for High German varieties? So there seems to be some conventions. I'm open to suggestions. Joonas07 (talk) 00:23, 2 August 2024 (UTC)[reply]
@Joonas07: I have added you the online dictionary of Baltic German as a reference template, {{R:de:BSS}}. Most of the dictionaries and whole sentences quoted from Baltic German therein are in Standard German. Schiller-Lübben is for Middle Low German. Fay Freak (talk) 23:04, 1 August 2024 (UTC)[reply]
Hello, I would like to request access to the AutoWikiBrowser tool. I have been contributing significantly by adding entries in Old Tupi and Guaraní, and I often need to correct some inaccuracies in the entries of these languages. Furthermore, the creation of Old Tupi entries only really started to take off last year; we are in a somewhat unstable phase where some quotation templates are occasionally renamed. For what it's worth, I already have access to AutoWikiBrowser on enwiki. Thank you, RodRabelo7 (talk) 04:48, 2 August 2024 (UTC)[reply]
This seems uncontroversial, based on edits such as this. I'm not familiar with the language, but your work seems reasonable to me. Please ping me if no one else grants access in a week. I'll try to check in on this thread to see if there are any other comments. —Justin (koavf)❤T☮C☺M☯04:53, 2 August 2024 (UTC)[reply]
Dear Wiktionary: If a word could be normatively be interpreted as either needing hyphenation or not needing hyphenation, and it is hyphenated by a row-splitting hyphenation, how do I take a verbatim quote of that sentence for a Wiktionary citation? This actually comes up A LOT for me, because formal Wade-Giles includes hyphenation, while informal Wade-Giles and postal romanization do not include hyphenation, so many words "could go either way". What I did in this case: diff on the Zichang page was make a context-based decision (i.e. this sentence did not fall out of a coconut tree; in the context of the book and the other usage of the word in a different entry of the dictionary, it appears that the authors might likely have intended that this hyphen is more than just a row-splitting hyphenation). But I also want to imagine what could be unburdened by what has been before (that is, the author may have intended non-hyphenation for this specific instance, even if the publisher did hyphenate for the row-split, and even if the same word was hyphenated elsewhere, and even if other similarly situated words in the book are hyphenated). Thanks for any guidance. Yours Truly, --Geographyinitiative (talk) 11:26, 2 August 2024 (UTC)(Modified)[reply]
I'm not sure how familiar you are with CSS and HTML, but have you by chance seen these web design solutions?
I think these kind of solutions will work for what you're going for, which may involve inserting raw HTML/CSS rather than a template or other wikitext. —Justin (koavf)❤T☮C☺M☯11:41, 2 August 2024 (UTC)[reply]
Thanks-- Okay, I'm looking at this, but does this coding allow me to signal to the reader that, within the context of the published book, there is an ambiguity as to whether the hyphen is merely a row-splitting hyphen or actually a part of the word proper (i.e. the hyphen would have been included if the word were not on the edge of a row)???--Geographyinitiative (talk) 11:47, 2 August 2024 (UTC)[reply]
If the surrounding context makes the intended usage clear (for example, if the same document has examples within a single line of the same word/proper noun spelled with or without a hyphen, or of analogously formed words or names) it seems fine to follow that. In cases where that can't be determined, I would say it should be considered whether these specific quotations are really essential.--Urszag (talk) 12:20, 2 August 2024 (UTC)[reply]
If it’s significant (for example, because a term has both hyphenated and non-hyphenated forms), I indicate this as “roly[-]poly” in a quotation. You can also use the template {{quote-gloss}}, which results in “roly[-]poly”. — Sgconlaw (talk) 15:26, 2 August 2024 (UTC)[reply]
As to Sgconlaw's comment, I am not sure if the hyphen is a gloss on the quote, and I don't want to misuse quote-gloss, though I see how this could be good. Concerning Urszag's comment (that I have usually agreed with) that "In cases where that can't be determined, I would say it should be considered whether these specific quotations are really essential." I have to admit that I have followed that line of thinking before. However, I have later come to feel that I really don't want to cause a bias in my citations by just blatantly ignoring a category of ambiguous situations in English. So I really want to embrace the citations as I come to them. There should be a normative way to deal with this category of scenario beside "fuck it". This is not a lowly or vulgar usage of English- this is a category of ambiguity that is baked into English, and I believe Wiktionary should have a way to confront the situation head-on and properly cite them as what they are. In the above quote the word "An-ting" is not the essential word, but instead the rare word "Tzu-ch'ang" which is super rare because it is a Wade-Giles name derived from a communist-only Chinese original (Taiwan did not use it), so Tzu-ch'ang is pretty rare, and the book is pretty authoritative. So I want to deal with "An-ting" in the "right" way that fully acknowledges the ambiguity rather than do my grab ass horseshit of writing something in the html. I came up with that shit ages ago as a work-around; now, I want to fucking do to beautifully and make it clear to the reader of the quote what the fuck is happening, and unambiguously tell the reader that there is a potential ambiguity. --Geographyinitiative (talk) 22:35, 2 August 2024 (UTC)[reply]
@Geographyinitiative, Sgconlaw: The purpose of {{quote-gloss}} is to contain text not present in the original text, so An{{quote-gloss|-}}ting would mean "there was no hyphen in the original, but there was supposed to be" — probably not your goal. The OED does something like this: An-ting [variant reading Anting]. Although I prefer something more explicit like this: An-ting [or Anting, if the hyphen is a line-breaking hyphen]Ioaxxere (talk) 01:53, 8 August 2024 (UTC)[reply]
Unless someone comes up with a better solution, I'm going to leave this quote (diff) as is. I'm going to eventually take this topic to Grease Pit to see if a real solution can be created for this kind of ambiguous situation. However, right now, for this quote, I don't think this quote is a good "model case" for the larger problem because I really feel that the context of the book itself more heavily favors the hyphenated form of "An-ting" than unhyphenated "Anting". But I'll keep this case in mind and come back to it later; please ping me if you have more help/input/advice on the topic generally. --Geographyinitiative (talk) 23:56, 2 August 2024 (UTC)[reply]
@Ioaxxere: I thought OED indicates variant readings when there are multiple versions of the same work, and some use one form of a term and some use another form. That’s how I interpreted it anyway. — Sgconlaw (talk) 11:21, 8 August 2024 (UTC)[reply]
I do agree that it would be nice to have a standardized solution. I've come across this issue more than once and it can be annoying when it's a rare word and I'm trying to figure out whether the hyphenated form is more common or not. Andrew Sheedy (talk) 05:00, 3 August 2024 (UTC)[reply]
Yeah guys, please keep me in mind if you come up with a good solution for this. I will keep Sgconlaw's use of quote-gloss in mind. But I really want to give readers of a quote the full picture on the quote and not either (a) ignore the potential ambiguity, (b) just opt not to use the quote, or (c) use the quote anyway without fully acknowledging potential ambiguity in some way that the reader can see without misusing quote-gloss (in my opinion) or using a work-around or similar, or relying on my personal assessment of what the author meant to pick one over the other. --Geographyinitiative (talk) 10:22, 3 August 2024 (UTC)[reply]
@This, that and the other Is that right? Is there a paper about this? I'd like to learn about the finesse behind when they use [-] and use it the same way they use it. It's very bizarre looking to me, so I want to be 100% clear what I'm doing if I follow that method- (1) EXACTLY what specific situations is it used in? (2) EXACTLY how is it formatted? (3) Do other dictionaries deal with this issue in a similar manner? (4) Is there any clear policy-level guidance on this issue anywhere in Wiktionary? If not, why not? Should it be created? --Geographyinitiative (talk) 11:02, 8 August 2024 (UTC)[reply]
I notice CAT:en:Waterfalls says it's for "names of specific waterfalls, not merely terms related to waterfalls, [nor] types of waterfalls." But even before I added to it, almost all its contents were related/type terms (and I could add more: byfall, catadupe, maybe spray bow, foambow, plunge pool, stickle, huck). I could solve this by changing "Waterfalls" to a "related-to" category; in this case, that wouldn't even cause other languages much hassle, as other languages barely use it. However... I think it is reasonable to have a category for specific Falls too, like we have for cities. But what could it be called? We use "CAT:en:NAME" for both set categories ("terms for seasons, not merely terms related to seasons. It may contain [...] types of seasons [or...] names of specific seasons"), related-to categories ("This is a "related-to" category. It should contain terms directly related to winter"), andname lists. In our schema, the category for terms related to waterfalls or which are types of waterfalls, and the category for names of specific waterfalls, should both be "CAT:en:Waterfalls" AFAICT. And because type isn't predictable from name, some people (reasonably!) think e.g. Category:en:Cities is named like a set category and put "capital city", eperopolis et al in it (and where else should these go?), while other people think it's named like a related-to category, or (yes) a name category... so, like many categories, its contents are a mix. A solution would be to specify the purpose in the name: ":en:set:Seasons", ":en:topic:Winter", ":en:names:Cities"... but this highlights another issue: does it make sense that :en:Winter can include wintery, but :en:Seasons says it shouldn't contain seasonal? Maybe not! (And is it unmaintainable, anyway? It seems like in practice the more fine-grained distinctions we assert, the less well people maintain them.) Should we merge "sets" into "related-to" categories, so "CAT:en:Seasons" could contain summerandseasonal? (In theory, set categories could just be ====Hyponyms==== sections of entries like [[season]], not needing to be categories at all.) - -sche(discuss)21:24, 3 August 2024 (UTC)[reply]
@-sche: I would be in favour of merging the two types of categories, as I don't really think the distinction is easy to maintain. Alternatively, if it is felt that in some cases it is appropriate to have a "name" category, maybe the default should be a related-to category (for example, "Category:Cities") and the "name" category should be a subcategory called "Category:Names of cities". — Sgconlaw (talk) 23:57, 7 August 2024 (UTC)[reply]
@-sche: I prefer a naming scheme that makes the purpose clear, so you might have "types of waterfalls", "waterfalls", and "particular waterfalls" for the three kinds of categories. Ioaxxere (talk) 01:36, 8 August 2024 (UTC)[reply]
@Ioaxxere: I don’t feel it’s necessary to distinguish between “Category:Waterfalls” and “Category:Types of waterfalls”. I’m somewhat concerned that if we have distinctions which are too fine we are just going to get editors dumping everything in “Category:Waterfalls”. — Sgconlaw (talk) 11:23, 8 August 2024 (UTC)[reply]
Proposal to allow hyphens in alt parameter of links in Derived terms, Related terms sections of proto-languages
Something I found neat in our PIE entries is the feature in WT:AINE allowing the splitting of reconstructed PIE terms by morpheme with hyphens in the alt parameter of links in Derived and Related terms. Not only does it allow more derivation transparency, but also you can square-bracket link the individual morphemes involved so less familiar visitors can be taken to the compositional morphemes to learn more about them.
I would like to amend WT:Reconstructed terms to allow this practice to be used on other proto-language pages, not just PIE (and not on non-proto-language entries).
Separating hyphens can be used in the displayed form of links in Derived terms and Related terms sections of proto-language pages to clarify the formation, as long as it is not used in the page name itself.
Strong support, have been doing this for non-proto reconstructions in, e.g., Prakrit and Ashokan Prakrit. It will be nice as a frequent reader of Proto-Indo-European entries as well, though I understand that this is obviously not always possible when there are factors like sandhi in play. Svartava (talk) 09:24, 4 August 2024 (UTC)[reply]
Please don't do this for lower-branched Uralic Proto-languages. I think this is not helpful for agglutinative languages overall.
Not sure I like it for PIE, either, but it is kind of a tradition in IE linguistics, so I guess. For languages where this isn't done in literature - not sure it's helpful. Thadh (talk) 09:51, 4 August 2024 (UTC)[reply]
As Thadh points out, this is something needs to be decided on a language-to-language basis. If Proto-North Caucasian feels this works best for them, godspeed. What I am opposed to is doing so on Proto-Italic and Proto-Celtic entries, as you have been doing. Those need to go to a vote, because the status quo is not to have hyphens. --{{victar|talk}}17:23, 4 August 2024 (UTC)[reply]
...which is why I posted here in the first place, to narrow down the boundaries of such a vote? — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 18:29, 4 August 2024 (UTC)[reply]
Another Latin "proper noun" question. Currently, there seems to be no standardization in how we format entries for Latin month names. Aprīlis(“April”) only has a capitalized entry, and is marked as an Adjective and Noun. Maius is marked as an Adjective and Proper noun; there is a stub at maius noting it is an Alternative letter-case form. On the other hand, iānuārius is used as the main entry (Adjective and Noun) while Iānuārius is marked as an Alternative letter-case form. Contributing further to the mess, Category:la:Months includes multiple variants of some names such as Jānuārius.
What should the main entries be, what POS should be used, and how much information should be included in the alternative case form entries? In English, the POS of months is treated as "Proper noun". Urszag (talk) 11:10, 4 August 2024 (UTC)[reply]
Do any Latin dictionaries indicate when something is a proper noun? (In English, one hurdle to consulting other dictionaries about whether some class of word is a common noun or proper noun has been that many lazily have just one 'noun' category into which everything goes.) I seem to recall the fact that Russian month names are listed as uncapitalized common nouns being the result of a discussion where Russian editors argued for that based on how Russian references/speakers treated them. Do you have a sense of whether modern editions of Latin texts usually capitalize month names, the way they usually capitalize personal and place names? Poking around Google Books, it looks to me like "modern" Latin texts (actually, everything that turns up, from texts written in Latin the 1500s and 1600s to recent editions of ancient Roman works) almost always capitalizes month names, which suggests the capitalized forms should be the main entries. - -sche(discuss)15:52, 4 August 2024 (UTC)[reply]
I'm not familiar with any Latin dictionary that indicates proper nouns. Typically they just mark nouns or proper nouns by providing the gender (m, f, n); DMLBS also makes some use of the label "sb." (substantive) for both nouns and proper nouns. In my experience, capitalization is the usual editorial convention.--Urszag (talk) 17:26, 4 August 2024 (UTC)[reply]
Since it seems (by capitalization) that Latin dictionaries treat months as capitalized proper nouns, I would argue we should do the same. Likewise the adjectives should be capitalized. Benwing2 (talk) 18:39, 4 August 2024 (UTC)[reply]
Capitalisation doesn't mark proper nouns: Several dictionaries also capitalise other adjectives like Homēricus(“Homeric”), Rōmānus(“Roman”) and common nouns like Rōmānusm(“Roman (person)”). As for months and spellings: It's also a matter of attestion. Is always both like Februārius and februārius attested? Likewise for months and POS: Is always both mēnsisFebruārius/februārius (or something like: Kalendae Februariae/februariae, Nonae Februariae/februariae, Idus Februariae/februariae) and simply Februārius/februāriusm attested? --16:18, 6 August 2024 (UTC)
I don't really understand the second part of this comment. Ancient texts don't use capitalization, so there is no relevant ancient attestation distinguishing the two. Pretty much every modern edition I've seen (or modern Latin works, such as "Lingua Latina Per Se Illustrata") follows the convention of capitalizing the names of Latin months. This isn't restricted to English editors either: you can see "Augustus" capitalized in French texts such as the Gaffiot dictionary. I did see some lowercase examples of Latin month names on Google Books (e.g. "mensis augustus") so they are also attested, but I'm confident that uppercase is currently the more usual convention.--Urszag (talk) 15:02, 7 August 2024 (UTC)[reply]
Another example of capitalization: "Datum Romae, apud S. Petrum, die XIX mensis Martii, in sollemnitate Sancti Ioseph, anno MMXVIII, Pontificatus Nostri sexto" in Pope Francis's Gaudete et exsultate (2018).--Urszag (talk) 15:25, 7 August 2024 (UTC)[reply]
I found an older discussion from when month names were moved to lowercase versions: Wiktionary:Tea_room/2015/June#Latin_month_names. It looks like EncycloPetey based this on (some edition of?) "Josip Lučić Spisi Dubrovačke Kancelarije, a series of legal documents in Latin from Ragusa in the late 13th century". I'm not convinced yet that the cited text is representative of medieval usage as a whole, or that medieval usage should be relevant compared to the typical usage of more recent centuries, but I wanted to link to that discussion for greater context. I have already started moving the names (back) to capitalized versions based on the input from -sche and Benwing2.--Urszag (talk) 15:38, 7 August 2024 (UTC)[reply]
The publication in question was the source of citations, used because it was the easiest at hand, and because the text had both capital and lowercase lettering. A search of other medieval records containing dates should be able to furnish additional citations, as long as the scribe wrote out month names rather than numbers. At the time of the earlier discussion, the Latin months were treated as adjectives because the available citations in both classical and medieval Latin demonstrated use as adjectives. Modern dictionaries and Modern Latin do use capitalized forms, but Augustus is not a good example, since it specifically derives from the name of a person. Capitalization of months like october and november would be stronger evidence for capitalization, but as I say, evidence at the time suggested the practice of capitalizing month words was a modern practice. --EncycloPetey (talk) 16:30, 7 August 2024 (UTC)[reply]
Thank you for the clarification; so this is a compilation which is being cited as showing multiple independent examples of medieval usage? I guess it seems to me that the first question to be resolved (before getting into the question of what typical medieval usage was) would be whether capitalization on Wiktionary should be based on modern capitalization practices (e.g. "Datum Romae, Laterani, die XV mensis Octobris, in memoria sanctae Teresiae a Iesu, anno MMXXIII, Pontificatus Nostri undecimo", Est utique fiducia/C'Est La Confiance, 2023) or on medieval capitalization practices. I think that in general, we follow modern practices for spelling Latin words in entry titles; e.g. the use of "ae" and "oe" rather than æ, ę, œ, although I guess it is often difficult to distinguish between Classical conventions and modern conventions.--Urszag (talk) 17:09, 7 August 2024 (UTC)[reply]
@Pulimaiyi, Kutchkutch, Svartava (feel free to ping others, no idea who is interested in this stuff these days): There are many terms that are only attested across several New Indo-Aryan languages but not at any earlier stages of Indo-Aryan. Sources like Turner's {{R:CDIAL}} reconstruct ancestral forms for such cognate sets, but due to phonological degradation (e.g. consonant cluster assimilation) the reconstructions can only go back to Proto-Middle Indo-Aryan rather than a language we clearly know how to deal with like Proto-Indo-Aryan or Proto-Sanskrit.
For the past couple years our strategy has been to call these reconstructions Proto-Ashokan Prakrit, which is a language we made up and not a label that is really used in any literature (0 hits on Google). We settled on Ashokan Prakrit since it is likely the ancestor of all New Indo-Aryan languages (including "Dardic") and we didn't have a later node that unifies NIA subfamilies, since e.g. we used to treat Prakrit and Apabhramsha as collections of languages.
Now that we have codes for unified Prakrit and unified Apabhramsha, I think we should move any Proto-Ashokan Prakrit terms without "Dardic" descendants (e.g. *𑀟𑀼𑀓𑁆𑀓𑀭(*ḍukkara, “pig”)) to Proto-Prakrit. Proto-Prakrit is a term used in scholarly literature on IA historical linguistics, including by Turner. Also, this way we are not overclaiming the age of the word.
One edge case to consider is that often, a term may be constrained to non-Dardic NIA but also happen to have a descendant in Kashmiri; an example is *𑀝𑁄𑀓𑁆𑀓(*ṭokka, “basket”)). Kashmiri is the "Dardic" IA language that is most in-contact with plains Indo-Aryan (particularly Punjabi). I think this should also be called Proto-Prakrit but we can debate this. Ideally, we reserve Proto-Ashokan Prakrit for any NIA terms with non-Kashmiri Dardic cognates. —AryamanA(मुझसे बात करें • योगदान)20:40, 4 August 2024 (UTC)[reply]
I agree. Some related followup Qs:
1. How do we want to handle cases like *dākka, which Turner reconstructs [1]here with both a long vowel and consonant cluster (which is generally considered invalid in Middle Indo-Aryan). It appears that Turner is reconstructing Old Indo-Aryan. In this case, do we want to say that the descendant is Sanskrit *डाक्क(ḍākka), Prakrit *𑀟𑀸𑀓𑁆𑀓(*ḍākka), Ashokan Prakrit *𑀟𑀸𑀓𑁆𑀓(*ḍākka), or Prakrit *𑀟𑀓𑁆𑀓(*ḍakka)?
2. Is Proto-Prakrit a separate language or just a shorthand for referring to reconstructed Prakrit? I haven't seen any Proto-Ashokan Prakrit language in Wiktionary, so I'm guessing what you're referring to is reconstructed Ashokan Prakrit, right? Dragonoid76 (talk) 18:57, 5 August 2024 (UTC)[reply]
One more question—what are the cases where it makes sense to reconstruct "Sanskrit", as opposed to "Proto-Prakrit" or "Proto-Ashokan Prakrit"? Can we make (or does it already exist?) a clear decision on these cases? For example:
Hindi कूँच(kū̃c) from Sanskrit *कुञ्च(kuñca), where कुञ्चिका(kuñcikā)is attested. It seems reasonable to reconstruct Sanskrit, rather than saying the NIA term is inherited from Ashokan Prakrit *𑀓𑀼𑀁𑀘(*kuṃca).
What about Sanskrit *चिष्ट(ciṣṭa) or *युट्(yuṭ)? What is the stance that we take here?
I also agree. For Dardic descendants, and also Pali descendants of Turner reconstructions, we might want a Proto-Middle Indo-Aryan but that ways the age of any word will obviously be implied more than what it would be if it was called "Proto-Prakrit". I'm also open for Sanskrit reconstructions which do seem better suited in some cases like *ध्वजदण्ड(dhvajadaṇḍa), *तिथिवार(tithivāra), etc. and this can be easily dealt with on a case-by-case basis (due to the low number of MIA editors) as to which reconstruction fits better. I would also like to point out that despite being less frequent, early MIA like Pali does show both a long vowel and consonant cluster and even some Prakrit words do that, so I don't think it would be very problematic to have Proto-Prakrit reconstructions having both a long vowel and consonant cluster. Svartava (talk) 04:55, 6 August 2024 (UTC)[reply]
@AryamanA: Hello! It's great to see you active again. As a matter of an incredible coincidence, @Svartava and I have been, for the past few weeks, discussing on Discord about having a Proto-Prakrit code. Having a Proto-Prakrit code is surely less problematic than taking Turner reconstructions (which were intended by Turner to be Sanskrit) and showing them as Ashokan Prakrit, a practice unique to Wiktionary. Moreover, in Ashokan reconstructions, we spell out the geminated stops (case in point: *𑀝𑁄𑀓𑁆𑀓(*ṭokka)) but we know that gemination was not reflected in spelling in the edicts of Ashoka. So we have to either change these reconstructions to Proto Prakrit or render them in the Latin script. Also, Ashokan needs to be set as the ancestor of Dardic (it's not, for now). @Dragonoid76: To address your queries: a long vowel followed by a geminated consonant cluster is uncommon, but not invalid in MIA, as cases like dātta definitely exist. As for Prakrit entries in the reconstruction namespace vs Proto-Prakrit as a separate code, I am of the opinion that since Prakrit has been merged, we might as well use Prakrit reconstructions. As for your next question of how to decide between Ashokan vs Pkt reconstruction vs Sanskrit, as Aryaman said, if it has non Kashmiri Dardic reflexes, it will be an Ashokan reconstruction. As of now, inc-ash is not set to be the ancestor of inc-dar-pro but that can be fixed. I believe it should be, because Shahbazgarhi Ashokan shows many features which can be said to be the ancestor of the corresponding features in Dardic. Deciding between Sanskrit and Ashokan can be much more challenging, given Ashokan contains sounds like /ṣ/, /ś/ and non simplified consonant clusters. So ciṣṭa might well be early MIA. One rule of thumb I'd use is, compounds where the components are discernable as Sanskrit words are Sanskrit, such as *bhaginī-putra -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪(𝘵𝘢𝘭𝘬)05:18, 6 August 2024 (UTC)[reply]
@AryamanA: Moving a few entries from reconstructed early MIA Ashokan Prakrit to reconstructed middle MIA Proto-Prakrit seems to be uncontroversial since that was the original proposal.
@Dragonoid76, Pulimaiyi: Regarding, Is Proto-Prakrit a separate language or just a shorthand for referring to reconstructed Prakrit?
I agree with
since Prakrit has been merged, we might as well use Prakrit reconstructions
rather creating a new code for Proto-Prakrit. This is because creating a new code for Proto-Prakrit would mean that we would have to decide whether it is an ancestor, descendant or contemporaneous with the merged Prakrit language. Furthermore, Prakrit reconstructions are usually one-off for special cases unlike protolanguages such as Proto-Indo-Iranian. Protolanguages such as Proto-Indo-Iranian are entirely reconstructed while Middle Indo-Aryan is a mixture of attested and reconstructed terms.
Would the script continue to be Brahmi? … we have to either change these reconstructions to Proto Prakrit or render them in the Latin script
When Proto-Indo-Aryan reconstructions were moved to Ashokan Prakrit reconstructions, it was a delight to see them in Brahmi script instead of Latin script. Then, Victar started this discussion WT:Beer_parlour/2021/March#Reconstructions_in_Latin_script
Victar: I'd like get a discussion going about adding a guideline to WT:PROTO that states that all reconstructions should be in Latin script. Most already are, but here's a list of the ones that buck that standard…Ashokan Prakrit … Sanskrit
Mahāgaja: Devanagari seems perfectly natural to me
Victar: If we're going by academia, reconstructions will always usually be in Latin script, which does also go for Sanskrit and Avestan. Seeing RC:Sanskrit/लुट्टति is rather weird to my eyes
Fay Freak’s comment
If a script … is continued to be used because being able to represent languages well … then use that …Devanagari and Cyrillic works very well … one can read and and write languages in it like natively, without understanding why there would be a different script … I like this dictionary because its aim of everything being in the script it should be written … knowledge is not by default in Latin script…Prakrit is always in native script—whether found by attestation or conjecture
I agree with Fay Freak’s comment. However, I also see what Victar meant. Academia in the English language will probably not consider Wiktionary’s reconstructions seriously if they are not in the Latin script.
It is not useful to reconstruct with the idiosyncracies of Ashokan Brahmi being applied, in comparative linguistics we care about the phonology not orthography.
If the idiosyncracies of Brahmi are not to be applied to reconstructed Brahmi, and if we care about the phonology not orthography, then that might suggest that the Latin script might be used for reconstructions if the Latin script better represents the phonology. However, it could be argued that even the Latin script has idiosyncrasies of its own.
Question 1: @Pulimaiyi, Svartava: If middle MIA reconstructions continue to be in Brahmi, would the anusvara be used for homorganic nasal consonants, or would they be written as the Brahmi equivalents of ङ् ञ् ण् न् म्? The middle MIA convention is to use the anusvara. RC:Ashokan Prakrit/𑀟𑀗𑁆𑀓 uses ङ्, while RC:Ashokan Prakrit/𑀫𑀡𑀺𑀕𑀁𑀞𑀺 uses the anusvara.
As for … how to decide between Ashokan vs Prakrit reconstruction vs Sanskrit, … if it has non Kashmiri Dardic reflexes, it will be an Ashokan reconstruction … given Ashokan contains sounds like /ṣ/, /ś/ and non simplified consonant clusters … ciṣṭa might well be early MIA
What this means is that there will reconstructions at three stages:
Question 2: @Pulimaiyi, Svartava: With such a scheme shouldn’t we use the ===Reconstruction notes==== section to explain why a particular stage was chosen for a reconstruction rather than another stage (in addition to other details)?
Pulimaiyi: Sanskrit reconstructions are very rare in wiktionary and are generally not favoured by wiktionary's convention … Sanskrit reconstructions are not favoured by wiktionary's convention because of the lack of reliable reconstruction sources to base it on.
We already have RC:Sanskrit/तिथिवार, which is why I even thought of creating this reconstruction. Or else, I'd have simply added {{inh|hi|sa||*ध्वजदण्ड}}, without linking it.
Many of the headwords, like so much of classical Sanskrit vocabulary, are in reality Middle Indo-Aryan clothed, for the convenience of presentation, in an earlier phonetic dress
Inqilābī: No idea, but it might be the case that Turner reconstructs both OIA and MIA terms.
At one point I was deciding whether RC:Sanskrit/तिथिवार should be moved to Ashokan Prakrit and then decided not to. If the ===Reconstruction notes==== section explicitly explains why that particular stage was chosen (in addition to other details), then that would clear up the confusion.
Turner posits that all forms of this root may have originated from *युट्ट which was a MIA replacement for युक्त
it seems that the justification for having RC:Sanskrit/युट् as Sanskrit rather than middle MIA is that we agreed not to have middle MIA roots at Talk:घोट#𑀖𑀼𑀝𑁆𑀝𑁆-_(ghuṭṭ-). However, early MIA CAT:Ashokan Prakrit roots are permissable according to the following statement in that discussion:
Ashokan Prakrit roots are tolerated because *we* consider the unattested terms in Turner's dictionary to be Ashokan Prakrit
One rule of thumb I'd use is, compounds where the components are discernable as Sanskrit words are Sanskrit, such as *bhaginī-putra
The components of RC:Ashokan Prakrit/𑀫𑀡𑀺𑀕𑀁𑀞𑀺 are discernable as Sanskrit, but I placed it in MIA rather than OIA (Sanskrit). *bhaginī-putra differs from RC:Ashokan Prakrit/𑀫𑀡𑀺𑀕𑀁𑀞𑀺 because it has the Kashmiri descendant K. bĕnathᵃr m..
The relationship between reconstructed MIA and Dardic languages has been discussed several times such as at
The existence of a Dardic cognate could suggest that this word existed in late Old Indo-Aryan/early MIA: this is precisely why initially a code for "Proto MIA" was proposed so that Pali and Dardic could be included; but that idea did not garner much support and we had to settle for Ashokan Prakrit instead, which albeit quite pervasive, unfortunately does not extend to Pali and Dardic.
Apparently there are more Dardic terms than just Kashmiri corresponding to CDIAL 4116 *gāḍḍa 'cart'
Kashmiri is the "Dardic" IA language that is most in-contact with plains Indo-Aryan (particularly Punjabi)
Although Kashmiri is the most spoken Dardic language, the other Dardic languages are also in contact with “plains Indo-Aryan”, which might explain گاڑے#Torwali. RC:Sanskrit/चिष्ट has the Shina descendant چٹھ#Shina. Also, CDIAL Introduction: derives the Khowar term ātΛpik from reconstructed MIA :
Khowar ātΛpik `to have high fever' must rest either upon a late MIA. *ātapp- (newly formed compound with ā from tappaï) or upon MIA. *āttapp- with analogical -tt- (after type ā-tt- < ā-tr-, etc.). The head-word ātapyatē under which the Khowar word appears is thus in reality a Middle Indo-Aryan word in Old Indo-Aryan form.
What is probably meant by “Punjabi” here is “Punjabic languages” such as Pahari-Potwari and Hindko in addition to the standardised Majhi Punjabi.
Urdu as a lingua franca is also in contact with Dardic languages to a significant extent.
Pashto is another lingua franca that is in contact with Dardic languages in Khyber-Pakhtunkhwa and Afghanistan. Although Pashto is an Iranian language, Pashto borrows from Urdu and Punjabic languages including Lahnda/Saraiki. Perhaps it is too much of a stretch for a Dardic language in Khyber-Pakhtunkhwa or Afghanistan to have a “plains Indo-Aryan” term through Pashto. For example,
We have basically zero standards on the level of detail one should put in an etymology section, some will only list the direct ancestor regardless on if it's derived from another language or not (DeJulio, others will list the ancestors of a word all the way to say, Latin(like dictionary or this Malay term for June), and then others still will go all the way back to PIE or similar. that's not getting into entries like admiral, orange or pizza that start to look run on paragraphs with stuff like cognates and miscellaneous etymological detail.
I do recognize a pattern of more common or popular words having the larger etymology sections but that not really the "problem" here, and the longer sections are all pretty much on topic even if they get rambly. For one, we aren't Wikipedia, and these long paragraphs are a bit unwieldy to the average reader(read: eyesore), and if i probably wouldn't have broached this topic this time last year on the merit of having the full etymology on the same page to be quite useful, and probably was the intent prior, however with the introduction of the etymon template among other technical revolutions on the site this year, there's now much better ways(imo) to present the info to the average readers. another argument for reducing these large sections would be synchronicity, as I've encountered plenty of cases where one entry is missing details provided by another or one having an error that the other had fixed.
now it might sound like i'm advocating for said "only list the direct ancestor" situation but honestly my main gripe with how things are are mostly just presentation of the info, I've brought up on the Discord the suggestion of if entries are to be going the distance of providing an exhaustive etymology, that it doesn't need to be presented in paragraph form, particularly given that it's mostly just three to five word statements like(now presenting how it could be presented instead of paragraphs):
I mentioned this on Discord: with the {{etymon}} template, I don't think it'll hit widespread usage until it's easier to use than the basic etymology templates like {{der}}, {{bor+}}, {{inh}}, etc. etc. Having to learn/use IDs and the whole system is daunting for the average editor. I do agree though that our etymologies do need cleanup in terms of what to display. A lot of times I'll just show the initial borrowing and put "ultimately from" for entries like Hawaiian ʻApekanikana or Yoruba Alibéníà. AG202 (talk) 17:08, 6 August 2024 (UTC)[reply]
@AG202: The goal of {{etymon}} is to connect entries like puzzle pieces, so I think the main problem currently is that very few entries are using it. In the future it will hopefully be saving massive amounts of time on stuff like categorization, finding derived terms, and writing out long etymological chains by hand. Ioaxxere (talk) 19:56, 6 August 2024 (UTC)[reply]
I'm in favor of increased usage of etymon to reduce the problem of different etymology sections not being in sync with each other, but I agree that in its current form the template is not simple enough to be easily used (e.g. the ID system is cumbersome, and the conditions for when not to use "from" are not intuitive).--Urszag (talk) 20:25, 6 August 2024 (UTC)[reply]
We've previously discussed - and seemingly agreed upon - how to make the syntax of {{etymon}} more intuitive. Due to the unfortunate choice of title I cannot link the thread directly, so here is the URL in plaintext: https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2024/June#{{etymon}}
Incorporating Benwing's last suggestion, we'd have something like:
{{ety|en#X|clever#Y|-ly#Z}} “[cleverly is] from clever + -ly”
{{ety|en#X|enm:charitee#Y}} “[charity is] from Middle English charitee”
{{ety|ru#X|de:montieren#Y|-овать#Z}} “[монтировать is] from German montieren + Russian -овать”
The X, Y, Z following the hashtags are IDs, and various additional parameters can be added like |inh=1 |bor=1 |blend=1 |backformation=1
The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.
Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.
Please share this message with members of your community so they can participate as well.
Micronations are not explicitly mentioned in Wiktionary:Criteria for inclusion#Place names, yet we have at least seven pages for micronations on Wikt. Seeing as they do count as place-names, I am asking here for input on whether or not micronations should be allowed to have their own entries/just be subject to the same criteria as any entry. FWIW, I am of the opinion that they should be allowed to have entries, and, for clarity, be added to the aforementioned policy link as legal scholars tend to classify them as political entities, which are already allowed entries on Wikt. Would appreciate any feedback or comments, including any opposition to this proposal! Kindest regards, LunaEatsTuna (talk) 03:30, 7 August 2024 (UTC)[reply]
I've discussed on the Discord that they should be counted, because they are names of places, and could be seen as already have been included in CFI.
My reasoning for this is as follows:
1. We include "[h]uman settlements: cities, towns, villages, etc."
2. Micronations are human settlements, in the sense that they have/had people who live in them. (We also list ghost towns with 0 people in them, so people actually living in them isn't a concern).
3. As such, human settlements are implicitly included in CFI.
Regardless of if you think my reasoning is sound, I do feel that they should be included, as they can achieve the same level of being talked-about as the towns in Arizona, or even more, in some cases (such as Sealand.) CitationsFreak (talk) 04:00, 7 August 2024 (UTC)[reply]
I firmly believe that they are not currently included under our current criteria for Wiktionary:Criteria for inclusion#Place names. Looking at the list found at w:List of micronations, I would be hard-pressed to say that our policy states that we should include all of them. Most of them have no people living in them, and some don't even have an actual territory. A resort, a farm, a bank, two sculptures, straight-up fraud, and more should not be included by default as purported micronations. While I don't necessarily support our current policy that includes ghost towns & unincorporated communities with no people living in them, those at least receive recognition from an actual state and can be found on official government documents.
A lot of micronations are essentially "I made this up". Some should fall under WT:COMPANY. For example, I simply do not think that the Principality of Snake Hill, from a "family in New South Wales who were unable to afford their taxes seceded from Australia", should be included by default here. Some micronations are just online communities, and I don't think we'd want to open the floodgates to the name of just any online community that declares itself a micronation. A number of them claim territory that they don't even live on. It just rings as unserious, frankly, and our place names policy is broad enough as is. They don't rise up the level that an actual unrecognized state like Somaliland does.
That being said, I would support a policy to explicitly include notable micronations such as Sealand, but I'm not yet sure what the notability criteria should be. But for now, I'd say that they fall under this policy: "Most manmade structures, including buildings, airports, ports, bridges, canals, dams, tunnels, individual roads and streets, as well as gardens, parks, and beaches may only be attested through figurative use.", if even that. Or they could go into the Appendix. AG202 (talk) 04:28, 7 August 2024 (UTC)[reply]
I would like to point out this line from the rationale of the CFI place names vote: "[T]he categories are left open-ended to allow more of our existing entries." This means that if a specific type of place is not explicitly spelled out, it does not mean that it falls under the criteria.
Also, the regular CFI criterion protects us from having to deal with every little obscure micronation made up by a ten-year-old in their bedroom. I would say that any micronation that is mentioned in three+ independent sources over a period of one year should be included. If enough people talk about, say, Melchizedek, then I'd say it's notable enough for us.
"Plus, is a fake nation really more similar to an airport or street or anything else mentioned in that sentence than a nation?" Yes? I'm almost certain major and even some minor airports have more notability and usage than the vast majority of the micronations listed. Let alone actual nations and sovereign states. Like I said some of them are literally a singular building. Also, honestly, our CFI criterion doesn't protect us, considering all we need are 3 Usenet comments, or at this point simply 3 tweets. AG202 (talk) 05:02, 7 August 2024 (UTC)[reply]
I meant that in terms of function. A micronation acts like a nation, with its own government and rulers and flag and so on. This is unlike an airport or a street, which doesn't.
Also, like I said, I am using the CFI standard, "use in durably archived media, conveying meaning, in at least three independent instances spanning at least a year". If these conditions are met when people are talking out a building, why shouldn't it be in Wikt? CitationsFreak (talk) 05:08, 7 August 2024 (UTC)[reply]
Because they are explicitly excluded by WT:CFI#Place names, unless they have figurative usage, which is exactly my point. If we included buildings and such by default, I wouldn't be replying here, but that's not the case. We can't simply have someone redress a building or company or farm or something similar as a "micronation", get 3 independent usages, and then bam, we include it by default. That just does not align with how I'd expect our policies to be read. And looking at the list from WP, based on the references they have, I would expect the vast majority, if not all, of them to pass if we include them by default. AG202 (talk) 05:15, 7 August 2024 (UTC)[reply]
I would totally expect a reader to look Sealand, but not the name of any other sea fort, since it is famous. (However, I wouldn't expect a reader to look up Bob's Principality of North-East Main Street.)
(In the Discord, I had also suggested "a new rule for microstates, that says something like "Ignore all references to the founding of the state[, since they are not independent]"? What do y'all think?) CitationsFreak (talk) 05:33, 7 August 2024 (UTC)[reply]
Well, a micronation is a territory around a building plus a government. So we include them by comparison to, or their partial identity with human settlements, neighbourhoods and countries, as we even include fictional countries. This does not exclude that some shall not be included also according to our inclusion criteria because they are more similar to constructed languages, for instance.
We should be more concerned with violation of WT:BRAND by their artificialities. Some are organized like a cult, a club or criminal organization, though we include 'ndrangheta, Hamas, Islamic Revolutionary Guard Corps and the Unification Church, or what: I think about Reichsbürger here, whose constructs aren’t considered micronations however. Somewhere it does go too far. We won’t agree on their being noted in references per se supporting their inclusion, though notability is important, since just for clarity and not being confused with Wikipedia Wiktionary editors will avoid mentioning notability in the CFI, which they fear not to even understand in the same way as you if they don’t edit Wikipedia.
We can make RFDs for any reason later if the current inclusion situation goes out of hand, I don’t see a benefit of a theoretical community agreement on inclusion criteria specific to micronations. It is right, necessary and sufficient that we have discussed it, this well help us later to find out what goes too far. Fay Freak (talk) 13:15, 7 August 2024 (UTC)[reply]
Micronations aren't all one kind (Liberland denotes a specific area, Obsidia is a movable rock; some are oft-mentioned, some scarcely-mentioned), so IMO we shouldn't add blanket acceptance of all micronations to CFI. But if enough people use a term like Liberland to refer to a given area, I don't see an obvious dividing line between that and other coinages for specific (or nebulous!) regions—which may not have administrative significance or population—we don't bat an eye at: the Triangle, the Golden Strip, Trójmiasto, Mariana Trench, not to mention terms where sovereignty is disputed, like Northern Cyprus, Judea and Samaria, or Donetsk People's Republic. If there are cites to support it, I don't see a reason not to include Liberland: but that doesn't mean we should define these as real nations; I might lead with Liberland being a name for a particular area (used by people who claim it's a nation), and likewise might merge the first two senses of Seborga and just mention that the town is claimed to be a micronation. It's true anyone can make up a micronation and we could be flooded, but we can RFD things were needed (if we don't blanket-include them), and AFAICT people could already coin and flood us with coinages for non-micronation regions: if people start calling an arbitrary U-shaped snake of land from Hamburg down to Hannover and east to Berlin and north up to Waren "HaHaBeWare" (or something as self-promotional as some micronations, like "Rachel's Backyard"), not asserting it to be a micronation but just saying "this is a name for this region, a la the Golden Strip", I don't currently see on what basis we wouldn't include that... (Also, while Obsidia, which I mentioned above, is less a placename and more like Ishango bone or Einang Stone, we seem to be deciding at RFD to keep such "names of specific individual stones and bones", so maybe Obsidia is fine too? I don't know; I'm more sceptical of it, and we don't currently have other stone-names I checked like Stone of Scone, but I'm curious why Ishango bone would get a pass and notObsidia... maybe we want to reconsider including Ishango bone?) I am, as always, liable to change my mind as I hear more arguments... - -sche(discuss)21:36, 7 August 2024 (UTC)[reply]
Garner still uses the regular plural in these types of definition. Thus, for trillion he states that in Great Britain, it traditionally means a million million millions.
(Notifying PUC, Jberkel, Nicodene, AG202, Benwing2): There has been a conflict on what to do with the headword line (pinging the article creator @Olybrius). My understanding is that the article "la" seems to be always used with the name of this river, and it is not capitalised; but I don't think we should change the headword line. What should we do? Are there other names in the same situation? This is not like the situation of La Défense where "La" is lexicalised as part of the name and is always capitalised (however there are also some websites that perhaps by mistake have left it uncapitalised.) --kc_kennylau (talk) 19:29, 8 August 2024 (UTC)[reply]
@Kc kennylau This is very common with French rivers as well as other entities, e.g. most countries (les États-Unis, la France, but just Israël). We don't have a general policy on how to handle this; in English, there is now a param |the=1 for cases like this, which displays "the" in the headword (e.g. the White House; but not always used, cf. the Castro, a well-known district in San Francisco). In German, {{de-noun}} also has special support for this. I'm not sure about other languages. Benwing2 (talk) 19:42, 8 August 2024 (UTC)[reply]
I do feel that we should maybe add articles in the headword for things like la la Barbade or l’Alabama. It makes it more clear for learners, especially since not every region or country uses an article. It's brought up quite often in French-learning spaces. AG202 (talk) 20:58, 8 August 2024 (UTC)[reply]
I agree. I don't know if it's necessary for rivers because AFAIK all rivers take an article, but for countries and regions it varies from term to term and is very useful to include. That's why it's included in English and German, for example. Benwing2 (talk) 21:17, 8 August 2024 (UTC)[reply]
Does your belief apply only to rivers, or also to countries and regions (see above)? If the latter, my concern is that these usage notes would need to be added to every country and region, and would be more compactly conveyed in the headword (following the example of English and German, among others). Benwing2 (talk) 21:35, 8 August 2024 (UTC)[reply]
I'd just find it easier to include the definite article in the headword for learners, since it's not like it's particularly common to find them with the indefinite article. And then for the prepositions used, we definitely have to include usage notes or usexes (like fr.wikt) after having seen this page for countries and this page for U.S. states, which is what I've done at pages like Alabama and Barbade. AG202 (talk) 04:37, 9 August 2024 (UTC)[reply]
It seems we're tackling several topics at once, but getting back to the topic of rivers specifically, the indefinite article is also in use: "Pour une Seine plus propre". Therefore, not only is it not useful to add the article in the headword, it's also potentially misleading. We don't feel the need to mention that Thames is used with an article, why should it be any different for French names? We're a dictionary, not a grammar book. PUC – 12:01, 9 August 2024 (UTC)[reply]
To be clear, I don't think rivers need an article displayed. However, I will say that in English, with United States, you can definitely say "(for) a cleaner United States" as well; it's just not particularly common, and it's generally understood as a possibility, so I don't think it's misleading to show the definite article. AG202 (talk) 13:34, 9 August 2024 (UTC)[reply]
I think you are missing the point. There are semantic reasons why some common nouns take articles and some don't, but there are no such reasons for proper nouns referring to countries and regions; it's essentially arbitrary. Benwing2 (talk) 00:38, 11 August 2024 (UTC)[reply]
It's rather that I don't see why the “default” state for a class of words should need to be marked every time, as opposed to just the exceptions. Nicodene (talk) 03:50, 11 August 2024 (UTC)[reply]
Because from a French learner's perspective, while it's clear that every noun has an article, it's not necessarily assumed with a country name considering how other languages handle countries. I've seen it happen so many times in French-learning spaces, where folks are confused as to which countries use an article, what gender they are, what prepositions they use, etc. etc. AG202 (talk) 01:19, 12 August 2024 (UTC)[reply]
Then mark the nouns and proper nouns that deviate from the general pattern of taking articles? I don't see the problem at all. Nicodene (talk) 01:25, 12 August 2024 (UTC)[reply]
How are readers of this dictionary (which is an English dictionary, intended for English speakers, whose countries don't normally come with articles) going to magically know these Wiktionary-specific conventions? Benwing2 (talk) 01:28, 12 August 2024 (UTC)[reply]
I'd be very surprised if there exists a single dictionary of French with entries/headwords like le chat, la femme, l'homme, la France, Israël, janvier, le zèbre. Nicodene (talk) 01:34, 12 August 2024 (UTC)[reply]
Most if not all bilingual dictionaries leave out lots of pertinent info; that doesn't mean we need to do the same (and User:AG202 and I have already said there is a material difference between 'le chat' and 'la France', which you seem to be willfully ignoring). Benwing2 (talk) 02:23, 12 August 2024 (UTC)[reply]
If the existence of an exception to a rule means that everything that does follow that rule needs to be marked as such, then you should also, logically, do the same with all French nouns. Nicodene (talk) 02:35, 12 August 2024 (UTC)[reply]
We really should have a policy for removal of bot rights from accounts that have become inactive for a reasonable period. We could say a bot is temporarily inactive after 2 years and permanently after 3 years. For example, NanshuBot and Websterbot have not edited since 2003, and TheCheatBot has made no contributions since 2008. There must be a notice to the bot owner prior to removal of rights. Any bot removed due to temporary inactivity must be restorable at the request of the owner. However, if the rights are permanently taken away after a longer period, it would require another vote for their reinstatement. Let me know what you think. — Fenakhay(حيطي · مساهماتي)02:45, 9 August 2024 (UTC)[reply]
@Fenakhay Sounds good to me. 2 years sounds good for a temporary revocation but for a permanent revocation maybe 5 years; 3 years seems maybe too close to 2 years. I would add that if a bot owner requests that the bot rights be restored, this doesn't reset the clock; if they ask for a restoration but don't do anything with their bot, then the bot is still subject to permanent revocation after the relevant period from the last edit performed by the bot. Benwing2 (talk) 04:14, 9 August 2024 (UTC)[reply]
Knowing which accounts are bots is surely of great value to researchers and others who are studying patterns of contribution to this wiki. Given the special importance of the bot flag as a way of distinguishing non-human contributors to our entries, I'd rather deal with the account compromise risk by indefinitely blocking inactive block accounts rather than taking away the bot group. This, that and the other (talk) 11:41, 11 August 2024 (UTC)[reply]
I agree with TTO here. When a bot hasn't edited for a long time, it doesn't suddenly turn into a human being. So if the only goal is to prevent the bot account from getting compromised, we might as well use a block. Ioaxxere (talk) 06:03, 15 August 2024 (UTC)[reply]
Yes, it confused me that neither Fenakhay nor Benwing2 actually gave a rationale for the proposal, so I had to read between the lines and assume it was to minimise the risk of account compromise, in which case blocking is the more appropriate solution in this context.
Hmm. This is tricky. I'm weakly inclined to Oppose as written and Support TTO's alternative idea to block inactive bots, because I appreciate that declaring inactive bots to have become human (!) — or, to have ceased being bots — is probably unhelpful... but I think the real issue is that we're using the bot flag to mean two different things at the same time, and that becomes a problem in situations like this where only one of the two things is true. We mean both "this account is [present tense] authorized to operate as a bot" and "this account is a bot". Perhaps what we really need is to have the devs add a new user group for "inactive or unauthorized bot" (which has no special rights), to which inactive, or recently-active and blocked unauthorized, bots can be switched...? But even then, blocking such bots seems advisable, so I am persuaded that blocking is a better way to accomplish the goals of "continue to indicate which edits came from a bot" and "prevent the accounts from making edits". - -sche(discuss)04:33, 17 August 2024 (UTC)[reply]
A comparison between bot activity and non-bot activity by the bot account holder may be useful. There may be cases where the bot account holder is still active, but not using their bot. DonnanZ (talk) 12:32, 18 August 2024 (UTC)[reply]
These changes would bring Wiktionary in line with the naming conventions of modern English scholarship, as found in for instance the Oxford Guide to the Romance languages (2016).
Context:
Francoprovençal has been the name used in French scholarship since the 1970's. Removing the older hyphen lessened the misleading impression that the language is some sort of secondary blend of French and Provençal (Occitan). There is also an element of typographical convenience.
Veneto has always been the name used in Italian scholarship, if I'm not mistaken, with Veneziano predominantly or exclusively reserved for the varieties spoken in Venice and environs, as opposed to the rest of the Venetan domain (Ve1, Ve3‒7).
Support, the Venetan proposal in particular has been a long awaited change, and given a part of modern Anglophone scholarship handle this sensibly we have little reason to stay behind. Catonif (talk) 22:15, 9 August 2024 (UTC)[reply]
Thanks for pinging me. I am pretty indifferent to the hyphen question for Francoprovençal, while I am not fully convinced about Venetan; after all, Venetia is the anglicized name for the region of Veneto (if the linguistic reasoning is to distinguish the specific dialect of Venice from the language as a whole). But if Venetan is now most common in English-language professional literature, then I don’t think there is much to debate. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo](parla con me)21:21, 13 August 2024 (UTC)[reply]
The region's name occurs ~15 times more often in English as Veneto than Venetia, according to a Google search for “region of ____” (119000 results versus 7960). The latter occurs generally in historical as opposed to modern contexts.
Also at the moment we have no (reasonable) way to indicate a term used in Venice proper, as opposed to, say, Padua. A dialect label like Venetian would be identical to the name we currently use for the overall language (contra, as mentioned, the name used in linguistics). Nicodene (talk) 22:05, 13 August 2024 (UTC)[reply]
Yeah, as I said, I get the reasoning. The thing is Venetian, despite being most commonly a word for stuff from Venice specifically, is not a strictly technical term like Venetan is—which is what comes to me a bit off given that this project is not directed to linguists but rather to the general public. And we could still label entries from the dialect of Venice as Venice, Venice dialect, Venice Venetian or something along those lines. But, again, it doesn’t mean I strongly oppose changing Venetian to Venetan. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo](parla con me)22:19, 13 August 2024 (UTC)[reply]
The general public in Italy would be surprised to hear the dialect of, say, Padua described as veneziano. E.g. on Italian Wiki Dialetto padovano redirects to this page, where veneziano is mentioned solely as an external entity: “le parlate dei centri più importanti…sono state influenzate dal veneziano”.
So this is more about the general public of English-speaking countries, which isn't aware that such a language exists, as opposed to a local variety of (Standard) Italian. Nicodene (talk) 23:00, 13 August 2024 (UTC)[reply]
Support If we are not going to have separate h2 for the main dialect groups of the Venetan language, then we must go for Venetan. As @Nicodene said, Venetian is the dialect of Venetan spoken in and around Venice. For instance, Paduans, Vicentines and Trevisans speak Paduan, Vicentine and Trevisan respectively, not Venetian. — Sartma【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】15:27, 15 August 2024 (UTC)[reply]
Hello, I'm still new here so not sure if I'm posting in the right place. But WT:TEA seems to be about individual words and my concern here is wider. There is a previous discussion of synthesised audio files at Wiktionary:Beer_parlour/2024/June#synthesized_audio_files but as far as I can see it was archived before reaching a firm conclusion, and I'm not sure what I'm supposed to do on encountering a batch of low quality synthesised audio files. They were added by a user whose only contributions seems were on 2 days in July, so I'm not sure if they're still active or are a known user who likes to contribute under different usernames. I'm sure somebody ought to have a word with the uploader, but that would best be done by someone with more experience than me.
The audio at fucking Nora is very unnatural, especially in intonation, and the one at paucilingual is of something else entirely. I suppose I could boldly revert all the additions, but I'm not sure whether the files themselves should be deleted or how to initiate that process. Moreover, the previous discussion seems to have no firm consensus on whether all synthesised audio files should be removed, or only the ones obviously of poor quality, and some of this batch seem somewhat reasonable (although all are obviously synthetic).
The previous discussion did seem to be inching towards developing some kind of process that an editor can follow when they encounter such files, but it doesn't look like a final consensus was reached on that either, or that it was written up on an appropriate help page. So while I'm flagging this particular batch up now, I think it would be helpful for there to be guidance available on what I'm supposed to do in future. LeadingTheLifeOfRiley (talk) 22:32, 11 August 2024 (UTC)[reply]
@LeadingTheLifeOfRiley I personally think synthesized audio should not exist on Wiktionary, because it's not nearly good enough (even the best TTS) at equalling a native speaker's pronunciation. This is also probably why there's a request that only native speakers should record audio, since non-natives might make "mistakes". In that case there's definitely no doubt that programs will make mistakes, so I think synthetic audio should not be put on entries. Kiril kovachev (talk・contribs) 18:09, 19 August 2024 (UTC)[reply]
I oppose all synthetic audio pronunciations. If I was looking for a pronunciation and couldn't read IPA I would not trust synthesized audio much more than my own best guess. — excarnateSojourner (ta·co)03:54, 20 August 2024 (UTC)[reply]
I'm strongly opposed to synthesized audio. I've removed all of User:JapanYoshi's synthesized audio files. I'm thinking about starting a vote to formally ban all synthesized audio on Wiktionary. — Fytcha〈 T | L | C 〉 14:39, 30 August 2024 (UTC)[reply]
English etymologies should start with "From" (or similar) rather than just a link.
English etymologies should end with a period.
Thus, for example, unhoaxable, currently {{prefix|en|un|hoaxable}}, is converted to: From {{prefix|en|un|hoaxable}}.
These changes will be going forward in a week's time for English only unless there are concerns that need to be addressed. (Notifying @Benwing2) Ioaxxere (talk) 23:25, 11 August 2024 (UTC)[reply]
Trust me that I know what I'm doing. As for + templates, there isn't currently consensus for adding them everywhere, so it's done on a per-language basis. Benwing2 (talk) 01:24, 12 August 2024 (UTC)[reply]
Currently there are no formalised guidelines on what orthography scheme to lemmatise Venetan terms in, which has led to at least three different orthographies being used conflictingly at the moment. I have written a concise guideline list at WT:About Venetian/sandbox (the definition section will of course have to be updated if the Venetian → Venetan renaming goes through). I'm not familiar with the bureaucracy needed to get that out of the sandbox and make it official, is this BP post enough if it receives enough support? Catonif (talk) 10:11, 12 August 2024 (UTC)[reply]
@Catonif: When there are no active editors and you are the only one to edit the language, you can just impose a standard first and change it later if people appear that have anything to say about it. If there are others that have an opinion, you can ping them on an About: page and discuss it there. I don't think a BP discussion is needed unless you personally want input. Thadh (talk) 12:31, 12 August 2024 (UTC)[reply]
I’ll chime in. I have made occasional edits to Venetian entries and I also thought some consistency was needed, thanks for working this out. Your proposal is very similar to the standardization I was thinking of, even though I don’t vibe with a couple of things: always marking ⟨è ò⟩ but not ⟨é ó⟩, and using ⟨qu⟩ rather than ⟨cu⟩. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo](parla con me)21:39, 13 August 2024 (UTC)[reply]
Hi @IvanScrooge98, thank you for the input! About the accents, the different opinions by the three modern competing standards are
only on /ɛ ɔ/, according to Grafia Veneta Unitaria (1995), which I followed
only on /e o/ according to Brunelli (2012)
on neither, according to Grafia Veneta Internazione Moderna (2017).
What are you proposing, on both /ɛ ɔ/and/e o/? If so that personally seems unnecessarily a bit cluttered. FWIW, vec.wikt also follows GVU 1995 in this regard.
About etymological Q I have no strong feelings, yet again from GVU: Pur riconoscendo che foneticamente non c'è nessuna differenza rispetto a cu + vocale, per il principio di adeguamento, per quanto possibile, alle abitudini grafiche italiane si scriverà aqua[…]. Né, per quanto l'identità sia evidente, si procederà a un livellamento, in ogni caso, con q (aqua, quor, squola) o con c (àcua, cuòr, scuòla). Admittedly, both Brunelli and GVIM seem to later ditch this principle and opt for cu always, and I'm ready to do so as well for the sake of scientific consistency, but my ultimate goal is to balance out and find the middle point of different forces, two of contrasting which being what the standard guidelines proscribe and what is actual everyday practice. My question is how familiar would cu spellings be for the average speaker (or rather, writer/reader) of Venetan? If it looks relatively natural then I can agree on switching to cu. If on the other hand it looks too unnatural and "artificial", or even straight-up wrong, then I'd rather keep the qu, which as far as I understand is still by far the commonest. Catonif (talk) 10:22, 14 August 2024 (UTC)[reply]
I’d go for accent on neither regarding ⟨e⟩ and ⟨o⟩. I think we should treat them like other vowels.
The thing is, as apparently admitted by the proponents themselves, qu is only more common due to the influence of Italian orthography, where the u in cu normally represents a full vowel and not a semivowel. This distinction does not exist in Venetian the same way it doesn’t in Spanish, for example, and I think we should proceed accordingly. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo](parla con me)10:35, 14 August 2024 (UTC)[reply]
@IvanScrooge98 Alright, I can bend towards no accent for the mid vowels on paroxytone (piane) words. This has the disadvantage of making the orthography ambiguous, making IPA sections necessary, but brings the scheme closer to both everyday practice and GVIM and arguably decreases visual clutter. As for ⟨cu⟩ I'm still unsure how natural it looks for speakers, but whatever. I'll make these two changes to the page and then officialise it into mainspace in a couple days from now if no further input is given. Catonif (talk) 12:46, 14 August 2024 (UTC)[reply]
@Catonif: Native speakers of Venetan dialects use any sort of spelling. Very few native speakers are even aware of the various spelling proposals, so they tend to apply what they learned in school for Italian. I have no issues tanking a bold approach here and go with what we prefer. My preference would be to use <cu> all the time. As for vowels, I would always indicate them in the headword, since some words in different dialects are distinguished only by their openness (I say dòcia, but 5 km from where I live they say dócia. I wouldn't write any accent in the entry name; there's too much vocalic variation depending on the dialect to fix a certain accent in the entry name. — Sartma【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】15:19, 14 August 2024 (UTC)[reply]
Hello @Sartma! Been a while. About accents in the headword, I'd prefer to avoid it as much as possible given sometimes it would be also in the entry name (for oxytone and proparoxytone terms) and sometimes it would only be in the headword, which although clear to us I believe would bring confusion to readers. Hence, I'd just omit accents on all paroxytone terms and leave dócia~dòcia shenanigans to the pronunciation section. Catonif (talk) 09:25, 16 August 2024 (UTC)[reply]
@Catonif: Been a while indeed. I had to take a break from Wiktionary's toxic environment. You're right, we should use the pronunciation section for those cases. 👍 — Sartma【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】11:16, 16 August 2024 (UTC)[reply]
@Surjection: I meant that the desktop version and the mobile version of the new design have identical HTML, but they each have a very different HTML to the current design so the module would have to be changed. Ioaxxere (talk) 20:30, 17 August 2024 (UTC)[reply]
@Ioaxxere This is just my opinion, but the desktop one in my opinion seems to be a bit too small in the new version. Comparing the page 🝬 that you use as an example, the current one puts the Unicode/HTML entity in a line above the name of the character, which keeps it out of the way; yours, on the other hand, puts it in line with the name, which seems to take up too much space, considering the box has also been shrunk.
I also like the liberal use of space employed by the current design on the bottom, which takes up another row to display the Unicode codepoints for the previous and next characters (which I also prefer), and correspondingly, there's a gap underneath the name of the character block, which makes it feel less cramped.
If there isn't a problem with the space usage in your opinion on the desktop version, would it be possible to keep it quite similar to how it is already in terms of spaciousness? I enjoy the way that it doesn't feel constrained right now and has all the space it needs to show all the information, whereas the new design seems too small for me (since it would easily have room to grow if I viewed it on any page as it is).
@Kiril kovachev: That's a good point, so I'll see if I can make the new design use a similar amount of space on desktop to the current design. But there is some information that I think is unnecessary, like the code points of the neighbouring characters which I think are always one less or one more than the current page's code point. Ioaxxere (talk) 19:26, 19 August 2024 (UTC)[reply]
@Ioaxxere Yeah, you might be right about that, it is technically not very useful. Maybe you can disregard that part, since it's just my arbitrary preference, but I guess I've gotten used to how it is at the minute. But I don't want to impede your change if you'd rather remove it. Kiril kovachev (talk・contribs) 22:38, 19 August 2024 (UTC)[reply]
Last month in this discussion, @JeffDoozan told me that his bot followed some strict rules when applying {{ux}}. I would like to gain consensus for the following bot job for English:
Apply {{ux}} even when the usage example contains a wikilink (like at attire#Noun) or multiple bolded items.
Apply {{ux}} even when the usage example is a phrase (rather than full sentences), like at puffing#Noun.
Apply {{co}} when the usage example contains two words, not including a leading "a" or "the", like at rabbit-proof#Adjective.
This algorithm isn't perfect and may result in some usage examples being misclassified, but it is still a big improvement over not using templates at all. Ioaxxere (talk) 19:21, 13 August 2024 (UTC)[reply]
Could we add an option to this template that a reading is uncertain, for extinct scripts that are not completely deciphered? This came up for me with the Linear B glyphs, many of which we know are syllabic letters rather than logograms (Unicode even separates them into different blocks), but there is uncertainty or dispute over which syllable they transcribe. Saying their "definition" is uncertain is a weird way of putting that; normal parlance is "reading". We might also want "reading" to trigger different categories (or perhaps rename the existing categories "terms with uncertain meaning or reading").
For the logographic Linear B glyphs, the current wording is fine IMO, but in other scripts "reading" might be appropriate to logograms as well. There may also be glyphs that have both phonographic and logographic uses, in which case we might want "reading" in one section and "meaning" in the other.
There are cases in other scripts where this might apply to words written in an opaque phonographic script (e.g. Akkadograms) -- we might know the meaning but not the reading, or vice versa. Possibly in some cases we'd want to say that both the reading and meaning are uncertain, rather than a binary choice. kwami (talk) 22:22, 15 August 2024 (UTC)[reply]
"der" template for phonological influence from substrate
Hey all, apologies if this has been asked before (cursory archive search suggests it hasn't), just checking in to clarify whether or not the "der" template can be used for languages that influenced a term, but which aren't ancestors of said term. Sanskrit नड(naḍa, “reed”), of Indo-European origin, is thought to have become retroflexed via substrate influence, most likely Dravidian. User:Djkcel says that Dravidian should be marked with a "der" template, but I'm not so sure about this, and the der template page makes no mention of this case, whether to confirm or deny. The Dravidian hasn't quite "hybridized" with the Sanskrit term (which would make "der" more clearly suitable), but it has exerted influence on it. Does anyone have any clue on this? User:Mahagaja, User:Vininn126. Thanks. Agamemenon (talk) 23:19, 16 August 2024 (UTC)[reply]
We currently have no categorization/template for terms that come from within a given language and are not derived or borrowed from another, such as compounds(jackhammer), clippings(motherfuck, affixation(frotteurism), among other methods of internal word formations. even if the aformentioned templates were to be given whatever is needed to denote said internal derivation, my observations have told me that a dedicated template would likely be needed as some etymologies don't slot neatly into an existing etymology template, and are usually just given either the mention or link template Akaibu (talk) 22:41, 17 August 2024 (UTC)[reply]
Isn't {{Template:from}} meant for generalized within-language derivations? Although it seems it may not actually function any differently from 'mention' at the moment, and as mentioned, more specific templates like the affix template should be used if appropriate. See e.g. puny, which was brought up when the etymon template was being introduced as an example of this type of derivation.--Urszag (talk) 00:55, 18 August 2024 (UTC)[reply]
that template currently doesn't categorize, if it can do such and be used for such internal derivations, that would satisfy. Akaibu (talk) 01:58, 18 August 2024 (UTC)[reply]
I was informed by @Victar that reconstruction entries on Wiktionary are rendered in Latin script corresponding to their vocalisation while only attested words are rendered in the language's original script, which is how Old Persian entries are already handled on Wiktionary.
However @Mellohi! changed the /k/, /w/ and /y/ in the Gaulish reconstructions to /c/, /u/ and /i/ so as to reflect the forms they are attested in Latin, and they argue that reconstructed words should be spelt like the other attested words in the language.
I have also also come across a Hittite reconstruction using cuneiform in the form of Hittite*𒊭𒀀𒆪𒉿𒀭, which is even more problematic than regular reconstructions because of how the large number of phonetic values per sign and large number of signs corresponding to a phonetic value in cuneiform, due to which even attested words in the many languages using cuneiform did not have fixed spellings in the script.
Can a fixed rule be established for all reconstructions in all languages? Personally, I argue for the phonetic-based use of the Latin script because reconstructions in the original scripts are not always feasible or predictable due to lack of standardisation in pre-modern scripts. Antiquistik (talk) 12:55, 18 August 2024 (UTC)[reply]
That's not feasible in cases where the script form is reconstructable, even if the pronunciation is not; e.g. I don't think our Ancient Greek reconstructions should be converted to the Latin script. Theknightwho (talk) 13:30, 18 August 2024 (UTC)[reply]
That's fair. In this case, there will need to be criteria established to decide which languages' reconstructions should be in Latin script and which should be in their native scripts. Antiquistik (talk) 13:49, 18 August 2024 (UTC)[reply]
"It's true, most academic reconstructions are written in Latin script, for clarity, and that's especially the case for languages like cuneiform Old Persian, which are orthographically unpredictable and difficult to read. To the point of Primitive Irish, I can't find any author that reconstructs it in Ogam,{{R:sga:McCone:1986|page=245}} and there is probably a good argument to reconstruct it in Latin script as well, and I would support that if brought up in a discussion."
I would Support requiring reconstructions for languages in scripts that are incompatible with the Latin alphabet to be converted to it, whether by transliteration, transcription, or spelling out the phonetics. Cuneiform is a partially logographic script, so the correspondance between spelling and phonetics is pretty loose in many cases. As you progress toward a more-or-less phonemic alphabet or abugida, it's more of a gray area. I wouldn't object to keeping reconstructions in such a script if there are other reasons to so so. In cases such as Gaulish, which is already in the Latin script, minor adjustments for compatibility with attested spellings aren't that big a deal. Chuck Entz (talk) 20:38, 18 August 2024 (UTC)[reply]
Editors naturally make the correct choices. Clarity is the key criterion here. Middle Persian had multiple shit scripts only so it is reconstructed in Romanization, Old Persian is also not transparent enough. Akkadian does not have the problem since we lemmatize at Latin script per language-specific decision, while for Sumerian I can imagine some to prefer cuneiform, but the Sumerian internet community is not at Wiktionary yet.
People working with a language often think the script directly instead of what it stands for, one reads with visual memory. For Old South Arabian it is likely that one would use their script and forgo Romanization since knowledge of many vowel values is wanting and acquaintance with the script is expected if one does anything at all with the language, and at a similar vein I made Punicreconstructions to avert entryism (an interesting context to apply this term, yes), also motivated by the idea that no one should enter ancient Romanizations (and Grecizations, hell why is this word unattested) outside of an appendix (as they would go out of hand and contain more textual corruption than truth). Fay Freak (talk) 21:28, 18 August 2024 (UTC)[reply]
@Fay Freak This would align with @Chuck Entz's comment that terms in logographic scripts would be more inaccurate to reconstruct compared to those recorded in more phonemic ones. For example, I would not necessarily support moving the Gothic and Prakrit reconstructions to the Latin script either, primarily because their representations in their respective scripts are certain to be accurate to how they would have been historically written (although I would not necessarily oppose such a move either if it was seriously proposed on Wiktionary).
Now, there is also the question of the extent to which various scripts have been used for the concerned languages as well. Given that this discussion started with concerns regarding Gaulish reconstructions, I think it is fair to take into consideration the fact that Gaulish was a primarily oral language which did not extensively use writing. I approve of primarily using the Latin script to render Pali on Wiktionary for the similar reason that Pali never had any one single primary script, and I think Wikipedia, though an independent project from Wiktionary, is also correct in primarily using the Latin script for rendering Sanskrit.
All this is to say, in addition to the question of the accuracy of reconstructions in scripts like cuneiform which had very loose spelling conventions which I have already addressed elsewhere in this discussion, there are also many more layers of nuance to take into account when choosing which reconstructions to Romanise and which ones to represent in scripts their languages are attested in. Antiquistik (talk) 11:46, 19 August 2024 (UTC)[reply]
@Victar: It is also extremely difficult to find authors that write Hittite in cuneiform, but that doesn't mean we shouldn't do it. I think our reconstructions should be given in the script the language used, unless of course that is not possible. Thadh (talk) 10:37, 19 August 2024 (UTC)[reply]
That certainly wouldn't be possible for the vast majority and even in cases where some (proto-)Hittite person was speaking a (proto-)Hittite word, the odds are very good that person was illiterate anyway, so it does make sense to me to try to normalize all these into a Latin script, as someone who does not know about Ancient Near East languages or the contemporary scholarship on them. —Justin (koavf)❤T☮C☺M☯10:40, 19 August 2024 (UTC)[reply]
@Theknightwho I would say that it depends on the specific language. It's fair to opt for Romanisation for a primarily oral language which barely used writing.
Though, when it comes to Hittite, the issue is instead about the reliability of reconstruction in the language's script, given that Hittite was written in cuneiform. And cuneiform being a mixed logographic-syllabographic script meant that it had very loose spelling conventions, not to mention that in cuneiform a single character could have several different phonetic values and a single phonetic value could be represented by several different signs. Antiquistik (talk) 11:54, 19 August 2024 (UTC)[reply]
@Antiquistik To clarify: the important issue here is the reliability of reconstructions. In the case of Hittite, your (and Victar's) argument has been that we cannot reliably reconstruct terms in cuneiform, and therefore we shouldn't have reconstructions in it; for Gaulish, the fact that it had no particular literary tradition also prevents us from being able to reliably reconstruct an authentic representation, because no such representation ever existed in the first place. In such cases, we use a normalised Latin script to represent morphemes (though I admit the distinction becomes confusing for languages that have actually been attested using the Latin script, such as Gaulish, even if it was only done on an ad hoc basis). However, at no point does the literacy of the majority of speakers play any part in this: it's true that "the odds are very good that person was illiterate anyway", but that was true for Ancient Greek, Gothic and Prakrit, too. The fact is that it doesn't matter, for our purposes. Theknightwho (talk) 12:07, 19 August 2024 (UTC)[reply]
@Theknightwho My bad, I forgot to clarify myself. Indeed, I don't think literacy of the speakers is a factor regarding whether or not reconstruction entries should be in scripts that were used to write the languages they are from.
Ability to create a reliable/accurate reconstruction in the script, and presence or lack of a literary tradition in a particular script or several specific scripts, should dictate whether or not to Romanise reconstruction entries. If either one of those is missing (e.g. the 1st one for Hittite; the 2nd one for Gaulish; both 1st and 2nd one for oral-only languages), then the reconstructions should be Romanised. Antiquistik (talk) 12:19, 19 August 2024 (UTC)[reply]
@Thadh The problem is that there was not one single fixed way of spelling words in scripts like cuneiform, or even Egyptian and Anatolian hieroglyphs and Linear A and B, for that matter. There were multiple ways in which words could be written even if using a very limited set of characters, and, in the case of cuneiform, a single character could have several different phonetic values and a single phonetic value could be represented by several different signs. This makes any process of reconstructing using cuneiform and similarly-functioning scripts extremely unreliable in terms of accuracy. Antiquistik (talk) 11:25, 19 August 2024 (UTC)[reply]
@Antiquistik: We often normalise the entries for such languages anyway, using one 'standard' spelling with multiple attested variants. Don't see how that would be problematic for the reconstructions.
As for @Koavf's point: If we're using arbitrary signs for recording a spoken language, might as well use a native script. What I said wasn't about "Proto-Hittite", it was about actual, recorded Hittite - scholarly consensus isn't always the best thing for us to follow. In the case of orthography, it's not. You're not arguing for reconstructing Middle English using Canadian syllabics just because it had a messy orthography - seems a bit disingenuous to force Latin unto those other languages, no? Thadh (talk) 14:31, 19 August 2024 (UTC)[reply]
@Thadh What you are proposing is feasible for adjads, abugidas and alphabets, not not with logographic and/or syllabographic scripts like cuneiform and the like.
Hittite cuneiform alone had four signs for /ša/, one sign for /sak/, eight signs for /ku/, and four signs for /wa/.
And the were no rules regarding which signs to give precedence in cuneiform, which simply makes it too uncertain how to normalise an unattested term in a language using this script. Antiquistik (talk) 15:18, 19 August 2024 (UTC)[reply]
@Antiquistik: I know how Hittite works. I also know these signs have the same value and were used interchangeably, so we can actually decide ourselves which one to give a priority. We can, for instance, say that ša1 is from now on the 'prioritised' form, with the others being added based on attestation - there, problem solved, all reconstructions now use ša1. That is exactly how we would treat any other attested language.
For logographic scripts, yes, that won't work, but most languages have a segmental alternative - the only languages that doesn't that I can think of that is deciphered is Sinitic, and even there we can often just use the modern sign for e.g. classical Chinese. Thadh (talk) 15:26, 19 August 2024 (UTC)[reply]
I don't know that it's disingenuous: it's just the most convenient manner to write these reconstructed forms. It may well be the case that the literature uses cuneiform to write them, but it could also easily be the case that they use Latinized forms. There would be nothing wrong in principle with Cherokee or Sinhala script or whatever, but I find it highly unlikely that is what the sources use. —Justin (koavf)❤T☮C☺M☯20:59, 19 August 2024 (UTC)[reply]
Support having reconstructed entries for poorly attested languages with weird scripts in Latin script. Making reconstructed Primitive Irish entries in Ogam is a pain in the ass. —Caoimhin ceallach (talk) 20:46, 19 August 2024 (UTC)[reply]
@Caoimhin ceallach: This online keyboard easily solves the Ogham issue. I think it might even be how those written-in-ogham titles even exist in the first place. But I don't mind changing reconstructed Primitive Irish to romanized entry names; albeit scholars generally romanize Primitive Irish in all-caps. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 21:44, 20 August 2024 (UTC)[reply]
So we have the following categories of related issues:
Primitive Irish: Requires this online keyboard to type in conveniently, and its attested inscriptions consist of virtually exclusively personal names.
Gaulish: Written in Latin script natively, the "Romanized" reconstruction pages are inconsistent with attested native Gaulish orthography. E.g. the reconstruction pages spell /k/ with the letter K when the actual Gauls spelled the sound with the letter C, and the reconstructions tend to use -y- even though Gauls never spelled /j/ like that (they used the letter I).
Cuneiform and Persian scripts: general nightmare to handle digitally, Romanized reconstruction entries are preferred for these to avoid hassles.
1 Could you add that to Wiktionary:About_Primitive_Irish? I think all hacks like that should be shared to help less savvy editors like me.
2 I agree with using C, I, U, also because that's what Delamarre's {{R:cel:DLG}} does, although he doesn't mark unattested forms as reconstructed, which we should definitely not copy.
@mellohi!, Caoimhin ceallach Is it accurate to say that Gaulish was natively written in the Latin script? It appears to have used Greek and Greek-derived scripts like the Lugano script before the Roman conquest, and Latin epigraphically under Roman rule, but it seems to have otherwise been a primarily oral language with no literary form.
I disagree on the cuneiform front. Linear B is also not great for writing in either, but that doesn't mean we shouldn't use it. Just normalise some phonetic spelling, and then list attested spellings, just like any well-covered language is (e.g. Old East Slavic). Thadh (talk) 17:49, 23 August 2024 (UTC)[reply]
Just to be clear, these are guidelines for only reconstructions. Attested forms of Old Persian and Hittite cuneiform, ogham Primitive Irish, etc., should still be written in their attested scripts. --{{victar|talk}}19:18, 23 August 2024 (UTC)[reply]
I would like to discuss the idea of sorting St and St. under Saint in place name categories in particular. This idea, though radical, is not as daft as it sounds, as Oxford and Collins do this in their printed dictionaries. That fact can't be proved online, you need to own, or refer to, the actual volumes to find out.
There has been a long discussion in the Grease Pit (Wiktionary:Grease_pit/2024/August#What_to_do_with_St?) over the treatment of the abbreviations, which are currently mixed up with all other entries beginning with St-. This is hardly satisfactory, and User:Theknightwho has been the obstacle to change. I did prepare an example with St Neots of proposed sorting under Saint using a sortkey, but TKW saw fit to revert it.
This user has become far too used to getting his or her own way since becoming an admin, and needs reining in by more senior admins. I am non-admin, and don't want adminship, but this leaves me open to being downtrodden, despite over 255,000 edits since 2013. DonnanZ (talk) 15:31, 18 August 2024 (UTC)[reply]
For context: English entries starting with "St" and "St." are not "mixed up": they're simply sorted according to the method that decided last year in in this thread, where we agreed that English sortkeys should ignore spaces and punctuation, in accordance with how most English dictionaries seem to do it. I reverted Donnanz's attempt to change all the sortkeys to manual sort=St., which put them out-of-step with all other English entries, and Donnanz has spent the last few days acting like this is about my personal preference versus his, for some bizarre reason, despite me and @Urszag explaining numerous times that he can't just ignore established consensus; I'm still not sure if Donnanz actually understands that, going by what he's just commented above. In fact, my personal preference would have been to not ignore spaces and punctuation in the first place, as I've told him several times, which would have avoided them being "mixed up" (as he calls it), but that's not what we decided.
That all being said, I would oppose any change to sortkeys to treat "St" and "St." as "Saint", because it makes automatic sorting impossible when it appears in the middle of terms, as it's impossible to distinguish from the abbreviation for "street": compare Bury St Edmunds (saint) with Bow St. Runner (street). Theknightwho (talk) 16:21, 18 August 2024 (UTC)[reply]
It would not be necessary to apply a sortkey to those examples, only to entries beginning with St or St. Thus the sortkey would need to be selective, and only applied manually, not automatically, to those that need it. With the limited numbers of entries this is not insurmountable. DonnanZ (talk) 16:55, 18 August 2024 (UTC)[reply]
If "St" and "St." are supposed to be sorted like "Saint", then Stoke St Gregory should sort before Stokes Bay and stokesia, because Stoke Saint Gregory would be sorted before them. By default, Stoke St Gregory is sorted after them, which means we're being inconsistent if we only sort "St" and "St." like "Saint" at the start of a term. Here's an alphabetically-sorted column template which demonstrates it:
Okay, so you're advocating for a sorting system that isn't even internally consistent. Let me change that oppose to a strong oppose. There are plenty of other examples where this happens, so taking issue with the specific one I gave completely misses the point; nevermind the fact that you're advocating for sorting place name categories in a special way that adds an annoying maintenance burden to ensure they're sorted consistently, and doesn't really make sense: either we do it everywhere, or we don't do it at all. Theknightwho (talk) 18:46, 18 August 2024 (UTC)[reply]
It used to be, or may still be, the bibliographical standard to treat abbreviations at the beginnings of terms (not sure about what happens when they occur in the middle) as if spelled out in full for sorting purposes. Thus St and St. were treated as if spelled as Saint, and Mc and M‘ (e.g., in McDonald) as Mac. That being said, I can see how this is not obvious to the average user who may expect to see all the Saints grouped together in one lot, and Sts in another. It may also cause difficulty in sorting as Theknightwho pointed out, though I wonder if there is a technical way to say "sort St and St. as Saint". At this point I remain undecided. — Sgconlaw (talk) 18:55, 18 August 2024 (UTC)[reply]
@Theknightwho: it can't be that common for there to be entries with Street abbreviated as St. I would imagine the use of St to mean Saint is much more prevalent in dictionary entries. What if we defaulted St and St. to mean Saint, and provided a parameter to override it manually? (This is, of course, on the assumption that there is consensus that St and St. should be treated like Saint, and perhaps the Mac situation should be treated that way as well, which has yet to be decided.) — Sgconlaw (talk) 20:38, 18 August 2024 (UTC)[reply]
@Sgconlaw I don't really see what benefit this extra maintenance work brings, as it's adding additional (ongoing) work for no clear purpose; the point of sorting terms in categories is to make them findable, while this achieves the opposite by defying user expectations, especially if we only apply it to some abbreviations and not others. FWIW, the OED Online sorts "St. Elmo's fire" under "St", not "Saint"; it's the same for all other saint terms. For instance, "stag", "St. Agatha's letters", "stage cloth": the precise same method we currently use. Theknightwho (talk) 21:01, 18 August 2024 (UTC)[reply]
FWIW, although my personal intuition would be to sort things as spelled ('respecting' spaces), thus "sack, saint, Saint Bernard, sap, St, St Andrew's cross, St Elmo's fire, stab, stand, stellar", the few dictionaries I've managed to find "St Whatever" terms in don't match either my intuition or each other: The Webster's New College Dictionary, Third Edition sorts "standpoint, St. Andrew's cross, standstill, ..., stellular, St. Elmo's fire, stem"; Webster's New Universal Unabridged Dictionary, Second Edition has all the "Saint" and "St." terms as run-ins under "saint", alphabetized there as "Saint Bernard, ..., Saint Valentine's Day, St.-Agnes's-flower, St. Andrew's cross"; and ... unhelpfully, those are the only two I've managed to find "St" terms in. I am not inclined to sort "St Whatever" terms under "saint Whatever" here: I think more people would look for "st..." terms under "st..." than would look for "st..." terms under "sa...". - -sche(discuss)05:58, 19 August 2024 (UTC)[reply]
@-sche: (edit conflict) Yes, that's the unknown factor. Where do users expect to find them, under Saint or St? Currently we have alphabetical sorting like Staffordshire Moorlands, St Agnes, Stagsden. My attempt to group all saint entries together in an orderly fashion, where St Agnes would be followed by St Albans etc., was thwarted by TKW, who has thwarted me at every turn. I would be much happier if we could do that, so we can discuss that here too. DonnanZ (talk) 09:30, 19 August 2024 (UTC)[reply]
I'm not sure where I would expect to find them (whether at Sa or St), but I would certainly expect to find all "St" terms together. At least, that's what would be most useful. Andrew Sheedy (talk) 17:57, 19 August 2024 (UTC)[reply]
If we do that, then we should stop ignoring spaces in sorting altogether, because it would be a really bad idea to take spaces into account only in this one case, because it's inconsistent. Pinging @DCDuring @J3133 @RichardW57 @Vriullop @Benwing2 who participated in the last discussion about this. Theknightwho (talk) 18:16, 19 August 2024 (UTC)[reply]
My understanding is that systems that face a broad user population have lots of special cases or very general architectures because users have diverse, complex, and seemingly contradictory needs. If we have one "special case", we will probably have others. What would be a way to accommodate them? DCDuring (talk) 19:45, 19 August 2024 (UTC)[reply]
This is a kludge, which is inadvisable because it is not obvious to other editors why this particular sort key has been used. If there is consensus that St should be sorted as if spelled as Saint, then a proper technological solution should be developed. The focus of the discussion ought to be on determining what the consensus is. — Sgconlaw (talk) 23:25, 19 August 2024 (UTC)[reply]
Precisely. I think there's probably consensus for not ignoring spaces, but I don't think there's consensus for treating "St" and "St." as "Saint". Theknightwho (talk) 23:27, 19 August 2024 (UTC)[reply]
I don't want random sorting, I would have to do more testing there, my intention is to segregate the saints from other St- places, placing them at the beginning of the St- entries. But judging by your past actions, you will disagree with that. Goodnight. DonnanZ (talk) 23:32, 19 August 2024 (UTC)[reply]
I wanted to see whether random sorting occurs. No, it doesn't. In the Welsh list St Asaph, St Davids and St Georges-super-Ely appear in proper alphabetical order between Square and Compass and Stackpole at the moment. Those edits can be reverted once you have checked them. An alternative would be using sort=Stz, which in theory would sort them after the other St- entries. At least I am trying to find a solution to the problem, your personal view seems to stop you from looking for one. DonnanZ (talk) 12:34, 20 August 2024 (UTC)[reply]
@Donnanz As @Sgconlaw pointed out, any manual sorting like that is a kludge, which we wouldn't want to use. As several users have said already, we shouldn't be carving out a special exception just for these, because the same issues apply to all kinds of other entries as well: all the entries starting "N.", "S.", "E." or "W.", any with "U.S." and so on. The problem is that you're not looking at the bigger picture, and don't seem to understand that your personal preference for these particular entries does not justify being inconsistent in how we sort things overall. It's not complicated.
You (still!) don't seem to grasp that you personally not liking something does not automatically make it a problem that needs to be solved: given that the sorting you don't like is the method used by the OED, it's clearly not nonsense; it just isn't what you'd prefer. If there is consensus for taking spaces into account when sorting (which would group "St." terms together), then we can do that, but if there isn't, then we won't. Again: this is a very simple concept that someone with your level of experience should understand by now, but you keep reverting back to the same arguments time and again and ignore everything that doesn't align with your view, which is not becoming of an editor with over 200,000 edits. You also constantly make things personal, which is not on. Instead of telling me what I think, absorb what I actually say. Theknightwho (talk) 12:54, 20 August 2024 (UTC)[reply]
I noted Sgconlaw's comment, and the aversion to sortkeys. However, no one has come up with a better solution, let alone an automatic solution, AFAIK. So this issue may never be resolved. And being bossed about is a definite turn-off. I am not trying to make things personal, just make an observation. What about personal attacks on me? I have to accept them, it seems. It applies both ways. DonnanZ (talk) 13:32, 20 August 2024 (UTC)[reply]
@Donnanz I just gave you a general solution in my last comment, and it's far from the first time I've mentioned it. What personal attacks on you are you referring to? Theknightwho (talk) 13:35, 20 August 2024 (UTC)[reply]
Referring to personal attacks on me was a general comment, but they can occur. But a "general solution", are you referring to taking spaces into account when sorting? In general sorting, probably not. I created White Ball along with alt form Whiteball earlier; the latter won't be sorted. But White Ball is sorted before Whitechapel, which is fine, and Whitechapel is followed by White City, as can be expected. However special cases, such as here, can occur. We have to get our heads around those somehow. DonnanZ (talk) 14:51, 20 August 2024 (UTC)[reply]
@Donnanz It's the same logic used for "white" above. If you remove the spaces, you can see it: "thecharltons", "theddingworth", "theddlethorpeallsaints", "theddlethorpesthelen", "thegorge", "themelthorpe", "thestukeleys" etc. The same thing happens with "red dog", "red drum", "rede", "redeem", "red ensign", "red hat", and so on. Theknightwho (talk) 20:39, 20 August 2024 (UTC)[reply]
@Donnanz The problem is that the solution would require us to add spaces back in to compounds (e.g. "Whiteball" → "White Ball"), since it would need to know "redeye" should be "red eye", but "redye" should not be "red ye", so it would be a monumental effort to do it all manually. Theknightwho (talk) 21:58, 20 August 2024 (UTC)[reply]
OK. I see there is a Derived terms section for the, but I don't bother with cataloguing any. There must be thousands of entries with that word. It occurs in a surprising number of place names; the road on two sides of Twickenham Green is named simply as "The Green". DonnanZ (talk) 22:45, 20 August 2024 (UTC)[reply]
Coming soon: A new sub-referencing feature – try it!
Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.
We want your feedback to make sure this feature works well for you:
Sign up here to get updates and/or invites to participate in user research activities.
Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.
What do y'all think about placement of possibly related terms? My thinking is to put them under See also and mark them (via qualifier) as possibly related (or probably related, when the likelihood is high); this notion reserves the Related terms section for only terms known with very high certainty to be related. But I will put them under Related terms (with the same qualifier) if most people prefer that. No big deal, as it doesn't come up very often. Just bouncing it off the beer parlour wall. If a consensus arises (or if one already did, in some talk namespace or other), it could be notated at Wiktionary:Related terms. Thanks all. Quercus solaris (talk) 01:22, 21 August 2024 (UTC)[reply]
@Quercus solaris I do it this way too, reserving the "Related terms" section only for words that are 100% related, otherwise it basically spreads the false information that two words "are" related rather than just maybe being related. The qualifier idea is good though. Kiril kovachev (talk・contribs) 16:54, 21 August 2024 (UTC)[reply]
My personal preference would be to have them under "Related terms" and note the uncertainty in a qualifier. But I don't really add related terms, so I'd rather leave the decision to those who do. Andrew Sheedy (talk) 18:54, 21 August 2024 (UTC)[reply]
Removing information from Azerbaijani articles written in Abjad alphabet
1 I filled out the Wiktionary with words from Azerbaijani words written in the Azerbaijani Abjad (Perso-Arabic alphabet). However, at some point, @Əkrəm Cəfər wrote to me on the page and asked if these words were Ottoman Turkish. I proved that they were not, since I used a lot of literature and dictionaries of the Azerbaijani language. Then, I noticed that he just deleted the information from these pages and gave a link to the Latin versions of these words. I was offended by this, since most Azerbaijanis write in the Abjad script. This person is a citizen of the Azerbaiajni Republic, which promotes and uses the Latin alphabet (I am not against this and even for it, but the Abjad alphabet is also part of this language), but Azerbaijanis are currently an indigenous people not only in the Azerbaijani Republic, but also (if we take into account the subethnic groups) in Georgia, Iran, Iraq, Russia, Afghanistan. Azerbaijanis from these countries did not accept the Latin alphabet as the main script, for example, in Russia the official script for Azerbaijani is Cyrillic. That's not the point. The point is that they cancel all my edits on the page. Here the next question arises, why do these templates like Template:az-arabic-noun for the Abjad alphabet exist if some users delete them and make a link to the Latin version.
2 The second question is related to the article müvəllidülma. @Fenakhay just deleted Abjad written word and renamed page to müvəllidülma. Also I was write that the word is formed from 1 Arabic root, 1 Arabic affix and 1 Persian word. But he replaced the etymology with Ottoman Turkish. (Given that this Ottoman word is not in the wiktinary, this is not an argument, but still) Maybe he has some evidence? or did he do this because he considers the Ottoman language more "prestigious" than Azerbaijani?
3 The third question is related to the constant rollbacks of information from articles written in the Abjad alphabet, I constantly encounter these restrictions that they write "this word does not exist in modern Azerbaiani". This is due to the fact that the ancestor of the Azerbaijani language is not defined in Wiktionary, or rather it is defined as Old Anatolian Turkish, but this is too ancient an ancestor. For comparison, in the Turkish language the ancestor is indicated as the Ottoman language and then the old Anatolian Turkish, this is logical. But it turns out that modern Azerbaijani has no ancestor in the time intervals from the 15th to the beginning of the 20th century (according to various sources, modern Azerbaijani can begin in 1922-1923, when the USSR occupied Azerbaijan, or in 1928-1939, when the USSR translated the Azerbaijani language into latin alphabet). However, historically, the ancestor of Azerbaijani was considered as Ajami Turkish ("Turkish of Persia" and was language of Qajars, Afshars, Qizilbashs etc, it is also ancestor for Qashqayi, possible for Khalaji etc), it is known under different names, but this is the most common, since most often it was simply called Turkî (Turkish, Turc, Turk). I could write Azerbaijani articles written in the Abjad alphabet within this language so as not to encounter restrictions, but as I understand it is not possible at the moment.
Please help me with this issue, since I have a lot of literature and I want to create pages indicating these words, but I encounter restrictions from other users. Sebirkhan (talk) 12:19, 22 August 2024 (UTC)[reply]
well, well, well… since i'm mentioned here, and i feel that i'm being blamed in a disastrously manipulative way, i, with all my humility, consider myself righteous to say a few words in order to defend myself. jimmy mcgill ahh intro
first of all, i'd like to talk about my promotion of the supremacy of the almighty and the glorious of all the writing systems. as seen here and in the discussion in their talk page, the user does not hesitate to appeal to manipulative fallacies, such as the classic ones, fabricating an enemy, blaming others, and self-victimizing themselves, as seen here, here, and here: …he considers the Ottoman language more "prestigious" than Azerbaijani?. even the simple act of creating a discussion in this page is a very nice example of that, since they just couldn't manage to provide an argument and tried to end the convo asap in their user talk page and just want to continue agitating.
azerbaijani has been contributed for in wiktionary for years, in all 3 writing systems — latin, cyrillic and arabic (aka perso-arabic or abjad), and nobody denies nor asks for the opposite of that. however, handling three scripts for a language can never be an easy task, since there are quite a few options for how to approach to this situation. as far, the widely applied solution is keeping the main entries in latin-script pages, providing an {{az-variant}} to make the access to the spellings in other scripts easier, and use the {{spelling of}} template with the adequate script code, which links to the main entry, spelled in latin. i have already provided arguments about why this makes sense and why we should continue doing things this way (in the reply to this message). i humbly think and believe that, north azeri (the one written in latin script) is the only one that's regulated, and the only one that's recognized as an official language. south azerbaijani, on the other hand, (written in arabic script) is not regulated and doesn't have a widely accepted standard orthography. in addition, notable per my consideration, the latin-script azerbaijani is more accessible for people on the internet (and in the real life in general, in the world outside iran), is more well-documented, and has an overwhelmingly better online support than the arabic-script one. apple not having an arabic-script keyboard for azerbaijani is just a simple instance for this. people would immediately think of north azerbaijani if we don't explicitly mention "southern", even though the macrolanguage includes both. these, i believe, could be the reasons why the latin script was selected to keep the main azerbaijani entries. we've been doing this for years, and it is the de-facto solution for creating azerbaijani entries on wikt. this is the reason why i cleaned the entry in the first place. unfortunately, this caused an edit war, which we're trying to solve. by the way, they also suggested having duplicate entries for each script, which i object as it'd be inconsistent and hard to maintain.
and about that ottoman thing… the orthography of the azerbaijani language was quite similar to the one of the ottoman turkish language until both languages switched to the latin script, at approximately same times —the end of 1920s—. and that one dated orthography differs significantly from the current persian-style orthography and the underrated varliq standard. that's why i thought it could be an ottoman turkish word, accidentally input as azerbaijani. then they provided some dictionaries that are older than my grandma, and that's why i suggested them being marked as {{lb|az|dated}}. we just forgor this due to this silly thing we've been kept busy with, such a tragicomedy
in conclusion, i don't and cannot ever have any objections for azerbaijani being written using different scripts, unlike they try and manipulate as if i would. i am just a man of keeping things tidy and clean, appropriately formatted. that's all. it's such a shame that i've been wasting more than 2 hours to write this. i just don't understand why they just keep insisting on their nationalist views, while not being able to provide reasonable arguments. i remember that i overcame this when i was 14, like a year ago or smth. it shouldn't be that hard and we shouldn’t be struggling with such shenanigans.
p.s. i see no problem with discussing the legitimacy of the status quo approach to azerbaijani entries, but i'd prefer reasonable arguments, instead of that our armenian friend will be grateful bs.
p.s. 2. i feel like there could be better reasons for why the latin script is (and should be) perceived as the main one, so, if you have any ideas, or you think that i'm wrong, i'd be thankful if you just threw them below. tia :D əkrəm.14:47, 22 August 2024 (UTC)[reply]
You are confusing the concepts again, I can't speak or write in a language called "South Azerbaijani". My grandfather was from the Ganjabasar region, which now is the east of the modern Azerbaijan Republic. I have never spoken to a person who speaks South Azerbaijani and have never read a book written in this language. How does the alphabet relate to this or that dialect? The problem is that you are deleting information from pages where the word is written in the Azerbaijani Abjad alphabet. I am talking about information that is missing from the page of the word written in the Latin alphabet. Why do you use the template you mentioned in relation to the Abjad alphabet with a link to the Latin alphabet, and not vice versa? Sebirkhan (talk) 15:14, 22 August 2024 (UTC)[reply]
well, the term south azerbaijani is just an alias i used to indicate the modern azerbaijani language, if that helps. if you're NOT talking about the modern language, well… obviously, {{lb|az|<dated|archaic|obsolete>}} is, in my humblest-to-god opinion, our only choice.
about that deletion, thing… JUST GO AND FUCKING READ WHAT THE FUCK I TOLD YOU, OKAY? umm, wait, actually, this is not okay. i wouldn't want to use such a language. all right, what about this: i kindly ask you to read my arguments and not to act like they never happened. please. i'm not going to write the same thing twice, just waitin' till you open your eyes and start seeing things you've never seen before.
@Sebirkhan You didn't prove anything, all of the dictionaries you provided are from the early 1900s and late 1800s, despite the fact that there was an Azerbaijani orthography reform in the 1980s. None of the dictionaries you provided proved those spellings are still recognized in the modern Iranian-Azerbaijani alphabet.
Secondly, You need to calm down and Assume good faith, it is absolutely disrespectful to accuse people you disagree with of having evil motives. For the record, Akram and Fenakhay were simply enforcing a long-standing wiktionary policy to consolidate all language information in one place. If an entry is repeated in multiple places then when one version of the entry is updated, all the others will become outdated. In those instances, it can be years before someone notices one entry is outdated. — BABR・talk15:27, 22 August 2024 (UTC)[reply]
Sorry, but I think you need to read my entire text to understand that the problem is a little broader than you thought. I can not used Abjad becouse they deleting this. The problem is that the ancestor of the Turkish language is indicated - Ottoman Turkish, which was used until 1920s. This completely solves the problem in the case of the Turkish language. At the same time, there is no solution to this problem for the Azerbaijani language - the ancestor of the Azerbaijani language is indicated in wiktionary as Old Anatolian Turkish, which was used until the 14th century at the latest (and which is also the ancestor of Ottoman Turkish and Ajami Turkish and Turcomani). Where is the ancestor of the Azerbaijani language in the period from the 15th century to 1920s? Where can I write these words, but so that Latin people do not delete information from the article and do not replace it with a template referring to Latin? Sebirkhan (talk) 15:38, 22 August 2024 (UTC)[reply]
The Wikipedia article Q110812703 was authored from late 2022, in the whole lot of languages. Guess Azerbaijanis organize well and their DMN made new projects during the pandemic. But they have missed what we have done all the time on English Wiktionary. I added Classical Azerbaijani two years earlier. Nobody outside global Azerbaijan could have expected such a preference for another term, even Azerbaijani Turkologists in the West, which seem content with this label. Unlike Classical Persian it has not been added as an ancestor of Azerbaijani for no discernible reason later, after our language data modules have been rewritten and reorganized multiple times and only acquired the option of us setting an L2 language to have an ancestor in an etymology-only variety of itself.
Either way editors should be aware what they do here. They compartmentalize Southern Azerbaijani incorrectly if the target audience of this dictionary necessarily reads Latin characters. It matters less then what speakers mostly use. Anyone seeking out en.wiktionary.org can get through Arabic Azerbaijani forms redirecting to Latin spellings, there is little grounds for animosity. Fay Freak (talk) 04:48, 24 August 2024 (UTC)[reply]
Hello, so can you please add Ajem-Turkic (aka Ajami Turkish, Ajami Turkic) as ancestor? As for the term Classical Azerbaijani (which is listed as a variety of modern Azerbaijani in wiktionary), I will try to explain why it is not entirely appropriate (and in general the use of the word "Azerbaijani" for the ancestor of the Azerbaijani language.) Ajem Turkic is the ancestor of several languages, but whether these languages are separate languages or dialects is a question for which there is no clear consensus - I mean Qashqai, Afshari, Iraqi Turcoman, Sonqori, Qizilbash. In book The Turkic varieties of Iran , Christine Bulut says (page 406) that written language for theese language was Ajam Turkic since 16th century. It is a good term. But it is also a good term to use because it does not require each of these languages to have an ancestor called "classical Qashqai" (or old qashqai), "classical Sonqori", etc. especially considering the fact that their vocabulary is identical to each other with a few exception. It is obvious that they all descended from one ancestor, but now the only question is what to call this ancestor.) The above mentioned languages/dialects have no relation to the region called Azerbaijan and have never in their life called their language Azerbaijani. 178.46.58.8511:49, 24 August 2024 (UTC)[reply]
The next language community meeting is scheduled in a few weeks—on August 30th at 15:00 UTC. If you're interested in joining, you can sign up on this wiki page.
This participant-driven meeting will focus on sharing language-specific updates related to various projects, discussing technical issues related to language wikis, and working together to find possible solutions. For example, in the last meeting, topics included the Language Converter, the state of language research, updates on the Incubator conversations, and technical challenges around external links not working with special characters on Bengali sites.
Do you have any ideas for topics to share technical updates or discuss challenges? Please add agenda items to the document here and reach out to ssethi(__AT__)wikimedia.org. We look forward to your participation!
You created Ajami Turkish and then Fenakhay moved it to Ajami Turkic 35 minutes later. Then an hour later you created Ajami Turkish again, Fenakhay deleted it, and a few minutes later you created it again, and he deleted it again. I think Fenakhay moved it because in English Turkish refers to the Oghuz language of Turkey, and Turkic refers to other related languages that are in the Turkic family. — Eru·tuon20:49, 23 August 2024 (UTC)[reply]
But why Turkish page says that Turkish is synonym of Turkic? I am as Azerbaijani Turk can say that Turkic word used for words like turkic runes, turkic tribes and other ancient things (also it common for all Turkic nations) but in case of Azerbaijani we use "Turkish". For example Azeri Turkish, Azerbaijani Turkish (see: w:Azerbaijani_language. So anyway it not incorrect word but synonyms, and I was blocked becouse I have used synonyms? 194.87.107.10720:58, 23 August 2024 (UTC)[reply]
as I know "Ajami Turkic" is protologolism of H. Boeschoten, i did not find any other sources that would not refer to him. Can you share links to the term you mentioned above from at least three different authors so that we know for sure that this term is preferable?
I think something like this looks good, if anyone has any thoughts on, for example, font selection, stroke thickness, or anything else I'd love to hear it. I was thinking a thinner font might look clearer when displayed in small size, but would like to get y'all's thoughts on it. It might also be better to have this as a separate file on Commons in the meantime. In any case looking forward to seeing this come to fruition! Thanks, ChromeGames (talk) 23:55, 23 August 2024 (UTC)[reply]
Thanks for tagging me in this thread. I was able to find two font types that can display 維 but either a bit heavier (the one now shown) or much thinner. Grateful if anyone can propose a better font so that I can improve on it. Thanks. Cypp0847 (talk) 12:40, 24 August 2024 (UTC)[reply]
I’m not sure why the change is needed or desirable. The rationale should be explained. Also, the current font for the new character is too heavy—one with thinner strokes would be better. — Sgconlaw (talk) 11:49, 29 August 2024 (UTC)[reply]
纟 is not part of Japanese, Korean, or Vietnamese as far as I am aware, though I have not studied those languages closely. If I am right about that, then 维 is China (PRC)-specific. 維 on the other hand is a character used in Cantonese, Hokkien, Japanese, Korean, other local languages in China, languages in Taiwan (ROC), and Vietnam and is acknowledged in the China (PRC) official standards and dictionaries for Mandarin. It is rooted in 2,000 years of kaishu. So, from this kind of superficial view, I would say yes, it seems like this is desirable, to show inclusiveness toward all cultures and traditions that use this character. (In the alternate, I would propose an ancient form of the character; the logo seems mildly presentist to my eye.) --Geographyinitiative (talk) 19:03, 31 August 2024 (UTC)(Modified)[reply]
We have multiple articles for combinations of opening and closing quotation marks, most saying only that they "enclose a quotation in some languages" but give no examples. In our navigation template {{quotation marks}}, ‟ ” and ‛ ’ were listed only for Italian. However, when I went to the Italian wiki and checked their sources (e.g. this source), I found that the more common sequences “ ”, ‘ ’ were said to be used. Thus we have no attested languages for ‟ ” or ‛ ’, and I tagged them for verification and removed them from the navigation template. If they can be verified to be used somewhere, it would be nice to have an example or two. kwami (talk) 01:16, 25 August 2024 (UTC)[reply]
They supposedly have been used in Greek for second-level quotations: Nick Nicholas's website (2005-04-23) cites Haralambous §1.6.1, who says "Also interesting is the case of the second level quotes. Here, quotes of the size and shape of the English ones are used, but the opening quotes are inverted, similar in form to raised small round guillemets : ‟εισαγωγικά”. Fortunately these quotes are provided by the Unicode standard (U+201F and U+201D, the latter being the same closing double quotes as in English) ; the author knows no other language in which this combination of double quotes might be used."--Urszag (talk) 02:41, 25 August 2024 (UTC)[reply]
Thanks! I'll restore the link but move it to Greek.
While creating "betch" I found several examples of betchya getting split back into betchya (or betch'ya), but, like, how the crap do I format an entry for this verbal "betch"? It's certainly not a contraction, but is it really a verb form? (Are there still headword templates for verb forms in English, BTW? I have not been editing much for well over a decade...) Circeus (talk) 06:59, 25 August 2024 (UTC)[reply]
Hello. I was playing around with quotation templates (I work on several languages using Cyrillic as their native script), and I stumbled upon the way how transliteration looks there. Now It looks like this:
2021 January 13, “Э̄лы ма̄т ле̄ккарыт рӯпитан ма̄гыс э̄рнэ ма̄шинат ёвтве̄сыт”, in Лӯима̄ сэ̄рипос[2], volume 1235, number 1, page 6:
Useful machines were bought for doctors working on far away land.
There are several issues I think could be useful to change:
Aligning the given text and its transliteration (Currently it is aligned with the translation, which is quite confusing)
Making the transliteration smaller and gray
Moving the transliteration above the given text
Here how it looks in my head
I noticed {{zh-x}} template does essentially the thing I mentioned above, so I think it wouldn't be terribly out of place since this stylistic decision already exists on Wiktionary (and honestly looks much neater):
I do like the idea of the transliteration being grey and possibly smaller, but I would prefer it below the original text - that way it is clear that the quote is in Cyrillic and transliterated in Latin, and not originally in Latin and normalised to Cyrillic. Thadh (talk) 18:08, 26 August 2024 (UTC)[reply]
I do think we should consider the official dark mode that is slowly being rolled out. The current color is similar to the background color of the dark mode, which seems undesirable as it can make the text difficult to read. Also I don't agree with moving the transliteration above the original text, as it implies the original text is in Latin. The transliterations are supposed to aid in reading the original script, not replace them. — BABR・talk18:21, 26 August 2024 (UTC)[reply]
Based on some testing, this color seems to be easy to read in both dark and light mode. This is the color used by Arabic conjunction templates. There might be a better color this is the just one I found that worked. The color used by timestamps is also good in both modes but I don't know the exact hexcode for that color. — BABR・talk18:26, 26 August 2024 (UTC)[reply]
In the topic, I described my experience with the light mode, and, to my look, the issue is in the alignment and lack of contrast, the current look of quotation templates is confusing, since it's not clear right away where the native script is. Transliteration should be the main focus point, and the transliteration should look complimentary, less distracting. One of the options is to visually separate it from the original text by making the transliteration gray and/or small, and possibly make a little larger gap between the two. Kaarkemhveel (talk) 18:34, 26 August 2024 (UTC)[reply]
I also like the idea, we can possibly make it so only for the light mode (and think later when the dark mode is rolled out and understood fully), but as Thadh said, I would prefer [the transliteration] below the original text - that way it is clear that the quote is in Cyrillic and transliterated in Latin, and not originally in Latin and normalised to Cyrillic.Svartava (talk) 18:25, 26 August 2024 (UTC)[reply]
I also think it makes more sense the transliteration being aligned to the original text rather thant the translation. Normalizations could be like this, too. Trooper57 (talk) 18:30, 26 August 2024 (UTC)[reply]
@Kaarkemhveel: I'm confused by what you mean with the Chinese example. {{zh-x}} does the exact same thing as the Cyrillic example, where the transliteration is aligned with the translation. The only difference is that the translit font color is slightly different. AG202 (talk) 18:54, 26 August 2024 (UTC)[reply]
Yes, I didn't even notice that, sorry! I think because it's perfectly readable, even though the alignment is the same as in the current Q template. Hieroglyphs look distinct partially because they are blue (because of the links) and partially because they are slightly bigger and differ greatly from the Latin text (which I don't think would work with Cyrillic-Latin situation). But the transliteration is gray, nevertheless. Again, sorry for this contradiction, it's totally my fault! Kaarkemhveel (talk) 19:02, 26 August 2024 (UTC)[reply]
it is your old friend/enemy (frenemy) Equinox. I stayed away for a quarter of a year, but I have started doing nasty IP edits again.
It started out just the way that I would touch Wikipedia (like fixing a comma, tiny corrections) and then I thought "oh I have to add such-and-such a missing word", and then I risked being a damn "Wiktionarian" again. If you remember, I first arrived on your site in 2008 when I found the WT:REE page (I can't remember why, but I do remember "darkwave" [a great music genre] and "countline" [chocolate industry], and SemperBlotto repeatedly unfairly banning me for being Wonderfool, which made no sense to me whatsoever, but I understood it in retrospect, because I was British and funny).
In future you may recognise me by my excellent definitional skills, my IP address (which changes every 12 hours or so, and is usually a long IP6 one beginning with a "2"), and my ABSOLUTELY NOT editing Spanish like Wonderfool. And by not having a user account. And not posting on talk pages and starting fights. I can't do "community". I was always best at just adding missing words.
Meanwhile in the real world I have been developing some cute software and walking in some hills. (And I'm about three quarters of the way through Tolstoy's War and Peace. Jesus, I am a voracious reader but this novel is murdering me.)
thanks for writing back to us. i wouldn't have seen this if i didnt still have your talk page on my watchlist. i'm glad to see you still helping out, but i'm also glad you're able to keep yourself busy there are other things you need to do. For some people social media platforms can become an addiction, and i think Wiktionary can be just the same. —Soap—22:49, 26 August 2024 (UTC)[reply]
I am convinced that it is like that. It’s just not prevalent in the overall population enough to have a name as its own behavioral addiction. w:WP:Wikipediholism test is not humorous to me. People just start to understand their dependence on technology, and disregard of it, between all education. Gotta balance the benefit you draw yourself from maintaining this elaborate vocabulary sheet. I mean surely you gained one or the other competence from it for your CV. It even directly increased my grades in the first state examination when I could answer more obscure questions because I repeatedly went through a law paper for quotes. You can choose your special interest wisely. Fay Freak (talk) 12:32, 27 August 2024 (UTC)[reply]
I think you were splendid doing community, greatly economical in posting on talking pages and engaging fights. But who cares about my opinion concerning community. I overanalyze it pathologically. Fay Freak (talk) 12:32, 27 August 2024 (UTC)[reply]
Currently, our Proto-Romance reconstruction, such as Reconstruction:Latin/adbracchiare, feature a reconstructed pronunciation. I think it would be neat if our attested entries with inherited descendants had the same thing, since after all we know they continued to exist in the same language. I'm aware that Proto-Romance doesn't necessarily correspond to an actual historical lect, but I nonetheless think that the reconstructed pronunciation would grant readers insight as to how Latin evolved during the first few centuries AD. Naturally some kind of disclaimer could be added if necessary. @Nicodene has outlined some sound changes here: User:Nicodene/sandbox. Other reconstructed pronunciations could potentially be added as well, such as Proto-Western-Romance or Proto-Balkan-Romance. What do you guys think? (Notifying Fay Freak, Brutal Russian, JohnC5, Benwing2, Lambiam, Mnemosientje, Nicodene, Sartma, Al-Muqanna, SinaSabet28): Ioaxxere (talk) 02:21, 27 August 2024 (UTC)[reply]
We had this once, more or less--it was labeled as "Vulgar Latin". Aside from various bugs, the biggest problem was that it wasn't actually accurate for a strict definition of "Proto-Romance": it included sound changes that were never completed in some Romance languages, such as lenition of intervocalic stops (often not seen in Italian or Romanian) or lowering of short /u/ to /o/ (not seen in Romanian or Sardinian). We certainly shouldn't do that. I think displaying a pronunciation that actually represents the common ancestor of all Romance languages is of limited usefulness: there aren't a huge amount of sound changes shared 100% between all Romance, so the forms will often not be all that different from the Classical Latin form. In addition, a few changes are somewhat uncertain: e.g. when I was looking into Cj → Cʲ while working on a Wikipedia article on w:Palatalization in the Romance languages, I discovered that some languages such as Sardinian show clusters in forms such as vineam > [bind͡za]~[ˈbind͡ʒa] or corium > [ˈkorju]~[ˈkord͡zu]~[ˈkord͡ʒu]. Those could be secondary developments of earlier [nʲ] and [rʲ] respectively, but they could alternatively indicate that fusion of [nj] and [rj] into unitary palatalized consonants never occurred in these languages at all ... while stuff like this doesn't make a huge difference to the reconstructed form, it's an example of how we don't actually have complete certainty about the details of Proto-Romance phonology and phonetics. You could say the same about our knowledge of Classical Latin phonology and phonetics, of course, but I think the arguments in favor of including that are a lot stronger than the arguments for including a Proto-Romance pronunciation on Latin entries. Anyway, despite those concerns, I'm not definitely opposed to the idea.--Urszag (talk) 05:03, 27 August 2024 (UTC)[reply]
The spoken vernaculars that evolved from Latin after the fall of the Western Roman Empire began as a dialect continuum from which the various Romance languages arose. Not only did the loss of intensive Empire-wide interaction and of a centre with a prestige standard lead to a divergence in the vocabularies, but this must inevitably also have caused the local pronunciations to start diverging, with (I believe) uncoordinated sound changes. The best we can do, IMO, is to identify Proto-Romance as the last stage of Colloquial Latin, as it was spoken at the fall of the Empire. Wikipedia has an article on the phonological changes from Classical Latin to Proto-Romance. I surmise that most of these changes actually stem from before these days and reflect the phonological differences between the prestige standard (Classical Latin) and the spoken Colloquial Latin as they were already during the late days of the Empire. --Lambiam07:25, 27 August 2024 (UTC)[reply]
The proposed new category would be considered a set category (i.e. containing terms for sciences and not merely terms related to sciences). Although there have been some discussions in recent months, currently, the type of a category (set category vs. related-to category) is mentioned in its description but not its name, and existing set categories don't have "Names of" in their name. I think "Branches of science" fits better in the current naming system. Einstein2 (talk) 20:50, 28 August 2024 (UTC)[reply]
Hi, I’m having Internet issues so I can’t respond in detail but imo this is the best way of handling related groups of etymologies in Arabic, which arise due to the underspecified script. Benwing2 (talk) 21:57, 28 August 2024 (UTC)[reply]
@Benwing2 Do these differ only by pronunciation? If so, would headers like "Pronunciation 1" and "Pronunciation 2" work, as used in Chinese? My concern with these is that any etymology given under a heading like "Etymology 4.1" is ambiguous, as I don't know which parts apply to all 4.X sections and which only apply to 4.1. Theknightwho (talk) 15:05, 29 August 2024 (UTC)[reply]
@Theknightwho No, usually not. For example, unvocalized كاتب could be كَاتِب(kātib) (a form I active participle meaning "writing/writer") or كَاتَبَ(kātaba) (a form III verb meaning "to correspond with (someone)"); unvocalized كتاب could be كِتَاب(kitāb) (a noun meaning "book") or potentially كَتَّاب(kattāb) (an agent noun "scribe") or maybe كُتَاب(kutāb) (plural of a different noun, or of an adjective); unvocalized كتب could be one of many things (a form I verb كَتَبَ(kataba, “to write”) or potentially a stative form I verb كَتِبَ(katiba) or كَتُبَ(katuba), or a form II verb كَتَّبَ(kattaba, “to cause to write”), or كُتُب(kutub) the plural of كِتَاب(kitāb, “book”), or potentially a stative active participle كَتِب(katib) or a verbal noun كُتْب(kutb), etc.). All of these are derived from the same underlying root ك ت ب(k t b) but derived by different inflectional and derivational processes, and are all different terms, typically a mix of lemma and non-lemma forms, usually with unpredictable meanings. In a related language like Maltese that is written in the Latin script, they would all be written differently, and each has its own etymology. In cases that differ only in pronunciation, they are indeed placed under the same Etymology section, but mostly that isn't the case. If the etymology applies to all 4.X sections I will place it under 4.1; it is usually quite clear whether this applies to the root (and hence to all sections) or only to the term in question. We could come up with a different way of handling this but I can't think of any that wouldn't require nesting down to L6 headers (which aren't explicitly allowed per WT:EL and don't display very well). Most languages don't have such underspecified writing systems so this issue doesn't appear anywhere but in Semitic languages and maybe some other Afroasiatic languages; other languages like Persian and Urdu that use the same underspecified Arabic writing system don't follow the same Semitic inflectional principles so typically don't run into this issue so much. Benwing2 (talk) 18:47, 29 August 2024 (UTC)[reply]
@Benwing2 Alright - I see what you mean. Level 6 headers are reasoanbly widespread in Chinese and Japanese entries due to the "Pronunciation X" headers, though, and I haven't noticed any issues with them. Theknightwho (talk) 19:04, 29 August 2024 (UTC)[reply]
What I mean is the level 6 headers look identical to the level 5 headers, so it gets confusing to distinguish what goes under what. Benwing2 (talk) 19:41, 29 August 2024 (UTC)[reply]
E.g. selen- is templated as a prefix, but in most of the examples it is either the root (e.g. selenic) or part of a compound. I don't see a way to handle this in the English-language POS templates or with the general 'head' template. kwami (talk) 02:47, 31 August 2024 (UTC)[reply]
How about just "combining form", "bound form" or something analogous? Or should it be broken up into functional sections like "prefix" (the OED argues that in some words it functions as a prefix), "root", "first element in compound words" etc? kwami (talk) 05:13, 31 August 2024 (UTC)[reply]
I don't agree with classifying it as a noun, as it's clearly not. We already have a POS combining form which is probably the right thing to use here (IMO). Benwing2 (talk) 20:50, 31 August 2024 (UTC)[reply]
Changed the POS. The option is not automated for English, and we still have 'prefixsee' because that's how derived words are formatted, but it's a start. kwami (talk) 23:14, 31 August 2024 (UTC)[reply]
Can we establish a way to label separable phrasal verbs (verbs with an adverb) and inseparable phrasal verbs (verbs with a preposition) in English?
inseparable phrasal verbs (verbs with a preposition, some sources call them "prepositional verbs")
Intranstive phrasal verbs and three-part phrasal verbs are always inseparable, but in other cases, there's no easy way to tell whether a phrasal verb is separable or inseparable. Learners have to look up this information in dictionaries.
Done, @Joonas07. Fay Freak (talk) 11:25, 2 August 2024 (UTC)
Support Vininn126 (talk) 13:35, 9 August 2024 (UTC)
Oppose the proposal as put. This, that and the other (talk) 01:28, 17 August 2024 (UTC)
Strong oppose synthesized audio. Vininn126 (talk) 15:09, 30 August 2024 (UTC)
