Wiktionary:Grease pit/2023/September

Alt params for Iranian Persian in Template:fa-regional
Hi @Erutuon: Could you please add alt params for Iranian Persian, the same way you did for Dari and Tajik?

The entry at could use the alt form (comma-separated).

FYI: @Sameerhameedy Anatoli T. (обсудить/вклад) 04:03, 1 September 2023 (UTC)


 * @Atitarev @Erutuon Hi, I added the parameter ir2 to fa-regional. So it should work now. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 02:57, 19 September 2023 (UTC)
 * @Sameerhameedy, @Erutuon: Thank you, applied! Anatoli T. (обсудить/вклад) 03:05, 19 September 2023 (UTC)

Template:demo
This is a more powerful version of temp demo, which avoids most of the issues related to that template by requiring that the supplied Wikicode be wrapped in. It is ported from w:Module:Demo, which I've cleaned up to use Module:parameters and generally avoid some of the nastiness of the original code (surprisingly, Wikipedia module code is generally of lower quality than Wiktionary module code despite the greater number of editors). See the documentation for some examples. Benwing2 (talk) 06:32, 1 September 2023 (UTC)

the wide-eyed smiley face
Is it possible to link to Unsupported titles/=) from within a synonym template? I want to add it to the synonyms list on the Unsupported titles/:) page but every way that I tried to get it in produced a Lua error (backslash, typing out "Unsupported titles", etc). Thanks, — Soap — 13:52, 1 September 2023 (UTC)
 * Well =) also exists, separately, without the "Unsupported titles" prefix (I guess it's not an unsupported title?). You can link there with . —Al-Muqanna المقنع (talk) 15:28, 1 September 2023 (UTC)
 * Apologies for not checking. I'd simply assumed a title could not contain an equals sign, let alone begin with one. I will nominate the page I created for speedy deletion since it is both unnecessary and confusing (the title makes it look like the person is at the regular =) page.)
 * However, the trick you showed me for how to paste the link does not work inside a template, so my question remains ... is it possible to make a link to =) from within a template, particularly the synonym template used on Unsupported titles/:)? Thanks, — Soap — 16:19, 1 September 2023 (UTC)
 * Never mind, I see it now. I was pasting the code literally from within the edit window and you meant for me to paste it from the live page view. Again, thanks. This should be resolved now. — Soap — 16:21, 1 September 2023 (UTC)

em space
The em space is displayed incorrectly inside certain templates (such as ux), see e.g.  senses 2.1 and 2.3. Einstein2 (talk) 18:14, 1 September 2023 (UTC)
 * This is being caused by some weird processing done in  in Module:links. Benwing2 (talk) 03:28, 2 September 2023 (UTC)
 * @Benwing2 @Einstein2 It was a bug in  in Module:utilities, which I changed yesterday to reduce the size of the data by removing the   and   from all the listed entities. For some reason,   was listed before , so it was wrongly picking up   followed by a 1/3 em-space  when it tried to match  . I've fixed this individual issue, but I'll go over the data today to make sure shortner names are always listed before longer ones. Theknightwho (talk) 13:07, 2 September 2023 (UTC)
 * I've resorted the data so that shorter names always come before longer ones, which should prevent any issues like this happening in future. Theknightwho (talk) 13:46, 2 September 2023 (UTC)

Wrong Order: Xiaoping Deng; Haishenwai Zedong Mao
Wrong Order: Xiaoping Deng; Haishenwai Zedong Mao --Geographyinitiative (talk) 21:00, 1 September 2023 (UTC)


 * @Geographyinitiative ?? This is a very cryptic post. This, that and the other (talk) 00:10, 2 September 2023 (UTC)


 * Pardon me! Two citations on these two pages have the names of two prominent figures written with surname last when English Wikipedia's article titles for those two personage are written with surname first. This is not the only two instances of this problem. I have notified - see . I will start adding additional examples of wrong placement of surname after given name here as I see them- here's one: (Binyan Liu for Liu Binyan),  (Li-shih Lu for Lu Li-shih- and the Chinese characters included from the article are deleted),   (Yu-ti Jen for Jen Yu-ti), Muling (Il-sung Kim for Kim Il-sung),  (Aizhu Chen for Chen Aizhu),  (Tê-kʻun Chêng for Chêng Tê-kʻun),  (Zongxu Zou for Zou Zongxu). The problem is so bad and so pervasive, I don't think it can ever be fully corrected, even if I worked on it manually for years. It is to take East Asian Names and make a joke of them. You want to talk about systemic, unintentional racism- well there you go! I'm trying my hardest to be polite here, but this is going to be a black mark on Wiktionary for years, so it's really painful for me because the burden is going to fall on me to correct something that shouldn't have to be corrected. All because what? And in the mean time, while Wiktionary is being copied by other sites and leaving a bad impression on potential readers and editors, Wiktionary's editor core does not care. "烏煙瘴氣. This site will always be a kludge. Let it 自生自滅." Wyang If I came on a website and saw "Zedong Mao" or "Xiaoping Deng", I'm telling you, I wouldn't see it as reliable. I would leave the website. --Geographyinitiative (talk) 08:03, 2 September 2023 (UTC) (Modified)


 * Might be missing something but didn't you add both of the ones in the original section title (at Muling and Haishenwai)? Is this a case of deliberately bad edits to make a point? I see from your other diffs that Benwing's bot has been rearranging last and first into, but that did not introduce the error since they were incorrectly entered originally: the citation name format "Y, X" means "X Y", hence Wikipedia's CS1 guideline to enter surname-first names purely in the last param. —Al-Muqanna المقنع (talk) 10:23, 2 September 2023 (UTC)


 * Thank you for your reply. I know I may be a silly person, but this is a major, major defect and problem. Like huge. To answer your question: "Deng" is considered a "last name" even though it does not come "last". "last name" means "surname". That's the way East Asian Names work (most of the time, unless the author has Westernized). It's a simple cultural difference. --Geographyinitiative (talk) 10:27, 2 September 2023 (UTC)
 * I am well aware of how East Asian names work—Hungarian names are also natively surname-first, incidentally: I'm talking about how to enter them in a citation. —Al-Muqanna المقنع (talk) 10:28, 2 September 2023 (UTC)
 * "Deng, Xiaoping" is correct. "Deng Xiaoping" is correct. "Xiaoping Deng" is an abomination (unless the author specifically uses it that way). It ruins all cites that are written with it, or if not "ruins" we can say "culturally whitewashes". Let me know if that's not answering the question. --Geographyinitiative (talk) 10:31, 2 September 2023 (UTC)
 * My point is precisely that "Deng, Xiaoping" is not correct since it means "Xiaoping Deng". So for example Wikipedia's states, "Where the surname is usually written first—as in Chinese—or for corporate authors, simply use editor-last to include the same format as the source". They were entered incorrectly, and will need to be corrected now either way. —Al-Muqanna المقنع (talk) 10:35, 2 September 2023 (UTC)
 * "Oh there's some special parameter on Wikipedia bro, lol". That doesn't solve the problem. The surnames were in the correct order when viewed by a reader looking at the entry page (not the code itself), and now they are not. Do you contest this? Do you not think this new order hurts the reliability or trustworthiness of the cites in the eyes of readers? I am done with this conversation. Thanks for your time. --Geographyinitiative (talk) 10:39, 2 September 2023 (UTC)
 * Yes, because, like I said, "Y, X" means "X Y", not "Y X". They were incorrect originally and are still incorrect. More directly: you entered them incorrectly and are now trying to fob off the responsibility on Benwing. It has absolutely nothing to do with special parameters on Wikipedia or whatever, the Wikipedia guidelines are indications of how to produce the correct result on Wikipedia; in our case we don't need to use "last"-type parameters at all since we simply have editors etc. —Al-Muqanna المقنع (talk) 10:44, 2 September 2023 (UTC)
 * Oh wow, well I never realized that I was wrong, but now I see that I was actually making an error. I totally get this now. It was me that was doing the systemtic, unintentional racism the whole time. I have attempted to apologize to Benwing here: . I just had a mistaken understanding of how Y, X and XY worked, but now I see that the comma actually means that it's X Y. I really did not know that before. How I never realized this, I will never know- just not well educated or such. I apologize for any confusion, but my misunderstanding led me to make this mistake for years, and then when I see this problem everywhere now, I was like "uhh wtf this is bad". I will try to correct the issue manually over time. I really appreciate you laying this out for me- it's so basic and simple, but I literally just did not know I was doing it wrong. Sincerely, Thanks! --Geographyinitiative (talk) 10:54, 2 September 2023 (UTC)
 * 's interpretation of last and first is newly promulgated. I warned at the time that it would cause trouble, that there was the interpretation of 'last' and 'first' as surname and personal name.  --RichardW57m (talk) 15:13, 5 September 2023 (UTC)

Old Tupi noun template
I was messing with the Wikitionary and ended with some ideas for Old Tupi headwork templates. What do you think? @RodRabelo7 @Bageense

For nouns:
 * User:Trooper57/Template:tpw-noun - just tells if the noun is possessable or not; couldn't think of many things to add since there's no number nor gender
 * User:Trooper57/Template:tpw-pluri noun - for pluriform nouns; maybe merge it with the first
 * User:Trooper57/Sandbox4 - some usage examples

Trooper57 (talk) 05:06, 2 September 2023 (UTC)


 * I don't use Wiktionary often, so I can't tell whether your templates are good, or whether they were made according to some standard. In any case, it's nice to see another wikipedian who studies the Tupi language! See you around. Bageense (talk) 14:14, 2 September 2023 (UTC)

Adding a Sanskrit, Indo-Iranian, and Indo-Aryan root category for affix/template
@Benwing @Theknightwho (Since you've updated Module:affix/templates lately) This request was already raised here, but we should have an equivalent to as, , and. Right now the module is locked, but this should be easy enough to implement and I could suggest or write the Lua for it if I had permissions. Dragonoid76 (talk) 10:13, 2 September 2023 (UTC)


 * @Dragonoid76 I don't think we need a bunch of lang-specific templates like this; we need one general template that takes a language code. In fact we have derivsee for this purpose already. IMO PIE root see should be removed and replaced with calls to derivsee. Benwing2 (talk) 13:27, 2 September 2023 (UTC)
 * @Benwing2 how would one call to see, for instance, Category:Terms derived from the Sanskrit root भृ
 * Could you add this to the documentation of if this is the intended way of using it. Dragonoid76 (talk) 19:17, 2 September 2023 (UTC)

Category columns broken
Something seems to be broken with columns on category pages. See WT:RTINE which is displaying as a single column. -- Sokkjō 10:23, 3 September 2023 (UTC)
 * Hmm... CAT:English lemmas is still two columns as expected, and I know categories with fewer than some number of entries never get split into columns, e.g. Category:English postpositions is one column and was in 2021, and RTINE was also one column already back in 2021. (I see that it was two columns back in 2015, when it had fewer entries than in does now, but perhaps the threshold for when to split off a second column was raised between 2015 and 2021.) Or did it still have two columns recently for you? Perhaps the length of the entries' names and the width of one's screen cause different numbers of columns to be displayed on different devices? - -sche (discuss) 17:29, 3 September 2023 (UTC)
 * It's very resent but it sems to have been fixed now. 🤷 -- Sokkjō 18:32, 3 September 2023 (UTC)
 * Mysterious! RTINE is still showing up as one column for me (even if I null-edit some of the templates and then the category page itself). - -sche (discuss) 18:40, 3 September 2023 (UTC)
 * Caching, I guess. -- Sokkjō 20:06, 3 September 2023 (UTC)
 * Going through Category:Templates by language, I notice that the single-column format is more common at lower levels in the tree. It might be something as simple as having subcategories on the same page as the categories. Chuck Entz (talk) 22:19, 3 September 2023 (UTC)
 * Votes are weirdly placed on my watchlist page now too. I'm thinking this is related to 's . -- Sokkjō 00:08, 4 September 2023 (UTC)
 * This is presumably to do with the width of the box titled "Newest pages ordered by last category link update" reducing the available space for columns. I made an experimental edit to this category page; can you check it now, ? If that solves the problem we would need to look at incorporating - into the output of auto cat on category pages with that wide box.
 * The weird placement of the watchlist vote box can be resolved by a similar fix. It's possible that my edits to Common.css broke this, but I did check carefully where the class names were in use across all namespaces. This, that and the other (talk) 02:20, 4 September 2023 (UTC)
 * I just checked; the watchlist votes box is difficult to move. What exactly has changed in the way it looks for you, ? This, that and the other (talk) 02:23, 4 September 2023 (UTC)
 * , is WT:RTINE still a single column for you?, the votes box is being moved to the left of the "Edit your list of watched pages", but maybe it's been that way for while? -- Sokkjō 02:58, 4 September 2023 (UTC)
 * Adding - has caused RTINE to be two columns for me. - -sche (discuss) 19:54, 4 September 2023 (UTC)
 * I think the solution here is to incorporate the functionality of - into auto cat and make the "Newest pages ordered by last category link update" box collapsible, collapsed by default:
 * {| class="wikitable mw-collapsible mw-collapsed"

! Newest and oldest pages
 * contents go here!
 * }
 * This, that and the other (talk) 12:18, 6 September 2023 (UTC)
 * I wouldn't be opposed to collapsing that, but I also think css in css is too wide. Maybe css with css. -- Sokkjō 18:10, 6 September 2023 (UTC)
 * Hopefully ✅ on all category pages now. This, that and the other (talk) 00:41, 27 September 2023 (UTC)
 * Hopefully ✅ on all category pages now. This, that and the other (talk) 00:41, 27 September 2023 (UTC)

Could the onom template be made to link to Appendix:Glossary when imitative is specified as the replacement display word?
Ideally, I would like this template, as currently used on pages such as and, to link to Appendix:Glossary when imitative is the word we display. Currently it just displays an unclickable plaintext word. If that is not possible or not convenient, I would still think it an improvement if the template always linked to Appendix:Glossary rather than linking to that only when the title= param is omitted. Both the template and the module it invokes are protected so I can't edit them (and likely wouldn't know what to do, anyway). Please help. Best regards, — Soap — 13:18, 3 September 2023 (UTC)
 * A comment: Dutch plas currently uses the display word imitation instead of imitative, and there are probably others like this ... this could also link to the "imitative" glossary entry if possible, but otherwise I still think a link to #onomatopoeic is better than an unclickable word. — Soap — 13:20, 3 September 2023 (UTC)
 * Also it seems that any of use of the title= argument breaks the link, even if the title given is onomatopoeic. — Soap — 08:54, 5 September 2023 (UTC)

Adding a function to
Would it be possible to add a parameter that prints the text "Rhyming phrase" to the beginning of lit, decapitalizes "literally", and adds the page to the appropriate language's category "rhyming phrases"? Vininn126 (talk) 14:30, 3 September 2023 (UTC)
 * Huh? No. Chuck Entz (talk) 14:49, 3 September 2023 (UTC)
 * Why not? Vininn126 (talk) 15:21, 3 September 2023 (UTC)
 * Why not just a separate template for rhyming phrases? —Al-Muqanna المقنع (talk) 14:57, 3 September 2023 (UTC)
 * I suppose. My reasoning for this is that rhyming phrases will necessarily always be with... well multiword terms, which frequently have, so having a parameter would reduce keystrokes. Vininn126 (talk) 15:28, 3 September 2023 (UTC)
 * But it's also a specific case that doesn't interact with what lit does by itself and is irrelevant for most of its invocations, so it'd be weird from a code perspective to bolt on that functionality here instead of just building a separate template with a lit param (which lit's own documentation recommends as a preferred alternative). —Al-Muqanna المقنع (talk) 16:19, 3 September 2023 (UTC)
 * That's an interesting solution, to be honest. I also appreciate the explanation as opposed to the dismissal Chuck gave... Vininn126 (talk) 16:21, 3 September 2023 (UTC)

Template:surname
At the old version of Tarren, there was some bullshit code producing crap. Any other occurrences of this??? Jin and Tonik (talk) 16:32, 3 September 2023 (UTC)
 * Seems like bullshit user input and not bullshit code. —Al-Muqanna المقنع (talk) 16:47, 3 September 2023 (UTC)

Unhide coordinate terms
I have repeatedly had the experience of looking for a list coordinate terms to add another term, in an entry where I knew I'd previously added such a list, but I can't find it even when Ctrl+F-ing terms I know I entered ... and only upon clicking "edit" to (re)add coordinate terms to the entry do I (if the entry is short) notice cot is present, just hidden with an evidently-easily-missed toggle. I can also use the toggle in the sidebar to opt-in to seeing them in general for the duration of one login from one browser, but I posit that if even I — a user familiar with Wiktionary and our toggles and who is specifically looking for this info which I know exists — miss the existence of the hidden list and its tiny toggle, the odds of lay readers who don't even know it's present figuring out to toggle it into existence (either on a specific entry, or through the main "show semantic relations" toggle tucked away in the sidebar) seem very low, meaning that in practice, we may as well not include the info. I sometimes move terms back to ====Coordinate terms==== sections even though I prefer them being next to the relevant sense using cot, because ====Coordinate terms==== is visible to readers whereas cot isn't. I suggest we make semantic relations visible to users by default, and make hiding them the opt-in behaviour people can choose, rather than having them hidden by default and having seeing them or knowing they exist as the opt-in option that only proficient users know to look for. - -sche (discuss) 18:08, 3 September 2023 (UTC)


 * Yes, I strongly agree with this. The one I really, really don't understand is alti (in-line alt forms) being hidden by default as well, which actively makes me not use it. There's no reason why synonyms should be shown by default but alt forms should not. Theknightwho (talk) 18:30, 3 September 2023 (UTC)
 * I strongly agree as well. I don’t think any semantic relation should be hidden. (I also didn’t even know that existed either) AG202 (talk) 18:33, 3 September 2023 (UTC)
 * making all semantic relations visible by default. —Al-Muqanna المقنع (talk) 00:13, 4 September 2023 (UTC)
 * Why is this being discussed in GP rather than BP?
 * If this has to do with defaults, the important thing would be the effect of hiding or not hiding on unregistered users and newbies, others having the ability and knowledge to use the sidebar toggles. I haven't seen the benefits or costs of this expressed in terms of such users. If our main need is to attract and keep users who happen upon Wiktionary, it would be good to imagine what the effect would be of, say, three additional lines (out of syns, ants, hypos, hypers, coords, which are just the top 5) between each pair of consecutive definitions. DCDuring (talk) 00:39, 4 September 2023 (UTC)
 * I don't think these are anywhere near as common as that, to be fair; it certainly won't be 3 new lines per definition. In general, though, -sche already laid out their proposal specifically in terms of lay users, and to my mind it's unambiguously better not to hide information from users by default. I've also found that when these lines are present in larger entries they actually help to break up long lists of senses. So I don't see the benefits of the current practice from an ordinary-user perspective as outweighing the costs at all. —Al-Muqanna المقنع (talk) 00:48, 4 September 2023 (UTC)
 * Our goal is to have as many of these as possible. The situation will be different in 3 or 10 years. DCDuring (talk) 16:36, 4 September 2023 (UTC)
 * I'd prefer to keep hypernyms and hyponyms hidden, but syn/ant/cot should be visible by default for sure. I'd even suggest to remove the show/hide toggle for them; isn't it just clutter? Does anyone currently use it to hide synonyms, which are shown by default? This, that and the other (talk) 02:25, 4 September 2023 (UTC)
 * I use them usually. DCDuring (talk) 16:36, 4 September 2023 (UTC)
 * Agreed on the hypernyms and hyponyms: hypernyms, especially, can become be truly massive. While it's true that they should, in such cases, be under their own header, there are too many contributors whose sole purpose in life is to scour the dictionary for such things and no easy way to catch the progression from a few to planetary size in a timely manner. Chuck Entz (talk) 02:59, 4 September 2023 (UTC)
 * FWIW, to your last point: independent of whether we hide or unhide them, it should be possible to make hyper (and any of the others) add a tracking link or tracking category any time more than N hypernyms are set, so we could easily monitor. (Perhaps the fact that ====Hypernyms==== sections and/or hypernyms lines lend themselves so easily to so many users adding such low-value crap is a sign we should reconsider how useful they are to begin with. But that's a separate discussion.) - -sche (discuss) 05:29, 4 September 2023 (UTC)
 * In my experience people also fail to distinguish properly between holonyms and hypernyms, and meronyms and hyponyms. I have not come across any enormous inline hyper/hyponym lists yet, though; there are enormous inline synonym lists on many Latin entries but the current practice does nothing to help that. —Al-Muqanna المقنع (talk) 09:59, 4 September 2023 (UTC)
 * It's just a matter of time. Once we didn't have many cognates in any etymologies. DCDuring (talk) 16:36, 4 September 2023 (UTC)


 * OK, I tried to make coordinate terms and alt forms visible by default, but it doesn't seem to have worked(?). (BTW are all of MediaWiki:Gadget-VisibilityToggles.js, MediaWiki:Gadget-visibilityToggling.js and MediaWiki:Gadget-defaultVisibilityToggles.js still used and non-redundant or could any be consolidated?) - -sche (discuss) 10:10, 5 September 2023 (UTC)
 * Works for me (now anyway). —Al-Muqanna المقنع (talk) 14:33, 5 September 2023 (UTC)
 * MediaWiki:Gadget-visibilityToggling.js is the old version and isn't a gadget anymore ( isn't anywhere in MediaWiki:Gadgets-definition) and isn't used by any user (search for ). Pinging User:This, that and the other, who did an experiment making the script a no-op. — Eru·tuon 00:07, 7 September 2023 (UTC)
 * yes, I was just being cautious. It can probably be deleted. This, that and the other (talk) 00:14, 7 September 2023 (UTC)
 * Yep, deleted. — Eru·tuon 18:46, 7 September 2023 (UTC)

Off transliteration
This works in head but for some reason templates using Module:tl-headword, can't have the translits disabled (tr=-, or any manual transliteration) when the entry is in Baybayin script. Working in Latin script entries though. I would like to request assistance on how to enable manual transliteration on tl-headword but still have automatic transliteration when left blank. Thanks! Ysrael214 (talk) 03:46, 4 September 2023 (UTC)


 * @Ysrael214 This might be due to an override-translit setting, which in general prevents manual translit from being entered; but it seems to me that - should still be respected in override-translit languages. User:Theknightwho has redone this handling from what it used to be; maybe they can look into this a bit. Benwing2 (talk) 23:55, 6 September 2023 (UTC)

MediaWiki:Common.css housekeeping
We have a long list, at MediaWiki:Common.css, of codes which are set to. We then also have separate sections for i.Deva, i.Grek.mention, i.polytonic.mention, i.Polyt.mention, .ib-comma, .ib-content i, .ib-content em, .use-with-mention i, .form-of-definition-link, and .mention i, i .mention, which do only the same thing. We could reduce the size of the .css file (which is downloaded for all users) by combining these into the main list — or at least combining i.Deva and the i.Grek/Polyt.mentions into the list of script codes, and combining the .ib and use-with-mention i and form-of and .mention i entries into a second list of non-script-code things that are also not italicized. Downside is that this would move .ib-comma away from other .ib- styles, and use-with-mention .mention away from other use-with-mention styles, etc, although since you can just use the search function to find the relevant line, I don't see this is a major problem. Should we consolidate the sections and save everyone a few bytes, or keep them where they are? (We could also consolidate a number of sections which all do nothing but .) TTO has done a good job of whittling the file down from a high of 50,000 bytes (and an average, since about 2016, of ~44,000) to 41,980; maybe with a little more work we can get it under 40k. - -sche (discuss) 20:20, 4 September 2023 (UTC)


 * @-sche I think as long as you don't change the actual display, optimizing the CSS is fine. Benwing2 (talk) 23:56, 6 September 2023 (UTC)
 * The main part of the code that can be removed is the part relating to romanization tables. As currently written, this styling is only used by a couple of pages in the Wiktionary namespace. However, there are other pages that have the same styling hard-coded as inline CSS, so some kind of solution is needed. Once that's sorted, we will definitely be able to get it under 40 KB (noting that MediaWiki minifies the CSS for delivery to users, so the effective size is much less - but it's still good to remove old cruft for our own ease-of-maintenance purposes if nothing else). This, that and the other (talk) 10:27, 7 September 2023 (UTC)

Fix MediaWiki:Gadget-DocTabs.js
After T316908 this default gadget partly broke in new Vector, displaying "Citations" tab incorrectly; in different places unpredictably; not working in the "Citations" namespace.

You need to replace with and with I tested the updated code for citations in new Vector, old Vector, Monobook and Timeless. JWBTH (talk) 21:03, 4 September 2023 (UTC)


 * Done! Thanks for the assistance. This, that and the other (talk) 12:27, 6 September 2023 (UTC)

Multiple references to same work
Hi everyone. Does anyone know if and how I can reference multiple pages of the same book using without creating a whole new entry in the   section? To explain: if I use this kind of syntax I get with the  section looking like this Is there a way to reference multiple pages (or page ranges) in the same entry, while avoiding repetition of the book info? —— GianWiki (talk) 10:06, 6 September 2023 (UTC)
 * [piece of information 1][1]
 * [piece of information 2][1][2]
 * 1) ↑ 1.0 1.1 Author Name (0000), Work Title, page 5
 * 2) ^ Author Name (0000), Work Title, page 55


 * @GianWiki Not that I know of. I'm planning on revamping the citation templates to use the quotation module backend, which is much more comprehensive, and as part of that we can maybe talk about how to fix this issue (although we need a standard for how to do this; either to repeat the author and year, or just the author, or write ibid. or something; not sure what the current bibliographic standards call for). Benwing2 (talk) 23:53, 6 September 2023 (UTC)
 * We could adopt/adapt w:Template:rp from Wikipedia. --RichardW57m (talk) 11:37, 7 September 2023 (UTC)

Visually distinguishing between ellipsis with and without tooltips
Apparently both and  allow tooltips, but offer no visual distinction unless one happens to move the cursor over the dots and notice something flashing momentarily. As it is now, the tooltip may as well just have inside jokes for in-the-know contributors. The persons who might most need the tooltips are also those least likely to discover them.

Is there a useful, but not too distracting way of visually distinguishing an ellipsis with tooltip and one without? Could different brackets do it? would it be possible to momentarily flash the tooltip content when the page loads? As the flash would become distracting and even annoying, it could be offered as the default for unregistered users and be turned off for all others or turned off by a gadget. Would some kind of not-too-subtle color difference work? Like blue for a tooltip-present ellipsis, which would take advantage of the fact that most users of wikis are aware of the meaning of blue links. DCDuring (talk) 12:38, 6 September 2023 (UTC)


 * @DCDuring What is the tooltip used for? I note that there’s an “other forms” option for nb... that allows you to list a bunch of alternative forms in a way that’s in a tooltip, but that seems like a terrible idea because you can’t see tooltips at all on mobile. As I’m on my phone right now, I’d have no idea if it was there. Theknightwho (talk) 13:21, 6 September 2023 (UTC)
 * It is used for various things now, especially in citations. The mobile interface has a lot more problems than this. Perhaps tooltips should be suppressed on mobile until the mobile interface is more comprehensively improved. I don't see why the PC interface should be limited to what looks good on the mobile interface. DCDuring (talk) 14:21, 6 September 2023 (UTC)
 * Every time I've seen people use the tooltip it's been for the text that's being elided (usually in long titles). Almost by definition in such cases I don't think it's relevant for ordinary readers—if it is, it shouldn't have been elided. —Al-Muqanna المقنع (talk) 13:29, 6 September 2023 (UTC)
 * What you describe is the default suppression of subtitles, publishers addresses, etc. In the passage text of a citation it can be handy to have more of the context available than what should be displayed routinely. A user of our entries may well be curious or skeptical about our decisions about what to elide. Should we force them to search the web, especially in those cases where we don't provide a pageurl? DCDuring (talk) 14:21, 6 September 2023 (UTC)
 * If no URL is provided then they have to search the web anyway. In general I believe citations should be limited to the info that is needed to easily find the source provided, so (again by definition) the extra material should either be hidden because superfluous or not hidden to begin with. I don't think there is any real benefit to reproducing 5-line-long early modern book titles, for example, and if some editors insist on putting them somewhere in the code I doubt anything much is lost by hiding it. On the whole I don't think it would be beneficial to have this kind of extended info visible by default to any group of users. Another typical case is hiding generic subtitles such as "A Novel", "A Comedy" etc., or indeed more extended ones, and in those cases it's often easier to find info on the relevant work by searching without the subtitle. —Al-Muqanna المقنع (talk) 14:27, 6 September 2023 (UTC)

Apostrophes and quotation marks in Wikipedia links

 * When using (or “w:” in a quotation template) to link to a Wikipedia article, $⟨‘⟩$, $⟨’⟩$ and $⟨“⟩$, $⟨”⟩$ should be automatically changed (in the link, not the display) to $⟨'⟩$ and $⟨"⟩$ because Wikipedia does not use them. J3133 (talk) 14:23, 6 September 2023 (UTC)
 * . I know some people don't like curly quotes anyway but if you are using them it's annoying to have to write stuff like . —Al-Muqanna المقنع (talk) 15:54, 6 September 2023 (UTC)
 * Another useful addition for w would be to automatically handle [] (for info like author names that isn't in the source itself), since unless you enter the brackets as HTML entities it collides with the markup for URLs and makes various kinds of mess. I have seen quite a few cases where people have entered stuff like, which in a quotation template currently produces something like:  Looks OK at first blush, but if you examine it closely the URL formatting includes the left bracket and excludes the right one (especially noticeable on mobile). —Al-Muqanna المقنع (talk) 15:54, 6 September 2023 (UTC)
 * I am fine with fixing the bracket issue but I think as long as there are a lot of people opposing the use of curly quotes, we should not make it easier to enter them. The curly quote proposal feels to me a bit like a way of finessing curly quotes into quotations in absence of an actual agreement to do so. Benwing2 (talk) 23:47, 6 September 2023 (UTC)
 * Mm, that seems like an odd take, there's no consensus against curly quotes either (the most recent relevant vote showed less support for standardising to plain quotes than to curly quotes), and quite a lot of templates that already use them automatically, so it makes no sense to arbitrarily make it slightly harder to enter them specifically in Wikipedia links. To the extent there is a consensus it is that people are free to use either, so they should be assisted in doing so. —Al-Muqanna المقنع (talk) 23:51, 6 September 2023 (UTC)
 * (Actually, worth noting that the vote above is about Wiktionary policy pages and I just remembered that WT:QUOTE explicitly prescribes using the same style as the original source in quotations anyway: "As a rule of thumb, the style of quotation marks and apostrophes (straight " or curly “) used in the original should always be used on Wiktionary." And the quote templates already generate curly quotes automatically for chapter/article titles! —Al-Muqanna المقنع (talk) 00:02, 7 September 2023 (UTC))
 * @Al-Muqanna The  inside quotation templates is an odd one, and I suspect it's down to some module parsing the wikitext and placing HTML after the first   it encounters, meaning that the third   is treated as plaintext. I'm working on something that can parse wikitext links, and it's able to handle these without issue, so it's possibly going to be easiest to wait until that's rolled out since the logic of when a closing   should be included in the alt text is not particularly straightforward to achieve with conventional Lua patterns. @Benwing2 Just FYI, this is a good example of the kind of issue that will be simpler to fix efficiently with the postprocessing parser, since it's simply a case of making sure the wikitext alt text handlers are correct, and it creates no additional work if it's not relevant to an input. Theknightwho (talk) 12:03, 22 September 2023 (UTC)

Persian-script Balti is broken
As part of a reworking of Persian, Module:fa-translit was moved to a new name yesterday. Nothing wrong with that- but... Balti uses Module:fa-translit for transliteration of its Persian-script forms and now all of them are either in CAT:E with module errors or will be the next time they're edited and the transclusion updates. Can someone please figure out which module it should use and update the data modules so that we get transliteration instead of module errors? . Chuck Entz (talk) 15:09, 6 September 2023 (UTC)


 * there's not a lot of documentation of Balti, or how its alphabet works. But based on this paper from the Institute of Central Indian Languages Balti should probably use Module:ur-translit. Also the old Persian transliteration module is not included in any templates, so the change needs to be made by a template editor or an administrator at Module:languages. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 17:30, 6 September 2023 (UTC)
 * @Chuck Entz @Sameerhameedy I changed the relevant language module to use the new name, until we are in agreement to change its translit scheme. Benwing2 (talk) 23:50, 6 September 2023 (UTC)

names categories
There's been a lot of discussion over the years of the oddities that result from certain names being in one top-level category while others are in another top-level category that uses a completely different naming system ("en:" vs "English"). E.g. Vadyms top-level category is Category:Names by language, whereas Sergeis top-level category is Category:Names, while Vladimir is in both. Following lengthy RFM discussions linked at Module talk:names, excarnateSojourner wrote some code to move things like Sergei from "Category:en:Russian male given names" to "Category:English male given names transliterated from Russian" (compare "Category:English male given names from Russian"), as part of having one top-level category with one naming scheme, but we need to make sure autocat and the rest of out infrastructure can handle the new names: what needs to be updated? - -sche (discuss) 04:59, 7 September 2023 (UTC)


 * @-sche I may be able to work on this eventually but there's a lot going on now, my apologies. Benwing2 (talk) 21:20, 23 September 2023 (UTC)

bot request: move Taos entries
Can someone move all the Taos entries which use ’ (curly quote) to ʼ (modifier letter apostrophe) per WT:RFM? - -sche (discuss) 06:04, 7 September 2023 (UTC)

Accelerated plural links in wrong colour
When I create a new (English) entry, the accelerated plural from WT:ACCEL shows as a blue link, like an existing entry, even though the entry does not in fact exist. They used to be green until recently. Note I'm using some old stylesheet like Monobook or something. Can anyone repro or fix? Equinox ◑ 12:34, 7 September 2023 (UTC)
 * The styling for such links was recently moved; perhaps some old skin missed being updated to use (or for some reason doesn't play well with) wherever they're now located? Or it's a temporary caching issue? . FWIW it works as expected for me; when the target page doesn't exist, the links are green when I'm logged in, and red when I'm logged out, until they're created, at which point they turn blue. - -sche (discuss) 15:23, 7 September 2023 (UTC)


 * I can provide Google Chrome "Inspector" CSS info if someone tells me what they need. Equinox ◑ 17:19, 7 September 2023 (UTC)
 * @Equinox it's because you're loading the WT:ACCEL gadget in a very ancient way, via a line on User:Equinox/monobook.js. The modern way (since 2011 or so) has been to go to Special:Preferences, Gadgets tab, and turn it on there. It seems that there are still a substantial number of users loading WT:ACCEL in this way; most are old users who are no longer active, but I will need to think of something to help those who are still active, like yourself. This, that and the other (talk) 22:47, 7 September 2023 (UTC)
 * This should be resolved now with no action required on your part (or anyone else's). The User:Conrad.Irwin/creation.js script now turns on the WT:ACCEL gadget for you. This, that and the other (talk) 23:33, 7 September 2023 (UTC)


 * "resolved with no action required on your part" is called backward compatibility and thank you for doing it. Haven't tested yet, but I bet I'm about 90% of your usership by edit volume. Equinox ◑ 02:40, 8 September 2023 (UTC)

template:trans-see
The former default, which is referred to in the documentation does not work, as one of the two examples given shows, so that one must type the same term in twice. Why? DCDuring (talk) 17:34, 7 September 2023 (UTC)
 * It was a bug, which I’ve now fixed. Theknightwho (talk) 18:01, 7 September 2023 (UTC)

Gadgets running on mobile for the first time
Apparently all gadgets run by default on the mobile skin of Wiktionary now (en.m.wiktionary.org), whereas they used to only run on the desktop version unless  or   was specified in MediaWiki:Gadgets-definition. (See this version of the page for the gadgets that used to be enabled on mobile.) If you notice one of your installed gadgets doing something bizarre on mobile, it can be disabled on mobile by an interface administrator with an edit like this until someone can figure out how to make it behave correctly. — Eru·tuon 22:18, 7 September 2023 (UTC)


 * @Jon (WMF) I am pinging you so you are aware of the chaos that this change has caused for us. You are a software engineer (as am I), so you should know to (a) be careful, (b) communicate breaking changes to your audience before making them. Apparently you did neither of these things. Can you elaborate why? Benwing2 (talk) 07:34, 8 September 2023 (UTC)
 * To be fair to the WMF folks, this was communicated three times in Wikimedia Tech News/2023: first in issue 2023-06 from February as an advance warning, and again in issues 2023-26 and 2023-27 from July to advise of the impending rollout. IMHO we should get Tech News delivered here to the Grease Pit, as this newsletter is WMF's main communication channel for breaking changes.
 * And yes, this has actually been in effect since July. I'm somewhat perplexed as to why others are only just noticing it. This, that and the other (talk) 12:42, 8 September 2023 (UTC)
 * All right, my apologies. I think my frustration stems partly from the general lack of response of the Wikimedia developers to Wiktionary-specific concerns, and the tendency to close as "will not fix" any Phabricator tickets we file. Yes, Wiktionary is smaller than Wikipedia but not that small. Benwing2 (talk) 21:57, 8 September 2023 (UTC)
 * Thanks, I looked through some of the recent Tech News on Meta-Wiki, but didn't find anything. I haven't been following them lately. I think they used to be posted in the Grease Pit at one point. [Edit: Apparently not. I just didn't have this year's page in my watchlist.] — Eru·tuon 21:58, 8 September 2023 (UTC)
 * Hi @Benwing2, firstly sorry for the chaos that has been caused to you. We do know to be careful and we did communicate these breaking changes. I'm sorry these messages didn't reach you, communication across all our wikis is challenging. We recently created a Stable_interface_policy/Frontend to document how Wikimedia developers communicate these changes so this should help set better expectations about what and how this should happen. All developers are expected to follow these guidelines, so please read through and check Stable_interface_policy/Frontend for the expectations we currently have on consumers of code like yourself.
 * Since communication is clearly an area we can improve, there has been discussion about having a mailing list to announce these sort of changes since the current communication mechanisms clearly do not reach the right audience. Since you missed our communication via tech news, if you have any thoughts on a mailing list or other ways we could be communicating to developers like yourself without tech news in a way that scales across all our projects I'd love to hear from you on mw:Topic:Xlrhitipsnlphmph.
 * Thanks for the ping and sorry again. Let me know if there's anything further I can do to help. Jon (WMF) (talk) 18:21, 18 September 2023 (UTC)

How to suppress tone sandhi in Teochew
It seems that the function is not added to the template yet. It is possible to suppress tone sandhi in Hokkien by the character "#" but not in Teochew. Mahogany115 (talk) 10:01, 8 September 2023 (UTC)

Quotation templatification issues, ways to find issues
I noticed a quote at east ("We, in the west...") sitting outside of the set of things that are recognized and collapsed as quotes, and in looking into how it got that way (this edit, ), I also noticed this edit terminated a quote too soon, leaving the ISBN dangling on its own line (since anything placed on the same wikitext line as a quote template gets shunted to the next line), and leaving the quote itself outside the template; I wonder if that is also how some metadata at common sense (TR) also ended up outside the template. I think it'd possible to find other cases where these things happened by searching for: - -sche (discuss) 20:14, 8 September 2023 (UTC)
 * 1) quote- or RQ- templates with extra text on the same line as, but outside of, the template (to find the second issue)
 * 2) cases where a quote template ends ( }} ) and then the following wikitext line starts with |someParameter= (to find some instances of the first issue)
 * 3) cases where there are more { than } or vice versa (to find other instances of the first issue, and probably a lot of other things caused by miscellaneous editors that we'd like to know about and fix)
 * , I'll check for and fix any similar bad bot edits. On the first edit, the bot (very, very incorrectly) matched multiple lines and then wrapped them in a quote template, so the total number of would have been balanced. Then someone partially fixed the bad quote which set the stage for the second edit, where it (arguably correctly) converted plain text to a quote and then ignored the random param lines after the plaintext.  As far as the cleanup lists go, I've already got #1 and #3 here and here. I think #2 should be extremely rare, but I'll check it out. JeffDoozan (talk) 20:38, 8 September 2023 (UTC)

How can we do this intelligently?
tried to talk about Longgang's origin here:. I tried to use Template:zh-l here: diff; my edit is arguably worse. Both of these are ugly results. Is there an intelligent way to do this? Thanks. --Geographyinitiative (talk) 21:30, 8 September 2023 (UTC)


 * @Geographyinitiative, LlywelynII: You can use l/m for Chinese with automated pinyin and simplified form support (this was a thing added a few months ago) - I've made accordingly. As a general principle, non-English words should always be wrapped in templates (l, m, lang, etc.), and this is especially the case for Chinese to allow the browser to use the correct fonts, and for the modules to generate pinyin and simplified forms. – wpi (talk) 12:58, 11 September 2023 (UTC)
 * Agreed. We should never be using bare links like this. Theknightwho (talk) 14:43, 11 September 2023 (UTC)

Bug discovered - Template:ja-noun producing incorrect ruby at 五つ子
See also Talk:五つ子. Basically, the ruby should be, but it's displaying incorrectly as. Since doesn't allow editors to specify the kanji string, and instead just pulls from the pagename, any attempts at manually adding the   markers to force correct parsing just fail out, since the pagename doesn't have any   characters. ‑‑ Eiríkr Útlendi │Tala við mig 21:31, 8 September 2023 (UTC)


 * @Eirikr Pinging User:Theknightwho who has done some work on this code. Benwing2 (talk) 22:00, 8 September 2023 (UTC)


 * The ruby relies on the ja-kanjitab template now. —Fish bowl (talk) 02:32, 9 September 2023 (UTC)

Module:family tree
This popped up in CAT:E today (in my time zone), along with assorted Beer parlour pages that invoke it directly like its documentation page does. After going through the transclusion list for Module:family tree/documentation and previewing Module:family tree/documentation from old revisions of all of those modules with edits over the last 24 hours or so (for the record: Module:families/data, Module:languages/code to canonical name, Module:languages/data/exceptional, Module:languages/data/2, Module:languages/data/3/p, Module:languages/data/3/y, and Module:string utilities), I think I've narrowed the cause down to, but I can't see anything wrong with it. Can someone figure out what's really wrong and fix it? Thanks! Chuck Entz (talk) 05:34, 9 September 2023 (UTC)
 * There are a couple of caches in Module:families/canonical names and Module:families/code to canonical name that were added by User:Theknightwho in April that needed to be updated. Unfortunately there doesn't yet appear to be a Javascript button to update them automatically as there is for regular languages, and the consistency check code doesn't seem to know about them. Benwing2 (talk) 18:31, 9 September 2023 (UTC)
 * I've added some more checks of Module:families/canonical names and Module:families/code to canonical name, so at least the errors are visible now. All of these derivative data modules should be updated by MediaWiki:UpdateLanguageNameAndCode.js as well when I feel like making it do that. — Eru·tuon 23:36, 9 September 2023 (UTC)
 * @Erutuon Thanks! The errors are actually spurious; the code you added needs to also check Module:families/data/etymology. Benwing2 (talk) 01:00, 10 September 2023 (UTC)
 * BTW User:-sche User:Vahagn Petrosyan User:Theknightwho I am going to eliminate the nonstandard etymology-only family codes OIr. and MIr. in favor of their canonical names ira-old and ira-mid. This is related to the elimination of nonstandard etymology-only language codes. Benwing2 (talk) 01:02, 10 September 2023 (UTC)

Removing inactive users from Babel categories
Following this, this vote authorized a bot to suppress anyone who hasn't edited in two years from the Babel categories. But when I looked through Category:User ja-N for active native Japanese-speakers to ping to another discussion, they were swamped by people who've been inactive since 2008, 2010, 2015. Anyone feel like making a bot run? If not, I'll at least manually remove users from the ja category; if we manually remove users every time we find ourselves looking through some category for active users, that's at least partially as helpful. For example, manually removing anyone whose last edit was before ~2020 just brought that category down from 64 to 38 users. (I had some other ideas earlier this year, including that if we didn't want to completely remove users from the categories, we could overwrite what they were sorted as, so instead of being sorted under "F", an inactive User:Foobar would be sorted under e.g. "⏳".) - -sche (discuss) 16:29, 10 September 2023 (UTC)
 * Definitely support regular bot runs to save manually combing through them. Checking the lists at Module:workgroup ping/data would probably also be useful. —Al-Muqanna المقنع (talk) 16:52, 10 September 2023 (UTC)
 * Yes please! Vininn126 (talk) 16:55, 10 September 2023 (UTC)
 * should have nocat, so the template does not need to be removed, as you are all about the categories. If one reviews someone’s old edits the information of his claimed languages may be relevant. Fay Freak (talk) 01:46, 15 September 2023 (UTC)
 * It's still useful to be able to check the category. Vininn126 (talk) 08:03, 15 September 2023 (UTC)
 * I don’t know how but ok, one can instead split the categories with inactive. I just had seen that -sche had commented out two Babel boxes. Fay Freak (talk) 15:31, 15 September 2023 (UTC)
 * Nobody was proposing to remove the template itself. But the vote mentioned above mentioned a parameter yes, it doesn't look like that was ever implemented? —Al-Muqanna المقنع (talk) 08:23, 15 September 2023 (UTC)
 * Yeah, it would be ideal if someone implemented that and then bot-added it. I can undo the several Japanese-speakers and two Romanian-speakers whose Babels I've simply commented out. - -sche (discuss) 15:48, 15 September 2023 (UTC)


 * Is this the right forum for this question? I'd have expected BP. DCDuring (talk) 12:15, 15 September 2023 (UTC)

lang
lang adds entries to Category:LANG twice-borrowed terms, but it should instead be Category:LANG twice-derived terms, if I'm not mistaken. -- Sokkjō 19:14, 10 September 2023 (UTC)
 * Yes, agreed. Also the reason why I hesitated creating it. Leasnam (talk) 19:23, 10 September 2023 (UTC)
 * On my understanding of how the templates are meant to be used, the existing setup is correct. My interpretation is that bor is only to be used with a borrowing into the entry language, otherwise you end up with wrong categorisation. So a twice borrowed term will use bor for the first borrowing (from the second language to the entry language) and then der for the second borrowing (from the entry language to the second language).
 * And even if I'm wrong, I'm dubious that there are any terms that are "twice-derived" but not "twice-borrowed". Surely borrowing is a necessary condition for a term to be "twice-derived". Can you give an example of a term that is "twice-derived" but not "twice-borrowed"? This, that and the other (talk) 23:46, 10 September 2023 (UTC)
 * Perhaps a borrowing from a Romance language into some form of Latin would be an example, but "twice-derived" doesn't sound very descriptive of the actual processes. After all, there might be several stages of inheritance before it was borrowed back, so such a term would be "derived" more than twice. Not that "twice-borrowed" is any better in that respect. Basically, these are terms that are "borrowed back" into the same language they came from after going through any combination of intermediate steps, but I can't think of an unambiguous attributive version of that- "re-borrowed" could mean that it was borrowed twice into the same language. Chuck Entz (talk) 00:53, 11 September 2023 (UTC)
 * I suppose it could be called "LANG terms borrowed back into the same language" or something; it would be longer but maybe less confusing. Benwing2 (talk) 02:32, 11 September 2023 (UTC)
 * This is the entry that brought this up, Reconstruction:Proto-West Germanic/kamisi. When a Germanic term gets borrowed into Latin, it quite commonly gets later reborrowed back into Germanic. Category:LANG reborrowed terms could work as a category name. Another solution might be to create a wrapper template called lang1 for use in such cases where you can have Category:LANG1 terms reborrowed from LANG2. -- Sokkjō 04:45, 11 September 2023 (UTC)
 * Ironically, this is an actual twice-borrowed term, but isn't being funneled into that category. -- Sokkjō 01:26, 12 September 2023 (UTC)
 * Surely that would only be twice-borrowed if was borrowed from PWGmc, which it does not appear to be. Or am I missing something? This, that and the other (talk) 08:28, 13 September 2023 (UTC)
 * The Germanic is borrowed from the Latin twice, frist as and secondly as . What else would be be called? -- Sokkjō 17:53, 18 September 2023 (UTC)
 * Oh, that's a doublet. @Benwing2 Chuck Entz perhaps we really do need a better term than "twice-borrowed", if it confuses even our experienced contributors! Wikipedia uses but their article is poor in quality. Benwing's idea of a more descriptive name is better. This, that and the other (talk) 00:38, 19 September 2023 (UTC)
 * Yeah, searching Google web and Google Books for the phrase "twice-borrowed", trying to figure out where we got that term from, I notice most of the hits are irrelevant, many are about cases like sclarēia that are not "twice-borrowed" in our sense but simply "borrowed on two occasions" (fun fact, some terms have been borrowed even more times), and some of the hits which do use our sense are saying things like "apparently this is called 'twice-borrowed'" as if they'd just learned it (from us?). Some clearer category name could be an improvement. Maybe "LANG terms borrowed back into LANG", with "...borrowed back into the same language" for the top-level category? I'm just thinking repeating the LANG might help avoid people understanding "LANG [say: English] terms borrowed back into the same language" as meaning "the English words in this category were borrowed from [e.g. German], and then later [German, etc] borrowed them back into [German]". - -sche (discuss) 17:01, 23 September 2023 (UTC)
 * Yes, I'd be very supportive of this name change. I've posted at WT:RFM. This, that and the other (talk) 02:32, 24 September 2023 (UTC)
 * Sure, it is a doublet -- and makes use of doublet on the page -- but a doublet can be once inherited and once borrowed as well. -- Sokkjō 17:14, 23 September 2023 (UTC)

PageNotice extension - ready for testing
Since at least 2017, there has been a desire to get the PageNotice MediaWiki extension installed on this wiki. This extension allows a common piece of content to be displayed at the top (or bottom) of every page in a namespace. For example, we could use it to display reconstructed at the top of pages in the Reconstruction namespace without having to actually add the template to every single page. We could even do something similar - adding a small box explaining what the pages are for - on other specialised namespaces like Citations or Sign gloss, if we were so inclined.

Anyway, when it comes to setting up new extensions, it seems that nobody is going to do this sort of thing for us. Somebody has to be willing to get their hands dirty (the years of discussions at T61245 may be of interest to some). So I decided to step up and do it.

For now, I have arranged for the PageNotice extension to be enabled at the Beta English Wiktionary. Currently it is displaying a notice at the top of all Reconstruction: pages, for example,. The message itself can be found at.

Please feel welcome to experiment with PageNotice on Beta over the next week or two. I'm happy to grant admin rights at Beta to known users here; just create your own account (it doesn't use the same accounts as this wiki) and ask me for the admin bit by pinging me here. Ping who was a proponent of this extension's installation back in the day. This, that and the other (talk) 09:23, 12 September 2023 (UTC)
 * Thanks for taking up the mantle with this. I've been reading the comments on Phabricator over the past weeks, and saw the same frustration and I had back then. Figures doing the "wrong" thing is the only way to get anyone's attention in a broken system. --  15:32, 12 September 2023 (UTC)
 * Wow, that ticket is a bureaucratic horrorshow, for just 100 lines of code. Jberkel 11:59, 14 September 2023 (UTC)

Unicode 15.1
Hi, could someone with the authority please update the module:Unicode data? There is a new block, CJK Unified Ideographs extension I from U+2EBF0 to U+2EE5F. Additionally, U+31EF should have the script common and category So, U+2FFC to U+2FFF script common and category So and U+2EBF0 to U+2EE5D script Hani and category Lo. Thank you. 193.2.154.13 12:28, 13 September 2023 (UTC)


 * I'll update the filter so that entries using these characters can be created. Theknightwho (talk) 12:47, 13 September 2023 (UTC)

Question on IPA pronunciation
Hi, does anyone know where the code is that converts the code for an IPA pronunciation (e.g. ) to the actual IPA pronunciation (bɐŋkɐ)? I'm trying to train an AI to convert spelling to pronunciation from the database dumps and would rather avoid webscraping the pronunciations. 195.194.22.58 14:53, 13 September 2023 (UTC)


 * MOD:bg-pronunciation Vininn126 (talk) 15:10, 13 September 2023 (UTC)
 * And if you were using Bulgarian as a random example, the complete list of modules is at Category:Pronunciation modules. This, that and the other (talk) 00:33, 14 September 2023 (UTC)

ۂ in Urdu
Should Urdu be linked differently or removed from links, e.g.  to  as in ?

Compare with Persian where  is linked to. ۂ looks the same as هٔ but the former is one symbol.

@Sameerhameedy, @Fenakhay, @نعم البدل, @Benwing2. Anatoli T. (обсудить/вклад) 07:35, 14 September 2023 (UTC)


 * @Sameerhameedy, @Fenakhay, @نعم البدل, @Benwing2: After a few edits to Module:languages/data/2: I think I got this right.
 * "U+06C1" redirects to, only for Urdu, not Persian (but may need to be added for other languages).
 * Should the handling in Urdu ALSO exist as in Persian, e.g. (U+0647 + U+0654) links to  (U+0647)?
 * Current Urdu:
 * from = {"هٔ", "ۂ"}, -- character "ۂ" code U+06C2 to "ه" and "هٔ" (U+0647 + U+0654) to "ه"
 * to = {"ہ", "ہ"},
 * Current Persian:
 * from = {"هٔ"}, -- character "ۂ" code U+06C2 to "ه"
 * to = {"ه"},


 * Sorry for many pings! Anatoli T. (обсудить/вклад) 02:06, 15 September 2023 (UTC)
 * If it's possible, I would keep in links when it's used in a compound, but redirect to  otherwise. So  should be as it is, but  should redirect to . نعم البدل (talk) 15:55, 15 September 2023 (UTC)
 * @نعم البدل: Thanks, I missed your ping, since the signature and the ping should be in one edit.
 * In any case,
 * links to
 * links to, just like
 * In both cases, is not in the page title but is part of the headword in the first example. It is treated as a diacritic and converts  to  on links, which was the idea.
 * It works basically identical as a Persian example with linking to  in  (which links to, note missing "هٔ") but it's for similar-looking but different symbols. Anatoli T. (обсудить/вклад) 04:53, 22 September 2023 (UTC)
 * - Yeah, actually, that's fine - keep as it is. I forgot that sometimes ۂ is also substituted with ـیہِ so it's best to just limit ۂ to headwords. نعم البدل (talk) 14:45, 22 September 2023 (UTC)

to ?
Box templates of maintenance purposes like have the   class. Does it make sense to add it to the templates based on, like ? JWBTH (talk) 10:45, 14 September 2023 (UTC)

Okinawan Conjugation Template(s)
Currently, there is only 1 conjugation template for Okinawan which is for the irregular palatal changing verbs. We should make (a) new template(s) for the regular conjugations and the special verbs (do, come…) Je suis une paille (talk) 14:42, 15 September 2023 (UTC)


 * If you are familiar with Okinawan conjugation patterns, by all means, please build those out. I currently lack both the expertise and the resources. ‑‑ Eiríkr Útlendi │Tala við mig 18:45, 15 September 2023 (UTC)
 * I could find/provide the resources, but the module-building would be the biggest issue. I'd like to build one out for Jeju too, but looking at Module:ko-conj gives me nightmares. AG202 (talk) 19:05, 15 September 2023 (UTC)
 * I’m sorry this sounds like a stupid question but I’m pretty new to this, how do I make a template? The wiktionary help didn’t really help me😅 Je suis une paille (talk) 02:49, 16 September 2023 (UTC)
 * @Je suis une paille you could try copy-pasting the code of Template:ryu-conj-palatal to Template:ryu-conj-regular or whatever you want it to be called, and making the necessary changes. might be able to assist. This, that and the other (talk) 07:51, 16 September 2023 (UTC)

Definition-line templates in etymologies
I frequently notice definition-line templates being used in eymologies, e.g. I just now spotted clipping of in shi. Anyone up for making a list of cases where such templates (Category:Definition templates) are in etymology sections, and seeing what we could then bot-replace with etymology-templates? (Might also want an edit filter to warn people against adding more, but maybe that'd be too 'expensive'.) - -sche (discuss) 15:45, 15 September 2023 (UTC)
 * I'm on the wrong computer now, but I could easily generate such a list in a couple of days' time. Maybe someone else will beat me to it.
 * It's worth noting that some form-of templates don't seem to have an etymology equivalent, such as inflection of. In fact, only eight form-of templates are explicitly documented as having an etymology equivalent: . This, that and the other (talk) 07:58, 16 September 2023 (UTC)
 * Here's a list, split by template. Some templates might be good candidates for bot fixes, but many may need some manual cleanup. JeffDoozan (talk) 17:43, 16 September 2023 (UTC)

Descendant trees and etymology-only languages
Pursuant to the mergers of the literary Prakrits and others into a single Prakrit language, has asked me to review the replacement of desctree by desc in  because of a self-reference in the descendants table, which previously led to an infinite loop. Can someone therefore direct me on how one is supposed to handle desctree and a convention that constituent literary Prakrits are etymology languages descended from a parent common 'Prakrit' language? There may be the immediate complication that the forms in specific literary Prakrits and thus etymology-only languages, Sauraseni Prakrit and Maharashtri Prakrit, are alleged to be the same as the 'Prakrit' form in whose entry the problem arises, though I see no evidence to support that highly credible assertion. (Moreover, if the word existed in Sauraseni Prakrit, that fact should be recorded in the headword line. It isn't.) The solution might just be that pra-mah should be replaced by pra-mah and desctree be applied at a lower level. The documentation of desc seems to imply that one should use pra-mah rather than simply omit the descendant, but our documentation would not survive a competent quality audit. .

There is of course the further complication that the physical lemma is merely a Wiktionary inference - barring an amazing accident of preservation, no quotation or contemporary mention is possible for the entry. (That hasn't stopped quotations being reconstructed.) --RichardW57 (talk) 22:32, 16 September 2023 (UTC)

Slowdown in Prakrit Declension
There has been something like a 30% slowdown in the CPU time generation of Prakrit declension since June this year. I don't know when it happened; it's now causing the generation of Module:pra-decl/noun/gallery/documentation to run out of CPU time. I don't think Benwing2's unnecessary changes to the declension module is the cause, as it only lengthens a few strings used in the process start up. The declension makes fairly intense usage of standard Prakrit transliteration from Brahmi, Devanagari and Kannada, and of transliteration from Latin by Module:typing-aids with the shortcut systems designated "sa", "inc-pra" and "inc-pra-Knda". The data files Module:typing-aids/data/sa etc. have not been changed since a speed up in declension was achieved in June this year. Any suggestions as to what may have gone wrong?

I think I may be able to achieve a significant speed up by condensing the typing-aids data files. The other alternative is to split the gallery by script. --RichardW57 (talk) 00:59, 17 September 2023 (UTC)


 * @RichardW57 My only thought is changes to core language modules by User:Theknightwho. More work is being done, which may have slowed things down. It may be possible to speed it up e.g. by caching, but this will increase memory. I don't see a problem with splitting the gallery file; I've had to do that in several cases for test files in my userspace, mostly due to template include size issues but sometimes due to speed issues. Benwing2 (talk) 01:03, 17 September 2023 (UTC)
 * @Benwing2 I can’t think of any significant changes that I’ve made recently. Theknightwho (talk) 01:06, 17 September 2023 (UTC)
 * @RichardW57 The current use of Module:typing-aids is a massive kludge that’s not really appropriate, and is likely a major source of problems, as it’s adding a ton of extra work for no obvious reason - can’t the original strings simply be processed directly? Theknightwho (talk) 01:11, 17 September 2023 (UTC)
 * Yeah, Module:typing-aids intentionally uses a simplistic transliteration method to make things easier, and it's supposed to run only when saving the page . It calls  for every pattern and replacement in the data modules, which is slow because that's a lot of calls across the Lua-PHP interface. An efficient Latin-to-whatever function should probably be developed in a separate module because the architecture of the Module:typing-aids data modules is not designed for optimization. For one thing, the data modules can't use function replacements, which can reduce the number of calls to   (though I'm not sure if that helps for Prakrit or not). I tried replacing   with   in Module:pra-decl/noun (put   into  ) and previewed Module:pra-decl/noun/gallery/documentation, and the tables finished generating in about 7.5 seconds. So apparently Module:typing-aids is taking up at least 2.5 seconds on that page. — Eru·tuon 02:27, 17 September 2023 (UTC)
 * I think I can achieve a speed up by using substitution tables as an input. Whether we should always use an automatic selection between ustring.gsub and string.gsub I don't know - and it may already be there.  There are other tricks we can play - if we convert IAST to Brahmi, it's safe rather than clever to ask Module:links to transliterate back. --RichardW57 (talk) 02:54, 17 September 2023 (UTC)
 * Using substitution tables in the typing-aids data module sa results in the gallery rendering 7 8 times out of 10 from the module editor, with Lua times in the seven successful cases ranging from 8.85s to 9.64s. It's currently out of cat:E.  I'll have to work on the Brahmi script and Kannada script data modules as well. --RichardW57 (talk) 14:02, 17 September 2023 (UTC)
 * I did the same redunction to the number of replacements for modules inc-pra and inc-pra-Knda as well, and timed 11 generations. The Lua CPU times in seconds were, sorted:
 * 7.27, 7.28 7.37 7.45 7.50 7.65 7.69 7.75 8.09 9.48 9.99
 * So, reducing the number of 'gsub' calls specified in the data modules makes time spent in Module:typing-aids relatively negligible. There is a set of about a dozen calls (one per dependent vowels) that could be reduced to one using the function-determined replacement value.  That could be reduced to two calls if we need to squeeze some more time out, at the cost of some obscure code.
 * Might using lua to build the declension table save run time as well as keeping memory usage lower? RichardW57 (talk) 17:23, 17 September 2023 (UTC)
 * It sometimes helps with memory usage. It won't help in every case because the total memory usage of the intermediate strings (a, ab, abc, abcd, ...) isn't necessarily less than the memory usage of the array part of the table used to hold the strings being joined with , but I guess it'd help   because the first literal string being concatenated is 241 bytes, so every new intermediate string being allocated is at least that many bytes (much more than an entry in the array part of the table). I'm not sure about time, but it's possible that allocating a bunch of longer strings takes longer. One idea that I haven't tried is creating the right size of table by doing   with as many  s as there will eventually be strings in the final version of the table (ideally a power of two because the length of the array portion is doubled when it needs to be lengthened... I think though I don't really understand the Lua 5.1 table-related source code). (Can do   before the   to see how many  s.) I think that means the Lua runtime doesn't have to reallocate to lengthen the array part of the table, which takes some time. Another technique is to have   and   to avoid the slight inefficiency of   checking whether it received two or three arguments. Anyway, this is a lot of explanation... I'll give this a try in Module:pra-decl/noun myself and see what happens. — Eru·tuon 21:20, 17 September 2023 (UTC)
 * The timings on that are a bit mysterious. 11 runs previewing Module:pra-decl/noun/gallery/documentation gave the LUA CPU times in seconds in ascending order:
 * 6.59, 6.73. 6.91. 7.01. 7.15, 7.17, 7.30, 7.52. 8.20, 8.37, 8.69
 * About half a second better, but worth keeping. Curiously, the Lua CPU time is always less than 9.00s - perhaps these runs were just lucky. --RichardW57 (talk) 23:11, 17 September 2023 (UTC)
 * It's still an intermittent visitor to cat:E. The evaluation of Erutuon's change must have been lucky to avoid random overhead. --RichardW57m (talk) 14:37, 19 September 2023 (UTC)
 * reduced the set of about a dozen calls to one by a cunning trick for Devanagari, not the most used Indic script in the gallery, and squeezed 0.9s off the timing (run times:
 * 6.12, 6.12, 6.13. 6.17. 6.20. 6.23, 6.24, 6.25, 6.27. 6.33, 6.40)
 * That's well worth propagating to Brahmi (module inc-pra) and Kannada (module inc-pra-Knda). That experimental 7.5s time reported above was either an unlucky result, trying to format IAST as Prakrit hit significant overheads, or conceivably even total CPU time rather than Lua CPU time. --RichardW57m (talk) 10:31, 20 September 2023 (UTC)
 * I see that at 1:27 on 17 September, reversed my replacement of unconditional mw.ustring.gsub by Module:string utilities' gsub, wnich in June 22 single run comparisons reduced run time from 9.997s to 7.763s.  I therefore compared the two methods, timed from a preview of editing Module:typind-aids.  The results of 12 runs each were:
 * gsub=mw.ustring.gsub:
 * 5.86, 6.56, 7.01, 7.32, 7.35, 7.55, 7.68, 7.85, 7.89, 8.08, 8.43, 9.65,
 * gsub=require("Module:string utilities").gsub:
 * 6.03, 6.27, 6.35, 7.07, 7.11, 7.24, 8.17, 8.33, 8.42, 8.45, 8.56, 8.66
 * The means are the same (means of 6.80 v. 6.83), so it no longer matters which one we use! At least I hope the timings were not affected by other edits going on at the same time - just after the timing completed, the rendering the gallery suffered a Lua time-out, but then the problem went away. --RichardW57m (talk) 14:23, 21 September 2023 (UTC)
 * The main overhead of the module was I think its design as a template extension. That has been bypassed since June '23. Now, I don't like doing everything twice; I would rather not convert the stem from native to Roman and then convert back, because that can sometimes change it, but for the Indian Prakrits that doesn't seem to be a problem - so long as we don't add phonetics into transcription.  Stitching the stem and ending together in Prakrit is fiddly, and I think is even fiddlier in an Indic script than in the Latin script.  (The problem is hiatus.)  Now, it may come to converting it to a more conventional reverse transliteration, but that would mean that we had transliteration to Indic being defined in yet another place, which would be a maintenance issue should we ever track the Wikipedia definition of IAST.  (Modern academic IAST is not the same as the original IAST.)  I don't like unnecessary proliferation. --RichardW57 (talk) 02:34, 17 September 2023 (UTC)
 * The problem with splitting the gallery table comes if one compares tables. With one big page, one would display it in two windows and scroll to bring the two tables one wants to compare into view.  If it is split into three, one easily ends up with six windows to control, which is rather more complicated for the reviewer. --RichardW57 (talk) 01:59, 17 September 2023 (UTC)
 * The timing seems all over the place. It's significantly faster when I preview the page from a Lua editing session!  At first I thought someone had already sped things up this morning, but viewing the page directly still loses a third of the last section, 'Mixed Script'.  Before, it was losing all the tables in the last section.  Perhaps I'm seeing the effect of a mix of CPU speeds. --RichardW57 (talk) 11:03, 17 September 2023 (UTC)
 * The timing seems all over the place. It's significantly faster when I preview the page from a Lua editing session!  At first I thought someone had already sped things up this morning, but viewing the page directly still loses a third of the last section, 'Mixed Script'.  Before, it was losing all the tables in the last section.  Perhaps I'm seeing the effect of a mix of CPU speeds. --RichardW57 (talk) 11:03, 17 September 2023 (UTC)

Superscripts in
Hi. I'm not exactly sure this is the right section to ask this, but I'll try. I tried adding the pronunciation for an entry where the realization of the cluster oscillates between,  , and  , but the  template does not accept  as a valid character, despite it being ostensibly part of the IPA. Is there any particular reason for this? Thanks in advance for your time. —— GianWiki (talk) 08:29, 18 September 2023 (UTC)

Category:en:Bridges
The label given to the template is not valid. DonnanZ (talk) 16:15, 18 September 2023 (UTC)
 * My bad. Fixed. -- Sokkjō 17:56, 18 September 2023 (UTC)
 * Thanks. The error message didn't prevent my adding to the category. DonnanZ (talk) 18:08, 18 September 2023 (UTC)


 * Well, I did fix it, but then reverted me LMFAO. -- Sokkjō 18:32, 18 September 2023 (UTC)
 * That's bizarre! DonnanZ (talk) 19:01, 18 September 2023 (UTC)
 * You haven't fixed a thing. Look how many errors there are because of your edits. — Fenakhay ( حيطي · مساهماتي ) 19:22, 18 September 2023 (UTC)
 * My edit was a . What specific errors did it cause? -- Sokkjō 19:30, 18 September 2023 (UTC)
 * You deleted CAT:Buildings handling, which is a parent CAT of many categories. — Fenakhay ( حيطي · مساهماتي ) 19:32, 18 September 2023 (UTC)
 * I see what happened now. Thanks for restoring it correctly, instead of just reverting me and deleting Category:Bridges. -- Sokkjō 19:39, 18 September 2023 (UTC)

anchor WTF
On the sledge page, is used with the parameter "Et2N". WTF is that about? P. Sovjunk (talk) 21:50, 18 September 2023 (UTC)


 * "Etymology 2 Noun", presumably. Added here by a Wikipedian. It was surely an attempt to make an etymid by someone who was accustomed to Wikipedia's anchor template.
 * "Et2N" doesn't appear in any other entries so the anchor can be removed. This, that and the other (talk) 00:45, 19 September 2023 (UTC)
 * Meh, I'm not gonna remove it. I'll probably best ignore anchors. P. Sovjunk (talk) 07:00, 19 September 2023 (UTC)
 * Removed the unused anchor. — Sgconlaw (talk) 20:17, 19 September 2023 (UTC)

Re: Help Understanding WHY a Hebrew Entry (Word) Has been DELETED ("transferred" elsewhere)
Hello,

I've visited your website at the following link: https://en.wiktionary.org/w/index.php?oldid=49405675#%D7%A9%D7%95%D7%A3 & have attempted to start a discussion (I have input that has NOT been presented/discussed on the Hebrew root ש-ו-ף) but, the entry seemed to have had a strikethrough (with a message to page visitors that the discussion had been moved elsewhere/archived & WITHOUT ANY option to start a new conversation!). What's up with THAT...? I'd appreciate your early expert advice & look forward to it. AK63 (talk) 11:50, 19 September 2023 (UTC)
 * That's a five-year-old RFV discussion. RFV (Requests for Verification) is a procedure for demonstrating that a term actually exists. It was struck because the person who brought up that particular case was satisfied that the relevant senses exist. You always have an option to start a new conversation, the strikethrough simply indicated that that particular conversation was over. A good place for generic discussions of a particular term might be the Tea Room. —Al-Muqanna المقنع (talk) 12:07, 19 September 2023 (UTC)
 * Or the Etymology scriptorium for an etymology discussion of a particular entry. DCDuring (talk) 13:17, 19 September 2023 (UTC)
 * Thank you / shuqran, for your response, ya AlMuqanna :) AK63 (talk) 09:13, 22 September 2023 (UTC)

Шайлушай should have a page
The word ‘шайлушай’ is increasingly common and deserves an entry. 216.56.8.2 19:26, 19 September 2023 (UTC)


 * What language? Benwing2 (talk) 21:10, 20 September 2023 (UTC)
 * @Benwing2: Russian. It's some kind of popular meme on Tiktok, which I haven't looked at yet. Possibly not a dictionary material. Anatoli T. (обсудить/вклад) 05:03, 21 September 2023 (UTC)
 * According to some russian reddits, it's a pretty large meme. Some users said joke is that the word "Шайлушай" is just gibberish. I guess it's a common enough word but can we even have an entry for humorous gibberish? I've never seen an entry for something like that. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 23:01, 23 September 2023 (UTC)
 * @Sameerhameedy It would fall under the "hot word" provision if we included it at all, but I'm skeptical. Generally a word needs to have three cites (uses, not mentions) over at least a one-year period, and "hot words" are included only if we think it's likely they will remain in use for a few years. Memes often come and go quickly. Benwing2 (talk) 00:53, 24 September 2023 (UTC)

How to run IPA modules
For pronunciation modules such as https://en.wiktionary.org/wiki/Module:bg-pronunciation, how would I run the Lua script on my own computer? I keep getting errors about other modules particularly mw.ustring not being found. 195.194.22.58 10:15, 20 September 2023 (UTC)


 * There are two possibilities. One is to do a network call and have the Lua code run on the MediaWiki servers. This can be done using site.expand_text in Pywikibot, e.g. I use site.expand_text("") to fetch data on all languages from Module:User:MewBot. The limitation here is MediaWiki only lets you do one call per second (although you can work around that using multiple threads, and you could also write a small module that takes a list of pronunciations, generates them all at once, and returns the results JSON-encoded). The other possibility is to set up a MediaWiki Lua environment on your own computer; this potentially runs a lot faster but requires some setup. I have never done this but I think User:Erutuon and some other editors around here have done so; maybe they can comment. Benwing2 (talk) 21:10, 20 September 2023 (UTC)

Yiddish automated transliteration
At, "Terms with manual transliterations different from the automated ones/yi" was showing up as a hidden category, so I removed the manual transliteration. An automated transliteration was displayed, but also " ". — Sgconlaw (talk) 13:21, 20 September 2023 (UTC)


 * @Sgconlaw You should not have removed the manual translit. Yiddish has a bunch of words imported from Hebrew that use the Hebrew spelling but Yiddish pronunciation and need manual translit. This is one of them, and the resulting transliteration 'mvin' is all wrong. Benwing2 (talk) 21:13, 20 September 2023 (UTC)
 * The issue with the empty category is something else; I'll take a look. Benwing2 (talk) 21:14, 20 September 2023 (UTC)
 * thanks. Mmmm, if a manual transliteration is required, then the template probably shouldn't be displaying "Category:Terms with manual transliterations different from the automated ones/yi"? — Sgconlaw (talk) 04:04, 21 September 2023 (UTC)
 * @Sgconlaw This category is added whenever there is a manual translit different from the automated one, regardless of whether it's required: there's no way in general to know automatically whether a given manual translit is required or correct. Probably actually the category should be named more like 'Pages with Yiddish manual transliterations different from the automated ones'; the current formatting is nonstandard as well as misleading, because the term with the manual translit often occurs on a different page (e.g. as in this case; maven itself is an English term and has no translit). The description should maybe be updated to make it clearer that pages in this category don't necessarily require cleanup; can you suggest a wording? Benwing2 (talk) 04:17, 21 September 2023 (UTC)
 * What I was planning to do before the number drastically shrank was to add text to the Pali category files of this nature along the lines of: "The following different manual transliterations are known to be necessary:...", with the list in the category file itself. The category is for maintenance; the pages flagged up need review at some point, but that won't need reviewing very often, especially if the transliteration is stable.  It might make sense to instead reference a page of reviews of transliteration, but I'm not sure where to put such a page.  Perhaps one could have it as a documentation page sitting under the relevant transliteration module.
 * Another alternative might be to add a template-level "don't check flag", but exposing it to campaigners and vandals is probably a bad idea. There is a Lua level "don't check flag", which is very useful for SE Asian Thai and Lao Pali inflection tables, where transliteration can need writing system information not available in the one-size fits all interface, and we live dangerously with translation tables on pages at grave risk of running out of memory. --RichardW57m (talk) 13:27, 21 September 2023 (UTC)
 * what is the function of categories like "Category:Terms with manual transliterations different from the automated ones/LANG"? Knowing this, I might have a better idea of how they should be named. To me, the current name suggests that the manual transliteration should be removed. — Sgconlaw (talk) 22:19, 21 September 2023 (UTC)
 * @Sgconlaw We also have categories like Category:Terms with redundant transliterations/yi when there are manual transliterations the same as the automated ones. I think the purpose of the 'different from the automated ones' is for checking whether the manual transliterations are wrong, e.g. they are using a different transliteration system from the automatic one. Unfortunately as User:RichardW57 points out, there's currently no tracking of which ones are necessary, which would have to be specified manually in a list somewhere. Benwing2 (talk) 23:16, 21 September 2023 (UTC)
 * And the redundant transliterations are tracked with a view to reverting to automatic transliterations, though there can be problems, e.g. when transliteration and Roman script equivalent diverge. (I work on the principle that words in the same language should be transliterated the same if they are spelt and pronounced the same.) --RichardW57 (talk) 07:52, 22 September 2023 (UTC)
 * ah, I hadn't realized there were two types of categories, "Terms with manual transliterations different from the automated ones" and "Terms with redundant transliterations". In that case I guess "Terms with manual transliterations different from the automated ones" doesn't need to be renamed, and it's just a matter of only removing transliterations from the "redundant" ones (though I'm not sure how the issue raised by should be resolved). — Sgconlaw (talk) 13:10, 22 September 2023 (UTC)
 * For Pali, that problem was resolved as follows:
 * As the 'principal' script is Latin, non-Roman script entries have a definition given by pi-sc, which displays the Roman script equivalent.
 * Headword scripts don't normally present transliterations, because of the previous point, but they will if given explicitly. A transcription value of '+' is interpreted as 'Give the standard transcription'.  As far as I am aware, this convention is only available at the level of Pali headword scripts and module; it does not (yet) descend to Module:links.
 * With the convention for '+', it was no longer necessary to spell out the transliteration, and so Category:Terms with redundant transliterations/pi was emptied. --RichardW57 (talk) 09:24, 23 September 2023 (UTC)

Module:Hani-sortkey
Here's a few edit requests for the module: – wpi (talk) 17:03, 20 September 2023 (UTC)
 * 1) Add the 5 new IDS chars ( and ) to the table at Line 22. The implementation might be a bit tricky, espeically for the last one.
 * 2) Replace the third link at Line 88 from Module:Hani-sortkey/serializer to Module:Hani-sortkey/data/serializer
 * 3) Add this clause at Line 142 to allow bypassing the while loop entirely if the text does not contain IDS characters (which is usually the case): lua.
 * I've dealt with this: 5 new characters added, the link's been corrected, and I've restructured how the module iterates over the string so that it does everything in a single loop, and only runs the IDS code if it absolutely needs to. This avoids having to use, which is slow and inefficient. Theknightwho (talk) 19:20, 21 September 2023 (UTC)

Category:en:Communes
I could have sworn there was a category for communes in France, but it seems to have been removed. I discussed it with User:Benwing2 earlier this year (User talk:Donnanz). What happened to it? DonnanZ (talk) 18:42, 20 September 2023 (UTC)
 * Category:fr:Communes in France though it only has one entry anyway. Doesn't look like there was ever an English category for it. —Al-Muqanna المقنع (talk) 18:57, 20 September 2023 (UTC)
 * Well, I haven't gone mad. I suspect somebody has disabled and deleted it. DonnanZ (talk) 19:57, 20 September 2023 (UTC)
 * It's "Communes in France" for . The categories for Algeria and Chile are "Communes of ...". Those two are working as they should be. I think it was originally "Communes of France" in English and French. DonnanZ (talk) 23:21, 20 September 2023 (UTC)
 * Category:en:Communes of France doesn't appear to have been deleted nor ever created. I would add it for you, but apparently I can't edit Module:place/shared-data, even though I can Module:category tree/topic cat/data/Places. -- Sokkjō 23:46, 20 September 2023 (UTC)
 * It should be created for English and French as so many entries include it. The anomaly of Category:fr:Communes in France (created by Wingerbot on 13 April 2023) needs to be addressed (in vs. of). Category:Municipalities of France also exists, but is hardly used. DonnanZ (talk) 09:09, 21 September 2023 (UTC)
 * Can we make it so Module:place/shared-data has the same permisions as Module:category tree/topic cat/data/Places? Sucks to have to ask every time. -- Sokkjō 17:50, 21 September 2023 (UTC)
 * It was User:Erutuon who added the template editor protection. I think the reason is that place is used on ~ 100,000 pages so any breakage to one of the modules it uses will cause a ton of errors, whereas Module:category tree/topic cat/data/Places is only used on category pages. However, Module:place and Module:place/data weren't protected at all, so I made all three have autoconfirmed protection. This means you should be able to edit them; hopefully we won't run into problems with bad edits from other autoconfirmed users. Benwing2 (talk) 20:29, 21 September 2023 (UTC)
 * 👌-- Sokkjō 20:53, 21 September 2023 (UTC)

memory errors going down
We're down to 42 from 64 yesterday. I think this is partly due to the work I did optimizing the labels data modules; I replaced one-element lists with bare items, converted duplicated strings to  wherever possible, and optimized the data module postprocessing step so it avoided doing work at that point in exchange for doing it later, when the label is processed. The idea is that the entire data module gets loaded into memory any time at least one label is used (well, there are several data modules, but we can ignore that for now); but the additional processing done when a label is seen is only done for the labels actually existing on the page, which is only a small subset of the entire set of labels. And using loadData on a module seems to use a lot of overhead, esp. for tables. So it's better to make the data modules as small as possible and do more work when processing the items actually needed. I think there's even more that can be done, ala using numbered entries instead of named ones for the most common fields, like we do for the language modules. There are also other data modules that could be similarly optimized. User:Theknightwho I think there's some postprocessing now done on the language modules, can we do a similar trick with them? Any other subsystems you can think of that are amenable to similar tricks? Benwing2 (talk) 19:00, 20 September 2023 (UTC)


 * @Benwing2 Yes, I've come to the same conclusion - it's usually better to do more work if it means you can avoid memory use. The savings were quite modest, but I've just reduced the size of the Module:Hani-sortkey/data/serialized string from 487KB to 301KB on the same principle: previously, every sortkey was stored in a format like, which took 5 bytes per sortkey. I've converted this to 3 bytes by using the format  , where the first byte is between 1 and 214 (since there are 214 radicals). The new method requires converting it to the correct radical once it's been accessed, but that's a pretty trivial process since the radicals are saved elsewhere in the string and can be looked up in a similar fashion once you have the index number. (Note that the page is longer than 301KB, since   takes 4 bytes to save, but obviously Lua only sees it as 1 byte). Theknightwho (talk) 20:36, 20 September 2023 (UTC)

inline diffs
Recently the MediaWiki developers added an inline toggle button to control whether the diffs shown when you view the history of a page are rendered in two side-by-side windows or in one inline window. In general I much prefer inline diffs, but the current formatting of the inline diffs is shitty in that it doesn't show the line numbers (unlike the side-by-side view), and doesn't make it clear where the hunks begin and end. Does anyone know if there is a way of customizing this? Benwing2 (talk) 23:05, 20 September 2023 (UTC)
 * The lack of hunks is reported at T346460. As for the line numbers, I've never found them remotely useful, except for code files (modules etc). Would you want them visible everywhere or just on code pages? I could file another Phabricator task - it's not something that could be locally customized. This, that and the other (talk) 23:35, 20 September 2023 (UTC)
 * @This, that and the other Thanks. For line numbers, just on code pages, I don't care whether there are line numbers on discussion pages and mainspace pages as I'm unlikely to look at them. Benwing2 (talk) 02:16, 21 September 2023 (UTC)
 * Filed T347013. This, that and the other (talk) 09:11, 21 September 2023 (UTC)
 * Thank you! Benwing2 (talk) 20:22, 21 September 2023 (UTC)
 * I believe this is now added, although I don't think my contribution had a whole lot to do with it. This, that and the other (talk) 06:18, 14 October 2023 (UTC)
 * @This, that and the other Yup, I see it in inline diff mode. Now I can finally turn on inline diffs :) ... Benwing2 (talk) 06:45, 14 October 2023 (UTC)

CSS for languages and scripts applies in mobile for now
After a discussion on Discord I came up with the idea of moving languages and scripts from MediaWiki:Common.css to a gadget at MediaWiki:Gadget-LanguagesAndScripts.css. That makes it apply on mobile for the first time, and it can be disabled by logged-in users in preferences. I'm not sure if mobile devices usually have enough fonts installed for this to actually be beneficial.

It is 17 kilobytes long when minified, and is delivered in the head tag of the page, so it makes up a large fraction of the total HTML size of a small entry (~60 KB non-minified). It also adds a lot of style rules for a mobile browser to apply. I don't know if this is going to be a problem for underpowered cell phones, but if so, we could disable it for the mobile skin in MediaWiki:Gadgets-definition. — Eru·tuon 03:49, 21 September 2023 (UTC)


 * Great initiative! This will reduce duplication with MediaWiki:Mobile.css, from which I suppose these can now be removed @Erutuon? This, that and the other (talk) 09:56, 21 September 2023 (UTC)
 * Yep, I've just done that. — Eru·tuon 21:19, 21 September 2023 (UTC)

"Lua error: Unmatched close-paren at pattern character 48"
Hello I've recently created the Sassarese pronunciation template, but when I try to use it, I get the error message in the title: Lua error: Unmatched close-paren at pattern character 48. Now, I counted the parentheses, and there is an equal number of  and , an equal number of   and  , and an equal number of   and. Can someone please explain the nature of this error to me? —— GianWiki (talk) 11:39, 22 September 2023 (UTC)


 * It looks like fair punishment for using a long template call rather than a Lua module. If you'd made a Lua Module, you'd've got a line number.  As the error lies in one of the parameters, just try each substitution parameter on its own until you find the error - or do a binary search if you can.  At the moment, all you know is that the problem is detected at character 48 of one of your parameters.
 * Incidentally, the subexpression [(b)(c)(d)(f)(g)(l)(m)(n)(p)(q)(r)(s)(sg)(t)(v)] looks very odd. What do you think it means?  Whatever it is, it ought to be extracted as an element, something one can do in Lua but not in templates.  You may have a problem with the regular expression engine.  You may have to first change the sequence 'sg' to a single character (e.g. to &#x24bc;) to do the replacements you want. --RichardW57m (talk) 13:20, 22 September 2023 (UTC)
 * @GianWiki I would really, really strongly advise that you don't take this approach. We generally don't like having imported modules from Wikipedia, because they're often not very good and difficult to maintain. In this case, it's made debugging your issues really hard, because it tells you nothing of value.
 * Would you be willing to redo things in a proper Lua module? That's generally how we do things here, and it makes things much easier to deal with. Theknightwho (talk) 13:38, 22 September 2023 (UTC)
 * @Theknightwho I really would be (actually, that was my first thought), except I know basically nothing about Lua, and it seems fairly complicated to me (as in, there are a lot of things to learn between me and the things I needed to make the template). To be honest, I thought I could circumvent this problem through that module, but it didn't pan out. I thought I could kinda lazy my way out of learning Lua. Thank you very much for the heads-up, by the way. —— GianWiki (talk) 14:53, 22 September 2023 (UTC)
 * @GianWiki I completely agree with User:Theknightwho about Wikipedia modules; this MultiReplace module is used on about 20 mostly reference pages so it shouldn't be too hard to eliminate. Benwing2 (talk) 21:17, 23 September 2023 (UTC)
 * @GianWiki Just BTW, I completely agree with User:Theknightwho about the general undesirability of importing Wikipedia modules. Benwing2 (talk) 01:56, 24 September 2023 (UTC)
 * Thank you for informing me about this. I had no idea. —— GianWiki (talk) 06:41, 24 September 2023 (UTC)
 * The pair of parameters where things go wrong may be displayed in a sandbox as
 * The closing parenthesis complained of is at the 48th character of the long parameter, immediately after [aeiou]. I suggest you study the pattern definition at https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Patterns.  Your 'pattern' is composed of:
 * Capture group (gli). It is delimited by parentheses.  It does not denote a context, as I think you think.
 * One-character Regular Expression (RE) "à".
 * One-character RE "[(bb)(cc)(dd)(ff)(gg)(gl)(gn)([ij]" Parentheses and left square brackets ([) have no special significance. What you wrote is equivalent to "[bcdfglnij[]", i.e. match one of 'b', 'c', 'd', 'f', 'g', 'l', 'n', 'i', 'j', '[', '(' and ')', which I am sure is not what you intended.
 * One-character RE [aeiou]
 * ')', the right parenthesis not matching the syntax at character 48.
 * The type of substitution you would have in Lua, if your scheme is basically correct, would look something like
 * lua where the ellipsis is some complicated expression that I think would have to rely on previous substitutions to make it simple enough to express in Lua regular expressions. --RichardW57m (talk) 14:13, 22 September 2023 (UTC)
 * @RichardW57m Thank you very much for the useful info. I'll have to take a better look into this. —— GianWiki (talk) 19:22, 24 September 2023 (UTC)
 * The tl;dr version is that parentheses and '[' do not count for balancing within [...]. --RichardW57m (talk) 14:36, 22 September 2023 (UTC)
 * The type of substitution you would have in Lua, if your scheme is basically correct, would look something like
 * lua where the ellipsis is some complicated expression that I think would have to rely on previous substitutions to make it simple enough to express in Lua regular expressions. --RichardW57m (talk) 14:13, 22 September 2023 (UTC)
 * @RichardW57m Thank you very much for the useful info. I'll have to take a better look into this. —— GianWiki (talk) 19:22, 24 September 2023 (UTC)
 * The tl;dr version is that parentheses and '[' do not count for balancing within [...]. --RichardW57m (talk) 14:36, 22 September 2023 (UTC)
 * The tl;dr version is that parentheses and '[' do not count for balancing within [...]. --RichardW57m (talk) 14:36, 22 September 2023 (UTC)

Supporting in  and
A lot of templates allow  (e.g. , , ) whereas  and  currently don't, although the   parameter does the same. Could we add  to  and  to make things more consistent? tbm (talk) 03:57, 23 September 2023 (UTC)


 * @Tbm Generally, the templates supporting alt are those that take multiple terms, including all those you have mentioned, while those that take only one term have the display form (the equivalent of alt) in the parameter after the term. Sometimes the second type of templates support alt, but it hasn't been a priority to add it everywhere because it's longer (and generally you can also use a two-part link in the term parameter). Benwing2 (talk) 21:06, 23 September 2023 (UTC)

Shahmukhi
So Punjabi, Saraiki etc. are using the Persian font for numbers instead of the Urdu one Compare Module:number list/data/pnb (Punjabi), Module:number list/data/skr (Saraiki) and Module:number list/data/ur (Urdu) Notevenkidding (talk) 06:47, 23 September 2023 (UTC)


 * This is part of a larger issue of forcing specific fonts for specific languages. There is a similar but different issue happening to Kazakh and Kyrgyz. Somehow Urdu, Arabic, Uyghur, and Persian are able to force a specific font but other languages can't. I brought up this issue in the discord but it seemed like almost everyone was surprised that some languages had the ability to force a specific font. So the amount of people who would know how to fix font issues are probably small. I suspect This module is the suspect though, but I have no way of confirming that. سَمِیر | Sameer (مشارکت‌ها • کتی من گپ بزن) 03:28, 24 September 2023 (UTC)
 * @Theknightwho do you think if we added code "pnb" and "skr" to Urdus font family, and "kk-Arab" and "Arab[lang=ky]" to Uyghurs, that would solve the font issues? Or do you think it's something else? Also @Benwing2, whenever you aren't busy, could you take a look at this too?  سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 03:36, 24 September 2023 (UTC)
 * @Sameerhameedy Apologies, you left me a message earlier that I didn't respond to. You are correct about the module in question, which was recently split out from MediaWiki:Common.css; this specifies the fonts used for each script. See lines 216-268. I notice that Kyrgyz does not have its own script code (see CAT:Kyrgyz language, where the script is just 'Arab'), where Kazakh does (see CAT:Kazakh language, where the script is 'kk-Arab'). There also appears to be some duplication in the font specs, as the first clause in the above lines sets the fonts and then later clauses also set the fonts for specific languages. Also, the gadget CSS file in question was only created a couple of days ago in order to fix mobile font issues, and 'Noto Naskh Arabic' is the first font listed for both 'Arab' and 'kk-Arab', so maybe it is fixed now. Also what do you mean by adding 'pnb' and 'skr' to Urdu's font family? I'm not sure what these are. Beyond this, I'm not sure as CSS isn't really my forte; the right people to look into this are User:Erutuon and/or User:This, that and the other. Benwing2 (talk) 04:05, 24 September 2023 (UTC)
 * OK, I see 'pnb' is Western Panjabi and 'skr' is Saraiki. Note however, that Western Panjabi has been merged into Punjabi, so the pnb code won't be seen at the CSS level. Also I'm still not sure what you mean about adding language codes to Urdu's font family. Benwing2 (talk) 04:09, 24 September 2023 (UTC)
 * @Benwing2 sorry, to clarify I was saying that for the section /* Kurdish, Punjabi Shahmukhi, Urdu */ I think the text should possibly be changed to:"
 * .ku-Arab,
 * .pa-Arab,
 * .Arab[lang=pnb],
 * .Arab[lang=skr],
 * .ur-Arab {
 * font-family: 'Noto Nastaliq Urdu', Tahoma, 'Arial Unicode MS', 'UT Cairo', 'UT Naskh', sans-serif;}.
 * Kazakh and Kyrgyz Arabic still don't look correct to me. Looking at Erutuons test cases only the "languages" kk-Arab and ky-Arab force Naskh, the languages "kk" and "ky" use my default system font which doesn't support many characters in those languages. Perhaps the section for Uyghur should add ".kk-Arab, .Arab[lang=kk], .Arab[lang=ky]"?
 * also @Erutuon, sorry to pile so much on you at once. When I turn on your gadget it doesn't force the naskh font in the title when viewed on mobile anymore, but before it did. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 04:45, 24 September 2023 (UTC)
 * @Sameerhameedy Not sure what  will do. Since Kazakh already has kk-Arab but not Arab as its script code, the script detection code will detect Arabic-script Kazakh terms as belonging to kk-Arab and do script tagging accordingly. Any Kazakh-specific changes should be done to kk-Arab. If we need to customize for Kyrgyz, presumably we should add a ky-Arab script code like for the other languages, and use it in the CSS. Benwing2 (talk) 05:03, 24 September 2023 (UTC)
 * @Benwing2 I thought that might've fixed Kazakh not showing in the right font for me but i'm not sure. Users on discord said the fonts were appearing weird for them on mobile, perhaps there's a separate module for mobile? I'm not sure. But Ill shut up and let @Erutuon and @This, that and the other look into it since they actually know CSS. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 17:29, 24 September 2023 (UTC)
 * For me پَہلا in Module:number list/data/pnb has the fonts for, which currently are the same as for Urdu   (MediaWiki:Gadget-LanguagesAndScripts.css) so I don't see how the CSS could be making it use Persian fonts (search for   on that page).
 * My testcases don't test how Kazakh or Kyrgyz text is actually formatted on English Wiktionary. Please just ignore them and look at actual entries. The -suffixed language tags are web-standard language tagging that is not used on Wiktionary. Please give an example of where you would like Naskh script to be forced.
 * I can add Noto Nastaliq Urdu to Urdu fonts. — Eru·tuon 19:26, 24 September 2023 (UTC)
 * @Erutuon Hi the Punjabi and Saraiki number lists are fixed for me now. As for the Kazakh and Kyrgyz thing, the arabic text shown at Айжан shows my system font, instead of Noto Naskh Arabic. Same thing can be seen in KK and KY Arabic-script entries such as جڭگ. (As I mentioned before, Noto Naskh Arabic would be preferable due to NNAs wide support and the rare characters used by Kazakh and Kyrgyz). سَمِیر | Sameer (مشارکت‌ها • کتی من گپ بزن) 19:41, 24 September 2023 (UTC)
 * Do you have the LanguagesAndScripts gadget enabled in your preferences? If you have it enabled (it should be, because it's enabled by default), the style rule applying to the text in Айжан should select one of the fonts . — Eru·tuon 19:46, 24 September 2023 (UTC)
 * @Erutuon, yes I have the setting on and I have Noto Naskh Arabic. Text inputted to correctly force Naskh for me, but text entered in  or  do not.  سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 19:58, 24 September 2023 (UTC)
 * Very strange! The only reason I can think of is that some style rule is taking precedence over the one I posted, but I have no idea what style rule that would be. The only way to figure out is, if you're on a computer, right-clicking on the offending text without the link here ( ايجان ), choose "Inspect", look for style rules containing  declarations, and find the first style rule that contains a   declaration that isn't crossed out. If you can post the style rule (i.e. including the selectors like   in this case), that would give me a clue of what's happening. Maybe there's no style rule overruling the Naskh font and instead the browser is thinking that some other font is more appropriate for   text (maybe based on the assumption that Kyrgyz is usually in Cyrillic in Kyrgyzstan). — Eru·tuon 21:44, 24 September 2023 (UTC)
 * @Erutuon The only thing I see when inspecting from my MacBook is "font-family: 'Linux Libertine','Georgia','Times',serif;" later on in the text it says font-family: sans-serif;
 * However I when I visited the mobile site on my MacBook (with the mobile user agent) and inspected, it said "font-family: -apple-system,'BlinkMacSystemFont','Segoe UI','Roboto','Inter','Helvetica','Arial',sans-serif;". Im not sure how to read this, but I think the mobile site is prioritizing the system font but the desktop site is forcing the correct fonts.
 * I think that's the case as when I compare the fonts on my phone and on my computer, the fonts are all displaying correctly on my computer. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 23:45, 25 September 2023 (UTC)
 * I wonder if there's some useful info here: This is related to the font setting under "User profile -> Internationalization -> More language settings -> Fonts -> Download fonts when needed" (this is unchecked for me). Benwing2 (talk) 03:12, 1 October 2023 (UTC)

Category:Entries needing topical attention
Should rfv-quote be placing anything in said category? If so, could someone please create it, as auto cat doesn't do it. If not, please amend rfv-quote so as not to place pages in the category and update its documentation so that it tells the truth.

I am re-using dictionary references where I believe has misinterpreted pronunciations in Thai script as words. He used it as support for the pronunciations interpreted in words; I am now trying to use it to support the Mon-script words. Someone needs to check the contents of the dictionary; my attempt to buy a copy resulted in us being temporarily scammed of the asking price. The nearest library copy to me is the other side of the Atlantic.--RichardW57 (talk) 13:33, 23 September 2023 (UTC)


 * The topic parameter has been removed from all the RFV/RFD family of templates. Apparently this template was missed, which I have now rectified. The discussion was at Category talk:Entries needing topical attention. This, that and the other (talk) 09:07, 24 September 2023 (UTC)
 * Thank you for cleaning up. --RichardW57 (talk) 21:35, 25 September 2023 (UTC)


 * What's the dictionary you are trying to obtain? - -sche (discuss) 01:24, 25 September 2023 (UTC)
 * This one: --RichardW57 (talk) RichardW57 (talk) 21:18, 25 September 2023 (UTC)

raz weirdness
There is an awkward situation with the etymology. Would it be possible to add something like and/or  and the like? Vininn126 (talk) 15:09, 27 September 2023 (UTC)


 * Another such case would be dzięki. @Benwing2 do you think you could add another parameter or many to ? Vininn126 (talk) 20:15, 28 September 2023 (UTC)
 * @Vininn126 sl already has pos and t params. Can you clarify what params you'd like to have added? Benwing2 (talk) 22:30, 28 September 2023 (UTC)
 * @Benwing2 when I add that, it mentions the pos of the loaned term. I would like to be able to mention what pos is referred to on the donor language. Please see the linked terms and check for yourself. Vininn126 (talk) 22:43, 28 September 2023 (UTC)
 * @Vininn126 I did take a look before but I'm still confused as to what your desired outcome is. Can you give an example of how you want it to look? Benwing2 (talk) 23:04, 28 September 2023 (UTC)
 * I think the issue is that I didn't add the senseid param and I don't quite understand how it works. Why does it display "sense 1"? That seems weird. Benwing2 (talk) 23:06, 28 September 2023 (UTC)
 * @Benwing2 Sorry, this is also an issue with . I have an issue where I have things like "sense 1" in these defs and it's unclear sense one of WHICH part of speech and I'm not sure how to differentiate between them. I would like the ability to link to specific defs but not rely solely on the text printed by.
 * It displays based on the number given at the front of the definition - I requested this feature be added to because it is a type of loaning based, by definition, on senses.
 * So I guess the issue is more with . Vininn126 (talk) 06:33, 29 September 2023 (UTC)

Module:zlw-ocs-verb
Module:zlw-ocs-verb is breaking page width. See býti. . -- Sokkjō 21:20, 27 September 2023 (UTC)


 * Thank you for bringing this up. I had been ignoring it for a long time having actually no idea how easily it could be repaired. From now on, it shouldn't break the page anymore. Zhnka (talk) 04:20, 28 September 2023 (UTC)
 * I happened to notice this but I didn't receive your ping. Did you add the ping afterwards? In general the ping has to be in the same commit as your signature for it to work. Benwing2 (talk) 05:24, 28 September 2023 (UTC)
 * I see you did do this. When you want to modify a ping, you need to instead re-ping in a new commit with a new signature. Benwing2 (talk) 05:25, 28 September 2023 (UTC)
 * Yeah, I didn't expect it to ping you, but I figured I'd address it to you as well and you read this page frequently enough. -- Sokkjō 05:28, 28 September 2023 (UTC)
 * Thanks. -- Sokkjō 05:28, 28 September 2023 (UTC)

Template undefined incorrectly stripping diacriticals from Vilamovian entries
The template (and thus also related templates like  and ) is incorrectly stripping diacriticals from Vilamovian entries. Thus, produces "łȧjst", even though there is an entry for łȧjst. — Sgconlaw (talk) 22:27, 27 September 2023 (UTC)
 * This is being done in the languages module, and likely intentionally. I don't know anything about Vilamovian but Wikipedia (which calls it the ) doesn't list ȧ in the Vilamovian alphabet, so I suspect it's not used in normal spelling. What does ȧ mean? Benwing2 (talk) 05:22, 28 September 2023 (UTC)
 * oh, I'm afraid have no clue. I just noticed that the Vilamovian word kept showing up as a red link when adding it as a translated word. (Pinging who created the entry, though the last time they contributed was in September 2022.) — Sgconlaw (talk) 11:30, 28 September 2023 (UTC)
 * @Sgconlaw This page on Omniglot says that ȧ is one of the "other letters" (not in the "alphabet" per se) and pronounced [a] (whereas regular a is pronounced [ɑ]; but the digraph ao is also pronounced [a]). I don't know what "other letters" means here. Benwing2 (talk) 20:03, 28 September 2023 (UTC)
 * BTW maybe we just need to move łȧjst to łajst and add a head parameter that includes the ȧ. Benwing2 (talk) 20:04, 28 September 2023 (UTC)
 * I guess it depends on whether the word is always spelled with an ȧ or whether that is just a typographical variant. — Sgconlaw (talk) 20:34, 28 September 2023 (UTC)

Awkward column widths
I hope it's ok to bring this up again here because there was no action at the talk page for almost 2 months. Ancient Greek Module:grc-decl is generating tables with oversized initial column (see for example) which are almost running off the edge of my screen, even at 90% zoom, forcing the final elements to be awkwardly compressed. It seems to me that this first column in particular (containing Number, Case/Gender, etc.) could comfortably be specified at half or even one third of its current width. Also contributing to this problem is the variant width of the following columns—which I can only assume is set based on the respective widths of the headings Masculine, Feminine, Neuter. Would it also be possible to get more uniform sizing of the columns (given that the length of each form is fairly uniform, at least within each given number) across the table. Masculine in particular seems to be far wider than necessary. Cheers. Helrasincke (talk) 15:00, 29 September 2023 (UTC)


 * @Helrasincke Yes, the structure of this template is a mess. I'm reluctant to make any quick changes because it looks like they would affect all Ancient Greek declension tables, even one-column ones like at, which clearly don't need to span the entire width of the page and really need a deeper fix :( This, that and the other (talk) 12:19, 1 October 2023 (UTC)


 * : MediaWiki:Vector-2022.css and MediaWiki:Vector-2022.js are now in CAT:E. I can't remember the last time that happened. Chuck Entz (talk) 01:14, 2 October 2023 (UTC)
 * @Chuck Entz thanks, fixed. It was my use of auto cat in a comment - I have no idea why MediaWiki tries to parse that... This, that and the other (talk) 03:24, 2 October 2023 (UTC)

Template:der4 at eel
The template does not play nice with images and sister-project boxes, overlapping template text content with images and sister-project boxes. I have moved the sister-project boxes. DCDuring (talk) 15:33, 29 September 2023 (UTC)
 * Apparently, the "problem" only occurs in the preview. Probably not worth addressing. DCDuring (talk) 15:37, 29 September 2023 (UTC)
 * Problem does not occur only in preview. It occurs at some pagewidths, when the page is newly loaded, but disappears when window size is changed and does not seem to recur, even at window sizes close to the original one. If this occurs with other column templates, it might well be worth addressing. DCDuring (talk) 16:07, 29 September 2023 (UTC)

Possible quote-bot hijinks?
I've just come across a quote attributed to a wrong source at gang which I suspect may be a result of a bot run or bot assisted clean-up of unformatted quotes. I've fixed it now, but this potentially affects much more than a single entry. I'm unable to track when exactly the text was deleted (I assume the page history is too big for the little tool), but compare here (addition of 2 unformatted quotes under Etymology 4) and here (the two have been mashed together). If somebody with superior technical skills could look into this, that'd be awesome. Helrasincke (talk) 17:02, 29 September 2023 (UTC)
 * : The quotes were added (the deletion of the checktrans-bottom template since then means you have to look in the "Translations to be checked" box to see it) with the quote before the attribution. In, the text of the first quote was mistaken for a usage example and removed, while its attribution was assumed to belong to the second quote and everything after the text of the second quote was also removed. This was human error- no bot was involved at the time. Chuck Entz (talk) 18:41, 29 September 2023 (UTC)
 * @Chuck Entz Ok good to know, thanks for looking into it. Helrasincke (talk) 19:32, 29 September 2023 (UTC)

Disabling auto-created categories by User:Babel AutoCreate
This user auto-creates categories like CAT:User bxr-3. Per the talk page of this user, to disable the category creation we need to file a Phabricator bug report. I am going to do that for the following reasons: If you have concerns please let me know. Benwing2 (talk) 23:28, 29 September 2023 (UTC)
 * 1) I have put these categories under the auto cat system, whereas the bot behind the user adds manual text that clashes with the text generated by auto cat.
 * 2) It sometimes generates categories for nonexistent language codes (as in 'bxr' above; we have a 'bua' code for Buryat; 'bxr' is an ISO 639-3 code for 'Russia Buryat').


 * If we have better 'bot infrastructure' for (semi-)automatically creating 'wanted' Babel categories these days, then yeah, this could be turned off—or maybe just blocked? (You'll notice it was blocked a couple times over a decade ago, but then unblocked since back then it was a necessary evil, since it mostly created valid categories which were not otherwise going to be created, although it has always also created annoyingly wrong categories too.) - -sche (discuss) 00:48, 30 September 2023 (UTC)
 * @-sche That's a good idea, I will block it. With the new code I've written, these user-competency categories can be auto-created with auto cat as long as the code in question is a valid full or etymology-only language, and params are available to specify the native-language translation of the English text (if you don't specify such a param, it gets added to a request category except for English and subcodes like 'en-GB'). AFAIK there are about 500 uncreated user-competency categories in Special:WantedCategories, which will get auto-created next time I run my script to create auto cat-able categories in Special:WantedCategories. Benwing2 (talk) 01:13, 30 September 2023 (UTC)

Temporary accounts for unregistered editors
Read this in your language • • Please tell other users about these changes



In 2024, editors who have not registered an account will automatically begin using temporary accounts. These editors are sometimes called "IP editors" because the IP address is displayed in the page history.

The Trust and Safety Product team gave a presentation at Wikimania about this change. You can watch it on YouTube.

There is more information at m:IP Editing: Privacy Enhancement and Abuse Mitigation.

SGrabarczuk (WMF) (User talk:SGrabarczuk (WMF)) 02:05, 30 September 2023 (UTC)


 * There's been a lot of teeth-gnashing on Wikipedia about how the fact that the system lets people request a new temporary ID as often as they like makes it harder to track that just one person is making a series of POV or vandalistic edits, although it is not clear to me if this actually represents a significant change relative to the existing option to make multiple named accounts. pt.Wikipedia banned unregistered / IP editors entirely a few years ago, which I guess we could always fall back on as a last resort if this turns out to be as much of a problem as pessimists think... - -sche (discuss) 02:35, 30 September 2023 (UTC)
 * "However, we will continue to give access [to IP addresses of anonymous contributors] to users who need to see them in order to protect the wikis." So potentially not a big deal. "Users who need them" includes admins but also other trusted users, I believe. See also m:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/FAQ. This, that and the other (talk) 07:17, 30 September 2023 (UTC)
 * "pt.Wikipedia banned unregistered / IP editors entirely a few years ago, which I guess we could always fall back on as a last resort if this turns out to be as much of a problem as pessimists think..."


 * I like the temporary ID change, but doing it like Portuguese Wikipedia? Please don't. It's seriously inconvenient; I can't tell you how many times I encountered typos or places I could add a line here or there in pt.Wikipedia and then gave up fixing it because it wouldn't let me publish it. I feel like logging in can be a bit of chore (especially on mobile) and sometimes PC I get logged out randomly...


 * If that change got implemented, I'd probably just stop editing here altogether like I did over there. I'm not sure if I'm the only one, but I kinda doubt it? Still thought it'd be nice to give my 2 cents.


 * ...Come to think of it, I'm not sure if I'm logged in right now. I'm User:MedK1. 2804:1B0:1901:CA73:4C8:C9CA:DDE4:8B93 09:26, 6 October 2023 (UTC)