Wiktionary:Grease pit/2024/November

in many terms that I have edited for anti-LGBTQ terms, I am in need of a better category to describe their usage than simply "derogatory", such as that these are used by broadly right-wing and alt-right groups to discredit LGBTQ people. currently many of these are tagged with the labels right-wing (no link or category) and alt-right, but following Wiktionary's category policy, they shouldn't as they are not related to right-wing ideas themselves but are used by their followers.

in this discussion, I am asking for advice on how to categorise these. talking on Discord and with GLAAD, I have proposed and been proposed these terms, with my opinions on them:

• conservatism: possibly too broad, and it was likely created for philosophical and economical terms.
• alt-right: too narrow for all terms.
• US conservatism: too narrow, the UK has coined many horrible terms, especially related to transphobia, these past few years.
• reactionary populism: possible. even though that would include a lot more terms, populists that are only homophobic but not transphobic are rare due the "philosophy" of the movement itself.
• anti-LGBTQ: possible, most direct! homophobia and transphobia should be aliases.

I prefer the latter two plus alt-right (for certain terms), but would like to see other's ideas. Juwan (talk) 15:42, 2 November 2024 (UTC)

Re "right-wing": on the contrary, it's correct to use a {{label}} to label terms that are used by some set of people (such as the right wing), just like our "US" label and "American" category is for terms used by Americans (whether they relate to the topic of America or not). Using a label to indicate that the term merely relates to a topic (but is used by everyone) is generally substandard, because that should be indicated in the definition and categorized using topic categories, though it is a persistent practice. It might be useful to double-categorize terms also into a user-agnostic catch-all category for all anti-LGBTQ terms (or perhaps it wouldn't? we got rid of the "Racist names for countries" category, moving it to a type-of-discrimination-agnostic "Derogatory names for countries" category, to which the parallel would be not "Anti-LGBTQ terms" but "Derogatory terms for people"), but we should keep labelling (and categorizing) who uses the terms as well. - -sche (discuss) 17:33, 2 November 2024 (UTC)

@-sche re re "right-wing": your knowledge is good to have yet this label still has the problem of being a bit vague in scope. how should we categorise the people that use these terms? re end. if we implement the category "derogatory terms for people", it makes sense to me to specify the type of discrimination. as people (or groups of people) are most commonly the target of discrimination, there is a way bigger number of terms that could be subcategorised. Juwan (talk) 19:38, 2 November 2024 (UTC)

@JnpoJuwan I am inclined to agree with you that right-wing is a bit vague, and on top of that I'm sure there exist right-wingers who aren't homophobic (the Cheneys?). I like the idea of a poscat category Category:English homophobic slurs or Category:English anti-LGBTQ slurs (or similar) to hold these terms. IMO it should be a poscat category, not a topic category; compare Category:English ethnic slurs and Category:English military slang. As for the "who uses the terms", if the answer is "anyone who's homophobic/transphobic/etc.", then IMO the term doesn't need such a characterization, although it should have some indication on the definition line itself that it's a slur (compare the n-word, used by racists of all stripes and given several such labels). I think the most useful cases where it makes sense to characterize a term by its users is when it's specific to a community such as the alt-right or 4chan. Benwing2 (talk) 20:43, 2 November 2024 (UTC)

I am fine with categorizing anti-LGBTQ slurs; to clarify, my parenthetical "or perhaps it wouldn't?" was only meant to express my uncertainty over whether others would agree that it was a good idea, because I noticed we seemed to be moving away from collecting terms based on type of discrimination when it came to "Racist names for..." categories (which were broadened to generic "Derogatory names for..."). You are right to point out we still have an "ethnic slurs" cat. (But "military slang" is categorizing who uses it again, isn't it, not who it's used towards?) I agree with your last point as well, that if "who uses it?" is "basically everyone who's trying to be derogatory to X" it doesn't need categorizing, but many terms are characteristically associated with specific subgroups of people (even if those subgroups are as broad as "US" or "right-wing"). - -sche (discuss) 20:58, 2 November 2024 (UTC)

@Benwing2 I support this. in short, for anti-LGBTQ (or any anti-X) terms:

• these are categorised under a dedicated poscat
• extreme or group-specific words are categorised in the group's related-to cat

Juwan (talk) 21:02, 2 November 2024 (UTC)

@JnpoJuwan OK sounds good. What should the category name be? Should we have a single Category:English anti-LGBTQ slurs or separate Category:English homophobic slurs and Category:English transphobic slurs? Benwing2 (talk) 21:06, 2 November 2024 (UTC)

@Benwing2 please create the wider LGBTQ one for now. if needed, I can split them into two or more later. Juwan (talk) 23:21, 2 November 2024 (UTC)

I think "anti-LGBTQ" is the best name for this. I don't like using the terms "homophobic" or "transphobic" in a Wiki context, because I think it's less neutral. Many people who could be labelled as homophobic would not self-identify as such, but would be comfortable calling themselves anti-LGBTQ. In addition, words like "homophobic" or "Islamophobic" seem less like descriptors of the words than of the motivation for using them. But maybe that's splitting hairs. Andrew Sheedy (talk) 18:58, 4 November 2024 (UTC)

Upon further thought, although I still prefer "anti-LGBTQ", I think I may be splitting hairs when talking about using the label "homophobic." Those who do not accept gay marriage for religious or other reasons but still avoid disrespecting or discriminating against gay people are typically not going around using slurs, so the distinction I was trying to make doesn't necessarily apply to the case at hand. Andrew Sheedy (talk) 19:16, 4 November 2024 (UTC)

currently, text marked in a language that doesn’t use the latin script has special css for it. this is good for languages, where font support is scarce, faulty or just unreliable, however some major orthographies (cyrillic, greek etc) also have these styles, which are, on most viewports, very ugly. the default font for cyrillic is arial/helvetica, which are good fonts by themselves, but they’re too overused. in the case of cyrillic, modern built-in fonts (noto sans, roboto, sf pro, freesans, even unifont!) already have good cyrillic support, not even counting arial or helvetica. the same can be said about modern (but not ancient) greek, however unlike cyrillic, greek is not a script i use on a daily basis.

this seems to be caused by the -webkit-locale property, and i am sure there is a way to not use it without breaking the whole wiktionary. this changes the font in chrome, but not in firefox.

however, this is what happens if you disable the default styles gadget. if it is enabled (as it is for most users), the font rules are in load.php. and that thing is working as it should (even though it still is ugly).

see also:

• message in the discord server by JnpoJuwan

БудетЛучше (talk) 17:10, 2 November 2024 (UTC)

I'm not quite sure what your request is. Benwing2 (talk) 20:49, 2 November 2024 (UTC)

my request is to make the “disable default styles” work properly in chrome. (because currently it disregards wiktionary styles in favor of chromium styles. the ideal behavior would be to use neither.) БудетЛучше (talk) 10:36, 3 November 2024 (UTC)

A fix (but a bad one):

* {
  -webkit-locale: "";
}

БудетЛучше (talk) 11:17, 10 November 2024 (UTC)

I created a new sandbox module at Module:User:Tc14Hd/utilities/templates. However, as you can see by the formatting of the page, it is not recognized as a module but rather as regular wikitext. Maybe this has something to do with the fact that I first created it in the wrong namespace and only later moved it to the Module: namespace. Is there a way to fix this? Tc14Hd (aka Marc) (talk) 19:33, 2 November 2024 (UTC)

It looks like you were right. I created a test copy with your code, which looked okay, so I copied it over your original and undeleted the earlier revisions. The last 2 steps required admin rights, though you could have created the copy yourself under a slightly different name and made those steps unnecessary. Chuck Entz (talk) 19:56, 2 November 2024 (UTC)

Yes, I have encountered this issue before: a page created outside of the Module: namespace will not become a Module if moved, it has to be created in Module:-space. (I am tempted now to check what happens if a page is created in Module:-space and then moved out.) - -sche (discuss) 20:45, 2 November 2024 (UTC)

Thank you! I already assumed that the only way of fixing it would be deleting the page and creating it again. Tc14Hd (aka Marc) (talk) 21:38, 2 November 2024 (UTC)

@Chuck Entz @-sche For future reference, if you click on "Page information" in the sidebar, you'll see a "change" button next to the page content model in the table, which is for situations like this. You can only convert pages into (proper) modules in the Module namespace, though. I have a feeling only admins can do this, too. Theknightwho (talk) 14:42, 3 November 2024 (UTC)

How can I prevent a template from crossing over into another language (level 2 headings)? For example, the Template:number box, when used on this page तीन in the section तीन#Marathi crosses over into the next language. This looks weird (see screenshot). I would ideally like to contain it within the language it was meant for.

Siddhant (talk) 01:47, 3 November 2024 (UTC)

You can use {{-}}. It could be inserted directly into the template, but that is likely to cause issues that you don't want. Instead, you could put it into the entry's page at whatever points you find it necessary. —Justin (koavf)❤T☮C☺M☯ 01:58, 3 November 2024 (UTC)

Thanks! That worked exactly how I intended. But I would really like this to be fixed everywhere. I can see 4 levels on how this should be fixed:

1. one-time usage on this page - Done
2. fix this specific template
3. fix all such language specific templates
4. fix how L2 headings are styled in general - we should have a {{-}} called before every L2 heading.

I'm not an experienced template/CSS-style editor, but I'm happy to learn if someone can guide me. Siddhant (talk) 06:00, 3 November 2024 (UTC)

I was looking for a show-hide template and found this one, created 14 years ago. I have used it at Corinth for a long list of places, although it works OK, it won't work if I place # in front of it, to give the number 3 in the list. It's all a question of appearance, the template may not have been created for this purpose. DonnanZ (talk) 10:26, 3 November 2024 (UTC)

@Donnanz I'm sympathetic to the idea of hiding long lists of places in definitions, but I'm going to remove the box for now due to the formatting issues, as it looks really bizarre on my laptop. We can reinstate it once we've worked out the best way to do it. Theknightwho (talk) 10:33, 3 November 2024 (UTC)

It starts with a div, so it can't be in the middle of a list. I agree that it should probably be removed. —Justin (koavf)❤T☮C☺M☯ 10:35, 3 November 2024 (UTC)

OK, I wasn't completely happy with it, I hope a satisfactory solution can be found. There's other place entries with the same problem. DonnanZ (talk) 10:58, 3 November 2024 (UTC)

To be clear, you're stating that the problem is that the entries are too long? I disagree: an entry that has "a place in the United States" with a list of 20 or so localities is not really that unreadable. —Justin (koavf)❤T☮C☺M☯ 10:46, 4 November 2024 (UTC)

Yes, I am. I agree that 20 or so isn't too bad, but Corinth has 49, so, unless you use the TOC, you have to wade through them all to get to Derived terms etc. Other examples are Washington (36), Lincoln (30 + 12 in Wisconsin), Franklin (39), Washington County (31). There are possibly others that escape me at the moment, but Corinth may be the most popular place name in the US for some reason. DonnanZ (talk) 12:12, 4 November 2024 (UTC)

I will grant you that 49 is substantially more than 20-some (in fact, it's double that), but I still don't think it's an actual issue, since this isn't a print dictionary and scrolling with the space bar is pretty trivial. —Justin (koavf)❤T☮C☺M☯ 15:21, 4 November 2024 (UTC)

Hmm, I doubt that every user would be impressed by that attitude. DonnanZ (talk) 23:55, 4 November 2024 (UTC)

I also doubt that every single user would feel the same way about virtually any issue. If you have some proposal that "if >x entries, then use a collapsible box", I'm all ears. If not, it's just matters of personal preference and "I think this is too much for me" stuff, which is not particularly helpful across the dictionary. —Justin (koavf)❤T☮C☺M☯ 00:02, 5 November 2024 (UTC)

If we can show and hide quotations, where #* and sometimes ##* is placed in front of each quote, it shouldn't be too difficult for a template writer to work something out for a long list of places. #* can't be used, that's only good for quotes. DonnanZ (talk) 14:50, 5 November 2024 (UTC)

Agreed that on a technical level, it should be possible, but there's a difference between the definitional entries, which are the basic core of a dictionary versus illustrative quotations or other secondary material. —Justin (koavf)❤T☮C☺M☯ 20:22, 5 November 2024 (UTC)

We can also show and hide translations. DonnanZ (talk) 15:13, 6 November 2024 (UTC)

"Or other secondary material", yes. It's not the primary function of a dictionary to give translations into other languages, but it is the primary function to define words. —Justin (koavf)❤T☮C☺M☯ 02:52, 8 November 2024 (UTC)

It could be argued that it's not a primary function to list quotes either, but we do and I have added loads over the years. Similarly with an excess of places with the same name, which probably won't interest every user. I have employed a few hide/show lists on my user page, including a US counties index. Do you remember deleting that? Feel free to browse it. DonnanZ (talk) 11:44, 8 November 2024 (UTC)

I do. I don't see how it's germane here. —Justin (koavf)❤T☮C☺M☯ 11:47, 8 November 2024 (UTC)

It is germane, as you put it, as my index employs hide/show. DonnanZ (talk) 12:09, 8 November 2024 (UTC)

If it was included in mainspace, I could remove it from my user page @Benwing2. DonnanZ (talk) 19:08, 8 November 2024 (UTC)

If others think that definitional entries should be hidden by default or in collapsible boxes, then I will support that as a consensus. I find it unlikely that others will think that is a good idea. —Justin (koavf)❤T☮C☺M☯ 12:10, 8 November 2024 (UTC)

I would like to hear from other editors, especially template editors. DonnanZ (talk) 13:59, 8 November 2024 (UTC)

it's saying my thing might be harmful, it's an abbreviation known as TND i've seen alot on fringe alt-right communities and it's seen to be known as Total n-word Death here is an example https://soyjak.party/soy/thread/9005613.html#9005651 ... there are more and i have seen definitions for other words on here which is slightly more rare such as thoughbeit and they originate from that community Ptlrsyltursytuyrsl (talk) 19:51, 3 November 2024 (UTC)

@Ptlrsyltursytuyrsl: please only add the definition if it complies with WT:DEROGATORY. Thanks. — Sgconlaw (talk) 19:08, 4 November 2024 (UTC)

MediaWiki message delivery 20:50, 4 November 2024 (UTC)

Why do so many pages link to {{ko-l}}? I was checking out "xx-l" templates and I saw that this one is linked to by countless pages with no mention of Korean. E.g. yttrandefrihet and grudzień. Ultimateria (talk) 01:17, 5 November 2024 (UTC)

@Ultimateria I think this may be a remnant of when we were seeing lots of additional false "transclusions" for technical reasons that have now been rectified, but they still haven't all filtered through yet. After doing a null edit on both those pages, neither shows {{ko-l}} being transluded anymore. Theknightwho (talk) 20:37, 5 November 2024 (UTC)

Wait, no, I'm wrong: . Those aren't transclusions, so that is very strange. I'll investigate. Theknightwho (talk) 20:39, 5 November 2024 (UTC)

It's something with {{inh+}} and {{der+}} specifically, but not {{bor+}}, suggesting that it's something to do with the way the first two are crude wrappers around other templates, since {{bor+}} isn't (as I re-implemented it properly a while ago). I can't remember the specifics, but there was a reason why it wasn't straightforward to do that with the other two, which is why I didn't do that at the time, but I'll investigate what's actually causing it, since it could be causing this issue with other templates as well. Theknightwho (talk) 20:52, 5 November 2024 (UTC)

Okay, it's actually {{glossary}} (which is used inside {{inh+}} and {{der+}} but not {{bor+}}), and it's to do with the fact that the glossary template works out what all the possible valid glossary links are and puts them in Module:glossary/data, which involves scanning Appendix:Glossary. For technical reasons that aren't worth explaining, the fact that {{ko-l}} is on the glossary page means that this counts as a "link". However, it doesn't count as a transclusion, so I think this is probably okay, since links to non-content namespaces like templates are generally easy to filter out. Theknightwho (talk) 21:14, 5 November 2024 (UTC)

Weird. Thanks for explaining. Ultimateria (talk) 02:18, 6 November 2024 (UTC)

I think this needs to be modified to either ignore the Thesaurus and Citations namespaces, or allow a wider range of characters in them. Using {{ws sense|en|foo}} in headers seems to be standard in the Thesaurus namespace, but gets flagged, and using ] and labels: colons, then "quotation marks around gloss" seems to be standard/common on Citations pages. Valid edits in these two namespaces constitute a significant part of what the filter is currently catching. - -sche (discuss) 04:46, 5 November 2024 (UTC)

@-sche I've removed the Thesaurus and Citation namespaces for now. I'll re-add them with a more appropriate regexes at some point, which account for the differences. Theknightwho (talk) 20:59, 5 November 2024 (UTC)

On pl.wikt there are gadgets that influence how categories are displayed. The first one makes the category box appear below each language section, before the heading of the next language section (see voda). This makes searching categories easier, since we don't have 200 categories in one box; we could also remove ---- being placed before every new section with that. The second one makes most of the categories hidden, they can be displayed by clicking once. This makes it so that people uninterested in categories don't have to scroll through unnecessary content. The third one shows 60 entries from the category after pressing (↓). I think these would be usefull addition for en.wikt. I think modifing hide button to group categories would be even better, I made simple visualisation how it would look for English Mars:

Before clicking:

After clicking:

Sławobóg (talk) 20:57, 5 November 2024 (UTC)

Practically impossible, even just the part about splitting the category list by language. How is a script supposed to know that Category:Helsinki slang is a Finnish category, for example? — SURJECTION ^{/ T / C / L /} 08:49, 6 November 2024 (UTC)

But it works on pl.wikt. I think it just works like <references/> and prints categories ivnoked in a section by templates, and they are in the same order as templates. Sławobóg (talk) 08:57, 6 November 2024 (UTC)

Very nice & useful idea M @Sławobóg to split Cats by language, perhaps with some half-line separator to help the eye. I think splitting for all sections is a bit too much. But i would like it with all categories at the very bottom (not at every language sector's end). Plus, needing a link on top #see Categories (like at {{minitoc}} or Example: salep#Categories to work automatically, would be nice. Also, at el.wikt, we place links for Categories directly at Language titles (see Wiktionary:Beer_parlour/2024/March#Language_titles_with_category) also at all labels {{label}}, so that readers can go immediately at the Category without scrolling down (e.g. try clicking labels at wikt:el:salep). But en.wiktionary never looks at little ideas coming from small wiktionaries. ‑‑Sarri.greek ^♫ I 09:44, 6 November 2024 (UTC)

<references/> works on the backend, not on the frontend (as a gadget). That is a big difference. — SURJECTION ^{/ T / C / L /} 12:54, 6 November 2024 (UTC)

@Surjection: Splitting categories by language also works with Tabbed Languages, which is a gadget. I can’t pretend to know the technical details, however. Maybe I’m wildly off-base somewhere. — Vorziblix (talk · contribs) 17:36, 6 November 2024 (UTC)

TL's category splitting, like everything else in TL, is highly technically rudimentary and likely to break. — SURJECTION ^{/ T / C / L /} 18:19, 6 November 2024 (UTC)

@Surjection we can tell the software that "Helsinki slang" is a Finnish category. how technically difficult is it really to add data on the connections between categories? I find this a very nice suggestion for organising catgeories that would be very welcomed, but of course I don't know the entire of process to implement it. Juwan (talk) 12:29, 6 November 2024 (UTC)

It's not practical to add every single category to some massive blob of data that the gadget would use. There are quite a few of these categories too that aren't even part of the category tree system, so we cannot use that either. — SURJECTION ^{/ T / C / L /} 12:54, 6 November 2024 (UTC)

A problem with precise links {{l|table|fr}} table#French is that we lose visibility of the See also line on top. Could this line become fixed? Thank you ‑‑Sarri.greek ^♫ I 10:46, 6 November 2024 (UTC)

My understanding is that the purpose of {{also}} is to help people who search for entries using the search box. Direct links using {{l}} should already point to the right entry, so there's no need for the {{also}}. What use case are you thinking of, Sarri.greek? This, that and the other (talk) 03:48, 7 November 2024 (UTC)

It has variaties (with accents etc) as in French, Greek, other. e.g. amo#Latin, ἁμαρτάνω#Ancient_Greek. Of course, one can scroll up and find them. Thank you M @This, that and the other. For a little moment, I can see it (desktop view), and then the text moves to its target. I thought it might be sticky, but then, if one does not need it, it might be irritating. ‑‑Sarri.greek ^♫ I 06:21, 7 November 2024 (UTC)

I have started experiencing problems viewing hiragana in various places, for example, in translation tables and in usernames. All I see is a glyph consisting of a circle inside a square. Is anyone else experiencing this issue? I am using Mozilla Firefox 131.0.3. — Sgconlaw (talk) 22:31, 6 November 2024 (UTC)

Updating to 132.0.1 seems to have solved the issue. — Sgconlaw (talk) 22:58, 6 November 2024 (UTC)

I just saw someone add "further" to the adverb template at apart, so now it says "more or further". What about "farther"? When you can say "further/est" you can always say "farther/est", so the template should show both. 2A00:23C5:FE1C:3701:F4E8:32FB:F63A:C6A4 11:37, 8 November 2024 (UTC)

A problem with <t:]> that is included in quote templates for translations of authors' names. The example from двустволка: #*

.

The translation of the name not visible although <t:Anton Chekhov> included in this quote-book. Now the name translations are gone in all ru quote-books. К.Артём.1 (talk) 19:20, 10 November 2024 (UTC)

Everything is fine now. К.Артём.1 17 November 2024

Can someone fix the issues with rsk-IPA? Namely,

1. Voiced consonants not getting devoiced appropriately when followed by unvoiced consonants, e.g. вшадзи (všadzi) should be not , and гевтот (hevtot) should be not , as seen in the rhyming.
2. Affricates not being fully devoiced when word-end, e.g. будз (budz) should have the same IPA as буц (buc) that is .

Insaneguy1083 (talk) 13:19, 11 November 2024 (UTC)

This isn't specific to any one language, but I've noticed that for whatever reason, when I do {{af|...|type=adap}}, it only creates a specific category for that specific language's adapted borrowings, rather than also having a category for say Language A words derived from Language B, like you would have with {{bor}}. Is that intentional? If not, are there plans to fix that? Insaneguy1083 (talk) 13:25, 11 November 2024 (UTC)

MediaWiki message delivery 00:07, 12 November 2024 (UTC)

I have created User:Red link example (confirmation) for use in documentation and testing.

The account is already globally locked, so cannot be used for editing.

It is vital that the user and talk pages are not created. Can an admin kindly protect them both, permanently, with an edit summary noting that they are "for use in documentation and testing"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:46, 12 November 2024 (UTC)

@Pigsonthewing Done, as requested, but could you please give us a little more detail on why this needs to be done on the English Wiktionary specifically? Thanks. Theknightwho (talk) 20:03, 12 November 2024 (UTC)

Thank you.

It doesn't need to be done here specifically; it needs to be done everywhere, generally. I'm starting with the multi-lingual and en. projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:24, 12 November 2024 (UTC)

For example, Category:Latin terms suffixed with -ō and Category:Latin terms suffixed with -ō (denominative) should be empty, with the latter instead being placed in Category:Latin terms suffixed with -o (denominative). In some cases, there's also strange criteria that I don't understand for which derived words get placed in these categories; e.g. gravidus, an adjective derived from the verb gravo, was placed in the category for words suffixed with -o, which doesn't match conventional usage of this category. Likewise gelata. I don't know if this is an issue with the template or with the parameters used on that particular page. @Ioaxxere Urszag (talk) 04:37, 15 November 2024 (UTC)

@Urszag: The category name thing was a simple fix and those categories should be empty now. As for the situation with gravidus, the template currently looks backwards to add the affix categories as long as it stays within the same language (there's a variable called etymonPassedThroughOtherLanguage that checks this). The reason for this is to catch cases like moustachelessness and categorize them under -ness as well as -less (since the term has both affixes). As far as the template is concerned, gravidus is gravis +‎ -ō +‎ -idus and gets added to both categories, but I guess that might not be desirable in this case. The options are: leave it as it is, get rid of the logic, or figure out a way to tell apart these two cases. Ioaxxere (talk) 06:14, 15 November 2024 (UTC)

Thanks for the fix with the macrons! As for the logic of words with multiple affixes: Do we want to include "moustachelessness" in both categories? The common practice as I understand it has been to only put a word in the category for the most recently added affix. That would be -idus in the case of gravidus, and -ness in the case of moustachelessness. I see how putting moustachelessness in the category for words suffixed with -less might occur if we treat affix categories using the same logic as "roots" categories, but I don't think these are really the same thing. (Setting aside the question that has been raised previously of whether we even want to have root categories that work that way, given how crowded they might get.)--Urszag (talk) 08:24, 15 November 2024 (UTC)

I am trying to add a footnote with the Arabic reference template R:Lisan al-Arab. The reference does show up down the page as expected, but when I then try to actually add a page number (let's say page 400) with

{{R:Lisan al-Arab|page=400}}

, the page number part doesn't show up down in the reference section, as if I didn't add it at all. Why is that? Is it because the reference isn't in Latin script? Is there a work around? Also, when I use that specific reference, it automatically adds «ABC» to the reference section, where ABC is the Arabic word that the page is about. For example, if I am on the page for دعا, the above reference (with or without the page number part) gives me

ابن منظور. «دعا»، لسان العرب.

with «دعا».

But in this particular instance, I am looking to have it reference a different word than the one the article is directly about. Is there any way to specify what word I want to have it put down? Isatuwarx (talk) 05:29, 16 November 2024 (UTC)

@Isatuwarx: the template is very rudimentary; basically it has no parameters for alternative entries or for page numbers. I can work on it; give me a few days. Is there an online version of the full text of this work that we can link the template to, for example, at Google Books or the Internet Archive? If you are specifying a page number, what edition of the work are you referring to? — Sgconlaw (talk) 08:17, 16 November 2024 (UTC)

The Internet Archive does have these scans where each upload is 2 volumes (20 volumes total, published by Al-Maṭbaʿa al-Kubra al-Amirīya in Bulaq from 1883 - 1890). Although, if it is feasible, I think Ejtaal (which uses the version published by Dar al-Ma'arif in 1986) would be better, the site's search function uses Arabic roots to find the pages too . One potential "negative" though is that that page has multiple dictionaries, where Lisan Al-Arab is just 4th of many in the default order, although you can force Lisaan Al-Arab to be the first dictionary listed via the top-left menu, like this link (I hope) demonstrates). In the URL, I have https://ejtaal.net/aa/#la=1, where "la=1" means "page 1 of Lisan al-Arab" (conveniently, it is both page 1 of the online gallery as well as *actually* labeled as "Page 1" in the printed book). When searching a root (like "d3w" or "دعو" if I wanted to get the root for دعا), the URL will update every dictionary's page number to the according page (except for the Supplement to Lane' Lexicon which is always 2 pages past the correct page for some reason); the code for each dictionary in the URL is listed at the end of each dictionary's heading (for example, Lisan Al-Arab heading says "4. Lisan al-Arab (Arabic) (la)", so "la" is the code in the URL that control its page number). There is already a reference template

{{R:ar:Wehr-4}}

that already does cite Ejtaal for the record if that is a useful thing to refer to (and it even lets me cite page numbers if I had wanted; but it doesn't let me specify the root; it defaults to the one the page is about).

I also didn't know it exist until just now, but https://arabiclexicon.hawramani.com/ibn-manzur-lisan-al-arab/ also could work as an alternative. It seems like every actual root entry has a URL of

https://arabiclexicon.hawramani.com/ABC/?book=3

where ABC is the Arabic-script root (with the caveat that Arabic roots ending in w/و are written with ا, so unlike with Ejtaal, it's root دعا not root دعو if I wanted to look up the verb دعا there) Isatuwarx (talk) 14:00, 16 November 2024 (UTC)

The Wehr-4 template defaults to the page name but does let you specifiy the root via |entry= and |1=, as I understand, though it also means you have to use this parameter outside root pages, which other editors always do however. It even specifically does some trick of URL-encoding via the transcluded {{ejtaal}} template. Fay Freak (talk) 14:46, 16 November 2024 (UTC)

Oh, you are right. That does work. Alright, so if Lisan al-Arab template can be made to work at least as well as the Hans Wehr template, that should be good enough. Isatuwarx (talk) 14:54, 16 November 2024 (UTC)

@Isatuwarx: What physical book would it be, anyway? There are various digitized versions of this medieval dictionary on the web which have no pages. At least one is on Wikisource, many may prefer https://arabiclexicon.hawramani.com/, or maybe you mean the one on http://ejtaal.net/aa/; I don’t know whether it is all the same. If you mean a particular edition, create a new template by porting existing reference templates that are mightier, e.g. T:R:ar:Freytag. Like the various editions of the Hans Wehr dictionary, found in this category, have different templates.

Grabbing the pagename is a so-called magic word, in the example of Freytag’s dictionary you can put another headword via |entry= syn. |1=, and in Thadh (talk • contribs)’s reference templates I have found that the page-name is only grabbed if a plus is added as |1= (the first positional parameter), e.g. T:R:aa:Parker:1985. The other complicated stuff in the reference templates are parser functions, we use to calculate numbers in URLs from |page= parameters (not present in the given rudimentary template) to link scanned pages online. If you want a really complicated example, Template:R:sem-eth:Littmann is as much as I know. Everything more technical is done by other users who have coding backgrounds, and have learnt to find documentation of technical implementations by themselves, for which I am thankful, so one can cover languages appropriately—the original reason why I even joined English Wiktionary specifically. Fay Freak (talk) 09:14, 16 November 2024 (UTC)

Are there any plans to adopt Wikidata:Lexicographical data in templates usage for forms in English Wiktionary? Bicolino34 (talk) 15:48, 16 November 2024 (UTC)

It says it has three parameters and gives the example of toplamak, but if you go to the actual page of toplamak the template is filled out differently than in the tr-conj-v page. Zbutie3.14 (talk) 00:58, 17 November 2024 (UTC)

In Vector 2010, the "QQ" button is near the top right of the page, a tab next to the "read - edit - history" tabs. In Vector 2022, it is instead in the right-side toolbar, which is hidden at high levels of zoom, and can also be hidden manually, leaving the QQ button buried a fair way down a dropdown list of "tools". Could anyone write some code that would move it (for me or in general) back to being one of the persistent tabs in the top "read - edit - view history - ☆" bar? - -sche (discuss) 01:35, 17 November 2024 (UTC)

There is an error in template ang-conj, specifically where strong class 5 verbs are concerned. For example, at Old English etan, it shows the first and third person singular indicative preterite as ǣt (long vowel) when it should in fact be æt (short vowel). Leasnam (talk) 02:11, 17 November 2024 (UTC)

This seems not to be an error, but a case of "etan" being an exceptional verb. Even though Bosworth-Toller lists the past conjugation of etan as "ic, he æt, ðú ǽte, pl. ǽton", Ringe and Taylor 2014:348 gives it as "ǣt, ǣton". This is also given by Hogg and Fulk 2011:248, which says fretan also has a long vowel in the second principal part, suggesting it is either from analogical leveling from the plural (? unclear to me why this would target only this verb) or from contraction of originally reduplicated forms.--Urszag (talk) 08:51, 17 November 2024 (UTC)

Thank you. Leasnam (talk) 00:20, 18 November 2024 (UTC)

I got this message a few minutes ago when trying to remove an off-topic message by an IP on Talk:making out.

This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: probably vandalism

I'm adding this here because the edit filter recommended me to. Also, another user should consider removing the talk page message. Gelasin (talk) 06:32, 17 November 2024 (UTC)

@Gelasin: I have deleted that talk page. — Sgconlaw (talk) 06:52, 17 November 2024 (UTC)

In the list of up to ten search results that drops down from the search field, navigation using the down and up arrow keys is broken. When these keys are used, the cursor focus does not proceed sequentially down/up the items in the list as expected. The problem is encountered in desktop web browsers. Voltaigne (talk) 10:01, 17 November 2024 (UTC)

Yes, I’ve just noticed this too. Very annoying. Currently the only way to correctly select an entry from a dropdown list is using the mouse. — Sgconlaw (talk) 14:11, 17 November 2024 (UTC)

It's T379983; the devs will supposedly try to fix it on Monday. I do find it bizarre that it's even possible for them to have broken it in only some skins (Vector 2022 is unaffected) in the first place. - -sche (discuss) 16:35, 17 November 2024 (UTC)

@-sche: thanks. At least they're aware of it. — Sgconlaw (talk) 16:42, 17 November 2024 (UTC)

This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: vandal edit summaries: "nothing", "idk", "made it better" etc.

What I was trying to do: nominate Citations:oink for speedy deletion

Edit summary: Nominating this page for deletion. This is my first time doing this, so if I did it wrong, feel free to change or revert this edit. Gelasin (talk) 01:50, 18 November 2024 (UTC)

@Gelasin: unfortunately, your edit summary coincidentally contained a phrase commonly used in vandals' edit summaries, but in a completely different context. I'm not sure it's worth rewriting the filter to avoid such a rare occurrence.

At any rate, thank you for reporting the problem- I've deleted the page in question. Chuck Entz (talk) 02:46, 18 November 2024 (UTC)

Hello; I think the Wiktionary entry for the word "bassoon" should link to the section on the modern German bassoon as well as the full Wikipedia entry because its second definition, while important, doesn't justify having its own. 136.223.34.48 22:50, 18 November 2024 (UTC)

Not 100% about this particular example, but if you want to link to a section in a Wikipedia article, one solution is to make a redirect on Wikipedia to the appropriate section and link to the redirect here. —Justin (koavf)❤T☮C☺M☯ 07:40, 19 November 2024 (UTC)

You can also link to sections by using # (e.g. {{wp|article#section}}). Perhaps we could modify the {{wp}} template so that it says something like " Wikipedia has a section on" instead of " Wikipedia has an article on" in such cases. Theknightwho (talk) 13:49, 19 November 2024 (UTC)

That would look nicer, but sometimes the link would be to a letter of the alphabet in a page of listings or a heading that does not refer specifically to the linked-from Wiktionary page or to any intelligible text we could put in one of our project links. Does WP have ways of linking to specific points in text, similar to {{senseid}}?

Also, there are some Wikispecies entries, eg, for alternative systematic treatments of higher taxa, including obsolete taxa, for which section links or {{senseid}}-type link targets would also be useful. DCDuring (talk) 19:46, 19 November 2024 (UTC)

Options for link target precision at WP include (1) ] (which resolves to Foo § Section, because any heading element gets its own anchor automagically) and (2) putting {{anchor|Bar}} inside the wikitext at the desired spot, which a link written as ] will resolve to. Thus, you can link from WT to WP using (1) ] or (2) ] if you create the anchor inside the WP page. Quercus solaris (talk) 19:25, 22 November 2024 (UTC)

MediaWiki message delivery 02:00, 19 November 2024 (UTC)

All those involved in anti-vandalism work really ought to read the Diff post. @Chuck Entz, Surjection come straight to mind (and may well be on top of this already - if so I apologise).

Incidentally, TheDaveRoss hasn't edited since January. If he doesn't come back soon we'll need to appoint a new CheckUser, otherwise Chuck will lose these rights (m:CheckUser policy#Removal of access). This, that and the other (talk) 04:29, 19 November 2024 (UTC)

Benwing, perhaps (as a nomination for second CheckUser), or indeed Surjection? BTW, relevant for people to note: it appears to get only a passing mention in that Diff post (?), but w:Wikipedia:Edit filter noticeboard#Protected_filters (permalink) explains in more detail that there is a new option that can and sometimes will be ticked when editing an abuse filter: "Enable the use of protected variables in this filter: Details of this filter will be hidden from users who cannot see protected variables. This action is permanent and cannot be undone." Abuse filters which deal with IPs might, as I understand, have that option set automatically.
My reading of the discussion at Wikipedia is that filters with this flag set (either intentionally because it's relevant, or unintentionally because someone misclicked) thereafter permanently cannot be viewed (and that flag cannot be unset except by phabricator request) by mere local admins / interface-editors (?), and can only be viewed by users with the special bit that lets them see protected variables, although perhaps that bit will be bundled automatically into the rights of those user groups (?). This will impact some of our filters that target vandals who use certain IP ranges. - -sche (discuss) 14:08, 19 November 2024 (UTC)

Apparently by the time someone is trusted enough to get special powers, they are already approaching wiki-burnout.

Benwing would be a good choice but don't they have enough on their plate? DCDuring (talk) 14:56, 19 November 2024 (UTC)

From blocking and page deletion activity we might take Pulimaiyi (talk • contribs) or Kutchkutch (talk • contribs), both having healthy activity levels, if that’s what you are concerned about. Probably can as well give checkuser to Theknightwho, I have not read whether anyone declined to become one, but entrusting one of Surjection or Benwing with it in addition to their already abundant activity levels indeed looks like a bottleneck and would feel forced.

I won’t attempt to understand the filter topic without seeing the admin interface. Fay Freak (talk) 22:35, 19 November 2024 (UTC)

There are currently over 500 Arabic entries in both Wiktionary:Todo/Lists/Uncategorised pages (all namespaces) and Special:UncategorizedPages. I've spot-checked a few, and they all seem to have {{ar-verb form}} as the only headword. These are only part of the 33,000+ transclusions, but most pages would have other content with other templates. As far as I know, this just started within the past week.

These all show categories on the pages themselves, but I have yet to find one on the category pages (my Arabic isn't that great, so that doesn't prove anything). Nonetheless, I suspect that the template's categorization isn't making it all the way into the categories in the database. Pinging @Fenakhay, Benwing2, Theknightwho Chuck Entz (talk) 14:33, 19 November 2024 (UTC)

@Chuck Entz The underlying issue was already fixed a couple of days ago, so these are already all filtering out. Theknightwho (talk) 15:01, 19 November 2024 (UTC)

The error message page for this filter is meant to show the HTML entity for the replacement character, but it instead shows the replacement character itself. This is because the source code for this error page contains �, which the browser shows as "�". Let's fix this by replacing � in the source code with �, which the browser will show as "&#xfffd;". TTWIDEE (talk) 19:58, 19 November 2024 (UTC)

@TTWIDEE Fixed. Theknightwho (talk) 21:09, 19 November 2024 (UTC)

I’ve recently encountered a problem in the Spanish pronunciation section of entries like zarigüeya where the Buenos Aires pronunciation is misleadingly labeled “(Latin America)”, and the correct label appears after clicking on “more”. I would say that {{es-pr}} should be edited so these entries look more like e.g. reyes or cebollazo. Underthebusdweller (talk) 07:38, 20 November 2024 (UTC)

...at slightly-higher-than-default levels of zoom, e.g. 120% and 133%: . (In contrast, 'normal' page content, such as the posts on this page, wraps and doesn't exceed the 'boundaries' of the central 'column' it is in.)
Admittedly, this may be less of a problem than the behaviour in Vector 2010, where at sufficiently excessive levels of zoom part of the TOC just disappears, inaccessibly cut off: . (In Vector 2022, if I increase the zoom beyond the level of the first screenshot, to the level of that second screenshot, the right side toolbar disappears and the screen can be scrolled to the right to access the rest of the TOC.) - -sche (discuss) 15:26, 20 November 2024 (UTC)

These boxes rely on a CSS class toc which is not defined in Vector 2022. While we could define the class ourselves as a workaround, I think we should not be relying on any skin-specific CSS for styling our templates.

In general the category TOC infrastructure is in an abysmal state. It is one of the last remaining areas of Wiktionary that has not been fully Lua-fied, and sorely needs it. I am doing my best to fix the issues in the existing templates using AWB, but I am discovering many category TOC templates that are still totally hand-coded (e.g. Special:PermanentLink/68835765)... This, that and the other (talk) 00:29, 21 November 2024 (UTC)

I have fixed the full boxes, like the ones in your screenshot. @-sche could you take a look? I'm in the process of fixing the small boxes (e.g. at Category:English terms derived from Swedish). This, that and the other (talk) 02:07, 21 November 2024 (UTC)

I've replaced virtually all uses of the toc CSS class, but another related class that is no longer defined by Vector 2022 is toccolours. This is used in quite a number of templates and there is no obvious replacement for it. I wonder if we should define a local equivalent (maybe with a new name like "standard-box"). This, that and the other (talk) 04:17, 21 November 2024 (UTC)

Ping @Surjection, Ioaxxere for thoughts on the above matter. Vector 2022 is being enabled as the default skin next week, so we need to get ready. This, that and the other (talk) 04:19, 21 November 2024 (UTC)

@This, that and the other: It looks like the sole purpose of toccolours is to add these styles:

.toc, .toccolours {
	background-color: var(--background-color-neutral-subtle, #f8f9fa);
	border: 1px solid var(--border-color-base, #a2a9b1);
	padding: 5px;
	font-size: 95%
}

So that should be straightforward to replace wherever necessary. Also, what do you mean by "Vector 2022 is being enabled as the default skin next week"? I thought most people were opposed. Ioaxxere (talk) 04:42, 21 November 2024 (UTC)

@Ioaxxere what do you mean by "should be straightforward to replace wherever necessary"? I wouldn't support adding inline styles - a maintenance nightmare.

As for changing of skins, it's ultimately a WMF decision. Unless WMF staff say it isn't happening, it will happen. There was a similar fuss made when Vector was made the default skin in place of Monobook some years ago, but the change happened anyway, and most people moved on fairly quickly. So I wouldn't worry about it if I were you.

(Incidentally, I just switched to Vector 2022 to get the new experience, and I am certainly enjoying not having lines of text spread across the entire width of the screen!) This, that and the other (talk) 04:52, 21 November 2024 (UTC)

@This, that and the other: I mean, by renaming the class to something else and reproducing the styles in a template styles page. The styles should use palette colours though (maybe --wikt-palette-paleblue and --wikt-palette-dulllightblue). When the default skin does switch we should replace these skin-specific styles ASAP. Ioaxxere (talk) 05:26, 21 November 2024 (UTC)

@Ioaxxere I ultimately put it in Gadget-Site.css; by deleting some other old crap I was actually able to reduce the amount of CSS in that file! The class is used in so many random places that I just don't think TemplateStyles would be workable. This, that and the other (talk) 06:08, 21 November 2024 (UTC)

Large TOCs look good (or at least free of 'toolbar overlap') now; thank you. - -sche (discuss) 04:41, 21 November 2024 (UTC)

Template:label/list is broken and only shows Lua error in Module:labels at line 338: attempt to call method 'find' (a nil value). 76.71.3.150 02:32, 21 November 2024 (UTC)

Looks like this is fixed now, probably by diff. 76.71.3.150 18:53, 21 November 2024 (UTC)

The "add topic" function at RFDE and RFVE is effectively unusable for me as designed. Practically each character that I type in the box takes about five seconds to process. What I can do is compose the text offline and paste it in all at once, which seems to be just one "processing hit" rather than multiple, or I can save short temporary content and then edit the individual section, so there are workarounds. It would be nice if the designed method was actually usable, however. I have a feeling that I have raised this once before. Perhaps others have too. Can nothing be done? Mihia (talk) 19:00, 22 November 2024 (UTC)

The solution is to finally close out the hundreds of very stale conversations that have been open for years and years, but there is no political will to do that. I am a big believer that if a "conversation" has been "open" for four years with no comments or consensus, there is no value in keeping it open and in fact, as you point out, some clear negatives. —Justin (koavf)❤T☮C☺M☯ 19:52, 22 November 2024 (UTC)

Could old entries with little or no activity be archived off onto another page? Mihia (talk) 20:06, 22 November 2024 (UTC)

That is exactly what I was arguing should happen and I have sometimes closed seemingly stale and defunct conversations with others objecting that maybe someone will come along with some interesting comment after seven years. I gave up on closing these ridiculously old conversations because it's not worth the headache to me, but I support anyone else doing it. —Justin (koavf)❤T☮C☺M☯ 20:13, 22 November 2024 (UTC)

I was thinking more along the lines of an automated process that hived off inactive threads after a certain period to somewhere where they would not clog up the works of the active entries. If they were left still available in archive, and able to reactivated if necessary, then would that satisfy the concerns that "someone might come along with some interesting comment"? Mihia (talk) 21:33, 22 November 2024 (UTC)

@Mihia: The simplest solution is to use the source editor or the AJAX editor (one of the buttons next to the section header) instead of the reply feature. — Fytcha〈 T | L | C 〉 22:49, 30 November 2024 (UTC)

Anybody can please explain me how to fix the diacritics in Norwegian? In etries like hol it looks very bad. It works with just one word example like rasshol to put them in the alternative forms section, but it ain’t right to do in the other cases, compared to what the practice is for the other languages like Serbo-Croatian or French. Tollef Salemann (talk) 14:51, 25 November 2024 (UTC)

The words which need to be fixed are all in "Category:Norwegian Nynorsk terms spelled with Ò", "Category:Norwegian Nynorsk terms spelled with É" and "Category:Norwegian Nynorsk terms spelled with Ó". By some reason, links to Norwegian words spelled with ê and ô have no problems, while these three other diacritics are not recognized by the program code. Examples you can see in diacritic-free spelling entries referring to the diacritics forms. Like, stota is not referring to stòta. Tollef Salemann (talk) 15:18, 27 November 2024 (UTC)

MediaWiki message delivery 22:42, 25 November 2024 (UTC)

Text in {{tq}} looks a little too dark in dark mode IMO, although it is technically legible; perhaps it could be made a bit brighter in dark mode? QQ looks good for the most part but the block that says "Google Books   Picked citations" (after you search for something) has a jarringly light background and text which is somewhat hard, although not impossible, to read against that backdrop. (Also, not our purview I understand, but fr.Wikt looks awful in Vector 2022 dark mode, with lots of bright white boxes with white or near-white text; I wonder if Vector 2022 is being rolled out as the default skin there too, or only here, because they may be in for a rude surprise...) - -sche (discuss) 22:48, 26 November 2024 (UTC)

{{m|el|ρολογιού//ρολοϊού}} gives only one transliteration: ρολογιού / ρολοϊού (rologioú), even though the transliterations of the two forms differ: ρολογιού (rologioú), ρολοϊού (roloïoú). @Theknightwho can you help? This, that and the other (talk) 01:32, 27 November 2024 (UTC)

With the new page layout, lines are VERY long -- too long to nicely read on a normal laptop screen (using Edge browser on Windows laptop). Yes the browser window can be shrunk, but this is a real drag. Most websites are designed so that individual lines of text don't stretch the entire way across the screen. I found an option under "Appearance", whereby one can supposedly choose "Standard" or "Wide" width, where "Wide" allegedly makes the content "as wide as possible for your browser window", but for me the content is as wide as possible even with the "Standard" option, and changing to "Wide" makes no detectable difference. Perhaps it's just that this feature is not working properly, and the default "Standard" ought to limit line length? Anyway, one way or another it would be good to get something working so that lines are of a more readable length. Mihia (talk) 10:37, 27 November 2024 (UTC)

I can't be sure, but I suspect what you're seeing is a result of the level of zoom you're using: in Vector 2022, at higher levels of zoom (including the one I too used, until being forced to use lower zoom by the switch), the left and right side toolbars disappear. If you switch to a lower level of zoom, you should see left- and right-side toolbars appear and lines of text like this discussion shrinking to only take up the 'central column'. Of course, then the text is very tiny; I don't know why it isn't an option to have both a decent level of zoom and/or text-size, and text that doesn't take up the whole width of the screen; I would prefer to have both. Perhaps we have to respond to Vector 2022 by editing the sitewide css files to increase the size of all text for desktop users? (Zoom level seems fine on mobile.) Failing that, is there a way an individual user could set all text to be some % larger than whatever size Wiktionary's default css sets it to, i.e. not just set all text to e.g. 125%, but set all text which is currently 100% to 125% while setting all text which is currently set to 200% to now be 250%, so that it is functionally larger at lower levels of zoom? - -sche (discuss) 15:37, 27 November 2024 (UTC)

You are absolutely correct: when I change zoom level from 100% to 90%, it switches to the columnar layout. It's as if the system thinks there "isn't enough room" at 100%, which is crazy as there is more than ample room. If I decrease the zoom level and increase the font size, I can get a combination that looks comfortable, but really I don't believe I should be needing to mess around like this. I should get a comfortable layout by default. Mihia (talk) 15:59, 27 November 2024 (UTC)

I've also just discovered that I can switch back to the old layout, so probably I'll do that for now ... Mihia (talk) 16:05, 27 November 2024 (UTC)

@-sche have you discovered the font size setting under the "appearance" panel (glasses-like symbol along the top)? This, that and the other (talk) 22:43, 27 November 2024 (UTC)

I had not; thank you. I am intrigued and amused that it only changes the size of text in the central column, not the size of the text in the sidebars nor, AFAICT, the size of the text I'm typing in this edit window, so its utility is ... limited, compared to being able to increase the zoom level of the whole page (which is not possible while retaining the sidebars). - -sche (discuss) 23:56, 27 November 2024 (UTC)

is no longer reachable. Not sure what we can do about this. Ioaxxere (talk) 02:14, 28 November 2024 (UTC)

@Ioaxxere that page only works if you're not logged in. I just tested it in an incognito window and it works fine. This, that and the other (talk) 05:20, 28 November 2024 (UTC)

@Ioaxxere oh, I see what you mean by "no longer reachable" - it's no longer linked within the UI. Fixed in although, to be honest, I think the link should probably go in the "..." overflow menu. This, that and the other (talk) 05:27, 28 November 2024 (UTC)

@This, that and the other: Thanks for the fix! I didn't realize we were inserting that link ourselves in JS, actually. I think you're right about putting it in the overflow menu. The link doesn't even go into the overflow menu when I resize the browser window: https://imgur.com/a/PqpDcDr. Ioaxxere (talk) 05:40, 28 November 2024 (UTC)

M @Ioaxxere, This, that and the other, How about a kind of MediaWiki:Sitenotice on top of every page with:

It's simple. I now log in less and less: It would be so helpful! Also: a polite gesture to non-logged guests in our house. ‑‑Sarri.greek ^♫ I 13:33, 28 November 2024 (UTC)

Sony is currently in CAT:E because the German and Portuguese sections get their definitions from the English, and one of the senses has been tagged with {{rfd-sense|en}}. The module error reads: Lua error in Module transclude at line 404: Cannot handle template{{rfd-sense}}.

This raises the obvious question of how {{transclude}} should handle {{rfd-sense}}. Should it just ignore it? The other option I can think of, tagging the transcluding sense with {{rfd-sense}}, but using the transcluding sense's language code, might run into trouble if the RFD is specific to only the transcluded sense as English. Perhaps we should consider some kind of maintenance category like "{language} entries transcluding challenged senses", with the name of the transcluded page as a sortkey. That way they would be easier to find and fix if the sense needs to be deleted.

Deletions are already tricky for the deleting admin because of alternative forms and inflections of the item being deleted, but {{transclude}} adds the problem of figuring out what to do with the transcluding entries, some of which may be in languages the admin doesn't know. The worst case would be a sense that's deletable in English, but not in some of the transcluding languages. Chuck Entz (talk) 02:31, 28 November 2024 (UTC)

@Chuck Entz: User:J3133 has taken care of this: diff. Their solutions was to remove the rf*-sense templates in the transclusion. — Fytcha〈 T | L | C 〉 22:45, 30 November 2024 (UTC)

aWa is bright text on a bright background, in dark mode: . (I included QQ and its own bright bar in the screenshot as long as I was taking one.) - -sche (discuss) 02:40, 29 November 2024 (UTC)

Possibly fixed now. — SURJECTION ^{/ T / C / L /} 22:27, 30 November 2024 (UTC)

There appears to be an issue with the rendering of the title in some (maybe all) of the ang-decl templates (e.g. ġelynd), where it reads "Declension of ' (strong ō-stem)" where I believe it would once read "Declension of ġelynd (strong ō-stem)". It seems to be leaving a " ' " where it used to show the term. Leasnam (talk) 17:38, 29 November 2024 (UTC)

@J3133 Chuck Entz (talk) 18:31, 29 November 2024 (UTC)

Fixed. J3133 (talk) 18:35, 29 November 2024 (UTC)

Thank you ! Leasnam (talk) 18:38, 29 November 2024 (UTC)