Wiktionary:Grease pit

Wiktionary > Discussion rooms > Grease pit

Click here to start a new Grease pit discussion.

Wiktionary discussion rooms (edit) see also: requests

Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.

Tea room start a new discussion | this month | archives Questions and discussions about specific words.

Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.

Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.

Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

A grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and thesaurus and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, abuse filters, Toolforge, etc. It is also the second-best place, after the Beer parlor, to think in non-technical ways about how to make the best, free, open online dictionary of “all words in all languages”.

Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.

Permanent notice

• Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
• Other tips and tricks are at WT:TAT.
• Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.
  
  

Grease pit archives edit
2024 January February March April May June July August September October November December 2023 January February March April May June July August September October November December
Earlier years 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 October November December

November 2024

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, Антон Чехов [Anton Chekhov], Егерь; 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)

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

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)

Adding page numbers or Arabic roots to a specific Arabic reference template

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)

Templates using Lexemes from Wikidata

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)

tr-conj-v template documentation out of date?

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)

location of QQ button

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)

ang-conj

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)

Edit incorrectly identified as harmful

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)

Search field dropdown list arrow-key navigation problem

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)

Edit filter

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)

Can we start linking to parts as well as whole Wikipedia entries?

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 "[English] Wikipedia has a section on" instead of "[English] 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) [[Foo#Section]] (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 [[Foo#Bar]] will resolve to. Thus, you can link from WT to WP using (1) [[w:Foo#Section]] or (2) [[w:Foo#Bar]] if you create the anchor inside the WP page. Quercus solaris (talk) 19:25, 22 November 2024 (UTC)

Tech News: 2024-47

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

• Users of Wikimedia sites will now be warned when they create a redirect to a page that doesn't exist. This will reduce the number of broken redirects to red links in our projects. [9]
• View all 42 community-submitted tasks that were resolved last week. For example, Pywikibot, which automates work on MediaWiki sites, was upgraded to 9.5.0 on Toolforge. [10]

Updates for technical contributors

• On wikis that use the FlaggedRevs extension, pages created or moved by users with the appropriate permissions are marked as flagged automatically. This feature has not been working recently, and changes fixing it should be deployed this week. Thanks to Daniel and Wargo for working on this. [11][12]

In depth

• There is a new Diff post about Temporary Accounts, available in more than 15 languages. Read it to learn about what Temporary Accounts are, their impact on different groups of users, and the plan to introduce the change on all wikis.

Meetings and events

• Technical volunteers can now register for the 2025 Wikimedia Hackathon, which will take place in Istanbul, Turkey. Application for travel and accommodation scholarships is open from November 12 to December 10 2024. The registration for the event will close in mid-April 2025. The Wikimedia Hackathon is an annual gathering that unites the global technical community to collaborate on existing projects and explore new ideas.
• Join the Wikimedia Commons community calls this week to help prioritize support for Commons which will be planned for 2025–2026. The theme will be how content should be organised on Wikimedia Commons. This is an opportunity for volunteers who work on different things to come together and talk about what matters for the future of the project. The calls will take place November 21, 2024, 8:00 UTC and 16:00 UTC.
• A Language community meeting will take place November 29, 16:00 UTC to discuss updates and technical problem-solving.

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

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)

Template:ar-verb form and Special:UncategorizedPages

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)

Abuse filter 33

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)

Spanish regional pronunciation

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)

right side toolbar overlaps category TOCs in Vector 2022

...at slightly-higher-than-default levels of zoom, e.g. 120% and 133%: [13]. (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: [14]. (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

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)

Editing RFDE and RFVE

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 [ edit, Ædit ] next to the section header) instead of the reply feature. — Fytcha〈 T | L | C 〉 22:49, 30 November 2024 (UTC)

Norwegian diacritics

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)

Tech News: 2024-48

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

• A new version of the standard wikitext editor-mode syntax highlighter will be available as a beta feature later this week. This brings many new features and bug fixes, including right-to-left support, template folding, autocompletion, and an improved search panel. You can learn more on the help page.
• The 2010 wikitext editor now supports common keyboard shortcuts such Ctrl+B for bold and Ctrl+I for italics. A full list of all six shortcuts is available. Thanks to SD0001 for this improvement. [15]
• Starting November 28, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: bswiki, elwiki, euwiki, fawiki, fiwiki, frwikiquote, frwikisource, frwikiversity, frwikivoyage, idwiki, lvwiki, plwiki, ptwiki, urwiki, viwikisource, zhwikisource. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF).
• View all 25 community-submitted tasks that were resolved last week. For example, a user creating a new AbuseFilter can now only set the filter to "protected" if it includes a protected variable.

Updates for technical contributors

• The CodeEditor, which can be used in JavaScript, CSS, JSON, and Lua pages, now offers live autocompletion. Thanks to SD0001 for this improvement. The feature can be temporarily disabled on a page by pressing Ctrl+, and un-selecting "Live Autocompletion".
• Tool-maintainers who use the Graphite system for tracking metrics, need to migrate to the newer Prometheus system. They can check this dashboard and the list in the Description of the task T350592 to see if their tools are listed, and they should claim metrics and dashboards connected to their tools. They can then disable or migrate all existing metrics by following the instructions in the task. The Graphite service will become read-only in April. [16]
• The New PreProcessor parser performance report has been fixed to give an accurate count for the number of Wikibase entities accessed. It had previously been resetting after 400 entities. [17]

Meetings and events

• A Language community meeting will take place November 29 at 16:00 UTC. There will be presentations on topics like developing language keyboards, the creation of the Mooré Wikipedia, the language support track at Wiki Indaba, and a report from the Wayuunaiki community on their experiences with the Incubator and as a new community over the last 3 years. This meeting will be in English and will also have Spanish interpretation.

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

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

a couple more candidates for palettization

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)

Transliteration missing when using // syntax

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

New page layout: line lengths

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 [sometimes-already-enlarged] 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)

Wiktionary:Preferences for users without an account

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 [18] 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:

choose this page's desktop style:	vectorClassic2010 - Vector2022 - monobook & mobile
logged-in users:	Global Preferences     >     ✓ O     >     Save

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)

Template:transclude and Template:rfd-sense

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:

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 and dark mode

aWa is bright text on a bright background, in dark mode: [19]. (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)

ang-decl templates

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)

December 2024

Module:fr-headword, {{fr-adj}}

If a qualifier is used but not for the preceding form, it is added to the wrong form; e.g., if |mpqual= and |mpqual3= are used but not |mpqual2=, |mpqual3= is added to the second plural (|mp2=). J3133 (talk) 07:47, 1 December 2024 (UTC)

Why do in-line references after tlb get put on a separate line?

E.g. see gōian. I don't think this is ideal formatting, is it? I tried putting the reference inside the template to avoid this, but that breaks the link, so it isn't a valid solution. Urszag (talk) 11:06, 2 December 2024 (UTC)

@Urszag I had a go at fixing this at [20]. Of course, as with any CSS change, I may have introduced a new bug somewhere else, so it will be something to keep an eye on. This, that and the other (talk) 22:58, 2 December 2024 (UTC)

What is the rationale for Anglian appearing below rather than on the inflection line? DCDuring (talk) 15:13, 3 December 2024 (UTC)

Edit request at Category:Request templates

The following content should be added to Category:Request templates § Deletion and verification.

• {{derogatory|date=DATE|rfd=|rfv=}} – Request deletion of an uncited derogatory term unless quotations are promptly added

There is another edit request at Category talk:Request templates § Edit request: RFM templates that I also support. Daask (talk) 17:42, 2 December 2024 (UTC)

@Daask I reduced the protection level to autoconfirmed, so you should be able to edit it now. This, that and the other (talk) 22:25, 2 December 2024 (UTC)

Tech News: 2024-49

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

• Two new parser functions were added this week. The {{#interwikilink}} function adds an interwiki link and the {{#interlanguagelink}} function adds an interlanguage link. These parser functions are useful on wikis where namespaces conflict with interwiki prefixes. For example, links beginning with MOS: on English Wikipedia conflict with the mos language code prefix of Mooré Wikipedia.
• Starting this week, Wikimedia wikis no longer support connections using old RSA-based HTTPS certificates, specifically rsa-2048. This change is to improve security for all users. Some older, unsupported browser or smartphone devices will be unable to connect; Instead, they will display a connectivity error. See the HTTPS Browser Recommendations page for more-detailed information. All modern operating systems and browsers are always able to reach Wikimedia projects. [21]
• Starting December 16, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: arwiki, cawiki, frwiki, mediawikiwiki, orwiki, wawiki, wawiktionary, wikidatawiki, zhwiki. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF). [22]
• This month the Chart extension was deployed to production and is now available on Commons and Testwiki. With the security review complete, pilot wiki deployment is expected to start in the first week of December. You can see a working version on Testwiki and read the November project update for more details.
• View all 23 community-submitted tasks that were resolved last week. For example, a bug with the "Download as PDF" system was fixed. [23]

Updates for technical contributors

• In late February, temporary accounts will be rolled out on at least 10 large wikis. This deployment will have a significant effect on the community-maintained code. This is about Toolforge tools, bots, gadgets, and user scripts that use IP address data or that are available for logged-out users. The Trust and Safety Product team wants to identify this code, monitor it, and assist in updating it ahead of the deployment to minimize disruption to workflows. The team asks technical editors and volunteer developers to help identify such tools by adding them to this list. In addition, review the updated documentation to learn how to adjust the tools. Join the discussions on the project talk page or in the dedicated thread on the Wikimedia Community Discord server (in English) for support and to share feedback.

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

MediaWiki message delivery 22:23, 2 December 2024 (UTC)

new tern? boodylaoop

the sound of messages recieved 160.2.117.67 01:37, 3 December 2024 (UTC)

See Wiktionary:Criteria for inclusion. —Justin (koavf)❤T☮C☺M☯ 01:44, 3 December 2024 (UTC)

Module:category tree/poscatboiler/data/lang-specific-raw

I need to add some information there so that categories I created show up on the category tree. I’d appreciate it if someone could either tweak permissions so I can edit the page or paste the information I need to add in my stead. Ping @Benwing2 so he can be aware I made this post.

Below is the code I need added.

raw_categories["Brazilian Portuguese forms superseded by AO1990"] = {
    description = "The following terms were officially used in Brazilian Portuguese — but not European Portuguese — until December 2015, when the period of transition between the previous spelling standard and the [[w:Portuguese Language Orthographic Agreement of 1990|Orthographic Agreement achieved in 1990]] ended.",
    parents = {
        {name = "Portuguese forms superseded by AO1990", is_label = true, lang = pt},
        {name = "Brazilian Portuguese forms", raw = true},
    },
}

raw_categories["European Portuguese forms superseded by AO1990"] = {
    description = "The following terms were officially used in European Portuguese — but not Brazilian Portuguese — until October 2015, when the period of transition between the previous spelling reform and the [[w:Portuguese Language Orthographic Agreement of 1990|Orthographic Agreement achieved in 1990]] ended in Cape Verde. Portugal’s transition period ended in May 2015.",
    parents = {
        {name = "Portuguese forms superseded by AO1990", is_label = true, lang = pt},
        {name = "European Portuguese forms", raw = true},
    },
}

Polomo47 (talk) 07:13, 3 December 2024 (UTC)

A template to handle large amounts of references in Further reading

I've been pondering - for at least Polish, the Further reading section can get very full - each template however is often used for something on a page, be it to support something such as Middle Polish or dialectal pronunciations/definitions, or obsolete definitions, etc., and also it's generally all the most commonly referenced material within Polish linguistics. This can become unwieldy, so I was thinking, what if we had a template such as {{bibliography}} that had some similar features of {{reflist}}, i.e. it can control the size of the references and such, but also local grouping, i.e. I could create categories "Middle Polish" and have the appropriate templates nested under that, or "Dialectal:" and then a subgrouping "Masovian", etc. etc. Vininn126 (talk) 09:58, 5 December 2024 (UTC)

More advanced support of noun class notation?

The Module:gender and number currently gives a large array of possible ways of specifying gender (such as m or f by sense), while it seems to disallow any class specification more complex than class foo. For many languages with noun classes, this is enough I guess, but there are cases where I’d like to give more information (such as in Swahili).

One issue is that there are different conventions, and they’re horribly confusing. The pan-Bantu convention, for example, is to number all classes, singular and plural separately. So *kɪ̀- and its descendants is class 7, *bì- is class 8, etc. In some modern Bantu languages the classes neatly pair up in singular and plural, so for example in Luganda, those two are jointly called class IV (see here for example).

I don’t think there’s a set convention for roman vs. arabic numerals. Our Appendix:Swahili noun classes uses roman numerals for the Proto-Bantu classes, for one. This means that any drive-by user who sees something labeled class IV can’t know whether that’s Proto-Bantu class 4, or some language-specific conflated class or other, or something else entirely.

One solution is using noun prefixes: class ki- etc. But that can be ambiguous. Or we could write class ki-(VII) and the like, but that gets clunky. Another is to put links to the appendix, as {{sw-noun}} currently does. This is not possible using the {{head}} template, I think. ({{sw-noun}} is currently hard-coded, no Lua, no {{head}} for inflections or class specifications, etc. I’ve started working on a version using our current infrastructure.)

To me the best solution would be more informative mouseovers: so we write class VII, and on mouseover instead of the rather unhelpful “noun class VII”, we’d see “class ki- (VII)”, or something of the like. But that would require modifying Module:gender and number in ways that go way beyond my abilities. Add to this the existence of Swahili nouns that have different class agreement by sense, and I hope you understand my pickle. ☺ MuDavid 栘𩿠 (talk) 03:05, 6 December 2024 (UTC)

@MuDavid This would require adding language-specific info to Module:gender and number, but there is precedent for doing this as there are other modules with lang-specific info attached. To handle Swahili nouns with different class agreement by sense, you'd create multiple headwords, one per class agreement (they don't have to be in separate Etymology sections if it doesn't make sense to do so). Benwing2 (talk) 21:49, 7 December 2024 (UTC)

Given there’s many languages with class agreement, and they tend to have many classes, I guess the lang-specific info had better go into separate data pages, no? MuDavid 栘𩿠 (talk) 02:45, 9 December 2024 (UTC)

Yes, there would be one module per language. Benwing2 (talk) 05:11, 11 December 2024 (UTC)

Today I discovered there are words that can take two different agreement classes without any change in meaning, apparently based on whim of the speaker. I think I could hack together a solution in Module:sw-utilities, but I also think extended functionality in Module:gender and number would be better. MuDavid 栘𩿠 (talk) 03:43, 13 December 2024 (UTC)

@MuDavid Headwords support multiple genders, so this wouldn't be a problem. As for adding language-specific classes, can you give me a list of the Swahili noun classes and how you want them to appear? Keep in mind that mouseovers/tooltips don't work on mobile, so we might want a different display for phones. Benwing2 (talk) 03:53, 13 December 2024 (UTC)

The left column in this table is a almost full list. There’s some words with mixed agreement m_(I)/n_(IX), such as rafiki.

I feared you’d bring up mobile at some point. @tbm, do you have any ideas?

On desktop I think my preferred version would be to show the roman numeral (as is currently the case), and give a mouseover with extra information, such as “agreement in ki class_(VII)” for example (but without the link/markup as that doesn’t work?).

Is a completely different display on phones possible? If so, something like “ki_(VII)” would be my preferred output (removing the word “class” to reduce clutter as a tradeoff for showing the prefix as well). If not, I’d vote for what I described for desktop above (to be consistent with other Bantu languages in look); if our convention isn’t clear, visitors can look up the adjective they need to decline to see it all, like: if you open the inflection table at -angu, there’s a full list with the roman numerals given. The extra information from the mouseover isn’t vital.

– MuDavid 栘𩿠 (talk) 09:15, 13 December 2024 (UTC)

@MuDavid Yes, it should be possible to display different content on mobile phones. @Ioaxxere @Surjection sorry for the ping again; it looks like the way to do this is to conditionalize on the screen width, per [24] and [25]. Different sets recommend a max width of 800-1000 pixels for the mobile cutoff. For some reason we don't have nice CSS classes already provided to make this easy; any objections to me adding this, or other thoughts? Benwing2 (talk) 09:33, 13 December 2024 (UTC)

I'm not sure why we are talking about viewport width when MediaWiki has a fully separate mobile site/frontend/skin which you can easily check via CSS or any similar means. However, I'm not very fond of the idea of showing different text on mobile than on desktop. I've always considered it disappointing that mobile browsers never implemented any way to show tooltips. — SURJECTION ^{/ T / C / L /} 10:29, 13 December 2024 (UTC)

@Surjection Sorry, how do you check for the MediaWiki mobile site/frontend/skin via CSS? Benwing2 (talk) 11:04, 13 December 2024 (UTC)

One option is to check for body.mw-mf. — SURJECTION ^{/ T / C / L /} 12:29, 13 December 2024 (UTC)

@Surjection I was able to get desktop-only using templatestyles in conjunction with Template:Benwing2/nomobile.css, but (a) I can't figure out the corresponding mobile-only settings (see Template:Benwing2/mobileonly.css and User:Benwing2/test-mobile, which doesn't work), and (b) this seems overly complex. Is there a simple way of checking without having to create special templatestyles CSS files? If not, can we just put some CSS in MediaWiki:Mobile.css and MediaWiki:Common.css to make this easier? Benwing2 (talk) 20:45, 13 December 2024 (UTC)

One would probably want to define something like (untested)

body .mobile-only { display: none; }

body.mw-mf .mobile-only { display: unset; }

body.mw-mf .desktop-only { display: none; }

— SURJECTION ^{/ T / C / L /} 21:09, 13 December 2024 (UTC)

Something else I noticed: if a gender is missing, the entry goes into the category “Requests for gender in lang entries”. But if it’s a class that’s missing (through |g=c?) then it isn’t. I for one think it should. @Tbm, do you agree? MuDavid 栘𩿠 (talk) 03:38, 11 December 2024 (UTC)

Yes, that would be nice! tbm (talk) 05:01, 11 December 2024 (UTC)

That’s been implemented. Thanks @Benwing2! MuDavid 栘𩿠 (talk) 06:32, 11 December 2024 (UTC)

Problem at {{bnt-verb}}

The template {{bnt-verb}} seems to have a problem with infinitive generation: it only gives “*kʊ̀ ”. See here for example; it should be “*kʊ̀béeka” (I think). It used to work, and no edits to the template were made since then, so the problem must be “backstage”, and I don’t know how to figure this out or solve it myself. MuDavid 栘𩿠 (talk) 03:10, 6 December 2024 (UTC)

etymology-only languages bug

At WT:LOL/E, at the bottom of the page, it reads

Lua error in Module:languages at line 1896: attempt to index local 'parent' (a nil value)

I found this while looking for something else and am not sure its important, but if it is, can we fix it? Thanks. —Soap— 19:06, 6 December 2024 (UTC)

It was a known bug that was fixed within 35 minutes but involved potentially thousands of entries, so it may take a while to clear comppletely. Chuck Entz (talk) 20:15, 6 December 2024 (UTC)

"Category:Pages with entries"

What does insert pages into Category:Pages with entries and its subcats? Is there a documentation of the system somewhere? Taylor 49 (talk) 19:37, 6 December 2024 (UTC)

@Taylor 49 it's done at Module:headword/page#L-884--L-885. Not sure what documentation is needed - it seems self-explanatory. Initially I was sceptical that the system was of any value, but it turns out to be essential for tracking entries with missing headword lines. This, that and the other (talk) 00:04, 7 December 2024 (UTC)

There seems to be about 20000 pages which should be in the category but aren't. 115.188.72.131 11:33, 7 December 2024 (UTC)

Thanks.

local content = raw_title:getContent()

Does the page "read itself" on every template calling Module:headword, ie again for every word class for every language? Taylor 49 (talk) 15:37, 7 December 2024 (UTC)

@Taylor 49 No. There are multiple levels of caching, so that the page reads and processes itself only once per page. You should ask @Theknightwho, who knows more about how this works. Benwing2 (talk) 21:42, 7 December 2024 (UTC)

@Taylor 49 @Benwing2 Even after a few months, the category is still populating, because those pages haven't been refreshed in the cache yet. I suspect pages are prioritised by the server based on daily/monthly page views, which will be 0 for many non-lemma pages. You can find all pages which aren't yet in the category with the search -incategory:"Pages with entries", selecting the mainspace and Reconstruction namespace (note the hyphen at the beginning, which makes it a negative search). Searching that just now gives 23,649 pages. Theknightwho (talk) 21:58, 7 December 2024 (UTC)

Good pickup by the IP - these are entries that only use archaic headword-line templates like {{lt-adv}} that don't call into the module. This, that and the other (talk) 21:47, 7 December 2024 (UTC)

Yuck, I didn't realize there were still headword templates coded like that but it makes sense, there are a lot of dusty corners in Wiktionary. Benwing2 (talk) 21:52, 7 December 2024 (UTC)

@Benwing2 I found a few more if you have time and inclination: {{art-nav-noun}} {{ast-num-card}} {{blk-pron}} {{br-pron}} {{ca-adj-sup}} {{ch-adj}} {{ff-root}} {{gel-noun}} {{ins-interj}} {{io-part}} {{io-pron}} {{ja-altread}} {{kkh-verb}} {{ko-syllable-hanja}} {{ksd-pron}} {{ml-con}} {{sq-personal pronoun}} {{sq-poss-adj}} {{syl-beng-noun}} {{tr-pron}} {{txb-noun-decl}}. I will do some if I have time.

Also most of the sign language headword templates, which are terribly unloved. This, that and the other (talk) 12:06, 8 December 2024 (UTC)

Actually a number of these are simply unused and can probably be deleted. I also found a bunch of unused Norwegian headword templates which I didn't list above... This, that and the other (talk) 12:10, 8 December 2024 (UTC)

I can see that 5 of the listed "dusty" templates are already deleted, after only 6 hours. @Theknightwho: Where is the caching implemented? To me it looks like that the page reads, parses and categorizes itself on every word class for every language, that can be over 100 times for some words. What ensures that this task is done only one time per page? AFAIK mw:Extension:Variables is banned on WMF wikis. Taylor 49 (talk) 19:43, 8 December 2024 (UTC)

@Taylor 49 Calls to getContent() are cached automatically in MediaWiki, so the actual database call happens only once per page. Furthermore, the heavy-duty page parsing is loaded using mw.loadData() through Module:headword/data, and data loaded this way is cached and executed only once per page. The code on line 749 of Module:headword only calls process_page() if the pagename is specified using the `pagename` field and isn't the same as the actual pagename (which generally only happens on test and documentation pages); otherwise it simply uses the precomputed processed page. There are probably other levels of caching as well that @Theknightwho knows more about. Benwing2 (talk) 20:23, 8 December 2024 (UTC)

@This, that and the other I converted or deleted most of them. There are 4 left that aren't deleted or crossed out. Benwing2 (talk) 22:26, 8 December 2024 (UTC)

@Benwing2 @IP 115 @Theknightwho I did some systematic purging, fixed the sign language headword templates (admittedly somewhat crudely), and added an invocation of {{head}} inside {{cuns}}. This has reduced the number of pages in the search from >20,000 to <100.

Once this filters through to the Toolforge replicas, I will adjust WT:Todo/Lists/Entries with missing headword lines to capture these pages and any future pages that are not in Cat:Pages with entries. This, that and the other (talk) 11:13, 10 December 2024 (UTC)

local function process_page(...)
		process_page = require(headword_page_module).process_page
		return process_page(...)
end

local function get_data()
		m_data = load_data(headword_data_module)
		return m_data
end

Yeah I can see that Module:headword/page containing expensive

local content = raw_title:getContent()

is imported at least 2 times, once via "require" and once via "loaddata" indirectly via Module:headword/data. Taylor 49 (talk) 20:41, 8 December 2024 (UTC)

@Taylor 49 process_page is only run directly by Module:headword if the |pagename= is set, which is almost never the case in mainspace, so raw_title:getContent() is still only being run once per page in the vast majority of cases. Theknightwho (talk) 21:12, 8 December 2024 (UTC)

Is "pagename=" intended exclusively for testing? I use "pagenameoverridetestonly=" for such cases. ;-) Taylor 49 (talk) 21:17, 8 December 2024 (UTC)

It's for testing and documentation pages. Benwing2 (talk) 21:20, 8 December 2024 (UTC)

Template:el-form-of-nounadj

I suggest to drop the usage of the old Template:el-form-of-nounadj that is clearly redundant to Template:inflection of. Bots can help to change them. Octahedron80 (talk) 00:46, 7 December 2024 (UTC)

Yes, indeed. This is a question for WT:RFDO really, but it is redundant.

There is one issue: Greek comparative adjective forms tend to be presented as non-lemma forms of the positive adjective, instead of non-lemma forms of the comparative adjective. Compare:

• Latin seniorem:
  • accusative masculine/feminine singular of senior
• Ancient Greek ἐγκυκλιωτέραις (enkukliōtérais):
  • feminine dative plural of ἐγκῠκλῐώτερος (enkukliṓteros)
• Greek λιγότερε (ligótere):
  • (deprecated template usage) Vocative masculine singular, comparative form of λίγος (lígos).
    instead of
    vocative masculine singular of λιγότερος (ligóteros)

I have to admit the nonstandard approach taken by {{el-form-of-nounadaj}} does seem somewhat more useful to the reader! (Even more useful would be something like "vocative masculine singular of λιγότερος (ligóteros), comparative degree of λίγος (lígos)".) But this is not something that is properly supported by {{inflection of}}. This, that and the other (talk) 01:07, 7 December 2024 (UTC)

@This, that and the other Actually it is. See 𐌱𐌻𐌴𐌹𐌸𐌾𐌰𐌽𐌳𐌰𐌽𐍃 for an example of this in action. Language-specific support is specified in Module:form of/lang-data/got. Benwing2 (talk) 09:17, 7 December 2024 (UTC)

@Benwing2 my apologies - I should have known you would think of it - you think of everything! Well there is certainly no reason to keep {{el-form-of-nounadj}} as it is then. It could be made into a wrapper for {{inflection of}} initially (@Octahedron80). This, that and the other (talk) 09:55, 7 December 2024 (UTC)

@This, that and the other In order to convert to the "even more useful" form you mentioned above, the bot would have to determine what the comparative adjective lemma is, which isn't currently specified in the call to {{el-form-of-nounadj}}. Do you know how hard that is? Can it be inferred from the term pagetitle itself? Benwing2 (talk) 21:45, 7 December 2024 (UTC)

@Benwing2 it is derivable by adding ος to the |compstem= parameter of the {{el-decl-adj}} template. This, that and the other (talk) 09:11, 8 December 2024 (UTC)

@Octahedron80 @This, that and the other @Saltmarsh I have a script ready to convert {{el-form-of-nounadj}} to {{infl of|el}}. I found it easier to derive the comparative/superlative base lemma directly from the non-lemma pagetitle by chopping off the ending and replacing it with -ος. Saltmarsh, in almost all cases the resulting text is shorter and easier to type. For example:

# {{el-form-of-nounadj|μόνος|g=m|c=gen|n=s}}
# {{el-form-of-nounadj|μόνος|g=n|c=gen|n=s}}

becomes

# {{infl of|el|μόνος||gen|m|s}}
# {{infl of|el|μόνος||gen|n|s}}

and can further be compressed to

# {{infl of|el|μόνος||gen|m//n|s}}

(I have a separate script to do this compression.)

The script automatically adds the |comp-of= or |asup-of= params as needed. For example on μεγαλύτερου (megalýterou),

# {{el-form-of-nounadj|μεγάλος|g=n|c=gen|n=s|d=c}}

becomes

# {{infl of|el|μεγαλύτερος||gen|n|s|comp-of=μεγάλος}}

which displays as

1. genitive neuter singular of μεγαλύτερος (megalýteros), the comparative degree of μεγάλος (megálos)

I am planning to run this script tomorrow. Benwing2 (talk) 08:52, 10 December 2024 (UTC)

• @Sarri.greek, Benwing2 Can I stress that in spite of my resistance I am not adverse to change. Common formats will bring a unified feel to Wiktionary.
  Nevertheless {{el-form-of-nounadj}} and similar language specific templates have the advantage of speeding up data entry, and more importantly making editing easier for new editors (one look at the Documentation for {{inflection of}}, which refers onward to modules etc, puts me off and it certainly do it for newbies. Experienced editors cannot see how things look to newcomers, and life here has become much more technical since I started. Some of this could be overcome by rewriting Wiktionary:About Greek - a job I could do without.

One question which my look at the documentation hasn't helped me with. Can {{inflection of}} accomplish mixed cases and genders as {{el-form-of-nounadj}} does?

    # {{el-form-of-nounadj|μικρός|g=n|c=nav|n=s}}
  gives:
    1. Nominative, accusative and vocative neuter singular form of μικρός (mikrós).

If I have a problem (or lack the patience) reading the documentation new editors certainly will.

With good will !   — Saltmarsh^☮ 10:52, 10 December 2024 (UTC)

Dear @Saltmarsh, the Wiktionary:About Greek is ok, I do not see anything that needs correcting. The universal system for writing heads, inflections etc covers everything, I think. Now, the robots are doing what we used to do manually in the earlier days of wiktionary, so, please do not worry. ‑‑Sarri.greek ^♫ I 12:55, 10 December 2024 (UTC)

PS to @WingerBot, Benwing, notifying my admin @Saltmarsh. Whatttt is this? στήριξα in ancient and modern Greek?? The way things are written are different in grc and el? The point is to make them similar? Why is grc like that? Why should an editor have to learn 2 or even 3 ways to write one and the same thing? Please unify them. If not unified, what is the point of changing only one of them? ‑‑Sarri.greek ^♫ I 15:55, 10 December 2024 (UTC)

@Saltmarsh The equivalent of {{el-form-of-nounadj|μικρός|g=n|c=nav|n=s}} using {{infl of}} is {{infl of|el|μικρός||nom//acc//voc|n|s}}. I assume this is what you mean by "mixed cases and genders"; you just put the different cases and genders together and separate by //. In general, if you are not sure how something works, check out the examples first; Example 2 under {{inflection of}} demonstrates exactly this usage. As for having a separate way of doing things for every language, that simply won't work; it leads to siloed language communities, making it hard or impossible for new users to contribute, and you get a non-unified look that makes the whole site look amateurish. Greek in fact is particularly bad because there's a whole ecosystem of weird templates like {{el-example}} that do general things in a Greek-specific way and really aren't necessary. Furthermore, documentation for individual-language-specific templates tends to be worse, and worse-maintained, that the language-agnostic documentation. For example, the documentation for WT:About Greek doesn't actually say anything about Greek templates, and the documentation at Wiktionary:Greek_headword-line_templates was completely out-of-date until I fixed it up to some extent last night.

@Benwing2 Thanks — I'm sure that we shall manage !   — Saltmarsh^☮ 10:34, 11 December 2024 (UTC)

@Sarri.greek I assume you are referring to the headword templates. Ancient Greek is already using {{inflection of}} for its definition lines and will be unified with Modern Greek as soon as I make the change to obsolete {{el-form-of-nounadj}}. I will do the Ancient Greek headword templates next; they are no more necessary than the Modern Greek ones we just eliminated.

Respectfuly, Benwing2 (talk) 08:09, 11 December 2024 (UTC)

@Saltmarsh @Sarri.greek I have deprecated {{el-form-of-nounadj}}. I am planning on doing the same to {{el-form-of-verb}}, and then I'll tackle the Ancient Greek headwords. Benwing2 (talk) 08:09, 13 December 2024 (UTC)

MediaWiki:Gadget-RevdelInfo.js

This gadget is on by default for everyone. However, I can't tell what it actually does. I tried comparing a few pages relating to the revision deletion log with it turned on and off and never noticed a difference. Is it nonfunctional? Ioaxxere (talk) 01:53, 8 December 2024 (UTC)

Based on Kephir's edit summary when creating it ("display revdel log on inaccessible revision/diff pages") and its description ("Display excerpts from the revision deletion log when trying to view deleted revisions and diffs between them"), I gather it pulled the relevant revision deletion event (who suppressed the text, edit summary, or username of a given revision) out of the log and displayed it when someone tried to view a revision or diff which had been hidden, to prevent people being confused like this about a situation where information is missing like the username here. (We still have a gadget which does something vaguely similar, pulling up a more informative excerpt of the block log on blocked users' contrib pages.) As far as I can tell, it doesn't work anymore; probably some MW change broke it. In theory it'd be useful, but it might no longer be possible to make it work: which admins have deleted any revisions of a given page is logged publicly, but does anything let non-admins see which admins deleted which exact revisions? - -sche (discuss) 06:05, 9 December 2024 (UTC)

I believe the info is extractable from the API, for example [26]. In the first log ID listed at the present moment (logid 53474838), we can see that Surjection hid the edit summary of revisions 82802609 and 82802607. This API response looks identical when I open it in an incognito window as a logged-out user. This, that and the other (talk) 10:17, 9 December 2024 (UTC)

Neat. Well, if someone wants to make a version of this gadget that works, I would say it'd be "somewhat useful, but not necessary enough to be a priority". (In the meantime, to Ioaxxere's point, it seems like we could turn this gadget off, since it doesn't seem to do anything at all...?) - -sche (discuss) 17:59, 9 December 2024 (UTC)

@-sche: Good to know — in that case I'll remove it from the list of default gadgets and if there's no interest in fixing it after some time then we might want to remove it entirely. Ioaxxere (talk) 05:50, 11 December 2024 (UTC)

Template:crh-latin-noun

This is an old template that shows up in Wiktionary:Todo/Lists/Template language code does not match header because it's not just used in Crimean Tatar entries. It's very simple: it takes positional parameters that are the endings for 5 cases (genitive, dative, accusative, locative, and ablative), and displays {{lang|crh|{{PAGENAME}}}} labeled as the nominative, and the other cases consisting of the same followed by the relevant positional parameter. It doesn't categorize, and it doesn't link to anything (except for "{{m|crh||{{PAGENAME}}}}" in the header, which of course doesn't do anything).

It's used in Turkish, Tatar, and Zazaki entries as well as Crimean Tatar ones, with what looks like 641 transclusions (there's at least one false positive due to {{desctree}}). Is this a problem? Or should we just add it to the excluded-template page for the Todo list? Chuck Entz (talk) 01:40, 9 December 2024 (UTC)

@Chuck Entz This should be split into language-specific variants. For one thing, it (now) has actual links in it that use the crh code, meaning it will link to the wrong language for any other language. Benwing2 (talk) 08:07, 13 December 2024 (UTC)

Temporary Accounts: technical help needed

As part of the rollout of Temporary Accounts, we are working to ensure that tools, gadgets, bots, user scripts, AbuseFilters, and any other community-owned code continue to work smoothly.

What are Temporary Accounts?

Temporary accounts are a new type of account for unregistered editors. Instead of showing IP addresses publicly, these accounts will assign temporary user IDs to logged-out editors. Tools that rely on IP addresses or workflows for logged-out users might need updates to function correctly. Temporary accounts are already live on some pilot wikis, with more pilot deployments planned for February and full rollout on all wikis in May.

How you can help

• Check if code (whether on Toolforge or on wiki, that is: tools, gadgets, bots, or user scripts) you created or frequently use works on the wikis where temporary accounts are already active. Here is the list of content wikis, and here is the list of beta cluster and test wikis with temporary accounts.
• If you notice a tool that might be impacted, we encourage you to try updating it based on our developer documentation guide.
• Do add the tools you see as impacted on this page. We want to monitor them to make sure that everything is working as expected.
• Take a look at Abuse Filters used on your wiki. Any filter using IPs via user_name will no longer be able to do so. Those filters need to be updated to use user_unnamed_ip instead. A comment from our engineers: "The main use case should be if you try something like ip_in_range(s). Things that map to usernames should be broadly ok, as they’ll continue to map to temporary account names." If you have more questions about AbuseFilter, you may add a comment on the Phabricator ticket T369611.
• If you find any issues or have comments or questions, let us know on the project talk page. You can also join the dedicated Discord thread for support and to share feedback to the team.

By helping test and report, you will ensure important tools work smoothly with this update. Thanks for your support! Udehb-WMF (talk) 07:51, 9 December 2024 (UTC)

Tech News: 2024-50

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

Weekly highlight

• Technical documentation contributors can find updated resources, and new ways to connect with each other and the Wikimedia Technical Documentation Team, at the Documentation hub on MediaWiki.org. This page links to: resources for writing and improving documentation, a new #wikimedia-techdocs IRC channel on libera.chat, a listing of past and upcoming documentation events, and ways to request a documentation consultation or review. If you have any feedback or ideas for improvements to the documentation ecosystem, please contact the Technical Documentation Team.

Updates for editors

Layout change for the Edit Check feature

• Later this week, Edit Check will be relocated to a sidebar on desktop. Edit check is the feature for new editors to help them follow policies and guidelines. This layout change creates space to present people with new Checks that appear while they are typing. The initial results show newcomers encountering Edit Check are 2.2 times more likely to publish a new content edit that includes a reference and is not reverted.
• The Chart extension, which enables editors to create data visualizations, was successfully made available on MediaWiki.org and three pilot wikis (Italian, Swedish, and Hebrew Wikipedias). You can see a working examples on Testwiki and read the November project update for more details.
• Translators in wikis where the mobile experience of Content Translation is available, can now discover articles in Wikiproject campaigns of their interest from the "All collection" category in the articles suggestion feature. Wikiproject Campaign organizers can use this feature, to help translators to discover articles of interest, by adding the <page-collection> </page-collection> tag to their campaign article list page on Meta-wiki. This will make those articles discoverable in the Content Translation tool. For more detailed information on how to use the tool and tag, please refer to the step-by-step guide. [27]
• The Nuke feature, which enables administrators to mass delete pages, now has a multiselect filter for namespace selection. This enables users to select multiple specific namespaces, instead of only one or all, when fetching pages for deletion.
• The Nuke feature also now provides links to the userpage of the user whose pages were deleted, and to the pages which were not selected for deletion, after page deletions are queued. This enables easier follow-up admin-actions. Thanks to Chlod and the Moderator Tools team for both of these improvements. [28]
• The Editing Team is working on making it easier to populate citations from archive.org using the Citoid tool, the auto-filled citation generator. They are asking communities to add two parameters preemptively, archiveUrl and archiveDate, within the TemplateData for each citation template using Citoid. You can see an example of a change in a template, and a list of all relevant templates. [29]
• One new wiki has been created: a Wikivoyage in Indonesian (voy:id:) [30]
• Last week, all wikis had problems serving pages to logged-in users and some logged-out users for 30–45 minutes. This was caused by a database problem, and investigation is ongoing. [31]
• View all 19 community-submitted tasks that were resolved last week. For example, a bug in the Add Link feature has been fixed. Previously, the list of sections which are excluded from Add Link was partially ignored in certain cases. [32][33]

Updates for technical contributors

• Codex, the design system for Wikimedia, now has an early-stage implementation in PHP. It is available for general use in MediaWiki extensions and Toolforge apps through Composer, with use in MediaWiki core coming soon. More information is available in the documentation. Thanks to Doğu for the inspiration and many contributions to the library. [34]
• Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. On December 4, the MediaWiki Interfaces team began rerouting page/revision metadata and rendered HTML content endpoints on testwiki from RESTbase to comparable MediaWiki REST API endpoints. The team encourages active users of these endpoints to verify their tool's behavior on testwiki and raise any concerns on the related Phabricator ticket before the end of the year, as they intend to roll out the same change across all Wikimedia projects in early January. These changes are part of the work to replace the outdated RESTBase system.
• The 2024 Developer Satisfaction Survey is seeking the opinions of the Wikimedia developer community. Please take the survey if you have any role in developing software for the Wikimedia ecosystem. The survey is open until 3 January 2025, and has an associated privacy statement.
• There is no new MediaWiki version this week. [35]

Meetings and events

• The next meeting in the series of Wikimedia Foundation discussions with the Wikimedia Commons community will take place on December 12 at 8:00 UTC and at 16:00 UTC. The topic of this call is new media and new contributors. Contributors from all wikis are welcome to attend.

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

MediaWiki message delivery 22:16, 9 December 2024 (UTC)

Any possibility of allowing users to manage multiple books across sessions?

I recently tried to use the book creation function to compile a list of entries for personal use and was shocked to find out it isn't saved across sessions. Can i ask what the rational for this is?

If there is no underlying obstacle to this, i'd kindly request allowing users to compile and manage any number of books they desire. I've invested an ungodly amount of my time searching for this exact functionality across platforms and this is the only one that actually works as i intend. It's such a shame to see it ruined by such an apparently simple defect. 1ifemare (talk) 06:06, 10 December 2024 (UTC)

@1ifemare I'm sorry to hear you had a bad experience with the book creator. When you're ready to save your book, you can click "Show book" and save the book into your userspace. I just saved a test book at User:This, that and the other/Books/test.

Unfortunately the book creator is an old piece of software that is not maintained, so there is no possibility of auto-save functionality being added to it. This, that and the other (talk) 06:20, 10 December 2024 (UTC)

@This, that and the other Thank you so much for replying.

That's the tragedy. It was the absolute best experience i had with a tool capable of creating a custom online personal dictionary - out of dozens of others i scoured the web for and thoroughly tested, just to find they all have crippling limitations, or just outright don't offer the desired functionality.

I tried saving a book, but there doesn't seem to be a away to re-open it as a book inside the creator software. There also doesn't see to be a way to delete saved books, unless i missed something. 1ifemare (talk) 13:47, 10 December 2024 (UTC)

palettize Galician, Portuguese, etc tables

On social media, I saw someone complaining that we were mistaken to list distinto as the short past participle of Portuguese distinguir, and in the process of looking into that, I noticed that all the conjugation tables on that page are bright-on-bright and could stand to be palettized, so I'm reporting that for tracking purposes. (Do we have a page or category for tracking "things that need to be palettized"?) - -sche (discuss) 09:12, 10 December 2024 (UTC)

@-sche I don't know of any central place for tracking these. If there is such a place, @Ioaxxere would know. I took a whack at palettizing the Spanish table; in the process the colors got a little more saturated and less pastel. Dunno if anyone will complain. I posted before and after side-by-side comparisons on Discord in the #general channel, but AFAIK you're not on Discord and I don't know how to post the pictures here at Wiktionary. Benwing2 (talk) 07:56, 11 December 2024 (UTC)

@-sche @Ioaxxere Ugh, I managed to palettize all the major Romance languages + Latin (not yet Proto-Romance though) as well as all the minor ones up through R. There are so many minor Romance languages out there, each with their own slightly different table. Ioaxxere, all the tables go 100% across the screen, which might not be ideal. Please take a look at Module:roa-verb/style.css; maybe there is a fairly simple way of fixing this. Unfortunately I don't understand the nuances of CSS well enough to know what to do here. Benwing2 (talk) 10:00, 12 December 2024 (UTC)

What does palettize mean in this context? The sole sense in our entry for the term doesn't seem to apply. DCDuring (talk) 15:36, 12 December 2024 (UTC)

It means using colors from MediaWiki:Gadget-Palette.css so that they are varied between light and dark mode.

Stujul (talk) 16:02, 12 December 2024 (UTC)

So it's ad hoc wikijargon, not worth including in palettize? DCDuring (talk) 18:17, 12 December 2024 (UTC)

Probably not, no

Stujul (talk) 20:53, 12 December 2024 (UTC)

@Benwing2: The closest thing to what you're describing is the report generated by MediaWiki:Gadget-AutoContrastFixer.js on a page load. It looks like this: https://imgur.com/a/auto-contrast-report-J9UovAe (in this example, the conjugation table at da#Bavarian as well as a couple other languages was adjusted). There's no central place that tracks all of the fixes.

As for the second point, NavFrames go all the way across the screen by default, but you can limit it with max-width: 40em or something like that. But that would make the Romance conjugation tables extremely cramped so I don't think there's any reason to do that. Ioaxxere (talk) 00:56, 15 December 2024 (UTC)

Thanks for converting the templates, and apologies for using an opaque term, respectively. (It was shorter than ~"convert to using Palette.css colors".) - -sche (discuss) 22:19, 12 December 2024 (UTC)

I guessed at a meaning like that, but there's always the risk that GP discussions with consequences to the less tech savvy will be opaque to them. BTW, I didn't find use in Google Books of palettize/ise except a modest amount possibly in the sense in our entry and as many as a misspelling of palletize/ise. DCDuring (talk) 23:45, 12 December 2024 (UTC)

head with added diacritics

Subject: For languages, where _1. the written words in books are without diacritics and _2. they are also presented in wiktionary and other dictionaries with extra diacritics.
At the moment, en.wiktionary presents the word type_1 at the title of the page. But only type_2 as headword, Template:head. This is very confusing for people who are not aquainted with a particular language: what is the word they should use and copypaste? e.g. italian with added accents, russian with added accents, ancient greek with added prosodies (breve and long), arabic (with vowel diacritics) etc. I think the head should be clearly presented both in its pure spelling as we see it in printed books and in parenthesis with its altered/auxiliary/fiddled spelling+tooltip (with added diacritics / with added so-and-so diacritics). Whenever I need to copy a word, I have to go to the title to copypaste it. For languages I do not speak, I never know how it is supposed to be written. Please help. Thank you. ‑‑Sarri.greek ^♫ I 16:29, 10 December 2024 (UTC)

Categories for year of attestation

I think that this could be pretty convenient. For example, if the word "ABO blood group" was first used in 1949, just have it have a category called "1949". Angrythewikipedian (talk) 16:59, 10 December 2024 (UTC)

It could be, if the editorial certainty about first uses were good. But categories would nudge us to shoehorn our adequately vague datings into them. And none might even apply to non-European languages even if we tried earnestly with the effort I consider disproportionate; I believe that we won’t get together a handful in Arabic, which I edit; people from the censored Chinese internet should voice their opinion about what they typically know about the creation ranges of non-artificial terms, if this isn’t verboten at their location as well, and whether this would be useful there. We shouldn’t base such a decision solely on English, and many American even admins around here are competent to see other languages. Fay Freak (talk) 17:40, 10 December 2024 (UTC)

I just don't think we have the data for most of our entries for this to be useful. — Sgconlaw (talk) 17:54, 10 December 2024 (UTC)

@Angrythewikipedian For reference, @Vininn126 wants to add something similar based on {{etydate}}, but (a) per-language and (b) based on ranges of a century or so, not individual years (which are much harder to attest and are "slippery" because it's common to find a quote that pushes back the earliest attestation from what it was previously thought to be). Benwing2 (talk) 08:00, 13 December 2024 (UTC)

Commenting to subscribe. Vininn126 (talk) 09:22, 13 December 2024 (UTC)

Add language codes to Module:wikimedia languages/data

The following language codes and corresponding should be added as they currently don't appear in many places despite having valid ISO codes: 'bfw' => 'Bonda/Remosam/ବଣ୍ଡା', 'gju' => 'गुज्जरी/Gujari/Gojri', 'hoc' => 'Ho/𑢹𑣉𑣉 𑣎𑣋𑣜', 'kgg' => 'Kusunda/Gemehaq gipan' 70.55.18.30 03:38, 11 December 2024 (UTC)

That's not what Module:wikimedia languages/data is used for. It's for mapping Wiktionary language codes to Wikimedia language codes, which are used to e.g. name project domains. — SURJECTION ^{/ T / C / L /} 07:17, 11 December 2024 (UTC)

different punctuation in different language versions of Wiktionary prevents automatic interwiki links

I tried to fix a language problem on Help:Interwiki linking, but the corrected paragraph still doesn't explain what to do when interwiki linking isn't working automatically e.g. the Swedish Wiktionary's "Lika barn leka bäst." and our "lika barn leka bäst". I checked that at least some other and perhaps all other Swedish proverbs in the Swedish Wiktionary aren't connected with the same proverbs in the English Wiktionary or the German Wiktionary, e.g. aller guten Dinge sind drei and https://sv.wiktionary.org/wiki/Aller_guten_Dinge_sind_drei. (Interestingly, that correct URL doesn't even work, even when adding a slash "/" after the period.) -- Espoo (talk) 08:40, 11 December 2024 (UTC)

I suspect that if both wikis want these to be crosslinked, they would both need to create redirects from the other's form. (We used to have to do this to accommodate fr.Wikt and en.Wikt using different apostrophes; that is now handled by considering the different forms of apostrophe interchangeable in the automatic linking function itself, but I don't think the same can be done for capital vs lowercase letters.) So sv.Wikt would create a redirect at [[sv:lika barn leka bäst]] (to [[sv:Lika barn leka bäst.]]), as they appear to have already done years ago, and we would do the reverse, creating a redirect at [[Lika barn leka bäst.]]. I would hope that if official sv.Wikt policy is to capitalize and include punctuation, everyone here would be fine with allowing redirects from sv.Wikt's forms, to enable interwiki linking, but perhaps others can speak up. - -sche (discuss) 16:15, 11 December 2024 (UTC)

I disagree with the term "linguistically incorrect habit" used at sv:Wiktionary:Bybrunnen#technical_problems_in_the_Swedish_Wiktionary. English wiktionary is undeniably biggest but has strange punctuation habits. On the page crack#Noun we can see

# {{lb|en|vulgar|slang}} The [[vagina]].

(vulgar, slang) The vagina.

Why the article "The"? Why the capital letter "T"? "The vagina." is barely a full sentence, is it? And why the dot at the end?

"sv:Lika barn leka bäst."

is a full sentence, therefore it ends with a dot and begins with a capital letter. On the page sv:crack

(vardagligt) /rent/ kokain

is NOT a full sentence and therefore it does NOT end with a dot and does NOT begin with a capital letter.

There is a very sane and useful point with the Swedish system: a definition is a replacement of the word defined:

The train was hauled by an old locomotive.

Definition style of Swedish wiktionary:

locomotive -- rail vehicle equpipped with a motor intended to pull trains

After replacement:

The train was hauled by an old rail vehicle equpipped with a motor intended to pull trains. (works)

Definition style of English wiktionary:

locomotive -- A rail vehicle equpipped with a motor intended to pull trains.

After replacement:

The train was hauled by an old A rail vehicle equpipped with a motor intended to pull trains.. (broken)

Also, if uppercase and dot are to get dropped for the sake of simplicity, then the comma must get dropped too. Then an eye for an eye, a tooth for a tooth is a technically incorrect/dysfunctional URL and must be moved to an eye for an eye a tooth for a tooth. It is inconsequent and useless to keep commas and at same time drop dots in proverbs.

Support redirects on both sides Eye for an eye, a tooth for a tooth. until a better solution is available. Taylor 49 (talk) 22:03, 20 December 2024 (UTC)

{{suffixsee}} etc. don't link to language subsections

List-based templates powered by Module:affix/templates such as {{suffixsee}}, {{prefixsee}}, etc. create lists where the entries don't link to the appropriate language subsection, but rather to the entire page. For example:

Dutch terms suffixed with -el (instrument)

You would expect e.g. "spil" to link to spil#Dutch, but it just links to spil. Even further, you would expect it to link to the appropriate sense, as indicated by the id.

Stujul (talk) 15:38, 11 December 2024 (UTC)

@Stujul The problem here is that the above list is not actually generated directly by the code in Module:affix/templates; rather, it's invoking the categorytree parser function, which is a special feature of MediaWiki itself that provides this functionality but unfortunately (AFAIK) doesn't support tweaking the generated links to include the appropriate anchros. I think we'd have to do this using a gadget (which should be fairly easy to write; pinging @Ioaxxere, @Surjection or @Erutuon if they happen to have time on their hands). Maybe alternatively we could generate the list ourselves and stick it in a NavBox or something; unfortunately I'm not sure we have dynamic access to the contents of a given category. (We do have access to the number of pages in a category, but that is a different ball of wax.) Benwing2 (talk) 07:58, 13 December 2024 (UTC)

I don't think we can access category members. Implementing a gadget for this is doable, but needs some thought, since we wouldn't want to duplicate catfix code. — SURJECTION ^{/ T / C / L /} 10:30, 13 December 2024 (UTC)

@Surjection: I think the catfix gadget should be extended to do this. I'm studying how it works now, but we'll need to simultaneously make changes to the modules behind {{suffixsee}} and co. Ioaxxere (talk) 01:26, 15 December 2024 (UTC)

@Stujul:  Done Ioaxxere (talk) 04:17, 15 December 2024 (UTC)

Reconstruction:Proto-Cushitic/ħazk-/*ħizk-/*ħuzk-

I can see why the entry creator wanted to do it this way, but our template infrastructure can't handle slashes in pagenames. Also pinging @Fay Freak as the only regular editor I can think of who might know anything about Proto-Cushitic. Chuck Entz (talk) 15:50, 11 December 2024 (UTC)

FWIW, our Proto-Sino-Tibetan entries also use slashes, e.g. Reconstruction:Proto-Sino-Tibetan/s-b/m-ruːl, and tildes, Reconstruction:Proto-Sino-Tibetan/m-ljak ~ mrak ~ mruk, and both at once, Reconstruction:Proto-Sino-Tibetan/p(r)an/t ~ b(r)an/t. It causes issues there, too, e.g. Wiktionary:Grease_pit/2024/September#how_Proto-Sino-Tibetan_pages'_names_display_in_categories. Perhaps someone can think of either a better naming format or a way to accommodate the slashes. - -sche (discuss) 16:08, 11 December 2024 (UTC)

Wildcards, V for the vowel. Fay Freak (talk) 17:01, 11 December 2024 (UTC)

redirect link to etymology 2

How can one make "shook" in the list https://en.wiktionary.org/wiki/shake#Derived_terms link to the adjective? -- Espoo (talk) 13:23, 12 December 2024 (UTC)

"various specific spammer habits" filter

I was trying to create Template:R:grc:Tucker. Why would links to reliable journals like onlinelibrary.wiley.com be blocked? 172.97.141.219 17:33, 12 December 2024 (UTC)

Because abuse filters have no way to tell whether an external link added by a new or anonymous user is to a reliable journal. They don't have access to templates or modules, and they can't afford complicated logic because they run every time any page is accessed anywhere on Wiktionary, so they have to be very fast. They also can't access any information about anonymous editors except for their IP addresses, so they have no way to tell you're not a one-time hit-and-run spambot- and trust me, they catch lots of spam edits all the time. It's a shame that they also stop a few occasional good edits in the process, but there's not much we can do about that. At any rate, I was able to see your attempted edit in the logs, so I went ahead and created the template for you. Chuck Entz (talk) 03:27, 13 December 2024 (UTC)

On enwiki, I noticed good websites like Wiley are trusted by w:MediaWiki:Captcha-addurl-whitelist. Should we import the list into mediawikispace and the tripped abuse filter? 172.97.141.219 17:24, 13 December 2024 (UTC)

Why should we spend our time maintaining such things when you can simply create an account for yourself and avoid all this trouble? This, that and the other (talk) 23:16, 13 December 2024 (UTC)

PIE stem type as a definable parameter

Ive been working at the Module:ine-nominals a bit, hopefully nothing too offensive, adding a few Categories for previously not-recognized stem types (nouns of which types were classified as root nouns), but there remain a few entries in the root noun categories which are in fact formally indistinguishable from root nouns, like *h₃dónts (*h₃dent- would be a perfecly fine root afaik) and only morphological analysis tells us this contains a -ónts. Therefore I would like to request a new parameter stem type which primarily interacts with the table.insert(data.categories operator to override any erroneous placement in the else-category (that is, root nouns).
The reason I'm asking is because adding a parameter is above my technical competence, I hope someone with Lua-knowledge can easily solve this.
If you have problems understanding my request, do ask. Suryaratha03 (talk) 19:30, 13 December 2024 (UTC)

1. Oh also the boilerplate module needs major reworking, whoever reads this might be interested in helping overhaul that. Suryaratha03 (talk) 20:27, 13 December 2024 (UTC)

Odd sorting by {{col3}}

@Benwing2: see peevish—any idea why {{col3}} does not sort "{{l|en|impeevish}} {{qualifier|obsolete}}" before "{{l|en|impeevished}} {{qualifier|obsolete}}"? — Sgconlaw (talk) 22:46, 13 December 2024 (UTC)

@Sgconlaw it appears to be ignoring punctuation and spaces, and sorting "impeevishedobsolete" before "impeevishobsolete". That's the "why"... as for a solution, that part would be more difficult. This, that and the other (talk) 01:00, 14 December 2024 (UTC)

@This, that and the other: from what I understand, the template is supposed to ignore templates like {{l}} and {{vern}}, and markup like “[[ ]]”, but an alphabetical sort should place “impeevishedobsolete” before “impeevishobsolete” so I’m wondering why that doesn’t happen. — Sgconlaw (talk) 04:44, 14 December 2024 (UTC)

@Sgconlaw "impeevishedobsolete" before "impeevishobsolete". I think it would make a lot more sense for {{col3}} and friends to sort specifically by the output of the {{l}} template only, ignoring any qualifiers, plain text, etc. This, that and the other (talk) 05:05, 14 December 2024 (UTC)

@This, that and the other: sorry, my mistake—I see what is happening now. The template is taking the qualifier “obsolete” into account when sorting, whereas if there were no qualifiers impeevish would appear before impeevished. I agree that qualifiers should be ignored when sorting. — Sgconlaw (talk) 05:17, 14 December 2024 (UTC)

@Sgconlaw: I changed the template to {{col3-u}}, which does the trick. No idea why it didn't before. DonnanZ (talk) 16:47, 14 December 2024 (UTC)

@Donnanz: thanks. However, ideally {{col3}} and its relatives should be able to deal with this sort of situation without editors resorting to manual sorting. — Sgconlaw (talk) 16:59, 14 December 2024 (UTC)

@Sgconlaw: Agreed, but {{col3-u}} comes in handy when all else fails. I have a problem with St for saint, which gets tangled up with everything else beginning with St when sorting. Our templates can't cope with that. DonnanZ (talk) 17:21, 14 December 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Fenakhay has pointed out a useful solution, which is to type "impeevish<qq:obsolete>". It seems that tags in angle brackets are ignored by the template for sorting purposes. Thanks! — Sgconlaw (talk) 18:32, 15 December 2024 (UTC)

Mobile view

I seem to have selected mobile view somehow by accident ( on Friday the 13th, of all days). I can enlarge the page text and the width, but everything else has shrunk, including images and search box. How can I reset it for my full screen? Wikipedia is OK, no problem. DonnanZ (talk) 15:06, 15 December 2024 (UTC)

@Donnanz Do you see a Desktop link on the very bottom of the page? You should be able to switch between the two views. Panda10 (talk) 17:39, 15 December 2024 (UTC)

Well, you can go to Mobile view and then switch back from that to Desktop. But I still get small text, which I can enlarge with the spectacle view at the top, as well as page size. But I didn't knowingly click on Mobile view, I probably clicked on Control by accident (instead of Shift) and a letter key. Editing this page has to be small text, not large, as before. DonnanZ (talk) 18:12, 15 December 2024 (UTC)

@Donnanz: what device are you editing on? If on a Mac, you can usually increase or decrease the text size of a browser window by pressing Command+ or Command- (no need to also press the Shift key). On a PC the key corresponding to Command is either Ctrl or Alt—offhand I can't remember which. — Sgconlaw (talk) 18:30, 15 December 2024 (UTC)

I have a PC built by my local computer shop years ago, now rebuilt by them with a solid state hard drive, and now with a wide screen, and with standard UK keyboard. I'm not sure if I have to press another key with Ctrl or Alt. DonnanZ (talk) 18:58, 15 December 2024 (UTC)

Fixed it. Ctrl, Shift and +, all at the same time, three times to get the required size. I have enough fingers... DonnanZ (talk) 19:56, 15 December 2024 (UTC)

@Donnanz: ah, so that's the keystroke. — Sgconlaw (talk) 20:19, 15 December 2024 (UTC)

@Sgconlaw: I could have dispensed with Shift by using the + key on the right of the keyboard. Never mind. Thanks. DonnanZ (talk) 20:33, 15 December 2024 (UTC)

Weird formatting in category lists

Category pages such as Category:Proto-Italic lemmas now give a list of forms such as "Reconstruction:Proto-Italicad, Reconstruction:Proto-Italicad-" etc., where "Reconstruction:Proto-Italic" is smooshed together with the reconstructed term. This seems like a bug: for readability, I'd expect at least a "/" separating them, although probably in this context it would be reasonable to just leave out "Reconstruction:Proto-Italic/" altogether and use an asterisk in its place. Urszag (talk) 17:05, 15 December 2024 (UTC)

Possibly related to the changes made here? A separate problem which would also be good to fix is that as described in September, a page like Reconstruction:Proto-Sino-Tibetan/t/duŋ shows up in Category:Proto-Sino-Tibetan_lemmas as just "Reconstruction:Proto-Sino-Tibetan/t" (now "Reconstruction:Proto-Sino-Tibetant") but is sorted under "d", which seems unhelpful two ways! - -sche (discuss) 17:34, 15 December 2024 (UTC)

 Fixed Special:Diff/83052949. — Fenakhay ^{(حيطي · مساهماتي)} 18:24, 15 December 2024 (UTC)

@Urszag: Sorry, the bug was in fact an oversight on my part. But I've just implemented your idea as an experiment so let's see what people think. Ioaxxere (talk) 00:50, 16 December 2024 (UTC)

Label and categories for concepts originating in Japan

there are several words for Japanese concepts in English and other foreign languges that require categorisation or recategorisation, as they are mostly just found inside the general Category:Japan. below are some recommendations for labels and categories that should be created:

• {{lb|en|Japanese fiction}} — Category:Japanese fiction
• {{lb|en|Japanese food}} — Category:Japanese food
• {{lb|en|Japanese pornography}} — Category:Japanese porngraphy

other suggestions are (with examples):

• people (samurai, geisha)
• fashion (gakuran, sailor fuku)
  • street fashion (gyaru, lolita)
• art (shibui, wabi-sabi)
• culture (may be way too general)

if you have any more suggestions, please let me know. Juwan (talk) 04:21, 16 December 2024 (UTC)

List of item languages suddenly lost?

I have noticed that the menu list of languages on top of each search item has suddenly disappeared? What happened and why? Is there a technical problem? I'm quite devastated, as those listings are very helpful and time saving, that you get an overview of all languages involved and may easily go straight to your preferences instead of having to scroll through every single language in the list. I hope it's just a technical issue, that it's soon to be in place again? Bemland (talk) 08:07, 16 December 2024 (UTC)

I'm using the new look, where they are listed in the top right-hand corner. E.g., sex says it's in 79 languages. DonnanZ (talk) 09:30, 16 December 2024 (UTC)

I'm pretty sure they are talking about the table of contents as the interwikis were on the left (not the top) before going to the top right.

It's not a technical issue. This was forced on Wiktionary by the WMF some time ago. Not sure where the table of contents went after the switch but if you go to your user preferences (top right), you can switch back to the old skin (Vector 2010) and the table of contents will come back. 115.188.138.105 13:08, 16 December 2024 (UTC)

The top right is for Wiktionary in other languages. On the left any other languages in English Wiktionary are listed (e.g. France), as long as you haven't hidden the Main menu and Contents. In addition, you can "Switch to old look" in the Main menu. DonnanZ (talk) 13:58, 16 December 2024 (UTC)

Thank you both very much, it worked fine reversing the skin back to 2010 version and that list of content top left returned, grateful of that! Hard to understand why its considered better without that list, but good that it's reversible. Still, newcomers don't know about that option, so maybe one should give some short info on that? Best wishes to you! Bemland (talk) 21:58, 16 December 2024 (UTC)

desctree errors in case of multiple etymologies

As pointed out by Rua five years ago, the desctree template simply picks the first descendants section it can find, which can be wrong when there are multiple sections. One example (before I copy/pasted the correct descendants) was at Latin ferus for the Old French descendants tree, old version here. I've also noticed that desctree picks any alternative forms (using 'alt') it can find, also when this is in another etymology section than the descendants. Example at ferrum: Old French 'fier' is not an alternative form of "iron".
Just an idea, but would some interaction with (the id's of) the etymon template be possible? Exarchus (talk) 14:23, 16 December 2024 (UTC)

@Exarchus: Yes, this is a situation I've predicted because no template can be smart enough to actually understand a complex entry like the one you linked. I was working towards integrating the descendant trees with {{etymon}} but there wasn't a ton of enthusiasm and it is very complex to implement. Ioaxxere (talk) 14:37, 16 December 2024 (UTC)

Multiple inline examples

I wish to request a method to create multiple inline examples in examples inside the {{ux}} and {{co}} templates. below is an example from time (permalink), where editors simply hacked it with non-breaking spaces. this is likely not great as it is a static width and may be not be understood semantically by screen readers.

1. {{ux|en|Roman '''times''';  the '''time''' of the dinosaurs;  how things were at that '''time''';  how things were in those '''times'''}}

   Roman times;  the time of the dinosaurs;  how things were at that time;  how things were in those times

please leave suggestions on a better way to denote this. Juwan (talk) 19:40, 16 December 2024 (UTC)

We need a new template, which can be English-specific. Perhaps:

{{en-ux-multi|Roman times|the time of the dinosaurs|how things were at that time|how things were in those times}}

Roman times; the time of the dinosaurs; how things were at that time; how things were in those times

Any thoughts? This, that and the other (talk) 01:17, 18 December 2024 (UTC)

TBH, I much prefer just keeping multiple examples like that on separate lines. Sure, it takes up more vertical space, but I think it looks cleaner and is far easier to skim and digest the different examples. Andrew Sheedy (talk) 22:34, 20 December 2024 (UTC)

I don’t mind if several short collocations are placed on the same line as it saves space, but don’t think we should allow for, say, more than three, or allow a string of collocations that flows on to a second line. I have been doing this in some cases by adding three em spaces between the collocations. — Sgconlaw (talk) 20:05, 21 December 2024 (UTC)

Tech News: 2024-51

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

Weekly highlight

• Interested in improving event management on your home wiki? The CampaignEvents extension offers organizers features like event registration management, event/wikiproject promotion, finding potential participants, and more - all directly on-wiki. If you are an organizer or think your community would benefit from this extension, start a discussion to enable it on your wiki today. To learn more about how to enable this extension on your wiki, visit the deployment status page.

Updates for editors

• Users of the iOS Wikipedia App in Italy and Mexico on the Italian, Spanish, and English Wikipedias, can see a personalized Year in Review with insights based on their reading and editing history.
• Users of the Android Wikipedia App in Sub-Saharan Africa and South Asia can see the new Rabbit Holes feature. This feature shows a suggested search term in the Search bar based on the current article being viewed, and a suggested reading list generated from the user’s last two visited articles.
• The global reminder bot is now active and running on nearly 800 wikis. This service reminds most users holding temporary rights when they are about to expire, so that they can renew should they want to. See the technical details page for more information.
• The next issue of Tech News will be sent out on 13 January 2025 because of the end of year holidays. Thank you to all of the translators, and people who submitted content or feedback, this year.
• View all 27 community-submitted tasks that were resolved last week. For example, a bug was fixed in the Android Wikipedia App which had caused translatable SVG images to show the wrong language when they were tapped.

Updates for technical contributors

• There is no new MediaWiki version next week. The next deployments will start on 14 January. [36]

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

MediaWiki message delivery 22:24, 16 December 2024 (UTC)

Category:Old Iranian languages and Category:Middle Iranian languages

These are chronologically-based "families" that are used to get around near-complete lack of information on specific Iranian lects from these time periods. until sometime yesterday, the {{auto cat}} modules allowed derivation categories based on them, but now we have 51 of them in CAT:E. I would note that the etymology templates still accept them. Chuck Entz (talk) 14:41, 18 December 2024 (UTC)

This was mostly my fault; I removed the entries from the canonical name-code mappings, because Module:data consistency check said these codes did not actually exist. Turns out that module just doesn't support the setup. I restored them some time ago and the errors are going away. — SURJECTION ^{/ T / C / L /} 22:18, 18 December 2024 (UTC)

IMO we should just be using (perhaps "etymology-only") language codes for this, like we do for substrates, etc, particularly because we're de facto treating it as a language when we reconstruct terms in it and have entries say something is from "Middle Iranian *foobar". Cf this and the replies by others. - -sche (discuss) 06:27, 19 December 2024 (UTC)

triple braces flagging bug?

For some reason this edit got flagged for using triple braces. Maybe some bug because two spaces are used in the term? Exarchus (talk) 16:32, 19 December 2024 (UTC)

Nevermind, the error is there because of a previous edit. Exarchus (talk) 16:37, 19 December 2024 (UTC)

I am still experiencing this error—when editing "Appendix:Colors/Colour grouping" even though I did not add any triple braces in the edit. Any chance it can be fixed soon? — Sgconlaw (talk) 12:54, 21 December 2024 (UTC)

If you look at the code there, there are several instances of triple braces to show either 'color' or 'colour', or 'gray'/'grey'. But I can't tell you more about how this should be fixed. Exarchus (talk) 13:56, 21 December 2024 (UTC)

@Exarchus: ah, I see. Those were already in the page before I worked on it. It seems like they are supposed to allow for alternative displays of the spellings of certain words depending on readers' preferences, but I don't know if they actually work. Can someone confirm this? — Sgconlaw (talk) 16:05, 21 December 2024 (UTC)

I couldn't make that structure work in my sandbox. I suspect that this may be something that works on other wikis and/or once worked here. Instances should probably be replaced by wikitext that function properly. DCDuring (talk) 18:28, 21 December 2024 (UTC)

@DCDuring: thanks. I've removed the odd markup. — Sgconlaw (talk) 18:48, 21 December 2024 (UTC)

It was a case where someone was improperly copying a template, {{gmh-decl-pronoun}}, into an entry. There should never be triple braced template arguments in entries because entries aren't transcluded as templates, and template arguments have no useful effect otherwise. I'm not sure why the template was copied into the entry. Ideally it would be used in the entry. — Eru·tuon 20:29, 21 December 2024 (UTC)

Thanks. I hadn't realized that triple brackets only work in templates, though that's the only place I've intentionally used them. DCDuring (talk) 20:34, 21 December 2024 (UTC)

@DCDuring They work everywhere, but there's not much point in them if the page isn't intended to be transcluded like a template. The reason they get flagged by the abuse filter is because they strongly suggest someone is blindly copying a template somewhere they shouldn't be (i.e. exactly what happened here). Theknightwho (talk) 21:26, 21 December 2024 (UTC)

Well, they work in the sense that all parameters are empty, and syntax that provides a value when a parameter is empty will always provide that value. Of course, the parameter-empty value without all the template syntax produces exactly the same result and you don't need to know template code. With the colors appendix, the code was set to provide the UK variants if the parameters for the US variants were empty, so the code accomplished nothing: "Col{{{or|our}}}" is just a very complicated way way of writing "Colour". If you had a page in your userspace with the code "{{Appendix:Colors/Colour grouping|or=or}}", it would display "color" instead of "colour" in those places, but I'm not sure it's worth the unreadble wikitext on the appendix page. Chuck Entz (talk) 21:59, 21 December 2024 (UTC)

Appendix:English catenative verbs

Hi. Could someone take a peek at the column formatting on this appendix please. Whole sentences have been split rather than maintained in their correct column. Thanks. -- ALGRIF talk 11:10, 20 December 2024 (UTC)

Edit: I think the column template used originally is deprecated. There should be two columns; one with the entry and the other with notes or special examples as needed. I cannot find how to do that now. Acceptable alternative would be simply to make the entries in 2 cols. Thanks. -- ALGRIF talk 12:15, 20 December 2024 (UTC)

ja-pron Pitch accent in compound words

Full context: Template_talk:ja-pron#Multiple_accent_phrases

I'm requesting permission to edit Module:ja-pron. To solve the issue of Japanese pitch accent in compound words, I've written a proof-of-concept template, Template:ja-acc-multi, that relies on ja-pron (similarly to how Module:ja-ojad relies on ja-pron), and right now its output looks like:

• 適者生存

• てきしゃせーぞん [téꜜkìshà sèézóń] (Atamadaka + Heiban – [1]-[0])

• 完全無欠

• かんぜんむけつ [kàńzéń mùkétsú] (Heiban + Heiban – [0]-[0])

This solves the issue with users manually hardcoding pitch accent in these words. Shlyst (talk) 20:14, 22 December 2024 (UTC)