Wiktionary:Beer parlour/2019/September

From Wiktionary, the free dictionary
< Wiktionary:Beer parlour
Archived revision by Mélange a trois (talk | contribs) as of 09:41, 13 September 2019.
Jump to navigation Jump to search

Unified approach for Korean hanja entries

Using the entry at 주 (ju) and 수 (su) as an example:

  1. Should we have separate etymology sections for every hanja in hangeul entries? Many of these are only used as affixes rather than unbound morphemes, and some entries such as 이 (i) can be assigned to as many as 250 hanja.
  2. Would it be better to set a criteria, e.g. only create individual etymology sections at hangeul entries for basic hanja or for those that have entries in major Korean dictionaries?
  3. Where would Sino-Korean compounds be listed to prevent duplication of content? At the hangeul entries or the hanja entries? KevinUp (talk) 00:28, 1 September 2019 (UTC)[reply]

Merge Middle Korean hanja and modern Korean hanja

Modern Korean dictionaries do not distinguish between Middle Korean hanja and modern Korean hanja. Using the entry at 顋#Korean as an example:

  1. Shall we merge Middle Korean hanja and modern Korean hanja under a unified Korean header using the format of 顋?
  2. Is the {{hanja form of}} template suitable for the definition line of such entries?

Note that hanja is used more frequently in Middle Korean literature compared to modern Korean literature, but readings are only available in modern Korean because they are not explicitly stated in Middle Korean literature.

Please state here if you oppose a unified approach for Korean hanja entries. KevinUp (talk) 00:28, 1 September 2019 (UTC)[reply]

Article layout revisited

Previous discussion: Wiktionary:Beer parlour/2018/November#confusing article layout, Wiktionary:Beer parlour/2016/November#Rethinking the approach to the presentation of senses

As of 2019, what are the community's thoughts on an approach similar to User:Wyang/zh-def?

I like the distinct background color which makes definitions easier to find. Some languages (not all) may benefit from a single "definitions" header.

Currently, Chinese Han character entries which uses a single "definitions" header does not indicate whether a particular definition is a "noun", "verb", "particle", etc. and would benefit from proper categorization.

Comments are welcome. KevinUp (talk) 03:20, 1 September 2019 (UTC)[reply]

I support the layout 100%. I don't support putting everything on a page into 1 template. DTLHS (talk) 03:24, 1 September 2019 (UTC)[reply]
Putting everything on a page into one template - This would affect only the definitions. Other templates can still be used within this "definitions" template. KevinUp (talk) 07:10, 1 September 2019 (UTC)[reply]
I generally like the layout or at least an approach that is more beautiful and I also like having data structured in templates. I do not like expanding the width 100% (e.g. what happens with pictures or other media?) and having things collapsed--this is not accessible to users. —Justin (koavf)❤T☮C☺M☯ 04:12, 1 September 2019 (UTC)[reply]
Yes, the collapsible approach is perhaps not that practical. Some of us might be looking for something specific and collapsing everything would cause some information to be hidden when CTRL+F is used. KevinUp (talk) 07:10, 1 September 2019 (UTC)[reply]
Not handy for search and basic display but also not useful for users who have scripts disabled or who use screen readers/text browsers or who have certain sensory motor issues that make tapping on a million links to display content on a page a real chore. —Justin (koavf)❤T☮C☺M☯ 07:15, 1 September 2019 (UTC)[reply]
Well, we could apply visibility options such as "Show derived terms", "Show quotations" similar to what we currently have on the desktop site. KevinUp (talk) 08:02, 1 September 2019 (UTC)[reply]
Sure, but I am opposed to all of the collapsing content that we have now for the same reason. To be sure, entries like set or a are going to be long: that's the nature of those sorts of entries. Making things inaccessible with collapsing content (even for Finnish declensions that I am never going to look at, let alone understand) is just bad practice. JavaScript is great but it shouldn't be mandatory for interacting with basic text like this. —Justin (koavf)❤T☮C☺M☯ 08:56, 1 September 2019 (UTC)[reply]
@Koavf: Is the collapsible content inaccessible without JavaScript? My impression is that it only disappears when the JavaScript code runs. — Eru·tuon 16:19, 1 September 2019 (UTC)[reply]
@Erutuon: Turn off scripts and everything is expanded by default (which is good). Non-script users will have no problem seeing this content. —Justin (koavf)❤T☮C☺M☯ 17:27, 1 September 2019 (UTC)[reply]
@Koavf: Hmm, I thought you were saying that users without JavaScript wouldn't be able to see collapsible content; maybe I misread you. I think collapsible content is collapsed by default for new visitors. What if it were expanded? Then users who have difficulty with the buttons wouldn't have to click anything to see content, but would if they wanted to be able to scroll more quickly. Perhaps it would be optimal if various categories of content were shown or hidden based on which state would lead to less clicking, but I don't know how to get that information. — Eru·tuon 17:56, 1 September 2019 (UTC)[reply]
You did not: I was just sloppy. Basic functionality shouldn't be based on scripts unless it's really something dynamic. The site we have doesn't include interactive elements like a game or anything that really needs to change state in front of someone's eyes or based on his inputs: it's a reference work made up of text with some accompanying media. Scripts just to collapse things that are a mild nuisance to scroll past are just a bad idea. It's generally easier to hit "Page Down" or smash the space bar a couple of times (these don't require very fine motor skills) to go past something you don't care about than it is to tab over to the little arrow that will expand the box or click on it. Finding data would be difficult and informative but I would still be in favor of not hiding anything that is the actual content of the dictionary (but I'm fine with the option of allowing it to be collapsed based on user interaction or preferences--unfortunately, our "expand all declension tables" preferences don't stick around at the moment.) —Justin (koavf)❤T☮C☺M☯ 18:21, 1 September 2019 (UTC)[reply]
I would also prefer for lists (not tables) to be expanded by default with an option to hide it if one wishes to do so. KevinUp (talk) 18:28, 1 September 2019 (UTC)[reply]
@Koavf: When you click the "show x" or "hide x" buttons in the "Visibility" menu in the sidebar, the resulting state is saved in your browser. It's not saved on a per-user basis though; do you mean that the state changes when you switch between browsers? — Eru·tuon 20:02, 1 September 2019 (UTC)[reply]
@Erutuon: No, using the same browser, it eventually goes away as a preference. It would be better if it were an actual user preference. —Justin (koavf)❤T☮C☺M☯ 20:32, 1 September 2019 (UTC)[reply]
@Koavf: That sounds like a bug. The setting is saved in localStorage (source code in MediaWiki:Gadget-VisibilityToggles.js), so it shouldn't go away. I am not sure how to add it in Special:Preferences if that's what you mean. One difficulty with having a checkbox for each category of visibility toggle is that there isn't a set number of categories (synonyms, translations, inflection, derived terms, etc.); they are generated based on section headers or the contents of HTML tags in the parser output. (In MediaWiki:Gadget-defaultVisibilityToggles.js, the category is the first argument to window.VisibilityToggles.register.) — Eru·tuon 20:49, 1 September 2019 (UTC)[reply]
Disgusting. Hard no. --{{victar|talk}} 18:06, 1 September 2019 (UTC)[reply]
Could potentially go for something like this. It's hard to judge from a Chinese entry since I don't understand that language. We would also need to be careful about what we hide/collapse by default and what we don't (and possibly tie that into individual user settings). Oh yes, and I agree with whoever made a fuss about JavaScript-less users. It should remain readable in Lynx etc. (it doesn't have to be beautiful, as long as we show all the content to those clients rather than some unusable JS placeholder). Equinox ◑ 10:00, 5 September 2019 (UTC)[reply]
Additional point I just remembered: quite a large number of people are colour-blind (in one way or another) and it's hard to find sets of colours that will suit all those different colour-blindnesses. With graphs and charts, you can ameliorate this by using texture (red spots, blue stripes, green crosses), but with text you can't do a lot. So we shouldn't rely on colour alone to indicate anything: it should only be a bonus hint, and also needs to have strong contrast with the background. Equinox ◑ 11:55, 5 September 2019 (UTC)[reply]
I do like the look of this, I would like to see an expanded version which would demonstrate how other key parts of an entry would be handled (e.g. etymology, translations). While I don't like using a single uber-template for this sort of thing, the benefits of having the data in the entry organized in a machine-readable manner may outweigh the costs of such a method. - TheDaveRoss 11:58, 5 September 2019 (UTC)[reply]

Code for comparison

New code
{{zh-def
|n|[[sugar]]
|syn: 食糖
|ant: 鹽
|x1: {{zh-x|糖尿病|[[diabetes]]}}
|x2: {{zh-x|糖{tong4}水|[[sugar water]]|C}}
|-
|n|[[candy]]; [[sweets]]
|mw: m:塊-“piece”,c:嚿-“piece”
|syn: 糖果
|x1: {{zh-x|棒棒糖|lollipop|C}}
|x2: {{zh-x|糖 食 得 多 冇益。|Eating too much '''candy''' is unhealthy.|C}}
|-
|n|{{zh-alt-form|醣|[[saccharide]]}}
|lb: organic chemistry
|x1: {{zh-x|多糖|polysaccharide}}
}}
Current code
# [[sugar]]
#: {{zh-x|糖尿病|[[diabetes]]}}
#: {{zh-x|糖{tong4}水|[[sugar water]]|C}}
# [[candy]]; [[sweets]] {{zh-mw|m:塊|c:嚿}}
#: {{zh-x|棒棒糖{tong4-2}|lollipop|C}}
#: {{zh-x|糖 食 得 多 冇益。|Eating too much '''candy''' is unhealthy.|C}}
# {{lb|zh|organic chemistry}} {{zh-alt-form|醣|[[saccharide]]}}
#: {{zh-x|多糖|polysaccharide}}

====Synonyms====
* {{sense|sugar}} {{zh-l|食糖}}
* {{sense|candy}} {{zh-l|糖果}}

====Antonyms====
* {{sense|sugar}} {{zh-l|鹽}}



















I copied the code from User:Wyang/zh-def#Code so that other users can comment on the approach rather than the appearance.

Some languages (not all) may benefit from such a structure. KevinUp (talk) 18:28, 1 September 2019 (UTC)[reply]

I have a feeling this styling can be done with CSS and JS, rather than having to put so much load on Lua modules. —AryamanA (मुझसे बात करें • योगदान) 01:35, 11 September 2019 (UTC)[reply]
I love it! Even if without hide/show, if everything is shown, it is great. I like the little buttons: Synonyms, Example... sarri.greek (talk) 09:36, 12 September 2019 (UTC)[reply]

Requesting language code for Middle Japanese

Previous discussion at Wiktionary:Beer parlour/2018/February#Middle Japanese, https://en.wiktionary.org/wiki/User_talk:Poketalker#Template_%7B%7Bbor%7Cja%7Cltc%7D%7D

Category:Japanese language currently lacks an ancestor, Middle Japanese, which can be further broken down into:

  1. Early Middle Japanese (800 to 1200AD)
  2. Late Middle Japanese (1200 to 1600AD)

This is because there are no ISO language codes for Middle Japanese. Therefore I would like to propose three new language codes for:

  1. Middle Japanese - ja-mid
  2. Early Middle Japanese - ja-mid-ear
  3. Late Middle Japanese - ja-mid-lat

By having these language codes we are able to create categories such as:

  1. Category:Middle Japanese terms with quotations
  2. Category:Middle Japanese reference templates
  3. Category:Early Middle Japanese terms borrowed from Middle Chinese
  4. Category:Late Middle Japanese terms borrowed from Early Mandarin

Technical considerations

These three languages can be designated as etymology-only languages because Middle Japanese is already merged with modern Japanese based on current practices. KevinUp (talk) 03:20, 1 September 2019 (UTC)[reply]

The etymology language codes can be created, but unfortunately categories starting with an etymology language name aren't supported. That is, templates can't categorize into them and there aren't category boilerplate templates for them. For instance, {{der}} only accepts an etymology language code as its second parameter (the language from which a term is derived), not first. Changing this would at least allow for more specificity in etymologies.
Middle Japanese can't treated as an ancestor of Japanese if it is an etymology language with Japanese as its parent. It doesn't make sense for a language to descend from a subvariety of itself. (That sort of relationship makes Module:family tree crash with a stack overflow, and it breaks the link to further-back ancestors. I tested this by making grc-koi, Koine Greek, an ancestor of grc, Ancient Greek, and previewing some pages. In ἐπί, Ancient Greek was not seen as a descendant of Proto-Indo-European anymore. I suppose this would be fixed by giving the etymology language an ancestor, though.) It would make sense for Modern Japanese (an etymology language) to descend from Middle Japanese, though without a category for Modern Japanese terms inherited from Middle Japanese, this relationship would only be used in family trees, if Module:family tree would display it. — Eru·tuon 08:03, 1 September 2019 (UTC)[reply]
Thank you for looking into this. If we can't create categories for etymology-only languages, I think (1) Middle Japanese will have to be designated as a full language code with Old Japanese as its ancestor and Japanese as its descendant. As for (2) Early Middle Japanese and (3) Late Middle Japanese, these two languages can be set as etymology-only languages with Middle Japanese as their ancestor.
Meanwhile, Category #3 and #4 above can be replaced by Category:Japanese terms derived from Middle Chinese and Category:Japanese terms derived from Mandarin (derived instead of borrowed and not that specific). KevinUp (talk) 18:28, 1 September 2019 (UTC)[reply]
At the moment, Middle Japanese can only have scripts if it is given a full language code. In any case, if it were an etymology language, its scripts couldn't be used anywhere but in etymology templates.
With Middle Japanese as an etymology language, Module:etymology would currently allow Category:Japanese terms derived from Middle Japanese (not to express an inheritance relationship, but the situation where one language borrowed from a second language, which borrowed from a subvariety of the first language), but would not allow Category:Japanese terms inherited from Middle Japanese, because it resolves an etymology language to its parent before checking that the first language can inherit from the second. So "Japanese inherited from Middle Japanese" is resolved to "Japanese inherited from Japanese", which the module objects to. If Middle Japanese is not made a full language, two ideas: allowing a term in one language to be inherited from a subvariety of the language, or allowing etymology languages in both positions of the derivation relationship (Category:Modern Japanese terms inherited from Middle Japanese instead, which makes more sense than Category:Japanese terms inherited from Middle Japanese). — Eru·tuon 21:23, 1 September 2019 (UTC)[reply]
I moved your comment below up here in case you haven't read my reply above. I think Middle Japanese will have to be made a full language, like how Middle Chinese is made a full language to avoid the complications you mentioned above. KevinUp (talk) 21:36, 1 September 2019 (UTC)[reply]
mid is the code for Mandaic, so mid-anything is not appropriate for a code for anything but a variety of Mandaic.--Prosfilaes (talk) 19:25, 1 September 2019 (UTC)[reply]
Thanks for pointing this out. I've changed the proposed language code to ja-mid instead. KevinUp (talk) 21:36, 1 September 2019 (UTC)[reply]
  • Various thoughts.
  1. Will we also create a code for Early Modern Japanese? Broadly speaking, "modern Japanese" can be dated from around the mid-to-late-1800s with the fall of the Edo Shogunate and the rise of the Meiji, the opening of the country and the influx of foreign words and concepts, the repurposing of existing words for new meanings, and the deliberate forging of new vocabulary in an attempt to modernize and standardize the language.
  2. Do we really need to make these new codes into full-fledged, separate and distinct languages, with their own entries and template infrastructure and the like? This seems like the wrong way to work around what seems to be a minor technical issue with the etym inheritance implementation.
I'll hazard a guess to say that most of the entries that we might put in the proposed new "language" headings for Early and Late Middle Japanese would be duplicating content from our modern Japanese entries. The main differences come down to things like sense development (such as ありがとう (arigatō) shifting from "in a manner difficult to exist" to "in a manner difficult to bear" to "welcome" and then the modern "thanks" sense), phonetic realization (such as /je/ and /we/ merging ultimately into /e/) and conjugation patterns (like the 下二段 (shimo nidan) lower bigrade conjugation pattern flattening out into the 下一段 (shimo ichidan) or modern lower monograde pattern). I feel much more comfortable trying to explain all of this in the context of "Japanese", rather than duplicating entry data across multiple different language headings, especially as the older senses and sometimes even conjugations are still used. I'd also like to point out that monolingual sources treat Middle Japanese as a matter of footnotes and formatting within entries for the modern language, rather than as a distinct entity.
‑‑ Eiríkr Útlendi │Tala við mig 23:03, 3 September 2019 (UTC)[reply]
  1. @Eirikr: Yes, I think it would be a good idea to create a code for Early Modern Japanese called ja-ear set as an etym-only language with Category:Japanese language as its ancestor. By doing so we can have categories such as Category:Chinese terms borrowed from Early Modern Japanese.
  2. The early and late varieties (Early Middle Japanese, Late Middle Japanese, Early Modern Japanese) will not be having their own entries and template infrastructure because these languages will only be used in the etymology section to display statements such as "From Early Modern Japanese X, from Late Middle Japanese Y", etc. to reflect sound or spelling changes.
As for Middle Japanese, it will be made a full language so that we can use the language code in templates and quotations within the Japanese section. I agree that some of the older senses and conjugations are still used in written Japanese so it is not necessary to create a separate entry for Middle Japanese. Middle Japanese can be merged into Japanese like how monolingual dictionaries treat the language. {{ja-see}} can be used to redirect entries with archaic spelling to the modern spelling. KevinUp (talk) 22:27, 4 September 2019 (UTC)[reply]
Okay, so the proposal is to have Middle Japanese as a full language but with no entries of its own? At the moment that means that Middle Japanese links would go to the Middle Japanese section, not the Japanese section as intended. Perhaps Module:links could be made to direct Middle Japanese links to the Japanese section. It would complicate linking in other modules because they couldn't rely on the section name being the canonical name anymore. — Eru·tuon 02:16, 5 September 2019 (UTC)[reply]
Yes, the plan is to have Middle Japanese as a full language with no entries of its own, similar to how Middle Chinese is unified with Chinese. The linking problem is an issue for languages that use such an approach. For example, all the hanzi entries in Category:Cantonese nouns link to TERM#Cantonese rather than the correct form TERM#Chinese. One way to overcome the linking issue for Middle Japanese is to periodically search for the following:
  1. {{l|ja-mid|TERM}} → convert to {{ja-l|TERM}} {{q|Middle Japanese}}
  2. {{m|ja-mid|TERM}} → convert to {{ja-mid-inline|TERM}} (new template similar to {{okm-inline}})
  3. {{cog|ja-mid|TERM}} → convert to {{cog|ja-mid|-}} {{ja-l|TERM}}
  4. {{desc|ja-mid|TERM}} → convert to {{desc|ja-mid|-}} {{ja-l|TERM}}
This is of course, an inefficient way to deal with this issue, but it is not uncommon to have links that link to nowhere, For example, I often click on Middle French links that only have a French section. I wonder if there's a way to identify links that already have a page but lack an entry in the target language so that false positives can be identified. KevinUp (talk) 03:15, 5 September 2019 (UTC)[reply]
Yeah, actually Jberkel's "wanted" lists check for that. For instance, quite a few of the links in the Serbo-Croatian list go to pages that already exist. So that's good, it won't be too hard to clean up the links. — Eru·tuon 03:30, 5 September 2019 (UTC)[reply]

Practical considerations

Pinging also @Dine2016, Eirikr, Poketalker, Suzukaze-c, TAKASUGI Shinji to inform them about this proposal.
  1. Currently, we have quotes from Nippo Jisho ((deprecated template usage) 日葡辞書) which are written in Latin script. Shall we add Latin as one of the scripts for Middle Japanese along with the Japanese script?
  2. Any thoughts on adding entries into Category:Japanese terms inherited from Middle Japanese after the language code is available? KevinUp (talk) 18:28, 1 September 2019 (UTC)[reply]
    This would include pretty much everything that is not a modern coinage or borrowing. I'm not sure about the utility / usefulness / use case for this category. See my comment above about keeping this within the context of "Japanese". ‑‑ Eiríkr Útlendi │Tala við mig 23:03, 3 September 2019 (UTC)[reply]
    Yes, this category would include all terms that existed in pre-modern literature. Perhaps some other category such as Category:Middle Japanese terms borrowed from Middle Chinese would be more useful. Lemmas can be put into this category if quotations of the Sino-Japanese term can be found in Middle Japanese. KevinUp (talk) 22:27, 4 September 2019 (UTC)[reply]
3. What shall we do with the following entries?
  1. かはす#Middle Japanese
  2. かはる#Middle Japanese
  3. かふ#Middle Japanese
  4. かへす#Middle Japanese
  5. かへる#Middle Japanese
  6. かめ#Middle Japanese
Shall these entries be merged into Japanese? KevinUp (talk) 21:54, 3 September 2019 (UTC)[reply]

Category:User_la-5

This category was created by a single user who grossly overestimates their skill in the Latin language - they haven't managed to even correctly write the description, although they refer to themselves in it in the singular. There is no legitimate need for this category any more than there is a need for Category:User_en-5. I propose that it be deleted. Brutal Russian (talk) 13:48, 3 September 2019 (UTC)[reply]

I missed that; that’s really gross. The custom one on the author’s, Aearthrise’s, user page is likewise horrifying. He does not even inflect … Fay Freak (talk) 00:31, 4 September 2019 (UTC)[reply]
LOL, though. Mélange a trois (talk) 21:55, 4 September 2019 (UTC)[reply]
Was going to suggest the same thing, also the Category:User la-N should be deleted. 𐌷𐌻𐌿𐌳𐌰𐍅𐌹𐌲𐍃 𐌰𐌻𐌰𐍂𐌴𐌹𐌺𐌹𐌲𐌲𐍃 (talk) 04:22, 5 September 2019 (UTC)[reply]

User_la-x category templates

(Notifying Fay Freak, JohnC5, Benwing2, Lambiam): @Urszag

Are all written in broken Latin.

  • The verb "contribuere" is not used in the intended sense - nor any other single verb to my knowledge;
  • "usor" in all category descriptions should read "usuarius" as in the template;
  • la-0: Hic usuarius aut nullam aut paucam linguam intellegere potest - should read "Hic usuarius aut nihil aut pauca latine intellegere potest";
  • la-2: "media latinitas" means "medieval Latin" - rephrase as "medius gradus", "satis bene...potest";
  • la-3: "callidissima latinitas" means "most ingenious" or "extremely cunning Latin" - rephrase as "probe ac latine";
  • la-4: the whole phrasing smacks of translationese, should probably say "latine loquuntur pariter~similiter ac/tamquam sermone patrio".

Could someone kindly direct me to the templates that should be edited? In addition, as far as I understand it's important that the phrasing reflect one's active knowledge of a language, and not just passive understanding - is this correct? In that case I'm planning to change the phrasing to "latine scit et scribere potest". My thinking is that due to the general lack of active Latin users people might be rather judging their reading skill - there are more la-3 tagged users than it-3 and ru-3, which I find difficult to believe (it says "speaks fluently" in the Russian template). If anyone has further translation suggestions, they'd be very welcome. Brutal Russian (talk) 14:57, 3 September 2019 (UTC)[reply]

Template:User la-0 DTLHS (talk) 14:59, 3 September 2019 (UTC)[reply]
And Template:User la-1, Template:User la-2, Template:User la-3, Template:User la-4, and Template:User la. (: Maybe they should be renamed la-I through la-IV. :) The first sense of contribuo at Gaffiot is “to bring in one’s share”, which is similar in meaning to “to contribute”.  --Lambiam 20:13, 3 September 2019 (UTC)[reply]
Thank you both. You can get a sense of using a word similar in meaning if you substitute contribute in the English description for any of its synonyms, e.g. "this user can bestow in simple Latin". Brutal Russian (talk) 21:29, 3 September 2019 (UTC)[reply]
  • contribuere Hm, on the internet? The English contribute, the German beitragen etc. arguably hadn’t this sense either before Stallman invented it; though I see that this stretches the Latin meaning more (simply put, Latin contribuere does not mean “to contribute”; in German it is more zuweisen, zuschlagen). What do you suggest? We should ponder more how to do GNU propaganda in Latin. But maybe as a Discord user you aren’t much into it.
  • Yes, usor isn’t even a word, except as a scanno for uxor or ūsūrīs etc.; see also Talk:proprietor. Ridiculous.
  • Indeed, media latinitas is Middle Latin aka Medieval Latin.
  • Yeah, the superlative callidissima is off, and evidently translates Romance.
  • Yeah, they tried to translate modern linguistic categories (“native speaker”, “natively” – how would a Roman say?)

When you have invented true Latin formulations, you should not miss to get Meta Wiki and the rest to fix their bad Latin. They have similarly bad phrasings, though not the same. I do not understand where the data is saved on Meta Wiki, possibly it is in software (can somebody find the texts?), but you find the texts displayed via meta:Category:User la. Fay Freak (talk) 22:35, 3 September 2019 (UTC)[reply]

Vicipædia defends usor as Neo-Latin.  --Lambiam 10:45, 4 September 2019 (UTC)[reply]
  • @Fay Freak I don't know whether there is an established word for it (even if a medieval one), I just know that contribuere is not that word - neither could I properly define what exactly it means, I just know it doesn't mean the same as its English or Romance look-alikes. Whatever the GNU propagandists come up with should at the very least be usable intransitively, for instance conferre. Btw, could you elaborate on why Discord users aren't supposed to be into it? =P
  • I've never come across a proficient speaker saying "native speaker" or discussing how to say it - I myself wouldn't outright censure nātīvus locūtor/ōrātor, but I wouldn't endorse it either - I'm not even sure which of the several options S&H give for "native" is the best one. For the time being, I don't think there's a need to use an equivalent to the English expression - the phrasing I suggest in the initial edit looks fine to me.
  • @Lambiam As a fellow Discord Latinist who writes excellent Latin says - and we don't agree in everything, but here we definitely do - if that's what it says on Vicipaedia, it's definitely wrong. They've managed to get the name of the whole language wrong, for Jupiter's sake (it's not Latina any more than it's Italiana, Española, Française etc). I think it remains so broken because people who see that it is aren't the same people who know how to fix it, and the former despair before even trying (that's true for me at least). I wouldn't be surprised if that page is usor's first attestation xD Brutal Russian (talk) 15:55, 4 September 2019 (UTC)[reply]

A category for images?

I think it would be useful to have a category which shows which entries (in each language) include images. However I'm not sure if there is a way that can be found to automatically categorise them rather than adding a category manually. Anyway, let's see what the reaction to this proposal is like first. DonnanZ (talk) 13:36, 5 September 2019 (UTC)[reply]

Maybe. Why is it useful? Who will use it, for what? Equinox ◑ 13:48, 5 September 2019 (UTC)[reply]
That's what I want to find out. I for one would make use of it, even to find entries that don't have images and would be better with them. And we seem to have categories for virtually everything else. DonnanZ (talk) 13:57, 5 September 2019 (UTC)[reply]
But how would you use a category of images to find entries that don't have images? I think there is no technology to say "list all entries NOT in a category". Equinox ◑ 14:11, 5 September 2019 (UTC)[reply]
Technology, no. One could notice an entry missing from the category, investigate and possibly rectify the omission if a suitable image can be found on Commons. And if one can't be found creating one from your own work is possible if you know where to find and photograph something suitable, I have been doing that lately. DonnanZ (talk) 14:20, 5 September 2019 (UTC)[reply]
Actually, there is a method to search for entries that lack a certain template or entries that are not in a certain category. Try this: KevinUp (talk) 15:36, 5 September 2019 (UTC)[reply]
I am not aware of any way to do this (automatically, it could easily by done asynchronously by analyzing database dumps) unless we started putting all images in templates. DTLHS (talk) 17:42, 5 September 2019 (UTC)[reply]
A template attached to the image entry is what I am thinking of, as long as it would allow access to the image itself. DonnanZ (talk) 18:39, 5 September 2019 (UTC)[reply]
To create a category for images such as Category:English terms with images, a template for images such as {{image|en|File:Carrots with stems.jpg}} will be needed. KevinUp (talk) 22:25, 5 September 2019 (UTC)[reply]
Hmm, not what I intended. I would like that to be superseded by the pagename if possible, e.g. {{image|PAGENAME|File:Carrots with stems.jpg}}. DonnanZ (talk) 23:15, 5 September 2019 (UTC)[reply]
Then we need to use templates, in place of using Mediawiki code. And the templates can never keep up with the capabilities of Mediawiki to display images. If you think that one way to embed images is the only used here then you are mistaken. Given that words for plants denote both the plant and the fruit it often makes sense to have a gallery showing the fruit maybe in different processing stages, the plant from the near in different seasons (bearing fruits, or when yet only blossoms), the plant from afar. Example: بَلاذُر (balāḏur) which meant the marking-nut before the New World explorations and now means cashew, so it has two, slightly different to German Neugewürz with its descendants. That’s what I expect from a dictionary to tell me what a plant name means.
We also use {{multiple images}}, or mostly only Sgconlaw and I use that, for example on moccasin, for different purposes – I use it to have horizontal grouping if there is space to the left but not enough content in the bottom to show one image under another. Turkish ispinoz / اسپنوز: Male and female finch.
This {{multiple images}} is problematic though because it doesn’t let me change relative image sizes so I have to pick roughly fitting ones :/.
It is probably better to only have the category system (if it has any use) but let editors categorize manually with {{cln}}. Fay Freak (talk) 00:14, 6 September 2019 (UTC)[reply]
A
The purpose of a category for entries that had images would be what? To review the appropriateness and adequacy of images? One could use search to find them in groups by using searchbox searches like 'incategory:"English nouns" incategory:"English lemmas" insource:/\[\[((fF)ile|(iI)mage)\:/'. One could add searches for galleries and other display generators.
I would have thought that the main problem is finding entries that might need images and also fit with one's topical interest or skills.
One could always use, say, Category:Requests for images in English entries to find a few entries that need images. Intersecting that category with a topical category would narrow the search. One could look for items in such a category that also had {{comcatlite}} or {{commons}} to find some that would be easy to fill. One could also exclude pages that already had images using -insource:/\[\[((fF)ile|(iI)mage)\:/'
A problem with a category like 'English entries without images' is that the category is so large as to not be usable in doing intersection searches in the search box. Another is that it would miss large numbers of definitions that were missing images because the English L2 section already had one definition with an image.
I would think that using {{rfi|en}} and adding "topic=" tags (or equivalent) would enable targeted searches (with or without categorization) for definitions that needed images. DCDuring (talk) 00:41, 6 September 2019 (UTC)[reply]
I was thinking of Category:English terms with images as mentioned by KevinUp (above), I feel Category:English terms without images would end up being far too large, and therefore a definite non-starter. DonnanZ (talk) 12:46, 6 September 2019 (UTC)[reply]
You can find pages with images using the following searches: insource:/(File|Image):.*(jpg|jpeg|png)/. This can be combined with incategory keyword. (A duplication od DCDuring's information above, oh well.) --Dan Polansky (talk) 10:39, 6 September 2019 (UTC)[reply]
There is so much that an active contributor can do with CirrusSearch. I'm reading up on regular expressions to do fancier things. But the "basics" are quite powerful. See CirrusSearch Help. DCDuring (talk) 13:52, 6 September 2019 (UTC)[reply]
All this is great to know - we should include it in a Help page like Help:Advanced Wiktionary skills. --Mélange a trois (talk) 21:33, 6 September 2019 (UTC)[reply]

Isekiri or Itsekiri?

Discussion moved from WT:Tea room/2019/September#Isekiri or Itsekiri?.

Module:languages/data3/i gives “Isekiri” as the main name for language code its. But “Itsekiri” is much more common.  --Lambiam 03:20, 7 September 2019 (UTC)[reply]

This is about the site as a whole, so I moved it from the Tea room, which is for discussing specific entries.
As for the topic itself, I notice that Wikipedia has w:Isekiri language as a redirect to w:Itsekiri language. Chuck Entz (talk) 03:56, 7 September 2019 (UTC)[reply]
I might add that its' spelling can lead to some head-scratching when used without quotes in sentences... ;p Chuck Entz (talk) 04:01, 7 September 2019 (UTC)[reply]
I support the change. @-sche, in case you want to weigh in. —Μετάknowledgediscuss/deeds 01:16, 8 September 2019 (UTC)[reply]

Replacing de-sysop votes with confirmation votes

Please read and comment on this proposal here: Wiktionary:Votes/2019-09/Replacing de-sysop votes with confirmation votes. —Μετάknowledgediscuss/deeds 03:56, 8 September 2019 (UTC)[reply]

Wikipedia Moss Project

Over at Wikipedia, some of you may be aware, there is a project called Moss which seeks to eliminate a pet hate of mine, tyops. A useful byproduct of this project is that it finds words potential missing Wiktionary words. Below around 100 such entries. The number at the beginning represents the number of occurrences in en.wikipedia. Enjoy and happy editing! --Mélange a trois (talk) 17:27, 8 September 2019 (UTC)[reply]

If only WP were valid attestation. This doesn't belong here. We could put it in WT:REE or a subpage thereof, an appendix, or a userpage [sic]. DCDuring (talk) 23:40, 8 September 2019 (UTC)[reply]
Technical, moth anatomy
Technical, AUS and NZ, ecology
Science fiction. Primarily Babylon 5 universe, but some other usage.
It would be cute/fun/useful? to have some automated bot-o-matic thingy that would connect that project with this one, along the lines of Wiktionary:Wanted entries. But don't go mad because a lot of them will be rubbish words. Equinox ◑ 23:59, 8 September 2019 (UTC)[reply]
Unsurprisingly, it's much easier to create long lists of "things that could be words" than to actually create entries. DTLHS (talk) 00:26, 9 September 2019 (UTC)[reply]
Very true, but to me that suggests that we just need a way to (permanently? or for some period of years) strike non-words from the record. I've noticed BTW that sometimes the very same word appears twice in WT:REE in successive years, perhaps because somebody forgot they'd added it before. Equinox ◑ 00:27, 9 September 2019 (UTC)[reply]
How about a list of failed requests, with explanation of why? Chuck Entz (talk) 01:50, 9 September 2019 (UTC)[reply]
Yes yes but once again we're suffering from not having any structure to our entries, just big lists and bullets and indents. If we have a list of "words to avoid" who's to say anyone will look at it? If we had a form where you filled in WORD + DEFINITION + SOURCES then we could validate it right off. Equinox ◑ 02:05, 9 September 2019 (UTC)[reply]

Inconsistent use of qualifiers in translations

I noticed e.g. here in the Swedish translations, that qualifiers sometimes comes before the terms. TranslationAdder.js always inserts them after the term. I found no guidance in EL.

I would like this to be more consistent so that my input filler script can pick up the qualifiers consistently. I suggest we agree here and then instruct a bot to do the job of moving them right. WDYT?--So9q (talk) 08:39, 11 September 2019 (UTC)[reply]

I think that in this specific instance {{sense}} is more appropriate – which IMO should always come before the term. The use of {{sense}} in translations should of course be rare, because there ought to be a single sense per list, but occasionally a target language will have distinctions that are not present in English. I see though that other examples that I can think of also use {{qualifier}}; e.g. at sister we have “Turkish: abla (tr) (elder), ...”, while I feel “Turkish: (elder sister): abla (tr), ...” would be better.  --Lambiam 10:32, 11 September 2019 (UTC)[reply]
Another example where qualifier comes first (see german translations). There is also semicolons as separators instead of commas. What a mess.--So9q (talk) 13:45, 11 September 2019 (UTC)[reply]
You will not find any consistency here. Translation sections are a free for all. Trying to clean up translations has driven several users off of the project in frustration. DTLHS (talk) 15:27, 11 September 2019 (UTC)[reply]
Shouldnt’t it technically be distinguishable by whether it comes before or after commata?
It can also be more complicated. For stubble “short stalks left in a field after harvest” I could for some Slavic languages discern a distinction between the stubble itself and a field of stubble, which latter might likewise been sought and are more commonly used in the respective languages, and I added them inside of the qualifiers. Guess one needs AI for the translation tables.
I support more markup though, so at least those who know can do better. @DTLHS I am myself shocked how many wrong langcodes or uses of {{t}} outside of translation tables by me you had to correct. I believe it is facilitated by the different source code formatting, the fact that in the translation tables the language names are in plain text. If the name was fetched like with {{m+}} the former error would be impossible and the latter less likely because it arises from copying terms to reuse them and deleting the plain text language name but forgetting to replace the template name. The language name is fetched somewhere anyway for the section link, unlike with {{t-simple}}.
(On the other hand one adds more language names than there are codes. Sometimes Christian Palestinian Aramaic, Jewish Palestinian Aramaic, Jewish Babylonian Aramaic under “Aramaic”, example in bed) Fay Freak (talk) 16:12, 11 September 2019 (UTC)[reply]
I'm no tech maven, but further automation of the translation tables is likely to have a dramatic negative effect on entry load times for some of our larger entries, especially those with highly polysemous English terms. [[a]] and [[water]] come to mind, but there are others. Maybe someone with good tech foo can come up with Summer-of-Code projects that would help with these. DCDuring (talk) 19:05, 11 September 2019 (UTC)[reply]

Should we include non-native audio pronunciations?

I came across a French user's audio file for the English word bicycle and removed it on sight as being unhelpful for English dictionary users, as well as nominating multiple files by the same user for deletion here. Two users including the uploader are arguing to keep the files, and I wanted some Wiktionary editors to weigh in. Maybe I'm wrong in wanting them deleted from Commons since I don't know their policy, but can we agree that there's no place for these in Wiktionary? Ultimateria (talk) 15:11, 11 September 2019 (UTC)[reply]

I also want to know if @Derbeth and @0x010C will choose to stop importing such recordings. Ultimateria (talk) 15:24, 11 September 2019 (UTC)[reply]
They might be kept, provided that they are sufficiently marked that they are not added automatically by bots. Who knows what one can use them for, maybe to illustrate articles about learning languages. They should not be included in the dictionary. There are enough native accents, it’s only noise. Fay Freak (talk) 16:18, 11 September 2019 (UTC)[reply]
User:Fay Freak brings up a possible tangential use of them but that would really be more appropriate at b: or v: (likely at b:fr: and v:fr, specifically) for interactive media teaching someone to speak English. I mean, there are already so many accents and lects of English let alone all of the hundreds of millions (billions?) of non-natives who have such wildly varying accents. I really don't see the value of this here since the goal is to show how a word is used by the community that uses that word. If a word gets adopted into another language, then use that pronunciation for that entry. —Justin (koavf)❤T☮C☺M☯ 17:13, 11 September 2019 (UTC)[reply]
I am having a similar problem in trying to delete an incorrect Armenian pronunciation here. Maybe we should block the bots for importing incorrect pronunciations, until their owners learn to maintain blacklists. --Vahag (talk) 18:16, 11 September 2019 (UTC)[reply]
Yeah that’s what I mean: They can be kept on Commons as for example usable to illustrate language learning, or erroneous pronunciation, as on Wikiversity, but the files have to be marked in one way or the other so the bot can distinguish. Fay Freak (talk) 18:26, 11 September 2019 (UTC)[reply]
Some imports (including the bicycle one) are from Lingua Libre via Commons. Lingua Libre collects all sorts of audio, including non-native pronunciation. The recording metadata has a reference to the speaker (example), which includes language levels, so a bot could only import recordings made by native speakers. – Jberkel 18:35, 11 September 2019 (UTC)[reply]
I think not, since the majority of users are likely to want to know the standard (Inner Circle) versions. At least we should ensure we have those before we try for anything more exotic. Equinox ◑ 18:21, 11 September 2019 (UTC)[reply]
I think we should stop trying to treat Commons names as meaning anything. Just because they aren't useful for us doesn't mean anything for Commons.--Prosfilaes (talk) 00:58, 12 September 2019 (UTC)[reply]

On the decline of Urban Dictionary

https://www.wired.com/story/urban-dictionary-20-years/

Not sure how much applies to this online crowd-sourced dictionary effort but it's worth thinking thru some of the problems with UD's methods and ensuring that we don't fall the same fate. —Justin (koavf)❤T☮C☺M☯ 20:42, 11 September 2019 (UTC)[reply]

"Where Oxford and Merriam-Webster erected walls around language, essentially controlling what words and expressions society deemed acceptable," really? I find very little value in this article and I don't think the author knows much about lexicography. I guess it points out (indirectly) that there is more to a dictionary than a 2D line between "descriptivism" and "prescriptivism": there are also "dictionaries" that simply invent vocabulary out of the ether ("inventionism"). DTLHS (talk) 20:53, 11 September 2019 (UTC)[reply]
Yeeaaahhhh (long drawn-out expression of dubiousness) ... The article author doesn't understand lexicography, and clearly doesn't distinguish between a list of memes, and a dictionary. UD is great if you want some idea of the current zeitgeist for a particular term, but it's useless as, well, a dictionary.
Ah, well. ‑‑ Eiríkr Útlendi │Tala við mig 21:11, 11 September 2019 (UTC)[reply]
I would guess the main reason for decline in sites with "user-generated content" is that now there are a lot more users and many of them are young children. A bit like what Eternal September did to Usenet. Equinox ◑ 21:19, 11 September 2019 (UTC)[reply]
It’s not like we couldn’t need a lot more users. Which decline? All runs fine until one tries to suppress information for politics, or for special rights. Fay Freak (talk) 21:56, 11 September 2019 (UTC)[reply]
"Which decline": well, politics aside, you don't think that Pewdiepie screaming and swearing his way through Minecraft, and the typical crop of YouTube comments, are a bit more inane than the quiet intelligent bloggers of the early 2000s? Equinox ◑ 22:04, 11 September 2019 (UTC)[reply]
No, I think that this is what is left after the legal trammels have grown ever heftier. Regulation everywhere, only some big players can calculate with it, and children who can’t care. If you are a blogger you will possibly drown in cease-and-desist letters because your privacy notice misses some trifle. It’s how at some time there were many producers of CPUs, now there are two – the laws have provided loopholes to eliminate competition, and the desire to become competitive. And in compliance with modern identity politics everyone is triggered by everything and tolerant towards addictions and degenerations thus tame, on top of coming out of schools more damaged than educated, which has always left majorities inane. Education always depended on incalculable details, and the cult of equality has stifled it. Everyone goes to school but learns nothing; everyone converses in cramped networks but may not tread on anyone’s toes; everyone may work but idlers stand at the door to have a share of it. That’s how you nurture the ugly. Fay Freak (talk) 23:41, 11 September 2019 (UTC)[reply]
Are you saying we need more users? I can't parse that. DTLHS (talk) 22:09, 11 September 2019 (UTC)[reply]
To answer a question that was not directed at me (pardon, Equinox): we need quality and quantity. A lot of one does not make the project that we want to make. —Justin (koavf)❤T☮C☺M☯ 22:35, 11 September 2019 (UTC)[reply]
So they complain about what? That Urban Dictionary depicts harsh reality and does not censor enough or that it has too much joke content and does not censor enough?
Nothing to applaud there. The internet should have dumps, and there should be lawless zones. Urban Dictionary still often has the definition you need that could not pass elsewhere. Fay Freak (talk) 21:56, 11 September 2019 (UTC)[reply]
I'm pleased about the fact that the author didn't think Wiktionary significant enough to be worth a mention in his article. --Mélange a trois (talk) 09:40, 13 September 2019 (UTC)[reply]

[[File:Screencapture-en-m-wiktionary-org-wiki-rock-2019-09-12.png|thumb|100px|Screencapture of the mobile Vector view of the term "rock" on Wiktionary.]]

Hi, I read the previous discussion at Wiktionary:Beer_parlour/2018/November#Titles_of_morphological_relations_templates more or less in its entirety. I suggest we do a thorough clean up of these templates and only keep the one(s) we all agreed on keeping and using.

To be more precise we currently have a whole host of templates in use in our main space:

  • {{col3}} and related ones
  • {{der-top}} and related ones
  • {{rel-top}} and related ones
  • {{Template:User:Donnanz/der3-u}} found here.

I would very much prefer to only have one template left when we are done if possible. All terms that should appear alike should be inserted using the same template with a few different parameters for e.g. title, number of columns, etc.

As an aside I got interested in this topic when browsing on my mobile with the default skin Vector on entries with a lot of derived terms (like rock) and where they were not collapsed by default (see picture ->). Terrible to scroll this and apparently no way to collapse. WDYT?--So9q (talk) 09:05, 12 September 2019 (UTC)[reply]

Is that really Vector? It looks like the mobile site, which uses Minerva. You can check with mw.config.get("skin") in JavaScript. (Special:Preferences only controls the skin used in the desktop site.) The mobile site just doesn't run many of the collapsibility scripts, only NavFrame. I wouldn't feel confident working on it myself because I never use it. — Eru·tuon 04:37, 13 September 2019 (UTC)[reply]
Oh, you are probably right. I would really like a menu on mobile for easily changing skin. Do you know how I could inject JS or HTML to do that?--So9q (talk) 06:19, 13 September 2019 (UTC)[reply]
You can change the skin by adding the query string ?useskin=whatever to the URL (for instance, https://en.m.wiktionary.org/wiki/aer?useskin=vector), but other skins aren't designed for mobile so the page just looks a lot like the desktop site. — Eru·tuon 08:37, 13 September 2019 (UTC)[reply]

Why do we mark race commonalities of English-language surnames?

Pretty much exactly that. It seems a bit strange, given the abstractness and variance of race.

Starbeam2 (talk) 01:36, 13 September 2019 (UTC)[reply]

I assume you are referring to things like "Aggarwal is most common among Asian/Pacific Islander (94.32%) individuals."? That information was added by a particular user and I have seen other users support removing it, but no action has been taken. DTLHS (talk) 01:37, 13 September 2019 (UTC)[reply]
Don't know about surnames but I have wondered about names like Shaniqua, which are not seen outside of black American communities. Well that one has a usage note. Given names are usually chosen by a parent, who belongs to such-and-such a culture. Surnames are a bit different... Equinox ◑ 02:13, 13 September 2019 (UTC)[reply]
Sure but surnames are also very culture-bound usually. —Justin (koavf)❤T☮C☺M☯ 02:22, 13 September 2019 (UTC)[reply]
So what can possibly be more "culture-bound" than given names that only black Americans use, like Shaniqua? I would wager money that no black Briton has that name. It's absolutely part of the culture. Equinox ◑ 02:27, 13 September 2019 (UTC)[reply]
No one is arguing otherwise. Certainly, the name Shaniqua is an African-American one. Not sure what your point is. Both "Moishe" and "Cantor" are Jewish names. Similarly, "Rodrigo" and "Hernandez" are both Hispanic. —Justin (koavf)❤T☮C☺M☯ 02:29, 13 September 2019 (UTC)[reply]
My point is that your immediate parents usually choose your given name, but your surname is usually left alone, and persists for a long time. Saying "Shaniqua is a black name" is an observation about how black Americans tend to name their kids; saying "Goldstein is a Jewish name" is quite another matter: maybe my great-great-grandfather was the last Jew in the family. Equinox ◑ 02:32, 13 September 2019 (UTC)[reply]
Because it tells you about how English language surnames are distributed, at least in the US. For all the problems with race, it's still a good proxy for ethnic groups in the US.--Prosfilaes (talk) 02:33, 13 September 2019 (UTC)[reply]
I think it's useful having this information. It provides at least vague information about where the name came from, and can be useful to fiction writers who might be trying to find a name that suits a particular demographic. Andrew Sheedy (talk) 02:55, 13 September 2019 (UTC)[reply]
I find it useful for researching the etymology. --Vahag (talk) 04:40, 13 September 2019 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Beer_parlour/2019/September&oldid=54111528"