Hello, you have come here looking for the meaning of the word Wiktionary:Beer parlour/2020/August. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Beer parlour/2020/August, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Beer parlour/2020/August in singular and plural. Everything you need to know about the word Wiktionary:Beer parlour/2020/August you have here. The definition of the word Wiktionary:Beer parlour/2020/August will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Beer parlour/2020/August, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
Although Proto-Dardic terms are now frequently shown on mainspace entries, I would be very hesitant to actually create Proto-Dardic entries because they're wanting in terms of research and we still don't have an established methodology and convention (like deciding which inflected form goes into the title, what notation to use, etc) of dealing with PD reconstructions. The entries created by this IP are neither sourced nor formatted. They, in my recommendation, should be deleted. -- Bhagadatta (talk) 11:42, 2 August 2020 (UTC)
I'm happy deleting them simply on the basis of them being garbagely put together. Dardic is a language family in my opinion though. See {{R:ine:HCHIEL|435}}. --{{victar|talk}}18:12, 6 August 2020 (UTC)
I do not know these data well enough to know whether Proto-Dardic is real. But I generally follow the rule that, until a set of consistent guidelines/references for a protolanguage has been established and discussed (i.e. WT:About Proto-Dardic), the entries should not be created. —*i̯óh₁n̥C20:26, 6 August 2020 (UTC)
@AryamanA: I would support either keeping Proto-Dardic as a code or doing away with it. There seems to be good argument for both sides the way I see it. I'm opposed to creating the entries like the ones that IP created; however, I wouldn't mind having tentatively reconstructed "Proto-Dardic" etymologies on the mainspace, if only to throw light on the possible previous form of those (Kalasha/Khowar/Torwali) words. -- Bhagadatta (talk) 14:27, 8 August 2020 (UTC)
Russian irregular verbs
Are there any Russian verbs with the -м -шь -ст conjugation besides дать and есть and if so should there be a category for them Dngweh2s (talk) 15:26, 2 August 2020 (UTC)
@Dngweh2s I don't think there are, besides the derivatives of those verbs. Not sure we need a category for only these two verbs + derivatives. We already have lots of verb categories and you can find these verbs easily by looking on the pages for дать and есть, which list all the derivatives. Benwing2 (talk) 23:39, 2 August 2020 (UTC)
"Долганский язык, сформировавшийся в процессе распространения якутского языка в макрорегионе взаимодействия различных этнических групп, является языком этноса, который в особых исторических условиях не ассимилировался в составе превалирующего в этом регионе этноса, язык которого принял, а стал функционировать изолированно, в удалении от основной массы носителей якутского языка." 2001 Артемьев, Николай Матвеевич. Долганский язык.
"The Dolgan language, formed during the spread of the Yakut language in the macro-region of interaction of various ethnic groups, is the language of an ethnos that, under special historical conditions, was not assimilated as part of the prevailing ethnic group in this region, but began to function in isolation, away from the main bulk of speakers of Yakut language". 2001 Artemʹjev, Nikolaj Matvejevič. Dolganskij jazyk. Doctoral thesis
"Некогда являлся наречием якутского языка, со временем, из-за достаточной обособленности в результате изолированности развития и внутренней перестройки под влиянием эвенкийского языка, стал самостоятельным языком"
"It was once a dialect of the Yakut language, but, over time, as a result of isolation and internal restructuring under the influence of the Evenk language, it became an independent language." Russian Wikipedia
@Allahverdi Verdizade, Erutuon: Wait, no. Dolgan and Yakut are living (albeit moribund) languages. They're derived from a single ancestor, but that ancestor isn't Yakut as it's spoken today, but instead some Proto-Yakut-Dolgan form. --{{victar|talk}}03:45, 10 August 2020 (UTC)
Well, it's not unheard of for a living language to be derived from another living language (or earlier form of a living language), like Afrikaans from Dutch. Wikipedia says the Dolgans moved away from the Yakut-speaking region in the 18th century, which is about as long ago as the Dutch colonizing South Africa. Judging by Dutch (or English) I suppose the language at that time wouldn't have been different enough from the modern language for us to assign it a separate language code. — Eru·tuon05:15, 10 August 2020 (UTC)
Language vs. dialect is, as you know, the never ceasing debate. Dolgan was already divergent before it became isolated from Yakut speakers, with its own declension paradigm and since then heavily influenced by Tungusic. It's funny, they actually say that some northern Yakut dialects have a greater degree of intelligibility with Dolgan due to a common Evenki word inventory. How do people feel about creating an Old Yakut language code, with lemma from Nicolaas Witsen lexicon, and make both Yakut and Dolgan descendants of it? --{{victar|talk}}17:39, 10 August 2020 (UTC)
That does not change the the-well established fact that Dolgan is descended from Yakut. Proto-Yakuto-Dolgan is unfortunately not a term in use, neither in English nor in Russian, and I do not support creating novel terminology within Wiktionary.
> Dolgan was already divergent before it became isolated from Yakut speakers, with its own declension paradigm
Did you read the above? It cites the ancestor of Dolgan and Yakut as Proto-Yakut (proto-yakoute), also pointing out that Dolgan predates the č/ǰ/s-merger that Yakut exhibits. --{{victar|talk}}00:01, 12 August 2020 (UTC)
This is a good paper too, going over several of the difference between the two languages, with many archaisms in Dolgan that aren't present in even the earliest attestations of Yakut, i.e. Proto-Yakut *suoq > Yakutсуох(suoq), Dolganһуок(huoq). --{{victar|talk}}01:12, 12 August 2020 (UTC)
@victar: I read the above, but nowhere do I find support for the claim that "Dolgan was already divergent before it became isolated from Yakut speakers". Anyways, what do you propose? Create a Proto-Yakout code or what? Allahverdi Verdizade (talk) 19:26, 17 August 2020 (UTC)
Technical Wishes: FileExporter and FileImporter become default features on all Wikis
The FileExporter and FileImporter will become a default features on all wikis until August 7, 2020. They are planned to help you to move files from your local wiki to Wikimedia Commons easier while keeping all original file information (Description, Source, Date, Author, View History) intact. Additionally, the move is documented in the files view history.
How does it work?
Step 1: If you are an auto-confirmed user, you will see a link "Move file to Wikimedia Commons" on the local file page.
Step 2: When you click on this link, the FileImporter checks if the file can in fact be moved to Wikimedia Commons. These checks are performed based on the wiki's configuration file which is created and maintained by each local wiki community.
Step 3: If the file is compatible with Wikimedia Commons, you will be taken to an import page, at which you can update or add information regarding the file, such as the description. You can also add the 'Now Commons' template to the file on the local wiki by clicking the corresponding check box in the import form. Admins can delete the file from the local wiki by enabling the corresponding checkbox. By clicking on the 'Import' button at the end of the page, the file is imported to Wikimedia Commons.
Armenian has an old tradition of using letters as numbers "Armenian numerals" in much the same way as Greek and Hebrew has them, except that like Roman numerals, they seem not to be especially marked as being numbers. There is evidence for use of both upper and lower case. Is there any reason why:
1) Upper and lower case numeral uses should not both have entries in Wiktionary.
2) Passing an upper case Armenian letter to {{mul-numberchart}} should not cause both upper- and lower-case letters to be displayed, as for Roman and Greek numerals.
There is an issue that @Vahagn Petrosyan is deleting my changes without giving a reason, let alone a good one. This has happened with {{mul-numberchart}} and he seems to have got it into his head that թ and Թ cannot both be numerals. (He's now deleted the lower case numeral entry!) --RichardW57 (talk) 16:44, 6 August 2020 (UTC)
I did some hunting for lower case Armenian numerals. I think I've found an example on p163 of "Medieval Armenian Manuscripts at the University of California, Los Angeles" by Avedis Krikor Sanjian. In the next to last line of Armenian script text on that page, there is a date explained as (= A.D. 1824) and the 4 characters before it seem to be a lower case Armenian number 1273. (I don't read the Armenian script, so I could have misunderstood what is going on.) --RichardW57 (talk) 18:35, 6 August 2020 (UTC)
I wouldn't say it's dumb but it does need fixing to separate it into two categories: Adjectival declension (when its with a noun/pronoun) and Sole/Lone declension. (Pronouns need this too). Solarkoid (talk) 14:31, 8 August 2020 (UTC)
Not too fond of that option (I don't think we do that anywhere else), but at least there's no duplicate. Thank you. PUC – 08:11, 9 August 2020 (UTC)
No, we don't. For consistency with other languages, there should be separate headword-line templates and inflection-table templates; and the latter should be used in separate ===Inflection=== or ===Declension=== sections rather than floating on the right-hand side, which I bet makes the mobile display very hard to read. —Mahāgaja · talk08:47, 9 August 2020 (UTC)
From my point its understandable, I can say that much. To be all honest, I didn't like it that it was next to the adjective to begin with but yeah. I personally can't do anything about it because of my lack of knowledge, but as I said, while at it, sole/lone declension might as well be added even though it is irregular on some degree. Solarkoid (talk) 17:18, 11 August 2020 (UTC)
License questions
I develop an open source - yet to be published - vocable trainer app and I have some license questions regarding the usage of wiktionary data and / or code. I'm new here, so I hope this is the correct place to ask this questions. Please feel free to point me to the right place or existing policies if I'm wrong here and this questions have been answered elsewhere already. Thanks!
I currently use modified variants of Module:fi-verbs and Module:fi-nominals to create conjugation and declination forms of the respective words to learn the different forms. My current understanding is, that this Lua scripts fall under the same license as the dictionary data on wiktionary, namely CC BY-SA 3.0, is this correct?
Does the license of this Lua scripts impose restrictions on my C++ program, which executes this scripts or is this independent of it? My program should be able to be fully used without the scripts and the scripts itself would be published under an CC BY-SA 3.0 license if it is possible to use different licenses of the C++ part and the lua parts (Regarding the C++ code part I'm considering a GPL 2.0 or GPL 3.0 license but I have to investigate this further as there might be license dependencies from other libraries / source code which I might use as well).
Wikidata has support for lexemes (see for example this finnish word) and in principle wikidata has technical advantages for my particular program as it is more friendly for machine reading. I understand that wiktionary has a different and more broad scope which can not be represented adequately by wikidata (which has its own, different purpose), however I wonder if some particular information from wiktionary can be put on wikidata as well and wonder if there are license issues in doing so. I realize that content on wikidata is licensed under CC0 1.0 and in principle it is not possible to put content published under CC BY-SA 3.0 under CC0 1.0 unless you have created the content yourself and are therefore able to dual license it. However in my understanding a single word and also its conjugated forms are not under copyright as they are features of the language (excluding trademarks). Would it be therefore possible to insert conjugation tables from wiktionary in wikidata? Of course all creative content as descriptions and also etymology would be excluded from this due to the license issues.
1 & 2. The license applies to everything. We're not lawyers, we can't give you legal advice, and you're best off just reading the license carefully. 3. You can do whatever you like at Wikidata, as far as I'm concerned. Obviously, they won't want you committing copyright violation, so if you plan to edit there, check with them rather than us. —Μετάknowledgediscuss/deeds04:22, 11 August 2020 (UTC)
Most inflection tables are probably only protected by database rights. (A good lawyer may know whether such rights are relevant. Some Wiktionary authors are working in the EU.) However, you will find that some tables are annotated, recording the applicability of the inflection and how well it is attested. I'm finding I'm having to put a lot of thought into the conjugation of Pali verbs - the aorist is particularly hard, but the existence of the middle of other tenses is often quite uncertain. We have a policy of not recording occasional misspellings, and I presume the same principle should apply to tables of inflections. I still haven't decided whether to record parāṇi as a neuter plural of Pali para. It's fairly clearly a Sanskritism, but that doesn't answer the question. Therefore, as we have to apply judgement, copyright probably does apply. --RichardW57 (talk) 17:26, 11 August 2020 (UTC)
Thanks for the answers, Μετάknowledge and RichardW57! I see it is not an easy topic and I should think further about it. I will look also how other projects handle it - it seems the combination of software and CC licenses is problematic up to CC BY-SA 4.0 where Creative Commons and FSF made sure it is compatible with GPL 3.0. However Creative Commons itself recommends not using their licenses for software. I would like to use some kind of copyleft license on my software and I think this is probably also required by the license of one of the libraries I use, so I have to check this very carefully. Coleitra (talk) 06:01, 12 August 2020 (UTC)
Either links automagically to dialectal in the Glossary, which gives two meanings: 1. Of or relating to a dialect. 2. Not linguisticallystandard. Some terms (such as hypercorrections and misconstructions) are not linguistically standard, where the deviation from the standard is not peculiar to a specific (group of) dialect(s) – but it would not be reasonable to call such terms “dialectal”. I do not know if this potential space between the definitions in the Glossary and in Main namespace is intentional, but if it is used, it is confusing. Also, I cannot think of examples that lie in that space for which the label “dialectal” makes sense, while the label “dialect” would not be appropriate. --Lambiam13:57, 8 August 2020 (UTC)
No, dialectical is definitely wrong! Do {{lb|en|dialect}} and {{lb|en|dialectal}} also categorize in exactly the same way? If so, then there really is no difference between the two and there's no reason to change one to the other. —Mahāgaja · talk08:50, 9 August 2020 (UTC)
{{quote-song}} says, for the "url" parameter: "The URL or web address of a relevant external website, such as a website containing a score of the song. Add such a link only if the score is no longer copyrighted – do not link to a website that has content in breach of copyright. Is setting the URL to the relevant genius.com page, if the artist doesn't host their own lyrics (example), reasonable? Genius appears not to violate copyright by hosting lyrics, though I couldn't find any information about how they manage that. This seems more useful than linking to, say, the official music video, since that's harder to 'read'. Does anyone have strong thoughts on the matter? grendel|khan20:20, 11 August 2020 (UTC)
Lyrics copyright seems like a huge mess. I don't see a problem with it. Just don't expect the links to work forever. DTLHS (talk) 20:24, 11 August 2020 (UTC)
a) Surely they violate copyright, their whole business model is based on doing what is illegal – although it might be that they license stuff, this will be often not viable as most lyrics will not be represented by copyright collection societies from whom they could obtain licences, and of course they may have made the commercial decision to just violate the rights as it is cheaper and the likelihood of suits for this matter is almost inexistent (especially in the rap field they began with). b) However links are still generally not copyright violations. (The few cases where the ECJ decided otherwise concerned special constellations for example with thumbnails or as when where the linked content would be unfindable without linking so the trial courts could just assume the site hosting the content to be connected to the linking site or consider the linking itself part of the publication infringing copyright. The rulings were it “may be” copyright violation to link but this cannot be simplified “it will be”.) c) Additionally even if a link to genius.com is copyright infringement the copyright holder still can’t act upon it against the Wikimedia Foundation as there isn’t the necessary legitimate interest in legal action as it is more effective to sue Genius, to take the content down instead of just the link, both being equally accessible as from US-based companies. (Some procedural principle like that will be true for most countries. I can’t tell for every system of law; the problem cannot be solved that since a web resource is accessible anywhere, one can sue in any country after its laws if the prevailing opinion on private international law in a country says that they therefore apply there.) Fay Freak (talk) 21:21, 11 August 2020 (UTC)
@Grendelkhan: is Rap Genius the same as Genius? The NYT article only refers to Rap Genius. I would avoid linking to Genius unless we are very sure the settlement and licensing agreement with Rap Genius covers Genius as well. — SGconlaw (talk) 14:31, 17 August 2020 (UTC)
Copyright aside, it doesn't feel "durable": it is a user-generated site rather than any kind of academic archive, and they may fill it with ads and change the URLs at any time. I would imagine the (user-submitted) lyrics are full of errors too, which makes it a dubious source to rely on. Equinox◑15:04, 17 August 2020 (UTC)
Ah, I didn't realize Genius was essentially a wiki as well. That's a good reason not to link to it as a reliable source. — SGconlaw (talk) 15:31, 17 August 2020 (UTC)
The audio is durable, if published in the usual way. The transcriptions on the myriad of lyrics web sites are not durable. They are a convenient place to look and link. They may not match the actual song. I listen to the song before trusting a web site. Even the more official version of lyrics packaged with an album can differ from the vocal track. (But the sleeve of an LP or CD is durable, so citable independent of the audio even if different.) As for legality, some of these sites license lyrics. Vox Sciurorum (talk) 15:36, 17 August 2020 (UTC)
This, that they are more likely to license, as well as that it is of a convenient layout, but also because it is a wiki with comments is why one wants to link it. Wikis support wikis, I guess? There is no rule not to link wikis, @Sgconlaw, though of course one does not quote Wikipedia. As Vox Sciurorum already implied Genius is not by itself the source; when I search lyrics I usually hear the song. OP just wanted to link Genius for the convenience of the readers – before other lyrics sites which are much shoddier and more likely to be dead links at some point. Plus wiki ≠ wiki if the only thing editors there are supposed to do is to transcribe correctly. Wiktionary is also more citable than Wikipedia because there aren’t that many things to fail and not as many interests to manipulate (than when writing biographies about living persons etc.), and I think Genius has a revision history (I haven’t felt a need to use it yet), so there is no reasonably-assumed problem from links being unstable; also because even in the far-away case that Genius.com gets sued and therefore must close we can just remove the URLs by bot, as opposed to a situation when people would link random sites. Again, the comparative stability is why OP wants to link Genius. Their market position is merited. He had considered some real reasons why he wanted to link Genius.com and not random lyrics sites, therefore the specific question. Fay Freak (talk) 17:27, 17 August 2020 (UTC)
I've rarely found a mistranscription on genius.com (compared to other lyrics sites). And the content is available on archive.org as well, so I don't see why we shouldn't link to it. – Jberkel17:47, 17 August 2020 (UTC)
(Proto-Finnic) vowel harmony
First point: Should we or should we not add these in the descendants? Cf. *-k'as and *-t'oin.
I'd like to use the {{head|hu|phrasebook}} headline template for Hungarian phrasebook entries to separate them from actual phrases and to clean up the phrases category. When I used the phrasebook parameter in the past, MewBot changed it to phrase with this comment: "Fixed part of speech of {{head}}". See ma rossz idő van. Is this a policy and will a bot make this change again if we start using this parameter? Phrasebook appears to be a valid parameter to {{head}}. I understand that this parameter will not put the phrasebook entry into the lemma category and this is fine. Thanks. Panda10 (talk) 16:14, 12 August 2020 (UTC)
This is designed to be as non-destructive as possible. It will only make changes when it is 100% sure that a given part of speech has a single definition and it is 100% capable of parsing, understanding, and converting all of the data in the nym section underneath that part of speech. If there's anything in the definition section that it doesn't understand, it will make no changes. If there's anything in the nym section that it doesn't expect, it will do nothing. If it finds any information in the nym section that it can't directly translate to a nym tag, it will do nothing.
Is this a desirable change? It seems like newer entries are moving towards the use of templates over sections, and I've been converting these manually when I encounter them, but if that's wrong, please let me know.
Should this process hyp(er/o)nyms or just synonyms and antonyms? Anything else?
Where should the templates go in the definition? Immediately after the "# " definition, after all of the "##", "#*", "#":" entries? Somewhere in the middle?
In what order should the templates be inserted? Synonyms, then Antonyms, then Hypernyms, then Hyponyms?
I can run this on other languages beside Spanish, if desired.
1) I'm very much in favor. 2) WT:EL also mentions Meronyms, Holonyms, and Troponyms, which are very rare, but I say include them all. 3) Not sure, I think this is disputed. 4) Yes, that's the order listed at EL. Ultimateria (talk) 18:44, 12 August 2020 (UTC)
An issue: in your gist of proposed changes, {{l|es|conflicto}} {{l|es|bélico}} was interpreted as two separate items. This is bad formatting (it should be {{l|es|] ]}}), but it seems to be pretty commonly used when the synonym is a phrase. So your script should not assume that {{l}} templates separated by a space are separate items. (See a full list of offending Synonyms sections.) However,they aren't all one item either: grid had a case where {{l}} was used by mistake instead of {{sense}} or {{q}}: {{l|pt|starting positions of racers}} {{l|pt|grid de largada}}. This should probably be {{sense|starting positions of racers}} {{l|pt|grid de largada}}. It would probably be best to skip these cases and manually check them over. — Eru·tuon19:19, 12 August 2020 (UTC)
I added the image shown on the right to the entry swadeshi(“a policy of nationalist self-sufficiency in India, involving the revival and promotion of domestic production and (originally) the boycott of British products”). I think it is good illustration for the entry as it is a historic poster promoting swadeshi, and actually mentions the term in its caption. The entry is appearing as WOTD on 15 August 2020.
@Dan Polansky has removed the image from the entry on the basis that "it does not show policy (the referent of the word) but rather a person and has excessively long caption". I'm bringing the matter here to get more opinions. Thanks. — SGconlaw (talk) 08:44, 13 August 2020 (UTC)
Thank you for starting the discussion. My position is as indicated in the edit summary. This image is not lexicographical and does not show the referent. It does not bring nearer any lexicographical fact to the reader; it stands in contrast to images of animals, even familiar animals such as a house cat. An entry for a policy probably should have no image since policies usually cannot be well shown. What I reject here is the idea of adding various loosely-related illustrations to entries only so that each entry has at least one image, and then adding to each image overlong lexicographically irrelevant captions linking to Wikipedia: the rendering in my browser shows the caption text to be twice as high as the image itself. We have successfully regulated at least one class of SGconlaw images that I found inappropriate, in WT:ELE#Images, via Wiktionary:Votes/pl-2018-04/Image policy, although the discussed image is of different sort of very marginal relevance.
On a general note, burdening the reader's attention with irrelevant or marginally relevant visual items is unfortunate. It does take reader's attention to find what they were looking for on the page; adding extraneous elements is not for free. --Dan Polansky (talk) 08:52, 13 August 2020 (UTC)
As for "mentions the term in its caption": attesting quotations is all we need, if that is meant for attestation. Otherwise, "include any image using the term of the entry in caption" would be a very bad policy, leading to inclusion of swaths of irrelevant and marginally relevant material. --Dan Polansky (talk) 08:58, 13 August 2020 (UTC)
@RichardW57: No it is not. The phrase in the picture is apparently using the literal meaning, which is different from its current meaning ("to work for free"). 恨国党非蠢即坏 (talk) 09:17, 22 August 2020 (UTC)
Terms which are lemma and non-lemma forms: how to categorize
I made Teamsters: this both a standard plural of Teamster but also collectively refers to the entity of the Teamsters union, so it is a lemma in that sense. Can anyone give me a precedent for this? Should categories like Category:English lemmas be manually added in this case? And for what it's worth, let's leave aside if the second sense should be in the definition: my question would still stand in general. —Justin (koavf)❤T☮C☺M☯01:40, 16 August 2020 (UTC)
I prefer the option of a sense at the main lemma labeled "in the plural" so all the definitions are on one page. In that case I wouldn't include the lemma category at the plural. One decent precedent I see is Cardinal/Cardinals, which rightfully lists entities as proper nouns. What I don't like is the redundancy and the fact that if you only look at one page, it's not obvious that the other contains definitions. Ultimateria (talk) 04:13, 18 August 2020 (UTC)
Picture Upload Policy
I invite editors experienced with pictures to examine the picture upload policy. The english speaking counties have laws that allow pictures to be used for educational and not for profit purposes. However, wikipedia frowns upon this because each countries's law is just a little bit different. For example, the US allows not-for-profit users to use material, and the UK allows pictures to be used for educational purposes. Here's the UK law (item 7, bullet point #2):
Since wikipedia is the internet's on-line encyclopedia, a cure all for all picture uploading is at hand. Can a code be made, and allowed to be used liberally for picture uploaders? This will address Wikipedia's unfair "fair use" policy (it does not allow the "fair use" of pictures, identified in the link above).
— This unsigned comment was added by Lord Milner (talk • contribs) at 17:35, 16 August 2020 (UTC).
I think it would be hard to justify a fair use policy at the Wiktionary. Wikipedia has encyclopedic articles about, for example, people and events, and it is easier to argue that a non-free image used under a fair use justification would aid in the understanding of such topics. This doesn’t really apply to Wiktionary entries which are simply definitions of terms. — SGconlaw (talk) 19:17, 16 August 2020 (UTC)
I'm having a hard time coming up with a fair use case for Wiktionary. If there was no free photo of Pluto? That's a hypothetical, and even then still a debatable one. There's just not a whole demand for fair use here.--Prosfilaes (talk) 23:52, 16 August 2020 (UTC)
Since we're not actually using it, we don't have a good fair-use case. It's a fine example, but certainly one we could do without.--Prosfilaes (talk) 01:57, 17 August 2020 (UTC)
The thagomizer example is an interesting one, but then I note it is only used on a citations page. In most cases where a non-free image is highly desirable I think it should be possible to refer readers to a Wikipedia article where the image appears, as was done at thagomizer. I think "File:Far Side 1982-05-28 - Thagomizer.png" should be deleted from the Wiktionary. — SGconlaw (talk) 14:25, 17 August 2020 (UTC)
Because of the ambiguity of "common nouns", Dutch (which has a "common gender") puts its common-gender nouns in a one-off category Category:Dutch nouns with common gender. This should be renamed to Category:Dutch common-gender nouns. Meanwhile, Norwegian (Bokmål and Nynorsk) don't have any per-gender noun categories, which should be rectified.
"Common gender" has two entirely different meanings, depending on language. In some languages, particularly Dutch and North Germanic, it refers to a separate gender category that historically derives from the merger of masculine and feminine genders, and is opposed to the neuter gender. In most other languages, however (e.g. Latin, Greek , Russian, Hindi, etc.), it refers to a noun that can refer to either a male or female being, and takes the masculine or feminine gender according to the sense of the noun. Someone who probably didn't realize that this category existed went ahead and created a label 'masculine and feminine nouns', which is currently populated only by Category:Hindi masculine and feminine nouns. The description says it applies specifically to nouns referring to beings where the gender follows the sense (i.e. identical to the 2nd definition of "common gender noun"), but this isn't obvious from the name, and as a result it wrongly includes nouns like सिगरेट(sigareṭ, “cigarette”), which can be masculine or feminine but not referring to a being and not with any sense difference between the genders.
I would like to suggest one of two possibilities:
Keep a single common-gender label that can have two different meanings depending on language. Call it 'common-gender nouns' and make it clear in its description that it can have either meaning depending on language. This won't cause ambiguity because languages with common gender (sense #1, i.e. merged masculine/feminine gender) can't have common-gender nouns (sense #2, i.e. either masculine or feminine depending on sense) and vice-versa. At least I *think* this is true; the only possible exception is Dutch, where some dialects have a two-way common/neuter system and others have a three-way M/F/N system.
Split the two meanings into different labels. Sense #1 (merged masculine/feminine gender, as in Dutch and North Germanic) remains as 'common-gender nouns'; sense #2 becomes maybe 'masculine and feminine nouns by sense' or 'nouns that can be masculine or feminine by sense'.
I think "epicene" could be yet another category for words referring to both males or females but having a fixed grammatical gender, per definition. An example would be до́ктор(dóktor, “doctor, physician”), which refers to both males and females but is used only as a grammatical masculine. Perhaps similar to Norwegian lege but I don't think we want any changes in Russian categorisations of genders.
OK to move Swedish, Danish and Dutch to "common-gender nouns". I think Norwegian (both NB and NN) is the one that still has remaining masculine/feminine genders, unlike the other North-Germanic languages and Dutch. There is some difference in gender classifications between, say Norwegian and Swedish, which should be carefully checked further.
@Metaknowledge I was always under the impression that "epicene" meant as in Anatoli's example, i.e. a noun that can refer by sense to masculine or feminine beings but belongs to a fixed gender. In this sense it's the opposite of common gender, where the gender and sense agree. Benwing2 (talk) 04:13, 17 August 2020 (UTC)
I guess this is a little off-topic, but I have a small issue with the Dutch "common gender". In school, we have been taught that every "common" gender noun would be divided into either masculine or feminine (thus referenced in the third personal pronoun as either hij or zij, and indeed the distinction common-neuter would clash with the canonical distinction masculine-feminine-neuter. If you look at Wiktionary:About Dutch it is clear that the common gender is used only as a placeholder, not a grammatical gender. Thus I am not sure this is a good solution for Dutch, as we don't have the category "?-gendered nouns per language". Furthermore, I think the whole Dutch category (or header policy) should be deleted altogether or moved to some other category. Thadh (talk) 09:28, 17 August 2020 (UTC)
The Dutch term collega is both common-gender in the sense of the grammatical gendersm and f having merged in the standard lect as spoken in the Netherlands, and epicene. By defining “common gender” to only refer to the grammatical gender when applied to Dutch nouns, we use the ability to identify epicene Dutch nouns. --Lambiam18:27, 19 August 2020 (UTC)
Low German revisited
I'd like to propose some changes to Low German. Feel free to vote under any item. (Note: I'm not married to any of the language code name.)
Split language code into East Low German (Märkisch, Mecklenburgisch-Vorpommersch, East Pomeranian, Low Prussian) and West Low German (Eastphalian, North Low German, Westphalian)
Move all entries under and to and
Make a family code instead, renaming it to Low Saxon (I think that was always the intent, to eventually depreciate as a language code.)
Optionals
Make Plautdietsch an etym-only code for East Low German , moving all entries to , labeling them with {{lb|nds-gle|dialectal|Plautdietsch}}
Make Dutch Low Saxon an etym-only code for West Low German , moving all entries to , formatting them with {{alternative spelling of|nds-glw}}, when needed
I'm not a position to talk about all of these proposals, but I do support splitting the Low German dialects according to linguistic boundaries rather than the political boundary of Netherlands vs. Germany. On the other hand, I oppose merging Plautdietsch in with any variety of Low German that has remained in Germany. Our existing Plautdietsch entries don't seem to reflect this well, but w:Plautdietsch language#Influences and borrowings shows that Plautdietsch has a bunch of words borrowed from languages it's been in contact with (Russian, English, Spanish, etc.), most of which German Low German presumably doesn't have. That's got to be a severe impediment to mutual intelligibility. —Mahāgaja · talk21:45, 17 August 2020 (UTC)
@Mahagaja Plautdietsch and the other East Low German lects share many of the same borrowings, ex. Koss(“goat”) from Polish koza, and Margell/Mejal(“girl”) from Old Prussian mērgā. Conversely, West Low German has quite a few borrowings from North Germanic. Regardless, the same argument could me made for Spanish of the Americas. --{{victar|talk}}23:45, 17 August 2020 (UTC)
Apart from the fact that it is ridiculous to assume that different names for some exotic plants (watermelon and eggplant, as mentioned on the linked Wikipedia article, which aren’t at all staples in Germany) are “severe impediment to mutual intelligibility” – speakers who came back to Germany anyway had to learn names of various material objects that did not exist in the communist backwaters and quickly did so –, I question the mere distinctness of “Plautdietsch” beside the alleged High German “Volga German”. If there are “effects of the High German consonant shift” as exampled on Wikipedia it is all just an Ausgleichsdialekt. (As also true, as I mentioned before, of Transsylvanian Saxon, i.e. the German dialect of Romania, which cannot be mapped to any dialect in Germany.) Many of the features described for the alleged Mennonite Low German are also features of Mennonite High German. Allegedly it is “Low Prussian” but Low Prussian is almost High Prussian. Suspiciously one always compares both to Standard German, Proto-Germanic etc. but never “Plautdietsch” to Mennonite High German. This concept of “Plautdietsch” heavily suffers from selection bias because some of the dialects will be closer to certain Low German dialects in Germany, some more to other dialects and some be more mixed with Mennonite High German, but both “Plautdietsch” and “Volga German” equally influenced by Russian and more influenced by each other than by any other dialects in German. So it would be most appropriate to speak of Low Russian Mennonite German and High Russian Mennonite German, but it would be unclear how to fit them into the trees, as there apparently came out one language by descendance from multiple languages. You aren’t be able to distinguish this Plautdietsch and Volga German if you pick up various returnees in Germany – only various idiolects some more and some less with features pointing to certain Low or High German dialects, but then again all is mixed up –, only if you suffer selection bias by only surveying certain villages in Russia or Canada etc., then with luck some distinctness can be sieved out – but there isn’t if you get and keep an integral picture. The Russian dialects of German are one language descending from all the German dialects from Palatinate German to Low Prussian, like Slovio descends from all Slavic languages and will sometimes be more close to Russian and sometimes be more close to Slovene, short of being more chaotic because of its states not being planned. And like when you can’t tell that an idiolect of Slovio descends from Russian or East Slavic when it is somewhat close to it you very usually can’t tell of a German dialect speaker from Russia whence his dialect descends. Yes, I have heard many of them speaking. The picture is hopelessly blurred. Fay Freak (talk) 10:13, 18 August 2020 (UTC)
Regarding the comment that you can't distinguish lects in returnees to Germany, whose lects have mixed and blurred and adapted towards standard German and/or the prevailing local lects (i.e. you can't distinguish who currently speaks which of those lects in a group of people who no longer really speak those lects?) : the obvious response is that modern mingling and convergence doesn't travel back in time and erase lects' historical (discrete) existence. Great Andamanese languages koineized and creolized as the populations of speakers diminished and were relocated and intermingled, but this doesn't retroactively change their distinctiveness in the past. - -sche(discuss)06:14, 21 August 2020 (UTC)
I oppose absolutely everything about this, as my preferred solution would be to merge every Low German lect (including Middle Low German!) into a single language code with a normalised system and spelling and temporal variants covered with tags and "alternative forms of". The splitting of Low German is what Germans call a 'Glasperlenspiel' (a pontlessly complicated effort that serves no other purpose than keeping those involved busy) hampering the actual usability of this dictionary by disjoining related information without benefit in return. The idea that somehow "East Low German" and "West Low German" exist in such a form that these respective regions differ more from each other than the lects in these regions differ from each other I cannot confirm from my studies. Korn (talk) 20:30, 30 August 2020 (UTC)
@Korn: The heart of what I'm suggesting is merging, but there is a pretty clear delineation between ELG and WLG, both in vocabulary and syntax. I can tell you, as someone coming from a family of Westmünsterländisch speakers, Plautdietsch might as well be High German for as much they understand Low German Mennonites. Normalizing the two into one would be nothing short of artificial shoehorning. For ELG, Plautdietsch would be the main entry space, being the one of the most speakers, and WLG would be Westphalian. I think on that basis, we have a pretty good stage for standardizing orthography. --{{victar|talk}}16:54, 8 September 2020 (UTC)
So name them. Name these differences which differentiate all dialects west of some line from those east of that line while not also differentiating the dialects east/west of this line internally, can't wait to learn something new after all these years. Korn (talk) 20:56, 8 September 2020 (UTC)
@Korn, I can list all the changes Plautdietsch underwent that Westphalian and other WLG dialects did not, if that's what you're asking, but they're nothing the Wikipedia page couldn't already tell you, i.e. palatalization (gistern vs. jistren), diphthongization (ma(a)ken vs. moake(n)), but the chiefly cited division between East and West Low German is syntax, and how WLG generalized -(e)t to the 1-3p plural of verbs, and ELG -en, and the preservation on the present perfect in Plautdietsch. At the very least, we can agree that having separate codes for Plautdietsch and Low Prussian is unfortunate. --{{victar|talk}}03:04, 9 September 2020 (UTC)
You're comparing Plautdietsch and Westphalian. Of course they differ, they're different dialects. Plautdietsch and any other dialect differ, Westphalian and any other dialect differ. Most Westphalian dialects differ no little from other Westphalian dialects. You're talking about some West Low German vs. East Low German and haven't even stated where you want to draw the line between them. But setting aside the irrelevance of your localised examples for the differentiation of West vs. East on a broader scale, even these don't hold up. Palatalisation exists in splotches basically everywhere, including Westphalian, e.g. Lippish where velar fricatives are palatalised unconditionally word initially. (The strong palatalisation of stop consonants is a feature confined to Prussian and Pomeranian, but it's phonetic, not phonemic, so certainly not worth splitting codes over - nor would it be if it was phonemic.) The generalisation of the ending -en exists in multiple dialects on level with or west of Westphalian, e.g. East Frisian. Diphthongisation of /ɔː/ to /ɔˑə/ exists in Southern Westphalian, e.g. around Dortmund. (The lacking merger of /a/ and /ɔː/ is the constitution feature of Westphalian and is not found in dialects either east or west of it.) Incidentally, I think I heard Plautdietsch speakers speak a monophthongised /moːcɘ/ in the past. I see a point to excluding the form of Plautdietsch which is 50% High German, otherwise I fully stand by what I said. Even if all your examples were neatly distributed along some east/west divide, they're minuscule and no basis to split codes on. If we worked like that, we'd have a separate code for every bloody village. Korn (talk) 08:07, 9 September 2020 (UTC)
tlb template
I edited outsuave to remove the {{tlb|en|rare}} at the end of the sense line. I had two reasons: one was because I disputed that the term was rare (which is clearly subjective and I don't want to argue over that), and the other was that the term label is almost invisible at the end of a verb's headword line:
outsuave (third-person singular simple presentoutsuaves, present participleoutsuaving, simple past and past participleoutsuaved)(rare)
Are any of our readers actually going to spot that tiny label hiding there at the end of the lengthy, and generally completely ignorable, headword line? I'd be very much in favour of placing the label at the start of each sense, like we have traditionally done. This is especially so in an entry like outsuave with only one sense; there is a clear disadvantage to using the {{tlb}} template with no added benefit. This, that and the other (talk) 01:59, 18 August 2020 (UTC)
@This, that and the other: About the “rare” label: all of the suitable uses I found have been added as quotations, including the only use on Usenet.
The documentation for {{tlb}} states it is used directly after a headword line: “This template takes the same parameters as {{label}} ({{lb}}), but is used directly after a headword line, not in a definition.”
I suppose that the point is to avoid repetition. If there is only one sense, there is no repetition to be avoided repetition. --Lambiam17:50, 19 August 2020 (UTC)
Yeah, it's a messy situation. :When I created the template (as Template:term-context, in the era of Template:context), I envisioned it as enabling a distinction between e.g. entirely archaic words/spellings vs still-common terms with a single archaic sense, and as enabling not having lengthy non-meaning-specific labels like "American spelling" or "British spelling" in front of all the meanings of especially a highly polysemous word with other labels like ]. But it is easily missed if placed at the end of the headword line, especially of a word with only one or two senses. I don't know where else it could go, though, on entries where it's appropriate to use. - -sche(discuss)08:01, 20 August 2020 (UTC)
I think that makes total sense, as some labels can be fairly lengthy and tedious if repeated in front of every sense. But if a label is short, {{term-label}} probably doesn't need to be used. — SGconlaw (talk) 08:57, 20 August 2020 (UTC)
This is true, and theoretically we should make that distinction... (or we should discuss whether to give up on that as an unmaintainable project, and resign ourselves to the fact that technically a term with only rare senses (or one one sense, which is rare) is still a "term with rare senses"...) - -sche(discuss)11:18, 20 August 2020 (UTC)
It's tempting to suggest using {{tlb}} on the sense line in cases like this:
which is hardly ideal. In my mind, the imperfect categorisation is a lesser issue than presenting the entry such that all information can be easily found by the reader, so I'd prefer to format it as
# {{lb|en|transitive|rare}} To douse with phlogiston.
To @Rua, Benwing2, Atitarev, Fay Freak, Erutuon and whomever is interested: I'd like to create a template and categories to cover cases such as Frenchentretien and Russianпризы́в(prizýv), which were obtained by subtracting a morpheme (with or without ablaut).
I had created {{deverbative}}/{{deverbal}} to that end, but someone (I think it was @Mahagaja) observed that deverbatives/deverbals are simply words derived from a verb; it doesn't say anything about the morphological/derivational process at work (and indeed, the template was used at убо́рщик(ubórščik), for example).
Not bad. Would leave us {{deverbal}} for noncatenative derivations, since it is not clear yet how to use {{transfix}}, as @RichardW57complained not a month ago. But whither would you link? You cannot link to a negative string. Somewhere you would like pages to describe these disfixes, with different functions (with different ids for them by which they are categorized, though at least the template use part is clear. With {{transfix}} having a different linking issue I do not even know what to supply to the template. An exampled explanation is at Wiktionary:Beer parlour/2017/January § Arabic consonant patterns. You would clearly have some sign for the nothing, with IDs if applicable, and probably one place for the negative, whereas with transfixes there are multiple ways to visualize them and places to link to, in contrast. Though perhaps to find this one place is even harder. Erutuon says there it is “unnecessarily biased against nonconcatenative morphology to not have the patterns described in the main namespace” which is most likely true so I guess the disfix page would also need a mainspace page.) Fay Freak (talk) 16:12, 18 August 2020 (UTC)
Hmm, I didn't remember that I said that so definitely. I wouldn't be opposed to putting consonant patterns in appendices now. Some readers could be confused about the placeholder consonants if the patterns are in mainspace. — Eru·tuon18:26, 19 August 2020 (UTC)
Re "whither would you link": am I missing something, or what about just (for "призыв") "from призывать, by removal of ''-ать", with a parameter to suppress linking of the last part if it were not itself entry-worthy, so that foob might say "from foobar, by removal of -ar" with no link? Linking to a page that explained disfixing would also work. - -sche(discuss)11:10, 20 August 2020 (UTC)
@Einstein2: I hadn't thought of that. But although there's indeed a great deal of overlap, not all back-formations are disfixations: see décontenancer, signaler, insignifier, where a whole paradigm was created out of (what was seen as) a non-lemma form. PUC – 11:18, 20 August 2020 (UTC)
I think those could (should) still be considered back-formations. I think there are English words back-formed from plurals (and labelled as back-formations). This requires more thought, though, as to whether there is a type of entry which is a product of disfixation but not back-formation, or whether we would simply prefer to use the word disfix for some cases for some other reason... - -sche(discuss)11:27, 20 August 2020 (UTC)
@JohnC5, Rua, Victar, AryamanA Do y'all have any idea about the placement of the accent in this word? I don't know anything about Balto-Slavic accentuation but it looks to me as if Slavic and Greek disagree with respect to the accent. The Greek and Slavic sources give the form without accent (the Slavic dictionary actually gives *h₃migʰlh₂) but can a word just be unaccented like that? In my opinion, this word was best left at the original root entry and a separate entry was not really required as there were only 3 descendants. Note also that in the original entry the descendants were sourced but they were removed and moved to this entry, this time without any sources. It isn't a big deal as the sources can be added right back away but I think if we cannot determine the accent, it'd be better if we left this information in the main entry. -- Bhagadatta (talk) 03:27, 19 August 2020 (UTC)
@Bhagadatta Even if you change something in the form, the Balto-Slavic stress will not change (these laws are not Balto-Slavic, but descendants). I would quote Beekes' reconstruction as a curiosity. Although this is my favorite Indo-European linguist. But I do not forbid you to fantasize. xD Gnosandes (talk) 17:58, 25 August 2020 (UTC)
Is it possible to ask the people whose voices are on pages pronouncing, say, the infinitive of a Russian verb, to also record declination sounds? Or the declension of a noun? A participle? Etc?
They have great voices and know the language, so I wouldn't do it, but I think the code infrastructure is present...
You can click the menu button on an audio file to see the uploader ("author") and leave a message on their talk page to see if they're interested in recording more. Ultimateria (talk) 04:22, 20 August 2020 (UTC)
Categories - English agent nouns that existed previously?
While looking at the English agent nouns category page, I noticed that 'curator' wasn't included. After doing some investigating how I might add it, I noticed that the normal formatting for it 'agent noun of|en|curate', wouldn't fit since it's not a new form in English, 'curator' having existed in Latin.
But seeing as it is an English agent noun I was wondering what policy would be on including such words in this category?
Since it's used in definition lines, not etymology sections, it doesn't matter IMO that the term wasn't coined in English. It functions in English as the agent noun of curate, and that's enough. Note, however, Wiktionary:Requests for deletion/Others#Template:agent noun of, where Rua argues that the template shouldn't be used at all and straightforward definitions should be used instead. But in the year and a half since that RFD was opened no one else has commented on it. —Mahāgaja · talk07:19, 20 August 2020 (UTC)
Re whether to put the word in the category (sidestepping the question of whether to use the template): my initial reaction was that it would be fine. However, I notice both ] and w:Agent noun insist the noun must be derived from a verb, and we did just have some discussions about using other words, like eye dialect, only in their strict sense, so, IDK. - -sche(discuss)11:13, 20 August 2020 (UTC)
OK. I admit at the time I wrote the above I didn't realize that the verb curate is a back-formation from the noun curator, nor that the verb is currently defined as "act as a curator for", which means reducing the definition of curator to {{agent noun of|en|curate}} would result in a circular definition. I still don't see anything wrong with manually adding {{cln|en|agent nouns}} to the entry, though. —Mahāgaja · talk07:42, 22 August 2020 (UTC)
Wu Dialects
I've recently been adding Suzhounese vocabulary. One problem I've run into is that Wu readings automatically default to Shanghainese phonology and its tone sandhi system. Is there a way of incorporating Suzhounese readings, and those of other Wu dialects? — This unsigned comment was added by Fluoromethyl (talk • contribs) at 15:54, 21 August 2020 (UTC).
@Fluoromethyl: The code at Module:wuu-pron is designed specially for Shanghainese. We would need new code designed for Suzhounese.
@恨国党非蠢即坏, Geographyinitiative: Edit warring is unacceptable (on both ends). You two should have talked it out way earlier. The edit summaries should also be used to communicate the problems with the edits. Reverting without explanation doesn't make it clear to the other side what is wrong with their edits. — justin(r)leung{ (t...) | c=› }09:42, 22 August 2020 (UTC)
It is clear that a link helps the reader understand the concept further. But I can understand others may not agree. I don't plan to edit the page again. I'm not really familiar with the term and its usage. The way the page is now is just fine anyway. Sorry for causing trouble. I just wanted a link there. But it is not that important. Geographyinitiative (talk) 10:05, 22 August 2020 (UTC)
@Geographyinitiative: From what I can see, the reason for the revert was that you linked to the wrong place, which is probably even worse than linking. Also, the wording of "Chinese character title" is quite stilted. I don't think anyone is against linking if it's linked properly. — justin(r)leung{ (t...) | c=› }10:16, 22 August 2020 (UTC)
I don't plan to edit the 战狼 page anymore. I want to work with others to edit the dictionary, not get into internet fights. The edit I wanted is not important, and I don't want to interfere with other people's creative viewpoint on the dictionary. I tend to add too many links and view character readable in Chinese languages and Japanese etc as characters, not just 'Chinese'. My mindset is Traditional characters as default. But I don't want to fight over that kind of minor stuff. I wash my hands of it, unless there is a penalty I need to undergo. Geographyinitiative (talk) 10:18, 22 August 2020 (UTC)
It's more the browser's job than every individual site's job to provide colour sets. Perhaps you could create (or find) a custom stylesheet, or accessibility settings. The old Opera browser was very good with applying custom colours to sites but they probably removed that feature when Opera got ruined and dumbed down. Equinox◑13:43, 22 August 2020 (UTC)
Many popular sites start to have night/dark mode for their members, like Twitter, Facebook, YouTube. Why don't we have it yet? --Octahedron80 (talk) 03:30, 23 August 2020 (UTC)
It might have something to do with them being giant corporations with dedicated employees hired to work on the UI, versus us being a not-for-profit website entirely run by volunteers. Just a hypothesis. —Μετάknowledgediscuss/deeds03:34, 23 August 2020 (UTC)
One must analyze the sentence rather than memorize a list of common linking verbs. Often unexpected candidates serve as linking verbs—e.g.:
• “The rule sweeps too broad.” (The writer intends not to describe a manner of sweeping, but to say that the rule is broad.)
• “Before the vote, the senator stood uncertain for several days.) (The word describes not the manner of standing, but the man himself.)
A similar issue arises with an object complement, in which the sequence is —e.g.:
• “Chop the onions fine” (The sentence does not describe the manner of chopping, but the things chopped. The onions are to become fine .)
• “Slice the meat thin.”
An elliptical form of this construction appears in the dentists’ much-beloved expression, Open wide (= open your mouth wide)
However, I find it contradictory that dictionaries include an adverbial meaning with the adequate sense for fine and thin, as well as the adverbs in -ly for phrases such as thinly-sliced ham or finely chopped herbs (oed.com/oed2/00251139 ; oed.com/oed2/00251175; oed.com/oed2/00084909; oed.com/oed2/00084930).
Collins has both adverbs Thin(ly) with the same meaning.
THIN (adverb): in a way that produces a thin piece or layer of something, I like my bread sliced thin.
The adverb tight includes specific grammatical points: ahdictionary.com or oxfordlearnersdictionaries.com.
If morphemes may be perceived by speakers of a language though pairs of words borrowed from another language, but we generally adopt the pattern of only presenting the etymology of an attested source word at the source word's entry, may we record such a borrowed word as containing the morpheme? Can the morpheme be given an entry? WT:CFI seems to say that mere morphemes don't qualify, but we nonetheless have plenty of prefixes and suffixes on Wiktionary. --RichardW57 (talk) 17:03, 23 August 2020 (UTC)
English is full of such pairs of borrowed words and indeed families of words derived from Latin or French, but the application I have in mind is the less productive Thai morpheme ำน, which appears in borrowed pairs such as เดิน(dəən, “to walk”) and ดำเนิน(dam-nəən, “procession (verbal noun)”), but has been applied to derive only a very few words from 'native' words, such as สำเนียง(sǎm-niiang, “sound, phoneme”) from เสียง(sǐiang, “sound”). If we are allowed to record ำน as a constituent of ดำเนิน(dam-nəən), how should we do it? My preferred method is to add a note such as 'synchronically analysable as เดิน(dəən, “to walk”) + ำน' to the etymology, which automatically puts the word in the corresponding category. (@Octahedron80 would appear to demur, saying that Thai doesn't have the concept of an infix, but merely mimics Khmer. We consequently have a potential edit war over the etymology of สำเนียง(sǎm-niiang), which would be particularly bad if it interfered with the outstanding work of translating the information on the etymology to English.) --RichardW57 (talk) 17:03, 23 August 2020 (UTC)
Colloquial Pali
My views on this are coloured by the assumption that Wiktionary is intended to be useful (for languages other than Sanskrit), except where we consider it more important to be correct. In particular, we want someone who can read English and can split text into words to be able to look those words up without having to retype them. --RichardW57 (talk) 17:39, 23 August 2020 (UTC)
I have become aware of a minor variation in the abugidic Thai script spelling of Pali. While higher quality publications fight to use the sequence <U+0E34 THAI CHARACTER SARA I, U+0E4D THAI CHARACTER NIKHAHIT> for Roman script "iṃ", most material (about 99%) on the web has given up the fight (which I think began with Windows XP enabled for complex scripts) and just uses <U+0E36 THAI CHARACTER SARA UE> instead. There are also dead trees that use SARA UE, which happens to be currently leading 3:0 in quotations on Wiktionary. I think we should go with the former as the 'standard' form, but how should the other form be tagged? Is it appropriate to tag the forms using SARA UE as 'colloquial'? The overwhelming volume of Pali text on the web is long-established text; I'm not aware of any chatter in Pali. (There is a Pali wikipedia, but that seems to all be in Devanagari.) --RichardW57 (talk) 17:39, 23 August 2020 (UTC)
Richard, these long, hyper-specific posts of yours aren't getting any traction, so I'll give you one piece of advice and two recommendations: 1. This probably isn't BP material. 2. We have a glossary of terms we use in the dictionary; look up "colloquial" there and you'll see it doesn't match what you describe. 3. There's barely a Pali editor community. If I were you, I would make a Pali-specific template to handle this spelling variation (an analogue of {{yi-unpointed form of}}) to point the less common form to the more common one, but I think you already knew that you should do that, so none of this was necessary. —Μετάknowledgediscuss/deeds15:26, 25 August 2020 (UTC)
@Metaknowledge: It isn't obvious where else I should have raised the issue. "Informal" is the only term there which might be better at capturing the stratified nature of the usage. However, your technical solution does kick the question into touch for grammatically simple words - the template can be used to centrally improve the wording if people don't like it. So it's a good solution. Thank you. Perhaps we simply impose more levels of indirection for grammatically complex words before one reaches the detailed glosses. Would a less inflammatory version of "pi-Thai-workaround for" be a sensibly named template? French and Romanian have both suffered from comparable spelling distortions because of subtly less-than-ideal computer support, but I've had no suggestions from that direction. --RichardW57 (talk) 18:40, 25 August 2020 (UTC)
The major use of the labelling will be footnotes for inflection tables. I have plans for the relevant footnote to be centralised so it too can be centrally reworded. --RichardW57 (talk) 18:40, 25 August 2020 (UTC)
I'd recommend the Information desk or a more informal venue like Discord, but I guess I was saying that you should be bold and go ahead with your ideas unless there is disagreement or conflict. Inherent in that is centralising your text, so that if someone does disagree, it will be easy to fix. —Μετάknowledgediscuss/deeds18:49, 25 August 2020 (UTC)
Entries for Arabic inflection forms
Which Arabic inflections forms should have separate entries?
To start with, I think there should be separate entries for the indefinite singular masculine accusative of nouns since most (but not all, a counter example being ماء) have an extra alif at the end distinguishing them from the nominative and genitive forms. I am interested in creating a bot to perform this task of page creation. If there is consensus, I can give a more detailed plan. Kritixilithos (talk) 12:50, 24 August 2020 (UTC)
A bot would have to be very carefully safeguarded; @Benwing2 has experience running an Arabic inflection bot and the difficulties therein. If you make a bot, you can run some test edits and then create a vote. —Μετάknowledgediscuss/deeds00:41, 27 August 2020 (UTC)
@Kritixilithos, Benwing2, Metaknowledge: Firstly, I don't think it's a good idea to create separate entries for terms with the same title but different diacritics, such as مَاءً(māʔan). Secondly, this word doesn't receive an alif in the accusative indefinite, since it ends in a hamza, so the declension is correct. It's unlike كِتَابًا(kitāban), which does receive an alif in the accusative indefinite of كِتَاب(kitāb). --Anatoli T.(обсудить/вклад)01:16, 27 August 2020 (UTC)
@Kritixilithos, Metaknowledge Beware that when creating non-lemma entries, there are a lot of special cases to handle. You have to handle e.g. creating an Arabic section when there is none, doing nothing when the entry is already present, potentially adding an entry in the same etymology section (we generally group etymology sections by pronunciation for Arabic), creating a new etymology section, etc. I have an existing script to do this for Arabic verbs, participles, verbal nouns, etc.; it runs to 2,324 lines of Python, not counting utility modules. You probably don't need all the complexity in this script but I estimate your script has to be at least 600-700 lines to handle all the cases properly. If you're not comfortable writing and debugging scripts of this length, I wouldn't consider this task. Benwing2 (talk) 04:38, 27 August 2020 (UTC)
@Kritixilithos Feel free. It sounds like you have enough programming experience to be able to take on a task like this. The warning is just to make it clear that this isn't a trivial task, basically to scare off newbie programmers who don't have the mindset to handle all the edge/corner cases properly. You also have to be able to clean up mistakes if they happen (which they probably will, eventually). For example, there was a bug in the handling of certain 2nd masculine plural subjunctives and jussives in Module:ar-verb (which I wrote), see . Basically, I forgot a silent alif in one place. The code in this module was used to generate non-lemma entries for several thousand verbs, so I had to write another script to clean up the mess, moving the misspelled pages to the properly spelled pages if that was possible without messing something up, otherwise removing the misspelled form from the page. This removal wasn't trivial: you might have to remove one line, one entry, one whole etym section or the entire page, and when removing an etym section, if you're left with only one, you have to deindent the etym section, since pages with single etym sections are indented less than pages with multiple etym sections.
BTW the github page you link to above is way out of date; if you're interested I'll push my more recent code to that page. Benwing2 (talk) 08:38, 27 August 2020 (UTC)
@Benwing2: Noted. Sure, I would be interested in your recent code. Even if I choose to write a bot anew, I can still refer to your program to know what things to handle. Kritixilithos (talk) 09:06, 27 August 2020 (UTC)
“we generally group etymology sections by pronunciation for Arabic” – we of course group by etymology. Having a new etymology section for each pronunciation, or only to have pronunciation sections, is annoying (sometimes even followed by the identical reference sections for each etymology, which is even more distracting). Page layout should not depend on the pronunciations, it’s not what to structure around. It is probably easiest to put all inflections and non-lemma forms (including verbal nouns, which are categorized as lemmas) into one etymology section {{nonlemma}}, even though even that is often superfluous if etymology 1 is only ”from the root XYZ” and the non-lemma forms are also from that root. Fay Freak (talk) 10:45, 27 August 2020 (UTC)
"Translations" of surnames
An anon has created a number of entries where they add an English and in some cases French entry for a Finnish surname, see e.g. Tikkanen. The names so far added seem to belong to famous sportsmen and it is clear that a lot of usage can be found in many languages, but does that make "Tikkanen" a French, English, German, Swahili etc. word? What do we think about this? --Hekaheka (talk) 15:05, 24 August 2020 (UTC)
Many of the more common English surnames have reasonable translation tables. See Smith as an example. Though I'm pretty sure that "Tikkanen" is not an English surname (only half a dozen entries) on . (for comparison, the same source has nearly 4,000 entries for the Italian surname "Rossi). SemperBlotto (talk) 15:10, 24 August 2020 (UTC)
It is the name of a US horse with an entry on Wikipedia, though. The problem is that some of these entries may be useful. One may want the translations for translating information about a sportsman to another language - perfectly legitimate. Some might miss the Thai forenames - how do you inflect Somchai in Russian? The information doesn't have to come through formal translation - one can just track the descendants of the surname in the original language. If Wikimedia's truly not going to run short of storage space, then we have two filtering criteria:
Notability - is there an entry on the English Wikipedia? Do we need to raise the bar beyond that? Do we use different languages' wikipedias?
Reliability - three quotations or whatever.
We have the same issues with all essentially multilingual entries - per language pronunciation, and per language grammar (mostly inflections).
Transliteration also raises its ugly head and it may be useful to know what the standard transliteration is - even if we don't like supporting tattoo creation.
As for flooding the Roman script pages, my feeling is that the scheme of all languages on one page is only going to fail more and more as we extend our coverage of ordinary words. --RichardW57 (talk) 16:02, 24 August 2020 (UTC)
Well, footballers' names do tend to get mentioned a lot, especially if they play for the national team, as Patrick Reichelt does. I could rattle off the names of half-a-dozen Thai pop stars with British surnames - but they're not an issue as we have rules against Thai names and as Thai words they should probably be in the Thai script. I must admit Nolan looks more like a forename than a surname. However, Cebuano on its own is not a flood - it's only one entry per page. For how a flood can develop, see Habsburg, and note the Hungarian inflections. These all have some way to go before they get as bad as Anna or Roma. Fortunately, capitalisation will mostly keep proper names to their own pages. Pity the word meter, with no protection from the SI system. --RichardW57 (talk) 20:29, 24 August 2020 (UTC)
There were five cases, all of them ice hockey players who have played in the NHL: Selänne/Selanne, Lumme, Tikkanen, Koivu and Kurri. I have done the following:
kept Tikkanen and Koivu as English (and of course Finnish) entries because according to the US Census a few hundred persons with each surname live in the US
But do they live in English-speaking parts?
kept the English and French sections of Selanne, because it is used as alternative spelling of Selänne in those languages
deleted the English and French sections of Lumme, Kurri and Selänne because a) they don't seem to be used as surnames in either language and b) as such the entries provide little if any value
I find it ultra vires, and totally misses the point that for a name to be a surname in a language it is not necessary for it ever to have been borne by someone who speaks that language. Putin is a surname in English, even if it have only ever been borne by people who live in Russia. --RichardW57 (talk) 13:58, 25 August 2020 (UTC)
What is the problem with how things are developing at present? Is it for example that German nouns risk being buried in a flood of copies of a proper noun? Is it that a page can't support, say 50 inflection tables? This seems different to the case of letters, where I suspect hordes of alphabet lists are part of the problem, but one page can probably handle the letters of an alphabet. --RichardW57 (talk) 20:36, 25 August 2020 (UTC)
Perhaps we should consider the following cases:
An inflected name used in Latvian. Perhaps the Afrikaans name Smuts would be a suitably challenging example, as many languages would use the same form, whereas most names are changed by being borrowed into Latvian.
A foreign surname used in Russian.
A foreign name as used in Chinese.
A foreign name in Hungarian.
While I like the idea of making these names that are naturally the same in dozens of languages formally 'translingual', how do we record the language specific aspects? They are pronunciation and inflection once they have stabilised, and sometimes other details, such as gender and number. In some languages, they may be instantaneously stable. Can we document inflection via a set of rules for each language? English inflection is fairly simple; other languages' is not. How do we handle pronunciation? One partial solution may be to exile localised aspects of a translingual name to an appendix for that name; that would declutter the table of contents for the original page. For the eternal city, would Rome and Roma both be translingual? --RichardW57 (talk) 20:36, 25 August 2020 (UTC)
I have originally created a page-specific discussion on this topic, but after seeing more of this kind I have decided to open one here. I don't understand the point of such a difficult diacritical representation of the pronunciation. Isn't that why we have the header ===Pronunciation===? And personally, I think the IPA is a far more effective way to show the pronunciation than to change the header from "båssjo" to "bå̄sˈsjo" (or something in that style). I have hidden these transcriptions (two now) for the time being, but the Proto-Samic reconstruction pages seem to favour these writings as well, and that made me doubt my approach. Thadh (talk) 13:46, 26 August 2020 (UTC)
The Wikimedia Foundation will be testing its secondary data centre. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.
They will switch all traffic to the secondary data centre on Tuesday, September 1st 2020.
Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.
You will be able to read, but not edit, all wikis for a short period of time.
You will not be able to edit for up to an hour on Tuesday, September 1st. The test will start at 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday September 2).
If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.
Other effects:
Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
There will be code freezes for the week of September 1st, 2020. Non-essential code deployments will not happen.
This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. Please share this information with your community.
Is it appropriate to change {{descendant}} to consider derived terms not just from the addition of morphemes but from the removal of morphemes too? Otherwise I'm not sure how to classify e.g. Armenian words derived from Russian words ending in -ный where that syllable is dropped in Armenian. It's a big enough difference that I don't think they're direct borrowings. Ultimateria (talk) 18:23, 26 August 2020 (UTC)
@Tooironic: The category is automatically generated if, at least one hanzi spelling is red-linked. So, it's valid and not obsolete. Do you have an example in mind? The other thing is, those spellings needs to be valid.
TBH, I think working on multisyllabic pinyin entries is a waste of time, IMO, multiword entries, like ], especially. Terms can be found without them. I suggested to suppress pinyin links on multiword entries such as 便利商店 (biànlì shāngdiàn). --Anatoli T.(обсудить/вклад)00:44, 27 August 2020 (UTC)
Ah, I see. Multisyllabic pinyin entries (yìyì, shìshí, etc.) should definitely be kept as they can be used to cross-reference our entries with those of other dictionaries. They are also helpful for users generally. As for "multiword" pinyin entries, do you mean pinyin entries with spaces in them? ---> Tooironic (talk) 01:11, 27 August 2020 (UTC)
@Tooironic: Yes, I mean pinyin entries with spaces in them, the simplest way to identify "multiword" entries. They don't really help to disambiguate anything, just filling red links. I think User:Justinrleung supports this but I don't remember where I asked him about it. --Anatoli T.(обсудить/вклад)06:35, 29 August 2020 (UTC)
That makes sense. We would need to put it to a vote though wouldn't we? Plus we'd need a bot to deal with the mass deletion of the entries. ---> Tooironic (talk) 06:41, 29 August 2020 (UTC)
@Justinrleung, Tooironic: @Justinrleung: It's understandable but you're not editing in pinyin either. Maybe it will become important later, as it was the case with pinyin capitalisations? I am personally annoyed when translations hyperlink pinyin romanisations, as if it's some kind of alternative script, like this: 便利商店(biànlì shāngdiàn).
@Tooironic: Thanks. A minivote would do, IMO (pro/contra/indifferent). Technical solutions may be requested later, when there is a general agreement. Finding pinyin entries with spaces must be a simple task. --Anatoli T.(обсудить/вклад)06:58, 29 August 2020 (UTC)
@Atitarev: I think it'd be safer to suppress links altogether for separate words because there maybe instances where the parsing may not be right (e.g. a suffix attached to multiword phrase, like 美術史學家). — justin(r)leung{ (t...) | c=› }07:21, 29 August 2020 (UTC)
Currently, translations of the numbers that have short and long scale definitions (billion and higher) are on two entries—the entries for the number in the short scale and the long scale. To avoid duplication, the translations should be in one entry—either the entry for the number in the short scale or the long scale. J3133 (talk) 09:03, 27 August 2020 (UTC)
The words for the short scale are always used in the long scale, so these will have to stay entries, so what you are proposing is prioritising the short scale over the long scale. Thadh (talk) 09:34, 27 August 2020 (UTC)
I'm sorry, I thought you meant keep the entries. My bad. I don't know if the long/short system is English-specific though. Thadh (talk) 10:02, 27 August 2020 (UTC)
Most languages don’t have similar ambiguities. If English billion is used in the sense of 109, translating it into French as billion, which can only mean 1012, is wrong. This is not very different from translating English spring in the sense of the season following winter by ressort, which is a good reason for having seperate translation tables for different senses of the term. --Lambiam14:45, 27 August 2020 (UTC)
@Lambiam: You do not understand; I am not opposing “having separate translation tables for different senses of the term”. I am opposing having to duplicate all of the same translations (for the same sense) on two entries. J3133 (talk) 14:58, 27 August 2020 (UTC)
So could you describe in a positive way, preferably illustrated with a concrete example, what the change is you would like to see, instead of telling us what you don't want? --Lambiam16:00, 27 August 2020 (UTC)
@Lambiam: Could you describe what specifically is it that you do not understand? I do not understand what are the points that you are trying to make and they do not seem to be in a positive way. J3133 (talk) 16:07, 27 August 2020 (UTC)
@Lambiam: J3133 refuses to explain, but the problem is that, for example, there are translations for the sense 1012 at both billion (long scale) and trillion (short scale). The proposal is to have just one translation table for 1012, at either the short-scale or the long-scale entry. — Eru·tuon19:54, 27 August 2020 (UTC)
So should one of the two just give up its translations altogether (but J3133 denies that this is what they want), or should it refer the user to the table at the other lemma, like in the form “a million million; 1,000,000,000,000 – seetrillion” (but J3133 also denies that that is what they want)? I only see statements about what they do not want, leaving no room for a solution. --Lambiam20:07, 27 August 2020 (UTC)
What I was actually speaking of is, for example, Russian: it has both the terms биллион(billion) and миллиард(milliard). While indeed, both of these could be put together into one translation hub, another approach would be giving these at billion and milliard respectively. Surprisingly, though, this doesn't yet happen, so indeed I agree with your proposal. Thadh (talk) 16:36, 27 August 2020 (UTC)
According to the Collins Cobuild English Usage, page 561
Three-syllable adjectives formed by adding 'un-' to the beginning of other adjectives, for example unhappy and unlucky, have comparatives and superlatives formed by adding '-er' and '-est' as well as ones formed by using more and most.
Restrict the use of UCLA Phonetics Lab Archive transcriptions
The UCLA Phonetics Lab Archive hosts word lists with recordings and phonetic transcriptions for a variety of languages. The recordings of native speakers are likely always of value for those interested, but transcriptions have to be accurate before they are useful.
There have in the past been instances where the UCLA Phonetics Lab Archive was used as a reference for adding transcriptions.
It is clearly the case that some of the transcriptions in the archive are inaccurate. The transcriptions for Bura do not indicate tone, although it is a tonal language. In the Swahili transcriptions, stress is shown with a high-tone diacritic, even though Swahili is not a tonal language. The Dutch transcriptions contain a high number of errors and notational inconsistencies, such as and for <te> and <de>, transcriptions with aspirated plosives and inconsistent use of versus .
So for some of the languages there are serious errors in the transciptions. Even if the transcriptions for other languages are in a better state, the inconsistent quality makes the archive's transcriptions unreliable. So I think that at least some restriction on their use is in order.
I'd suggest three alternative options for restricting those transcriptions:
Universally ban the use of UCLA Phonetics Lab Archive transcriptions.
Generally ban the use of UCLA Phonetics Lab Archive transcriptions, but editor communities may allow their use on a per-language basis.
Allow editor communities to ban the use of UCLA Phonetics Lab Archive transcriptions on a per-language basis.
Naturally, none of these options would disallow editors to transcribe the recorded words themselves.
2600:1:B16F:FBD6:614A:6793:6071:321D has been systematically (and ineptly) converting all the entries for the small kana used by Ainu from Translingual to Ainu. They corrected their mistakes in the one entry they were reverted on, but the rest still have a mix of Translingual and Ainu templates and categories.
@Eirikr and Alves9 have been debating (and talking past each other) about approaches to the language in RFV-N and the Tea Room
@Siljami posted a quite legitimate question at Category talk:Ainu adjectives about whether Ainu adjectives are really stative verbs. This question was discussed in 2013 and everyone seemed to show support for the stative-verb approach at the time.
Sijami mentioned that attempts to change Ainu adjectives to stative verbs have been reverted in the past , while Wiktionary:About Ainu lists 7 parts of speech- which don't include "adjective".
The impression I get is of several people working independently on the language and setting up parts of the infrastructure, but no community. If memory serves, User:BenjaminBarrett12 (who set up the original useless About page) was the main person working with the language in my early days as an admin, but he hasn't been around since 2015. Category:User ain contains only Category:User ain-1, which is empty. Both were created automatically, and nothing links to them except the automatic link from Category:Ainu language.
Is there any way we can get everybody on the same page and have Wiktionary:About Ainu functioning as a reflection of community consensus, rather than as something irrelevant to most editors in the language? Chuck Entz (talk) 00:10, 29 August 2020 (UTC)
I'm not sure if there was ever any debate surrounding this, but Kana is an awful system for representing Ainu. If we can all agree to mainly use Latin from now on many divides that have appeared because of it will vanish. If we can get that right, I'm positive the About page will look beautiful in no time (provided there aren't any stubborn reverters!) And forgive me if I am wrong, but aren't Japanese "adjectives" also, in fact, verbs? It's a convenience term, I believe. Alves9 (talk) 01:32, 29 August 2020 (UTC)
What script to use is a side issue. How is it an obstacle to arriving at a larger consensus? As for Japanese, that's a matter for the Japanese community, who have their own conventions about part of speech. Let's keep the focus on Ainu. Chuck Entz (talk) 02:00, 29 August 2020 (UTC)
An user has been making quite an issue over whether it should be half-width ィ should be full イ in one place, ㇻ be ラ in another, etc., issues that would not arise if Latin was the predominant system. Also, I am sorry to say, a great deal of Ainu entries are just plain incorrect because someone happened to enter a big kana instead of a small one, since they represent two very different sounds (in fact, that's probably most of the ones taken from Mr. Batchelor's material). I thought you would know as, it seems, you have been following our discussion closely. Alves9 (talk) 02:11, 29 August 2020 (UTC)
Automatic transliteration should be probably made functional as soon as possible if Kana entries are expected to be added at a large scale at any point (either that or abandon Kana completely).
All Ainu language materials that I have make the approximation of stative verbs to adjectives, the same way it is made in Japanese: Both Kindaichi and Chiri make a distinction between verbs and adjectives, although they both note that such a distinction is not required from a functional point of view. Kindaichi says that adjectives (...) are similar to the category of adjectives in Japanese. , Chiri says "The difference between verbs and adjectives in Ainu is very slight, semantically the former express acts, while the latter express properties, and functionally the latter have no imperative form -- that is all. There is no morphological difference whatsoever." (Refsing, 1986)
Batchelor does not even mention anything close to the concept of a stative verb (he does, however, curiously point out that some adjectives seem to be just verbs with some variety of prefix). And so it's clear the difference is very insignificant. In general, I think taking a more practical and less pragmatical approach to Ainu is would be best, as it is still more or less a living language, and with a great abundance of material at that.
Ainu may not be standardised, but, based on sheer quantity of material and the fact that Ainu Times is monolithically Saru, it's clear the Saru (Biratori) dialect is the predominant one. It should take priority in most situations. Alves9 (talk) 12:08, 29 August 2020 (UTC)
Actually I made automatic transliteration from Kana to Latin (and also I have my local version of vice versa, though i didn't remember if I uploaded it, there are also some other templates and modules I made) fully functional in Japanese Wiktionary (ja:テンプレート:ain-kana-conv) and migrated a version from there to here (maybe needs to be updated). But since I don't think there is enough community and rules, especially currently we are using a mix of Kana and Latin which is quite not happy work with then. So I decided to focus on Ainu dictionary in Japanese Wiktionary. I (and maybe some other personnel) clarified the rules and build the automating/manual template infrastructure as well as added some words.
From what I see, almost all of newer materials from 2000 to now, except some material intended for Basic Ainu for Japanese People, most of them are using Latin as the main script which has a lot of advantages. Especially I have never seen an academic paper or a dictionary without latin transliterations. Before I started contribute at Japanese Wiktionary, it's interesting that almost no lemmas are in Kana, rather all of them are in Latin and some with the manual transliteration there, but here in English Wiktionary it is a little bit unclear, most of existing lemmas using Kana and some with Latin transcription, the others are not. Anyway, I think it is necessary to be consistent whether we settle on Latin or Kana as the lemma. -- Mkpoli (talk) 06:20, 30 August 2020 (UTC)
Latin audio files
A lot of the audio files for classical Latin aren't accurate. They don't have nasalization or different vowel qualities for short vowels. The long vowels are also like three times as long with unnatural intonation. Dngweh2s (talk) 15:35, 29 August 2020 (UTC)
Classical Latin is a dead language and as such, it should not provide audio files. Few people are able to correctly pronounce Latin due to the Classical Latin phonology. Thus all inaccurate audio files for Classical Latin must be removed, as well as for any language. Ecclesiastical Latin audio files are authorized as it is still alive. Can you provide some examples ? Malku H₂n̥rés (talk) 15:50, 29 August 2020 (UTC)
You're talking about the ones by @EncycloPetey, right? They do sound really unnatural, and have mistakes even within the context of how Americans normally pronounce Latin. Unfortunately, Wikimedia Commons is unlikely to agree to removing them unless EncycloPetey himself requests it. —Μετάknowledgediscuss/deeds16:43, 29 August 2020 (UTC)
Perhaps a solution is to have a discussion with the Wikimedia Commoners about this, to see if they can be more flexible with the deletion of such incorrect files. --Java Beauty (talk) 16:45, 29 August 2020 (UTC)
Maybe @Dngweh2s can just comment them out, because bots aren’t programmed to parse comment syntax and hence assume the contents of comments as already present? At least the filters often don’t ignore comments. Fay Freak (talk) 19:24, 29 August 2020 (UTC)
If one knows how it is pronounced correctly, there is also someone who can pronounce them correctly (which “few people are able to correctly pronounce Latin” also says). So we should have Classical Latin Audio files. Ecclesiastical Latin is unnatural and wrong, deriving from a time of exitiable ignorance and superstition where all went by guess and by gosh. New Latin words should also have Classical Latin pronunciations and audio files, since pronouncing all Latin like the Romans would have is the current standard – since nobody understands Latin how Anglo-Saxons pronounce it according to their wont, and few go to church, so “Ecclesiastical Latin” is unheard. And there hasn’t been a monolithic “Ecclesiastical Latin” as presented by Wiki editors either, it is mostly an excuse for accented, native-language based, ignorant Latin. It is left as but the façade for underperformers, the inner circles of Latin students has internalized historical phonology thus far as to skip the Dark Ages – whether the historical baggage or the pseudo-enlightened surroundings – and emit the clean tones of the Roman Republic. Fay Freak (talk) 19:24, 29 August 2020 (UTC)
Why would you assume that Classical Latin is the current standard? Current standard as decided by whom? I am sure Vatican City has its own standard (and being the only country with Latin as a main language, perhaps that isn't so non-standard?), while gymnasiums all over the place pronounce Latin how the pupils would be able to do it easiest. For example, although not Latin, but I know for a fact Latin doesn't differ in this, the Ancient Greek textbooks we received in school contained a table, one column signifying the "school pronunciation" (θ /t/, φ /f/) and another giving the "historical pronunciation" (θ /tʰ/, φ /pʰ/). Thadh (talk) 19:44, 29 August 2020 (UTC)
Why would you assume anything happening in schools to be standard? You mention yourself the reason why schools should be disregarded and disdained: “Gymnasiums all over the place pronounce Latin how the pupils would be able to do it easiest.” Schools are an abomination where humans are degraded and nivellated to keep with the vilest standards, they shouldn’t exist. I am thinking more of university usage, and better living-Latin communities, places people actually choose to attend to use Latin.
But even in gymnasiums I have yet to hear Ecclesiastical Latin, or pronouncing ⟨c⟩ and ⟨g⟩ as anything other than and , namely before ⟨e⟩ and ⟨i⟩, or the ending -tiō not as , etc. Although I noticed boomer buffers having only been exposed to the vulgar pronunciations – it has already been eradicated in Latin teacher trainings at universities and in gymnasiums (I have witnessed both at multiple places). Apparently this is the standard as decided by the Ministry of Education, as they have stipulated in the school curricula for Latin (page 24 for the lower grades and page 40 for the higher grades) that the candidates ”are able to recite the meaning-bearing words and word blocks with correct pronunciation”. Don’t they demand correct pronunciation in this sense in Britain? I often notice they fall behind the standards of Europe in many respects. What does one even do in countries where there isn’t “traditional” Latin schooling, e.g. Russia or Japan? I guess they have no choice but to go with Classical Latin pronunciation, or to consciously violate the rules.
Science is the current standard, hence the historically correct pronunciation. School pronunciation is either that or substandard. Haven’t ever seen a school textbook using IPA by the way. What happens if a pupil decides to go with the historical pronunciation though? Why would it be less standard? It can’t be, hence his pronunciation represents the mostly violated standard. The majority is wrong. Οἱ πλεῖστοι κακοί.Fay Freak (talk) 22:29, 29 August 2020 (UTC)
I share your enthousiasm of the historical pronunciation, but I am afraid we don't yet live in a society where science dictates truth. Standardisation isn't bound to science, it's bound to usage - which is statistically defined. As for your thoughts about how gymnasiums operate, let me tell you: we pronounced <c> as /s/ before <e> and <i>, we pronounced <tio> more like /tsio/ than /tio/ and we had far too unclassical vowels, and if I in my Greek class would try to pronounced the aspirated consonants instead of fricatives, no-one, including my teachers, would understand me. Also, your notion that IPA isn't used in schools is just outright wrong, we had special lessons in English learning us IPA;
But let me return to the main topic, what is standard Latin? Most Latin speakers undoubtedly speak an Ecclesiastical variety, and like with any language, I would think the vast majority does constitute rule. After all, we don't include the Latin pronunciation in Italian entries just because it is "historically more correct"?? I mean, why would we? And we don't include 18th century pronunciation of modern Dutch, although it is undoubtedly the same language as now (we even write that in etymologies). So why would the case with Latin be different? Thadh (talk) 23:14, 29 August 2020 (UTC)
Strange strawmen: “we don't include the Latin pronunciation in Italian entries just because it is "historically more correct"” – because it is Italian and not Latin. I have not quite said “IPA isn't used in schools”. But that is true for whole countries; in NRW according to my experience nobody learns that in school, unless some teacher is particularly dedicated, nor have I seen it in any school textbook, and I have attended a lot of schools and school textbooks over the years. It is hard to find persons who know IPA. What you tell about how you pronounced, I tell you the opposite how we pronounced. None of that palatalization and if there had been one it would have been cacophonic and difficult to understand; and the German vowels happen to be like those in Classical Latin (“different vowel qualities for short vowels”).
Nor are standards bound to but usage. This is just a convenient view for Anglo-Saxons who lack regulatory authorities on languages. Sometimes usage is 90% wrong, why not. The same way a certain person on Wiktionary fails to understand the difference between misspellings and typos, which is according to what people have in their heads. When doing that “school pronunciation” people don’t even believe it is strictly correct, so it is on an even lower level than a misspelling or mispronunciation is. Statistically, most usage in the country you mention is deliberately, consciously incorrect, and should therefore be disregarded, the same way we have warned certain people to cite certain digitized academic chits on native American languages not intended for publication, the same way customary law does not arise if there hasn’t been, apart from habitual application (longa consuetudo), legal conviction that it is right (opinio iuris). Fay Freak (talk) 16:18, 30 August 2020 (UTC)
But how do you define the difference between Italian and Latin? All difference between historically related languages (which Italian and Latin undoubtedly are) is a matter of definition; If the need arose, Italian could be classified as a dialect of Latin. But historically, that need didn't arise, and indeed the opposite happened. So that is what I am trying to tell you, standardisation and relative difference are subjective matters, and I don't think - and I hope you agree - a dictionary should implement more subjective factors than needed; thus we shouldn't be setting standards, that ought to be done by subjective institutions (e.g. countries). Thadh (talk) 19:06, 30 August 2020 (UTC)
I don't think we need two templates to write out the word "circa" or its abbreviation. And why is there no option to toggle the comma off in {{circa}}? It could be trivially done with an if-statement. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 17:06, 31 August 2020 (UTC)
It seems strange, but I think the reason for two separate templates was that {{circa}} is intended only for use for quotations on entry pages, which is why the year is in bold and it is followed by a comma, whereas {{circa2}} is for use in running text. — SGconlaw (talk) 17:26, 31 August 2020 (UTC)
Request new etymology-only languages codes
I face difficulty when etymologize Indonesia words from a specific isolect without language code. These the isolects:
Basemah/Besemah isolect of Central Malay, possible code pse-bsm
@Rex Aurorum I've added ms-old Old Malay and ms-cla Classical Malay, as I can see they are well documented as stages-that-exist. I also added the Betawis as I see they are dialects, and if you will find codes useful, I see no harm in granting them (if anyone does have objections, please pipe up). Besemah seems more scantly discussed, but I added it, too. If you search this site for "Old Malay" you will find some etymologies already mentioning it which you could adapt to use this code. :) - -sche(discuss)03:50, 9 September 2020 (UTC)