Wiktionary:Grease pit/2021/March

Our language categories are no longer showing descendant trees. What's going on? —Mahāgaja · talk 08:42, 2 March 2021 (UTC)

They're back now. —Mahāgaja · talk 08:29, 6 March 2021 (UTC)

See Talk:A#Galizionario-Style_Breakdown_Needed. --Apisite (talk) 23:15, 3 March 2021 (UTC)

While editing ノンバイナリー, I received an error message, 'Lua error in Module:ja-ruby at line 590: Can not match " でした。

" and " でした。"'. This occurs even when I copy and paste ' でした。' into both the kanji and kana lines of ja-usex, so I don't think it is user error. Does anyone know what is going on? Cnilep (talk) 01:16, 5 March 2021 (UTC)

Perhaps I should specify: it was the second of the three instances of ja-usex on that page that caused the trouble. I put an html comment there to remind myself and others where the problem occurred, and what the example should say. Cnilep (talk) 01:19, 5 March 2021 (UTC)

On a lark, I tried adding an arbitrary character to the lines, and it worked. '·


でした' parses, but 'でした' does not. Obviously this is not ideal, but I've put the arbitrary character in there for the time being. Cnilep (talk) 00:49, 7 March 2021 (UTC)

@Cnilep: Invisible Unicode characters were the culprit. —Suzukaze-c (talk) 03:31, 7 March 2021 (UTC)

I don't understand how such characters could be in the string. I copied the kanji string, pasted a duplicate, and then converted it to kana. I copied and pasted just 'でした' several times, always getting the error message on preview. Is this some issue with my IME? Or was there something after the final '%' that I was unaware of? Cnilep (talk) 11:59, 7 March 2021 (UTC)

Something seems to broken; the page doesn't show the tool for adding new rhymes. --Akletos (talk) 13:21, 5 March 2021 (UTC)

I vaguely remember hearing that that tool had been disabled, though I don't remember by whom or why. —Mahāgaja · talk 08:29, 6 March 2021 (UTC)

Searching the Grease Pit archives for "rhyme", the most recent discussion I can find is August 2020 when Dixtosa improved it but it was apparently still working. Someone proposed switching to categories, but I didn't think that had happened yet. I don't see any recent edits to the tool, though. Maybe some Mediawiki change broke it. - -sche (discuss) 01:20, 9 March 2021 (UTC)

This is a pretty pathological case, but the adjective "forward" appears to have two comparative forms yet three superlative forms. Is there any way to specify this through "en-adj"? I have tried a few things but can't get it to work. Mihia (talk) 20:54, 5 March 2021 (UTC)

The template page (but not the documentation page that it transcludes!) for {{ne-conj}} has had this error for weeks now. Could someone please fix it?

Thanks! Chuck Entz (talk) 22:43, 7 March 2021 (UTC)

On both Wikipedia and Wiktionary, in both Firefox and Chrome, I notice that if I write "RFC 1", "RFC 2", etc, it automatically generates a link to https://tools.ietf.org/html/rfc1 etc. Is this something the Mediawiki software is doing? For me, it was unexpected and undesirable because I was writing in reference to a Wikipedia RfC. I can, of course, override it by explicitly supplying my own link or writing RfC 1 with a lowercase f, so I suppose it's not a big deal. - -sche (discuss) 01:09, 9 March 2021 (UTC)

@-sche: These are deprecated magic links (they also occur for ISBNs and PMIDs). You can prevent them occurring by using nowiki (e.g. RFC 1 turns into RFC 1, where as <nowiki>RFC 1</nowiki> or RFC<nowiki/> 1 turns into RFC 1). GreenComputer (talk) 15:53, 9 March 2021 (UTC)

@-sche: Fix ping. GreenComputer (talk) 15:54, 9 March 2021 (UTC)

I just noticed that the inflection table at συλλαβή has no article in the dual dative and accusative, where instead of ταῖν συλλαβαῖν & τὼ συλλαβά you have just συλλαβαῖν & συλλαβά. The table is wholly produced by a template, so it is the template that includes the mistake. What do we do? MGorrone (talk) 14:39, 9 March 2021 (UTC)

@Erutuon, JohnC5 Can this be fixed at Module:grc-decl, please? —Mahāgaja · talk 14:48, 9 March 2021 (UTC)

@Mahagaja, Erutuon, MGorrone: I believe I have fixed the issue with this change. Apparently you can't use ipairs in that way. —*i̯óh₁n̥C 01:00, 10 March 2021 (UTC)

At لوق the "lok" in "Rumi spelling lok" appears in a much larger font. The head is generated by {{head|ms|adjective|Rumi spelling|lok|sc=Arab}}. Removing sc=Arab still leaves a large "lok". How should this be fixed? Vox Sciurorum (talk) 15:30, 10 March 2021 (UTC)

• Fixed by ‪Fenakhay‬. Vox Sciurorum (talk) 16:04, 10 March 2021 (UTC)

I just noticed μένω has the same uncontracted future twice, once as "Epic, Ionic" and once as "Uncontracted", and has the contracted one marked "Contracted". I tried correcting the latter with a titleapp=, but it was ignored. Should the "Uncontracted" table be removed? And how to we mark the Contracted one as such? MGorrone (talk) 18:29, 10 March 2021 (UTC)

I've removed the "Epic, Ionic" table as it was identical to the uncontracted table that followed (no distinct endings for Epic/Ionic as compared to Attic in this case). The fact that the contracted future table is labeled "Uncontracted" is a known problem (see Module talk:grc-conj#Contracted forms labeled uncontracted) and is more widespread than this entry. —Mahāgaja · talk 18:33, 10 March 2021 (UTC)

Eventually, if I ever revamp Module:grc-conj, I would like to get rid of the convention of having uncontracted and contracted tables, and just show the forms that are actually attested or plausible in each dialect or group of dialects. The uncontracted forms of some verbs aren't actually attested and it's misleading to have them shown in a table and linked. (In some cases people have even created entries for these forms by mistake.) In the case of μένω (ménō), if I remember right, Attic doesn't have any uncontracted future forms, so the uncontracted future table will just be gone, and we'll need a new table for Epic and Ionic. So I restored the template but put it in a HTML comment to remind us that we will need that table in the future. — Eru·tuon 20:24, 10 March 2021 (UTC)

Greetings and salutations, noob here. I would have Latin, Sardinian and Venetian links convert diacritics into plain letters, as per this discussion. What module handles this, and is there anything else I should change? Brutal Russian (talk) 19:46, 10 March 2021 (UTC)

Latin already strips diacritics, or are there more diacritics you'd like to strip? Sardinian is handled at Module:languages/data2 and Venetian at Module:languages/data3/v. —Mahāgaja · talk 20:32, 10 March 2021 (UTC)

Thank yuo. It doesn't strip acutes, graves and circumflexes of the New Latin orthography deûm, ponè. That deûm tho - shouldn't that page be deleted? Brutal Russian (talk) 20:55, 10 March 2021 (UTC)

‌ Category:Latin terms by their individual characters has a bunch of suspicious words. Vox Sciurorum (talk) 00:16, 11 March 2021 (UTC)

Compare {{tea room}} and {{tea room sense}}. J3133 (talk) 08:16, 11 March 2021 (UTC)

When saving a page there is a choice of how long to watch it for, it defaults to "Permanent" — is there a way of setting the default to less time, say "1 month". If there is I haven't found it. — Saltmarsh. 09:58, 11 March 2021 (UTC)

Yes, though I never tried it. You can click on Permanent and then a list of time periods will show up. ॥ ☼ সূর্যমান ☽ ॥ 11:19, 11 March 2021 (UTC)

Thanks, yes - but I would like it to be set permanently to a shorter period - ie to always save the watch list for say a month, so that older edits/creations drop off after that. I was thinking that I might have missed something - if it ain't an option it doesn't matter! — Saltmarsh. 12:45, 11 March 2021 (UTC)

I prefer the permanent setting - but I use it only for entries I have created - it gives me a tally for those that way. DonnanZ (talk) 14:34, 14 March 2021 (UTC)

Is there any way I can create my own templates in a sandbox or something? Not in the main Template: namespace. ॥ ☼ সূর্যমান ☽ ॥ 11:23, 11 March 2021 (UTC)

Never mind, I figured it out. ॥ ☼ সূর্যমান ☽ ॥ 11:59, 11 March 2021 (UTC)

{{az-conj}} has now a bunch of verb forms which have variants (dated and colloquial) which are generated correctly in the table but not yet by accel. To take an example, almaq: all 2pl-form have two variants, with and without optional -nı-, which is expressed as alırsı(nı)z in the template. The omission of -ni- is commonplace in speech, but considered too informal for writing (although it does occur), which is why the greenlink should produce this: alırsınız, i.e. the full form with a link to the reduced form in {{alter}}. If it could at the same time automatically create the alternative form alırsız, it would be just lovely. Allahverdi Verdizade (talk) 22:36, 13 March 2021 (UTC)

@AryamanA

I noticed a discrepancy at the Lepcha transliteration module. --Apisite (talk) 06:40, 14 March 2021 (UTC)

I'm a fairly new user, and trying to add a conjugation table to a Sicilian word (prisirvari) and getting extraordinarily lost. Am I supposed to be able to add stuff into templates per page, and if so, how do I do it? Alternately, if I go about making a template for Sicilian (which I'd... rather not be the one to do) how does that work? I have all the info, I'm good at the /language/ parts, the technical parts... are killing me a little. Elliott Dunstan (talk)

@Elliott Dunstan: our Sicilian verb-inflection table templates are here. I assume that {{scn-conj-ari}} is the one you want for prisirvari. You can follow the template documentation for instructions on how to use it, or take a look at the verbs that already use it listed at Special:WhatLinksHere/Template:scn-conj-ari. —Mahāgaja · talk 21:36, 15 March 2021 (UTC)

Template:re: Oh, thank you! I think I got it working. I don't know why I didn't see those when I looked, but I think the template thing overwhelmed me a lot. Much appreciated. Elliott Dunstan (talk) 15:38, 16 March 2021 (UTC)

This comes down to usability, and folding away certain longer content.

Working in Japanese entries, I've recently encountered a user who wraps etymology details in a collapsible template, currently {{rel-top}} and {{rel-bottom}}, out of apparent concern that the etym section is too long and visually distracting.

I can see their point of view: long etymologies could be seen as a negative for usability, for users who are not interested in this content.

However, the {{rel-top}} template enforces two columns by default, which seems inappropriate and ugly for the kinds of explanatory text blocks that are common in etymologies.

I spent some time poking around to see if there were a different template that would allow for a similar collapsible element, but without the columns. This led me to a few questions.

• {{collapse-top}}:

There is the generically named pair of {{collapse-top}} and {{collapse-bottom}}. For reasons that I don't know, {{collapse-top}} was designed to specifically mimic the {{trans-top}} template -- it has the same yellow background, two columns by default, and it has the same "Add translation" text boxes.

This template's What Links Here shows that it isn't transcluded much, and in at least a few cases (such as in the Wiktionary:Tea_room/2020/December#(geen)_volle_zalen_trekken_/_nee,_jij_trekt_volle_zalen thread), it has been used as a generic collapsible element, where the yellow background, columns, and "Add translation" portions are probably not wanted.

Can {{collapse-top}} be safely repurposed to a more generalized use case, removing the translation-related formatting and inputs? Would doing so break anything?

Ideally, {{collapse-top}} would produce the same general effect as {{rel-top}}, only with different default text, and only one column.

• {{rel-top}}:

Alternatively, this template could be tweaked to allow a second argument to specify the number of columns. Presumably, 2 would still be the default, to minimize disruption.

It appears that {{rel-top}} in turn uses {{column-count}} to plop out the CSS needed for the columns. {{column-count}} is already parameterized, so it's just a matter of passing in the desired number.

Can {{rel-top}} be safely updated to specify the number of columns? Would doing so break anything?

• JavaScript:

The above template-based approaches would require editors to manually add the -top and -bottom templates to get the content to collapse. This approach is thus inherently scattershot, and a lot of work to maintain.

Would it be possible to use a JavaScript-based approach to collapse ===Etymology=== sections (and any others), as we already do for quotations?

This would presumably apply to all ===Etymology=== sections automatically, and a user's preferences could be configured to always expand or always collapse these sections.

If so desired, this might even be code-able to only collapse ===Etymology=== (or other) sections longer than X number of lines, perhaps.

Curious as to the community's thoughts. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:30, 16 March 2021 (UTC)

@Eirikr: We have {{collapse}}. J3133 (talk) 18:36, 16 March 2021 (UTC)

@J3133: Yes, we do. But the bright green is, IMO, ugly, and it's jarringly different from the rest of our entry infrastructure. Somewhere along the line, I'd also gotten the impression that we are encouraged to use the -top and -bottom templates instead. ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:51, 16 March 2021 (UTC)

Following in the path of the online OED, we might have a (non-visually jarring, perhaps grey) autocollapsed box, where the title of the box will automatically show the first ~ line of its contents, followed by an ellipsis. Of course, changing EL to have the etymology below the definition might really be the way to go. —Μετάknowledge^{discuss/deeds} 00:31, 17 March 2021 (UTC)

@Μετάknowledge, I'm curious, how would it work to put the etym below the defs, when we're organizing the entries based on the etyms? I have trouble visualizing what that might look like for any multi-etym entry. ‑‑ Eiríkr Útlendi │^{Tala við mig} 00:56, 17 March 2021 (UTC)

We recently had a discussion about this. Form 1, Form 2, etc would replace the numbered etymology sections, and the new (unnumbered) etymology sections would be nested one level lower, below their respective form. —Μετάknowledge^{discuss/deeds} 01:00, 17 March 2021 (UTC)

Interesting. The general structure is fine by me, but using headers of ===Form 1===, ===Form 2=== seems to confusingly suggest that the terms have different spellings / graphemes, which is a concern. ‑‑ Eiríkr Útlendi │^{Tala við mig} 03:44, 17 March 2021 (UTC)

As long as it's clear which etymology belongs to which section, there's no reason to have the actual etymology at the top of an etymology section. We might even have a different type of header for the "Etymology" organizational structure and the etymological content.

Another possibility would be to have the beginning and the end of any given section visually tied together, so you can see the section as a whole- like what we do with the language sections, but repeating the pattern fractally with narrower and narrower subsections. The idea is to have a given class of content live in a specific place in each level of organization- perhaps with the more concrete and simple things first, and the more abstract/theoretical and/or verbose stuff at the bottom. Another way to look at it is treating things like the etymologies and inflection tables as footnotes to the definitions and pronunciation information. That puts the concise and practical information at the top, and the supporting details at the bottom- sort of like the inverted pyramid principle in news writing. We might even think about making the headword line the actual head of the whole section. I'm just sort of brainstorming at the moment- it will require a lot more thought to figure out how it would work in practice. Chuck Entz (talk) 04:53, 17 March 2021 (UTC)

Hmm, hmm, yes, interesting. I like the idea of visually tying things together better than we currently do.

I'm still struggling a bit to imagine the layout. We have various oddities in different languages to contend with, things like English object (verb) and object (noun), or the multiple different pronunciations of Japanese 柄 (e, kabi, gai, kara, gara, tsuka, tsuku, hozo). Whatever we arrive at will have to accommodate all of this somehow. I'm looking forward to what we can come up with. ‑‑ Eiríkr Útlendi │^{Tala við mig} 07:59, 17 March 2021 (UTC)

• I am in favour of collapsible etymology sections where they are excessively long, having come across some lengthy Latvian ones for example. I have experimented with {{collapse}}, but can't get it to collapse properly. When using it, it collides with any Wikipedia links and added images opposite the etymology and a yawning gap is created, which is far from desirable. DonnanZ (talk) 12:12, 24 March 2021 (UTC)

I recall this coming up somewhere else just recently. My concern with collapsing the content is that it is then very easy for someone to not realize it's there; even a veteran editor and admin missed the collapsed table in cat last October. (Nonetheless, I do collapse very long content, including IIRC in that very entry, but also e.g. Iroquois.) Having the top line(s) of the content be displayed (in the same legible, non-greyed-out font as at present) and then fade out or terminate in an ellipsis mid-sentence might help with that. - -sche (discuss) 05:32, 27 March 2021 (UTC)

Hello how's things. I do have a suggestion (that does take some work of writers). Our translation collapsing boxes do allow the heading section to state the sense of the word that is being translated. This is helpful when two or more senses have their own separate lists of translations.

Entries with multiple etymologies could use the same kind of box. And the consistency with the collapsed boxes for derived terms and translations make things neat. 119.56.103.124 16:47, 31 March 2021 (UTC)

• Shotgun thoughts: —Cool idea, been trying to do this too since the last discussion which I can't find—Related: cognates in the =ETY= section—Collapsibles easily missed - ellipsis definitely the way to go—In that shape moving it down wouldn't be as pressing; my own reason for doing so is that =ETY= is thematically related to =Derived terms= etc. So it would make sense to have these grouped up into a "meta section" below the definition. This would separate it from the thematically related =Alternative forms=, which I can live with as long as they're near =Pronunciation=.—On the subject of visually tying together, I stumbled upon {{senseid}} again today and was pleasantly confused thinking that the definition section had finally acquired some visual cues, especially useful to visually group quotations and synonyms together with a definition. Alas! But something simple like this would go a long way towards improving the look and feel of the website.—Grouping definitions by Form without necessarily specifying POS could resolve the POS heading issue: click #1, click #2, click #3 Brutal Russian (talk) 04:24, 3 April 2021 (UTC)

Some of the links displayed using this template are malformed; in parts where commmas and/or dashes are used to indicate different forms the links that the template creates link to bad page names such as one with the comma and everything in the page title, instead of having 2 separate links when there are 2 forms listed for one inflection of the noun. User: The Ice Mage ^{talk to meh} 15:27, 17 March 2021 (UTC)

I think the time has come to enable transliteration of Pali from non-Roman scripts. Module:pi-translit has been tested, and seems to me to be working. However, it would be nice to check its interaction with Pali templates before it is accepted. How do I test it out? In a world without protections, I would make an uncommitted edit to Module:languages/data2 to add field translit_module = "pi-translit" to m and view content pages using the editor's preview facility. However, the module seems to be protected against my doing that sort of thing. Do I need to simultaneously sandbox a lot of infrastructure?

The Thai and Lao scripts each have different writing systems for Pali depending on whether or not one writes the short vowel 'a'. Sometimes one cannot tell which system an isolated word is in, and the word has different transliterations for the two systems. Is there any mechanism for passing the identification of the writing system to the transliterator? For example, สุตวา (sutavā) is sutavā (“learned (nom. s.)”) if 'a' is unwritten, but sutvā (“having learnt”) in the system where it is written. (This is a productive confounding of abugidic past active participles and alphabetic absolutives; the former are rare.) RichardW57m (talk) 14:43, 18 March 2021 (UTC)

We passed 6,500,000 entries some time ago. Would anyone like to find out what it was and then update Wiktionary:Milestones? SemperBlotto (talk) 16:45, 20 March 2021 (UTC)

I figured we weren't counting half millions any more for some reason. Given deletions, I'm not sure there's a feasible way to find a meaningful answer to this now. —Μετάknowledge^{discuss/deeds} 20:54, 20 March 2021 (UTC)

I think it should be possible to reconstruct this with the history log (replaying all insertions and deletions). Maybe it can be even done with some clever SQL. – Jberkel 21:47, 20 March 2021 (UTC)

Please create a list of pronunciation of most used words (Wiktionary:Frequency lists) with IPA and audio file. The table should have both IPA and the audio file to assist non native speakers in learning word pronunciations. Thank you -Vis M (talk) 22:52, 20 March 2021 (UTC) Example list:User:Vis_M/Pronunciation_list Vis M (talk) 16:36, 30 March 2021 (UTC)

Hey- how can I get the "Recent additions to the category" box (like we can see on this page: ) onto this page: Han phono-semantic compounds? I want to use it to monitor this category and see what changes are made. Thanks for any help. Please ping me if you have an answer. --Geographyinitiative (talk) 15:11, 24 March 2021 (UTC)

@Geographyinitiative: By adding a DynamicPageList (e.g., see Category:Translingual proper nouns). J3133 (talk) 15:16, 24 March 2021 (UTC)

On MediaWiki:Common.css#L-2464 says that CategoryTree generates a new line but I think this is not correct, the new line is generated due to the template {{suffixsee}} having an extra line right before the noinclude tag. I realized this while implementing the same temp on ku.wikt. The other affix-see templates doesn't have that line.--Balyozxane (talk) 11:54, 26 March 2021 (UTC)

Just bringing this to attention. Don't how long it's been like that. -45.58.196.55 19:06, 26 March 2021 (UTC)

• Odd, I don't see any Lua memory warnings when I view the page. ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:12, 26 March 2021 (UTC)
  • Sorry, I have no idea what just happened but right after I verified the link in the heading the error fixed itself...? (This is what it looked like.) (And wiki didn't let an IP address editor use the Undo function.) -45.58.196.55 19:14, 26 March 2021 (UTC)
    • Right now, the page is using 52,312,651 out of the 52,428,800-byte maximum allowed. That translates to 0.11 MB below the 50 MB limit. All it takes is a minor tweak to one of the dozens of modules transcluded by the entry to take it over then line one way or the other. For that matter, it might just be a tiny random change in the way a server is processing the code. Think good thoughts- it might make a difference... Chuck Entz (talk) 23:30, 26 March 2021 (UTC)
• See Wiktionary:Lua memory errors. J3133 (talk) 19:16, 26 March 2021 (UTC)

Hello!

Is it possible to see edits with the no head temp tag that haven't been edited since? I namely looked into the logs for that tag but so many versions have been overwritten and hence does not need to be fixed. If there was a way to exclude the already fixed entries that would be appreciated. Thanks! Jonteemil (talk) 00:15, 27 March 2021 (UTC)

Not in the logs themselves. Someone would have to combine the log data with data from the edit histories. You could sort of infer how likely it is to have been overwritten by how old the most recent tag for an entry is: if there are edits since the tagged one that aren't in the log, it's been fixed. Not foolproof, since you can't predict when or if an entry is going to be edited- but it's better than nothing. Chuck Entz (talk) 01:45, 27 March 2021 (UTC)

You could conceivably generate a list yourself of entries without head templates, from the database dump. - -sche (discuss) 05:23, 27 March 2021 (UTC)

Is there any way to survey entries to see if they're approaching the 50 MB memory limit? It would be nice to not have to wait until they end up in CAT:E to reduce memory usage.

If there's no way to directly access memory usage from a bot, perhaps there's some way for a bot to do the equivalent of "View Page Source" on a browser, since there's parser profiling data embedded as comments in the html listings.

We could narrow it down a bit, since almost all the out-of-memory-errors I've seen so far have been single-character entries in Category:Translingual lemmas or entries in Category:English lemmas with translation tables. The few exceptions have had literally dozens of L2s. I'm sure we could narrow it down further by using frequency/basic words lists. Chuck Entz (talk) 04:36, 27 March 2021 (UTC)

Recently I found most entry titles have changed to a serif font, while Chinese titles have remained sans-serif. Screenshot: . Does anyone else experience this? -- Huhu9001 (talk) 00:53, 28 March 2021 (UTC)

Copied from Template talk:audio.

The look of player's menu is absolutely awful, the commonly used contrast "grey or dark grey on black" is very hardly readable and there is no any alternative for people with some visual problems or disabilities. Has someone of developers tried to use the "Settings", where the elements of list are shown in dark grey on black and don't have any tooltips? Settings UI is not resizable, no link to external help for users, no info whether the settings are saved for current session only or for subsequent use etc...

And nobody is interesting in fixing the "echo effect" at start of second and next playing of the same file, the bug which has been noticed more than 10 years ago and still happens on the last Google Chrome. --2A00:1370:8115:53ED:786E:9AE4:4090:1993 08:17, 28 March 2021 (UTC)

I stumbled upon a few crappily-formatted quotes like in this edit, which gave the wrong year. I'm assuming we could find some more like that which have , or , and make a list of them, and see how many of them are the result of Wonderfolly. Yellow is the colour (talk) 19:35, 28 March 2021 (UTC)

@Yellow is the colour: and —both are quite relaxed, so they catch as many incorrect dates as possible, at the cost of finding many false positives. —Tacsipacsi (talk) 20:10, 1 April 2021 (UTC)

We have reader complains that mobile pages are always expanded which make the pages hard to see. This becomes a serious problem on LongPages with a hundred entries. Especially that TOC does not appear in mobile view.

I have verified with mobile view that this is the case on WT. Section headings always appear expanded.

I also went to the other WikiMedia projects and their section headers are minimized (collapsed).

Anyone knows why the difference in behavior and how to fix it? Need to call in help from meta:?119.56.97.84 05:55, 30 March 2021 (UTC)

I will go look for a meta developer to see if I can get some opinions. 119.56.103.124 16:58, 31 March 2021 (UTC)

This is a global setting active on all Wiktionaries (but not on other Wikimedia projects). It was discussed in phab:T63447, and while I’m also embarrassed by this setting when I read Wiktionary on mobile (as I do a lot), I also understand the reasoning there. —Tacsipacsi (talk) 19:46, 1 April 2021 (UTC)

A recent Beer Parlour discussion talked about duplicated definitions for every POS header. This gets worse when multiple senses/etymologies, and even worser when there are declensions.

This discussion is about if better headers can be used to lessen such duplicated senses, and what form it can take. 119.56.103.124 16:58, 31 March 2021 (UTC)