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

October 2024

Module:foreign numerals needs higher Roman numerals

Module:number_list/data/la has now been extended beyond one million, which caused the Roman numerals automatically generated by Module:foreign numerals to get out of hand. Wikipedia represents 1,000,000,000 in Roman numerals as M with two lines over it; I don't know where it comes from, but that is at least more likely to have ever been used than repeating M̅ a thousand times. Urszag (talk) 22:19, 1 October 2024 (UTC)

Can Quiet Quentin be modified for formatting only?

I don't generally use QQ for searching, since I am often searching books.google for specific date ranges, looking for earliest and latest cites, or looking for uses of rare senses, eg currently the noun sense of scarper, which I was unaware of until I read it in the Guardian, following which I had to look through about 130 bg quotes to find two more uses. (I couldn't use QQ because, even when it hasn't reached what seems to be its daily quota, it seems to stop after around 20 hits, and anyway, there is sometimes insufficient context in the snippet it shows to know whether the cite is using the word in the sense I'm searching for.) I'm not expecting that to change anytime soon -- I believe I'm using sufficiently fuzzy skills that it will take a while yet for AI to catch up with me, and at the same time, I read slowly enough that Google knows I'm not a machine, so they don't shut me down.

BUT, having found my cites, I then spend ages filling out the details into the template -- often longer than it took me to do the search. Would it be possible to modify QQ (or some other gadget) to take an input of a particular bg page, rather than searching for it itself, and format the cite from that? Hopefully, that would be easy, since it must do something very similar at present, after users click on the cite they want to use. --Enginear 01:54, 3 October 2024 (UTC)

Developers broke our CSS again

phab:T376361, itself caused by a bungled fix to phab:T375876...

What even is integration testing? Ioaxxere (talk) 02:39, 3 October 2024 (UTC)

辨へ

This is a {{ja-see}} issue; 辨へ is the old kana form of 辨え, the kyūjitai form of 弁え, which is an alternate form of わきまえ (which has the old kana form わきまへ). All of the other forms work, but not 辨へ. TE(æ)A,ea. (talk) 02:42, 4 October 2024 (UTC)

@TE(æ)A,ea.: Seems the template lacks a default way of handling alternative kyūjitai forms. Thankfully, it accepts custom fields. Binarystep (talk) 05:31, 24 October 2024 (UTC)

"bodkin" not showing up in -kin category

bodkin isn't showing up in the Category:English terms suffixed with -kin (diminutive). Can someone explain why it's happening and/or show me how to fix it? Thanks! Katya0133 (talk) 04:26, 4 October 2024 (UTC)

@Katya0133 It was using {{m}} instead of {{af}}. Anyways, that part should ideally be covered under Middle English. Catonif (talk) 12:21, 4 October 2024 (UTC)

Add Hanunoo Transliteration in language settings

Please add the additional attributes to m["hnn"] at Module:languages/data/3/h:

m["hnn"] = {
    "Hanunoo",
    35435,
    "phi",
    "Hano, Latn",
    translit = {Hano = "hnn-translit"},
    override_translit = true,
    entry_name = {Latn = {remove_diacritics = c.grave .. c.acute .. c.circ}},
    standardChars = {
        Latn = "AaBbKkDdEeGgHhIiLlMmNnOoPpRrSsTtUuWwYy",
        c.punc
    },
    sort_key = {
        Latn = "tl-sortkey",
    },
}

Thanks! 𝄽 ysrael214 (talk) 11:06, 4 October 2024 (UTC)

Tested the translit module and  Done. Catonif (talk) 12:46, 4 October 2024 (UTC)

@Catonif Hi can you also add "hnn" to data.hyphen_not_multiword_sep at Module:headword/data? 𝄽 ysrael214 (talk) 14:56, 4 October 2024 (UTC)

Request for globalisation of JS snippet for hieroglyphs

Following this discussion. There is currently an issue with the display of hieroglyphs not supported by WikiHiero, as {{egy-h}} has to treat them separately (traditionally this was done manually via egy-glyph), which leads the final result to go to a new line when those glyphs are encountered if the window is too small. For example, check the quotation under hrm and decrease your window size (or access it from your cellphone, where the width is insufficient already) and notice the unwanted line breaks. This can be solved via a JS snippet, currently at User:Catonif/hierotables.js (I know modifying raw HTML with regexes is usually considered forbidden practice, but handling this with JQuery seemed to get too lengthy and bug-prone), which also solves another issue, this time intrinsic to WikiHiero, about even more unwanted wrapping in complex hieroglyphs groups.

Given that we already have a JS script running on Common.js for WikiHiero, MediaWiki:WikiHieroTempFix.js (this makes WikiHiero results display inline with the text rather than displaying block), launched whenever WikiHiero calls are detected, I believe the content of hierotables.js snippet could be simply incorporated in it.

The second issue is that this WikiHieroTempFix.js I just mentioned is not called on MediaWiki:Mobile.js, but only on MediaWiki:Common.js, which means that if I access pages such as ⲑⲱⲟⲩⲧ from my cellphone (weirdly enough, not if I access it in mobile mode from the PC however), the hieroglyphs in the etymology rather messily do not display inline with the text. I don't know whether we're planning to merge Common.js and Mobile.js, as @Ioaxxere recently finally did for their .css counterparts, which would get rid of this issue, but as long as that's not the case I call for WikiHieroTempFix.js to be run also by Mobile.js.

CC: @Vorziblix. Catonif (talk) 12:18, 4 October 2024 (UTC)

If no one has any objections, I support putting all of User:Catonif’s suggestions into operation. This JS snippet resolves some very longstanding issues with WikiHiero and should make mobile browsing of relevant entries much less messy. — Vorziblix (talk · contribs) 23:41, 7 October 2024 (UTC)

linkify_entry at Module:table tools is no longer correctly handling asterisked/reconstructed inputs

Not sure when this went bad, but attempting to process table entries thorugh the linkify_entry function no longer correctly creates links to reconstructed entries. Instead, an input like *jptwj creates a link to Reconstruction:[language name]/Unsupported titles/Reconstruction:[language name]/jptwj; see the links at {{Egyptian demonstratives}} for a number of examples. This only happens when the asterisk comes at the start of the input; inputs like jptw, *jptwj, where multiple entries are listed and the reconstructed one doesn't come at the beginning, are processed fine. Anyone know how to fix it? — Vorziblix (talk · contribs) 14:32, 4 October 2024 (UTC)

@Vorziblix This is caused by {{lang}}, not by Module:table tools, and is due to something in embedded_language_links in Module:links. I've asked User:Theknightwho to look into it. Benwing2 (talk) 00:08, 5 October 2024 (UTC)

JPEG artifact: compression-induced image distortion

also: JPEG artefact

• JPEG artifact: compression-induced image distortion

188.4.61.73 21:35, 4 October 2024 (UTC)

It's not clear what you are saying. — Sgconlaw (talk) 21:48, 4 October 2024 (UTC)

@Sgconlaw context-free posts to the GP can often be elucidated by checking the user's abuse log. In this case I think the abuse filter is not set up properly, as the user did provide a definition, even though they failed to remove the rfdef template. This, that and the other (talk) 04:15, 5 October 2024 (UTC)

Category:Terms in nonstandard scripts by language

I've been going through these, and I'm finding a few common types of false positives:

1. Zero affixes like ∅- and -∅ have entries in various L2s and are included in etymologies.
2. Combining diacritics with a dummy character as a holder, such as ◌́, ◌̂, ◌̈, ◌̀, etc.
3. Links to Wikipedias and other Wiktionaries. Wikimedia sites can have entry names in any language, so links to their entries should not be treated as text in a specific language. For instance, all the Cyrillic characters have entries on English Wikipedia with Cyrillic titles, but the links to those entries in {{wikipedia}} or {{pedia}} are not English terms in Cyrillic. Likewise, a Wikipedia in a non-Latin script will have articles on organisms and their taxa under their taxonomic names, but links to those are not terms in the language of the Wikipedia in Latin script.
4. Languages with no script specified. What's the point of putting the entire language in an entry-maintenance category?
5. Obsolete or rare orthographies like Belarusian Łacinka, or Arabic script for various languages in the Philippines, Indonesia, South Asia, Eastern Europe, etc. I realize that these have to be handled on a case-by-case basis, but I thought I would mention them, to be thorough.
6. Multilingual symbols such as mathematical or scientific notation, signs for gods, astrology and alchemy terms. Here again, this is probably case-by-case.

Some common mistakes. I'm not sure there's a technical fix for these:

1. Transcriptions copied from comparative literature by people who don't know or care that they're in the wrong script.
2. Bad language codes
3. Wrong templates: people using {{l}} instead of {{lb}} for labels is probably the most common (there was even someone who used {{l|lb}}, which made them into Limburgish).
4. Errors in template syntax: for instance, not putting the right number of pipes between positional parameters, so a translation or transliteration is treated as a display form.

One special case worth mentioning: Hindi and Urdu headword templates have links to the equivalent term in the other language. If someone uses {{head}} instead, they try to reproduce this by having fields for "Urdu spelling" or "Hindi spelling", but these are tagged as the language of the headword rather than as another language. There may be a way to work around this, but I haven't found it yet.

I hope I haven't overloaded this topic. I was afraid that I would never get around to posting this if I had to decide how many individual posts to break it into. Thanks! Chuck Entz (talk) 17:31, 5 October 2024 (UTC)

I tried to solve false positive type 3 in Special:Diff/82308974 and 4 in Special:Diff/82309298, but it might take a while to filter through. As for 6 (multilingual symbols), we shouldn't be writing {{syn|en|❤️}} or whatever. I guess it should be {{syn|en|mul:❤️}}. This, that and the other (talk) 11:41, 7 October 2024 (UTC)

@Theknightwho reverted the second change, pointing out that this is a useful way of keeping track of which languages need script codes added to their language data. TKW might also be able to help fix false positive types 1 and 2 by making the relevant code ignore the ∅ and (presumably) ◌ characters. This, that and the other (talk) 23:37, 7 October 2024 (UTC)

tt template broken?

In five#Translations it seems usages of Template:tt are broken and only show "true" or "true, true" Xie1995 (talk) 19:04, 5 October 2024 (UTC)

This looks to be fixed. Benwing2 (talk) 21:03, 5 October 2024 (UTC)

Tamil script

Is there a particular reason for it to appear always in italic when it's linked? Sérgio R R Santos (talk) 11:37, 7 October 2024 (UTC)

Module:languages help

Hi, here on enwiktionary, {{bn-noun}} gives বই • (boi) (see বই#Noun). On bnwiktionary, we don't need the translit part for Bengali word (in this example, the (boi) part). So, i comment out translit part from languages/data module. But the template still says "Transliteration required". How can we remove it? (We still want "Transliteration required" for other languages but not for Bengali language.) আফতাবুজ্জামান (talk) 17:28, 7 October 2024 (UTC)

@আফতাবুজ্জামান Hey it looks like you should undo your change and instead add "bn" to the list here: Module:headword/data#L-434. Benwing2 (talk) 21:55, 8 October 2024 (UTC)

{{IPAchar}}

Is it possible to update {{IPAchar}} so that it does not allow a line break after a slash (/), to avoid a result like what is simulated below?

In German schon is pronounced /

ʃoːn/.

I tried inserting a zero-width no-break code after the slash when using the template, but this causes it to throw a "unrecognized character" error. — Sgconlaw (talk) 16:44, 8 October 2024 (UTC)

We could add word joiners after opening and before closing at Module:IPA#L-538. It looks as though this would solve the problem. (Using CSS would too, but then IPA pronunciations would never wrap, which is not correct behaviour.) Would the word joiners cause trouble on any known system, or with copy-pasting? This, that and the other (talk) 09:09, 9 October 2024 (UTC)

Edit request to MediaWiki:Badtitletext

Change the link m:Help:Page name#Restrictions to mw:Manual:Page naming#Page title restrictions. Also while you're at it you may want to consider adding a similar message to MediaWiki:Title-invalid-characters which is more likely to be seen. * Pppery * _{it has begun...} 23:35, 8 October 2024 (UTC)

@Pppery:  Done — would it make sense for MediaWiki:Title-invalid-characters to be an exact copy? Ioaxxere (talk) 01:40, 9 October 2024 (UTC)

Suggested code:

<div class="plainlinks" style="background-color:#FFE7DD;border: 1px dashed #884444;width:90%;margin:auto;text-align:left;text-align:center;margin-bottom: 10px">
Sorry, titles containing the character $1 are [[mw:Manual:Page naming#Page title restrictions|not supported by our software]]. It is possible that the entry you are looking for is below; if not, please [[WT:RE|request]] it or [{{fullurl:Appendix:Unsupported titles|action=edit}} add it] yourself.
</div>
{{Appendix:Unsupported titles}}
{{Appendix:List of protologisms/Long words}}

Almost an exact copy, but I modified the first sentence a little to include the specific invalid character. Some more advanced logic could in theory be added but that already exists in MediaWiki:Gadget-UnsupportedTitles.js so I wouldn't bother. * Pppery * _{it has begun...} 01:42, 9 October 2024 (UTC)

Done, I also tweaked the CSS a little. Ioaxxere (talk) 02:28, 9 October 2024 (UTC)

Cleanup job - substed templates

https://en.wiktionary.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&search=insource%3A%22NavFrame%22 Ioaxxere (talk) 03:20, 9 October 2024 (UTC)

Your post is wildly obscure, so I have to tease out what you're trying to tell us, but it seems like, e.g. ორომს has a declension table that was inserted as HTML rather than MediaWiki syntax. Looking at {{lzz-conj-table}}, it is very different from the conjugation table in this entry, so I suppose that User:Gubazes inserted it by hand deliberately. Maybe he can tell us more about what happened there? And maybe you can elaborate on what you're trying to tell us with this thread or if you have a proposal for what to do? —Justin (koavf)❤T☮C☺M☯ 05:48, 9 October 2024 (UTC)

Right, let's get to the point. The first, tables are different because it represents intransitive and transitive verbs, whereas ორომს (oroms) is bitransitive (they are conjugated for both the subject and the object). It's irregular, that's why it's been insterted by hand. I tried to create a Laz conjugation table for the template so people could see what the conjugation looks like, but I failed. I couldn't figure out how to represent tenses, which to include and which to not, how to determine root, preverbs and so on. I think the template page needs to be deleted until someone with more experience with Wiktionary templates can create a better script. Gubazes (talk) 13:34, 16 October 2024 (UTC)

Pannonian Rusyn alphabetical order

The current alphabetical order on Pannonian Rusyn (in Category:Pannonian Rusyn lemmas and so on) is wrong. I've copied the correct one into T:list:Cyrillic script letters/rsk, and I can also confirm it's correct because it's the one used by the 2010 dictionary (T:R:rsk:RSS) which I use as my main reference, and publications from the 70s are listed on the Wikipedia page which state the standardized orthography. Can someone more technologically savvy than myself fix the order? Thanks. Insaneguy1083 (talk) 09:57, 9 October 2024 (UTC)

@Insaneguy1083: Done: diff. It might take a while for everything to update itself to the new order. — Vorziblix (talk · contribs) 21:29, 9 October 2024 (UTC)

Thanks! Insaneguy1083 (talk) 21:32, 9 October 2024 (UTC)

@Vorziblix: actually, I think you did it wrong? Г and Ґ are treated as separate letters, as are И and Ї and Е and Є. They're not meant to be collated together. Insaneguy1083 (talk) 21:35, 9 October 2024 (UTC)

@Insaneguy1083: They are not collated as if they are the same letter—Ґ will always come after Г, and so forth. The sorting itself should be correct. Unfortunately the headings in the category pages will treat them as the same letter, but there’s no way around that—it’s the same situation we have in Ukrainian, etc. — Vorziblix (talk · contribs) 21:42, 9 October 2024 (UTC)

@Vorziblix: Hmm. Curious. Well, thanks a lot for updating the sorting anyway. If there's any updates on being able to separate Г and Ґ etc. in Ukrainian/Carpathian Rusyn, do let me know. Insaneguy1083 (talk) 21:49, 9 October 2024 (UTC)

There is a way around that these days - we have a gadget for this very purpose. — SURJECTION ^{/ T / C / L /} 19:23, 13 October 2024 (UTC)

how do I restore the copy-paste function to the edit window? (dvorak keyboard)

This changed just recently. I assume it's a wiktionary thing, because control-x, c and v for 'cut', 'copy' and 'paste' still work properly on this page, in the url window, and in edit windows on WP.

Currently, in the edit window of a wikt article, if I hit control-x I get bold formatting, with control-c I get italic, and with control-v I get superscript. Presumably this has something to do with me using a dvorak keyboard (dvorak x and c correspond to qwerty b and i), but other commands are not affected. E.g. control-z and -y are still 'undo' and 'redo', despite corresponding to the qwerty keys for t and /. Also, as noted, this page is not affected: All keys work properly right now in this edit window.

Can I do something with my css to override this behaviour? kwami (talk) 02:12, 10 October 2024 (UTC)

Which skin are you using? —Justin (koavf)❤T☮C☺M☯ 05:42, 10 October 2024 (UTC)

Vector 2022. I just switched to Vector legacy, and the behaviour is the same. kwami (talk) 06:26, 10 October 2024 (UTC)

The same thing is now happening on WP, so I'll ask there as well.

BTW, it occurs here if I edit the thread, but not if I 'respond' to a comment, opening a new window. kwami (talk) 00:13, 14 October 2024 (UTC)

Update: On WP they said that the patch that broke this has been reverted, and will be going out on thursday. Meanwhile, for anyone reading, the syntax highlighter breaks this function and can be used as a temp fix. kwami (talk) 01:28, 14 October 2024 (UTC)

Template:Photo_montage from Wikipedia

Hi all! I've been adding photos to plant family name definitions, and I'd love to be able to use the photo montage template from Wikipedia; it'd be ideal to show more of the taxon's range of diversity, rather than just the type species, and this would be much faster than creating and uploading an individual collage image for each family.

Is there any equivalent template on Wiktionary, something that'll take a few Commons images and arrange them in the space of one thumbnail? If that doesn't already exist here, is there any reason I can't or shouldn't just copy and paste the module code from Wiki -- citing the source, of course? Can templates be ported that easily? ("That's not how any of this works" is an extremely valid answer, especially seeing as I've never written a Mediawiki template before! I'm willing to learn, though.)

Thanks for your time. --Photosynthetic430 (talk) 18:56, 11 October 2024 (UTC)

@Photosynthetic430 you're more than welcome to give it a go. As this template is Lua-based, you'd need to copy w:Module:photo montage too. That module does not appear to have any dependencies, so it should copy across cleanly. This, that and the other (talk) 03:20, 14 October 2024 (UTC)

On it, then! I'll report back if it works, haha. -- Photosynthetic430 (talk) 20:52, 14 October 2024 (UTC)

Looks like it works! Now to finish removing the 'pedia-specific bits of the documentation. -- Photosynthetic430 (talk) 21:22, 14 October 2024 (UTC)

Old English category TOCs are missing thorn

In e.g. Category:Old English lemmas, the TOC is "A B C... Z", "aa... ba... ca... ... zz", with no "þ" AFAICT, so it's not obvious how to navigate to where the entries starting with thorn are. In fact, trying to manually change the URL to reach them, I notice that they aren't sorted under either thorn or th. I eventually tracked down that they, and eth, are sorted after tz; whether this makes sense I don't know, but it'd be useful to add to the TOC a thorn anchor pointing to where they are. (I have forgotten offhand where the TOC is generated from.) - -sche (discuss) 00:50, 13 October 2024 (UTC)

@-sche I think you have to make {{ang-categoryTOC/full}}, noting that {{ang-categoryTOC}} exists for categories with between 200 and 2500 entries. We could also do with {{is-categoryTOC/full}}. This, that and the other (talk) 04:37, 17 October 2024 (UTC)

Functioning French Wiktionary extension for French Firefox?

Is there a working French lookup extension for French Firefox? Ineuw (talk) 04:33, 13 October 2024 (UTC)

@Ineuw: You click onto the loupe in your search bar when on the French Wiktionary mainpage, click its icon for “adding French Wiktionary”, and Bob’s your uncle. Ctrl + K focuses the search bar. Fay Freak (talk) 09:01, 15 October 2024 (UTC)

How to write Babel language boxes?

I've listed myself as mzs-1 on my user page, but the message for that (i.e. "This user has basic knowledge" blah blah blah) is in English. Where can I go to write these messages for Macanese? Insaneguy1083 (talk) 10:07, 13 October 2024 (UTC)

They are known as infoboxes or userboxes. Look at my collection of infoboxes and if you have questions, post back here.Ineuw (talk) 18:28, 13 October 2024 (UTC)

Insert code like:

{{#babel:en|pt-3|mzs-1|de-1}}

etc. Let me know if that's confusing. —Justin (koavf)❤T☮C☺M☯ 18:33, 13 October 2024 (UTC)

I already did that. That's not the issue - the issue is that the message is in English, because no one's written a personalized one for Macanese yet, and I was wondering where I could do that. Insaneguy1083 (talk) 18:35, 13 October 2024 (UTC)

Oh, I see. translatewiki: is where these messages are translated. —Justin (koavf)❤T☮C☺M☯ 18:36, 13 October 2024 (UTC)

Bad Wikipedia links generated by Template:label

While going through WT:Todo/Lists/Broken links to Wikipedia, I noticed a number under Aragonese. These are governed by Module:labels/data/lang/an, and I saw that the bad links were only from those labels that had { } tables in their Wikipedia parameter. From the documentation, I would have expected these to generate a link to the first of the values in the list:

labels["Belsetán"] = {

Wikipedia = {"es:Aragonés belsetano", "Bielsa"},

regional_categories = true,

should link to w:es:Aragonés belsetano. Instead it links to w:Belsetán- a behavior the documentation says should happen when Wikipedia = true

Am I missing something, or is this an undocumented bug/feature? (I should add that the linking on the category pages such as Category:Belsetán Aragonese seems to work as described, so something would be lost by simplifying it to :Wikipedia = "es:Aragonés belsetano"},). Chuck Entz (talk) 21:41, 14 October 2024 (UTC)

This sounds like a bug. I'll take a look. Benwing2 (talk) 22:17, 14 October 2024 (UTC)

Feature request: have QQ remove extraneous spaces

Fresh out of QQ (but with underlining added), a cite often looks like:

• 2016 April 28, Andrew Picard, Myk Habets, Theology and the Experience of Disability: Interdisciplinary Perspectives from Voices Down Under, Routledge, →ISBN, page 51:

  ... the saltland for its dwelling place ? It scorns the tumult of the city ; it does not hear the shouts of the driver . It ranges the mountains as its pasture , and it searches after every green thing . ( Job 39 : 5-8 ) Yahweh assigns […]

Could QQ be made slightly smarter, to remove the extraneous spaces? (This has been suggested before.) - -sche (discuss) 23:13, 15 October 2024 (UTC)

Cat:Russian present adverbial participles and Cat:Russian past adverbial participles

These terms, such as татуируя (tatuiruja), should be in Cat:Russian non-lemma forms but are not for some reason. I note that Russian present active/passive participles do appear to be properly categorised. Can anyone advise? This, that and the other (talk) 06:02, 16 October 2024 (UTC)

Is it really as simple as this? I searched module space for the singular form (mod:"present passive participle") but I guess I should have looked for the plural. This, that and the other (talk) 06:35, 16 October 2024 (UTC)

Yeah that should be all you have to do. Benwing2 (talk) 05:45, 17 October 2024 (UTC)

Request: templates to thesaurus and appendix

I wish to request new templates for creating links to thesaurus and appendices more easily. similarly to the templates such as {{temp}} (creates a link to templates) and {{w}} (to Wikipedia), these should exist so that we do not need to tediously type the whole link. examples below:

{{thes|en|good}} gives [[Thesaurus:good#English]]

{{snowclone|en|X with a capital Y}} gives [[Appendix:Snowclones/X with a capital Y#English]]

there are likely other usecases that I haven't thought about, please feel free to reply with some. Juwan (talk) 08:27, 19 October 2024 (UTC)

Is there a reason why these need language parameters? I don't know that we have a lot of multilingual appendices or thesaurus entries... —Justin (koavf)❤T☮C☺M☯ 12:01, 19 October 2024 (UTC)

{{thes}} exists now. —Justin (koavf)❤T☮C☺M☯ 12:07, 19 October 2024 (UTC)

thank you very much! I would prefer them (at least the thesaurus one and other specialised templates) to have a language parameter, because 1. it is useful for the few entries that are multilingual, 2. it is already required that all thesaurus pages must have a language header, so why not make use of it, and 3. these can bring some help for accessbility for screen readers reading the title (if that implemented in the future). the last one is a whole can of worms to itself but I digress. Juwan (talk) 12:42, 19 October 2024 (UTC)

@JnpoJuwan why do you want this? When inlining synonyms (as we should be doing) using the {{syn}} template, you can write {{syn|en|...|Thesaurus:happy}} to get

Synonyms: ...; see also Thesaurus:happy

This, that and the other (talk) 21:54, 19 October 2024 (UTC)

@This, that and the other it's used outside of {{syn}}! a big example is under the see also header in the thesaurus namespace or when mentioning it in talks. Juwan (talk) 23:23, 19 October 2024 (UTC)

If anything, a more generic Appendix link would maybe be useful for typing, like {{ap}}. —Justin (koavf)❤T☮C☺M☯ 12:10, 19 October 2024 (UTC)

that's true! but why not both? that was just one example appendix among many that I could have chosen. Juwan (talk) 12:43, 19 October 2024 (UTC)

"/testcases/documentation" pages in CAT:E

I thought these were errors that would need to be fixed one at a time, until I noticed that there are "/testcases/" pages in CAT:Pages with module errors/hidden. Would it be possible to make all documentation pages of hidden pages also hidden? Pinging @Theknightwho. Chuck Entz (talk) 21:31, 19 October 2024 (UTC)

Peranakan Indonesian in Module:languages/data/3/p

I request to change the entry of Peranakan Indonesian as follow.

m["pea"] = { "Peranakan Indonesian", 653415, "poz-mly", "Latn", ancestors = "ms", } Xbypass (talk) 00:20, 20 October 2024 (UTC)

QQ dark mode

Trying out Vector 2022 dark mode, I notice that QQ still has a light background; could it be given a dark-mode-compatible version? - -sche (discuss) 19:26, 21 October 2024 (UTC)

@-sche:  Done Ioaxxere (talk) 03:15, 26 October 2024 (UTC)

'Wikidata item' link is moving, finally.

Hello everyone, I previously wrote on the 27th September to advise that the Wikidata item sitelink will change places in the sidebar menu, moving from the General section into the In Other Projects section. The scheduled rollout date of 04.10.2024 was delayed due to a necessary request for Mobile/MinervaNeue skin. I am happy to inform that the global rollout can now proceed and will occur later today, 22.10.2024 at 15:00 UTC-2. Please let us know if you notice any problems or bugs after this change. There should be no need for null-edits or purging cache for the changes to occur. Kind regards, -Danny Benjafield (WMDE) 11:28, 22 October 2024 (UTC)

Request to deprecate Toki Pona head templates

I wish to request that the following list of templates be deprecated and replaced with the template {{head}} in all appendix entries. toki pona, as an isolating language, does not have any type of inflection, making these templates simply redundant.

• {{tok-adj}} (adjectives)
• {{tok-adv}} (adverbs)
• {{tok-cardinal}} (cardinal numbers)
• {{tok-conj}} (conjunctions)
• {{tok-noun}} (nouns)
• {{tok-part}} (particles)
• {{tok-prep}} (prepositions)
• {{tok-pron}} (pronouns)
• {{tok-verb}} (verbs)

hope I didn't miss any, that'd be silly. Juwan (talk) 18:51, 22 October 2024 (UTC)

This is normally dealt with at WT:RFDO, but I agree that these hand-coded headword templates need to be done away with. This, that and the other (talk) 01:29, 23 October 2024 (UTC)

@This, that and the other I didn't know, sorry! moving discussion there. Juwan (talk) 08:14, 23 October 2024 (UTC)

in my opinion these could possibly be replaced by content words and particles, though i don’t know БудетЛучше (talk) 11:19, 10 November 2024 (UTC)

Undefaulting MediaWiki:Gadget-CodeLinks.js

Per MediaWiki talk:Gadget-CodeLinks.js, I'm going to undefault CodeLinks.js and save our readers some bandwidth. Anyone who still wants the Wiktionary-specific features can reenable the gadget in their preferences. Ioaxxere (talk) 04:46, 24 October 2024 (UTC)

Template:el-noun-proper

While going through Category:Greek terms in nonstandard scripts, I found a number of entries where the second positional parameter (originally the third) was a transliteration rather than the expected plural. This is because of changes (including a move and a change to a redirect target) starting a bit over a decade ago that converted things so the behavior of that parameter was completely different, but without updating a number of the entries.

There seem to be dozens of these, so I'm bringing it here to see how best to remedy this. There are well over a thousand entries in Special:WhatLinksHere/Template:el-noun-proper, so simply changing the parameter to match a minority of old uses doesn't look like a good idea- besides which, all the ones I've checked so far have a transliteration that's redundant to the automated one.

As I see it, there are two options:

1. Have a bot go through and remove all the transliterations from the second (or third?) parameter
2. Add a named parameter for the transliteration, then have a bot go through and convert the positional parameters with transliterations to the named parameter.

Either way, if the bot detects a transliteration by the presence of Latin script, there are a couple of Latin-script keywords that are used instead of the Greek-script plural for indeclinable and uncountable proper nouns- so those will have to be allowed for.

Pinging Greek editors for their opinions and insights- (Notifying Saltmarsh, Sarri.greek, Rossyxan, FocalPoint): Chuck Entz (talk) 14:59, 24 October 2024 (UTC)

@Chuck Entz hello. Could you please indicate two-three examples? This will help me in understanding the issue. FocalPoint (talk) 16:31, 24 October 2024 (UTC)

M @Chuck Entz, if you are in a hurry to clean up, either way is fine. Cat:Greek proper nouns was at my 'to do' list (1899 reviews, most of them have a plural to be added, +ipa), after I finish the pending corrections (approx.1000) at WT:LTR#plan for Medieval Greek. PS May I ask, about Categories. Sometimes Subcategory members are fully indexed at a supracategory, sometimes they are not (they are different, extra members). Is this indicated in some way? Thank you ‑‑Sarri.greek ^♫ I 16:45, 24 October 2024 (UTC)

On second check, @Chuck Entz, I need to do Category:Greek terms in nonstandard scripts by hand. The English ones are ok, The Greek are less than 180, and probably need more attention. ‑‑Sarri.greek ^♫ I 19:52, 24 October 2024 (UTC)

Want to add customer-side to customer#Derived_terms

I wanted to add customer-side to customer#Derived_terms, but this was seen as harmful. 81.217.68.78 14:36, 25 October 2024 (UTC)

Unfortunately this is a global abuse filter, managed on Meta-Wiki, and we can't do anything about it here. The best way to avoid this type of issue is to simply create an account. This, that and the other (talk) 08:17, 27 October 2024 (UTC)

Edit Blocked for African Beaked Snake Article

Hello! I was attempting to add a detailed, factual description for the African beaked snake (Rhamphiophis oxyrhynchus) but was blocked by an automated filter. My goal was to contribute additional information on the species' appearance, habitat, behavior, diet, reproduction, and interactions with humans, presented in an informative, neutral tone. I believe this content would enhance understanding of the species for readers.

If there’s a specific part that triggered the filter or needs revision, please let me know, and I’d be happy to adjust the submission accordingly. Thank you for reviewing this! PrajinExplores (talk) 17:32, 27 October 2024 (UTC)

Wiktionary is a dictionary. "[A]dditional information on the species' appearance, habitat, behavior, diet, reproduction, and interactions with humans" does not belong in a dictionary. — SURJECTION ^{/ T / C / L /} 17:43, 27 October 2024 (UTC)

@PrajinExplores: You tried to create a long article that mostly didn't match Wiktionary formatting, and it was detected by a filter that was created to prevent people from posting long articles about themselves. The fact that you were doing it without an account probably didn't help. Really, the first few lines were all that would make sense for a dictionary entry, plus a single-sentence definition line.

What I saw in the filter log wouldn't be bad as a Wikipedia article, without the first few lines (they would only make sense in a Wiktionary entry) and with the addition of references and the standard Wikipedia templates. You might want to create a user page at Wikipedia, and submit the article as a draft. Chuck Entz (talk) 23:29, 27 October 2024 (UTC)

Template:ky-adj is broken

The second parameter should not default to {{{1}}}. This should be fixed; apparently, this is not the first time this has happened. -BRAINULATOR9 (TALK) 23:20, 27 October 2024 (UTC)

@Babr: who edited it fairly recently. —Justin (koavf)❤T☮C☺M☯ 00:56, 28 October 2024 (UTC)

It looks like @Almanbet Janışev is the one who edited the relevant part of the template a month ago, and they have a history of breaking things. Chuck Entz (talk) 02:48, 28 October 2024 (UTC)

Tech News: 2024-44

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

• Later in November, the Charts extension will be deployed to the test wikis in order to help identify and fix any issue. A security review is underway to then enable deployment to pilot wikis for broader testing. You can read the October project update and see the latest documentation and examples on Beta Wikipedia.
• View all 32 community-submitted tasks that were resolved last week. For example, Pediapress.com, an external service that creates books from Wikipedia, can now use Wikimedia Maps to include existing pre-rendered infobox map images in their printed books on Wikipedia. [1]

Updates for technical contributors

• Wikis can use the Guided Tour extension to help newcomers understand how to edit. The Guided Tours extension now works with dark mode. Guided Tour maintainers can check their tours to see that nothing looks odd. They can also set emitTransitionOnStep to true to fix an old bug. They can use the new flag allowAutomaticBack to avoid back-buttons they don't want. [2]
• Administrators in the Wikimedia projects who use the Nuke Extension will notice that mass deletions done with this tool have the "Nuke" tag. This change will make reviewing and analyzing deletions performed with the tool easier. [3]

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

MediaWiki message delivery 20:56, 28 October 2024 (UTC)

Android app for Wiktionary

Hi, is there an Android app for Wiktionary? How does it work? I have been advised that there is no infrastructure for push notifications for Android apps for sister wikis and I would be interested to know more. Related: phab:T378545. Thanks! Gryllida 23:13, 29 October 2024 (UTC)

@Gryllida Others may be able to comment more, but I don't know of any mobile app for Wiktionary on any platform. Instead there is just the mobile website, which leaves a lot to be desired (but for which there are active efforts by editors like @Ioaxxere, @Surjection and others to improve its appearance). Benwing2 (talk) 05:49, 1 November 2024 (UTC)

There was a Wiktionary Android app on the Google Play store back in the day; I had it on my old phone. I think it's the one mentioned here: mw:Wiktionary Mobile. It was good enough for basic browsing but the Android UI of the app felt outdated even 10 years ago, so it's no surprise it was retired. This, that and the other (talk) 09:20, 2 November 2024 (UTC)

@Gryllida: The app English Dictionary - Offline uses Wiktionary for its data but unfortunately only covers English (the same company has versions in a couple other langauges as well). I wished for dedicated Wiktionary app as well but if no one steps up I guess I'll have to create it myself... Ioaxxere (talk) 02:46, 2 November 2024 (UTC)

Template request: Pronouns

I wonder if this would be a useful template for anyone else. for non-English languages, there should be a template where you may pass parameters and it would output a definition line regarding the pronoun, similarly to templates such as {{place}} and {{demonym-noun}}. this would be good for standardisation and harmonisation between entries and possibly helpful for categorisation.

{{pronoun|pt|1|sg}}

First-person, singular pronoun; I, me

{{pronoun|es|2|pl|f|inf}}

Informal, feminine, second-person, plural pronoun; you, you all

{{pronoun|pt|3|obj|clitic}}

Oblique, third-person, clitic pronoun; him, her, it, them

Juwan (talk) 14:56, 31 October 2024 (UTC)

@JnpoJuwan IMO this is a good idea, although I'm not sure how easy it is to automate the generation of the English-equivalent glosses. The way I imagine it, any arbitrary {{infl of}} tags could be supplied to {{pronoun}}, which would make it hard to come up with a generic algorithm to convert these tags into English-equivalent pronouns. This would be especially problematic, for example, with second-person pronouns, where English has only "you" and various dialectal plural forms (you all, you guys, y'all, yinz, etc.). For example, given the wealth of ways of saying "you" in European Portuguese (tu; archaic vós; você, vocês; o senhor, a senhora, os senhores, as senhoras; plus object variants te, ti, vos), any auto-generated English-equivalent gloss would be highly misleading. Instead you'd need a custom non-gloss definition following the output of {{pronoun}}. Japanese, among others, would be similar. Benwing2 (talk) 05:46, 1 November 2024 (UTC)

@Benwing2 I believe that the English glosses being "lossy" in detail is not a critical issue. these to me serve as a way for others to have a basic idea of what pronoun is roughly equivalent in English. all the variants of "you" in Portuguese glossed as "you" is okay, as the rest of the non-gloss serves to disambiguate what is different. this is how glosses already work in some way right now. the template having a dedicate gloss template to override the automatic gloss would be a good compromise to me. Juwan (talk) 18:50, 1 November 2024 (UTC)

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. [4]
• 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. [5]
• 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. [6]

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: [7]. 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. [8]
• 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. [9]

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. [10]
• 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. [11]

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. [12]
• 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. [13]

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. [14][15]

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%: [16]. (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: [17]. (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)