Wiktionary:Beer parlour/2021/June

Hi! I've been working on Akkadian, Sumerian and Cuneiform Translingual entries recently. I've been using "Sumerogram", "Akkadogram" and "Determinative" as POS when needed, but I've been made aware those are not standard and could cause issues. (see 𒌉 for usage examples of Sumerograms, 𒀭 for Determinatives and 𒅆 for Akkadograms)

All three of them are necessary to structure Cuneiform entries for Akkadian and Sumerian (and Hittite, too) in a consistent way. Therefore, I'd like to propose adding them to the standard POS list. Do I have your vote? :D Sartma (talk) 09:08, 1 June 2021 (UTC)

Support. Tied to this, could "phonogram" be recognized as a header? See e.g. Old Korean 只.--Tibidibi (talk) 09:20, 1 June 2021 (UTC)

Per Fay Freak, revise vote to support "heterogram".--Tibidibi (talk) 16:51, 1 June 2021 (UTC)

On third thought, go back to supporting the original proposal. Oppose "logogram" because the category could lead to inconsistencies with other languages that use logograms, e.g. Japanese, and the existing POS setup should be preserved for those languages.--Tibidibi (talk) 17:49, 3 June 2021 (UTC)

@Tibidibi I was thinking last night that even if we end up choosing Logogram as POS, we would do so because it's the familiar term in Mesopotamian studies, in the same way Kanji is for Japanese, so it wouldn't really create any inconsistency with Japanese. Using Logogram for Akkadian/Hittite wouldn't necessarily mean we have to change POS for other languages. Sartma (talk) 18:05, 6 June 2021 (UTC)

@Sartma Sorry for the late response. I actually now fully agree with you, we can choose logogram as POS because these are just soft redirects where an orthographically worded header makes sense, which is not the case for the CJKV entries.--Tibidibi (talk) 07:22, 5 July 2021 (UTC)

Support. — Fenakhay ^{(تكلم معاي · ما ساهمت)} 15:41, 1 June 2021 (UTC)

uncertain - but could you at least add some actual definitions or translations to those entries. SemperBlotto (talk) 15:49, 1 June 2021 (UTC)

Hi! Sumerogram, Akkadogram and Determinative are categories of a cuneiform sign, in the same way Noun, Verb or Adjective are categories of a word. They classify the sign and under them we give a link to all the different words that can be written with that sign, so you will not find any "actual" definition or translation there. You find all relevant information in the page of the words listed under each category. If you take a second to check the pages I linked above you can see what I mean. Try clicking on a couple of the words linked as "Sumerogram of" or "Akkadogram of" under Sumerogram/Akkadogram and you'll be redirected to those words' entries. Sartma (talk) 16:55, 1 June 2021 (UTC)

@SemperBlotto: So the Akkadian and Sumerian word mentioned at مَيْس (mays) uses the sign 𒄑 (GIŠ) which wasn’t pronounced, when used as a determinative, but indicated to the reader that now the name of a tree follows (you might discern that the sign looks like a tree if you have a font for it installed). For this reason one might not parse the whole cuneiform string as a word so that one seeks a separate entry for 𒄑 (GIŠ), and any such signs, categorizating them as so-called determinatives, or taxograms or semagrams.

A heterogram is when you write mlkʾ, from the Aramaic spelling of the Semitic term for “king” *malk-, but actually mean and say شاه (šāh). They did such things frequently in the Ancient Near East. Fay Freak (talk) 17:16, 1 June 2021 (UTC)

Why not Heterogram? So one can use it later for Aramaeograms in Pahlavi etc. (@Victar) The definition line template {{sumerogram of}} already says “sumerogram”.

I guess Heterogram would work too, if you really are against Sumerogram/Akkadogram. It's just not a word you would find in Mesopotamian studies that much (I never saw it before now! XD), so it would be a bit confusing/alienating to people looking up Akkadian words. It says what it is, it just doesn't paint it a familiar colour. Like, when you study Akkadian you have glossaries and dictionaries with Akkadian words and then you have lists of "Sumerograms" (that unluckily never give the cuneiform, they're just like "A = water, A.BA = father, etc.) . I understand that Heterogram is more versatile, and I'm not against it in principle, but if there's no strong reason to change the labels, I would prefer to keep the more familiar ones. In the end, that's what they do in languages that use Han characters too (Japanese calling them Kanji, Korean Hanja, etc.). If we decide to go for Heterogram, then we should probably ask Japanese and Corean editors to change their entries accordingly too. Sartma (talk) 18:31, 1 June 2021 (UTC)

Actually, there's another word that's widely use in Mesopotamian studies: Logogram. That would be generic like Heterogram, including both Sumerograms and Akkadograms. What about Logogram? Again, if we choose a more general name, then for consistency we need to change also Kanji and Hanja, since they both are just Logograms.Sartma (talk) 10:56, 2 June 2021 (UTC)

@Sartma Two points:

• There is a difference in that most people consulting Korean or Japanese entries are (hopefully) going to be casual learners, to whom "Hanja" and "Kanji" are the familiar terms, while most people consulting Akkadian entries will be people with at least some linguistics background who can be relied on to be more familiar with terms such as logogram, heterogram, etc.

@Tibidibi I don't think that we should base our decisions on the perceived or hypothetical readers of Wiktionary entries, arbitrarily discriminating by language (Japanese and Korean: ok; Akkadian: no, sorry): in other words, I'd like to be able to have a discussion based on facts and not personal feelings or perceptions. There will be a lot of casual learners of Akkadian and Sumerian consulting Wiktionary (judging by existing Akkadian and Sumerian entries, I can assure you that who wrote them was probably even more casually learning them than people using Wiktionary for Japanese and Korean...) to whom "Sumerogram", "Akkadogram" and "Determinative" are the most familiar terms (if not the only one they'll ever hear). I would like to write entries for the vastest possible public, but mainly for a public that's actually interested in Sumerian and Akkadian, not for general "people with some linguistics background". I'd like those entries to be useful to those who are studying those languages, not to "others" (what sense would it make to do otherwise?). Every language has its own "technical" terms. I'm not sure who we are pleasing by changing well established terms to favour others that would just make everything less clear, confusing and alienating. We don't do that with Latin, Ancient Greek or Sanscrit, were all traditional categories are maintained, whether they make "linguistically" sense or not. I'd like to see the same respect for Akkadian and Sumerian too. Sartma (talk) 15:58, 2 June 2021 (UTC)

@Sartma Okay, I take back the point about discriminating by langue. But we are not removing the "Sumerogram" and "Akkadogram" terms, and they are still displayed prominently in the page. They are still on the page due to {{sumerogram of}}, only the title of the header is "heterogram". So no information is lost, and if anything information is added; people will now know from the header that these are heterograms.--Tibidibi (talk) 16:10, 2 June 2021 (UTC)

• Logogram is an extremely broad term while, to the best of my knowledge, full-scale heterogramic systems are more-or-less exclusive to the Ancient Near East, Japanese (modern and historical), and Old Korean; Chữ Nôm does not really use Chinese characters in this way. And since heterogramic entries are not made for Old Korean (there is no point because the phonetic component is not known) while Japanese has its own system already, it seems better to use "heterogram", which would become a more precise category exclusively used for extinct languages of the Near East. Modern Hanja are not heterograms.--Tibidibi (talk) 15:18, 2 June 2021 (UTC)

@Tibidibi: Logogram is a hyperonym of heterogram. The choice between the two should therefore take relevance and pertinence into account. Is it necessary to use "heterogram" instead of its hyperonym "logogram"? Does "heterogram" add any relevant/pertinent information that "logogram" doesn't express already? I'd argue that for the use in Akkadian entries "logogram" is sufficiently clear and there's no need to choose its hyponym "heterogram". The indication of a "foreign origin of the sign" is implicit in the further indication of the logogram as a Sumerogram or Akkadogram. Moreover, "Logogram" has the advantage of also being a very familiar word for people studying Akkadian and Sumerian: that to me is one big point in favour of its use. Sartma (talk) 16:29, 2 June 2021 (UTC)

I can concur; I know next to nothing of Sumerian and that stuff, but having "Logogram" as the header tells us enough; having each definition preceded by label "sumerogram of" and "akkadogram of" is clear, since it informs me of what to look for to know more about it. I actually understand what you're talking about here, which is sufficient for an entry. "Determinative" really should be a possible header, since it's used everywhere in the past, though the explanation you give reminded me more of jukujikun and the like. Knowing that the words make intuitive sense to those unfamiliar with the standard lingo, and having them agree with the accepted in-field jargon makes for this proposed system sufficing in my eyes. 110521sgl (talk) 14:31, 3 June 2021 (UTC)

• I will also add here that the Korean hanja entries do not represent logograms (as in the glyphs themselves) but Sino-Korean morphemes, and most are closer to full lemmas than soft redirects. If anything the "Morpheme" header would be more appropriate, except that most Korean linguists agree that many Hanja used in modern Korean are not genuinely productive morphemes in modern Korean, especially given the decline of Literary Chinese education. So Hanja is really the only header that fits.--Tibidibi (talk) 16:10, 2 June 2021 (UTC)

@Tibidibi True, hanja in modern Korean are not logograms. They're just a different way to spell Sino-Korean morphemes, as you say. So, for example, 椅子 is just a different spelling of 의자. In modern Korean it's just a question of stylistic choice. Sartma (talk) 16:48, 2 June 2021 (UTC)

“determinative” should probably be added since taxogram and semagram are much less used and classifier seems restricted for a thing that is used with numerals, though determinative has another meaning we list and I personally prefer taxogram and semagram because these elite words are unambiguous and parallel to other -grams, and I see semagram is used with another meaning by word-gamesters (the one I knew first we don’t have yet, as with heterogram, I’m finna fix it). Fay Freak (talk) 16:47, 1 June 2021 (UTC)

Here too, I'm not against it in principle, but for the same reasons I'd prefer to keep Sumerogram/Akkadogram, I'd prefer to keep Determinative too. This is the word used in every Akkadian and Sumerian reference material (Dictionaries, textbooks, essays...); it would be confusing/alienating if we used something unusual in the field. Sartma (talk) 19:22, 1 June 2021 (UTC)

Support the original proposal. Nobody actually uses heterogram when working on these languages, so we'd just be causing confusion for no gain; it's not like we have a finite number of L3s we can use. —Μετάknowledge^{discuss/deeds} 16:46, 3 June 2021 (UTC)

Support 110521sgl (talk) 19:52, 3 June 2021 (UTC)

Hi @JoeyChen, I asked on your discussion page why you removed grammatical articles from glosses. You didn't answer and you insist on continuing to do it: Special:Diff/62639656. Then I raised the issue in BP last month and no opinions were offered in favour of your practice, but neither were any firm and clear guidelines offered against it. I think such a fundamental disagreement deserves a coherent discussion - perhaps even a vote? Surely it can't be that difficult to decide. Please engage. Brutal Russian (talk) 19:39, 2 June 2021 (UTC)

I can see why they're doing it. I'm quickly going to look at a physical dictionary for Latin real quick. Oh. I thought I remembered there being indefinite articles in it, but apparantly dictionaries don't give articles for Latin nouns. So JoeyChen's doing it right. (Woordenboek Latijn/Nederlands zevende herziene druk Amsterdam University Press, 2018) 110521sgl (talk) 14:35, 3 June 2021 (UTC)

@110521sgl:"Right" in the context of wiktionary is what corresponds to our editing policies/guidelines. These can be influenced by what other dictionaries are doing, but what other dictionaries are doing does not determine what we consider to be "right"; moreover, if one wants to determine what other dictionaries are doing, consulting just one isn't enough. {{R:OLD}} uses articles the way our English definitions use them, definite and indefinite; it does present its definitions as sentences finished by a stop. {{R:L&S}} seems to be inconsistent, but does use them in the same word; see further "FriezeDennisonVergil" on the same website (at the top, only for words used by Virgil). It seems to me that the way English speakers choose to present English definitions is a good guide to the natural way to present them, and this would make article-less glosses aberrant. In addition, translations in templates like {{m}} generally require the use of articles to distinguish parts of speech, and it's simply better when the definitions in these templates consistently reflect the definitions in the entires. Otherwise, why not gloss verbs without the to for ultimate confusion? Finally, do you really find it desirable to gloss eg. cantiō, pugna as "singing", "fighting"? If not, what's the point of making an exception for disambiguation instead of introducing a general rule? Brutal Russian (talk) 21:50, 3 June 2021 (UTC)

Hi. I think the CFI for foreign languages is not clearly spelt out. If I understand correctly, the present consensus followed is:

1. English Wiktionary should have entries for all foreign natural language words that exist in the foreign natural language. The definitions and descriptions should be given in English. Title should be in the foreign script.
   • Entry layout for foreign terms is identical except that it should not have Translations sections
2. Foreign translations of English words should be added to the translations section of English entries.

I had long time not contributed anything to Wiktionary as I was unsure to what extend can foreign languages be added. Note that English WT has very less Indic language content (only 14,000 Hindi entries and just 1,400 Malayalam entries) despite their respective language versions of WT have over hundred thousand entries. WT:Statistics. So, please clear out the inclusion criteria for non-English languages in the CFI and other policy pages. I wish that a WT:Foreign languages page will be created. Thank you! Vis M (talk) 22:43, 3 June 2021 (UTC)

The main blocker is the nominal policy that we shouldn't just include an alleged word because some other dictionary has the word. The other is that we need usable translations into English of these words. Strictly, for non-English words, we give translations rather than meanings, though I think a lot of editors go for meanings rather then translations. There's no policy reason why English Wiktionary shouldn't include most of those lemmas - the reason is shortage of labour. On the other hand, there can be policies excluding some very obvious inflections, as for English. --RichardW57 (talk) 05:49, 4 June 2021 (UTC)

Ok, thank you very much! Vis M (talk) 00:24, 6 June 2021 (UTC)

The inclusion criteria for English are the same as for all other well-documented languages.__Gamren (talk) 23:32, 10 June 2021 (UTC)

There is a policy, though I don't know that it is documented, that the collection of meanings or translations for a word are kept at the main entry rather than duplicated across alternative forms or inflections. What, then, are the allowed uses of the gloss fields in many of the linking templates, such as {{inflection of}}, {{alternative form of}} and {{sa-sc}}, or indeed {{bor}}? --RichardW57 (talk) 05:35, 4 June 2021 (UTC)

One view, promulgated by Inqilābī, is that, "We provide the meaning in nonlemma entries only when there are multiple definitions in the entry", essentially that the purpose of these short glosses is to distinguish the lemmas. He's used this view to delete one of my brief gloss given for Pali သီလ (sīla, “habit”), which technically is a lemma, though some prefer to call it a soft redirect. (It actually stores script-specific information; by @AryamanA's rejection of the use of data-modules for word-specific information, irregular inflection can cause these subsidiary lemmas to involve a fair bit of work. Pali seems to have a host of irregularities.) --RichardW57 (talk) 05:35, 4 June 2021 (UTC)

I have been taking the view that these glosses can provide a one-stop service to the user who has temporarily forgotten the word; if he wants more meaning, he can click on, but if the reminder is enough, job done. So, may we attempt to be user-friendly by providing memory-jogging glosses? --RichardW57 (talk) 05:35, 4 June 2021 (UTC)

I also sometimes provide a brief gloss in non-lemma even when the lemma entry is unambiguous, especially if the main lemma is more than one click away (e.g. an alternative spelling of an inflected form or a mutation of an inflected form). —Mahāgaja · talk 15:08, 4 June 2021 (UTC)

What do people think about User:Turkish Glossary of Untranslatable Expressions, and User:Términos de la psicología (earlier version User:Jimena rc)? While the subject matter is relevant to a dictionary, these are completely isolated from the rest of Wiktionary- none of these accounts have made any edits outside of their own user and user talk pages.

I'm probably going to delete the "psicologia" ones either way because the definitions are all in Spanish, but I think we need to discuss this- it's starting to look like a trend. Chuck Entz (talk) 21:19, 4 June 2021 (UTC)

I think they are in need of a kind of software for their vocabulary records, and are here because they have been conditioned to seek out a SaaSS. Fay Freak (talk) 02:24, 5 June 2021 (UTC)

This is an improper use of user names. As to the Turkish list: if attestable, why are these entries not simply terms/phrases in mainspace? (In fact, some are: (bacanak, cümbür cemaat, ellerine sağlık, kaçıncı, ulan/lan, üşenmek.) It is not at all unusual that some term has no direct equivalent in another language, or that some idiom does not make sense when translated word for word, or needs a usage note to explain when it can be used. The list has the appearance of having been copied from elsewhere, what with the remark “also seen in the photograph” while there is no photograph.  --Lambiam 17:13, 6 June 2021 (UTC)

My recent favourite "untranslatable" Spanish term is por el culo te la hinco. I was wondering how I'd translate that if it was in a film - probably have the character sing "Ah Ah Ah Ah Number Five Number Five" Beegees-style as a relatively humorous alternative. Indian subcontinent (talk) 20:52, 6 June 2021 (UTC)

...which probably explains why I'm not a film-script translator. Indian subcontinent (talk) 20:53, 6 June 2021 (UTC)

“In yer tewel I swive” Fay Freak (talk) 21:07, 6 June 2021 (UTC)

“In yo' mom's muff I dive” Indian subcontinent (talk) 22:54, 6 June 2021 (UTC)

The following pronouns have no genitive formː there & relative which. The following common nouns are not found with a genitive form eitherː umbrage, sake, dint, worth, behalf, lack, basis, extent, means, stead, shrift, spate, heed, & cusp. What's a good way to deal with this?--Brett (talk) 16:35, 6 June 2021 (UTC)

Maybe I'm just dumb but how is umbrage any different from anger? I can't see how a possessive or genitive is acceptable for one but not the other. —Justin (koavf)❤T☮C☺M☯ 20:40, 6 June 2021 (UTC)

I don't see anything that need to be "dealt with", to be honest. Make a list in a subpage of your username, I guess Indian subcontinent (talk) 20:47, 6 June 2021 (UTC)

Better corpuses? Better analysis? You ought to find that 'whose' does function as the possessive of 'which'. As a mathematician, I have no problem pondering a basis's cardinality. (It's in print as, "In fact, for any two vector spaces A and B, we can always find a vector space C, whose basis’s cardinality is big enough, such that A ⊕ C = B ⊕ C.") And googling quickly turned up, "Then we consider the case of unknown cusp's order and derive an adaptive wavelet estimator with the uniform rate slower only by a log n factor than the corresponding rate for known ffi." I also found, "Business Insider calculated that Amazon CEO Jeff Bezos made $160,000 per minute at his net worth's peak September 2018".

If such a lack were real and noteworthy, the 'Usage notes' seem a sensible place to mention such a lack. --RichardW57 (talk) 22:22, 6 June 2021 (UTC)

"the richness of sake's taste" FTW Indian subcontinent (talk) 22:59, 6 June 2021 (UTC)

That's just taunting. --RichardW57m (talk) 11:06, 7 June 2021 (UTC)

"If first extent's measurement in EAD = boxes, enter boxes in ASpace type." --RichardW57m (talk) 11:06, 7 June 2021 (UTC)

I suspect certain verb forms also happen not to have a 'genitive form', such as 'am'. Do clitic forms of verbs take the possessive clitic, or does it force the clitic to decliticise? This question seems to be more of an issue for a grammar rather than a dictionary. The clitic's realisation seems to be variable after 'is' and 'was', even amongst those who have mastered the apostrophe. (The question is whether the 'repeated morph constraint' gets applied.) --RichardW57m (talk) 11:06, 7 June 2021 (UTC)

I asked for opinions on creating pronunciation usage templates back in March, but didn't receive any. Since then I've only created one ({{U:la:pron-dropvowel}}) because it rubs me the wrong way to create templates with monstruously long names. These result from the need to specify what type of usage template it is, for example. In my opinion the type is best distinguished by the capital-letter, and so I've just made {{P:la:4decl-neut}}, where P stands for "pronunciation". I'm not sure if Etymology needs its own letter, but no other sections that do come to mind, since the rest of the entry is basically treated as one section and the note generally appears under Usage notes. Do you think this is a good approach? Earlier-created pronunciation notes are often found in the Usage notes section, which I think is the wrong place for them, and I've been consistently putting them under Pronunciation. Brutal Russian (talk) 00:32, 7 June 2021 (UTC)

I'd go ahead and do it, and if it breaks anything someone will eventually realise. Also, don't worry about long names in templates - we have long-named stuff like Template:RQ:Chapman Mask of the Middle Temple and Lincoln's Inn and Template:RQ:Denham On the Earl of Strafford's Tryal and Death Indian subcontinent (talk) 22:35, 7 June 2021 (UTC)

Do inline synonyms/antonyms as specified using {{syn}}, {{ant}}, etc. go before or after usage examples? Benwing2 (talk) 01:39, 12 June 2021 (UTC)

Before, I think. Imetsia (talk) 02:19, 12 June 2021 (UTC)

It was left unregulated, I discovered shortly after the vote introducing them and you probably have read: But there one has argued for before. Which I now also prefer mostly because otherwise the quotes push away the semantic relations on expansion but you would like the synonyms and company near the definition to even understand the definition or you wonder where they went. Fay Freak (talk) 03:01, 12 June 2021 (UTC)

Given that almost everyone in that discussion wanted them placed before usage examples, and I agree, and WT:ELE agrees as well, I've changed the documentation of all inline *nyms to indicate that they go before usage examples. Benwing2 (talk) 04:23, 12 June 2021 (UTC)

@Justinrleung, Suzukaze-c, Tooironic, 沈澄心 Should the pinyin of the names of ethnic groups be capitalized here on Wiktionary? In 現代漢語詞典 they are capitalized even though they are classified as nouns. An example is Hànzú for 漢族. The same is true for 漢人, 漢語 and 漢字, but not 漢姓. RcAlex36 (talk) 11:25, 12 June 2021 (UTC)

Thanks for the ping. I don't have an opinion on this matter. ---> Tooironic (talk) 11:33, 12 June 2021 (UTC)

Also @Frigoris, Bula Hailan. RcAlex36 (talk) 12:02, 12 June 2021 (UTC)

@RcAlex36 See this link 汉语拼音正字法基本规则, in section 6.3.2, the Pinyin transcription of 景頗族 is capitalized. Bula Hailan (talk) 12:10, 12 June 2021 (UTC)

I don't think 現代漢語詞典 has a separate label for proper nouns, but even so, I think these should be capitalized. — justin(r)leung _{{ (t...) | c=› }} 16:04, 12 June 2021 (UTC)

@Suzukaze-c, 沈澄心 Any opinion on this? RcAlex36 (talk) 05:28, 13 June 2021 (UTC)

I personally support capitalization but do not care if someone supports the opposite. —Suzukaze-c (talk) 05:31, 13 June 2021 (UTC)

With no editor opposing capitalization I will go ahead and capitalize the pinyin of words in question. RcAlex36 (talk) 09:24, 14 June 2021 (UTC)

@Atitarev made this change (); I'm pinging that editor in case they have a comment. I don't have an opinion on it, but I will note that Xiandai Hanyu Guifan Cidian has no capitalized pinyin forms, but Xiandai Hanyu Cidian does (as noted above). --Geographyinitiative (talk) 12:32, 14 June 2021 (UTC)

Note section 6.3.3 in which the pinyin for 漢語 is written as Hànyǔ. Also, Xiandai Hanyu Cidian, being the primary prescriptive standard for Standard Chinese, should be considered more authoritative than Xiandai Hanyu Guifan Cidian in my opinion. RcAlex36 (talk) 14:19, 14 June 2021 (UTC)

@RcAlex36: I failed to understand when to capitalize. 粤语 is transcribed as Yuèyǔ in 汉语拼音正字法基本规则 (2012) but yuèyǔ in Xiandai Hanyu Cidian (7th edition). --沈澄心✉ 09:10, 22 June 2021 (UTC)

WingerBot is making entries worse by changing {{l|en|a}} in definitions to ]. The former is superior because it links to the intended definition, not to the top of a large page that happens to contain a definition. See Special:diff/62729111. Compare a to a. I have to scroll down 22 pages to reach the English section if I follow the page link. Vox Sciurorum (talk) 11:35, 12 June 2021 (UTC)

I'm not sure the first is superior, since it also uses Lua (which can be of significance in some pages). Also, the English section is always the first or second one on the page, so you can click it in the contents box. That said, I'm not sure machine-changing these is a good idea without consensus, since I can imagine some editors prefering the former style over the latter. pinging @Benwing2 Thadh (talk) 11:59, 12 June 2021 (UTC)

It may be tedious doing it by hand, but a bot should have no trouble using ] to replace {{l|en|a}}. Chuck Entz (talk) 17:42, 12 June 2021 (UTC)

@Vox Sciurorum This has been discussed before and I think people were generally in favor of raw links for English. Generally this is how people enter the definitions anyway; it's annoying to enter templated links everywhere when creating definitions by hand (which is how it has to be done). The vast majority of pages for English words don't have large tables of contents at the top, and the English definition is almost always the top definition, so usually it's not an issue. If this is really an issue, we can use templated links only for the pages with large tables of contents. Furthermore, most of the time words like a aren't even linked in definitions; how many times do you need to check the definition of a word like this anyway? Benwing2 (talk) 18:01, 12 June 2021 (UTC)

I think plain wikilinks work in definitions, etymologies, etc, for Translingual terms as well, whether CJKV or taxonomic, except inside certain templates like those in the {{der}} family. DCDuring (talk) 18:32, 12 June 2021 (UTC)

Plurals are the only possible non-lemma forms of nouns in Italian, so there's really no point in having a category Category:Italian noun plural forms distinct from Category:Italian noun forms. For this reason, I plan to run a bot to convert all Italian 'noun plural forms' to plain 'noun forms' and remove the category Category:Italian noun plural forms. This would make Italian work like English and Spanish (which likewise have only plural non-lemma noun forms, which are placed in the 'noun forms' category directly). The same thing should be done in French. Benwing2 (talk) 01:31, 13 June 2021 (UTC)

Per above and Category talk:English noun plural forms § RFM discussion: March–May 2019. J3133 (talk) 01:45, 13 June 2021 (UTC)

How do we handle the interaction with the clitic -'s? In many ways, it still works like a case form. --RichardW57m (talk) 11:48, 14 June 2021 (UTC)

We only have a small handful of pages that are noun forms but not noun plural forms, and the change was already made for English; Italian doesn't have this issue. I support moving the Italian, French, and English proper noun categories. However there are still 179 categories in Category:Noun plural forms by language. Should they all be moved to "X noun forms" even if they have case systems? No one has complained so far about the 51,671 pages in Category:German noun forms versus the 174 in Category:German noun plural forms. Ultimateria (talk) 17:21, 14 June 2021 (UTC)

@Ultimateria I don't think there should be anything in Category:German noun plural forms. In general, "noun plural forms" doesn't really make sense for languages with case because there usually isn't a single plural noun form. German is a partial exception in that nouns with plurals in '-n' and '-s' have the same form for all cases, but I still don't see the point of a 'noun plural forms' category there. Benwing2 (talk) 04:03, 15 June 2021 (UTC)

@Ultimateria, Benwing2, J3133 It makes some sense when the plural has a separate stem, as most notably in Semitic languages. However, it is these stems that one would want to cpature. --RichardW57m (talk) 11:30, 15 June 2021 (UTC)

I'd like to make the same change to Dutch and Afrikaans noun plural forms. These languages are similar to English and Romance languages. Dutch does have some archaic case forms, but these are all segregated into CAT:Dutch noun case forms. Benwing2 (talk) 04:45, 25 June 2021 (UTC)

It appears that all Italian cardinal numbers are listed as both numerals and adjectives. The way it seems to have gotten this way is that User:SemperBlotto made all Italian numbers be marked as both nouns and adjectives around 2008, and User:Ultimateria converted the nouns to numerals in 2020, leaving the adjectives. I don't believe "adjective" is a correct POS and am planning on deleting the adjective POS from all of the numbers. Benwing2 (talk) 00:57, 14 June 2021 (UTC)

By all means delete them. Ultimateria (talk) 01:14, 14 June 2021 (UTC)

Agreed, although I wouldn't bother for some of the larger numbers. Many of the cardinal-number entries are in the process of being deleted outright (see the category talk page). So I don't think we should waste time first editing the categories for entries that will be deleted soon anyways. Although I do invite other admins to continue the work of deleting that large mass of cardinal numbers per our previous vote. Imetsia (talk) 01:21, 14 June 2021 (UTC)

numbers are considered adjectives in Italian though. Why would Adjective be wrong? Sartma (talk) 05:27, 14 June 2021 (UTC)

Dear all,

Wikimania 2021 will be hosted virtually for the first time in the event's 15-year history. Since there is no in-person host, the event is being organized by a diverse group of Wikimedia volunteers that form the Core Organizing Team (COT) for Wikimania 2021.

Event Program - Individuals or a group of individuals can submit their session proposals to be a part of the program. There will be translation support for sessions provided in a number of languages. See more information here.

Below are some links to guide you through;

• Program Submissions
• Session Submission Guidelines
• FAQ

Please note that the deadline for submission is 18th June 2021.

Announcements- To keep up to date with the developments around Wikimania, the COT sends out weekly updates. You can view them in the Announcement section here.

Office Hour - If you are left with questions, the COT will be hosting some office hours (in multiple languages), in multiple time-zones, to answer any programming questions that you might have. Details can be found here.

Best regards,

MediaWiki message delivery (talk) 04:18, 16 June 2021 (UTC)

On behalf of Wikimania 2021 Core Organizing Team

Like the standard language, the swedish noun entries on wiktionary have two genders common/neuter. However, since almost every (traditional) dialect has the three masculine/feminine/neuter, it would be better to split the common gender template into something like c/f and c/m so both dialects and standard language would be accommodated equally in this aspect. There are also a few nouns that have different gender in different dialectareas. — This unsigned comment was added by ASkyr (talk • contribs) at 09:40, 18 June 2021 (UTC).

This is a good suggestion, and one that I myself have been thinking of making. There are still certain noun classes that have a strong connotation with feminine or masculine gender, for instance the nouns with -a in singular and -or in plural are historically feminine, and intuitively seen by natives as such, while the nouns with -e in singular and -ar in plural are likewise, but masculine.

Not to mention that the distinction between masculine and feminine was still largely existing in the written language of the 1600s and 1700s, which counts as Swedish and thus, being attested, should be included in the dictionary. I should add that SAOB, the Dictionary of the Swedish Academy, also lists nouns as "r. l. f." (common or feminine) and "r. l. m." (common or masculine), rather than only "r." (common) Mårtensås (talk) 18:58, 20 June 2021 (UTC)

I think this would be useful information, whether we put it in the headword line or at least in declension tables, and given what's been said above about how it's necessary for describing not only dialects but the early modern language, and how another major dictionary includes it, I'm inclined to include it. German entries sometimes mention a noun's varying gender in "dialects" via usage notes, but the number of Swedish nouns where this information would be applicable seems so high that it should go somewhere more "regular", like the headword line or declension table. (I suppose there may be some modern coinages/borrowings which don't have a traditional gender besides common, though, yeah?) - -sche (discuss) 21:16, 20 June 2021 (UTC)

I already added support for it so that it looks like how SAOB handles it, see jord (it reads like " jord c or f "). Mårtensås (talk) 12:06, 21 June 2021 (UTC)

Despite the failed vote, Creation of Template:inh+ and Template:bor+, @SodhakSH (and Brutal Russian) went ahead and created the templates {{bor+}} and {{inh+}}. They should be deleted and locked to prevent them from being recreated. @Metaknowledge, Thadh, Donnanz, Fenakhay, DannyS712, Fay Freak, -sche, Jberkel, Mahagaja --{{victar|talk}} 18:46, 18 June 2021 (UTC)

I agree, but this seems like a discussion for WT:RFDO, not the Beer Parlor. —Mahāgaja · talk 19:07, 18 June 2021 (UTC)

RFD created as well. --{{victar|talk}} 20:36, 18 June 2021 (UTC)

I think lengthy case presentings shouldn't be part of RFDs, so I'm going to give mine here, where it seems to be tolerated.

These templates' function is to make editing easier for a small number of editors (by name, mostly, but probably not exclusively, SodhakSH, Inqilābī and Brutal Russian), and arguably create a regular wording for etymology sections (although I, as well as others, dispute that). The necessity of the text that is now being displayed using these templates is very much disputed to a degree that a supermajority (13 to 5) has voted to abolish giving the text within the {{bor}} template. Of course, one could argue that adding the template {{bor+}} isn't contradictory to that vote, but seeing as the vote concerning adding bor+ also failed I wouldn't be so certain of that.

Some bring up the issue that AryamanA voted just past the time and thus failed to make the difference, but seeing as PUC was also going to vote oppose (mind you, an oppose vote is worth twice a support), the vote would have failed anyway.

Now, some have brought up that a new template's creation shouldn't need any vote, but I'd argue that since this template is one in a series of arguably most used templates (after {{head}}, {{l}} and {{m}}), any creation of a template that takes over a part of or even the whole function of {{bor}} or {{inh}} should get a vote, which it did in this case, and would have even without the initiative of the template's advocates.

So, to reiterate, the proposal to create these templates was turned down in a democratic process that is of the highest form we have. An RFD discussion is of no value, since it's not as important as a vote, and as such I, and anyone who agrees with me, plead to the administrators of this project to delete these templates, lock them and either create another vote (which I personally would find absurd, since we just finished this one, and we are currently not in the season where the majority of Wiktionary editors is regularly editing), or just ban the creation of such templates until a supermajority of Wiktionary editors actually agrees that this template should be created. I thank you for your time.@Victar, SodhakSH, Inqilābī, Brutal Russian, Mahagaja, Fenakhay, Imetsia, Benwing2, PUC, Lambiam, Andrew Sheedy, Bhagadatta, Chuck Entz Thadh (talk) 11:09, 21 June 2021 (UTC)

There’s no question of having them ‘deleted & locked’. From the vote it is clear that a supermajority was in favour of the templets, only Time kept the vote from officially passing. Many/Most of the supporters (and even an opposer, Metaknowledge) agree that this vote was not needed at all: and what’s more, especially because these are harmless templets with no differing functionality, they should be kept. As Lambiam rightly pointed out, we have lots of unnecessary templets but we keep em. Now, the reasoning that Canonicalization could have also cast his vote is not a whit a good justification for the claim that the vote would have anyway not passed, forasmuch as all editors were not aware of the vote, and if the vote were to be prolonged, more people would have cast their vote. Also, {{inh+}} & {{bor+}} are overlapping templets in the sense that they would only be used initially in the etymology section, but also generally and not always, depending upon the preference of the editor. It is in fact more democratic to have overlapping templets; to not let using them is authoritarian. All etymology templets (save {{com}}) not only produce the full wording but also have the keywords linked to Glossary, thus ’tis only natural that {{inh}} & {{bor}} should do likewise; but seeing as these two templets are used very often, two new templets had to be deviced (at first I was thinking of using parameters, but that idea was rejected owing to the perceived unwieldiness thereof, hence having the new templets is the best possible choice). Has any of the opposers a better solution to’t? ·~ dictátor·mundꟾ 13:52, 21 June 2021 (UTC)

The difference between {{inh}}/{{bor}} and any other of the etymology templates is that "inherited", "borrowed" and "from" are pretty self-explanatory; calque, semantic loan and onomatopoeia not so much, and so the template provides the link, so that editors don't have to link to the glossary manually, and the readers don't have to know every lexicographical term to read the dictionary. For the two templates in question, it's simply not necessary, and the new templates don't even link to the glossary.

For what it's worth, it seems a little silly to have such a discussion over two templates, I give you that, but I think that templates that are used on a day-to-day basis in all languages in a certain way shouldn't be replaced by another template just like that, especially against a held vote. Also, about the supermajority: I have already adressed that, PUC said they would have voted against, making it again a non-supermajority. Thadh (talk) 14:30, 21 June 2021 (UTC)

No, they do, I already announced that before. I said that more people would have voted if the vote had lasted beyond a month, there would have been more supporters as well, please do not use Canonicalization as a distraction. In many language families, templets like {{lbor}} are used as often as {{bor}} & {{inh}}; so the needlessness of the etymological text is unjustified. Also, your claim that ‘The necessity of the text that is now being displayed using these templates is very much disputed to a degree that ’ is not any premise: during that time {{etyl}} reigned supreme, and people just wanted to have consistency in line with the few other existing/utilised templets. This time again, we are advocating consistency. ·~ dictátor·mundꟾ 15:00, 21 June 2021 (UTC)

The point is that we don't know what would have happened if the vote had lasted longer. Maybe people would have flocked to support it and it would have passed with flying colours, or maybe it would have failed miserably, or maybe the result would have been exactly the same: failing by a narrow margin. The same way that my non-casted vote is irrelevant, Aryaman's late vote is irrelevant. What matters is the actual result. So, by all means, make your case, but drop that argument, which weakens it. 212.224.224.150 15:12, 21 June 2021 (UTC)

You're right about the linking, I'm sorry, I vaguely remembered looking at the new templates and not seeing these, but it turns out I was wrong. I've slashed that comment. Thadh (talk) 15:41, 21 June 2021 (UTC)

@Thadh: I don't think you get it right when you say the utility of showing the text is disputed in the old vote. People voted to remove the text because it had to be constantly deleted using the parameter, because the templates are constantly used in other positions than line-initial, and this was cumbersome - not because the text was useless (ctrl+F only finds 1 'usef' and no 'util'). The two new templates have been created in order to make it less cumbersome to display full and unambiguous etymological statements line-initially, and because adding an optional parameter to {{inh}} and {{bor}} would have resulted in the same cumbersomness as the old vote had banished. Both votes were designed along the same goal of making life easier for everyone, and I find it difficult to understand the position of people who argue against making life easier on procedural grounds of a vote that didn't pass by 1 and that wasn't even required in the first place. This seems less like democracy and more like make-yourself-feel-good bureaucracy. I will also add that a precedent for these templates was already present as {{m+}}, which takes over the functionality of {{m}} and of very marginal utility indeed, albeit created full 4 years ago.—When you mention "a small number of editors", naming only three, are you doing it after having read through all the support votes? Brutal (talk) 00:01, 22 June 2021 (UTC)

@Brutal Russian: Not everyone that voted support is in favour of using these templates, they're - from my understanding - just not against the creation of the templates for the people that want to use them.

If showing the text wasn't the issue, then a creation of the parameter |t=1 would've done the trick, but the thing is that not everyone likes to write "Borrowed/Borrowing" (although I always do write it) before an etymology, and it seems like almost no-one wants to systematically put "Inherited from" before every inheritance. The vote has shifted a long time ago from "Should we actually create and use these specific templates?" to "Should everyone be able to create any template without a vote?". I personally believe that the creation of these templates will lead to the standardisation of their usage (since the community always strives to a unified style for as much as possible), and since I neither like them in action nor think them useful, I oppose this development.

For {{m+}} it's different, because the usage of the template is very marginal and mostly handy for the reason that some languages' names are just too darn difficult to remember (try typing out "Xârâcùù" or "Babine-Witsuwit'en" with a plain keyboard without copy-pasting in a casual mention), but I wouldn't be too sad if it were deleted because a majority of the community doesn't like it. Thadh (talk) 10:37, 22 June 2021 (UTC)

@Thadh: ‘Not everyone that voted support is in favour of using these templates, they're just not against the creation of the templates .’: That’s clearly a misrepresentation, just behold the support votes; what you said best describes the abstain votes. The issue with the vote was hardly the text in itself but the creation of new templets. The new templets would be very helpful for {{der}} cleanup: one would not have to see the wikitext or scroll down to the categories to check if {{inh}} or {{bor}} has been used. And the display of the keywords (they are linked to the glossary) is nothing wrong: all kinds of etymologies are equally significant. If you do not like the templets, do not use em, but please allow the templets’ backers to use them. Tolerance of harmless things is the best policy. ·~ dictátor·mundꟾ 11:44, 24 June 2021 (UTC)

You may still find it dangerous (healthwise) to 'clean up' "Inherited from {{der|pi|sa|...}}". There are quite a few words where there has been a morphological change between Sanskrit and Pali, but the relationship is not one of borrowing. --RichardW57m (talk) 15:38, 24 June 2021 (UTC)

@RichardW57: (1), (2). Nothing will be ‘dangerous’ as I am against a bot normalisation. ·~ dictátor·mundꟾ 11:59, 25 June 2021 (UTC)

@RichardW57: Could you explain your example? Is it appropriate that the template and category disagrees with the text? Which should be corrected to which, or how this should otherwise be resolved? Please give an actual example word or two if possible. Brutal Russian (talk) 19:52, 26 June 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'm glad someone has noticed the clash between the wording and category. But we were assured above that everyone understands 'inherited'.

1. The example that set me thinking is the alleged inheritance of Pali candimā (“moon”) from Sanskrit चन्द्रमस् (candramas). Geiger sees the first components (candi- and candra-) as being different alternatives in the Caland system, so if the Pali descends from the Sanskrit form, there has been a morphological change. Given the characteristics of the Caland system, I'm now inclined to see the first element in Pali as more ancient, with a strong possibility of the Sanskrit form being the later formation, and reject the notion of the Pali form descending from the Sanskrit form, so this word might not actually be an example. If we ignore the discrepancy in the initial forms, we have the issue that apart from the nominative, the singular of the Pali word is now declined from the stem candima - it has been morphologically restructured to include a thematic vowel, rather than being a consonant stem. --RichardW57 (talk) 21:56, 26 June 2021 (UTC)
2. At first sight, a better example is the Pali doublet sumedha (“wise”) and sumedhasa, which are now thematic adjectives that Geiger derives from the consonant stem seen in Sanskrit सुमेधस् (sumedhas). The former Pali word is indistinguishable from a bahuvrihi on Pali medhā (“wisdom”), so is arguably a morphological restructuring, disqualifying the use of {{inh}}.
3. Another awkward case is the current etymology of Latin nurus - "From {{inh|la|itc-pro|*snuzos}}, from {{inh|la|ine-pro|*snusós}}". I'm not sure that the second 'inh' is valid in this sequence at all. The problem is that the Latin word is 4th declension, not 2nd declension. There's been some morphological restructuring there.
4. @Brutal Russian: A good example of arguable morphological change from Sanskrit to Pali is Pali ojā f from Sanskrit ओजस् n (ójas). --RichardW57m (talk) 13:09, 28 June 2021 (UTC)

I would like to create a bot to populate Category:English three-letter words (using the method outlined by User:Thryduulf) and Category:English terms with multiple etymologies (by checking for multiple etymology sections), and any other under-populated categories I find. Are these categories worth populating? Is there a better way to populate them than by using a bot?

I have experience with Python and from what I've seen I think I could make the bot using Pywikibot fairly easily. —TeragR ^disc./con. 02:01, 19 June 2021 (UTC)

Yeah, this seems like it could be done relatively easily. Though I am no competent expert, I'd say populating the categories could well be worthwhile (there are all kinds of categories out there, after all, many of which have less utility than this proposal), and a bot would probably be the best way to do it. Moreover, this kind of edit should be minor and easy enough to achieve, right? Have you already begun working on it? Support your idea :) Kiril kovachev (talk) 16:42, 20 June 2021 (UTC)

Yes, the edits would be simple and minor. I wanted to ensure there was consensus before writing the code, so I have not started that yet. —TeragR ^disc./con. 22:30, 20 June 2021 (UTC)

Personally I don't think the categories are necessary, but I don't strongly oppose the idea. In other discussions, users have expressed concern about "category bloat", i.e., scrolling to the bottom of a page and seeing dozens and dozens of categories which make it hard to find what you're looking for. I'm surprised more active editors haven't responded here, but don't be surprised if you face some opposition after you start adding these categories. Ultimateria (talk) 01:25, 23 June 2021 (UTC)

Thank you for mentioning that. IMO the difficulty in finding one category in a large block of categories sounds like a UI issue (though admittedly not one I'm volunteering to try to fix). I don't mind if consensus says the category is unuseful, but I would like to see it deleted in that case. —TeragR ^disc./con. 04:28, 23 June 2021 (UTC)

I'm surprised that "three-letter words" is manually populated, since it could be trivially added by {{head}} or the like (although I would also be wary of feature creep). —Suzukaze-c (talk) 02:43, 23 June 2021 (UTC)

Good to know! In that case perhaps this is not a job for a bot (but rather for a template). —TeragR ^disc./con. 04:30, 23 June 2021 (UTC)

@TeragR User:Suzukaze-c is right, there is no point in using a bot to add categories like "N-letter words". Category:English terms with multiple etymologies is harder to do by template and involves an expensive operation (reading the page text), which isn't warranted on all English pages, although I'm not sure we'd want it auto-added by bot to all pages (that would require some consensus). Benwing2 (talk) 04:40, 25 June 2021 (UTC)

Hello, I'm one of the Movement Strategy and Governance facilitators working on community engagement for the Movement Charter initiative.

We're inviting input widely from users of many projects about the upcoming formation of the Movement Charter drafting committee. You can provide feedback here, at the central discussion on Meta, at other ongoing local conversations, and during a Global Conversation upcoming on 26 and 27 June 2021.

"The Movement Charter drafting committee is expected to work as a diverse and skilled team of about 15 members for several months. They should receive regular support from experts, regular community reviews, and opportunities for training and an allowance to offset costs. When the draft is completed, the committee will oversee a wide community ratification process." (Creating the drafting committee)

Further details and context about these questions is on Meta along with a recently-updated overview of the Movement Charter initiative. Feel free to ask questions, and add additional sub-sections as needed for other areas of interest about this topic.

If contributors are interested in participating in a call about these topics ahead of the Global Conversation on 26 and 27 June, please let me know. Xeno (WMF) (talk) 16:48, 19 June 2021 (UTC)

The three questions are:

1. What composition should the committee have in terms of movement roles, gender, regions, affiliations and other diversity factors?

2. What is the best process to select the committee members to form a competent and diverse team?

3. How much dedication is it reasonable to expect from committee members, in terms of hours per week and months of work?

As mentioned on the talk page Module talk:families/data a few months ago, in line with the current nomenclature, the canonical name of the language family that includes Korean, Jeju, and extinct languages from the Korean peninsula should be "Koreanic" and not "Korean." Glottolog, Wikipedia, Wikidata, recent literature & research, along with Wiktionary's own entry for Koreanic, list it as the title for the language family; thus, the change should be made officially in Module:families/data. AG202 (talk) 18:04, 19 June 2021 (UTC)

Support--Tibidibi (talk) 13:59, 20 June 2021 (UTC)

Pinging Korean editors. (Notifying TAKASUGI Shinji, Atitarev, HappyMidnight, Tibidibi, B2V22BHARAT, Quadmix77, Kaepoong, Omgtw15): — Fenakhay ^{(تكلم معاي · ما ساهمت)} 16:06, 20 June 2021 (UTC)

Support, seems like there's no reason not to change this. Kiril kovachev (talk) 16:34, 20 June 2021 (UTC)

Support — Omgtw15 (talk) 18:15, 20 June 2021 (UTC)

Support: Koreanic is rare but established in the linguistic circle. — TAKASUGI Shinji (talk) 02:31, 21 June 2021 (UTC)

Pinging @幻光尘 since it was originally their suggestion in Module_talk:families/data that spurred this proposal here. Thank you! AG202 (talk) 07:48, 21 June 2021 (UTC)

Not my area but having just had a little conversation with AG202: can this be implemented without a vote? Equinox ◑ 01:27, 7 July 2021 (UTC)

I propose that only {{swp}} be used in dictionary entries to link to the corresponding Wikipedia page. Some editors do be converting instances of {{wp}} to {{pedia}}; but the problem therewith is that the latter templet is put beneath ===Further reading===: which is but a wrong practice! The heading is meant only for references (non-inline ones), while Wikipedia (or any other sister project) cannot technically be used as a reference. Therefor, {{pedia}} should be deprecated; and so should be {{wp}}, for it has fallen out of favour with many users. Thus, {{swp}} should be the only templet available for linking to encyclopedia articles. ·~ dictátor·mundꟾ 01:54, 20 June 2021 (UTC)

Wiktionary:Entry layout § Further reading (this was voted): “This section may be used to link to external dictionaries and encyclopedias, (for example, Wikipedia, or 1911 Encyclopædia Britannica) which may be available online or in print.” The claim it is wrong is a fallacy as you redefined it (“meant only for references”); rubbish from Inqilabi is not surprising. J3133 (talk) 02:43, 20 June 2021 (UTC)

I would further note that the following paragraph from there:

This section is not meant to prove the validity of what is being stated on the Wiktionary entries (the “References” section serves that purpose).

I have frequently put sources as to the gender of words under "References", though as I have been told (it felt more like an instruction) that 'we do not use inline references', I didn't even struggle to make the source of the gender explicit. It has annoyed me to see References changed to Further reading - I now learn that these changes were actually damage. --RichardW57 (talk) 13:51, 20 June 2021 (UTC)

I have personally never used {{swp}} and always use {{wp}}, and see it being used all the time, so I don't understand what you mean by it being "fallen out of favour". Thadh (talk) 11:17, 20 June 2021 (UTC)

@J3133: By encyclopedia I was referring to Wikipedia; WP cannot be used as a reference in dictionary entries, as it is only a sister project. That’s why we have the templets {{wp}} and {{swp}} to link to the WP page. (By the way, you can make personal attacks at me, but try to spell my name aright.) ·~ dictátor·mundꟾ 14:45, 20 June 2021 (UTC)

@RichardW57: ===Reference=== is used only for inline sources, whilst ===Further reading=== for non-inline sources. Otherwise both are the same. (See this entry for an example of an approximate use of the headings.) ·~ dictátor·mundꟾ 14:45, 20 June 2021 (UTC)

@Thadh: I myself have used* both {{wp}} and {{swp}}, but as I said, it has fallen out of favour with some editors (not I) as you saw in the diff. ·~ dictátor·mundꟾ 14:45, 20 June 2021 (UTC)

“WP cannot be used as a reference”: try to read again, “Further reading” is “not meant to prove the validity of what is being stated on the Wiktionary entries (the “References” section serves that purpose)” (thus “References” and “Further reading” are not “the same”). Also that was a note of you making your own rules (as when you thought you can add new templates and new parameters and insisted no one can delete them, as was proved otherwise, before your ad hominems). “It has fallen out of favour with some editors”: Irrelevant, as {{wp}} is used by more editors, thus the opposite can be argued. J3133 (talk) 14:48, 20 June 2021 (UTC)

Here is point 5 (which passed) of the vote (Wiktionary:Votes/2016-12/"References" and "External sources") that implemented the difference between “References” and “Further reading” (then “External sources”, later renamed) before the naive Inqilabi makes a fool of himself:

“Allowing the usage of "External sources" only in cases where other dictionaries and encyclopedias (including Wikipedia) are listed as suggestions of places to look, without serving as proof for specific statements in the entry.”

Wikipedia is explicitly mentioned as being allowed. J3133 (talk) 15:07, 20 June 2021 (UTC)

But in reality no one has objected to @Jberkel and others’ continual substitution of {{wp}} with {{pedia}} (I for one definitely think it’s counterproductive). You mostly edit English entries, so you may not be aware of the actual usage of ===References=== & ===Further reading===. And the vote mentions Wikipedia only because {{pedia}} was formerly used beneath ===External sources===; after this heading was renamed to ===Further reading===, the vote was not officially updated, but per our prevalent practice, WP cannot be used beneath ===Further reading===. (Note that our English entries, being the oldest ones here, are the least updated.) ·~ dictátor·mundꟾ 15:18, 20 June 2021 (UTC)

“per our prevalent practice, WP cannot be used beneath ===Further reading===”: You mean your practice, as this is not our practice for most of us. Others do not support this new practice you and presumably some others use (and thus this proposal will likely fail). J3133 (talk) 15:20, 20 June 2021 (UTC)

Hello! I wanted to introduce a new iOS English dictionary app that is based on Wiktionary data. Please check http://www.vedaist.com/ if you're interested. I currently show a very minimal meaning of a word. Noun, verb, adjective or adverb sections for English meanings are shown. Over time I'll be adding more features.

I wanted to acknowledge the great work all of you have put into building Wiktionary, and making it possible for me to build on top of your work. If there is any feedback for me, please reach out. Thanks! — This unsigned comment was added by Toucanvs (talk • contribs) at 08:31, 20 June 2021 (UTC).

Shouldn't you acknowledge Wiktionary on the app pages, to conform to the CC BY-SA 3.0 License?  --Lambiam 11:29, 20 June 2021 (UTC)

I have an acknowledgement in the Settings > Dictionary section with license information there. Or did you mean something else @Lambiam. Toucanvs (talk) 00:18, 22 June 2021 (UTC)

@Lambiam the latest version of the app now credits wiktionary and has a cc license link on each word page. Toucanvs (talk) 10:59, 28 June 2021 (UTC)

ps, thanks for pointing this out @Lambiam. I think the current version I have meets the CC license requirements. The text is "Dictionary content from Wiktionary under the Creative Commons Attribution-ShareAlike license" Toucanvs (talk) 11:13, 28 June 2021 (UTC)

I think that will do, but is it possible to hyperlink to the precise license, e.g. as follows: "Dictionary content from Wiktionary released under the <a target="_blank" href="https://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike License</a>">?  --Lambiam 12:30, 28 June 2021 (UTC)

Oh yes. That's been done. Both Wiktionary and the CC license are links. Toucanvs (talk) 12:58, 28 June 2021 (UTC)

I don't have iOS, so I can't give much feedback on that front, but indeed, it would be good to credit the Wiktionary authors for your uses. ^^ I am a big fan of the adless, trackerless paradigm, though, so I hope that's something you'll never change :) Kiril kovachev (talk) 16:31, 20 June 2021 (UTC)

@Kiril kovachev I updated the attribution to be per entry in addition to the settings. See the 3rd screenshot in https://apps.apple.com/us/app/vedaist-english-dictionary/id1572821331.

I would like to add user based features that would require login in the future, but that's different from tracking for ads. Toucanvs (talk) 11:05, 28 June 2021 (UTC)

@Toucanvs Looks good to me, good luck with your development! ^^

@Toucanvs: please add it to Wiktionary:Wiktionary-supported software (don't mind the deletion notice). – Jberkel 06:50, 21 June 2021 (UTC)

done @Jberkel Toucanvs (talk) 00:18, 22 June 2021 (UTC)

General question to all editors: how would your ideal attribution look like? As an example, when exporting a text from Wikisource, the generated document contain a list of contributors ordered by edits. – Jberkel 09:52, 23 June 2021 (UTC)

@Jberkel have a look at my replies on this thread for the changed attribution per entry. Toucanvs (talk) 11:10, 28 June 2021 (UTC)

Yes, but that's the bare minimum, hence my asking what an "ideal" attribution could look like. – Jberkel 13:47, 28 June 2021 (UTC)

Hello, I have recently been in the process of developing a bot for the purposes of auto-generating derived form entries based on Bulgarian noun conjugation tables. To put it simply: the bot fishes for declension tables across all noun lemmas fed to it, takes note of what derived forms come from what lemmas, and creates definitions based on that data. Once generated, the definitions are either appended to existing entries, as long as they don't already have a Bulgarian section, or a new page is created containing the entry it just generated.

The edits I have already made under my own account using the bot can be viewed here: diff, diff, diff, diff, diff

(apologies, I don't know how to link these properly)

My GitHub repository is linked here - if you have Python knowledge, please run through if you're interested and see if you can spot any bugs. There are a few other resources in there, such as one to help to understand the program more clearly, and some sample output data to show what the edits the bot's making would look like. There are also instructions as to how to run the bot yourself if you wanna trial it out and look for problems.

I additionally wrote a few paragraphs describing the method on my bot's user page, which, if you have any objections to, please let me know once again. If all goes well, I'll post a vote to get the bot approved sometime soon.

If you have any questions or doubts, please ask me for answers, and I will do my best to respond well. One final thing - understandably, few people on here, if any, will have experience with both the Bulgarian language and Python, so - if no one cares, I'll just apply to votes within a few days. However, if there does happen to be anyone interested who could audit for any mistakes, I would be highly grateful for your help. Thanks for reading!

Kiril kovachev (talk) 16:28, 20 June 2021 (UTC)

@Kiril kovachev: I fixed your links for you. Chuck Entz (talk) 16:49, 20 June 2021 (UTC)

@Chuck Entz Thanks ^^ Kiril kovachev (talk) 17:07, 20 June 2021 (UTC)

I don't like new pages being created when there's no evidence that the word has existed in any language. Some inflected forms are best left hiding in the inflection tables. --RichardW57 (talk) 18:50, 20 June 2021 (UTC)

@RichardW57 Surely there's warrant enough in the fact that those forms theoretically can exist? If the lemmas exist in the first place, then the declension tables only show a specific use case of the word. I can guarantee you that if anyone's using the lemma, then they're surely also using the definite form (effectively the word "the"), or the plural form, or whatever. Admittedly, I have no way of gathering evidence for each form as to whether it 'exists' in the wild or not, but declension tables are created with the fact that not all words have a "vocative" or a "plural" in mind, so it won't be creating any purely theoretical forms. Though it makes no sense for completely ordinary words not to have an attested plural, no? The editors that created those tables exclude forms that are obviously non-existent by using the template.

@Kiril kovachev That should work for words that the authors know from their own experience, but I do note that телефон (telefon) is given as an example of a word without a vocative, only to find that its declension table gives it one.--RichardW57m (talk) 12:35, 23 June 2021 (UTC)

The rationale for having declined form entries at all is that it helps readers of a language discover a lemma without necessarily knowing how words in a language conjugate. They can look up an inflected form and wind up on the lemma straight away like that. I felt inspired to make this, by the way, because of Latin declension tables. Check out zodiacus, for example - surely you don't mean to tell me all of these forms have been individually sourced? Kiril kovachev (talk) 16:56, 22 June 2021 (UTC)

A great many Latin word forms actually have quotes. However, I do think that Latin forms are overdone, and to some extent are counter-productive. If one looks up an inflected form, and there is no entry for it, one may yet find it by looking for a word that links to it or even doing a complete text search. However, if languages A and B have it as an inflected form, and language A has had the equivalent of your bot run, but language B has not, one will be directed to the word in language A. This provokes an unproductive race between languages to create entries for their inflected forms. --RichardW57m (talk) 12:35, 23 June 2021 (UTC)

Incidentally, does your bot handle the case of an inflected form being an inflected form of two different Bulgarian lemmas? --RichardW57m (talk) 12:35, 23 June 2021 (UTC)

@RichardW57m Now that you mention it, incidentally not really. As I wrote on the bot's userpage, the bot can trace multiple inflected forms from some given lemma, like if there are multiple senses of the same spelling of a word, but you're quite right in saying it wouldn't account for a totally different lemma declining in the same way as an existing one. It's not beyond implementation, but... would that case come up particularly often? I can't think of any cases off the top of my head where different words happen to decline to the same form like that - though I won't deny that's an oversight on my part. Do you know of any examples?

@Kiril kovachev I don't know Bulgarian, so even a single example is hard work. But, with a little effort, I see that the numerical plural of кос (kos, “blackbird”) is the same as the singular of коса (kosa, “scythe”). I noted a similar problem with the perfects of Latin circumsto and circumsisto. The bot creating entries for the perfect tenses didn't handle their sharing the perfect circumsteti. --RichardW57m (talk) 11:10, 24 June 2021 (UTC)

@RichardW57m I suppose this case isn't too much of a problem, since the behaviour of the bot would be to skip that inflection. There may still be problems on that front though, like that some inflections would only be generated for one of two different lemmas, but I believe that would also not be much of a concern. If some are left uncreated, they can be manually added. Still the problem that they could go unnoticed, I suppose.

As for your point on Latin being oversaturated with forms, I understand that is a very sensible concern. Before making this bot, I hadn't considered what effect that would have on users searching for other languages, nor perhaps the bloat it would generate across the wiki. Nevertheless, I find the convenience of being able to locate a term you're looking for directly rather than having to identify words that link to it a great utility. I would argue that the ease of simply entering a term and being directed to an entry linking to the lemma you're seeking is much more utilitarian than needing to scan through the search results or engage a full-text search. Perhaps it's just for me, but I find that navigating the search results and waiting for dead load-times to be the more arduous part of using Wiktionary. Maybe a minor gripe, but this is part of my motivation why I feel these would help.

Also, though it's correct to say this kind of editing can certainly start an 'arms race', if you will, I wouldn't call it unconstructive, personally: at any rate, it's adding to the dictionary's function at least somewhat, whilst equally not detracting from users-of-other-languages' ability to search in their own. That users may find a different language's entry when searching for their own is unfortunate, but wouldn't that incentivise more of such entries to be created for those languages, too? Rather than a race, wouldn't that make up healthy 'competition' instead? It would be nice to hear more people's opinions from the community about this other than just our own. If it's really the case that people don't want all these pages to be inundated with inflected forms, it isn't a big deal to scrap that idea, but I just thought it would be a constructive direction to go down. I was under the impression that Latin declined form entries were quite helpful.

I do occasionally worry about the sheer flooding of the system. With Pali, we have some significant degree of automated support for 14 writing systems across 10 scripts. A regular masculine noun of the commonest declension has 16 case and number forms, so that's 224 forms. (Inflection isn't yet supported for two of those systems - I want to see evidence for them first, but there are another two writing systems that depend on manual support, and there are several other writing systems or variants that need a small amount of manual support.) Waiting to take off, there's Sanskrit with thirty odd scripts and its large inflection tables, though at present only nominal inflection in Devanagari is productive. (I think it should also support significant sandhi variants.) When checking that Pali inflection tables direct only to Pali entries, I frequently find that the Roman script masculine/neuter genitive/dative singular points to a Finnish inessive. Of course, Swahili verbs do quite well with just a single script. --RichardW57m (talk) 11:10, 24 June 2021 (UTC)

14 writing systems! Out of interest, just what are the 4 not listed on Wiktionary:About Pali? In a similar vein to Pali entry flooding, though, Bulgarian nouns in particular can have at most 9 inflections (with vocative - 7 without), whilst most have between 5 and 7 (masculine 7-9, feminine/neuter 5-7). In comparison, it's not nearly as bad... but for a large number of entries, admittedly still a big footprint.

It lists 10 scripts, not 10 writing systems. The Thai script has two writing systems, one with implicit vowels (thus an abugida in Daniels' terminology) and one where the historical vowels are always explicit (thus an alphabet in Daniels' terminology). Both systems are alphasyllabaries in Bright's terminology. Both of these two writing systems are fully supported. Lao uses three quite different consonant complements - that of Lao, same again with nuktas, and the full set of consonants as extended by the Buddhist Institute. All three are used as alphabets, and the last one is also used as an abugida. Only the two systems using the extended range of consonants is fully automated, but inflection is also automated for the system with nuktas. For the most restricted set, the inflection of masculine and neuter nouns needs manual tuning. There is effectively an eleventh script, the Shan script. (Formally, it is part of the Burmese script.) That comes in two flavours - one with stacked consonant clusters and one where a vowel killer symbol is used. We generate both for lists of alternative spellings, but inflection tables are not yet generated for them.--RichardW57 (talk) 01:06, 27 June 2021 (UTC)

And, insofar as authors' entering the declension tables with maybe-dubious forms... that is another flaw, to be honest. I was planning, however, on using this bot in perhaps a different way than usual, i.e. looking at its output for each entry, at least for several hundred generations, to make sure that it's working as intended, before allowing it to make an edit. That would solve the problem of there being any bugs in the code, as well as correcting any questionable inflections like you mentioned. Maybe this would be more satisfactory? Sorry for the wall. Kiril kovachev (talk) 19:12, 23 June 2021 (UTC)

Well, 'telephone' does have a vocative role in English, as in "Telephone, don't ring. I'm busy". Bulgarian may be different.

Theoretically it can happily exist in Bulgarian too, but one of the only dictionaries online refutes it. Kiril kovachev (talk) 20:29, 24 June 2021 (UTC)

Support. The code looks well documented, but I have too little experience with Pywikibot to meaningfully review it. —TeragR ^disc./con. 18:42, 22 June 2021 (UTC)

Can we set aside the equivalent of an (alcohol-free) marriage counseling facility?  --Lambiam 11:54, 21 June 2021 (UTC)

I have put the discussions in collapsing boxes. 212.224.224.150 15:36, 21 June 2021 (UTC)

As revealed on current RFVs for FemShep, the current wording of WT:FICTION only covers terms originating in the universe. I propose it be expanded with something like "Terms originating in, or which refer to specific entities within, fictional universes...". Examples of affected entries:

1. FemShep, BroShep
2. Supes, Spidey
3. Ship names

As I've said on the RFV for Charizard, I feel that the purpose of the fiction clause is to avoid terms that only make sense in the context of a work of fiction. To be included, it needs to somehow transcend that setting, which in practise means acquiring a more generic meaning than it had on inception. Much like BRAND and genericized brand names, really. In fact, with modern copyright law, a work of fiction is a brand, now that I think about it.__Gamren (talk) 23:41, 21 June 2021 (UTC)

Support — surjection ⟨??⟩ 17:22, 23 June 2021 (UTC)

Tentatively Support; I think the proposed wording is good, though hopefully with more input we can be more certain this doesn't accidentally cover anything we don't want it to. All the things I can think of where I'm not sure whether they should actually be excluded are things which are not affected by the change; for example, Whovian was coined outside but also refers to something outside the specific Doctor Who universe (namely, a real-world fan of that universe), so it's unaffected by either the current or the proposed rule (👍), and a transmat#Noun can transmat#Verb things in 3+ unrelated fictional universes (the cites for the verb are Star Trek, Doctor Who and Supergirl), so AFAICT it's also unaffected...? It seems like this change would also affirm our previous deletion of Talk:MissingNo.. - -sche (discuss) 23:54, 23 June 2021 (UTC)

Vote is up.__Gamren (talk) 15:39, 30 June 2021 (UTC)

What's the current state of DerbethBot and audio? LinguaLibre data is currently not used, and as someone has just remarked, it's tedious to add audio files manually. Metaknowledge (talk • contribs) has started User:Metaknowledge/audiowhitelist, but this is not used yet? Reading some recent discussions with Derbeth (talk • contribs), they seem to be reluctant to make modifications to the bot. Perhaps we should consider a fork of it? – Jberkel 13:55, 23 June 2021 (UTC)

I thought the plan was that Derbeth would use the whitelist, but I haven't checked in for a while. A fork might be a good idea, but whatever we do, I think we need to use whitelisting instead of blacklisting to avoid the crap that has accumulated unnoticed in the past. —Μετάknowledge^{discuss/deeds} 16:30, 23 June 2021 (UTC)

I had some doubts about the whitelist, mainly because some people act as native speakers of multiple languages. I know it's possible if you are raised bilingual, but what about the person speaking Delhi dialect of Hindi and US dialect of English? Are both dialects spoken on the native level? I am not able to judge that, I'm not a native speaker of either. I haven't spoken about my doubts loudly, sorry for this. I became more engaged in linking CJK strokes and feature requests from de.wiktionary. I can apply the whitelist for the most obvious cases (one person-one language) and we can discuss the harder cases. --Derbeth ^talk 16:54, 23 June 2021 (UTC)

Ideally the bot would read the whitelist configuration from the page, and assume it's correct, otherwise it'll be a lot of back-and-forth. – Jberkel 17:18, 23 June 2021 (UTC)

@Derbeth: Yes, that person is native in both. Why are you troubled by native bilingualism? That whitelist was composed carefully, so you don't need to second-guess it. —Μετάknowledge^{discuss/deeds} 17:29, 23 June 2021 (UTC)

@Derbeth I am in agreement with the idea of a whitelist. I could potentially fork the code and add a whitelist although it might be easier for me to rewrite it in Python using pywikibot as I haven't done much Perl hacking in a long while. Benwing2 (talk) 03:01, 24 June 2021 (UTC)

Ok, I implemented support for all whitelist entries. Please take a look at Occitan changes, as Occitan has particularly chaotic organization of files on Commons. I hope I matched dialects correctly. --Derbeth ^talk 06:50, 26 June 2021 (UTC)

Thanks! I checked some Catalan and French entries, all good. – Jberkel 15:07, 28 June 2021 (UTC)

Users whose contributions should not be added.

— This unsigned comment was added by 212.224.226.27 (talk) at 17:24, 23 June 2021 (UTC).

Should we have sense lines (and, in the event we wouldn't otherwise have an entry, entire entries) at pages like Godes, mans, kings/kinges, etc for their use as genitives/possessives, especially in early modern English works before the use of the apostrophe was standardized? (E.g. "by godes grace, I meane not to infringe his directions, for any mans pleasure" in a 1612 text at Google Books.) By vote, we don't include God's, man's, king's, etc as genitives because they're transparently separable into God+-'s, etc; OTOH, we include gods and kings as plurals although they're fairly transparent. So which side of the line is mans on? (As an interesting case, I can find at least one citation of the Latinate genitive Jesu for Jesus; that kind of thing, irregular genitives à la irregular plurals, I certainly would be inclined to include if I could only find enough citations.) - -sche (discuss) 15:47, 23 June 2021 (UTC)

@-sche: I believe we already discussed this. J3133 (talk) 17:26, 23 June 2021 (UTC)

Thanks for that link! I was trying to find that thread before I posted this, because I recalled discussing this briefly with someone. Since it really was "we" who discussed it (the two of us, and one comment from a single other user), I hope this thread attracts more input. As I said in that thread, AFAICT and AFAIK we don't currently have entries/sense-lines for genitives of this type, but... ever since you brought it up, I've been thinking there should be some kind of community consensus (ideally consisting of more than three users) on whether we should or not... - -sche (discuss) 23:18, 23 June 2021 (UTC)

@-sche: I have mentioned contractions below; e.g., mans (“man is”). Should we also include them? J3133 (talk) 11:31, 26 June 2021 (UTC)

@-sche: I created kingis. J3133 (talk) 16:20, 31 August 2021 (UTC)

Seems reasonable to me to add such genitives. As @Vox Sciurorum pointed out on the previous discussion, this is already a regular feature of other languages', even if their genitives are transparent, and I see no harm in adding reasonable genitives like that... my only concern being, could this call into question what else we should include from pre-standardized orthography? From your quote: should 'meane' also be entered as an archaic variant of 'mean'? If not, why is it different from 'kings' or 'kinges', effectively just obsolete spellings of now-standardized inflections? At any rate, though, definite support for forms like 'Jesu'; if they're attested, then they're legitimate and should be added. Kiril kovachev (talk) 09:38, 24 June 2021 (UTC)

I am in favor of adding archaic genitives like Godes, mans, etc. They should just say {{obsolete spelling of|en|God's}}, {{obsolete spelling of|en|man's}} etc. And yes, meane should be added as an {{obsolete spelling of}} too. —Mahāgaja · talk 11:47, 24 June 2021 (UTC)

@Mahagaja: ], unless also used for contractions, then would need two senses (if we also want those forms). J3133 (talk) 19:19, 24 June 2021 (UTC)

Re Kiril: yeah, we definitely already include (and should include) a lot of entries like meane (e.g,, thinke); it's just obsolete genitives/possessives which, as I said in the previous thread, I'm not aware of any examples of us including before now (presumably because we don't include the corresponding modern possessives). - -sche (discuss) 21:30, 24 June 2021 (UTC)

Follow-up question: do we want to link to these obsolete possessive forms from the lemma entries, and if so, how? I think there's generally a benefit to lemma entries containing links to all their inflected forms so those forms are findable (and so erroneous ones can be fixed), but I'm guessing we don't want to change the headword line of king to

"king (plural kings or (obsolete) kinges or (obsolete) kingis or (obsolete) kingys, possessive king's or (obsolete) kings or (obsolete) kinges or (obsolete) kingis or (obsolete) kingys)"

because then it's really long and we're making obsolete forms excessively prominent. We could list kinges et al as alt forms in ], but we don't have entries like ] to shunt mention of the obsolete alt forms to. (In this case, you could say "put the alternative possessives also on ] and let the link in "plural kings" be enough, but that doesn't work when the plural isn't of the same form as the obsolete possessives, like with child.) - -sche (discuss) 02:37, 1 September 2021 (UTC)

Is there a consensus on tone indicators here? I've created a list of the commons ones at User:AntisocialRyan/Tone_indicators. We already have "/s", and others have exploded in online use over the past couple years. See Google Trends for "tone indicators" and "gen meaning". I think the majority of them should be included, or at least on an Appendix page. AntisocialRyan (talk) 20:22, 23 June 2021 (UTC)

I'd say if they meet attestation requirements, include them. Perhaps we could discuss whether /fake and /safe and other regular words like /comment or /wondering would be better handled under /fake, /comment, etc or just by a sense at Wiktionary:Beer parlour/2021/June/ — for comparison, we don't have entries for most parenthetical things like (not really) or (joking), only a few like (!). But the bulk of them, like /s, are as opaque and "idiomatic" as abbreviations like S. and p. which we include, so AFAICT the only hurdle is whether they're attested to the usual standards. - -sche (discuss) 23:30, 23 June 2021 (UTC)

Not sure how many strong sources would include these, but searching something like "genq" on Twitter and going to Latest shows how frequent these are used. Just /genq alone is said multiple times a minute, and that form isn't as common as /gen (harder to search for, though). After studying these a lot I can confirm they're all used often. Is this ok? I will wait for more feedback anyway before creating them all. AntisocialRyan (talk) 23:48, 23 June 2021 (UTC)

• I'd like to request a different name for these than "tone indicators" -- in a multilingual project such as this, "tone" has too many ambiguous meanings (perhaps ironically, given the subject of this thread :) ). For me personally, I first thought from the title that this thread would be about notation conventions for Chinese or Navajo or Igbo or some other tonal language.

As a proposal, how about "intent indicators"? I believe that this is less ambiguous. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:27, 24 June 2021 (UTC)

I like it, but do we decide the names for things or do we use what is widely used already? "Tone indicators" is what they're referred to as generally, I put some sources on that page if you'd like to learn more! :) AntisocialRyan (talk) 19:57, 24 June 2021 (UTC)

Ahh, good point, I agree "tone indicator" wouldn't be a great name as it refers to too many other things, so if both kinds of tone indicator exist in some languages (e.g. if there is a Chinese analogue of /s exists), the contents of the category will be a muddle. We're talking about what to call the category they'd be in, right? Because I assume the part of speech header will just be one of the existing/usual ones, like Interjection (a la "psych!"), or the ol' catch-all header Particle, or perhaps the Symbol header /:s uses. Perhaps we could add a qualifier like "discursive tone indicator", although that gets no google hits. I also see the phrase "tone tags" used, which seems a little less ambiguous: a tone marker in the languages Eirikr mentions could be called a tone indicator, but would someone call it a tone tag? If not, maybe that'd work? - -sche (discuss) 21:24, 24 June 2021 (UTC)

1. Ah right, people do refer to them as "tone tags" as well sometimes, although "tone indicator" is more common. That could work.

2. I have yet to see variants for other languages, I feel like I would notice but I probably don't pay as much attention to posts using non-Latin scripts.

3. "/s" uses the Symbol part of speech header and I think that fits well since its only in written text. AntisocialRyan (talk) 21:54, 24 June 2021 (UTC)

Read this in another language • Subscription list for this multilingual newsletter

Earlier this year, the Editing team ran a large study of the Reply Tool. The main goal was to find out whether the Reply Tool helped newer editors communicate on wiki. The second goal was to see whether the comments that newer editors made using the tool needed to be reverted more frequently than comments newer editors made with the existing wikitext page editor.

The key results were:

• Newer editors who had automatic ("default on") access to the Reply tool were more likely to post a comment on a talk page.
• The comments that newer editors made with the Reply Tool were also less likely to be reverted than the comments that newer editors made with page editing.

These results give the Editing team confidence that the tool is helpful.

Looking ahead

The team is planning to make the Reply tool available to everyone as an opt-out preference in the coming months. This has already happened at the Arabic, Czech, and Hungarian Wikipedias.

The next step is to resolve a technical challenge. Then, they will deploy the Reply tool first to the Wikipedias that participated in the study. After that, they will deploy it, in stages, to the other Wikipedias and all WMF-hosted wikis.

You can turn on "Discussion tools" in Beta Features now. After you get the Reply tool, you can change your preferences at any time in Special:Preferences#mw-prefsection-editing-discussion.

–Whatamidoing (WMF) (talk)

14:15, 24 June 2021 (UTC)

• Hmm. I'm curious about this. I've been working on metrics and quantification in my day job, and struggling with the problem of metrics that don't actually measure what people think they measure.

• Newer editors who had automatic ("default on") access to the Reply tool were more likely to post a comment on a talk page.
• The comments that newer editors made with the Reply Tool were also less likely to be reverted than the comments that newer editors made with page editing.

A follow-up question comes immediately to mind. Granted, these comments weren't reverted, so they're probably not just vandalism. But were those comments themselves worthwhile? Did they add to the discussion in constructive ways? ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:31, 24 June 2021 (UTC)

They didn’t measure how many editors were scared away by it. Like I haven’t edited once on Arabic Wikipedia, could mend no obvious mistake, because they have enabled Visual Editing by default (for surely, editing source-code bidirectionally provokes mistakes of newbs), but I did not discover how to get out of the angry fruit salad. Fay Freak (talk) 23:00, 24 June 2021 (UTC)

@Fay Freak: What a wonderful turn of phrase, angry fruit salad. Thank you for expanding my vocabulary!  :) ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:14, 25 June 2021 (UTC)

something-something can mean so-and-so, but one of the cites is "You're nothing but a something-something bookworm." in which it's not obvious if it's a noun or an adjective. Another example:

In Japanese it's supposedly うんたらかんたら or うんたら. It's also in the title of Family Guy: Something, Something, Something, Dark Side. What to do with this? It's a stand-in word with no obvious PoS. Alexis Jazz (talk) 15:27, 25 June 2021 (UTC)

"A something-something bookworm" is attributive use: in English, all nouns are happy to function as adjectives, no need for a separate PoS header. And to me it doesn't feel like something-something is the same as something, something, something. MuDavid 栘𩿠 (talk) 07:28, 3 July 2021 (UTC)

Is it possible to create a Template:rgn-adj etc. for my term?--BandiniRaffaele2 (talk) 23:28, 25 June 2021 (UTC)

SGrabarczuk (WMF) 01:19, 27 June 2021 (UTC)

Defective pings are by far the most common technical error here in the forums. Every day I see several attempts to correct posts where pings failed due to misspelling of user names or missing signatures. Sad to say, these attempts almost never work. Instead, they make it look after the fact like the pings were done correctly, but without actually pinging anyone.

Here's what you need to do make a ping (I'm using my own name to avoid hitting anyone with stray pings):

1. Create a new post that includes a ping, and sign it.

   A ping happens when a link to the user's user page appears in a new message that is signed in the same edit. I don't know the details of what the system requires to see a message as new, but at the very least it can't be an edited version of something that was already there. If you misspelled something so it didn't link properly or even left the ping out entirely, simply correcting the error accomplishes nothing- you're correcting an old edit, not making a new one. I usually format the new message as a reply to the first one, with a note that I made a mistake in the first ping, and including the ping in the new message- making sure it's correct and that I sign it correctly.

2. Make an edit and include a ping in the edit summary

   Any link to a user's user page in an edit summary triggers a ping, whether there's a signature or not. The only trick is that templates don't work in edit summaries. Instead you have to link to it the old-fashioned way, in double square brackets: ]. If you you want to correct your old edit so it looks right, you can redo the failed ping at the same time in the summary for that edit, as in: "]: fixing my ping".

A couple of other points:

1. There's no need to ping anyone on their own talk page. I've never checked whether it actually creates a notification, because the notification that someone has edited one's talk page is of much higher priority than a mere ping. The only thing such an attempted ping accomplishes is that the kind of people who are picky enough to edit dictionaries tend to find it annoying.
2. It's easy to check your pings in preview: all you have to do is open the link in another tab or another window. This won't affect your edit window. If they don't have a user page yet, you can at least tell from the text on the page you go to whether you're at the non-existent page for an existing user or for one that isn't registered

   If you have a multi-button mouse, right-click on the link. Otherwise (on a Mac, anyway) shift-click. This gives you a menu from which you can select the option to open the link in a new tab or a new window. It's probably not as easy in the mobile version, but I've never used it.

   When you preview your edit, a preview of the edit summary should also show in the same window. You should be able to follow that link the same as you would the one in the text.

I hope you find this helpful. If anyone knows more, feel free to chime in with an addition or correction. Chuck Entz (talk) 00:16, 28 June 2021 (UTC)

Do pings register from e.g. a page creation, page deletion, move, etc? Or just edit summaries? Ultimateria (talk) 03:34, 28 June 2021 (UTC)

A page creation is an edit that has an edit summary, pinging from a page creation should work. As for the others: I have no idea, though they do seem different to me. As a test, I just deleted one of my user subpages and linked to your user page in the deletion reason- did you get a ping? Chuck Entz (talk) 03:48, 28 June 2021 (UTC)

I did not. Ultimateria (talk) 03:53, 28 June 2021 (UTC)

To make it easier: activate beta feature "discussion tools". It adds a reply link, it is autosigned, and it has an icon for pinging participants. Vriullop (talk) 06:54, 30 June 2021 (UTC)

Hello. I mostly don't use this, partly because I doubt the mechanism (maybe merely mentioning a user should "ping" them; cf. subtweet), also because I tend to assume people watch their discussions (but I often ignore my watchlist for weeks too, and then stuff scrolls off the available history). Maybe we should have an info page like WT:PING. It could even redirect to whatever actual help page exists for this feature (on 'pedia or WMF), since that stuff is never easy to find. If you create one here, remember to indicate how to block pings, and warn people that pings may be blocked, and aren't guaranteed to get through. love, Equinox ◑ 00:13, 7 July 2021 (UTC)

Inqilabi is trying to add |withtext=1 parameters to {{bor}} and {{inh}} instead of these templates. This subsection is for reaching consensus (i.e., support or oppose; as an extension of the vote above), which Inqilabi should have created instead of secretly adding them (the parameters were not mentioned above), as this is clearly controversial (especially “Inherited from”; or writing it manually instead). J3133 (talk) 16:33, 27 June 2021 (UTC)

Inqilabi has removed this discussion, which I moved from WT:RFDO, as I am not fussy about where it is placed. J3133 (talk) 05:31, 28 June 2021 (UTC)

I think it is not worth fighting over. There is no clear notion of what changes need a vote or even an advance public notice. In this edit I "secretly" added a |nodot=1 parameter to {{R:TLFi}}. IMO, changes that do not affect users who are not aware of them do not need a vote.  --Lambiam 12:46, 28 June 2021 (UTC)

I agree with Lambiam. The addition of an optional parameter is harmless and @Inqilābī's request was not at all problematic IMHO.--Tibidibi (talk) 13:51, 28 June 2021 (UTC)

Given what a contentious issue this has been, he really should have let things cool down before trying to push for a |withtext= parameter. I'm against adding "Inherited from" to all inherited derivations carte blanche, and don't think "inherited" needs explaining with a link, nor does "borrowed". I'm pretty tired arguing about this issue though and would like a temporary cease fire. --{{victar|talk}} 18:41, 28 June 2021 (UTC)

IMO this whole controversy is pointless, and I agree with Lambiam and Tibidibi. Benwing2 (talk) 02:57, 29 June 2021 (UTC)

Your vote expressed that, so no surprise. --{{victar|talk}} 03:17, 29 June 2021 (UTC)

@Victar: What? I requested for the parameter just 2 hours after the vote had ended, while the recent contention (which was begun by SodhakSH; and for which he’s still fighting) originated 3 weeks later. And, I will not permit any bot-operation for standardising the etymologies, so what is really your concern? Also, having ‘Inherited from’ would help to distinguish inheritances from the plain ’from’ as used with {{der}}. ·~ dictátor·mundꟾ 23:19, 29 June 2021 (UTC)

• Oppose this; I want any short parameter like |wt=1 or |tx=1, that too only if the new templates are deleted. Better to type "from" than these lengthy parameters. 🔥शब्दशोधक🔥 04:55, 29 June 2021 (UTC)

  Lengthy? Sure, you would want to manually link the keywords to the glossary while other editors would benefit from the parameter. The shorter form |wt= was my idea, anyway. ·~ dictátor·mundꟾ 23:19, 29 June 2021 (UTC)

  Mr. Dictātor, when the fuck did I say |wt= was not your suggestion? Even |tx= was somebody else's. These are way easier to type than |withtext=. Asking ould any of you mind if I replace "Inherited" with "{{glossary|Inherited}}" (and same for borrowed) does not mean that I'm going to that: until the new templates exist, I'll use them only in new entries. Answer this one for me: what is value of so many Keep votes at RFDO? 🔥शब्दशोधक🔥 09:28, 30 June 2021 (UTC)

• @Erutuon: Hi. For a long time I have been asking @Benwing2 to add the parameter |withtext= to {{inh}} & {{bor}}, but he’s been sore busy these days— so could you please do the job. As you can see in this discussion, this change would be noncontroversial (4-2-1). Thanks. ·~ dictátor·mundꟾ 20:24, 2 September 2021 (UTC)

  "Noncontroversial"? --{{victar|talk}} 20:49, 2 September 2021 (UTC)

  Yes. You did not say anything ’gainst it, did you? You were only talking ‘cooling down’ things. And SodhakSH was just being faddy, while J3133 was just being agnostic. So no real opposition. ·~ dictátor·mundꟾ 21:33, 2 September 2021 (UTC)

  I am against adding "Inherited from" to etymologies, be it automated or not. If the guideline put forth at Wiktionary:Beer parlour § Stipulation on the templates vote is equally adhered to here as well, I have no issue with the parameter being added to {{bor}}, though preferably without a glossary link, which is unnecessary for a simple term like borrowed. --{{victar|talk}} 21:46, 2 September 2021 (UTC)

  Don't think after this long time you can just do it. I still oppose. {{inh+}} and {{bor+}} do the job nicely enough, I won't opt for the long withtext=1, rather I'll go for +. Svārtava² • 03:51, 3 September 2021 (UTC)

  Svārtava, so did you not notice that people were going to make a compromise? inh+ is going to die— so the parameter proposal is much, much better as the etymological wording would be displayed. ·~ dictátor·mundꟾ 06:35, 3 September 2021 (UTC)

  Inqilābī, inh+ won't die. It may not be used, but no one has the right to kill it as it passed RFDO along with bor+. I'd rather put from with inh than go for |withtext=1. By the way, note I'm not opposing this because you are the proposer; so please don't accuse me falsely of that :) —Svārtava² • 08:19, 3 September 2021 (UTC)

  I think you already asked me to add |withtext=1 and I said I think it's a bad idea because it's less clear and possibly uses more characters than writing the text out, and less convenient than {{inh+}} and {{bor+}}. And furthermore, the opposition to {{inh+}} isn't really about it being another template, but about whether we want to write "inherited from" in etymologies at all or in which cases. So I'm not willing to do this. — Eru·tuon 21:39, 3 September 2021 (UTC)

As per the policy on the use of the borrowed template here https://en.wiktionary.orghttps://dictious.com/en/Template:borrowed/documentation#When_to_use we are supposed to only use it for the borrowing languages spoken at the time of the borrowing. For example, English wouldn't use "borrowed" for a borrowing that happened during Middle or Old English. However, this is only good for languages that we have delineated into different stages, like English (modern, Middle, New), French, Portuguese, Spanish, German, Irish, etc. But what about the many languages that don't have that breakdown? That makes things inconsistent. Like Italian, Albanian, Romanian, Serbo-Croatian, etc. These terms are meant to cover over 1000 years of history in some cases, while Middle English is a specific period in time of 400 years or less. This is a problem both across languages and within them as well. For example, some etymologies might not necessarily explicitly include the "Old" version of the language. Like in French, Spanish, or Portuguese, something may be borrowed from Latin but they don't include the Old French, Old Spanish, Old Portuguese form necessarily, even if it was borrowed during the time that language was spoken. It's also harder in cases like Welsh where the exact time of a word's introduction is not always clear. It helps to know a detailed etymology and history of the word. But for example, some French terms may be listed as "borrowed" from Latin, while others (where Old French is listed as an intermediate) are simply listed as being "derived" from Latin. I do agree that the ultimate goal of this idea is good, and it will be good once everything is actually done, but until then it can be messy, disorganized, and inconsistent. Guess we just gotta work with it. Word dewd544 (talk) 22:24, 30 June 2021 (UTC)