Using the entry at 주 (ju) and 수 (su) as an example:
Should we have separate etymology sections for every hanja in hangeul entries? Many of these are only used as affixes rather than unbound morphemes, and some entries such as 이 (i) can be assigned to as many as 250 hanja.
Would it be better to set a criteria, e.g. only create individual etymology sections at hangeul entries for basic hanja or for those that have entries in major Korean dictionaries?
Too many separate etymology sections for every hanja in hangeul entries are redundant.
Basic Hanja for educational use should suffice. Others are much rarely used.
Duplicating Sino-Korean compounds at the hangeul and the hanja entries is even more important if Chinese, Japanese, or/and Vietnamese share the same scripts in compounds, like 日本 (Japan).--Jusjih (talk) 23:34, 17 October 2019 (UTC)[reply]
Merge Middle Korean hanja and modern Korean hanja[edit]
Modern Korean dictionaries do not distinguish between Middle Korean hanja and modern Korean hanja. Using the entry at 顋#Korean as an example:
Shall we merge Middle Korean hanja and modern Korean hanja under a unified Korean header using the format of 顋?
Is the {{hanja form of}} template suitable for the definition line of such entries?
Note that hanja is used more frequently in Middle Korean literature compared to modern Korean literature, but readings are only available in modern Korean because they are not explicitly stated in Middle Korean literature.
Your example may not be very good to merge. I speak Korean only in very basic level, so I advise asking native Korean speakers knowing hanja.--Jusjih (talk) 23:37, 17 October 2019 (UTC)[reply]
As of 2019, what are the community's thoughts on an approach similar to User:Wyang/zh-def?
I like the distinct background color which makes definitions easier to find. Some languages (not all) may benefit from a single "definitions" header.
Currently, Chinese Han character entries which uses a single "definitions" header does not indicate whether a particular definition is a "noun", "verb", "particle", etc. and would benefit from proper categorization.
Putting everything on a page into one template - This would affect only the definitions. Other templates can still be used within this "definitions" template. KevinUp (talk) 07:10, 1 September 2019 (UTC)[reply]
I generally like the layout or at least an approach that is more beautiful and I also like having data structured in templates. I do not like expanding the width 100% (e.g. what happens with pictures or other media?) and having things collapsed--this is not accessible to users. —Justin (koavf)❤T☮C☺M☯04:12, 1 September 2019 (UTC)[reply]
Yes, the collapsible approach is perhaps not that practical. Some of us might be looking for something specific and collapsing everything would cause some information to be hidden when CTRL+F is used. KevinUp (talk) 07:10, 1 September 2019 (UTC)[reply]
Not handy for search and basic display but also not useful for users who have scripts disabled or who use screen readers/text browsers or who have certain sensory motor issues that make tapping on a million links to display content on a page a real chore. —Justin (koavf)❤T☮C☺M☯07:15, 1 September 2019 (UTC)[reply]
Well, we could apply visibility options such as "Show derived terms", "Show quotations" similar to what we currently have on the desktop site. KevinUp (talk) 08:02, 1 September 2019 (UTC)[reply]
Sure, but I am opposed to all of the collapsing content that we have now for the same reason. To be sure, entries like set or a are going to be long: that's the nature of those sorts of entries. Making things inaccessible with collapsing content (even for Finnish declensions that I am never going to look at, let alone understand) is just bad practice. JavaScript is great but it shouldn't be mandatory for interacting with basic text like this. —Justin (koavf)❤T☮C☺M☯08:56, 1 September 2019 (UTC)[reply]
@Koavf: Is the collapsible content inaccessible without JavaScript? My impression is that it only disappears when the JavaScript code runs. — Eru·tuon16:19, 1 September 2019 (UTC)[reply]
@Koavf: Hmm, I thought you were saying that users without JavaScript wouldn't be able to see collapsible content; maybe I misread you. I think collapsible content is collapsed by default for new visitors. What if it were expanded? Then users who have difficulty with the buttons wouldn't have to click anything to see content, but would if they wanted to be able to scroll more quickly. Perhaps it would be optimal if various categories of content were shown or hidden based on which state would lead to less clicking, but I don't know how to get that information. — Eru·tuon17:56, 1 September 2019 (UTC)[reply]
You did not: I was just sloppy. Basic functionality shouldn't be based on scripts unless it's really something dynamic. The site we have doesn't include interactive elements like a game or anything that really needs to change state in front of someone's eyes or based on his inputs: it's a reference work made up of text with some accompanying media. Scripts just to collapse things that are a mild nuisance to scroll past are just a bad idea. It's generally easier to hit "Page Down" or smash the space bar a couple of times (these don't require very fine motor skills) to go past something you don't care about than it is to tab over to the little arrow that will expand the box or click on it. Finding data would be difficult and informative but I would still be in favor of not hiding anything that is the actual content of the dictionary (but I'm fine with the option of allowing it to be collapsed based on user interaction or preferences--unfortunately, our "expand all declension tables" preferences don't stick around at the moment.) —Justin (koavf)❤T☮C☺M☯18:21, 1 September 2019 (UTC)[reply]
@Koavf: When you click the "show x" or "hide x" buttons in the "Visibility" menu in the sidebar, the resulting state is saved in your browser. It's not saved on a per-user basis though; do you mean that the state changes when you switch between browsers? — Eru·tuon20:02, 1 September 2019 (UTC)[reply]
@Koavf: That sounds like a bug. The setting is saved in localStorage (source code in MediaWiki:Gadget-VisibilityToggles.js), so it shouldn't go away. I am not sure how to add it in Special:Preferences if that's what you mean. One difficulty with having a checkbox for each category of visibility toggle is that there isn't a set number of categories (synonyms, translations, inflection, derived terms, etc.); they are generated based on section headers or the contents of HTML tags in the parser output. (In MediaWiki:Gadget-defaultVisibilityToggles.js, the category is the first argument to window.VisibilityToggles.register.) — Eru·tuon20:49, 1 September 2019 (UTC)[reply]
Could potentially go for something like this. It's hard to judge from a Chinese entry since I don't understand that language. We would also need to be careful about what we hide/collapse by default and what we don't (and possibly tie that into individual user settings). Oh yes, and I agree with whoever made a fuss about JavaScript-less users. It should remain readable in Lynx etc. (it doesn't have to be beautiful, as long as we show all the content to those clients rather than some unusable JS placeholder). Equinox◑10:00, 5 September 2019 (UTC)[reply]
Additional point I just remembered: quite a large number of people are colour-blind (in one way or another) and it's hard to find sets of colours that will suit all those different colour-blindnesses. With graphs and charts, you can ameliorate this by using texture (red spots, blue stripes, green crosses), but with text you can't do a lot. So we shouldn't rely on colour alone to indicate anything: it should only be a bonus hint, and also needs to have strong contrast with the background. Equinox◑11:55, 5 September 2019 (UTC)[reply]
I do like the look of this, I would like to see an expanded version which would demonstrate how other key parts of an entry would be handled (e.g. etymology, translations). While I don't like using a single uber-template for this sort of thing, the benefits of having the data in the entry organized in a machine-readable manner may outweigh the costs of such a method. - TheDaveRoss11:58, 5 September 2019 (UTC)[reply]
Please don't do this. It will be a maintenance and (editor) usability nightmare. Individual templates are easier to understand, composeable and potentially cacheable. The proposed solution nests templates and has parameters inside parameters, with its own syntax. Also, I don't understand the point of "this would affect only the definitions" – definitions make up the bulk of the dictionary. Instead of moving the data into templates we should be looking at moving data to a Wikibase instance (in the long term). Jberkel17:52, 17 September 2019 (UTC)[reply]
If this is going to go anywhere at all, I feel that we need to put some work into creating several hundred examples (with complex entries) of the proposed format: pages with multiple etymologies, pages with multiple pronunciations, pages with a single sense, inflected entries. Otherwise it's impossible to see the edge cases and the potential amount of effort it will take. DTLHS (talk) 17:20, 17 September 2019 (UTC)[reply]
Is there any way to do this without using a module to do the heavy lifting? If not we should test very large entries as well since we run into Lua errors frequently and this will potentially exacerbate that issue. - TheDaveRoss17:25, 17 September 2019 (UTC)[reply]
Overall, the comments regarding this proposed format are positive. The colors will need to be tweaked and collapsibility made expanded by default. Anyway, the closest example we have for the appearance of entries using this format can be found at entries such as かん(kan) and とうきょう(Tōkyō). This is just an example of how entries might look in future if we decide to implement such an approach. KevinUp (talk) 18:24, 17 September 2019 (UTC)[reply]
There's definitely a long way to go before this actually gets implemented. We could perhaps test this out with Chinese Han character entries, which has already replaced the parts of speech header by a single definitions header. (I would like to see more precise categorization of Category:Mandarin nouns, Category:Cantonese nouns, etc.) KevinUp (talk) 18:24, 17 September 2019 (UTC)[reply]
I am not talking about changing anything in the mainspace. You should create examples in your own user space. And especially you need to create examples with more than just Japanese and Chinese entries. DTLHS (talk) 18:27, 17 September 2019 (UTC)[reply]
These three languages can be designated as etymology-only languages because Middle Japanese is already merged with modern Japanese based on current practices. KevinUp (talk) 03:20, 1 September 2019 (UTC)[reply]
The etymology language codes can be created, but unfortunately categories starting with an etymology language name aren't supported. That is, templates can't categorize into them and there aren't category boilerplate templates for them. For instance, {{der}} only accepts an etymology language code as its second parameter (the language from which a term is derived), not first. Changing this would at least allow for more specificity in etymologies.
Middle Japanese can't treated as an ancestor of Japanese if it is an etymology language with Japanese as its parent. It doesn't make sense for a language to descend from a subvariety of itself. (That sort of relationship makes Module:family tree crash with a stack overflow, and it breaks the link to further-back ancestors. I tested this by making grc-koi, Koine Greek, an ancestor of grc, Ancient Greek, and previewing some pages. In ἐπί, Ancient Greek was not seen as a descendant of Proto-Indo-European anymore. I suppose this would be fixed by giving the etymology language an ancestor, though.) It would make sense for Modern Japanese (an etymology language) to descend from Middle Japanese, though without a category for Modern Japanese terms inherited from Middle Japanese, this relationship would only be used in family trees, if Module:family tree would display it. — Eru·tuon08:03, 1 September 2019 (UTC)[reply]
Thank you for looking into this. If we can't create categories for etymology-only languages, I think (1) Middle Japanese will have to be designated as a full language code with Old Japanese as its ancestor and Japanese as its descendant. As for (2) Early Middle Japanese and (3) Late Middle Japanese, these two languages can be set as etymology-only languages with Middle Japanese as their ancestor.
At the moment, Middle Japanese can only have scripts if it is given a full language code. In any case, if it were an etymology language, its scripts couldn't be used anywhere but in etymology templates.
I moved your comment below up here in case you haven't read my reply above. I think Middle Japanese will have to be made a full language, like how Middle Chinese is made a full language to avoid the complications you mentioned above. KevinUp (talk) 21:36, 1 September 2019 (UTC)[reply]
Will we also create a code for Early Modern Japanese? Broadly speaking, "modern Japanese" can be dated from around the mid-to-late-1800s with the fall of the Edo Shogunate and the rise of the Meiji, the opening of the country and the influx of foreign words and concepts, the repurposing of existing words for new meanings, and the deliberate forging of new vocabulary in an attempt to modernize and standardize the language.
Do we really need to make these new codes into full-fledged, separate and distinct languages, with their own entries and template infrastructure and the like? This seems like the wrong way to work around what seems to be a minor technical issue with the etym inheritance implementation.
I'll hazard a guess to say that most of the entries that we might put in the proposed new "language" headings for Early and Late Middle Japanese would be duplicating content from our modern Japanese entries. The main differences come down to things like sense development (such as ありがとう(arigatō) shifting from "in a manner difficult to exist" to "in a manner difficult to bear" to "welcome" and then the modern "thanks" sense), phonetic realization (such as /je/ and /we/ merging ultimately into /e/) and conjugation patterns (like the 下二段(shimo nidan) lower bigrade conjugation pattern flattening out into the 下一段(shimo ichidan) or modern lower monograde pattern). I feel much more comfortable trying to explain all of this in the context of "Japanese", rather than duplicating entry data across multiple different language headings, especially as the older senses and sometimes even conjugations are still used. I'd also like to point out that monolingual sources treat Middle Japanese as a matter of footnotes and formatting within entries for the modern language, rather than as a distinct entity.
The early and late varieties (Early Middle Japanese, Late Middle Japanese, Early Modern Japanese) will not be having their own entries and template infrastructure because these languages will only be used in the etymology section to display statements such as "From Early Modern Japanese X, from Late Middle Japanese Y", etc. to reflect sound or spelling changes.
As for Middle Japanese, it will be made a full language so that we can use the language code in templates and quotations within the Japanese section. I agree that some of the older senses and conjugations are still used in written Japanese so it is not necessary to create a separate entry for Middle Japanese. Middle Japanese can be merged into Japanese like how monolingual dictionaries treat the language. {{ja-see}} can be used to redirect entries with archaic spelling to the modern spelling. KevinUp (talk) 22:27, 4 September 2019 (UTC)[reply]
Okay, so the proposal is to have Middle Japanese as a full language but with no entries of its own? At the moment that means that Middle Japanese links would go to the Middle Japanese section, not the Japanese section as intended. Perhaps Module:links could be made to direct Middle Japanese links to the Japanese section. It would complicate linking in other modules because they couldn't rely on the section name being the canonical name anymore. — Eru·tuon02:16, 5 September 2019 (UTC)[reply]
Yes, the plan is to have Middle Japanese as a full language with no entries of its own, similar to how Middle Chinese is unified with Chinese. The linking problem is an issue for languages that use such an approach. For example, all the hanzi entries in Category:Cantonese nouns link to TERM#Cantonese rather than the correct form TERM#Chinese. One way to overcome the linking issue for Middle Japanese is to periodically search for the following:
{{l|ja-mid|TERM}} → convert to {{ja-l|TERM}}{{q|Middle Japanese}}
{{cog|ja-mid|TERM}} → convert to {{cog|ja-mid|-}}{{ja-l|TERM}}
{{desc|ja-mid|TERM}} → convert to {{desc|ja-mid|-}}{{ja-l|TERM}}
This is of course, an inefficient way to deal with this issue, but it is not uncommon to have links that link to nowhere, For example, I often click on Middle French links that only have a French section. I wonder if there's a way to identify links that already have a page but lack an entry in the target language so that false positives can be identified. KevinUp (talk) 03:15, 5 September 2019 (UTC)[reply]
Currently, we have quotes from Nippo Jisho (日葡辞書) which are written in Latin script. Shall we add Latin as one of the scripts for Middle Japanese along with the Japanese script?
This would include pretty much everything that is not a modern coinage or borrowing. I'm not sure about the utility / usefulness / use case for this category. See my comment above about keeping this within the context of "Japanese". ‑‑ Eiríkr Útlendi │Tala við mig23:03, 3 September 2019 (UTC)[reply]
This category was created by a single user who grossly overestimates their skill in the Latin language - they haven't managed to even correctly write the description, although they refer to themselves in it in the singular. There is no legitimate need for this category any more than there is a need for Category:User_en-5. I propose that it be deleted. Brutal Russian (talk) 13:48, 3 September 2019 (UTC)[reply]
@Brutal Russian:@Fay Freak:,@Mélange a trois:,@Holodwig21: You are incorrect about there not being inflections, monsieur. "Iste usuarius potest contribuere cum cognoscentiā professionalis de linguā romanā; id est forma imperialis, ecclesiastica, et mediævalis" translates, in the tradition of spoken Medieval Latin, this user can contribute with the knowledge of a professional of the roman language; i.e. the imperial, ecclesiastical, and medieval form. My word choice is more free than "classical-only". That said, we should delete the category of User_la-5, since there is no need for the category like en-5. Aearthrise (talk) 17:17, 25 September 2019 (UTC)[reply]
@Aearthrise: While it's somewhat more gooder than the previous version, it still doesn't quite make sense, translating to "These users can contribute about as well as in the speech of the Latin language profession". Brutal Russian (talk) 06:51, 26 September 2019 (UTC)[reply]
I deleted the category, having noticed it today. We don't even have an en-5 category atm, and if there are problems with the text and/or accuracy of the only included user... just use la-4. - -sche(discuss)22:49, 17 January 2020 (UTC)[reply]
The verb "contribuere" is not used in the intended sense - nor any other single verb to my knowledge;
"usor" in all category descriptions should read "usuarius" as in the template;
la-0: Hic usuarius aut nullam aut paucam linguam intellegere potest - should read "Hic usuarius aut nihil aut pauca latine intellegere potest";
la-2: "media latinitas" means "medieval Latin" - rephrase as "medius gradus", "satis bene...potest";
la-3: "callidissima latinitas" means "most ingenious" or "extremely cunning Latin" - rephrase as "probe ac latine";
la-4: the whole phrasing smacks of translationese, should probably say "latine loquuntur pariter~similiter ac/tamquam sermone patrio".
Could someone kindly direct me to the templates that should be edited? In addition, as far as I understand it's important that the phrasing reflect one's active knowledge of a language, and not just passive understanding - is this correct? In that case I'm planning to change the phrasing to "latine scit et scribere potest". My thinking is that due to the general lack of active Latin users people might be rather judging their reading skill - there are more la-3 tagged users than it-3 and ru-3, which I find difficult to believe (it says "speaks fluently" in the Russian template). If anyone has further translation suggestions, they'd be very welcome. Brutal Russian (talk) 14:57, 3 September 2019 (UTC)[reply]
Thank you both. You can get a sense of using a word similar in meaning if you substitute contribute in the English description for any of its synonyms, e.g. "this user can bestow in simple Latin". Brutal Russian (talk) 21:29, 3 September 2019 (UTC)[reply]
contribuere Hm, on the internet? The English contribute, the German beitragen etc. arguably hadn’t this sense either before Stallman invented it; though I see that this stretches the Latin meaning more (simply put, Latincontribuere does not mean “to contribute”; in German it is more zuweisen, zuschlagen). What do you suggest? We should ponder more how to do GNU propaganda in Latin. But maybe as a Discord user you aren’t much into it.
Yes, usor isn’t even a word, except as a scanno for uxor or ūsūrīs etc.; see also Talk:proprietor. Ridiculous.
Indeed, media latinitas is Middle Latin aka Medieval Latin.
Yeah, the superlative callidissima is off, and evidently translates Romance.
Yeah, they tried to translate modern linguistic categories (“native speaker”, “natively” – how would a Roman say?)
When you have invented true Latin formulations, you should not miss to get Meta Wiki and the rest to fix their bad Latin. They have similarly bad phrasings, though not the same. I do not understand where the data is saved on Meta Wiki, possibly it is in software (can somebody find the texts?), but you find the texts displayed via meta:Category:User la. Fay Freak (talk) 22:35, 3 September 2019 (UTC)[reply]
@Fay Freak I don't know whether there is an established word for it (even if a medieval one), I just know that contribuere is not that word - neither could I properly define what exactly it means, I just know it doesn't mean the same as its English or Romance look-alikes. Whatever the GNU propagandists come up with should at the very least be usable intransitively, for instance conferre. Btw, could you elaborate on why Discord users aren't supposed to be into it? =P
I've never come across a proficient speaker saying "native speaker" or discussing how to say it - I myself wouldn't outright censure nātīvus locūtor/ōrātor, but I wouldn't endorse it either - I'm not even sure which of the several options S&H give for "native" is the best one. For the time being, I don't think there's a need to use an equivalent to the English expression - the phrasing I suggest in the initial edit looks fine to me.
@Lambiam As a fellow Discord Latinist who writes excellent Latin says - and we don't agree in everything, but here we definitely do - if that's what it says on Vicipaedia, it's definitely wrong. They've managed to get the name of the whole language wrong, for Jupiter's sake (it's not Latina any more than it's Italiana, Española, Française etc). I think it remains so broken because people who see that it is aren't the same people who know how to fix it, and the former despair before even trying (that's true for me at least). I wouldn't be surprised if that page is usor's first attestation xD Brutal Russian (talk) 15:55, 4 September 2019 (UTC)[reply]
@Lambiam@Benwing2@JohnC5@Fay Freak@Urszag@Brutal Russian It's not incorrect to use contribuere, though its classical meaning of "paying a public expense" or "joining territory" is different than later meanings. This is an example of a medieval Latin meaning of contribuere: Traité de Savone 17 November 1394 ...et exercitus ipsius domini ducis contra illos contra quos dictus dominus dux guerram faciet et habebit, hoc modo videlicet quod ipsum commune et Saône teneantur dare et contribuere ipsi domino duci balistarios centum tantum...|...and the army of the warlord against those whom said warlord may make and will have wars, in this way let it be known that that community and Saône must give and contribute to that warlord only 100 bowmen...; another example is a French-Latin dictionary from 1750 - "Cic. Contribuer, donner, fournir, donner, apporter, attribuer, assigner, former une tribu de, mettre en une tribu.; Contribuere injuriam injuria Sen. Rendreinjure pour injure...", it's the same as the dictionary's definition of conferre;;;Don't let your classicist zealousness cloud your ability to understand that Latin is a long-lived language that did change. Aearthrise (talk) 03:33, 26 September 2019 (UTC)[reply]
@Aearthrise Using contribuere to mean conferre is classical, albeit peculiar in a figurative way, seeing how far removed this meaning is from the primary one. Using contribuere intransitively is, as far as I can see, neither classically nor medievally correct. You will have noticed that I've even suggested an English approximation of the kind of mistranslation this leads with "This user can bestow in simple English", illustrating how dictionary definitions and synonyms aren't reliable guides to correct usage. If it had been medievally correct but classically incorrect, I'm sure you wouldn't have suggested adopting the medieval usage over the classical one any more than regularly adopting habeō factum to mean fēcī, for precisely the same reasons that are too obvious to need voicing.
The Seneca citation in the dictionary you linked has been dialed via a Chinese telephone - the actual text is "an alterum alteri [sc. beneficium injuriae] contribuere et nihil negotii habere, ut beneficium iniuria tollatur, beneficio iniuria", the relevant part of which the latest Loeb translates as "or ought I to combine the two into one". This is what appears to be the word's most basic meaning, and it has nothing to do either with the meaning we're discussing or the one the French (mis)translation purports - not to mention being transitive. I suggest you use a dictionary at least a hundred years less ancient than this - preferrably the Oxford Latin Dictionary (available at libgen) - and always check the citations yourself. Perhaps then you will find that my judgement of what is and isn't correct Latin hasn't in fact been clouded, but yours clarified. Brutal Russian (talk) 06:29, 26 September 2019 (UTC)[reply]
I think it would be useful to have a category which shows which entries (in each language) include images. However I'm not sure if there is a way that can be found to automatically categorise them rather than adding a category manually. Anyway, let's see what the reaction to this proposal is like first. DonnanZ (talk) 13:36, 5 September 2019 (UTC)[reply]
That's what I want to find out. I for one would make use of it, even to find entries that don't have images and would be better with them. And we seem to have categories for virtually everything else. DonnanZ (talk) 13:57, 5 September 2019 (UTC)[reply]
But how would you use a category of images to find entries that don't have images? I think there is no technology to say "list all entries NOT in a category". Equinox◑14:11, 5 September 2019 (UTC)[reply]
Technology, no. One could notice an entry missing from the category, investigate and possibly rectify the omission if a suitable image can be found on Commons. And if one can't be found creating one from your own work is possible if you know where to find and photograph something suitable, I have been doing that lately. DonnanZ (talk) 14:20, 5 September 2019 (UTC)[reply]
Actually, there is a method to search for entries that lack a certain template or entries that are not in a certain category. Try this: KevinUp (talk) 15:36, 5 September 2019 (UTC)[reply]
I am not aware of any way to do this (automatically, it could easily by done asynchronously by analyzing database dumps) unless we started putting all images in templates. DTLHS (talk) 17:42, 5 September 2019 (UTC)[reply]
Then we need to use templates, in place of using Mediawiki code. And the templates can never keep up with the capabilities of Mediawiki to display images. If you think that one way to embed images is the only used here then you are mistaken. Given that words for plants denote both the plant and the fruit it often makes sense to have a gallery showing the fruit maybe in different processing stages, the plant from the near in different seasons (bearing fruits, or when yet only blossoms), the plant from afar. Example: بَلاذُر(balāḏur) which meant the marking-nut before the New World explorations and now means cashew, so it has two, slightly different to GermanNeugewürz with its descendants. That’s what I expect from a dictionary to tell me what a plant name means.
We also use {{multiple images}}, or mostly only Sgconlaw and I use that, for example on moccasin, for different purposes – I use it to have horizontal grouping if there is space to the left but not enough content in the bottom to show one image under another. Turkishispinoz / اسپنوز: Male and female finch.
This {{multiple images}} is problematic though because it doesn’t let me change relative image sizes so I have to pick roughly fitting ones :/.
The purpose of a category for entries that had images would be what? To review the appropriateness and adequacy of images? One could use search to find them in groups by using searchbox searches like 'incategory:"English nouns" incategory:"English lemmas" insource:/\[\[((fF)ile|(iI)mage)\:/'. One could add searches for galleries and other display generators.
I would have thought that the main problem is finding entries that might need images and also fit with one's topical interest or skills.
One could always use, say, Category:Requests for images in English entries to find a few entries that need images. Intersecting that category with a topical category would narrow the search. One could look for items in such a category that also had {{comcatlite}} or {{commons}} to find some that would be easy to fill. One could also exclude pages that already had images using -insource:/\[\[((fF)ile|(iI)mage)\:/'
A problem with a category like 'English entries without images' is that the category is so large as to not be usable in doing intersection searches in the search box. Another is that it would miss large numbers of definitions that were missing images because the English L2 section already had one definition with an image.
I would think that using {{rfi|en}} and adding "topic=" tags (or equivalent) would enable targeted searches (with or without categorization) for definitions that needed images. DCDuring (talk) 00:41, 6 September 2019 (UTC)[reply]
I must admit I forgot about {{rfi}}, which I have been able to comply with once or twice, but this isn't added in every case where images are desirable. DonnanZ (talk) 09:12, 6 September 2019 (UTC)[reply]
You can find pages with images using the following searches: insource:/(File|Image):.*(jpg|jpeg|png)/. This can be combined with incategory keyword. (A duplication od DCDuring's information above, oh well.) --Dan Polansky (talk) 10:39, 6 September 2019 (UTC)[reply]
A look at Glottolog makes it seem like the 't'-less form has become more common in more recent works that are specifically about the language; however, in broader literature both exist, and in an Ngram Itsekiri is much more common, as Lambiam says. So, support. - -sche(discuss)02:28, 15 September 2019 (UTC)[reply]
Replacing de-sysop votes with confirmation votes[edit]
Over at Wikipedia, some of you may be aware, there is a project called Moss which seeks to eliminate a pet hate of mine, tyops. A useful byproduct of this project is that it finds words potential missing Wiktionary words. Below around 100 such entries. The number at the beginning represents the number of occurrences in en.wikipedia. Enjoy and happy editing! --Mélange a trois (talk) 17:27, 8 September 2019 (UTC)[reply]
It would be cute/fun/useful? to have some automated bot-o-matic thingy that would connect that project with this one, along the lines of Wiktionary:Wanted entries. But don't go mad because a lot of them will be rubbish words. Equinox◑23:59, 8 September 2019 (UTC)[reply]
Very true, but to me that suggests that we just need a way to (permanently? or for some period of years) strike non-words from the record. I've noticed BTW that sometimes the very same word appears twice in WT:REE in successive years, perhaps because somebody forgot they'd added it before. Equinox◑00:27, 9 September 2019 (UTC)[reply]
Yes yes but once again we're suffering from not having any structure to our entries, just big lists and bullets and indents. If we have a list of "words to avoid" who's to say anyone will look at it? If we had a form where you filled in WORD + DEFINITION + SOURCES then we could validate it right off. Equinox◑02:05, 9 September 2019 (UTC)[reply]
Inconsistent use of qualifiers in translations[edit]
I noticed e.g. here in the Swedish translations, that qualifiers sometimes comes before the terms. TranslationAdder.js always inserts them after the term. I found no guidance in EL.
I think that in this specific instance {{sense}} is more appropriate – which IMO should always come before the term. The use of {{sense}} in translations should of course be rare, because there ought to be a single sense per list, but occasionally a target language will have distinctions that are not present in English. I see though that other examples that I can think of also use {{qualifier}}; e.g. at sister we have “Turkish: abla(tr)(elder), ...”, while I feel “Turkish: (elder sister):abla(tr), ...” would be better. --Lambiam10:32, 11 September 2019 (UTC)[reply]
You will not find any consistency here. Translation sections are a free for all. Trying to clean up translations has driven several users off of the project in frustration. DTLHS (talk) 15:27, 11 September 2019 (UTC)[reply]
Thanks for the warning. I just found Wiktionary:Translations and it contains nothing about qualifiers or senses to my surprise.
Two questions come to mind:
Will we need a vote or discussion about where to put the qualifier or can we agree that always putting it after the term is correct?
Shouldnt’t it technically be distinguishable by whether it comes before or after commata?
It can also be more complicated. For stubble “short stalks left in a field after harvest” I could for some Slavic languages discern a distinction between the stubble itself and a field of stubble, which latter might likewise been sought and are more commonly used in the respective languages, and I added them inside of the qualifiers. Guess one needs AI for the translation tables.
I support more markup though, so at least those who know can do better. @DTLHS I am myself shocked how many wrong langcodes or uses of {{t}} outside of translation tables by me you had to correct. I believe it is facilitated by the different source code formatting, the fact that in the translation tables the language names are in plain text. If the name was fetched like with {{m+}} the former error would be impossible and the latter less likely because it arises from copying terms to reuse them and deleting the plain text language name but forgetting to replace the template name. The language name is fetched somewhere anyway for the section link, unlike with {{t-simple}}.
(On the other hand one adds more language names than there are codes. Sometimes Christian Palestinian Aramaic, Jewish Palestinian Aramaic, Jewish Babylonian Aramaic under “Aramaic”, example in bed) Fay Freak (talk) 16:12, 11 September 2019 (UTC)[reply]
I'm no tech maven, but further automation of the translation tables is likely to have a dramatic negative effect on entry load times for some of our larger entries, especially those with highly polysemous English terms. [[a]] and [[water]] come to mind, but there are others. Maybe someone with good tech foo can come up with Summer-of-Code projects that would help with these. DCDuring (talk) 19:05, 11 September 2019 (UTC)[reply]
My understanding is that it has always been preferred that qualifiers be after the translations, but the Translation Adder used to insert them before the translation (I think because that was "easier" to code). I recall that there was a short thread somewhere which led to that behavior of the Translation Adder being fixed (it may have been Ruakh who fixed it). - -sche(discuss)02:38, 15 September 2019 (UTC)[reply]
And I recently saw a user (forgotten the name) using either qual or gloss to give a literal English rendering of the linked foreign term! Equinox◑02:42, 15 September 2019 (UTC)[reply]
FYI my ImprovedTranslationAdder.js now supports adding literal translations the correct way e.g: {{t+|af|jakkals trou met wolf se vrou|lit=jackal is marrying wolf's wife}}
Should we include non-native audio pronunciations?[edit]
I came across a French user's audio file for the English word bicycle and removed it on sight as being unhelpful for English dictionary users, as well as nominating multiple files by the same user for deletion here.
Two users including the uploader are arguing to keep the files, and I wanted some Wiktionary editors to weigh in. Maybe I'm wrong in wanting them deleted from Commons since I don't know their policy, but can we agree that there's no place for these in Wiktionary? Ultimateria (talk) 15:11, 11 September 2019 (UTC)[reply]
They might be kept, provided that they are sufficiently marked that they are not added automatically by bots. Who knows what one can use them for, maybe to illustrate articles about learning languages. They should not be included in the dictionary. There are enough native accents, it’s only noise. Fay Freak (talk) 16:18, 11 September 2019 (UTC)[reply]
User:Fay Freak brings up a possible tangential use of them but that would really be more appropriate at b: or v: (likely at b:fr: and v:fr, specifically) for interactive media teaching someone to speak English. I mean, there are already so many accents and lects of English let alone all of the hundreds of millions (billions?) of non-natives who have such wildly varying accents. I really don't see the value of this here since the goal is to show how a word is used by the community that uses that word. If a word gets adopted into another language, then use that pronunciation for that entry. —Justin (koavf)❤T☮C☺M☯17:13, 11 September 2019 (UTC)[reply]
I am having a similar problem in trying to delete an incorrect Armenian pronunciation here. Maybe we should block the bots for importing incorrect pronunciations, until their owners learn to maintain blacklists. --Vahag (talk) 18:16, 11 September 2019 (UTC)[reply]
Yeah that’s what I mean: They can be kept on Commons as for example usable to illustrate language learning, or erroneous pronunciation, as on Wikiversity, but the files have to be marked in one way or the other so the bot can distinguish. Fay Freak (talk) 18:26, 11 September 2019 (UTC)[reply]
Some imports (including the bicycle one) are from Lingua Libre via Commons. Lingua Libre collects all sorts of audio, including non-native pronunciation. The recording metadata has a reference to the speaker (example), which includes language levels, so a bot could only import recordings made by native speakers. – Jberkel18:35, 11 September 2019 (UTC)[reply]
I think not, since the majority of users are likely to want to know the standard (Inner Circle) versions. At least we should ensure we have those before we try for anything more exotic. Equinox◑18:21, 11 September 2019 (UTC)[reply]
I think we should stop trying to treat Commons names as meaning anything. Just because they aren't useful for us doesn't mean anything for Commons.--Prosfilaes (talk) 00:58, 12 September 2019 (UTC)[reply]
I use LinguaLibre to record pronunciations, and admittedly I got a couple of them wrong. For one I even recorded a fart sound, just to see if anyone actually listens to them (they did, and quite quickly removed it from the site). As for non-native pronunciation, it seems obvious that it is not as good as, for example, my beautiful voice. Also, I'd love to hear each word spoken by 10 different accents - Liverpudlian, Scottish, South African, Deep South etc. Hmm, I wonder which word has the most audio pronunciations? I'm sure one of the more geeky users can find out. --Mélange a trois (talk) 09:46, 13 September 2019 (UTC)[reply]
Not sure how much applies to this online crowd-sourced dictionary effort but it's worth thinking thru some of the problems with UD's methods and ensuring that we don't fall the same fate. —Justin (koavf)❤T☮C☺M☯20:42, 11 September 2019 (UTC)[reply]
"Where Oxford and Merriam-Webster erected walls around language, essentially controlling what words and expressions society deemed acceptable," really? I find very little value in this article and I don't think the author knows much about lexicography. I guess it points out (indirectly) that there is more to a dictionary than a 2D line between "descriptivism" and "prescriptivism": there are also "dictionaries" that simply invent vocabulary out of the ether ("inventionism"). DTLHS (talk) 20:53, 11 September 2019 (UTC)[reply]
Yeeaaahhhh (long drawn-out expression of dubiousness) ... The article author doesn't understand lexicography, and clearly doesn't distinguish between a list of memes, and a dictionary. UD is great if you want some idea of the current zeitgeist for a particular term, but it's useless as, well, a dictionary.
I would guess the main reason for decline in sites with "user-generated content" is that now there are a lot more users and many of them are young children. A bit like what Eternal September did to Usenet. Equinox◑21:19, 11 September 2019 (UTC)[reply]
It’s not like we couldn’t need a lot more users. Which decline? All runs fine until one tries to suppress information for politics, or for special rights. Fay Freak (talk) 21:56, 11 September 2019 (UTC)[reply]
"Which decline": well, politics aside, you don't think that Pewdiepie screaming and swearing his way through Minecraft, and the typical crop of YouTube comments, are a bit more inane than the quiet intelligent bloggers of the early 2000s? Equinox◑22:04, 11 September 2019 (UTC)[reply]
No, I think that this is what is left after the legal trammels have grown ever heftier. Regulation everywhere, only some big players can calculate with it, and children who can’t care. If you are a blogger you will possibly drown in cease-and-desist letters because your privacy notice misses some trifle. It’s how at some time there were many producers of CPUs, now there are two – the laws have provided loopholes to eliminate competition, and the desire to become competitive. And in compliance with modern identity politics everyone is triggered by everything and tolerant towards addictions and degenerations thus tame, on top of coming out of schools more damaged than educated, which has always left majorities inane. Education always depended on incalculable details, and the cult of equality has stifled it. Everyone goes to school but learns nothing; everyone converses in cramped networks but may not tread on anyone’s toes; everyone may work but idlers stand at the door to have a share of it. That’s how you nurture the ugly. Fay Freak (talk) 23:41, 11 September 2019 (UTC)[reply]
This comment reeks of a desire to ignore the facts in favour of shoehorning one's ideological agenda in even when it's in opposition to the facts or not even wrong. The real reason for Pewdiepie being vapid when compared to bloggers is that the internet has became mainstream, with the inevitable results; this "mainstreaming" happens to all forms of new media. A decent portion of his audience is literally children; what do you expect? There's still plenty of intelligent content on the internet if you know where to look; it's just that you'd rather pontificate towards a brick wall than have to actually bother to engage with anything. Hazarasp (parlement · werkis) 10:24, 24 September 2019 (UTC)[reply]
To answer a question that was not directed at me (pardon, Equinox): we need quality and quantity. A lot of one does not make the project that we want to make. —Justin (koavf)❤T☮C☺M☯22:35, 11 September 2019 (UTC)[reply]
So they complain about what? That Urban Dictionary depicts harsh reality and does not censor enough or that it has too much joke content and does not censor enough?
Nothing to applaud there. The internet should have dumps, and there should be lawless zones. Urban Dictionary still often has the definition you need that could not pass elsewhere. Fay Freak (talk) 21:56, 11 September 2019 (UTC)[reply]
I would very much prefer to only have one template left when we are done if possible. All terms that should appear alike should be inserted using the same template with a few different parameters for e.g. title, number of columns, etc.
Is that really Vector? It looks like the mobile site, which uses Minerva. You can check with mw.config.get("skin") in JavaScript. (Special:Preferences only controls the skin used in the desktop site.) The mobile site just doesn't run many of the collapsibility scripts, only NavFrame. I wouldn't feel confident working on it myself because I never use it. — Eru·tuon04:37, 13 September 2019 (UTC)[reply]
Oh, you are probably right. I would really like a menu on mobile for easily changing skin. Do you know how I could inject JS or HTML to do that?--So9q (talk) 06:19, 13 September 2019 (UTC)[reply]
I assume you are referring to things like "Aggarwal is most common among Asian/Pacific Islander (94.32%) individuals."? That information was added by a particular user and I have seen other users support removing it, but no action has been taken. DTLHS (talk) 01:37, 13 September 2019 (UTC)[reply]
Don't know about surnames but I have wondered about names like Shaniqua, which are not seen outside of black American communities. Well that one has a usage note. Given names are usually chosen by a parent, who belongs to such-and-such a culture. Surnames are a bit different... Equinox◑02:13, 13 September 2019 (UTC)[reply]
So what can possibly be more "culture-bound" than given names that only black Americans use, like Shaniqua? I would wager money that no black Briton has that name. It's absolutely part of the culture. Equinox◑02:27, 13 September 2019 (UTC)[reply]
No one is arguing otherwise. Certainly, the name Shaniqua is an African-American one. Not sure what your point is. Both "Moishe" and "Cantor" are Jewish names. Similarly, "Rodrigo" and "Hernandez" are both Hispanic. —Justin (koavf)❤T☮C☺M☯02:29, 13 September 2019 (UTC)[reply]
My point is that your immediate parents usually choose your given name, but your surname is usually left alone, and persists for a long time. Saying "Shaniqua is a black name" is an observation about how black Americans tend to name their kids; saying "Goldstein is a Jewish name" is quite another matter: maybe my great-great-grandfather was the last Jew in the family. Equinox◑02:32, 13 September 2019 (UTC)[reply]
For every "Goldstein" who has a very tenuous connection to the Jewish people, there are 10,000 "Jacob"s who have no relationship to the Jewish people. Personal names are much more likely to not be culture-bound/associated than surnames. —Justin (koavf)❤T☮C☺M☯18:59, 14 September 2019 (UTC)[reply]
Because it tells you about how English language surnames are distributed, at least in the US. For all the problems with race, it's still a good proxy for ethnic groups in the US.--Prosfilaes (talk) 02:33, 13 September 2019 (UTC)[reply]
I think it's useful having this information. It provides at least vague information about where the name came from, and can be useful to fiction writers who might be trying to find a name that suits a particular demographic. Andrew Sheedy (talk) 02:55, 13 September 2019 (UTC)[reply]
I understand the need for demonstrating association, but it does rub me the wrong way how obsessively it shows up. I admit surnames should mention their connotations on the page, but only if it's A) especially prominent and B) not a repeating a general rule. Rule A is for names like Poindexter, which is associated with nerdy people, and Rule B means to exclude Steinberg for Jewish stereotypical names, since it demonstrates the -berg suffix used in stereotypical formations of "[Ashkenazic] Jewish names". Also, the US Census doesn't perfectly reflect how race is seen in the US: as Middle Eastern North African people (MENA), many Hispanics, many Portuguese-descended people, many Latinos, Sephardic Jews, Romanis, Ashkenazic Jews, Armenians, and Kartvelians are considered "White" on legal papers despite it not socially being the case for many of them, especially the first 6 groups. Nonetheless, I don't plan on touching those parts of the pages at the moment. Starbeam2 (talk) 18:47, 14 September 2019 (UTC)[reply]
I decided to include that information when I added the surnames. I decided to do so for two reasons: I had the information and it seemed lexically relevant. I concur that there are problems with the stats (as has been mentioned above) and that the relevance to a dictionary is not inarguable. I would not strenuously object to their removal if people felt that they don't belong, I would even be willing to remove them myself if that is the verdict. - TheDaveRoss22:47, 15 September 2019 (UTC)[reply]
Where's the information for the label "dialectal" come from? When meaning Of or relating to a dialect, such a dialect should be added as well as the source, for example in unlight --Backinstadiums (talk) 15:52, 15 September 2019 (UTC)[reply]
Our glossary, to which the label (dialectal) links, gives two meanings:
The latter sense need not be tied to any specific identifiable dialect; it could also be slang or a colloquialism. It may be unfortunate that the label combines these two senses, especially as we also have the label (nonstandard). Many of the Turkish terms labelled “dialectal” can more properly be called “regionalisms”, but the regions in which the terms are current do usually not correspond to a well-defined and named geographic subdivision. Compare the distributions of faucet vs. spigot in the US, where the latter (in the sense of “faucet”) also does not keep to a well-defined border but spills over from Philly into the Midland dialect region.[1] --Lambiam16:38, 15 September 2019 (UTC)[reply]
"Such a dialect should be added as well as the source" is a counsel of perfection (sense 3). We rarely have very specific information. But it is useful to know that a given definition may not not be generally understood in all places a language is spoken. DCDuring (talk) 18:21, 15 September 2019 (UTC)[reply]
@DCDuring: It all depends on the definition of "dialect" to begin with, but if an editor knows a term is dialectal, they must at least know some dialect/region or, for further investigation, add where the info comes from --Backinstadiums (talk) 18:59, 15 September 2019 (UTC)[reply]
False. The editor might know that it is regional but be unsure about the region. Also if he writes one region it looks like the term is only from this region. Fay Freak (talk) 19:34, 15 September 2019 (UTC)[reply]
For entries to specify dialects rather than using "dialectal" is a good ideal/goal, but it will take a long time before all the entries currently labelled only as "dialectal" can be labelled more specifically. - -sche(discuss)19:21, 15 September 2019 (UTC)[reply]
This is not possible as a principle. If a term is used only in certain villages and an author uses such a term you do not know which village it points to or whether it is picked up elsewhere. Such can only be solved with dialectological atlantes which are based on surveys and are thus topically restricted. Fay Freak (talk) 19:34, 15 September 2019 (UTC)[reply]
As I said in my talk page, our convention is to use "Old Church Slavonic" L2 header, which usually just corresponds to "церковнославянский" in Russian sources. It would be wrong to use the language code "cu" and have a header anything but "Old Church Slavonic". The "cu" will add to "Old Church Slavonic" categories, not "Church Slavonic". --Anatoli T.(обсудить/вклад)10:19, 16 September 2019 (UTC)[reply]
(edit conflict) @ПростаРечь: Question. Are you sure, it's not "Old East Slavic" (древнерусский) or old New Russian, rather than "Church Slavonic"? By this time (1581), the Russian language has fully formed and it seems like a mixture of Russian with Old Church Slavonic or just a very ecclesiastic form of older Russian (ru)? When I get accustomed to the fonts, I can actually read and understand it as a Russian text, perhaps with a bit more ease than modern English speakers can read Shakespeare. Sorry, I just can't dedicate too much time at the moment but we need to assess what language it is. (Notifying Benwing2, Cinemantique, Useigor, Wikitiki89, Stephen G. Brown, Guldrelokk, Fay Freak, Tetromino, Canonicalization): Does anyone want to assess the language of the Ostrog Bible? Is it cu, ru or something completely new? --Anatoli T.(обсудить/вклад)12:35, 16 September 2019 (UTC)[reply]
It might be worth considering changing our convention so that the canonical name of cu is Church Slavonic, which we can then divide as needed into dialects such as Old Church Slavonic (= Old Bulgarian?), Serbian Church Slavonic, Russian Church Slavonic, Middle Bulgarian, Bosnian Church Slavonic, Croatian Church Slavonic, and whatever other varieties editors deem desirable. —Mahāgaja · talk12:26, 16 September 2019 (UTC)[reply]
But the syntax is not what is visible in the dictionary. And this can be seen as Medieval Latin, where the Latin was also too German, too Spanish, too French grammatically, but yet never was Spanish or French. If the endings are like in the Old Church Slavonic original and Old Church Slavonic is still the model intended by writers then this speaks for unity. Also, if we don’t know where to draw the line this also speaks for a more flexible approach with labels. блꙋдити(bluditi) can be added with {{spelling of}} or {{form of}}. Fay Freak (talk) 12:46, 16 September 2019 (UTC)[reply]
The main problem with that approach is that pretty much all of our etymologies use cu to mean Old Church Slavonic- are we going to have to add qualifiers to all of them?. Chuck Entz (talk) 12:45, 16 September 2019 (UTC)[reply]
@ПростаРечь:. Yes, please do for forms not used in other forms of (currently) "Old Church Slavonic" (i.e. words or forms that are specific to this variety and you know it). Please don't use any other language header for now, just "cu", as language codes go with language names and categories. We need to create a new language at Wiktionary to avoid a mess. I think we're dealing with "Church Slavonic" here with the Russian specifics. Technically, it's not a very big deal, I think, just need an agreement. Are you OK to continue using "cu" and "Old Church Slavonic" and a label for a while? We need the community to wake up from slumber!
Please also keep all the discussion here. I don't want to make the decision myself and I'm not so great at creating a new language structure.
I agree with Mahāgaja that we need separate varieties. "cu-r" ("Russian Church Slavonic") seems like a good candidate. Some linguists may cringe but people should realise that what they call using "Church Slavonic" have very distinct flavours on many levels.
@Atitarev: Russian Church Slavonic (or Russian Synodal recension) is the language of books since the second half of the 17th century, in my opinion. The Ostrog Bible published in Ostroh (Grand Duchy of Lithuania) in 1581 (the 16th century). I would prefer more politically neutral naming unit, e.g. Old East Church Slavonic (or simply Church Slavonic / Middle Church Slavonic for a while) or something like that. ПростаРечь (talk) 11:49, 17 September 2019 (UTC)[reply]
Just to clarify, I am not suggesting creating a new L2 language code. I am suggesting treating all the varieties mentioned as dialects of cu, which would be renamed "Church Slavonic". Then L2 would read ==Church Slavonic==, and definition lines would include labels like {{lb|cu|Russian Church Slavonic}} (or whatever name we decide on) which would then categorize into a CAT:Russian Church Slavonic (notCAT:Russian Church Slavonic language), which would itself be a subcat of CAT:Church Slavonic language. —Mahāgaja · talk12:12, 17 September 2019 (UTC)[reply]
@Vorziblix please, don't divide terms from the Ostrog Bible in Ruthenian, Old Russian and so on, otherwise, we risk having an edit war because there are many reliable sources, that contradict each other. Such a sittuation we also have with some Old Dutch texts (e.g. Wachtendonck Psalms, it is hard to determine whether a text actually was written in Old Dutch or in other western Low German dialects). I really want to use a collective name. You may offer such a term. Note: Ivan Fyodorov was the first known Russian printer in the Grand Duchy of Moscow and the Polish-Lithuanian Commonwealth. ПростаРечь (talk) 08:42, 21 September 2019 (UTC)[reply]
@ПростаРечь: Apologies. While I agree that calling these recensions Ruthenian/Russian/etc. is not ideal, I do think it’s preferable to use some name that’s seen actual use in academic work. As far as recensions of Middle Church Slavonic go, most papers I’ve looked through seem to agree that there are three or four recensions, viz. a ‘Bulgarian’ recension, a ‘Serbian’ recension, and the East Slavic recensions, which some papers divide into ‘Ruthenian’ and ‘Muscovite’ and some label with a single blanket term, usually ‘Russian’ or ‘Ruthenian’. (See for example Robert Mathiesen (1984), The Church Slavonic Question: An Overview (IX-XX Centuries).) Other terms that occasionally show up include ‘Rusian Church Slavonic’ (with one ‘s’) and ‘East Church Slavonic’. My problem with ‘Old East Church Slavonic’ is mostly the word ‘Old’, which makes it very confusing given that it’s a variant of Middle Church Slavonic and not either OCS or OES, and the fact that it doesn’t seem like anyone else has ever used this term. But perhaps there’s no good solution here. Feel free to change my labels as long as they’re consistent. — Vorziblix (talk · contribs) 12:06, 21 September 2019 (UTC)[reply]
Oppose as mentioned above. I would treat Russian Church Slavonic as a dialect of Church Slavonic, not as a separate language. (And our ad-hoc language codes always begin with an official ISO code, so if we do create a new code for RCS, it should be something like sla-cru or sla-rcs, not just cru, since that is already a deprecated code for a variety of the w:Karu language.) —Mahāgaja · talk12:12, 17 September 2019 (UTC)[reply]
Abstain Bad code, as pointed out by Mahagaja, and unfortunately ad-hoc name. Apart from that I wouldn’t object to keeping the Church Slavonic recensions distinct. — Vorziblix (talk · contribs) 21:48, 17 September 2019 (UTC)[reply]
Change canonical name of cu from "Old Church Slavonic" to "Church Slavonic" and create dialect tags and categories for the various recensions of Church Slavonic - a mini-vote[edit]
Support. Very practical. I assume the recensions and Old Church Slavonic will have their codes like grc-aeo for Aeolic Greek, and we have extra module data for {{lb}}. We have also recently removed “Old Latin”, and I suppose that “Classical Syriac” should also be “Syriac” sooner or later if we respect that people used it in the 19th century or even use it, in so far as Latin is now “used”, as a literary language (we had codes for “Syriac” and “Classical Syriac” but people just got confused and added stuff for the latter under the former). Fay Freak (talk) 13:37, 17 September 2019 (UTC)[reply]
Support, with the proviso that main lemmas should be at the OCS spellings wherever possible, with post-OCS forms entered as alt-form entries. Also note that we already have some later Church Slavonic entries such as телѧ(telę) that should be updated if this succeeds; more can be found by running a search for "later Church Slavonic". — Vorziblix (talk · contribs) 21:48, 17 September 2019 (UTC)[reply]
Support but it's unclear for me how it affects Etymology/Descendants section, because there are 3 cases of Church Slavonic: OCS, NCS0/NCS1 (NCS without/with specified recension).
Support In the Romanian principalities of Wallachia and Moldavia, Church Slavonic was used not only in church, but also in administration. While the grammar standards mostly remained as in the original language, the vocabulary continued to evolve. So, if a Romanian word was borrowed from Church Slavonic (the official language of the states), I can now only choose **Old** Church Slavonic, which is inaccurate, as the word was definitely not part of the language as written down by Cyril and Methodius, but a later addition. Bogdan (talk) 22:51, 8 February 2021 (UTC)[reply]
Oppose Too great a risk of confusion. We can't count on every editor to label terms appropriately, which reduces the value of Wiktionary for those wanting to distinguish genuine old forms from later inventions. OCS was, at least in its original Bulgarian-Macedonian form, a very close reflection of the local language, which makes it valuable for historical linguistics. The later recensions, especially modern Russian forms, are not particularly useful for that purpose. If we do decide to merge the two, the model of Latin should be followed, with genuinely old forms unmarked and later inventions marked. —Rua (mew) 17:25, 19 September 2019 (UTC)[reply]
We could not count on editors not adding non-old terms as Old Church Slavonic already. Now we want to make it more current for the first time. Fay Freak (talk) 10:48, 20 September 2019 (UTC)[reply]
I offered the solution of following the Latin model, where "old" is considered the default and later forms/recensions get a context label. —Rua (mew) 10:47, 21 September 2019 (UTC)[reply]
More or less, but I think "Russian recension" is a better label and will probably be more widely understood, since it's the term used in general studies of CS. —Rua (mew) 15:44, 21 September 2019 (UTC)[reply]
“Russian recension” without further qualification is usually taken to refer to the post-1650s standardized Synodal recension, which should IMO be kept distinct from the earlier (Middle Church Slavonic) forms. (The distinction remains significant even today in that the Old Believers never accepted the Synodal recension and still use the older forms.) — Vorziblix (talk · contribs) 21:27, 23 September 2019 (UTC)[reply]
@Rua But we don’t call later recensions of Latin names like “Medieval Old Latin”. If we keep the L2 named “Old Church Slavonic” the recensions are “Russian Old Church Slavonic” and so on – the labels contradict the header. Also unlike between antiquity and the Middle Ages where history, the Dark Ages create a patent gab, it is not so clear where Old Church Slavonic ends, it slowly degrades. The difference between the vernacular and the literary language was never that great. Still in 18th century Russia one thought the Church Slavonic to be some kind of “High Russian”. And one can never be sure if something is “only late” or rather later authors have preserved something old since we don’t have complete dictionaries of the ancient lect like with Latin. Fay Freak (talk) 14:05, 21 September 2019 (UTC)[reply]
That's a naming issue more than anything. The problem I have is with forms missing yers, or worse, non-native outcomes of certain phonemes that clearly give a local colour to certain words. OCS is by default assumed to be an early form of Bulgarian-Macedonian, and therefore people will use that in historical assessments. If we have words with clearly Russian developments like ъ > o, ǫ > u and ę > ja then it does a disservice to the people using Wiktionary for historical linguistics, because they cannot tell that it's not Bulgarian-Macedonian in origin. We could require that everything be labelled and nothing left to chance, but that's hugely messy when OCS is at its core Bulgarian-Macedonian and the other recensions are basically mixed languages combining true OCS forms with the local language. —Rua (mew) 15:44, 21 September 2019 (UTC)[reply]
Abstain unless we figure out how to map existing uses of cu to cu-old or whatever code is chosen for it. For example, generally when I have entered references to Old Church Slavonic, I use {{cog|cu|...}} or {{bor|cu|...}}/{{der|cu|...}} whereas if I need to enter a reference to e.g. Russian Church Slavonic, I say "Russian Church Slavonic {{m|cu|...}}". If this convention is generally adhered to, we can (maybe) replace all uses of cu in cog/bor/der with cu-old. My concern is that editors have been entering OCS terms using the cu code since that's what its canonical name is, and this info will be lost if we switch the name to just Church Slavonic. Benwing2 (talk) 04:16, 18 September 2019 (UTC)[reply]
@Benwing2 Switching the header by bot and then adding the label “Old Church Slavonic” via {{tlb}}? There aren’t many possibilities thinkable. Some entries might already be not Old Church Slavonic but another Church Slavonic, but by that execution the entries do not become any more wrong. Fay Freak (talk) 10:48, 20 September 2019 (UTC)[reply]
@Fay Freak You're still thinking in terms of entries. The main problem is in etymologies. Right now, {{cog|cu}} displays "Old Church Slavonic", and people have been adding various templates to the etymologies with the "cu" code for many years with the expectation that the display would be exactly that. The second the change is made to the module, all of those etymologies are going to say "Church Slavonic", including those that don't link to any entry. If we don't change all those etymologies to say that it's Old Church Slavonic they're referring to, an etymologically-important distinction will be lost.
A few of those etymologies may be already referring to later Church Slavonic, but I would imagine that to be very rare. Switching the name would mean that the rate of deceptive naming would switch from almost all okay with a few rare exceptions to almost all deceptive with a few rare exceptions. OCS is a very important language in etymologies, so we need to come up with a solution before going through with this change. Chuck Entz (talk) 21:10, 20 September 2019 (UTC)[reply]
I have not mentioned what I imagine to be then: under the assumptions of existing usage you have made and which I share, one would change these usages to an etymology-language code, cu-ocs or OCS I deem most likely. Then analogously what I have said about entries: Some stated Old Church Slavonic words might already be not Old Church Slavonic but another Church Slavonic, but by that execution the statements do not become any more wrong. It would not switch to “deceptive” in any case. I imagine that for entries the “Old” part goes to {{tlb}} and in links in etymology and descendant sections the code “cu” is replaced with the new code for Old Church Slavonic: Apparently one first creates etymology-only code, then switches cu in etymology and descendant sections to it, then renames L2 sections by removing “Old ”.
In etymology sections there are by the way probably comparatively few – though from a Slavic viewpoint I can only stress the importance of Old Church Slavonic –, for example I get only 110 hits for the search terms "Cognate to" "Old Church", i. e. any mainspace space that contains the wording “Cognate to” and "Old Church", which does not even comprise only pages which do mention Old Church Slavonic words in the sections in question but also Old Church Slavonic pages. Whereas in Proto-Slavic entries there is virtually always Old Church Slavonic meant; editors have been wary enough to use formattings likeRussian Church Slavonic {{m|cu|...}}, and other editors usually have not added any Church Slavonic term at all.
I don’t see what I could have missed: If 1. we change cu to return “Church Slavonic” instead of the former “Old Church Slavonic” but in etymology and descendant sections change the occurences of cu that return a name to cu-ocs before and 2. in entry pages we change the L2 headers to have “Church Slavonic” instead of the former “Old Church Slavonic” but in the same bot edit put “Old Church Slavonic” into {{tlb}} unless there are contrary labels (as those ПростаРечь has now deployed), then we do not change any statements. Fay Freak (talk) 01:04, 21 September 2019 (UTC)[reply]
Is tull not countable in the sense of “custom house”? The Swedish Wiktionary lists a plural, not only for the sense tullstation but also for the sense avgift som betalas när vara förs över gräns. Can’t you say tullarna är höga (for which “customs duties” may be a better translation than “toll”, which is more like vägtull )? --Lambiam20:35, 16 September 2019 (UTC)[reply]
There are two declension templates for uncountable nouns:
Yeah, you are right. Thanks for the help. As an aside I asked Gamren to create a new ACCEL template for swedish like he did for danish.--So9q (talk) 20:54, 16 September 2019 (UTC)[reply]
I think it is a misnomer; the only “irregularity” I see is the absence of plural forms, so sv-noun-unc-[c|n] should have been enough. --Lambiam22:04, 16 October 2019 (UTC)[reply]
@Lambiam: I agree, I also find it odd that the default ending is -n/-t rather than -en/et and that the definite form has to be manually written for all uncountable nouns that don’t end in a vowel (which has got to be a majority), e.g. mjölk or arbetslöshet. It should be the other way around in my opinion, so that sv-noun-unc-c yields what’s now in mjölk, and sv-noun-unc-c|ondsk yields what’s now in ondska and then some special case for those on -s like majs (which is now fully manually typed out). (Don’t worry, I’ll bring this up on the appropriate talk page as well.) --Lundgren8 (t · c) 22:15, 16 October 2019 (UTC)[reply]
I am of the opinion that categories for requests for various things like translations, etymologies, definitions et cetera should not be in “hidden categories”. Now only editors who have opted in in their settings see from the mainspace that there are categories like Requests for etymologies in Russian entries. If they were displayed then users who don’t know about them but are inclined to solve them could be lead into much-needed partipication.
A related issue is that the etymology request entries however are cluttered. Category:Requests for etymologies in Latin entries counts 3,550, but the bulk is names and one does not see the bigger fish to fry. Since it is likely that one is interested to solve appellative nouns but not proper nouns and on the other hand people who are interested in proper nouns likely want to solve personal names, demonyms, settlement names, hydronyms, and the like asunder, and these are special fields with special sources and dynamics, I propose that we add a parameter to {{rfe}} / {{rfelite}} to sunder the requests into subcategories at least thus far. Fay Freak (talk) 12:55, 17 September 2019 (UTC)[reply]
I'm not quite sure what you're driving at. For example click on "edit" for trading post, it has 10 hidden categories, at the bottom "This page is a member of ten hidden categories" - click on that and they are all revealed. DonnanZ (talk) 19:58, 17 September 2019 (UTC)[reply]
@Donnanz: The categories as visible under the page, not the editing window. I have a line “Hidden categories” where I find request categories, if a page is in such a category, under every page because I have set it up in my preferences but if people don’t set it they don’t see these categories. I have argued to unhide the requests to optimize user attraction. Fay Freak (talk) 20:18, 17 September 2019 (UTC)[reply]
@Fay Freak: No, I don't think that is necessary. Looking in the translations section for trading post one can see a few red-linked entries, so it's obvious there is no entry, as well as languages marked "please add this translation if you can". It's worth mentioning that in some cases blue links can be false, appearing in one language but no entry exists in another language spelt the same. DonnanZ (talk) 20:39, 17 September 2019 (UTC)[reply]
According to Wiktionary:Etymology, etymologies should be brief and include a simple list of previous forms.
I would prefer to see "From Middle langterm1, from Old langterm2, from Proto-langterm3." rather than "First attested in work W, 15?? as term1. Also attested in work X, 16?? as term2. Also attested in work Y, 16?? as term3 ..."
Yes probably they should be added as quotations. But I wouldn't just move them to the citations namespace (unless you actually have quotations) where they will be forgotten about. DTLHS (talk) 16:31, 17 September 2019 (UTC)[reply]
The contributor would seem to be following and extending our common practice of burying definitions in favor of alternative forms, pronunciations, and lists of cognates, just to mention what can appear in each L3 section above the definitions. DCDuring (talk) 17:12, 17 September 2019 (UTC)[reply]
I don't fault B2V22BHARAT for this formatting, since there was precedent in Korean entries. Ideally, the Middle Korean entries should actually be created, and it should be moved there, IMO. —Suzukaze-c◇◇19:28, 17 September 2019 (UTC)[reply]
Yeah, as I recall, this was the previous format and both of us converted it into this. I think the "also attested" parameter was misused because it was originally meant for terms that had slightly different spellings. I think it would be better to add quotations at the Middle Korean entry and indicate only "from Middle Korean X" in the etymology section for a less cluttered appearance. KevinUp (talk) 19:53, 17 September 2019 (UTC)[reply]
The reason for using {{okm-inline}} is because Middle Korean uses Yale romanization which is different from Revised Romanization used by South Korea for modern Korean. For example, Middle Korean 뎌르다(tyeluta) is tyeluta not dyeoreuda; Middle Korean 잡다(capta) is capta not japda.
And of course, terms such as Modern Korean져르다(jeoreuda), Middle Korean뎌르다 (Yale: tyeluta), 댜르다 (Yale: tyaluta) deserve their own entries with quotations, not mere mentions in the etymology section.
I understand what you're trying to do. However, I don't understand how reconstructed words(or consonant), namely the "Proto-Indo" European words, which has no record, only based on ideas, can be justified in favor of Latin and Greek Cognates, which has actual records.
To be specific, I fully agree on Latin(cor,cordis)---> Heart(Modern English) shift, because there is actual record of cor, cordis on Latin, but I'm not convinced of the kerd--> Heart part, since 'kerd' is merely a reconstructed word, which has no record that your ancestors have used it.
More examples: quod(Latin)--> what, centum(Latin)--> Hundred --> OK.
Kwod(Latin)--> What, Kemtom(Latin)--> Hundred --> I'm not convinced.
If you can present to people the actual usage of Kwod and Kemtom(or at least K*-) in other languages, such as German, Portugese, Spanish, French, etc, then I think people including myself will be more easily convinced. B2V22BHARAT (talk) 14:07, 19 September 2019 (UTC)[reply]
For example, like this: *kerd-
Proto-Indo-European root meaning "heart."
It forms all or part of: accord; cardiac; cardio-; concord; core; cordial; courage; credence; credible; :: credit; credo; credulous; creed; discord; grant; heart; incroyable; megalocardia; miscreant; myocardium; :: pericarditis; pericardium; quarry (n.1) "what is hunted;" record; recreant; tachycardia.
It is the hypothetical source of/evidence for its existence is provided by: Greek kardia, Latin cor, Armenian sirt, Old Irish cride, Welsh craidd, Hittite kir, Lithuanian širdis, Russian serdce, Old English heorte, German Herz, Gothic hairto, "heart;" Breton kreiz "middle;" Old Church Slavonic sreda "middle."
I don't know why Greek, Hittite and Breton language are chosen as representation of Proto-Indo European language, but at least in this presentation I can somewhat understand *kerd- sense. Sincerely, B2V22BHARAT (talk) 02:20, 20 September 2019 (UTC)[reply]
@Suzukaze-c: I think {{okm-inline}} is necessary because of the differences in romanization. Middle Korean 뎌르다(tyeluta) is tyeluta not dyeoreuda; Middle Korean 잡다(capta) is capta not japda. We don't want other editors, especially new editors to end up correcting these.
As for {{defdate}}, it can be omitted if there is only one spelling (optional not compulsory). It is much more useful when there are spelling changes across different time periods. Compare edit1 and edit2. KevinUp (talk) 09:04, 25 September 2019 (UTC)[reply]
Hi, I searched the archives in here and WT:EL and found no information about how to handle images for non-english terms.
My questions is whether it is a good idea to include images on a page for every language of a term. E.g. the article bolt has 3 images on the english tab. Would it be a good idea to copy those to be shown also on the Danish, Old English and Norwegian tabs?--So9q (talk) 19:22, 17 September 2019 (UTC)[reply]
I don't think it's a good idea to use the same image in every language entry for the same meaning. That is a bit boring. Other suitable images are often available on Wikipedia Commons. DonnanZ (talk) 20:55, 17 September 2019 (UTC)[reply]
What makes sense for users who use tabbed languages does not make sense for those not using that gadget. Sometimes you can't both have your cake and eat it. DCDuring (talk) 23:15, 17 September 2019 (UTC)[reply]
Yes at least for things that don't usually have a term in other languages (like Finnish kalakukko, a loaf of bread with a fish baked into it — though this example is spoiled by the fact that we seem to count it as an English word too). Equinox◑14:52, 21 September 2019 (UTC)[reply]
It is a good thing to add varying images – but boring and wasting bandwidth to have the same –, there are so many unused images, and many things can benefit from multiple images, and if all do not fit on the English page we can at least have multiple across languages. Look at оман / oman, elecampane in all Slavic languages, as an example. It would be very silly to repeat the same image, innit. Effectively it’s one dictionary entry for one word, having inflections and pronunciations for multiple languages. Fay Freak (talk) 15:13, 21 September 2019 (UTC)[reply]
I don't think wasting bandwidth is a real consideration: including the same image (it's only a link!) in multiple entries is only a few dozen bytes for the markup. We aren't actually making copies of image files. Equinox◑15:39, 21 September 2019 (UTC)[reply]
Ultimately this is yet another thing that could, in theory, be solved by separating "meanings" from "renderings" (a bit like HTML vs. CSS, heh): if there is a general concept "an apple" and 3,000 languages have words for it, then the image really belongs to the concept and not to the words. I know it ain't that simple but this issue will keep coming up, and those OmegaWiki people seem to have realised it. Equinox◑15:41, 21 September 2019 (UTC)[reply]
That was thought for the case when one accesses a foreign language entry defined as “X” with an image and then one clicks on the definition only to find the same image in the English entry. This would load the image twice assuming it is not cached. Fay Freak (talk) 16:20, 21 September 2019 (UTC)[reply]
Just a few questions: 1) why do we mark words with bekadgefat letters? Aren't those words 100% predictable? Maybe we should mark irregular pronunciations/ stressings instead? 2) Why do latinizations even for monsyllabic words have accents? 3) Do we capitalize proper noun latinizations? This one applies to more than just Hebrew. Starbeam2 (talk) 19:46, 17 September 2019 (UTC)[reply]
1) Probably because for beginners it is not yet so predictable, or it might be relevant if a Hebrew word is mentioned in an etymology section of an other language and the reader cannot be expected to know about it. Then the transcriptions include even this detail so they can just be copied. 2) They shouldn’t. Or perhaps they weren’t monosyllables because of lost schwas. 3) Opinions vary. Fay Freak (talk) 20:05, 17 September 2019 (UTC)[reply]
1. I mean, all of them have the same six letters each time. Even if could not read said letters, i could probably recognize the individual shapes. 2) Aye aye, guess i'll fix it. 3) I honestly think it should be the case, as latinization is the only time capitalization is required. Furthermore, i have one more question: 4) If i don't know the stress, but i know the pronunciation of a Hebrew word, can i make a latinization without stress and mark it as such? Starbeam2 (talk) 19:40, 18 September 2019 (UTC)[reply]
Hey all - I've been editing the Tungusic section of Wiktionary for a little while now, and I'm finding it extremely frustrating to add entries correctly or consistently due to the lack of coherence among experts in how they write things in their papers. And even more frustrating is the fact that currently, I have to convert these Latin-script texts into Cyrillic, when many of the languages do not have a clear, defined orthography or conversion protocol from converting between Latin and Cyrillic. What does one do about this?
It seems as if each expert has their own system for representing sounds - some use IPA-based transcription, and some use one that represents the underlying vowel harmony rather than the actual phonetic realisation - both have their merits, in my opinion. And due to the patchy documentation available online, it's extremely difficult, and in some cases, impossible to determine how several different systems represent the same word. Then there's the transcription into Cyrillic, which poorly represents the sounds and is not standardised, which I feel leaves a huge possibility of inaccuracy in entries - something which I feel very uncomfortable about. I want to be comfortable that my entries represent exactly what is presented in linguistic journals, which I do not feel is currently possible.
To amend this, I believe that we should use the Latin-script orthographies used in the journals, even though there are several in use; then decide as a community on the Cyrillic standard to be used across all of the Tungusic languages, which accurately represents the information contained in the Latin orthographies, before transliterating the Latin entries as Cyrillic ones. The vast majority of the Tungusic languages do not have a standard form, or any form at all that is widely utilised - the exceptions being the likes of Evenki and Manchu. The Evenki orthography however, is plagued with all the difficulties of the other languages. Manchu, in my opinion, is highly regular and standardised across all circles of experts and their literature; and thus, does not need adjustment. I'd rather, personally make use of several accurate orthographies, than use one without a standard, that I have to convert from Latin myself, and that is full of inconsistencies and inaccuracies.
Then there is also the question of dialects - Tungusic is made up of many dialect continuums, and I feel that these dialects should be represented accurately, distinctly, and clearly, which is currently not the case. We as a community need to decide on the dialect categories for each of the languages and do our best to label each entry with them. This, in my opinion, is a major part of accurately representing the languages as they are spoken/were spoken.
Please do give me your thoughts on this - I'd love to see this resolved so we can increase the quality of our coverage of these absolutely fascinating languages. TheSilverWolf98 (talk) 00:42, 18 September 2019 (UTC)[reply]
Since I've not had any replies, I've created a page that lists Oroch words extracted from numerous academic journals, just to illustrate the variation in the ways linguists represent this language. And how little overlap there is between papers in terms of content. Oroch Wordlist. The case is similar to the one presented here for all Tungusic languages except Manchu. TheSilverWolf98 (talk) 01:54, 20 September 2019 (UTC)[reply]
The issue of using Latin vs. some more "native" script is a fraught one. I personally favor using Latin transcription for languages without a standardized native script. This includes cases like Moroccan Arabic and maybe Egyptian Arabic, where (especially in the former case) the Arabic script cannot accurately represent the sounds of the language without extra diacritics and such that (in practice) are never used. Benwing2 (talk) 16:26, 20 September 2019 (UTC)[reply]
BTW if we do use Latin transcription, I'd much prefer that we pick one of the academic systems in use (probably whichever one is most common or well-documented) and convert all other representations into that one. Otherwise it will be total chaos for users trying to actually read the entries. Benwing2 (talk) 16:28, 20 September 2019 (UTC)[reply]
The method of transcription I see most often (probably because there are many articles by him made available online) is the one used by J A Alonso de la Fuente, though Peter Piispanen, Alexander Vovin, Sergei Sarostin, and others use their own transcriptions. Due to the lack of overlap between the papers (in that they all present different items of vocabulary), it is difficult to see how to convert one to another. I personally am a fan of Alonso de la Fuente's transcription system, as it very clearly displays vowel harmony, and makes use of some simple diacritic sets. If you visit my Oroch Vocabulary page, which I linked above, you can see many examples of his transcriptions. Of course, I'd still like others to offer up their ideas on this. TheSilverWolf98 (talk) 01:06, 21 September 2019 (UTC)[reply]
I don't think that a unified Tungusic orthography is possible or desirable. Most of these languages have had attempts at literary standards with varying results in usage and official recognition. I would certainly prefer to base ourselves on the literary corpora, scant as they are, over journal articles.
I suggest using the orthography of the dictionary you're primarily basing your entries on. If you don't even have a dictionary, this doesn't bode well for the entries. If you just want to use the language for linking cognates and listing descendants, this can be handled ad hoc by giving only the transcription. The same goes for dialect partition. Crom daba (talk) 00:24, 24 September 2019 (UTC)[reply]
Automatically replacing "Foolang {{m|bar|...}}" with "{{cog|bar|...}}"[edit]
Hi. I have written and run a script to automatically replace "{{etyl|FOO|...}}{{m|BAR|...}}" and "Foolang {{m|BAR|...}}" (and similar variants) with {{cog|FOO|...}}. Basically, it looks for expressions of this sort preceded by "Cognate with/of/to" or "Cognates include" or "Compare with/to". It is smart enough to handle chains of terms of the sort "Compare Low German {{m|nds|dick}}, Dutch {{m|nl|dik}}, English {{m|en|thick}}, and Danish {{m|da|tyk}}". It is also smart enough to handle etymology languages. When running over the 20190901 dump, it finds 30,692 replaceable cases on 16,441 pages. However, it also finds 1,733 cases where it can't do the replacement due to an unrecognized language name, a language name not agreeing with the code, etc. Some of these cases have to be handled manually, but some can be automated. For example:
There are 506 cases of the form "Danish and Norwegian {{m|da|...}}" or "Spanish and Catalan {{m|es|...}}" or similar. How should we handle these?
replace with e.g. "{{cog|es|TERM}}, {{cog|ca|TERM}}" (which duplicates the term — although that isn't necessarily bad — but includes links to both-language variants of the term);
replace with e.g. "{{cog|es|-}} and {{cog|ca|TERM}}" (which preserves the same appearance except with properly linked language names, but doesn't allow for a link to the term in the first language);
replace with e.g. "{{cog|es|TERM|lang2=ca}}" (which requires changes to the implementation of {{cog}} that I could make; we'd have to decide how to display this, e.g. maybe the first language could display as a language name but link to the term);
leave as is.
There are 60 cases of language name "Hindustani" followed by the Hindi and Urdu forms, e.g. on پل we have "Hindustani {{m|hi|फूल}} / {{m|ur|پھول|tr=phūl}}". How should we handle this? Maybe replace with e.g. "{{cog|hi|फूल}} / {{cog|ur|پھول|tr=phūl}}"?
There are 35 cases of language name "Mooring North Frisian" along with language code frr (North Frisian). There's no etymology language "Mooring North Frisian", maybe we should create this?
Generally, I am in Support of the replacement of "Foolang {{m|bar|...}}" with "{{cog|bar|...}}" if this occurs after the keywords "Compare ...", "Cognate of ...", "Cognates include ...". There will also be some cases of "Compare unrelated ..." that will need {{noncog}} instead. KevinUp (talk) 08:24, 19 September 2019 (UTC)[reply]
A few more things:
Some users are incorrectly using {{etyl}} instead of {{cog|-}}. I found some (55 entries) by searching for:
The ones that have "Cognate to {{etyl|lang|-}}[[term]]" can be automatically replaced by {{cog|lang|term}} while the rest that have "Cognate to {{etyl|lang1|lang2}}" will need to be hand-checked.
This one is totally unrelated, but there are a lot of entries using "[[term]]" instead of {{l|lang|term}} under "Synonyms", "Derived terms", "Related terms", etc. I suppose this can be automatically done by bot? KevinUp (talk) 08:24, 19 September 2019 (UTC)[reply]
@KevinUp I have a script to do this. I ran it before on certain languages, mostly languages with non-Latin scripts. It's safer to do that because you can check the script of the link to make sure it's correct, which helps weed out raw links to English terms. Currently it has the properties of certain languages hardcoded in it (the full name and language code, ranges of script characters, and how to strip accents from the link to see whether a two-part raw link can be converted to a one-part templated link), but I'm pretty sure I can get this info from the languages modules. Let me see if I can resurrect the script and get it working on all languages. Benwing2 (talk) 02:52, 20 September 2019 (UTC)[reply]
For non-Latin script languages, raw links are mostly present in recently created entries (2018-2019). As for Latin-script languages, I've come across raw links for Spanish and Italian in older entries. KevinUp (talk) 08:01, 20 September 2019 (UTC)[reply]
I just realized that the main offenders are actually English entries. For example, I recently fixed historical method#English which had raw links since 2008 when {{l|en}} was not yet used for semantic terms.
@KevinUp I resurrected and cleaned up my script. I ran it for about 20 languages and it replaced 82,574 raw links on 50,400 pages. I then expanded it to 88 languages and reran it, and it replaced another 39,732 raw links on 15,704 pages. I then did a postprocessing run that should have gotten all or nearly all of the false positives (it found about 800 potential false positives, which I checked by hand and fixed as necessary). With a bit more work I could probably get it working on all 7,000+ languages but I think I'm reaching the point of diminishing returns. Note that I purposely didn't do English (because I'm not sure whether it's universally agreed to replace raw English links with templated links), also Chinese, Japanese, and Korean (because I'm not sure whether {{l}} is appropriate for them or if there are language-specific variants that should be used instead). If you have the answer to my uncertainty for any of these four languages, please let me know. Benwing2 (talk) 06:12, 22 September 2019 (UTC)[reply]
BTW most of the false positives were due to badly formatted entries in Finnish, Esperanto or Icelandic; not sure why these languages in particular were offenders. Benwing2 (talk) 06:17, 22 September 2019 (UTC)[reply]
@Benwing2: Brilliant work done. Thank you for running the script. For English entries, I think this 2016 vote indicates that most editors are in favor of converting raw links to {{l}}. Perhaps you can run the script to convert raw English links under "alternative forms" and "see also" to {{alter}} and {{l}} respectively, because these are the main offenders (Remember to exclude Thesaurus links and Category links from the script).
For Chinese, raw links under "Synonyms, Antonyms, Related terms, See also" use {{zh-l}} while those under "Derived terms" use {{zh-der|term1|term2|term3|...}}.
For Japanese, all raw links will need to be fixed by hand because the kana or transliteration must be provided. The correct format can be either {{ja-l|term}} or {{m|ja|term|tr=}} or {{ja-r|kanji mixed-script|kana}}.
Because all of these will need to be manually fixed, can you list out the affected entries on a separate page?
@KevinUp Thanks for the info! I will implement it. Meanwhile, I wrote a script to replace raw descendant links with {{desc}}. There was a partial run by User:MewBot previously to do this but it seems to have missed some spots. My bot found 37,978 replaceable cases on 19,760 pages. I haven't done the final saving run yet. The logic is approximately as follows:
Look for things like * → Lithuanian: {{l|lt|Akvilė}} or ** Occitan: [[agla]] or some mixture or raw and templated links.
Replace the raw links with templated links, based on the language code of a templated link on the same line, or (if there are no such templated links) on the language code corresponding to the language name, if the name can be uniquely mapped to a regular or etymology language based on canonical names.
Replace the combination of name + first templated link with {{desc}} if the language name and template code match (either exactly in the case of regular languages, or by matching the regular-language parent in the case of etymology languages). If the character → occurs before the language name, remove it and add |bor=1 to {{desc}}.
There's also a rule that operates before all others to special-case Serbo-Croatian, which typically lists both Cyrillic and Latin versions and needs to use {{desc|...|sclb=1}}.
It issued 6,796 warnings, of which 3,053 were due to an unrecognized language name; 1,406 were due to a language name that was recognized but not the canonical name of any language; 2,084 were due to mismatch between language name and code; 75 were due to there being templated links with different language codes on the same line; 59 were due to a language name that was the canonical name of both a regular and an etymology language (oops); and a few other warnings occurred due to strangenesses in raw links (mismatching two-part links, non-convertible links like [[nouvelle#Noun|nouvelle]], [[w:Scipionyx|Scipionyx]] or [[#Etymology 3|renna]].
The top list of unrecognized language names is:
241 Church Slavonic
123 East Slavic
118 Written Tibetan
109 Northern
105 Beijing
63 Middle Latin
62 Written Burmese
61 Khalkha
61 Eastern
58 Eastern Yugur
50 Orkhon
50 Classical
48 Guangzhou
39 Southern
37 Shanghai
37 Sgaw
33 Palaung
31 Mnong
29 Gallo-Latin
27 Taiwan
27 Dalian
26 Syriac
25 Western Malayo-Polynesian
22 Russian Church Slavonic
22 Finnic
21 Northern Ryukyuan
20 Faeroese
The top list of observed non-canonical language names is:
270 Romansh
194 Nynorsk
137 Azeri
81 Old Frankish
43 Cuman
36 Khorezmian
35 East Frisian
30 Uighur
25 Meadow Mari
25 Hill Mari
20 Komi
19 Croatian
18 Nancowry
18 Mari
15 Malaccan Creole Portuguese
14 Modern Greek
12 Odia
12 Languedocien
12 Gascon
11 Nogay
11 Kurripako
10 Official Aramaic
The top list of mismatches between name and code is:
We can probably special-case some of the most common unrecognized and non-canonical language names. In the mismatches, usually the language name is correct but sometimes it appears to be the other way around, e.g. nb and nn are more correct than "Norwegian", and some cases may need to be handled manually.
The mismatches involving language code xng may be script names; an example is Reconstruction:Proto-Mongolic/temexen. Can you take a look at that and let me know what's going on? It may be possible to handle these script names using {{desc|...|sclb=1}} similar to Serbo-Croatian above, but I don't understand what "Armenian" is doing in the list. Thanks! Benwing2 (talk) 23:35, 22 September 2019 (UTC)[reply]
@KevinUp I went through the top 99 cases of mismatches between lang name and code, and decided what to do, i.e. one of (a) go with the language name and change the code to match (the majority of cases); (b) go with the code and change the language name to match; (c) leave alone. One thing I did was change my script to "correct" lang code "zh" used for Old Chinese, Middle Chinese and Cantonese to the appropriate code for that language (och, ltc, yue). An example that has all three plus modern Mandarin is Reconstruction:Proto-Sino-Tibetan/(s/z)a-j. However, I see now this may be controversial, and the links to code "zh" may be intentional, because all these languages are merged under the "Chinese" header. If "zh" is correct, then unfortunately {{desc}} can't be used without additional support for cases like this. Can you comment? Thanks! Benwing2 (talk) 05:16, 23 September 2019 (UTC)[reply]
"Uyghur", "Arabic", "Armenian", "Chinese" are transliterations of Category:Middle Mongolian language using the respective scripts so I can propose the following changes:
As for Middle Chinese, Old Chinese, Mandarin and Cantonese, the following convention has to be applied to all entries because the entries for [[TERM#Old Chinese]], [[TERM#Mandarin]], etc does not exist.
The templates on the right will provide the transliteration if it is available. This edit is a proposed solution for Proto-Sino-Tibetan entries.
There's a lot of work to be done, but I'm glad you're able to assist with this. Thank you very much for writing the scripts and running the bot. KevinUp (talk) 22:42, 23 September 2019 (UTC)[reply]
@KevinUp Thanks for your detailed post! Maybe you can help review my proposed changes to canonicalize non-canonical language names. I went through all languages that occurred more than I think 3 times, and came up with the following:
non_canonical_to_canonical_names = {
"Romansh": "Romansch",
"Nynorsk": "Norwegian Nynorsk",
# Nynorsk: more specific than Norwegian
"Azeri": "Azerbaijani",
"Old Frankish": "Frankish",
"Cuman": "Kipchak", # is this correct?
"Khorezmian": "Khwarezmian",
"East Frisian": "Saterland Frisian",
"Uighur": "Uyghur",
"Meadow Mari": "Eastern Mari",
"Hill Mari": "Western Mari",
"Komi": "Komi-Zyrian",
# Croatian: ? map to Serbo-Croatian?
# Nancowry: more specific than Central Nicobarese
"Mari": "Eastern Mari",
"Malaccan Creole Portuguese": "Kristang",
"Modern Greek": "Greek",
"Odia": "Oriya",
# Languedocien: more specific than Occitan
# Gascon: more specific than Occitan
"Nogay": "Nogai",
"Kurripako": "Curripaco",
# Official Aramaic: ? more specific than Aramaic?
"Southern Altay": "Southern Altai",
"Ludic": "Ludian",
# Sorani: ? map to Central Kurdish?
"Sinhala": "Sinhalese",
"Car": "Car Nicobarese",
# Serbian: ? map to Serbo-Croatian?
"Kurmanji": "Northern Kurdish",
# Chakavian: more specific than Serbo-Croatian
# Valencian: more specific than Catalan
# Logudorese Sardinian: more specific than Sardinian
# Campidanese: more specific than Sardinian
"Awakatek": "Aguacateca",
# Auvergnat: more specific than Occitan
"Yukuna": "Yucuna",
"West Greenlandic Pidgin": "Greenlandic Pidgin",
# Walser: more specific than Alemannic German
# Swiss German: more specific than German
"Papiamento": "Papiamentu",
"Low Saxon": "Low German",
# Kinyarwanda: ? more specific than Rwanda-Rundi?
# Kajkavian: more specific than Serbo-Croatian
"Izhorian": "Ingrian",
# Flemish: ? more specific than Dutch?
"Belarussian": "Belarusian",
"Sipakapa": "Sipakapense",
# Ripuarian: ? more specific than Central Franonian?
# Nuorese: more specific than Sardinian
# Moselle Franconian: ? more specific than Central Franconian?
# Logudorese: more specific than Sardinian
"Inupiaq": "Inupiak",
# Frisian: not same as West Frisian
"Abkhazian": "Abkhaz",
"Tangkhul": "Tangkhul Naga",
# Siglitun: ? more specific than Inuktitut?
"Salako": "Kendayan",
"Proto-Sami": "Proto-Samic",
# Poitevin: more specific than French
"Old Uighur": "Old Uyghur",
# Nunatsiavummiut: ? more specific than Inuktitut?
"Khamnigan": "Khamnigan Mongol",
# Inuinnaqtun: ? more specific than Inkutitut?
"Ilokano": "Ilocano",
"High German": "German",
# Erzgebirgisch: more specific than East Central German
# Bontok: not same as Central Bontoc
"Bikol": "Bikol Central",
"Balochi": "Baluchi",
# Amuzgo: not same as Guerrero Amuzgo
}
Since you seem familiar with lots of languages, maybe you could review this? Some cases were obvious to me, e.g. Gascon, Languedocien, Auvergnat, etc. cannot be mapped to "Occitan" because they're more specific dialects even though they're listed as other names of Occitan. Conversely, Amuzgo probably cannot be mapped to Guerrero Amuzgo because it's less specific, even though "Amuzgo" is listed as another name of "Guerrero Amuzgo" and the Guerrero Amuzgo language code was consistently used; I imagine the use of the Guerrero Amuzgo code could be a mistake and would need manual checking. Other cases are less obvious; e.g. even though I'm familiar with the situation re. Serbo-Croatian, Serbian and Croatian, it's not completely obvious that mapping "Serbian" and "Croatian" to "Serbo-Croatian" is correct. Benwing2 (talk) 00:47, 24 September 2019 (UTC)[reply]
Also take a look at my changes to Reconstruction:Proto-Mongolic/temexen. You can use |sclb=1 with {{desc}} to have it list the script name instead of the language name. Note that Mongolian, Arabic and Armenian scripts (among others) can be autodetected very accurately, so you don't need to explicitly specify them. This doesn't work for Chinese characters; if you don't specify the script, it displays as "Unspecified". When you use |sc=Hant, you get "Traditional Han" instead of "Chinese"; hopefully this is OK. Also, what's with the Middle Armenian entry? Is this a transcription in Armenian characters or an actual borrowing into Middle Armenian? In the former case it should presumably be tagged as language xng; in the latter case it should be tagged with |bor=1 to indicate that it's a borrowing, which displays an arrow (→) before it. Benwing2 (talk) 01:04, 24 September 2019 (UTC)[reply]
I implemented your suggestions for the unrecognized languages but from your change to Reconstruction:Proto-Sino-Tibetan/(s/z)a-j it looks like Old Chinese, Middle Chinese, etc. need to be done by hand. I have a fast way of doing this; basically, (1) I dump all the pages I want to work on to a file, (2) I save a copy of the original file, (3) I then hand-edit the file, (4) I use a script to push the changes. It needs the original copy to make sure that no one else changed the page in the meantime. This allows you to work much more quickly, do search-and-replace operations across all pages, etc. This is probably a bit like AWB or JWB although it might be faster; not sure. I can try to make these subs myself but you might have to do them as you're more familiar with these languages. If so, I'll save the dumped pages in my userspace and let you edit them. Benwing2 (talk) 02:24, 24 September 2019 (UTC)[reply]
Appears to be a language group with up to four varieties. May require a language code.
Regarding Reconstruction:Proto-Mongolic/temexen, I've updated the Armenian transliteration as {{desc|xng||թաման|sc=Armn|sclb=1|tr=tʿaman}} (It's not an actual word in Middle Armenian, but a 13th century transliteration of Middle Mongolian using the Armenian script). I'm not sure why omitting sclb=1 gave an "Unspecified" error for the Armenian term.
Regarding Reconstruction:Proto-Sino-Tibetan/(s/z)a-j, I think I can track down Old Chinese and Middle Chinese descendants using insource:/\{\{desc\|och/ incategory:"Proto-Sino-Tibetan lemmas" after your bot has converted "Old Chinese" etc into {{desc|och}}. It will take some time for me to check and edit the IPA transliteration generated by {{och-l}} and {{ltc-l}}, so you don't have to dump the pages for me to edit as I can do it after you've run the script. KevinUp (talk) 19:25, 24 September 2019 (UTC)[reply]
Rather than using {{q}}, it would be better to create etymology language codes for the dialects and put those codes in {{desc}}. Then the links in those dialects can be easily located. — Eru·tuon19:57, 24 September 2019 (UTC)[reply]
@KevinUp Thank you very much! As for the Proto-Sino-Tibetan pages, many of them have manually-specified Baxter-Sagart and Zhengzhang transliterations following the Old Chinese, and sometimes have |ts= params for the Middle Chinese. An example with both is Reconstruction:Proto-Sino-Tibetan/nja-ŋ/k, where |ts= appears to contain Zhengzhang's version and |tr= appears to contain Baxter's version. Currently |ts= isn't supported in {{zh-l}} or variants. I think what I'll do is add support for |ts= to them, which will allow me to convert the links, and leave alone the manually-specified Old Chinese transliterations and such; you'll have to edit them afterwards. Benwing2 (talk) 01:03, 25 September 2019 (UTC)[reply]
I'm not sure why |ts= and |tr= is used for Middle Chinese, but it can be replaced by {{ltc-l}} instead (Different linguists have different reconstructions, other reconstructions can be viewed at the Chinese entry).
So for Proto-Sino-Tibetan pages, the Middle Chinese and Old Chinese transliterations will need to be manually converted (some characters have multiple readings) while all the other lects (Mandarin, Cantonese, Min Nan, etc) can be removed. KevinUp (talk) 07:50, 25 September 2019 (UTC)[reply]
@KevinUp Thanks. I did a run last night to add {{desc}}, incorporating your various suggestions on mapping non-canonical language names. It changed about 35,000 entries on about 20,000 pages. It didn't make any changes involving adding {{q}} tags and such, other than "Written" in the case of Tibetan and Burmese; these await the discussion below on new etymology languages. I also didn't have it change Proto-Sino-Tibetan entries with Middle Chinese, Old Chinese or Cantonese, or remove the various modern lects from those pages. If you're sure about these changes, I'll do a separate run to fix up the Proto-Sino-Tibetan pages. Benwing2 (talk) 15:17, 25 September 2019 (UTC)[reply]
According to the Wikipedia article, it's generally considered a dialect of Japanese. If we need something besides dialect marking, it'd be ja-hjm or something. I'd prefer if we used something consistent with w:IETF language tags; that is ja-hachijo (6-8 letter extension name that I'd be happy to try and register officially.)--Prosfilaes (talk) 12:42, 20 September 2019 (UTC)[reply]
@Prosfilaes: Sorry for the late reply. Okinawan is also generally considered a dialect despite not being very mutually intelligible. Yet we have most if not all the Ryukyuan languages in Wiktionary. One of those codes would work too I think. MiguelX413 (talk) 21:43, 22 September 2019 (UTC)[reply]
To judge from the Wikipedia article, it doesn't seem like a good idea to give it a code that marks it a dialect of Japanese, nor of any of the Ryukyuan languages. I'd recommend jpx-hcj instead using the code for the Japonic language family rather than the code for Japanese specifically. —Mahāgaja · talk09:03, 27 September 2019 (UTC)[reply]
We have the rfdef template that allows us to add a sense line with no actual definition, so that Kiwima another user who knows the meaning can fill it in. (This is perennially abused by Wonderfool for phrases he has encountered in sports journalism.)
I have a pretty large list of "good" words that are definitely CFI-attestable but whose meaning I can't work out, usually because it's very specialised (particle physics etc.) though some might be regionalisms or what not. I'm tempted to start creating entries for these, since some info can be given (part of speech, pronunciation, 3 citations, etc.) even without a definition — and perhaps users are more likely to work on them than they would be with a big list of red links.
Support Of course you can do as much as you know, and you cannot be blamed for being lazy if defining the term requires special knowledge or a clear mind you do not have. If you leave requests, it is inviting (especially if the request categories won’t be hidden). And English coverage is probably at the point where definitions become harder for that reason. Fay Freak (talk) 15:00, 21 September 2019 (UTC)[reply]
Support I reserve the right to change my mind if this is somehow abused. I have done this a few times, but usually because I wanted to look something up, because the citations I found didn't support the first definition that I had added, or because I was interrupted before finishing. DCDuring (talk) 19:04, 21 September 2019 (UTC)[reply]
I sometimes create Finnish entries with rfdef, mostly for the purpose of me filling them in later. I remember one of the first larger projects I took part in was filling in a few hundred Finnish rfdefs to empty that category, so this is certainly something that has been done before. — surjection ⟨?⟩ 17:34, 23 September 2019 (UTC)[reply]
I would like to either delete dialects from the "other names" section of languages (e.g. other name "Italian Walser" for language "Alemannic German") or move them to a separate "dialects" section. IMO, "other names" should only contain synonyms for the language (e.g. Farsi = Persian, High German = German, Slovenian = Slovene, Serbo-Croat = Serbo-Croatian, Daco-Romanian = Romanian, etc.). Otherwise, certain bot jobs get much harder. Any objections? Benwing2 (talk) 08:49, 22 September 2019 (UTC)[reply]
A dialects field seems a better approach than just deleting dialect names. There may be hairy issues, like of which language a given dialect in a dialect continuum is a dialect. But there is no hard rule that the dialects of different languages form disjoint sets. (The current coding also allows a language to have several ancestors, like for Saramaccan). For flexibility, I can envisage a scheme in which dialects are treated on the some footing as languages, with their own codes, which then would require a field status, with values like "language" and "dialect" but also allowing a later extension to "language family". And for recording synchronic relationships there should then be fields like parents and members, where the latter could replace dialects. --Lambiam10:49, 22 September 2019 (UTC)[reply]
Setting aside possible future schemes, if we just add a field now it should probably be lects rather than dialects, as lots of the included varieties aren’t (strictly speaking) dialects. E.g. for Serbo-Croatian the various national divisions are standardized registers based on one and the same dialect. — Vorziblix (talk · contribs) 19:28, 22 September 2019 (UTC)[reply]
Yes, those should go into a new field in the language data. The reason why they shouldn’t be removed is that sometimes it is hard to find how a language is named on Wiktionary because the spelling of the language name varies. Having synonymous or in this case often used pars pro toto names there helps to find the language category. Fay Freak (talk) 13:05, 22 September 2019 (UTC)[reply]
I agree with Fay Freak that it's useful to have dialect names somewhere in the language data modules. That allows you to search in Category:Language data modules to figure out which language code or language name Wiktionary uses. If possible, the dialect names should be given codes in Module:etymology languages/data and moved there. Then they can have their own otherNames fields. For instance, in the otherNames of Alemannic German, Walser German, Walserdeutsch, and Wallisertiitsch probably refer to the same dialect, so if an etymology language were created, one of them would be the canonical name (probably Walser German) and the others would be in its otherNames field.
Unfortunately not everyone understands how Module:etymology languages/data works, or knows that they can use the search box in Category:Language data modules (and the search results aren't very user-friendly anyway, especially if you don't understand Lua code), so a language-searching gadget might be nice. This is a start, but it only searches codes and canonical names of regular languages in submodules of Module:languages. It should also be able to search otherNames and the names of etymology languages. — Eru·tuon19:59, 22 September 2019 (UTC)[reply]
OK, I'm thinking of splitting otherNames into two new fields aliases (true alternative names) and dialects, and updating the Lua code accordingly so that code that currently looks at otherNames is changed to look at both aliases and otherNames. (There are only a few spots that access the field directly and I'm pretty sure I can find them all.) The advantage of using a new field is that it's clear when a given language has been audited. How does this sound? Benwing2 (talk) 01:38, 24 September 2019 (UTC)[reply]
If (dia)lects were moved to a new field, it should be done by those familiar with those languages, not just some mass migration. There's a lot of gray that needs navigating, like when a dialect name is a common stand-in for the standard name. --{{victar|talk}}05:56, 24 September 2019 (UTC)[reply]
I just came across some languages such as Category:Inuktitut language with lects that are incorrectly placed under "Other names". I would support splitting otherNames into aliases and lects, and of course, this has to be done manually, not done by mass migration to prevent errors. KevinUp (talk) 19:37, 24 September 2019 (UTC)[reply]
@Victar I agree that there are gray areas. My plan was to move stuff where it's clear (e.g. Uighur is clearly an alias of Uyghur; Auvergnat, Gascon, Languedocien are clearly dialects of Occitan, not aliases) and leave the remainder alone. This can be done bit-by-bit. Benwing2 (talk) 02:37, 25 September 2019 (UTC)[reply]
In my opinion, etymologies should be as succinct as possible while still giving enough information for it to be useful. For instance: this etymology of French bedeau has so much information it could be confusing to a reader. This one ignores the terms Germanic origins, which is interesting and useful to me at least. And this one conveys the right amount information in my opinion, however its categorization is not exhaustive.
A compromise could be to have etymology categorization without it being stated explicitly in the written etymology. That still doesn't completely solve the "how much etymology" dilemma (do we want to still categorize Cebuano sin as being from Old High Germanic? or Icelandic skunkur from Proto-Algonquian?), but it'd be easier to write concise etymologies without sacrificing categories.
I have a (very) rudimentary outline of what a categorization template might look like here: User:Julia/etycat. Let me know if this is something that people would be on board with, or if anyone has other/better ideas about how we can improve our etymologies. Julia☺☆15:07, 22 September 2019 (UTC)[reply]
Might comment more on this later; I probably prefer etymologies which are decently detailed (e.g. Middle English/High German/Low German/Dutch etc. should at least go back to Proto-Germanic), though I ultimately don't care too much about how it's done as long as categories are kept. One solution would be to have a template which allows users to "expand" the etymology (thus showing the more distant etymology of the respective word) in the manner of Template:grc-IPA (can possibly explain in further depth if you or others don't understand/misunderstand what I mean). Hazarasp (parlement · werkis) 10:46, 24 September 2019 (UTC)[reply]
Certainly, the longer of the two can be cleaned up a bit, and the cognates can be removed, but I do not think we are doing the etymology full justice, as the form of the word comes from *bidilaz but the sense comes from *budilaz, so it is really a merged term. The idea of a categorisation template is great, but I fear that in the end that would just add more work and upkeep. Having the ability to kill 2 birds with one stone (adding the etymology AND cateogising the term at the same time) is a major plus. Leasnam (talk) 17:48, 27 September 2019 (UTC)[reply]
My preference would be to have an expandable etym with as much information as possible. You don't always know what aspect of the etymology will be of interest to the reader (so there would be disagreement about where to draw the line), and it would be annoying to have to click through four different pages to get the entire history of the word. Andrew Sheedy (talk) 20:50, 27 September 2019 (UTC)[reply]
Synophone reference in a Wiktionary definition.[edit]
Homophones, synophones, synographs, & homographs for disambiguation or clarification of unexpected, unexplained, or just subtle, aural or written ambiguity (perhaps treated similarly to rhymes or anagrams).
i.e.: kefir (fermented drink, often mis-pronounced as) v keffer (black beetle, or derogatory racial epithet a'la "N-word") are carefully pronounced differently, but often mispronounced the same.
Is there a standard format for including references to such potential confusions, for disambiguation, when adding a definition?
@Erutuon, KevinUpUser:Erutuon suggested creating etymology languages for varieties that are listed at least somewhat frequently in Descendants sections. Following are my suggestions for etymology languages for these variants:
Serbian, Croatian: sh-ser, sh-cro (Are we sure we want to do this? I can see this being abused.)
Kinyarwanda, Kirundi/Rundi: rw-kin or just kin, rw-run or just run (the shorter forms are ISO 639-3 codes)
Flemish: nl-fle (or nl-vla?) Is this a linguistic (rather than geographic) entity at all?
Glottolog subdivides Flemish: Antverpian (the dialect of the city of Antwerp), French Flemish, West Flemish, East Flemish and Limburgish. We could potentially assign codes nl-ant (Antverpian), nl-fre (French Flemish), nl-eas; the other two already have codes.
Ripuarian, Moselle Franconian: gmw-cfr-rip, gmw-cfr-mos (or are gmw-rip/gmw-mos better?); note also that Luxembourgish (code lb) is a subvariety of Moselle Franconian.
Siglitun, Natsilingmiutut (also Netsilik, Natsilik, Nattilik, Netsilingmiut, Natsilingmiutut, Nattilingmiutut, Nattiliŋmiutut), Inuinnaqtun: These are dialects of Inuvialuktun, which appears to be a language grouped under the Inuktitut macro-language. I don't think I have enough knowledge here to do justice to Inuit varieties.
Thuringian, Upper Saxon German, Erzgebirgisch, Lusatian-New Marchian (or Lausitzisch-Neumärkisch): I feel on uncertain ground here, but we could assign codes gwm-ecg-thu, gwm-ecg-upp, gwm-ecg-erz, gwm-ecg-lus (or shorter forms gwm-thu, gwm-upp, gwm-erz, gwm-lus).
Yeah, but the analogy sh-cha, sh-kaj, sh-tor is good.
Serbian, Croatian: Better not. The mere presence as langcodes reinforces again the impression of there being different languages, the impression which political climate has inculcated, representing borders only 30 years old. If I really want to distinguish I write it out. Additionally assignments to one of the countries only are often tentative. I can have a hard time to say which region of Germany a term is used in, and we wouldn’t create codes for “Hesse German”, “Lower Saxony German”, etc. (although these are separate states). While okay in labels for linking there is less room for uncertainty.
Agreed that having Serbian and Croatian is probably a bad idea. I’m going through some occurrences of these in Descendants and Etymology sections, and almost all are just being used as a synonym for Serbo-Croatian, i.e. they aren’t even characteristic of one national standard or another. Even in the rare cases where we are dealing with a word characteristic of one of these standards, it’s almost never exclusive to that standard — all the more so when we factor in the other two standards (Bosnian and Montenegrin). In sum, the vanishingly small number of cases when these might come in handy as etymology languages is IMO far outweighed by their potential for abuse, as is evidenced by the fact that most preexisting occurrences fell under the latter rather than the former. — Vorziblix (talk · contribs) 15:57, 25 September 2019 (UTC)[reply]
Swiss German: Confusing, there is also a “Swiss High German”, only used in but a single entry, Englishkepi. Apparently to mean Swiss Standard German, while there is “Austrian German” to mean Austrian Standard German.
11–13: Can’t imagine people using them systematically and the dialect areas are uncertain in the borders and vary between maps but okay. Don’t know though why you left out Silesian and High Prussian. There is extensive literature in both, not only on both. If we want a dialectologist to come we need to have all them codes. Fay Freak (talk) 04:55, 25 September 2019 (UTC)[reply]
Regarding Flemish, the term is used in two different senses, which is confusing. Colloquially, it is used for the variant of standard Dutch spoken in Belgium. It is also the name of one of the Dutch dialect groups, which is geographically confined to the historical County of Flanders, an area that today includes French Flanders (a tiny part of France) and Zeelandic Flanders (in the Netherlands). It can be split further into West Flemish and East Flemish. The dialect spoken in Bruges is West Flemish, while that in Ghent is East Flemish. Another Dutch dialect group spoken on both sides of the Dutch–Belgian border is Brabantian; Antverpian is in the Brabantian group. If native Dutch speakers in Brussels speak standard Dutch, they speak Flemish in the colloquial sense, but they are not Flemish speakers in the dialect sense: their dialect is Brabantian. For more, see Dutch dialects. A variegated picture is offered by File:Languages Benelux.PNG. --Lambiam05:57, 25 September 2019 (UTC)[reply]
@Fay Freak, Lambiam Thanks for your comments. I agree about Serbian and Croatian. I didn't intentionally leave out Silesian or High Prussian, I just looked up w:East Central German and copied the four subdivisions listed in the box on the right. I see that the article itself divides things a bit differently and does include Silesian and High Prussian. Based on both of your comments, I'm going to skip etymology languages for Dutch dialects, East Central German dialects and Inuktitut dialects as well as "Swiss German" as I don't have the background to do them justice. Should I also skip adding entries for Ripuarian and Moselle Franconian? I'm not sure if this entry was being referred to. Benwing2 (talk) 15:08, 25 September 2019 (UTC)[reply]
@Benwing2 I've compiled your suggestions into the following table. I made some amendments by using 6 characters instead of 9 characters for the proposed language codes. Of these, I find the Dutch varieties to be most inconsistent. It seems odd for East Flemish to be made an etymology language whereas West Flemish is a full language. KevinUp (talk) 17:27, 25 September 2019 (UTC)[reply]
Including codes for the topolects Belgian Dutch and Surinamese Dutch should not be problematic – although I’m not sure where such codes would be used. For the former, just steer clear from fle, vla and vls. What about nl-blg (not bel to avoid any confusion with Belarusian) and nl-sur (not srn to avoid confusion with Sranan Tongo)? --Lambiam18:25, 25 September 2019 (UTC)[reply]
@KevinUp Thanks! Hopefully if no one objects I can implement them pretty soon. Note that Silesian should be called Silesian German because there's another Silesian (which, depending on your viewpoint, is a dialect of Polish or a distinct language). Benwing2 (talk) 02:28, 26 September 2019 (UTC)[reply]
@KevinUp I went ahead and created etymology languages for the Occitan varieties. I included Aranese, which is a standardized subvariety of Gascon, and I used "Shuadit" instead of "Judeo-Occitan" since that is the name used in Wikipedia and Wikidata. I notice that there are already etymology languages for Guernsey Norman and Jersey Norman, which use the codes roa-jer and roa-grn (when I would expect more like nrf-jer and nrf-grn, since nrf is the code for Norman). I originally followed this convention and used codes like roa-gas for Gascon, roa-pro for Provençal, etc., but then switched to oc-gas, oc-pro etc. as in the above table. I think it's more logical to name etymology languages after their immediate parent non-etymology language instead of after the overarching family, unless there's some uncertainty as to the correct parent (which there doesn't seem to be here). Certainly it is more clear, just examining the code, what it might correspond to (e.g. roa-pro could potentially correspond to any Romance language starting with Pro...), and it reduces the chance of clashes. Furthermore, it makes it easier to construct links, which currently must use the non-etymology-language parent (given the code roa-jer for Jersey, it's far from obvious that you should use code nrf for links to Jersey entries, but much more obvious if the code is nrf-jer). For this reason, I created alias codes nrf-jer = roa-jer, and nrf-grn = roa-grn. If we agree on the principle I've enumerated, we can eventually obsolete the old codes for Jersey and Guernsey Norman, but that is a task for another day. Benwing2 (talk) 07:58, 27 September 2019 (UTC)[reply]
@Benwing2: Thanks for creating the language codes for the Occitan varieties. I noticed that Category:Occitan language has two separate codes for Category:Provençal (prv and oc-pro). Any idea what's going on?
@Lingo Bingo Dingo Hi. Benwing2 is creating etymology-only language codes for several languages to be used in the "descendants" section. We're having some trouble with "Flemish" and its variants. Are you familiar with it?
Would it be relevant to create an etymology language code for Flemish for the purpose of listing descendants? It seems that Flemish refers to a dialect continuum, rather than a single language.
I'm not very knowledgeable about Dutch dialects, so I'll ping some other Dutch contributors @Rua, Morgengave, Mnemosientje, DrJos, Curious, Mofvanes, Voltaigne. In general, I'm not sure whether dialectal etymology language codes are very useful for modern Dutch; though country-specific codes and a code for Brabantian may be useful. But really, you'd have to ask the people who work with etymologies of terms borrowed from these varieties of Dutch.
As noted above, this depends on usage, in everyday language it would mean "Belgian Dutch", but in a linguistic context I'd interpret "Flemish" as meaning "East and West Flemish". It is probably confusing to use it as a synonym of "Belgian Dutch" here.
No opinion, though this might be a rather messy solution if it is intended to cover both East and West Flemish. But such a code for "Belgian Dutch" may be useful.
Thanks for the reply. I think the terms listed under descendants as "Flemish" will have to be checked to determine whether these refer to "West Flemish" or some other variety. KevinUp (talk) 09:52, 28 September 2019 (UTC)[reply]
@KevinUp How do you see the tree of children under "Category:Occitan language"? I found it once and saw the Provençal duplication but I can't find it now. There was an existing entry for Provençal causing the duplication; I tried to merge it with the new one but can't verify that this fixed things. I also changed the language codes for the various Occitan dialects to correspond to the retired ISO 639-3 codes that used to be used for them; hopefully this is OK. If anyone was using the old codes, it will trigger an error, and we can correct them. Benwing2 (talk) 20:09, 28 September 2019 (UTC)[reply]
@KevinUp I added Valencian, Chakavian/Kajkavian/Torlakian, the three Central Nicobarese varieties, Kinyarwanda/Kirundi, and the Sardinian varieties. I didn't add any of the Germanic or Inuktitut varieties as there are issues still to work out. Benwing2 (talk) 20:46, 28 September 2019 (UTC)[reply]
@Benwing2: Thanks for fixing the duplicate language codes for Provençal. I don't know why the language tree at Category:Occitan language was temporarily disabled 12 hours ago but I think the situation is resolved now.
Thanks for creating the etymology codes for these languages. I've updated the codes you used to the table above so that others may refer to it. As for the Germanic and Inuktitut varieties I suppose those will have to wait for another day. KevinUp (talk) 07:53, 29 September 2019 (UTC)[reply]
Can we make the Occitan language codes easier? oc-lnc? Usually dialects are just the first 3 letters, unless you need to disambiguate. --{{victar|talk}}08:31, 4 October 2019 (UTC)[reply]
As someone what works in Occitan, I went ahead and changed them, and are in line with KevinUp's original suggestions. --{{victar|talk}}08:39, 4 October 2019 (UTC)[reply]
Including language name in translation templates[edit]
User:DTLHS suggested I look into translation tables after Descendants. Currently we have translation table entries formatted like this:
This template will automatically display the language name at the beginning, similar to {{desc}}. It will also allow multiple translations to be specified; the extra numbered params in {{t}}, which refer to genders, will be moved to |g= or |g1= (for the first entry; comma-separated if there's more than one), |g2= (for the second entry), etc. I don't think this will add to the Lua load as we already have to load the language tables to retrieve the properties of the language in question. {{tr+}} and {{tr-check}} can be created to mirror {{t+}} and {{t-check}}. Thoughts? Benwing2 (talk) 02:51, 26 September 2019 (UTC)[reply]
Those are script names. {{desc}} handles this using the |sclb=1 param, which says to display the script name in place of the language name; I'd implement the same. Benwing2 (talk) 03:39, 26 September 2019 (UTC)[reply]
Some translation lines have both {{t}} and {{t+}}, e.g. “Roman: nȁdūt(sh), flatulentan” found at flatulent. Won’t mixing {{tr}} and {{tr+}} duplicate the language name? Perhaps encode this as {{tr|sh|nȁdūt|+|flatulentan}}? Template {{label}} is an example of a template processing its parameters sequentially but not entirely independently, so this should be possible. The issue also arise with lines that have both {{t-check}} and {{t+check}}, e.g. “Esperanto: (please verify)kabano(eo) (1,2), (please verify)kajuto (on a ship)” found at hut. --Lambiam10:53, 26 September 2019 (UTC)[reply]
I'm quite happy with the format of our translation sections as it is now. I like that the translations are atomic and that you can add a literal translation and other data (e.g. a qualifier) per translation. Furthermore the TranslationAdder Gadget would need to be changed to support such a change.--So9q (talk) 13:51, 26 September 2019 (UTC)[reply]
@Lambiam That's a good point. The alternatives are either to use a format like you mentioned (or alternatively something like "{{tr|sh|+nȁdūt|flatulentan}}"), or use the format "{{tr+|sh|nȁdūt}}, {{t|sh|flatulentan}}" similarly to what is currently done with {{desc}} and {{l}}. Benwing2 (talk) 14:26, 26 September 2019 (UTC)[reply]
@So9q If we were to combine the translations as I suggested, literal translations and qualifiers per translation would be supported with |lit=/|lit1= for the first one, |lit2= for the second one, etc. and |q=/|q1= for the first one, |q2= for the second one, etc. I'm aware that the TranslationAdder Gadget would need fixing; if the format change is agreed upon, I (perhaps with User:Erutuon's help) could make the change. Benwing2 (talk) 14:31, 26 September 2019 (UTC)[reply]
Nice to hear you are committed :) (I made my own improved version of TA FYI). I now see this as a possible improvement because the template would prevent people from adding weird stuff to translation sections like qualifiers before the term etc.
As an aside currently some translations have <\!-- html-notes and hidden translations also which we should also decide if we want to do something about. @erutuon could you make me a list of articles with <\!-- in the translation sections to have a statistic of how many there are?--So9q (talk) 14:45, 26 September 2019 (UTC)[reply]
@So9q: Here's the list of mainspace titles in which a Translations section contains a HTML comment. (Edit: Here's a version with the comments shown, if you want to search for translation templates inside of them.) — Eru·tuon17:57, 26 September 2019 (UTC)[reply]
Swedish Wiktionary's entry 'europeisk' had 16 translations, but Ukrainian (uk) was not among them, so I went via English Wiktionary's entry European and found it to be європе́йський. While I was there, I also added some other translations (be, bg, cs, el, eo, et, gl, hu, sk, sl, sq, sr, tr), increasing the number from 16 to 30. This is something I've been doing several times a week for the last couple of years. Sometimes en.wiktionary is missing a translation, which I can add.
Perhaps I should have copied the whole section from {{trans-top}} to {{trans-bottom}}? And not only to sv.wiktionary but also to a couple of other languages? Or a network of bots could do that and also discover any inconsistencies. This sounds, of course, exactly like the old interwiki link bots that were running on Wikipedia less than a decade ago. So, should we do what Wikipedia did and move the entire translations sections into Wikidata? Or are there any other tools (bots? toolserver tools?) that can assist in spreading translations?
(Of course, having done this manually already, I fully understand the difficulties in determining whether the translation sections are for the same sense of the word. For a word like 'European' (adjective, pertaining to Europe) this is the case.) --LA2 (talk) 13:28, 26 September 2019 (UTC)[reply]
Don't blindly copy translations if you have no idea about the language in question. No bulk-copying, please. Will you be able to tell if a word is used in the wrong form? E.g. feminine, instead of masculine (lemma), or a noun instead of an adjective? --Anatoli T.(обсудить/вклад)13:39, 26 September 2019 (UTC)[reply]
Bad idea, if you do that the dictionary becomes like any translation memory. Bots don’t see the nuances, don’t see if a term becomes slightly different across languages. Fay Freak (talk) 13:50, 26 September 2019 (UTC)[reply]
That's why I only added translations to 14 European languages using Latin or Cyrillic script, where I can determine what is reasonable and not, and refrained from adding translations for various Asian languages. But still, it was a lot of copy-and-paste that could have been made easier by a tool. If you see any translations that you know are wrong in the entry European, you can remove them at any time. If you see any that are wrong in the Swedish Wiktionary, you are of course welcome to discuss this in the Swedish Wiktionary. --LA2 (talk) 15:12, 26 September 2019 (UTC)[reply]
The answers I get here indicate a lower level of maturity than I had hoped for. I conclude that no such tools exist today. Well, fine. --LA2 (talk) 21:42, 26 September 2019 (UTC)[reply]
Are you giving up on us? 😃 Actually I like the idea of a tool to do this as I have done similar copying myself. I suppose we could start with all all words having only one sense in the translation section of both wiktionaries. Could you help me write some pseudo code for this?
customTargetWikt = en
customSourceWikt = sv
languages = [list of 14 languages you feel confidence with]
articles = [European, Caucasian]
for i in articles do
look up target translation section
check only one section
split into array by line
look up source tr section
check only one section
split into array by line
compare the two and show form
end
form
give user checkboxes for each line to be copied
submit
for i in checked box do
add the lines to targetwikt section
Another consideration beside the ones mentioned above is that copying without attribution is technically a violation of Wikimedia's Creative Commons license, though normally it's too minor to make any practical difference. Systematic, mass copying might be pushing the boundaries a bit, though.
To do it properly you would need to mention that it's copied in your edit summary and the page you got it from. That way it's possible to trace the edit history back to the original contributor. Chuck Entz (talk) 04:51, 27 September 2019 (UTC)[reply]
This week, I found that some IPv6 has vandalized Thai entries. They usually add misinformation and delete partial content on the entries. Sometimes, they vandalize other language that uses Thai script. Please keep an eye on them. --Octahedron80 (talk) 03:09, 28 September 2019 (UTC)[reply]
Dispute resolution and reporting bad behaviour[edit]
I've consulted Help:Dispute_resolution.
It is very short, and quite lacking. Wikipedia:Dispute resolution is quite good and thorough. The options are clear, and it goes through all the possibilities. Here on Wiktionary, however...
First of all, no one uses discussion pages (why are they called "discussion" here, but "talk" o Wikipedia, BTW?). What's the point of them being there, if they aren't used? Also, this means that you don't have a clue as to if/what discussion has happened, in regards to an entry, unless you comb through the Beer Parlour (and maybe some other places?)
...and how/why is anyone supposed to even be aware of those options? Not only does this make discussion needlessly convoluted, but also essentially hidden (to any who do not make the effort to make themselves educated about the system)
...which is completely contrary, to the whole idea of Wikimedia's sites. Granted Wiktionary is a somewhat different thing to Wikipedia, but I fail to see how that could possibly explain this, or any other reason for why this is a better way of doing things, here.
Help:Dispute_resolution is very brief. Brief to the point of barely saying anything. Also, concerning the line "talk to a friendly Administrator"... How would one even begin to do so? Who should you choose? On Wikipedia, you have noticeboards to bring things up on, that are checked by admins. That system it good and simple, and works perfectly well. Why isn't it like that, here?
...and that line is only about someone who keeps pestering an editor. What about the great multitude of other, bad/destructive/disruptive behaviours, none of which are mentioned or addressed? Does this mean that you are fine with (and thereby, in effect, encourage) any bad behaviour, outside of someone pestering another?
Vandalism, edit warring, abuse of power... these are all perfectly acceptable things to do? After all, there are (apparently) no consequences.
You have nothing like Wikipedia's Dispute Resolution Noticeboard, which are there to mediate a discussion, when it is found to not work, with just a normal talk page discussion. An excellent tool, that performs its function quite well.
We have the occasional problematic editor, but nothing like on Wikipedia. Administrators tend to block trolls and edit warriors, and that is it. The more rules and defined processes you have for dispute resolution (like on Wikipedia), the more you invite wikilawyering and people trying experimentally to find the boundaries of acceptability. The disputes we have are about technical issues and the emotions do not run high (except for the occasional, rare, problematic editor). Given this actual state of affairs, I feel Help:Dispute resolution is adequate. For example, if you question how a term is defined, bring your concern to RFV. All administrators are friendly (if you are courteous and not trolling). I’ve never felt a need to contact one (in their capacity as administrator), but if the need arose I‘d pick one who is knowledgeable about the matter the dispute is about. --Lambiam00:28, 29 September 2019 (UTC)[reply]
"Administrators tend to block trolls and edit warriors, and that is it."
They can only do so, if they know about it ...and they can only know about it, if people report it. There is, however, no real way to do so.
"the more you invite wikilawyering"
As opposed to not having the faintest clue, as to how to go about things? No idea if what they do is okay or not? Wikilawyering is easy to deal with. Complete confusion isn't.
"and people trying experimentally to find the boundaries of acceptability."
If you have no boundaries, then people are guaranteed to breach them. Intentionally or not. Having boundaries lets good faith editors know, how to go about things. Those who would experiment around the boundaries, will do so either way.
"I’ve never felt a need to contact one (in their capacity as administrator), but if the need arose I‘d pick one who is knowledgeable about the matter the dispute is about."
...and how would you know, which one that would be? (if it's just if they know the language... you'll generally still end up with many different options) You, specifically, might, but not everyone does. Especially someone new, who would be completely clueless. If, on the other hand, there was a noticeboard admin issues (maybe just the one, where Wikipedia would have many separate ones, due to the smaller number of people, but nevertheless a noticeboard), then it would be a simple matter. How/why would it be better to ask people to chose an admin, from a long list, without having the faintest clue?--213.113.49.18003:02, 29 September 2019 (UTC)[reply]
Old discussions of words in the Tea Room, RF… rooms, and other such pages are generally archived to the talk pages of the words in question after they’ve been resolved, so checking the talk pages should show you the relevant previous discussions, if there were any. Talk pages of entries are also sometimes used to ping specific editors for help with the word in question (using e.g. the {{ping}} template). What they are not used for is community-wide ongoing discussions of particular entries; those should be brought to the Tea Room or one of the various RF… pages, as appropriate. The reasoning behind this is that our community is small enough that posts on entry talk pages usually go unnoticed, so unless you’re pinging some specific editor, it doesn’t make much sense to post on entry talk pages.
As for how anyone is supposed to be aware of the options, the Main Page prominently links to the Community Portal and Discussion rooms, where all of them are listed — not exactly ‘hidden’ IMO.
We don’t have noticeboards because there’s never been much of a need for them; all the main discussion rooms are checked by admins anyway, and problems usually get brought up there if not on individual user talk pages. For newcomers we have the Information desk specifically set aside for them to raise questions and concerns. More experienced users typically know which admins are working in their field (once again, the community is very small). — Vorziblix (talk · contribs) 02:15, 30 September 2019 (UTC)[reply]
"What they are not used for is community-wide ongoing discussions of particular entries"
Community-wide? What are talking about? Who said anything about anything that is community-wide? Talk pages are never used for anything that is community wide. You appear to be completely ignorant of why they exist, why they were made (in both MediaWiki, which Wiktionary and other Wikimedia projects use, and other Wiki systems), and how they are used. (in pretty much all other Wikis, aside from Wiktionary)
Talk pages are for discussing how to edit the specific article/entry they are connected to, with the others who edit that specific article/entry. No more, no less. There is nothing community wide about it, in any way, whatsoever ...nor is there, usually, any need for it to be.
For the rare occasions when a discussion needs to go wider than that, or if certain dispute resolution system is used (such as a discussion being taken to a Dispute Resolution Noticeboard), then a link to it is added there, with the wider discussion being done in the relevant place for it. (though there are certain efforts for widening things, where it still remains in the talk page, such as Wikipedia's system for "request for comment", to take a relatively common example)
"The reasoning behind this is that our community is small enough that posts on entry talk pages usually go unnoticed, so unless you’re pinging some specific editor, it doesn’t make much sense to post on entry talk pages."
If more than one person edits an entry, then all those editors would notice edits to the talk page. Hence, the talk page would not go unnoticed. If there are no other editors, then there cannot possibly be any disputes, regarding how to edit the entry, and thus no need for discussion. Given that, your argument doesn't really make any sense. Granted, questions and requests, rather than discussions on how to edit the entry, would face the problem you mention ...but that could be solved with a notice on the talk pages (including when you create one), pointing that out, and pointing people to where such things should be stated. It does not, however, apply to discussions. At all.
"As for how anyone is supposed to be aware of the options, the Main Page prominently links to the Community Portal and Discussion rooms, where all of them are listed — not exactly ‘hidden’ IMO."
First of all: Who ever visits, much less reads, the main page of any Wikimedia site? People can, if they seek answers, look at the bar to the left, but the main page? No.
Secondly: Why do you expect that everyone does a thorough search, and plenty of reading? Why have such a steep learning curve? I'm relatively good at these things (and have plenty of experience in looking up such things, from Wikipedia, where I used to edit regularly. Something I should see about getting back to ...but that's not relevant to this discussion), and have looked up and read the articles you mention ...and I still don't get it. At all.
"We don’t have noticeboards because there’s never been much of a need for them"
You don't have need for one. That doesn't mean there isn't a need for one. When instructed to talk to an admin ...and then be faced with a long list of people, having not the faintest clue, as to who to pick, and thus be stranded not knowing what to do... (whereas having an admin noticeboard, where you put stuff for admins, and any admin who knows they are appropriate to deal with the particular issue, can chime in, would have solved the issue, perfectly well ...without making things any more complicated or effortful, for the admins, in the least)
How is that a situation, where "there is no need"?
"all the main discussion rooms are checked by admins anyway"
"and problems usually get brought up there if not on individual user talk pages."
If it is brought up in an individuals talk page, that doesn't mean that it gets proper attention ...and according to all the info I have been able to find, this is not the proper place, for reporting bad behaviour. Admins are. If you're saying that's not correct, then you are stating that the information on Help:Dispute_resolution, Wiktionary:Beer_parlour, and other articles on Wiktionary, is fundamentally wrong.
"For newcomers we have the Information desk specifically set aside for them to raise questions and concerns."
If people have to ask about basic issues, that means that the information is not clear and/or easily accessible/"findable".
"More experienced users typically know which admins are working in their field (once again, the community is very small)."
...and those who aren't "more experienced", should be left to fend for themselves, having no clue, whatsoever?
Wikipedia has the guideline of "Please do not bite the newcomers", and generally talks about striving, in both rules and the desired behaviour of editors, to make things easier for the new/ignorant.
Does Wiktionary have the opposite view: Do everything for the experienced editors, and don't give a damn about newbies? Make it difficult to know how things work? Surely not?--213.113.49.3404:34, 1 October 2019 (UTC)[reply]
Our experience with newbie contributions, especially in English, seems to be trending toward lower and lower net value. We have fairly high levels of coverage of terms, so new definitions offered by newbies are increasingly wrong in some way. We have more and more templatization and standardization, both documented and undocumented. These make it a bit difficult for a newbie to help without taking the time to learn.
I suppose that we are much less interested in process than WP is. Many of us are escapees from WP. I certainly find WP not worth the time and aggravation, largely because of the elaborate processes and what feels like consequent wikilawyering. DCDuring (talk) 05:07, 1 October 2019 (UTC)[reply]
"Our experience with newbie contributions, especially in English, seems to be trending toward lower and lower net value."
That is a sign that you're clearly going in the wrong direction.
"We have more and more templatization and standardization, both documented and undocumented."
You say that you are, and wish to be, simpler than Wikipedia ...but also that you are, and should be, far more complex than Wikipedia? Also, if you have standards and templates, what justification is there, for any of these to be undocumented?
I suppose that we are much less interested in process than WP is.
Having less documentation and clear and efficient systems, does not mean that you get less process (in fact you get more). Just more confused process. Any less process you have, is purely due to having less people.
"Many of us are escapees from WP. I certainly find WP not worth the time and aggravation, largely because of the elaborate processes and what feels like consequent wikilawyering."
I fail to see anything all that elaborate, about how things work at Wikipedia ...and how/why does not having any rules, stop malicious behaviour? You probably get a lot less wikilawyering and other bad behaviours, but only because so few bother to edit Wiktionary. Especially those who just want to disrupt. (who are more prone to go to bigger places)--213.113.49.3413:04, 1 October 2019 (UTC)[reply]
What exactly do you mean? (also: there are several specific complaints, in what I have written)
"or do you just wish we had a process that was to your taste?"
I deeply resent your suggestion. I see that Wikipedia's policy of "Assume good faith" (which I find, is a rule one should follow, not just on Wikipedia, but generally) is not shared by Wiktionary.
I am not asking for things to be to "my taste!" I am asking for things to make sense! To be intelligible. To be as good as they can.
If you think my arguments are invalid, if you think the current system (and the articles that describe/explain it) is better than what I suggest: You are free to argue against what I say. I always welcome honest and reasoned criticism. If anyone shows me that I am wrong/mistaken, I thank them, as they have not only taught me something, but also (far more importantly) rid me of a misconception.
However, I would ask you to refrain from making baseless ad hominems, or any other blatant and obvious fallacies.
Criticism that isn't, however, isn't something I am willing to put up with. (and can anyone make a reasonable case, for why anyone should?)--213.113.49.3413:04, 1 October 2019 (UTC)[reply]
I have no idea what you are referring to, by "WMF". The one single thing I can see, is that you are dismissing what I've said, out of hand, with mere baseless insults and ad hominems. I have done nothing to earn your insults (as you yourself implicitly admit, by making no arguments aside from ad hominems that you don't even bother to back up. Not that ad hominems are okay, even if the criticism in it has any basis, but still...), and even if I did, the way in which you make your accusations, still flies in the face of WT:Civility. Quite unlike any of the other replies, I've gotten here in the Beer parlour. Given how public this discussion room is, I would hope someone picks up on this fact, and acts accordingly. Either way, I see no reason to respond further, to anything you say, as long as you chose to behave in a clearly hostile/malicious manner, which only seeks to hurt/anger/dismiss, rather than resolve/explain/debate.--213.113.49.3416:27, 1 October 2019 (UTC)[reply]
Ignoring all else which has been said, I agree that the Dispute Resolution page language is unhelpful and not particularly relevant to the current state of the project. I have started a draft for new language aiming to be clearer and more helpful to those not as familiar with the project at Help:Dispute resolution/update. - TheDaveRoss15:08, 1 October 2019 (UTC)[reply]
Looks a lot better.
Solves the problems with the "contact an admin"-bit and a lack of a notice board(s) for issues, by making the Beer Parlour serve those functions instead, which I guess could work.
I notice, though that your draft instructs people to use talk pages, just as other wikis do. This would involve a fundamental change in policy. One I would approve of, as is obvious from what I've written, but given how that goes against how things have been done here, for so long (not to mention the comments about it, in this section), I'd say getting that through may take some doing. (on that note: When I created this topic, I didn't exactly expect to convince everyone, straight away. I expected to mainly get opposition. To start with, and maybe also at the end ...but even then, I might push some a little, plant a few seeds... "A journey of a thousand miles begins with a single step". Well, hopefully not a thousand miles) Also, as it is not, at least not yet, the policy of Wiktionary, I'm unsure if I should have made this reply on the talk page of the draft, or here, so... I figured the safest option was to comment here. For now, at least.
Furthermore, your list and description of discussion rooms fails to mention where one should bring up discussions of how exactly a given word should be defined. (see the other topic I made here. I'm not entirely confident that the response I got, was completely correct. The responses to my RFV hasn't been that it's in the wrong place, but I'm not sure if that's because it is the right place, or because people let it slide, or something)
Still: As I said, it's a clear improvement, IMO. A good start.
...but given how every one else has responded here, I'm not too hopeful about it getting implemented. (I hope I'm wrong about that) After all, it would appear to be completely counter to the opinions of everyone else who has responded to me, so far.--213.113.49.3416:27, 1 October 2019 (UTC)[reply]
It should be based on "sticks and stones may break my bones but words will never hurt me". If somebody starts "doxing" (posting real-world info) then shut it down fast. Otherwise, who cares. Equinox◑16:11, 1 October 2019 (UTC)[reply]
So bad actors should just be ignored? Be allowed to behave badly? Granted, it may be sensible for normal individuals to ignore bad actors, but if admins don't at least tell them off, in some way, if it's not marked as unacceptable behaviour, how is that not an implicit approval of the bad behaviour? (and also implicitly telling the victims, that you're fine with them being treated like that? That, if anything, they are the ones at fault?) ...and does that not make a complete lie, out of WT:Civility? Making it a rule that isn't worth the paper it isn't written on?
Furthermore, while bad actors can easily be ignored, in a place like here in the Beer Parlor, what about when editing a Wiktionary entry?
...oh, and I've always found the saying "sticks and stones may break my bones but words will never hurt me", to be a rather ridiculous saying. After all, physical injuries heal easily. Injuries to the heart, however... not that I'm hurt by foolish insults from some random guy on the internet. Why would I care what they say? ...but the principle still stands: Emotional pain is no less serious than physical pain. On the contrary, it can often be far more long lasting and harder (or, indeed, impossible) to heal.--213.113.49.3416:41, 1 October 2019 (UTC)[reply]
I'm glad you find us ridiculous. How about you do some actual work of any kind here, then we will take you seriously, if you're lucky. Equinox◑16:50, 1 October 2019 (UTC)[reply]
Sarcasm is not exactly civil. You have yet to show any evidence, that I have been malicious or unconstructive, in any way (not that you've even attempted to try), or at all uncivil (unless you count the instances, where I point out clear evidence of incivility, in others ...but if you can't do that...), nor have you made any attempt to rebut any of my arguments. (though I am, of course, not claiming that no one has. There are others who have engaged in discussion ...not counting DCDuring, as he/she has clearly chosen to abandon that, in favour of mere ad hominems and slander. Not that DCDuring's tone sounded particularly civil before then, though it wasn't enough to surpass the assumption of good faith ...other than in retrospect)
And then you baselessly, and very falsely, claim that I haven't done any work on Wiktionary.
There is my edit to なぎなた (which was apparently reverted, for no apparent reason), なた (which, to be fair, Eirikr replaced with having it take its info from 鉈, which is a clearly better solution ...but that was clearly spurred by my edit, and it was one, that did the same as mine did, just that it now automatically updates to reflect any future changes), 提げ物 (which was reverted, for no apparent reason ...though the current version does contain my change of meaning, if not my exact wording. Thus my edit was apparently deemed legitimate, and led to improvement), 鉈, 薙刀, 蜜柑 (even if you should chose to dismiss what got reverted, I still got some stuff through), 長刀, 余り, 全然, みかん, 眉尖刀, shield, 太刀, billhook, my creation of 鉈鎌 and 剣鉈 (I've been tempted to also create 大鉈 and 腰鉈, but at the moment, that would have to wait for the RFV on 鉈 to be settled first)... I had forgotten a bunch of those, until I looked them up. I'm kinda surprised at the length of that list. I think that covers all of my recent edits. (I've done a rare few edits before. Dunno what happened to those. Don't remember them)
As I told DCDuring: Make a proper response, and I'll happily reply, but I will not dignify any further responses from you, if they continue to be like this. It would be pointless.--85.229.232.8209:03, 2 October 2019 (UTC)[reply]
I fail to see how an anonymous person posting lengthy arguments about how everything should be different, and dismissing various major editors on the site, is particularly constructive. We're not going to change everything, and by being so broad, you're just causing distraction instead of ultimately producing change.--Prosfilaes (talk) 09:58, 2 October 2019 (UTC)[reply]
"I fail to see how an anonymous person"
My being anonymous, is completely irrelevant. It's no more than an ad hominem.
"lengthy arguments"
Well, it's big issues. I do want to be concise, but... it's not really possible to cut these things down, and still keep the important bits. (also, I'll freely admit that I'm not that good at being concise)
"dismissing various major editors on the site"
You are talking about people who clearly dismissed me, out of hand, whilst blatantly going against WT:Civility and WP:Assume_good_faith. People who show that they are not, at all, interested in honest reasonable debate ...and, as I've stated clearly, I only dismiss any further comments they make if they continue to display such behaviour. As soon as they behave in a civil, honest, and rational manner, I'll be fine with responding. Anyone who behaves in such a manner, will never have any problems with me. Disagreements, sure, but not problems. (maybe a bit of problem, due to misunderstandings, but as long as they're civil, honest, and rational, those should be easy to clear up, so...)
"We're not going to change everything"
Not until/unless you are convinced, no ...and as the system has been this way, for a long time, you're (note: plural you) no doubt set in your ways and convincing you would take some doing. Probably won't happen overnight ...but the number of issues that have gotten changed, over time, due to it being brought up for debate, now and again, is astronomical.
Also, I assumed that bringing it up, would make you explain your reasons. (which is good, both for me to learn them, and for you to think about them more) Something that has only partially happened. I've mostly not gotten any further responses, beyond a first one, from editors, which makes things very superficial. You don't really get any proper understanding of things, that way, nor does any actual discussion get started, in any meaningful way.
"by being so broad, you're just causing distraction instead of ultimately producing change."
I don't agree about it being broad.
As for a distraction... All debate is distraction. If you want to create change, you have to distract. That's just how it is. That is no excuse for shutting down debate, at the first sign of disagreement. If you disagree, make counter-arguments. Present contrary evidence. (concerning the issue at hand! Not the people involved) When you've talked through all issues, go with the consensus. Even if you think it's wrong. (there have been some Wikipedia discussions that didn't end up with the result I wanted ...but as long as everything was done properly, I've always been fine with it) That's how things should go.
Dismissing a persons arguments, out of hand, for no other reason than a baseless assumption of bad faith or just strongly disagreeing/disliking, is not a valid approach.
An echo chamber, does not lead to progress. It leads to stagnation.
...and how could you be sure if this hasn't done anything to lead to change? Sure, change hasn't happened, straight away, but that's just the short-term result.--85.229.232.8212:04, 2 October 2019 (UTC)[reply]
What discussion? None of you, has bothered to actually try to discuss. "Two monologues do not make a dialogue." - Jeff Daly
It takes two to tango ...and so far, I'm the only one trying to "dance". (i.e. discuss ...and no, taking just one or two steps, doesn't even begin to be a dance) ...or can you demonstrate otherwise?--213.113.50.17301:34, 3 October 2019 (UTC)[reply]
WT:RFC vs WT:RFV vs WT:RFV. What does WT:RFV do? Where can you get help with discussing the definition of a word?[edit]
Help:Dispute_resolution states that WT:RFC is for stuff like formatting, example sentences and trivia. WT:RFV is for things like content, definitions, synonyms, pronunciation and etymology ...and WT:RFD is for determining if the word exists or is relevant. (notable?)
Thus I must conclude that if one seeks help with a discussion/dispute concerning the definition/meaning of a word, it should be posted on WT:RFV.
...but on WT:RFV, however, it states "This page is for disputing the existence of terms or senses. It is for requests for attestation of a term or a sense, leading to deletion of the term or a sense unless an editor proves that the disputed term or sense meets the attestation criterion as specified in Criteria for inclusion/.../", which is a direct and complete contradiction of what Help:Dispute_resolution says
...and leaves anyone seeking help with a discussion/dispute concerning the definition/meaning of a word, with nowhere to go.--213.113.49.18021:05, 28 September 2019 (UTC)[reply]
WT:RFV is the right place if you would like to dispute that a term has a given definition. It says "[This page] is for requests for attestation of a term or a sense". Sense is another word for a definition. — Eru·tuon22:51, 28 September 2019 (UTC)[reply]
The tea room is where you would discuss definitions for senses that you don't want removed, including challenges to their validity. If you want to challenge whether a definition matches usage (as a descriptive dictionary, we go by usage rather than authoritative references), you would use rfv As for your other comments/questions: Wiktionary has far fewer active users and admins than Wikipedia, so we can't afford the kinds of bureaucracies and detailed procedures that Wikipedia has. Also, we're a dictionary, so there's a far smaller amount of allowable variation in content: definitions are concise, streamlined and and more telegraphic in style. Your original version of the definition was a fairly decent short encyclopedia paragraph, but rather wordy for a good dictionary definition.
As for the nature of your interactions: the edit comment that says "please leave a message on my talk page" is automatically inserted by the rollback tool and can't be changed for an individual edit, so you shouldn't read too much into it. Please bear in mind that we have 6 million entries and 97 admins- both active and inactive (which explains why posting on talk pages isn't very effective). Of course, most of those pages aren't being edited, but we have well over a thousand new edits that need patrolling every day. Only a handful of the people who patrol those edits know enough Japanese to spot problems, and Eirikr is the only admin among those who regularly spends a substantial amount of time on it.
All of our patrollers are overworked, but it's especially bad with Japanese. Eirikr could have handled your case better, but it's a bit much to leave an outraged, screaming "ALL CAPS" message after less than a day. Not only that, it dramatically raises the stakes, and therefore the amount of time and attention needed for a proper response. Leaving a wall of text on someone's talk page after that and then characterizing a fairly detailed reply as a non-response because it didn't categorically and decisively refute every point doesn't strike me as very helpful, either.
The bottom line: regardless of whether you're right or wrong, the amount you've contributed so far vs. the amount of time spent by a knowledgeable editor responding to your demands leaves me wondering if you'll ever be worth the time taken away from improving our Japanese entries- right now, you're more of a time-sink than an asset. I hope I'm wrong, but it doesn't look too promising. 00:36, 29 September 2019 (UTC)
So it would appear that WT:RFV is right, then? Then the article should be rewritten, to be less confusing. Again, I quote "Overview: This page is for disputing theexistenceof terms or senses. (original emphasis) It is for requests for attestation of a term or a sense, leading to deletion of the term or a sense (emphasis mine) unless..../". In other words, it indicates that it is about removing a term or sense. Not modifying, adjusting, or changing it. Just deleting.
"Wiktionary has far fewer active users and admins than Wikipedia, so we can't afford the kinds of bureaucracies and detailed procedures that Wikipedia has."
That makes no sense. Sure, it might explain why you don't have as many boards, as they do, but it does not explain having none ...and it does nothing to explain the non-use of discussion/talk pages.
Also, we're a dictionary, so there's a far smaller amount/.../"
Everything you mention hereafter, is completely outside of what I brought up. It is completely off-topic and irrelevant, to the issue at hand. Important, sure, but this isn't the place for it. You could have responded, where I have discussed it (or somewhere else more appropriate, and point me there), but certainly not in an unrelated topic, such as this. Therefore, I will not respond here. (do it at an appropriate place, and I'll be happy to)--213.113.49.18002:50, 29 September 2019 (UTC)[reply]
I think it is better that we showed the gemination in Latin words, using ◌ː in their narrow transcription, instead of showing the phonemes one after another. For example, for bucca, what is /ˈbuk.ka/ in its broad transcription can be transcribed phonetically as [ˈbʊkːa]. Pinging @Fay Freak & @Brutal Russian for this. —Lbdñk (talk) 11:15, 29 September 2019 (UTC)[reply]
@Rua: It remains in the broad transcription; to make up for its loss in narrow transcription, we could show the hyphenation for the word (eg. buc‧ca) in the pronunciation section, as is done in entries of modern European languages, where, I have seen, the syllable division is not much cared about. —Lbdñk (talk) 12:19, 29 September 2019 (UTC)[reply]
Curiously enough, the current Italian transcrption goes with the double spelling - bocca. Why does la-IPA have syllable division, any way? I think it either should go altogether, or the double consonant be left spelt double. Brutal Russian (talk) 15:19, 29 September 2019 (UTC)[reply]
@Lbdñk: I'd be fine with it, but only if all syllable divisions in the IPA are dispensed with. Otherwise consistency demands geminates be also divided. I don't feel particularly in favour of either option, but dividing syllables in the IPA doesn't seem like a terribly common practice, as you say, especially when it's already done in the phonemic transcription. Brutal Russian (talk) 20:49, 30 September 2019 (UTC)[reply]
For phonetic transcription, I don't care whether geminates are transcribed like [t.t] or like [tː]. While omitting the syllable division mark in this context and not in others is a little inconsistent, it doesn't remove information from the transcription, because Latin geminates predictably contain a syllable division. (For comparison, the stress mark also unambiguously indicates a syllable division, and so an explicit syllable divider is not used next to it.) I am in favor of keeping the syllable division mark in other contexts, and in all contexts in Latin phonological transcriptions (I don't think Lbdñk was suggesting removing them in this context, since the original post in this thread mentioned using /ˈbuk.ka/ alongside [ˈbʊkːa], but I'm not sure whether Brutal Russian was talking about replacing /ˈbuk.ka/). Syllabification of consonants is relevant to Latin scansion: a syllable with a short vowel is heavy if it ends in a consonant, but light otherwise.--Urszag (talk) 22:46, 30 September 2019 (UTC)[reply]
@Urszag: I agree with you that using ◌ː is not goin' to make the syllable division ambiguous, and your point is so good. And obviously, we cannot do without syllabification owing to its phonological and metrical significance. So, by my proposal, syllabification would always be shown in broad transcription; in narrow transcription, only geminates would make the exception. Therefor, with your backing, I am thinking of starting a vote for representing geminates with ◌ː in narrow transcription. @Brutal Russian, I will need your backing too. —Lbdñk (talk) 18:02, 1 October 2019 (UTC)[reply]
@Urszag, Lbdñk: If one knows how to divide Latin words into syllables, nothing will make syllable division ambiguous to them since as you say, it's by and large predictable - two consonants make two syllables unless mūta cum liquidā. If one doesn't, there's nothing obvious about a geminate consonant being split - Southern Italian even has initial geminates. But forget that, I'm not suggesting we dispense with them in the phonological transcription - just in the phonetic one, if and since we're at it. I simply don't see for the sake of what we want to introduce the inconsistency, while on the other hand consistency is a reason onto itself. Is there a single other language on wiktionary whose IPA features syllable division? Brutal Russian (talk) 23:10, 1 October 2019 (UTC)[reply]
@Brutal Russian: Well, the Sanskrit template is the only one listed above that generates a phonetic transcription with syllable division. The others generate phonemic transcriptions. [Edit: I went through Category:Pronunciation templates and the only other example was {{mnc-IPA}}. So it's pretty rare. There were many more phonemic transcriptions with syllable division than phonetic.] — Eru·tuon23:30, 1 October 2019 (UTC)[reply]
@Erutuon: I see, thanks. I don't know whether Manchu has double consonants, but the Sanskrit transcription - seemingly the ony one with syllable divisions both in phonemic and phonetic - likewise spells them double: सत्त्व(sattva). Brutal Russian (talk) 12:09, 2 October 2019 (UTC)[reply]
@Brutal Russian: So coming back to the original topic, whatever steps be taken, I am against simply using phonemes one after another for geminates in narrow or phonetic transcription. Even {{sa-IPA}} is doing much better in this aspect in that, in words like सत्त्व(sattva), while transcribing diagraphs (here त्त्) the first consonant is being shown with an unreleased stop, thereby making the transcription perfectly phonetic, while at the same time not getting rid of syllable break. Whereas in Latin the transcription is misleading: [k.k] is too scanty in phonetic transcription, and is acceptable only in broad or phonemic transcription. —Lbdñk (talk) 18:44, 2 October 2019 (UTC)[reply]
@Lbdñk: First, I don't think that the phonetic transcription that we give for Latin has to be narrow. In fact, I'm a little leery of the goal of giving a narrow transcription for Classical Latin pronunciation, because since it is reconstructed, there are always going to be gaps in our knowledge of the phonetics. It's not as problematic as trying to give a phonetic transcription of, say, Proto-Indo-European, but there are a few places where I think the current transcription for Latin is already too narrow—specifically, the transcription of [kʷ] as fronted [kᶣ] before front vowels (Allen's argument for this fronting is not implausible, but I think it's inconsistent to transcribe this detail while leaving out other plausible details of similar specificity, like the "sonus medius", or the probable existence of allophonic fronting of /k/ and /g/ before front vowels). Second, I don't really understand what's misleading about using [k.k]. This transcription doesn't imply that the initial [k.] is released; it doesn't specify that it is unreleased either, but that ambiguity is not a flaw in my opinion because we can only guess about whether Latin speakers ever used a distinct release for the first half of a geminate.--Urszag (talk) 23:34, 2 October 2019 (UTC)[reply]
Why isn’t there a sign for syllable break inside a segment, if syllable break is suprasegmental and can occur during a segment? We need some kind of combining character below geminates. It is ugly and distracting anyway to have that dot (U+002E FULL STOP) between syllables. It appears to be baggage of the typewriter age. In suprasegmental analysis one uses many signs below and above a line if one is able to, as particularly in handwriting. If you see the full-stop in published works denoting a syllable break it is not unrestrictedly a standard. Fay Freak (talk) 12:50, 2 October 2019 (UTC)[reply]
@Lbdñk As you see the syllable break can be inside a geminate consonants signified by Xː but we cannot put the dot inside it. It is suprasegmental anyhow! Hence there must be a mark below or above the line. Also, doesn’t one normally use a middle dot for this purpose? At least that’s what I have seen in many dictionaries though not necessarily in IPA. Fay Freak (talk) 19:06, 2 October 2019 (UTC)[reply]
@Fay Freak: I had already stated above my proposal for such problems as this. Repeating it again: syllabification would always be shown in phonemic transcription, so if we cannot show the syllable break inside a geminate in phonetic transcription, then there is no problem, as the phonemic transcription would be showing it anyway (/ˈbuk.ka/ versus [ˈbʊkːa]). —Lbdñk (talk) 19:34, 2 October 2019 (UTC)[reply]
@Lbdñk That is confounding, though not necessarily for me. I have seen people passing by and removing syllabification from phonemic transcriptions because of it being a feature of narrow transcription. Fay Freak (talk) 19:36, 2 October 2019 (UTC)[reply]
@Fay Freak: On the other hand, whenever I find English words being shown without syllable division (and the transcription used is mostly phonemic), I syllabify them. Be that as it may, we should go ahead and modify {{la-IPA}}, showing Latin geminates by ◌ː in phonetic transcription. —Lbdñk (talk) 20:02, 2 October 2019 (UTC)[reply]
What speaks against putting the dot between ◌ː? Maybe that’s intended, because they shouldn’t have overlooked the fact that one can’t use the dot otherwise when there is a syllable break during a geminate consonant. (For kk is not synonymous to kː.) Fay Freak (talk) 20:06, 2 October 2019 (UTC)[reply]
You mean why not do ◌.ː? I don't recall seeing that done intentionally; ː is meant to be placed directly after the consonant or vowel that it modifies. (.ː looks like it represents a "long syllable break", which is nonsensical.) It's not just a problem with long consonants; we can't put syllable breaks in the middle of single consonants either, but English is supposed to have ambisyllabicity. — Eru·tuon01:46, 3 October 2019 (UTC)[reply]
Capitalization of proper nouns in languages using scripts without a lower/uppercase distinction[edit]
Sorry for the long post. TL;DR below.
Focusing on Germanic initially - as that is the primary domain in which I edit - I would like to draw attention to the issue of how we represent proper nouns on Wiktionary. I have recently been working on Continental Germanic attestations of Germanic theonyms a bit, and I noticed we had donar at lowercase (per an earlier deleted edit, it was moved from the uppercase version to its current lowercase spelling in late 2010), whereas our entry at *Þunraz lists the OHG name with a capital among its descendants.
This reveals a tension in the way we handle ancient scripts on Wiktionary: on the one hand, capital letters as a means of distinguishing proper nouns is an early modern innovation and their use is an anachronism, so using only lowercase letters would be more true to the sources, which in the case of Germanic typically use some variant of the Carolingian minuscule, Gothic minuscule, Gothic alphabet or runic - all scripts lacking an upper/lowercase distinction. On the other hand, a lot of scholarly literature describing ancient and medieval texts and even some editions of those texts use initial capital letters to distinguish proper nouns from other nouns in ancient and medieval languages.
I have since created an entry for OHG wodan and wigidonar at the lowercase spelling, as my view is that staying as close as possible to the source script in the representation (and especially transliteration) of ancient and medieval words is desirable. This is inconsistent with how proper nouns are handled in Old Norse currently, which on Wiktionary consistently uses capitalization in entry titles (see Category:Old Norse proper nouns). One may contrast this to Gothic, where I have been using lowercase initial letters in the transliteration of proper nouns consistently (see Category:Gothic proper nouns).
It seems to me that forming some coherent policy or at least a stronger guideline is desirable within the Germanic languages and perhaps further afield too (see below). Do we take the Old Norse precedent, preferring to use initial capital letters in entry titles despite their absence in the source scripts, or the Gothic one, where I have consistently used lowercase transliterations? Or a compromise?
As a final point to consider I would like to adduce the case of proper nouns in non-Germanic languages, especially those using non-Latinate scripts (which pretty much all lack an upper/lowercase distinction, except Greek). The case of Latin, which until the early modern period similarly lacked an upper/lowercase distinction (using the same scripts as abovementioned Germanic languages), is a weird one, as it has continued to be in use into the modern period and thus experienced the shift from minuscule or majuscule-only orthography to an orthography with an upper/lowercase distinction while it was still actively being used and it thus has initial capitalization in its Category:Latin proper nouns. A small overview of non-Latinate languages:
For Ancient Greek, which gained an upper/lowercase distinction in running text sometime in the modern period as well (the same as Latin), we have initial capital letters.
For Mycenaean Greek we seem to consistently forgo capitalization of initial letters, e.g. 𐀀𐀖𐀛𐀰(a-mi-ni-so), 𐀡𐀮𐀅𐀺𐀛(po-se-da-wo-ni).
Less similar are Arabic and Hebrew, which both lack capitalization in how we transliterate them. See هُولَنْدَا(hūlandā) and הוֹלַנְד, for example.
Further afield, for ancient languages we have languages using cuneiform. The picture is mixed.
Here we have Sumerian with an initial capital letter in its transliteration: 𒄑𒉈𒂵𒈩. Without an initial capital letter: 𒀭𒆘.
Akkadian w/ initial capital in transliteration: 𒀀𒇉𒌓𒄒𒉣. And without: 𒆠𒈾𒄴𒈾.
Another ancient language is Egyptian, which consistently forgoes initial capitalization, e.g. at mꜥnḏt.
Classical Mongolian similarly is transliterated without capital letters: ᠪᠠᠷᠠᠭᠤᠨ ᠲᠥ᠋ᠪᠡᠳ(baraɣun töbed)
Chinese seems to consistently transliterate with capital letters: 三十年戰爭／三十年战争(Sānshínián Zhànzhēng); same goes for Japanese.
These examples suffice for now.
TL;DR:
The distinction between upper/lowercase to distinguish proper nouns from other nouns in Latinate scripts only arose during the early modern period, and its projection onto earlier scripts through its inclusion in transliterations is something of an anachronism.
There are currently Old Germanic entries which lemmatize proper nouns at their lowercase-initial spelling (which is true to the sources, which being Carolingian minuscule, Gothic minuscule or Runic all lack an upper/lowercase distinction).
There are currently also Old Germanic entries, especially in the realm of Old Norse, which do use capital letters for proper noun entries, which goes against the scripts used in the sources but which accords with how they are referred to in modern scholarly literature most of the time.
Finally, Gothic - using a non-Latinate script (not the Gothic minuscule, but the Gothic alphabet!) based on Greek uncials with some Latin and perhaps Runic influence - does not currently use capital letters in its transliterations of proper nouns.
As for non-Germanic:
In the cases of some modern languages such as Chinese and Japanese, which have elaborate systems of transliteration/romanization, we universally use capitalization of initial letters in proper nouns despite the lack of an upper/lowercase distinction in those languages which may justify it.
In other modern languages such as Hebrew and Arabic, we forgo capitalization of transliterations.
In the cases of ancient languages using non-Latinate scripts, the picture is mixed: Ancient Greek uses initial capitals, Mycenaean Greek does not. Akkadian and Sumerian present a mixed picture. For Egyptian and Classical Mongolian we consistently forgo capitalization.
Given that many modern languages with non-Latinate scripts have their own established ways of transliterating/romanizing which we should probably not tamper with (Arabic, Chinese, Hebrew, Japanese, etc.), a general Wiktionary-wide policy seems undesirable to me. However, for ancient and medieval languages specifically we are currently being very inconsistent - often within the same language - and we would probably benefit from considering the issue and deciding on some coherent approach. I would consider it a victory if we had a clear approach to Germanic languages - especially those written in Latinate scripts, such as Old Norse and OHG - but it would of course be great if we could clear up the inconsistency with the Cuneiform scripts and with Classical Mongolian (etc.) as well (and possibly others). Thoughts? — Mnemosientje (t · c) 14:07, 30 September 2019 (UTC)[reply]
When adding Middle Dutch entries, I've consistently used lowercase, and I think that should be applied in general to manuscript forms in other languages too. However, Old Norse in particular uses a normalised orthography that strongly differs from anything found in manuscripts, so it can be argued that not just the capitalisation is an anachronism, but the whole orthography is. Therefore, I don't think capitalisation can be seen separately from spelling normalisation. —Rua (mew) 14:24, 30 September 2019 (UTC)[reply]
I would support using upper case even if it's anachronistic, since it's follow the general rule of the Latin script. While old manuscripts lack this distinction, recent work seems to follow the convention of using upper case letters. I've seen the Wulfila project use them despite Gothic lacking it. There is also the case of we not writing some Latin words all in upper case despite it being used for inscriptions. 𐌷𐌻𐌿𐌳𐌰𐍅𐌹𐌲𐍃 𐌰𐌻𐌰𐍂𐌴𐌹𐌺𐌹𐌲𐌲𐍃 (talk) 01:37, 1 October 2019 (UTC)[reply]
No worries, I can carry on the length on par.
Classical Mongolian transcription should probably use upper-case letters because of the Cyrillic equivalents, else the languages look more different than they are. I assume the same for for example Azerbaijani, that Azerbaijani Arabic spellings should have their transcriptions as if it were the Latin (Latin is the main script of Azerbaijani, but formerly Cyrillic).
On Ottoman Turkish and Old Anatolian Turkish: Having a 1:1 correspondence of Ottoman transcriptions is handy, it dovetails with the Turkish descendants and sometimes also etymon capitalization (say when the word is from Greek or Armenian).
But looking on پاسقالیه, I see that Modern Turkish uses both Turkishpaskalya and TurkishPaskalya, and Turkishbüyük paskalya and TurkishBüyük Paskalya so on, so technically should we have once {{ota-proper noun|tr=Paskalya}} and once {{ota-noun|tr=paskalya}} on the same page as well as the alternative forms twice because of the transcription?
No. Majuscule-writing is not decided by a word being a proper-noun: Names of recurring feasts each refer to a class of feast hence are never proper nouns. Note, English editors, that I see the inconsistency that Easter is a “noun” and Ramadan is a “proper noun”. What’s proper about “Ramadan” for it to be a proper noun? It seems wrong, also for EnglishEid al-Fitr, although you might not find a plural. Day of Potsdam is a proper noun because it refers to a certain festival in history. D-Day is a proper noun because it occured once, but a noun in that transferred sense; Black Friday is a proper noun applied to several entities (like forenames are not unique) and is also a noun for the phenomenon. День Побе́ды(Denʹ Pobédy) is a proper noun for its original and a noun for its holiday. Who is gonna clean that up?
I reason that from this follows that we should never capitalize demonyms in Ottoman and Old Anatolian Turkish and never names of feasts. @Allahverdi Verdizade to wit. But proper nouns. Paskalya isn’t a proper noun.
It is interesting that current Old Church Slavonic proper nouns have no capitalization, but upper case versions hardredirect as for example Исоусъ. Maybe it is more naturally to capitalize entries in every Slavic language, because otherwise one starts from some terms in upper case and then goes over to lower case at an inconspicuous threshold, see RussianИисус(Iisus). I find it hard to conceive that there is a diachronic barrier between Slavic languages where it makes click and suddenly I have to use only lowercase, and others will find it hard too, I predict – much easier it is to say “it’s done like one does in the modern languages”. Proto-Slavic proper nouns have uppercase again, and that seems comfy.
For Arabic, a part is based on the fact there is auto-transcription of vocalized text, which is also on some wishlists for Hebrew script. It would be booky if {{ar-proper noun}} only made upper-case transcriptions. Majuscules are not needed in the head-lines anyway. I do transcribe names in quote translations with upper-case letters, because the opposite in English text is very unnatural and it is distracting to have uncapitalized proper nouns if the language consistently employs majuscules in such kinds of words.
Don’t derive anything from the cuneiform spellings. These languages have been very wild and generally not edited by people who should work in cuneiform. And now further chaos ensues from that pernicious vote according to which Akkadian can be entered in Latin transliterations. Nobody will clean up and expand our Akkadian entries if not some exotic conspiracy.
And now from the more clear case let’s explain the Germanic: Since Slavic insinuates universal majuscule usage, let’s hold it like that at least in every Latin-script entry that is of the Germanic language family. Whether the other scripts should be treated thus I am in no position to assess. Fay Freak (talk) 02:03, 2 October 2019 (UTC)[reply]
This discussion is too long, I haven't read all of it. A few points from me. Generally, it's been agreed that capitalisations should not be used for transliterating languages where there is no such distinction BUT, as for Chinese and Japanese, the capitalisation applies to proper nouns and the start of the sentences based on specific policies for hanyu pinyin (Chinese) and standard Hepburn rōmaji (Japanese). Korean romaja followed the same but this can and probably should be disputed if no such policy really exist. I was one of the proponent of the capitalisation for Korean but I won't insist on keeping this policy. That said, Chinese (multiple romanisations) and Japanese capitalisation don't follow the English capitalisation, e.g. month names or names of weekdays are lower case, so are nationalities/language names (this is still being disputed!). It's also worth noting that capital letters may mean a completely different sound or represent a different letter (in the original script) in certain alternative transliterations, that's why it should definitely be avoided for Arabic, Hindi, etc. Most editors have agreed to use just the lower case, AFAIK. For languages with dual scripts, such as Kurdish or Mongolian, I think it's still correct to romanise the script with only lower case for the script, which doesn't distinguish between capital and small letters. --Anatoli T.(обсудить/вклад)10:07, 2 October 2019 (UTC)[reply]
Coming back to the Germanic languages, I see that Fay Freak is of the opinion that majuscules should be used word-initially for proper nouns in Latin-script languages; Rua seems to favour the use of non-capitalized forms reflecting the manuscripts except for Old Norse and User:Holodwig21 again shares Fay Freak's opinion and seems to want to extend it to Gothic too.
I'm still on the fence: on the one hand, standardizing them all to use an upper/lowercase distinction is intuitive to the modern reader. On the other hand, as Rua mentions the manuscript forms just totally lack them, and it isn't certain that the degree of normalization found when ancient words are used in modern scholarly texts is necessarily the same degree that should be used in a descriptive dictionary such as ours.
I guess it is similar to the situation of scholars who create either a regular edition of a text (typically capitalizing proper nouns even in languages which had no case distinctions) or a diplomatic edition of a text (which seeks to stick as closely as possible to the manuscript sources). In the latter case, proper nouns are rarely capitalized when the edition reflects texts in scripts that lack capitalization, and I happen to see my work in chronicling old languages on Wiktionary as more analogous to that of creating a diplomatic edition than anything else: I want to represent the language as it is found in the sources (ad fontes!) as much as is reasonably possible.
As a last point, I guess I can say with certainty that for non-Latin ancient and medieval scripts which never in their history had an upper/lowercase distinction (such as the Greek and Cyrillic scripts developed later on) it makes no sense to me to use that distinction in transliteration; e.g. Runic and Gothic should not have capitalized transliterations (yes, Streitberg's edition of the Gothic Bible uses capitalization, but he is not providing a diplomatic edition nor is he compiling a descriptive dictionary). — Mnemosientje (t · c) 14:00, 13 October 2019 (UTC)[reply]
The consultation on partial and temporary Foundation bans just started[edit]
Hello,
In a recent statement, the Wikimedia Foundation Board of Trustees requested that staff hold a consultation to "re-evaluat[e] or add community input to the two new office action policy tools (temporary and partial Foundation bans)".
Out of pure curiosity, how many of our users see "Wikimedia" as part of what we do, and not an external weird alien that sometimes deigns to dip its fingers into our hobby? Equinox◑05:17, 1 October 2019 (UTC)[reply]
Since I talked about fingers, I suppose one shouldn't bite the hand that feeds: they do provide server space. I can guarantee though that in the next six months or so there will be political incursions. I hope someone has a non-WMF backup in case we have to do the biggest fork ever. Equinox◑16:34, 1 October 2019 (UTC)[reply]
Done
Support We have a lot of material in this language and it's distinct. --Anatoli T. (обсудить/вклад) 12:06, 17 September 2019 (UTC)
Oppose as mentioned above. I would treat Russian Church Slavonic as a dialect of Church Slavonic, not as a separate language. (And our ad-hoc language codes always begin with an official ISO code, so if we do create a new code for RCS, it should be something like 
Abstain Bad code, as pointed out by Mahagaja, and unfortunately ad-hoc name. Apart from that I wouldn’t object to keeping the Church Slavonic recensions distinct. — Vorziblix (talk · contribs) 21:48, 17 September 2019 (UTC)
