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)

A fix (but a bad one):

* {
  -webkit-locale: "";
}

БудетЛучше (talk) 11:17, 10 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)

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)

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)

@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: [4]. 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)

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)

@-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)

Categories gadget idea

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:

Categories: English lemmas  (hidden categories)

After clicking:

Categories: English lemmas Pronunciation: English 1-syllable wordsEnglish terms with IPA pronunciationRhymes:English/ɑː(ɹ)zRhymes:English/ɑː(ɹ)z/1 syllable  English terms with audio pronunciation Etymology: English eponymsEnglish terms derived from Middle EnglishEnglish terms inherited from Middle EnglishEnglish terms derived from LatinEnglish terms borrowed from Ukrainian  English terms derived from Ukrainian Grammar: English proper nounsEnglish nounsEnglish uncountable nounsEnglish countable nouns  English nouns with unknown or uncertain plurals Labels: English poetic termsEnglish terms with rare senses  English terms with obsolete senses Topics: en:Astronomyen:Roman deitiesen:Heraldic tincturesen:Alchemyen:Chemistryen:Villages in Ukraineen:Places in Ukraineen:Mars (planet)  en:Planets of the Solar System Others: English terms with usage examples  English terms with quotations

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)

The also line, always visible

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)

Hiragana not displaying properly

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)

en-adv template: further, farther

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)

Problems with <t:[[w:|]]>

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

1885, Антон Чехов, Егерь; English translation from Constance Garnett, transl., The Huntsman, 1918:

.

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)

rsk-IPA module

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 [ˈfʃad͡zi] not [ˈvʃad͡zi], and гевтот (hevtot) should be [ˈɦɛftɔt] not [ˈɦɛvtɔt], 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 [but͡s].

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

Adapted borrowing categories

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)

Tech News: 2024-46

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

• On wikis with the Translate extension enabled, users will notice that the FuzzyBot will now automatically create translated versions of categories used on translated pages. [5]
• View all 29 community-submitted tasks that were resolved last week. For example, the submitted task to use the SecurePoll extension for English Wikipedia's special administrator election was resolved on time. [6]

Updates for technical contributors

• In 1.44.0-wmf-2, the logic of Wikibase function getAllStatements changed to behave like getBestStatements. Invoking the function now returns a copy of values which are immutable. [7]
• Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. The API will be rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints. The impacted endpoints include getting page/revision metadata and rendered HTML content. These changes will be available on testwiki later this week, with other projects to follow. This change should not affect existing functionality, but active users of the impacted endpoints should verify behavior on testwiki, and raise any concerns on the related Phabricator ticket.

In depth

• Admins and users of the Wikimedia projects where Automoderator is enabled can now monitor and evaluate important metrics related to Automoderator's actions. This Superset dashboard calculates and aggregates metrics about Automoderator's behaviour on the projects in which it is deployed. Thanks to the Moderator Tools team for this Dashboard; you can visit the documentation page for more information about this work. [8]

Meetings and events

• 21 November 2024 (8:00 UTC & 16:00 UTC) - Community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year. The theme of this call is how content should be organised on Wikimedia Commons.

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

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

Protection of User:Red link example

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)

Etymon not stripping macrons for Latin category names

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)