Wiktionary:Grease pit/2024/November

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← October 2024 · November 2024 · December 2024 → · (current)

---

Labels and categories for anti-LGBTQ derogatory terms

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)

default styles for non-latin scripts

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)

Module is not recognized as such

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)

Prevent template from crossing Level 2 headings

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.

[wiktioanry] Screenshot showing spilling of the number box template into another heading

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)

Template:hide box

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)

im trying to add a new definition for an abbreviation seen as offensive

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 [here]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)

Tech News: 2024-45

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• Stewards can now make global account blocks cause global autoblocks. This will assist stewards in preventing abuse from users who have been globally blocked. This includes preventing globally blocked temporary accounts from exiting their session or switching browsers to make subsequent edits for 24 hours. Previously, temporary accounts could exit their current session or switch browsers to continue editing. This is an anti-abuse tool improvement for the Temporary Accounts project. You can read more about the progress on key features for temporary accounts. [1]
• Wikis that have the CampaignEvents extension enabled can now use the Collaboration List feature. This list provides a new, easy way for contributors to learn about WikiProjects on their wikis. Thanks to the Campaign team for this work that is part of the 2024/25 annual plan. If you are interested in bringing the CampaignEvents extension to your wiki, you can follow these steps or you can reach out to User:Udehb-WMF for help.
• The text color for red links will be slightly changed later this week to improve their contrast in light mode. [2]
• View all 32 community-submitted tasks that were resolved last week. For example, on multilingual wikis, users can now hide translations from the WhatLinksHere special page.

Updates for technical contributors

• XML data dumps have been temporarily paused whilst a bug is investigated. [3]

In depth

• Temporary Accounts have been deployed to six wikis; thanks to the Trust and Safety Product team for this work, you can read about the deployment plans. Beginning next week, Temporary Accounts will also be enabled on seven other projects. If you are active on these wikis and need help migrating your tools, please reach out to User:Udehb-WMF for assistance.
• The latest quarterly Language and Internationalization newsletter is available. It includes: New languages supported in translatewiki or in MediaWiki; New keyboard input methods for some languages; details about recent and upcoming meetings, and more.

Meetings and events

• MediaWiki Users and Developers Conference Fall 2024 is happening in Vienna, Austria and online from 4 to 6 November 2024. The conference will feature discussions around the usage of MediaWiki software by and within companies in different industries and will inspire and onboard new users.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

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

{{ko-l}}

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)

abuse filter 104

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 [[links, sometimes piped]] 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)