text:
Wiktionary:Grease pit/2024/May

Lithuanian collation
I've been cleaning up some coding errors in Lithuanian entries, and I noticed that seven years ago had ineffectually added skesti to the headword line of ? What problem was it hoped to address? The word currently gets sorted (except when separated from its tagging as Lithuanian between "ske" and "skė" and in particular before "ski"; it looks as though sorting was much worse when the entry was created. It's possible that the hope was that it would be sorted between  and  as would be done by Mimer SQL.  .  I have removed the ineffectual parameter from the page. RichardW57m (talk) 13:13, 1 May 2024 (UTC)

 * And we can find successive dictionary entries, , , , showing the problems with promoting secondary collating differences to primary differences. --RichardW57m (talk) 14:50, 1 May 2024 (UTC)
 * Where is the design rational for our current Lithuanian collation? As far as I can tell, if it was controlled from Module:languages/data/2, it was implemented on or after 2 December 2022, in Module:lt-sortkey, which was deleted on 7 January 2023.  Essentially - why are secondary collation differences promoted to primary, whereas they are simply ditched in French, so sort French e, é, è and ê the same, but make Lithuanian e, ę and ė sort like completely different letters?  Was it a conscious decision?  I suspect the decision was taken by, and it can always be justified by being better than what went before. --RichardW57m (talk) 17:25, 1 May 2024 (UTC)
 * @RichardW57m What do you mean by "problems with promoting secondary collating differences to primary differences"? Can you clarify? BTW I doubt User:Theknightwho intentionally made a decision to change Lithuanian sorting order. He did a lot of work restructuring the *handling* of sort keys, but AFAIK the intent was to preserve whatever sorting rules were already present. Benwing2 (talk) 23:58, 1 May 2024 (UTC)
 * @Benwing2 Richard is referring to the Unicode Collation Algorithm, which uses primary, secondary and tertiary weightings (secondary tiebreaks primary, and so on). While I'd very much like us to use the UCA, implementing it would be a lot of work, but it would be a big improvement over the crude sort methods we generally use at the moment.
 * To answer @RichardW57m's question: the current sortkey isn't based on the UCA - with a handful of exceptions, our sortkey algorithms are very simple. Theknightwho (talk) 00:23, 2 May 2024 (UTC)
 * Well, someone made a change between 28 November 2022 and 15 December 2022 (see ), but the history is hidden in the now deleted Module:lt-sortkey. Was it perhaps ? --RichardW57 (talk) 06:48, 2 May 2024 (UTC)
 * I'm afraid Theknightwho's answer isn't an answer to my question. While our collations seem to be defined entirely by what the UCA would term primary keys, they tend to attempt to approximate the native sorting orders.  It hasn't always been done - our Roman script Pali sorting bears no relationship to the usual sort order, for example, being mostly based on the foremost sorting order for each script. Someone should be making a decision on how to do the approximation - but they may not actually understand the subtlety of the secondary level. --RichardW57 (talk) 06:48, 2 May 2024 (UTC)
 * @RichardW57 There's only one edit to Module:lt-sortkey, when it was created on Dec 1 2022 by User:Theknightwho. It looks like prior to that there was no sorting algorithm defined for Lithuanian. The Lithuanian dictionary at sorts ę as if it were e (e.g. gesti is directly followed by gęsti) but treats ė as a distinct letter, hence gežtis is directly followed by gėbelėti. I think you should figure out the correct sort order according to standard dictionaries, and then we can implement it. Benwing2 (talk) 07:07, 2 May 2024 (UTC)
 * {[re|Benwing2}} There had been a prior algorithm, but it was subsumed in the stripping of the three stress accents to generate page names. I haven't dug into the history of this stripping, but it may explain some of the oddities of Lithuanian templates if it was a later feature on Wiktionary.
 * Am I missing a trick with the LKZ web site? I can't see how to get a dictionary page from it, only dictionary entries.  Short of ordering books, I could only find Lalis's dictionary and introductory pages. --RichardW57m (talk) 08:40, 2 May 2024 (UTC)
 * @RichardW57m You can e.g. type just g in the search box and hit enter, and down the left rail you'll see a list of all the entries starting with g, in sorted order. Benwing2 (talk) 08:56, 2 May 2024 (UTC)
 * Thanks. Curious. The 'standard' Lithuanian collation as defined by CLDR and demonstrated (today) at  has gėbelėti before gežtis. --RichardW57m (talk) 10:19, 2 May 2024 (UTC)
 * But remember Theknightwho's assessment above of the UCA (let alone the CLDR Collation Algorithm) being a lot of work. Last time I looked, the latter wasn't clearly defined. --RichardW57m (talk) 10:31, 2 May 2024 (UTC)
 * This LKZ list may not be reliably sorted. We have four consecutive items gabumas, gabūnas, gabuoti, gaburdalas, but the distinctly non-empty lists of words stating 'bub' and 'būb' do not overlap!  Likewise for words starting gabu and gabū.  At https://zodynas.vz.lt/terminaiRaidec.php, I found the index headings/links ABCČDEĖFGHIJKLMNOPRSŠTUŪVZŽ, but 'E' and 'Ė' and also 'U' and 'Ū' pointed to the same lists!  Possibly that's a case of the author and the software having different ideas about Lithuanian sorting.  The list for 'U' and 'Ū' contained examples of both as initial letter. --RichardW57m (talk) 13:10, 2 May 2024 (UTC)
 * , I will need some help assessing what is a 'standard' Lithuanian dictionary.  I've now found what looks like one at https://archive.org/details/lyberis-sinonimu-zodynas-2002/page/106/mode/2up; (Sinonimų Žodynas = "Dictionary of Synonyms") the page linked to makes it rather obvious that 'e', 'ę' and 'ė' are the same in some sense, and page 128 shows the intermingling of the three.  Page 244 shows that 'u' and 'ū' have the same primary weight. Page 252 shows sameness for 'a' and 'ą'.  Page 147 proclaims sameness for 'i', 'į' and 'y'.  Page 528 proclaims the sameness of 'u', 'ų' and 'ū', though a demonstration for u ogonek will need more searching. --RichardW57m (talk) 15:00, 2 May 2024 (UTC)
 * @RichardW57m Implementing the UCA for general use on Wiktionary would be a lot of work because (a) it presents performance difficulties due to the size of the UCA dataset and complexity of tailorings, and (b) the sortkeys generated by the UCA aren't suitable as Wikimedia category sortkeys since they're numeric, which would mess up category headers. As such, any general implementation will need to solve that issue, too.
 * Implementing something something which emulates the UCA for one language is probably not too difficult, though (like our other sortkey algorithms) it would only support the relevant diacritics for the language. Theknightwho (talk) 15:17, 2 May 2024 (UTC)
 * Using the UCA doesn't force the use of the DUCET. To be honest, most of the CLDR tailorings don't look too wonderful when applied to characters not used outside the language's known character range.  I suggest the  keys be loaded as strings (which is what we do now).  The UCA implementation notes admit that the DUCET values are unfit for any system that expect keys to be C strings, and explains how to convert them.
 * Even now, starting a category display of Lithuanian terms at 'Y' causes the first letter header to be shown as 'I'. I think that sort of thing is inevitable for any letter that sorts out of code point order. --RichardW57m (talk) 16:10, 2 May 2024 (UTC)
 * I finally found the demonstration of 'u' and 'ų' having the same primary key in the sequence 'skùsti', 'skų́sti', 'skų́stis', 'skùtas' on paɡe 440. Word internal 'ų' is inconveniently infrequent.--RichardW57 (talk) 21:21, 2 May 2024 (UTC)
 * The only CLDR collation for Lithuanian gives "Bronius Piesarkas: Lithuanian-English Dictionary ISBN 9986-465-56-7" as its source, and this collation defines ogonek on 'a', 'e', 'i' and 'u' not to make a difference in primary weight, 'e' and 'ė' not to differ in primary weight, 'i' and 'y' not to differ in primary weight, and 'u' and 'ū' not to differ in primary weight.  The only weird thing about this collation is that it defines the accentuation marks (acute, grave and tilde) to make secondary differences, and thus be more significant than capitalisation, which I don't believe.  It's also saying that, inter alia, a difference of accent on the first syllable would outweigh a difference between 'e' and 'ė' in a subsequent syllable.  That's probably refutable. --RichardW57 (talk) 22:02, 2 May 2024 (UTC)
 * @RichardW57 I hope this might be what you're looking for (excerpted from Ambrazas et al):
 * In dictionaries and other lists of words arranged in alphabetical order, a and ą, e, ę and ė, i, y and į, u, ū and ų are treated as if they were identical letters, even though they represent different sounds. Therefore the following alphabetical order is customary: –  –,  –  – ,  –  –  – .
 * This appears to be confirmed by, for example, the Lyberis Lithuanian-Russian dictionary where is followed by,  is followed  (under which we find e.g. , ). Helrasincke (talk) 22:15, 4 May 2024 (UTC) Helrasincke (talk) 22:15, 4 May 2024 (UTC)
 * @Helrasincke @RichardW57 Yeah, this is easy enough to implement, if no one objects I'll go ahead and do that. Benwing2 (talk) 00:19, 5 May 2024 (UTC)
 * The only question is whether this is what people would prefer, as opposed to government directive. I've been surprised by the evidence that some would prefer to treat 'e' v. 'ė' and 'u' v. 'ū' as primary differences.  We did have someone object to the CLDR treating 'i' v. 'y' as a secondary difference.  The objection was dismissed as being based on ignorance, but I can't help wondering if there is a folk collation. --RichardW57 (talk) 14:06, 5 May 2024 (UTC)
 * Curiously enough, Cathy Wissink and Micha Kaplan get Lithuanian 'i' v. 'y' wrong on p11 of https://www.infitt.org/ti2002/papers/03WISSIN.PDF - carelessness, ignorance or misinformation? --RichardW57 (talk) 14:35, 5 May 2024 (UTC)
 * @RichardW57 That is an interesting find. To be honest, it seems like they're right insofar as y does immediately follow i (as opposed to preceding it), but only when all else is equal (see below, I presume this is the secondary collation in action, though I have to admit I'm still getting my head around primary vs. secondary). I've just checked the Lithuanian Root List and it has the following to say:
 * The morphemes in the root, prefix, and suffix lists are presented in Lithuanian alphabetical order. As in Lithuanian dictionaries, the letter y (designating long /i:/) is treated alphabetically as a variant of i, and in cases where otherwise identical roots differ only in initial letter i vs. y, the root with initial i is listed first (e.g., ir-1, yr-1 ‘come apart’)
 * So on that front, Wissink & Kaplan do appear to get that detail quite wrong. Thus Vakareliyska gives: bur- — būr- — būrb- — burn-; drambl- — drąs- — drask-, ėd- — egl-, yd- — iešk- ... ir- — yr- — irz-; ūg- — ugd-. In this sense Ambrazas's statement (but not the examples) they are treated identically is also not entirely correct (or has perhaps been mistranslated). It appears the secondary order is: base letter > y/macron(?) > ogonek > dot. The only one I have my doubts about is the secondary order of y and į as well as ū and ų since Vakareliyska organises the heading on p.21 and p.56 respectively as "I, Į, Y" and "U, Ų, Ū" (compare "A, Ą" and "E, Ę, Ė") and I actually can't find any minimal examples to confirm or deny this, especially since from my understanding ų is quite rare outside of inflections. Helrasincke (talk) 21:19, 8 May 2024 (UTC) Helrasincke (talk) 21:19, 8 May 2024 (UTC)
 * The secondary order I find plausible is base, base + ogonek, base + length marking, which is consistent with the CLDR. The instances of base + length marking are 'ė', 'y' and 'ū'.  That's also the ordering Wktionary currently promotes to primary, and the ordinary presented for longer versions of the alphabet.  'Dot above', except as part of ė, is probably less significant than capitalisation. --RichardW57 (talk) 07:22, 11 May 2024 (UTC)
 * I put out feeler about the reality of Lithuanian collation rules, and got an interesting indirect response from a Lithuanian. He said that the diacritics (and 'i' v. 'y'), other than those for accentuation), create what are treated as different letters and are sorted as such.  When he then compared the system he described with a dictionary, he came back with the response that the ordering in the dictionary was 'weird'!  (The intermediary was Bradn on the Zompist Bulletin Board.) On this basis, what we have at present is just fine! --RichardW57m (talk) 13:58, 15 May 2024 (UTC)
 * The secondary order I find plausible is base, base + ogonek, base + length marking, which is consistent with the CLDR. The instances of base + length marking are 'ė', 'y' and 'ū'.  That's also the ordering Wktionary currently promotes to primary, and the ordinary presented for longer versions of the alphabet.  'Dot above', except as part of ė, is probably less significant than capitalisation. --RichardW57 (talk) 07:22, 11 May 2024 (UTC)
 * I put out feeler about the reality of Lithuanian collation rules, and got an interesting indirect response from a Lithuanian. He said that the diacritics (and 'i' v. 'y'), other than those for accentuation), create what are treated as different letters and are sorted as such.  When he then compared the system he described with a dictionary, he came back with the response that the ordering in the dictionary was 'weird'!  (The intermediary was Bradn on the Zompist Bulletin Board.) On this basis, what we have at present is just fine! --RichardW57m (talk) 13:58, 15 May 2024 (UTC)

Lua Modules variable sized arguments and the arg magic variable
Several Lua Module have been "corrected" or modified and returned back to the Lua 5.0 old way of dealing with variable sized arguments. As Scribunto currently uses Lua 5.1 and efforts are ongoing that may update the Lua engine to new versions, I think we should stick to more modern ways to deal with varargs functions.

This is also important for me as I extract data from wiktionary and the Lua version I rely on does not understand this jargon anymore.

@Theknightwho Module:languages now uses the (soon obsolete) arg var in :

function export.addDefaultTypes(data, regular, ...) local n = arg.n 	local types = n > 0 and concat(arg, ",") or ""

Please, could you change it to : function export.addDefaultTypes(data, regular, ...) local arg = {...} local n = select( '#', ... ) As a quick fix ?

The same goes on with Module:scripts which has been "corrected" recently and introduced the same problem:

for i = 1, arg.n do    if not types[arg[i]] then

from the more modern (older) version:

for _, type in ipairs{...} do   if not self._type[type] then

Also please consider modernizing the Module:tables function:

function export.append(...) local ret, n = {}, 0 for i = 1, arg.n do 		for _, v in ipairs(arg[i]) do

Thanks in advance, Dodecaplex (talk) 21:14, 3 May 2024 (UTC)

 * @Dodecaplex The instances where I’ve implemented this have been where it maximises performance, and I would not support changing that. The workaround that you suggest generates a performance hit, which is unacceptable for functions which are called many thousands of times, as happens with memoisation.
 * I really don’t see the point in caring about what is officially deprecated in Lua 5.1 while there is no chance of the functionality disappearing in the near future. I appreciate that it creates awkwardness for you, but the solution is for you to use a Lua 5.1 binary. Theknightwho (talk) 21:16, 3 May 2024 (UTC)
 * @Theknightwho As Lua 5.1 is used in Scribunto, then arg is already deprecated.
 * In Lua 5.1, using arg in the function WILL imply a new table creation which will have a cost.
 * While using ... will avoid the creation of the magic table named arg (which is always null in Lua 5.1 when varargs are to be used). See for instance this stackoverflow answer.
 * My suggested changes where just a workaround, but if you want to avoid performance hits, then directly use the ... which contains directly the args (no overhead for arg table creation:
 * select('#',...) instead of arg.n,
 * select(1,...) instead of arg[1],
 * select(2,...) instead of arg[2], etc. (well, it is not that easy as indeed select(2, ...) will give the unpacked table from position 2, see details in the cited question)
 * This will have a better performance impact and will last longer in the long term... Dodecaplex (talk) 21:57, 3 May 2024 (UTC)
 * @Dodecaplex If you look at the instances where it's been used, a table has to be created anyway. It's possible to iterate with, but that rapidly becomes much slower than iterating over a table. I appreciate it's deprecated in Lua 5.1, but that is a completely academic point, really - in practical terms, it just means it's not portable to Lua 5.2 or higher, but Wiktionary doesn't use 5.2 and there's no chance it will for the foreseeable future. If and when that changes, we can adapt the code. Theknightwho (talk) 23:16, 3 May 2024 (UTC)
 * @Dodecaplex If you look at the instances where it's been used, a table has to be created anyway. It's possible to iterate with, but that rapidly becomes much slower than iterating over a table. I appreciate it's deprecated in Lua 5.1, but that is a completely academic point, really - in practical terms, it just means it's not portable to Lua 5.2 or higher, but Wiktionary doesn't use 5.2 and there's no chance it will for the foreseeable future. If and when that changes, we can adapt the code. Theknightwho (talk) 23:16, 3 May 2024 (UTC)

Need help with creating Module:number list/data/vi
Hello guys! I've been planning on expanding the cardinal box of the Vietnamese cardinal number entries by creating Module:number list/data/vi based on the data given in the English Wikipedia article Vietnamese numerals. Similar to Module:number list/data/ko, the number list should include both the native Vietnamese and Sino-Vietnamese transliterations. Does anyone here know how to do this? Thanks in advance! ChemPro (talk) 05:53, 4 May 2024 (UTC)

 * @ChemPro I can try to help you with that, but first you should try to make the module by copying the Korean one and filling in the corresponding Vietnamese forms. Benwing2 (talk) 18:48, 4 May 2024 (UTC)
 * Done! --ChemPro (talk) 08:04, 5 May 2024 (UTC)
 * @ChemPro What you did was about half done, but I tried to fix it up. It still needs some work. Benwing2 (talk) 00:11, 6 May 2024 (UTC)
 * Hello, thanks for fixing the error. I have some remarks on what still needs to be improved or implemented:
 * For numbers which include the digit 1 from 21 to 91, the number 1 is pronounced as mốt.
 * Even though năm chục (50) is an alternative form to năm mươi, it is not used to construct numerals from 51 to 59 (the same principle applies to all the multiples of ten from 20 up to 90)
 * When the number 5 appears after 10 in the unit digit, the pronunciation changes from năm to lăm --ChemPro (talk) 07:42, 6 May 2024 (UTC)
 * When the number 4 appears after 20 in the unit digit, pronunciation changes from bốn to tư --ChemPro (talk) 07:52, 6 May 2024 (UTC)
 * @ChemPro OK, thanks. I'll get to this tomorrow, going to sleep now :) ... Benwing2 (talk) 08:01, 6 May 2024 (UTC)
 * Some additional informations to the rules mentioned above:
 * Exceptions to the rule of changing the pronunciation from năm to lăm are numbers ending in 05 (such as 105, 605, 9405, 39605).
 * In some Vietnamese dialects, the number seven (bảy) it also read as bẩy. I tried to implement it, but it somehow caused an error. --ChemPro (talk) 08:36, 6 May 2024 (UTC)

Bot preventing the creation of a redirect
Wiktionary bot is preventing me from turning this page ناـ to a redirect to نا. Everytime I tried, it's being labeled as a potentially harmful action. The page formerly contained prefix entries for 4 languages. I appropriately moved them to نا. - Ash wki (talk) 10:08, 4 May 2024 (UTC)

 * I have done the intended page for you, surely the filter distinguishes us by user rights. But I think admins should give you autopatroller, I have observed meticulously clean and reasonable edits in you. Note that according to the discussion  wanted to move affixes, probably to contain the character, anyway, so you might want to put in your voice there. Fay Freak (talk) 11:35, 4 May 2024 (UTC)

@Fay Freak Thanks a lot. I'll look into the discussion, thanks. Ash wki (talk) 11:44, 4 May 2024 (UTC)

MY PAGE WONT UPLOAD
I WAS ONLY GIVING THE LINK TO MY WIKIPEDIA PAGE!!!! Lilly is cool (talk) 17:42, 4 May 2024 (UTC)

 * that’s exactly why … — Sgconlaw (talk) 17:47, 4 May 2024 (UTC)

 * If you make it a wikilink, as in [[:w:User:Lilly is cool]], the abuse filter won't think you're just linking to some random website. Chuck Entz (talk) 17:57, 4 May 2024 (UTC)

I keep getting logged out
Ever since I cleared my site data for Wiktionary to fix the translation-adder, I have to log in again on my PC every day. However, my other devices don't have this issue. Any ideas? Aaron Liu (talk) 18:31, 4 May 2024 (UTC)

 * @Aaron Liu Weird. When you log in, there's a button to remember the login for up to a month or so; do you have that checked? Also I've found that if you log out of any MediaWiki site, it logs you out of all of them. Benwing2 (talk) 18:46, 4 May 2024 (UTC)
 * I’ve had the same issue today, so it might be a server problem. Theknightwho (talk) 19:05, 4 May 2024 (UTC)
 * I didn't log out before clearing the data, and I have no problem at all staying logged in on my iPad. Aaron Liu (talk) 19:15, 4 May 2024 (UTC)
 * @Benwing2 I am still logged in on other wikis, so logging in is instant. I'll try logging out and back in again, thanks. Aaron Liu (talk) 20:46, 5 May 2024 (UTC)

Dialectal variation
I'm currently trying to improve the state of Polish dialects and subdialects, showing the hierarchy and what-not. Would be the best option? The idea isn't exactly to show synonyms, but just different reflexes of the same word. Vininn126 (talk) 06:22, 5 May 2024 (UTC)

 * What is the difference between what you're describing and an altform? Nicodene (talk) 07:08, 5 May 2024 (UTC)
 * Synonyms, as I understand it, have different morphemes, alt forms don't; in short these would be alt forms. I'd be wary of placing dozens of these by village in a hard to structure alt forms section, it would be nice to organise subdialects by dialect and to be able to host many easily. But I'm wary as this seems to be for synonyms. Vininn126 (talk) 08:07, 5 May 2024 (UTC)
 * @Vininn126 This sounds like a job for Descendants. Can you not put them on the proto-page and direct other pages to that page? BTW this is related to my post (maybe in the BP) about creating a generalization of alt. We may need a generalization of desc/desctree as well for these purposes. In general I'm not a fan of the dialect synonyms approach of using a separate module for the actual synonyms/alt forms/etc.; that is the approach used by etymtree and it didn't work. Benwing2 (talk) 19:47, 5 May 2024 (UTC)
 * @Benwing2 They are indeed descendants. It could be possible to set up there, but there's also the issue of how to list them on the Polish page itself. The alternative forms section and might lead to a huge mess. Vininn126 (talk) 07:11, 6 May 2024 (UTC)
 * Soft redirect? Do we need to list every dialectal form on every page? Benwing2 (talk) 07:17, 6 May 2024 (UTC)
 * @Benwing2 That's not my intention. Dialectal forms would most definitely be listed on the Standard Polish reflex. My issue is how to do that. The forms themselves would also be soft redirects (although this also sometimes gives pause to wonder, as they often don't always have the same definitions. They don't have the same declensions either, but I can make templates for that). The issue is if I have for example lekarz (which it might have?) with 6-10 forms and labels, it might not sound that bad, but I think giving it more structure would aid the reader, i.e. being able to organize subdialects by dialect and also maybe even geographically. Vininn126 (talk) 07:23, 6 May 2024 (UTC)
 * @Vininn126 It does sound like you want a generalization of desc/desctree for use in Alternative forms or whatever. I think structuring it the way that Descendants sections do it would work well. Benwing2 (talk) 08:03, 6 May 2024 (UTC)
 * I suppose I'll try that once I've done more work on the actual subdialects themselves. Vininn126 (talk) 08:05, 6 May 2024 (UTC)

< > (Unsupported titles/`lt` `gt`): broken labels
results in “ (Internet slang) ”. J3133 (talk) 15:27, 5 May 2024 (UTC)

 * @J3133 On which page? I tried this on a test page and it displays correctly. Benwing2 (talk) 19:42, 5 May 2024 (UTC)
 * : have you tried clicking on the wikilink in the title? I suspect it has something to do with interaction between characters in the pagename and the wikitext generated by the modules for the categories, though I have no clue whether it's the modules or the js or both that's doing it. Chuck Entz (talk) 20:31, 5 May 2024 (UTC)
 * @Chuck Entz Thanks, I see it now. Benwing2 (talk) 21:10, 5 May 2024 (UTC)
 * @Theknightwho Can you please take a look at this? This is happening in in Module:languages. The pagename passed in is, which is the actual pagename (rather than the "Unsupported titles" version), and line 1282 removes HTML tags, with the result that the sort key is an empty string, which is why the display shows garbled. I don't know why you are removing HTML tags but it clearly will interact badly with any pagename that looks like an HTML tag or contains HTML tags in it. Benwing2 (talk) 21:32, 5 May 2024 (UTC)
 * @Benwing2 Yes, this is something I’m aware of but a proper fix may not be straightforward, and may need to wait until the proper rewrite and disentanglement of the links and languages modules is ready. In the meantime, it should be possible to use the original input as a backup if the result is the empty string. Theknightwho (talk) 22:06, 5 May 2024 (UTC)
 * @Theknightwho Can you code this up? Benwing2 (talk) 22:25, 5 May 2024 (UTC)
 * Sure. Theknightwho (talk) 00:46, 7 May 2024 (UTC)
 * @Benwing2 The (short-term) solution was for in Module:utilities to use  from Module:headword/page as the sort base instead of, as that effectively instructs  in Module:languages to treat any formatting characters in the input as literal, which makes sense if they're included in the actual page title. This isn't ideal, though: I don't think Module:languages should be dealing with escapes or handling formatting characters at all, as they should only be dealt with by modules which handle raw inputs and final outputs. Theknightwho (talk) 18:12, 7 May 2024 (UTC)
 * @Theknightwho OK thanks! What you say makes sense; where would you move the makeSortKey functionality that deals with escapes and formatting characters? Also under what circumstances can HTML end up in the sort key and need to be removed? Benwing2 (talk) 19:34, 7 May 2024 (UTC)
 * @Benwing2 If I remember correctly, the original reason I added this is because inputs like en would push bar through, but I don't know if that's still the case.
 * The ideal situation would be for the Module:languages functions like, (etc.) to treat their inputs as literal, with any formatting issues being handled by Module:links, Module:usex (or whatever), but that's only feasible if we have a consistent way to handle raw inputs, since they're non-trivial to deal with. This is what the wikitext parser is supposed to do, because it generates a "wikitext object" which can be processed in whatever way is needed while retaining any formatting in the text. However, it's hard to do that while ensuring good enough performance, because it needs a custom regex engine if you want to have string function functionality.
 * For sortkeys specifically, the solution is just to convert the wikitext object into the display text as a string (i.e. raw input → wikitext object → display text), which effectively amounts to removing any formatting characters, but it doesn't make sense to add all the extra complexity of parsing wikitext just for that. Theknightwho (talk) 19:46, 7 May 2024 (UTC)
 * For sortkeys specifically, the solution is just to convert the wikitext object into the display text as a string (i.e. raw input → wikitext object → display text), which effectively amounts to removing any formatting characters, but it doesn't make sense to add all the extra complexity of parsing wikitext just for that. Theknightwho (talk) 19:46, 7 May 2024 (UTC)
 * For sortkeys specifically, the solution is just to convert the wikitext object into the display text as a string (i.e. raw input → wikitext object → display text), which effectively amounts to removing any formatting characters, but it doesn't make sense to add all the extra complexity of parsing wikitext just for that. Theknightwho (talk) 19:46, 7 May 2024 (UTC)

Enabling collapsed quotations on Appendix: and Reconstruction: pages
I've already gone through every page in the Appendix and Reconstruction namespaces to remove bad uses of. Could one of our interface administrators change MediaWiki:Gadget-defaultVisibilityToggles.js to include namespaces 100 (Appendix) and 118 (Reconstruction) so that quotations can display properly? (Before anyone asks, there are legitimate quotations on reconstructed entries, such as Reconstruction:Proto-Germanic/Harigastiz). Ioaxxere (talk) 16:55, 5 May 2024 (UTC)

 * The issue is some of our reconstruction only languages actually have quotations, if I understand correctly... Which means they aren't reconstruction only. Vininn126 (talk) 17:00, 5 May 2024 (UTC)
 * Yeah this is related to the issue with Proto-West-Germanic kamb being attested, which still hasn't been resolved. Benwing2 (talk) 19:40, 5 May 2024 (UTC)
 * ✅ This, that and the other (talk) 10:00, 6 May 2024 (UTC)

"SORRY" abbreviations

 * Moved to Tea room/2024/May

Why additional line under headings in discussion pages?
Was this announced? Voted on? Imposed by MediaWiki? Or by someone else? DCDuring (talk) 00:43, 7 May 2024 (UTC)

 * It's coming from MediaWiki updates, which are announced at WT:Wikimedia Tech News/2024 (we really should get Tech News sent to GP imo).
 * The look might take a bit of getting used to, but I can already see the benefits. For instance, being able to see at a glance how recently each discussion was contributed to, rather than trawling through signatures, is clearly useful – it's proven its value on Wiktionary's mobile view, where it has been visible for some time.
 * In any event, the announcement advises that you can turn the new look off in the Editing tab of your preferences. This, that and the other (talk) 01:20, 7 May 2024 (UTC)
 * @DCDuring Personally I think its usefulness outweighs any possible space wastage. Benwing2 (talk) 19:35, 7 May 2024 (UTC)
 * It really only helps in longer discussions and wastes space otherwise. In any event, the at-a-glance feature at watchlist is more useful and saves, rather than wastes space. 14:23, 7 May 2024 (UTC)
 * Anything I can turn off is OK with me. DCDuring (talk) 20:19, 7 May 2024 (UTC)
 * @This, that and the other BTW according the their Tech News 2024-18, they did a one-year A/B test of this feature and analyzed the outcome based on factors like how many replies they see and such. I'm impressed that they put the effort into doing this test (and one year is a very long time for an A/B test, but I understand that this may have been necessary to get statistical significance). Benwing2 (talk) 22:19, 7 May 2024 (UTC)
 * Yuck. They should have made a legacy toggle in the settings. If someone creates a CSS override that restores the original appearance, please ping me. -- Sokkjō 04:18, 8 May 2024 (UTC)
 * , you can turn it off by unticking "Show discussion activity" at the bottom of the "Editing" tab of Special:Preferences. - -sche (discuss) 15:48, 8 May 2024 (UTC)
 * <3 -- Sokkjō 16:50, 8 May 2024 (UTC)
 * It looks like the stats on how many days or months since the last edit are wrong- late December isn't "4 months ago". Chuck Entz (talk) 15:01, 8 May 2024 (UTC)
 * @Chuck Entz Late December is between 4 and 4.5 months ago, no? Benwing2 (talk) 21:00, 8 May 2024 (UTC)

I cannot execute a sql file wiktionary dump
I'm trying to contribute to wiktionary and would like to analyze the category links and make sure they are correct but I'm not able to manipulate the sql files. They are too large and my software crashes. How do you guys do it? This is the file I'm talking about

enwiktionary-latest-categorylinks.sql.gz

located here:

https://dumps.wikimedia.org/enwiktionary/latest/

It is 5 gigs. I tried importing it into Navicat but it did not work. I even tried divided the files into a mere 1/50th of its size and that could not work either. Kylefoley202 (talk) 07:19, 8 May 2024 (UTC)
 * These are certainly very large files. There are a few ways to proceed:
 * If you just want to issue SQL queries against the categorylinks table, use Quarry.
 * You could set up a local installation of the MariaDB database server on your computer and use the provided command line tools to run the SQL script against your local server.
 * Or else write a simple script (say in Python) to parse the SQL file character by character. Here's a rudimentary script I wrote a while ago that converts a different table's SQL script (pagelinks) to CSV:

 * I hope this helps. If you want more advice, tell us what it is you want to do with the file. This, that and the other (talk) 11:57, 8 May 2024 (UTC)
 * Thanks, I already wrote a python script to parse the sql file and I am rolling and in action. I want to work on getting the IPA transcriptions of English words correct for the purposes of perfecting the rhymes categories.  I'm a poet after all.  I also want to build an app that both outputs sublemmas given a lemma and also output lemmas given sublemmas.  I want to correct any mistakes I find in Wiktionary. I need to figure out how to quickly insert edits into wiktionary with software then upload them in a quick and painless manner. Kylefoley202 (talk) 19:50, 8 May 2024 (UTC)
 * Also, I can't tell whom I'm talking to, that would help. Kylefoley202 (talk) 19:51, 8 May 2024 (UTC)
 * @Kylefoley202 In terms of making changes to individual pages, you should use pywikibot, maybe in combination with mwparserfromhell to parse the wikitext. My bot scripts do this, e.g. the find_regex.py script lets you download pages using various selectors, and push_find_regex_changes.py lets you upload pages after making changes in a text editor. Benwing2 (talk) 21:37, 8 May 2024 (UTC)
 * : Please read WT:BOT. Before you make mass changes to Wiktionary entries, you need to show the community that you know what you're doing and that you will edit according to Wiktionary standards. You should also be aware that Wiktionary has its own ways of doing IPA that have been developed through discussion and consensus, so you might unintentionally fix some things that aren't really broken. I'm just saying this for the record. I'm sure you're responsible and know what you're doing. Chuck Entz (talk) 14:29, 9 May 2024 (UTC)
 * This script seems like an incredibly convoluted way of implementing a regex. Ioaxxere (talk) 16:26, 9 May 2024 (UTC)

Periodically post link to appropriate section of WT:Wikimedia Tech News?
Following up on TT&O's suggestion above: Apparently WT:Wikimedia Tech News/2024 often contains changes relevant to many of us. Would it make sense to post a link the section of the subpage that had the latest posting? The full text would not be necessary and would take up a lot of space. (There have been 19 postings (~weekly) so far this year!) Presumably, anything that someone objected to, didn't understand, etc. would be made a topic. DCDuring (talk) 17:53, 8 May 2024 (UTC)
 * Another approach would be for someone to red Tech News and try to anticipate which items would be of interest to our active users. DCDuring (talk) 17:58, 8 May 2024 (UTC)

 * One other idea: right now, and then once at the start of each year, briefly use the same round-robin-esque move technique that keeps each new month's GP on the watchlist of everyone who watchlisted the previous month's GP, to move the year's Tech News page to here so that everyone who watchlists the GP (and is presumably interested in technical matters) also has the Tech News page on their watchlist. If that page is only updated about once a week, compared to the GP being updated many times a day, it should not be a burdensome thing to have in one's watchlist. (There is, of course, also the option of just getting Tech News delivered here, as suggested in the section above and on several prior occasions when it's happened that people failed to notice something which was technically announced in Tech News. This...honestly might be the better idea, since again, one update a week probably won't make the GP so large as to cause problems.) - -sche (discuss) 19:47, 8 May 2024 (UTC)
 * I think just having the Tech News delivered to the Grease pit would be fine. Benwing2 (talk) 21:38, 8 May 2024 (UTC)

Is it possible to output all of the IPA transcriptions of words with Quarry?
I want to go through all of the IPA transcriptions of words, check them and make sure they're correct, then correct the ones that are wrong. Is this possible to do with Quarry? I have already written some Python code, that goes through and sort of does that but of course it's not 100% accurate. I'm using one of the files uploaded here, I forget which one: https://dumps.wikimedia.org/enwiktionary/latest/ I realize I should have asked this question before I wrote the code, but, hey, live and learn. Also, I'm not very good with MySQL, in fact I just started learning it yesterday, so if you know of MySQL code that does this please post it. I also have a similar ambition to link all of the sublemmas to their superlemma. Is that also possible? Kylefoley202 (talk) 04:47, 9 May 2024 (UTC)

 * @Kylefoley202 The IPA transcriptions are contained in the page content itself, which is inside the "pages-articles" dump. This is an XML file. Parsing this content is something a lot of people have spent time thinking about! You might like to explore https://github.com/tatuylonen/wiktextract for instance. This, that and the other (talk) 10:49, 9 May 2024 (UTC)

In SQL Wiktionary category file, all words are in caps and does not distinguish between gas and GAs
In looping over this SQL file

enwiktionary-latest-categorylinks.sql.gz located here: https://dumps.wikimedia.org/enwiktionary/latest/

in Python (I can't figure out how to use this software https://quarry.wmcloud.org/) I find the line: 1. "129690,'English_non-lemma_forms','GAS\\nGAS','2022-12-18 20:54:34','GAS','uppercase','page'"

But you would think that 'gas' is a lemma, not a non-lemmas but then you realize that they are referring to this entry:

2. https://en.wiktionary.org/wiki/GAs

Why does Wiktionary put all words in all_caps on this sheet? How does Wiktionary know how to input that line 1 into website 2? Kylefoley202 (talk) 06:56, 9 May 2024 (UTC)

 * @Kylefoley202 what you have found is the category sort key, which is capitalised because sorting is case-insensitive. What you have to do is look at the page ID (that number at the beginning) and cross-reference this with the "page" table. See the MediaWiki database schema for more details. (Hint - the table names in the database schema diagrams are links to pages with much more info about the table.) This, that and the other (talk) 10:57, 9 May 2024 (UTC)
 * Cool, thanks for the reply. Kylefoley202 (talk) 06:32, 10 May 2024 (UTC)
 * @Kylefoley202 Just FYI, I would recommend not bothering with SQL but just directly reading the "pages-articles" file, which contains all the current content (as of the date of the dump) for all pages. It is pretty easy to parse, either using mwparserfromhell or just rolling your own parser. If e.g. you are interested in English IPA transcriptions, you just need to look for pages that have an en template in them and pull out the IPA content. Benwing2 (talk) 21:03, 13 May 2024 (UTC)
 * Also, because the file is big, you should use the XML SAX parser that's built into Python . Benwing2 (talk) 21:04, 13 May 2024 (UTC)

Template:pre categorization is broken when the second component is unlinked
See for an example. The category link markup shows up as plaintext. — S URJECTION / T / C / L / 11:22, 9 May 2024 (UTC)

 * @Surjection My suspicion is that the "term" (i.e. what's normally the link target) is being treated as the empty string somewhere in the process, and this is what gets used as the sortkey, since that's what's causing the category target to fail. There's special handling for the link itself in situations like this, since the alt text gets displayed instead of a failed link to nowhere, but there needs to be something for the sortkey as well. @Benwing2 is much more familiar with the affix module(s) than I am. Theknightwho (talk) 14:09, 9 May 2024 (UTC)
 * @Surjection@Theknightwho Should be fixed; let me know if you see any more issues with the affix code. Benwing2 (talk) 23:52, 11 May 2024 (UTC)

Edit request to MediaWiki:Common.css
Add a new line in between lines 27 and 28:, which fixes an issue where headings are cut off or compressed on narrow screens. Maybe Ioaxxere (talk) 15:41, 9 May 2024 (UTC)

 * @Ioaxxere can you share some screenshots or generally be more specific about what the problem is? If it's a MediaWiki issue it should be reported on Phabricator. This, that and the other (talk) 23:58, 9 May 2024 (UTC)
 * See https://imgur.com/a/GT6DE58. I don't think this is a Mediawiki issue as it seems that all the CSS is working as intended. Ioaxxere (talk) 02:32, 10 May 2024 (UTC)
 * @Ioaxxere Thanks for that. The issue looks to be specific to mobile (see T316670 where a  solution is suggested). Note that Common.css is not loaded on mobile, so we have to modify MediaWiki:Mobile.css instead. ✅ in . This, that and the other (talk) 04:15, 10 May 2024 (UTC)
 * Something similar happens on desktop when the viewport is extremely narrow: https://imgur.com/a/jWznzhF. Since this admittedly represents an extreme case, your solution is probably good enough (although I think it's better to have fewer lines of code). Also, what makes you say that common.css isn't loaded on mobile? I was able to change the mobile CSS with User:Ioaxxere/common.css. Ioaxxere (talk) 04:31, 10 May 2024 (UTC)
 * @Ioaxxere The issue on desktop looks different, as the letters don't spill down the page one by one like they do on mobile. In any event it's an extreme case as you say, since narrow viewports are pathological on desktop. As for the non-loading of MediaWiki:Common.css on mobile, see mw:Extension:MobileFrontend. This, that and the other (talk) 05:38, 10 May 2024 (UTC)
 * It turns out that the desktop case isn't so pathological after all — on 𑀏𑀓𑁆𑀓, the floated number box is wide enough to consume the header even on desktop. I strongly recommend that you implement my original request. Also, that documentation is clearly wrong, as it claims that mobile view also doesn't load user-defined stylesheets. If that were the case, I wouldn't have been able to post those screenshots. Ioaxxere (talk) 13:29, 10 May 2024 (UTC)
 * It turns out that my change causes some problems with talk pages. Could you change the selector to ? Ioaxxere (talk) 17:46, 10 May 2024 (UTC)
 * @Ioaxxere ✅. This, that and the other (talk) 07:00, 11 May 2024 (UTC)
 * The talk page problem hasn't been fixed since MediaWiki:Mobile.css still has the original selector. If Common.css is in fact loaded on mobile, then the Mobile.css code can be safely removed. Otherwise, it should be the same as in Common.css. Ioaxxere (talk) 18:54, 11 May 2024 (UTC)
 * @Ioaxxere ✅ that. This, that and the other (talk) 11:44, 12 May 2024 (UTC)
 * Thank you! I think everything looks good now. Ioaxxere (talk) 19:46, 12 May 2024 (UTC)

 * Regarding whether Common.css is loaded for mobile users: at least historically, it definitely wasn't, because over the years we've had to copy various bits of useful code from Common.css to Mobile.css because they were visibly not being loaded on mobile. (It would not surprise me if personal User/common.css pages function differently.) Surely we could just test this, though, e.g. by adding a test class to the main Common.css (but not Mobile.css) that makes things tagged with that class show up e.g. at 300% size and bright green, adding some text tagged with that test class to this discussion, waiting a while for caches to clear and such, and then seeing whether the text is in fact big and green on mobile. - -sche (discuss) 15:26, 12 May 2024 (UTC)
 * I'm curious to find out as well. I've tagged this text with the class, so if it looks unusual on the mobile skin then we'll know for sure. Ioaxxere (talk) 19:46, 12 May 2024 (UTC)
 * OK, and here's some text tagged with more complex styling. - -sche (discuss) 05:16, 13 May 2024 (UTC)
 * I recall someone mentioning there was an unavoidable 5-minute delay before changes take visible effect: sure enough, for the first 5-7 minutes (both before and after clearing my cache) I was not seeing the text display any differently than normal on either Desktop or Mobile, logged in or logged out, on Firefox or Chrome. However, I do now see the big green text (and slightly more complex vertical and backgrounded/highlighted text) on Desktop, whether logged in or out, on Firefox or Chrome, as expected. I do not see any of that styling when I use the Mobile version of the site in Firefox or Chrome from my computer, nor when I use my actual mobile, so indeed it appears that only Mobile.css and not Common.css is loaded for mobile users (as expected). But I'll leave the test classes in place for another couple days in case it's a caching issue or anyone wants to test anything else, other browsers, etc. - -sche (discuss) 05:34, 13 May 2024 (UTC)
 * Yeah I have run into that delay too. The message telling you to clear your cache is misleading and we should change it. Benwing2 (talk) 20:45, 13 May 2024 (UTC)
 * OK, I changed it. Benwing2 (talk) 20:48, 13 May 2024 (UTC)

 * I've removed the test class, and can offer the following data about how soon changes take effect: I removed the "big and green"-ification text at 22:14, and the text above was still big and green (unchanged) at 22:15–22:18; the text changed back to normal when viewed via Tor at 22:19 (just five minutes), but was still unchanged when I viewed it from my 'usual' browser until 22:24 (ten minutes). (The difference is, I assume, to do with the fact that I had no 'cache' in Tor, but had the big green text in my cache in my usual browser.) - -sche (discuss) 22:31, 17 May 2024 (UTC)
 * The selector is broken now due to the recent Heading HTML changes. It seems to work if I change the CSS line to:
 * Ioaxxere (talk) 18:10, 13 June 2024 (UTC)
 * Hmm, I wonder if this is also what has broken aWa and other gadgets that involve section headings. - -sche (discuss) 21:39, 13 June 2024 (UTC)
 * Hmm, I wonder if this is also what has broken aWa and other gadgets that involve section headings. - -sche (discuss) 21:39, 13 June 2024 (UTC)

Wrong categorisation of cites with an untranslated passage
en puts the page into Category:English quotations with omitted translation, and fr puts the page into Category:French quotations with omitted translation. This is wrong, because these cites do not have an explicitly omitted translation (see the description of the category). Moreover, the first case is doubly wrong, because the passage is English so it does not require a translation. This, that and the other (talk) 05:49, 10 May 2024 (UTC)
 * When I converted cite-book to use Module:quote, I made it automatically set - if no translation is provided to suppress the "Please add a translation" message for compatibility with the original behavior of cite-book. I didn't realize that it was generating categories, too. I can add handling for ! to suppress the nag and suppress the categorization unless anyone has a better suggestion for handling this. JeffDoozan (talk) 01:12, 11 May 2024 (UTC)
 * @JeffDoozan This use of ! seems a bit hacky and will expose this to the end user (which might not be wanted). What I might do instead is set an additional flag in the call to to suppress the request-for-translation category (note that the category is already suppressed if the language is English or Translingual). Benwing2 (talk) 22:03, 11 May 2024 (UTC)
 * It's causing a similar problem for 'Lithuanian' - Untranslated citing of a journal. --RichardW57m (talk) 11:21, 13 May 2024 (UTC)
 * @JeffDoozan Are you able to take a look at this in the next couple of days? Benwing2 (talk) 20:43, 13 May 2024 (UTC)
 * This should be fixed now. I added a 'noreq' param to to suppress the request for translation. JeffDoozan (talk) 21:31, 13 May 2024 (UTC)
 * @JeffDoozan Thanks! Benwing2 (talk) 21:36, 13 May 2024 (UTC)

While things are now better, how do I stop cite-journal with text being recorded as a quotation? The problem occurs in the use of Template:R:xsv:Zinkevičius85, which cites an article in Luthuanian that gives a Sudovian word list. Expanding lt by adding xsv switched the categorisation from terms with Lithuanian quotations to terms with Sudovian quotations, but these aren't quotations: they're mentions of Sudovian words. --RichardW57 (talk) 07:01, 14 May 2024 (UTC)

 * @JeffDoozan I think we need an extra cite-specific parameter for this; maybe 1 or 1 or something. Benwing2 (talk) 07:20, 14 May 2024 (UTC)
 * Should cites normally be treated as quotations? The term might not appear in the quoted citation at all!  --RichardW57m (talk) 13:13, 14 May 2024 (UTC)
 * I did try both 1 and on, but they seemed to leave it as being a quotation. Additionally, as it's a citation, the author came first, which caused a Wikimedia parsing problem because the author text is a Wikimedia link - the author has a Wikipedia article on the Lithuanian Wikipedia but not the English Wikipedia.
 * When we come up with a solution, it also needs applying to the reference at . --RichardW57m (talk) 13:37, 14 May 2024 (UTC)
 * What should happen when 1 is provided? Does it suppress all categories? Add them to a new category? Change the formatting? If it's just suppressing the categories, would using the existing 1 to suppress all categorization work? JeffDoozan (talk) 14:10, 14 May 2024 (UTC)

Early access to the dark mode (mobile web, logged-in)
Hi everyone, as announced in November, the Web team at the Wikimedia Foundation is working on dark (sometimes also called night) mode. Now, we have released the feature for logged-in users of advanced mobile mode across all wikis for testing purposes. But don't worry, the new feature is not disruptive! (See the "known limitations" section below.) It's just important for us to work together with you before we release this feature to a wider audience. Our goals for the early rollout are to:

 * Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
 * Get your help with flagging bugs, issues, and requests
 * Work with technical editors to adjust various templates and gadgets to the dark mode

Go to the project page and the FAQ page to see more information about the basics of this project.

Known limitations of the initial release

 * Currently, dark mode is only available on mobile, for logged-in users who have opted into advanced mode, as an opt-in feature.
 * Gadgets may initially not work well with dark mode and may have to be updated.
 * Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.

What we would like you to do (the broad community)

If you have questions - ask us! Also, where appropriate, consider linking to the Recommendations for dark mode compatibility on Wikimedia wikis on pages explaining how to define colors in code. Soon, this page will be marked for translation. We would like to emphasize that the recommendations may evolve. For this reason, we are not suggesting to create your local wiki copies of recommendations. At some point, the copy could become different from the original version.

What we would like you to do (template editors, interface admins, technical editors)

When most bugs are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. To make this happen, we need to work together with you on reporting and solving the problems.

 * 1) To turn it on, use the mobile website and go to the settings part of your menu and opt into advanced mode, if you haven't already. Then, set the color to dark. (Later, we will be allowing the device preferences to set dark mode automatically).
 * 2) Next, go to different articles and look for issues:
 * 3) * If you have noticed an issue with a template but do not know how to fix it
 * 4) *# Go to the recommendations page and find a relevant example
 * 5) *# If no relevant example is available or you're not sure of the fix, contact us
 * 6) * If you want to debug many templates in dark mode
 * 7) *# Go to https://night-mode-checker.wmcloud.org/ and identify templates that need to be fixed. The tool flags the top 100 most read articles.
 * 8) *# Go to the recommendations page and find a relevant example
 * 9) *# If no relevant example is available or you're not sure of the fix, contact us
 * 10) * If you want to identify problems beyond the top 100 articles.
 * 11) *# Install the WCAG color contrast browser extension (Chrome, Firefox) and visit some articles. Use it to identify problems
 * 12) *# Go to the recommendations page and find relevant examples
 * 13) *# If no relevant example is available or you're not sure of the fix, contact us
 * 14) * If you have a bug report for dark mode that is not related to templates
 * 15) *# Take a screenshot of what you are observing.
 * 16) *# Contact us. If possible, please write down your browser version and operating system version.

Thank you. We're looking forward to your opinions and comments! SGrabarczuk (WMF) (talk) 15:29, 10 May 2024 (UTC)

 * Exciting. I tried it just now and notice the following things: as you say, WT:SB reports that it is only available in light mode. On mainspace pages, the few things I could think of to check all worked just as well in dark mode as in light mode. MediaWiki:Gadget-OrangeLinks.js works (in both light and dark mode) to turn a link orange if it is specifically 'tagged' with a specific language which isn't present on the linked page; conversely, whereas on desktop bare [[wikilinks]] like that are sometimes colored orange when they are implied to be pointing to a section which isn't present, on mobile this is not the case (probably just because whatever local en.Wiktionary functionality turns such links orange on desktop has been deemed by us too large or complex to turn on for mobile). In other words, on desktop, both [[suadero]] and en in this revision of rose meat show up as orange (as neither page has an English section yet), but on mobile only en is orange (and it is orange in both light and dark view), whereas [[suadero]] is blue. - -sche (discuss) 19:40, 10 May 2024 (UTC)
 * I guess I don't understand what the big deal is about dark mode. Back in the old old days of TRS-80's and such, "dark mode" was the only thing you got and people hated it, hence the switch to black-on-white text. Benwing2 (talk) 21:46, 11 May 2024 (UTC)
 * Me neither … — Sgconlaw (talk) 21:48, 11 May 2024 (UTC)
 * It's for people on phones or laptops in dark places, particularly to avoid eye strain or so as not to bother others. No, it's needless on desktops but can still be a personal preference. — LlywelynII  22:05, 16 May 2024 (UTC)
 * Right, so like “I’m in the middle of a movie but gotta find out the meaning of the word insufferable!” Ha ha, OK. — Sgconlaw (talk) 17:49, 17 May 2024 (UTC)
 * Well it can also be useful for people with particular neurologies. 'Sides, don't need to understand it to have it. Vininn126 (talk) 17:51, 17 May 2024 (UTC)

 * Or married users who relax (and protect their IRL relationships) by correcting nameless strangers on the internet, don't have free time before the kids go to bed, and can't stand most of reddit. Lots of specific use cases. — LlywelynII  02:20, 19 May 2024 (UTC)
 * Some issues I noticed at a cursory glance:
 * The coloured backgrounds for top3 and friends need to be inverted. But the text is still perfectly legible.
 * Same for the coloured backgrounds of the content of collapsible boxes like trans-top and practically all our inflection templates. However, this is not a big deal, as (a) the text is still legible, and (b) the boxes are initially collapsed so do not really interfere with the overall "dark" look of the page.
 * This, that and the other (talk) 11:41, 12 May 2024 (UTC)

 * Was just looking for this. I don't understand why it would only be enabled for mobile where the phone and apps themselves can already shunt everything to dark mode from it. Desktop/laptops are where it's actually needed on site. — LlywelynII  22:05, 16 May 2024 (UTC)
 * Hey everyone, I have an update: dark mode is now available in Vector 2022 as a beta feature: Accessibility for Reading (Vector 2022).
 * Just like previously, when we were releasing it on mobile, this is still an early rollout. The goals are the same: both technical volunteers and the Web team need a lot of space for collaboration on the existing code before dark mode may become available for logged-out users. The limitations of our dark mode haven't changed much either: we're still focusing on the main namespace. Later, the feature will be available on other namespaces.
 * Finally, our requests to you are the same: we're inviting technical editors to make the main namespace dark mode-friendly, and if you have any questions, we welcome your questions. Check out the Accessibility for Reading project page and the FAQ page to see more information about this project. Thank you!
 * (@LlywelynII, you're right, the mobile rollout was just the first step. Eventually, dark mode will be available for both logged-in and logged-out users on mobile and desktop.) SGrabarczuk (WMF) (talk) 17:13, 17 May 2024 (UTC)
 * It needs Vector 2022? Eh, thanks but no thanks. I like having usable space on the page... But yeah, keep at it and thanks for your work. — LlywelynII  02:23, 19 May 2024 (UTC)

Help needed with Template:RQ:Kojiki
This initially was for displaying bibliographic details and an optional first parameter for some unspecified text that was simply displayed if present. envisioned it as having an optional numeric first parameter for the volume number, and wrote the documentation that way. When converted it to use Module:quote, he assigned the first parameter to the section parameter.

The problem is that all but a couple of uses that had a first parameter had non-numeric text in it consisting of things like "Poem 1". When Poketalker added code to convert the section number in the first parameter to a section name, this caused ParserFunction errors in almost the entire transclusion list because the code did arithmetic on non-numeric text. I fixed a handful by adding a pipe to add empty first parameter, then got tired of it and posted on Poketalker's talk page to let them know about the problem. Their attempts at fixing the problem haven't been successful.

So, what can be done about this? After Poketalker's "fix" there are "only" 51 entries in Category:Pages with ParserFunction errors. That's unacceptable. I see a few potential ways out of this.

 * 1) Restore the code to do arithmetic on the first parameter and have a bot add a pipe in front of all non-numeric first parameters
 * 2) Figure out some way to check if the first parameter is numeric, and either apply the arithmetic selection code if it is or treat it the same way as the optional second parameter if it isn't.
 * 3) Get rid of the whole volume number concept and code, since only a couple of entries actually use it.

A secondary question is whether this even needs to use a module. It looks like most of the usage is of this template followed by the actual quotes and their translations (on separate lines using other templates). The following lines could be converted into parameters for an improved template, but without that, the module contributes nothing.

Also pinging, who originally created the template. Chuck Entz (talk) 17:38, 10 May 2024 (UTC)
 * Appears to have been resolved by Benwing2. — Sgconlaw (talk) 17:51, 17 May 2024 (UTC)
 * Thanks to @Chuck Entz for bringing this up and @Benwing2 for fixing the issue. I think I remember bringing up concerns about using Lua for this template, as it was quite simple to begin with, and the module's behavior didn't seem compatible with how the template was actually used.  Glad to hear it's been resolved. ‑‑ Eiríkr Útlendi │Tala við mig 18:53, 17 May 2024 (UTC)
 * For reference, here's the earlier thread:
 * Wiktionary:Grease_pit/2024/January#Lua-fication_of_simple_reference_templates_--_rationale?
 * It seems that sparked a longer technical discussion than I was aware of earlier (things IRL have kept me from spending much time here lately). ‑‑ Eiríkr Útlendi │Tala við mig 19:02, 17 May 2024 (UTC)

How to turn off the new thing on talk pages
e.g. "Latest comment: 22 hours ago | 1 comment | 1 person in discussion | Subscribe". How to get rid of this and go back to normal? Equinox ◑ 20:56, 10 May 2024 (UTC)
 * In "Preferences". I just turned off loads of features, including the crap you mentioned P. Sovjunk (talk) 21:45, 10 May 2024 (UTC)
 * Specifically, untick "Show discussion activity" at the bottom of the "Editing" tab of Special:Preferences, see above. - -sche (discuss) 22:47, 10 May 2024 (UTC)
 * Having it give "Latest comment" information in diffs is just bizarre. Not only is there better and more accurate information in the diff header, it treats the diff as the latest comment, even if you're looking at very old diffs. While it's technically true that the diff was (by definition) the latest comment as of the time on the diff, it's utterly pointless and somewhat misleading. Chuck Entz (talk) 01:28, 11 May 2024 (UTC)
 * @Chuck Entz Where does it give "Latest comment" info in diffs? Can you elaborate? Benwing2 (talk) 21:44, 11 May 2024 (UTC)
 * : The same place it does when you view a page the usual way. Under where it says "Wiktionary:Grease pit/2024/May: difference between revisions" is a link to the parent page "<Wiktionary:Grease pit". Below that is where the new system says something to the effect of "Latest comment [] hours ago by []". I've turned the new system off, so I can't give you specifics, but the number of hours ago and the author of the content apply to the diff being viewed, not the conversation as a whole. It kind of makes sense if you think of the diff being a snapshot of the state of the page as of the time of the edit, but it's redundant to the diff header:
 * Revision as of 14:44, May 11, 2024 edit undo thank
 * Benwing2 (talk | contribs)
 * (How to turn off the new thing on talk pages: Reply)
 * (Tag: Reply)
 * The above is the diff header for the edit I'm replying to, minus a couple of admin-only bits. I have a gadget enabled that adjusts time stamps to local time, so you'd have to add 7 hours to get the usual UTC. The new system would say something like "Latest comment 1 hour ago, by Benwing2", ignoring any later comments to the same topic. In this case there aren't any, but I seem to remember seeing a case where someone posted a reply, then someone else posted a reply, with only the first reply reflected when I viewed the diff for the first reply: i.e., if you posted a reply to a given topic, and Sgconlaw posted a reply to the same topic an hour later, it would say "Latest comment 2 hours ago by Benwing2" when I viewed the diff for your edit, but "Latest comment 1 hour ago by Sgconlaw" when I viewed the next diff. Chuck Entz (talk) 22:18, 11 May 2024 (UTC)
 * @Chuck Entz I see, now, yes. You have sharp eyes; I didn't even notice the "Latest comment" stuff at the very top of the page, only the one underneath individual section headers. Benwing2 (talk) 23:51, 11 May 2024 (UTC)
 * This is indeed bizarre and useless, from what I can see, which you and the site coders might be interested in due to my attention atypicalities. Not that I would pay attention to it. I was delighted when first seeing the new thing, while I also use Vector 2022 as the site skin. Fay Freak (talk) 23:29, 11 May 2024 (UTC)

 * Another problem: suppose I want to link to a specific section of a talk page. I think there used to be a table of contents, or a right-clickable link ("copy to clipboard") or something, but now I can't find a way to grab that section link. Equinox ◑ 12:16, 12 May 2024 (UTC)
 * I do have the anchor symbol giving me the link due to a gadget. Preferences → Gadgets → User interface gadgets → ⚓: add copyable anchor links to sections Fay Freak (talk) 12:21, 12 May 2024 (UTC)

 * Neat. I wonder why it says "undefined" when you hover the mouse pointer over the anchor icon! Equinox ◑ 12:23, 12 May 2024 (UTC)
 * Well, you should wonder, you have habitually coded websites, I assume, this is one of the things one notices then. I don’t read hover texts much. How people of your branch are wont to respect the tooltips in comics, rather than continuing information being hidden in such a way discontenting them, is beyond me: this is how it always looks to me. It should have a text for text-based browsing I guess, now somebody has to find where to add the source line. Fay Freak (talk) 12:45, 12 May 2024 (UTC)

 * I hate doing Web sites. I still spell it "Web site" because I am a Victorian Charles Dickens. But nobody wants a bloody Windows desktop app any more. sigh sigh. Equinox ◑ 19:52, 12 May 2024 (UTC)

Proper nouns, def=1 but where it's optional
See Talk:Leopards Eating People's Faces Party, latest thread by. Sometimes we want to specify "the" (def=1 parameter) but it's optional, not mandatory. Equinox ◑ 12:15, 12 May 2024 (UTC)

 * The quotations without "the" look like broken English to me. Ioaxxere (talk) 19:48, 12 May 2024 (UTC)

 * Okay but I have definitely seen "optional the" cases other than this one. Equinox ◑ 19:51, 12 May 2024 (UTC)
 * @Equinox @Ioaxxere Use ~; it should be documented on the en-noun page. Benwing2 (talk) 19:55, 12 May 2024 (UTC)

Kyūjitai spellings displaying as orange links
It seems that MediaWiki:Gadget-OrangeLinks.js is incompatible with ja-see, as the "Alternative spelling" box on Japanese kanji entries is displaying kyūjitai spellings as orange links despite the Japanese L2 header being present. See 嘘だろ and 尽くした. Binarystep (talk) 01:29, 13 May 2024 (UTC)

 * I suspect this is happening because those forms aren't categorized as either lemmas or non-lemma forms. Benwing2 (talk) 20:57, 13 May 2024 (UTC)
 * What's weird is that it only does this with kyūjitai spellings. Other alternate forms, such as hiragana spellings, categorize correctly. Binarystep (talk) 05:05, 14 May 2024 (UTC)
 * @Binarystep I think to fix this we should make kyūjitai spellings be either lemmas or non-lemmas. I notice for example that romaji spellings are considered non-lemmas and hiragana spellings are considered lemmas. Pinging Japanese editors: . Benwing2 (talk) 05:23, 14 May 2024 (UTC)
 * I don't know if changes have been made in the hour or so since Binarystep Benwing posted, but the kyūjitai, kana, and kanjitab all appear blue to me. I'm using Firefox web browser on a Windows 11 computer, if that's any clue. Cnilep (talk) 06:20, 14 May 2024 (UTC)
 * Still orange for me. I'm using Chrome on Windows 10, if that's relevant. Binarystep (talk) 06:23, 14 May 2024 (UTC)
 * @Cnilep They appear orange to me, too, after a couple of seconds for the OrangeLinks gadget to do its thing. Do you have that gadget enabled? Benwing2 (talk) 06:51, 14 May 2024 (UTC)
 * Oh, no, sorry, my mistake. I don't have the gadget turned on. Cnilep (talk) 07:01, 14 May 2024 (UTC)
 * I'm seeing orange links as well.
 * Given that kyūjitai spellings are the old, deprecated spellings, and that we put all the "main" info elsewhere, I think categorizing these as "non-lemmas" would probably be best. ‑‑ Eiríkr Útlendi │Tala við mig 18:56, 17 May 2024 (UTC)
 * That's not really how we treat non-lemmas in general, though. Theknightwho (talk) 23:49, 17 May 2024 (UTC)
 * Yeah I think the precedent here would be to make them lemmas, although I would be supportive of User:Nicodene's and User:-sche's proposal to treat alternative forms as a third type of term, neither lemma nor non-lemma but "alternative form" (on a language-specific level, and not so much for one-off alternative forms like in English, but for languages with systematic alternative forms either due to a lack of standardization at the time or due to spelling reform, as in this case). Benwing2 (talk) 23:52, 17 May 2024 (UTC)

Inflections wrongly doubled
Hi, In the page ドラマティック, I have noted that the romaji transcription of the inflections wrongly duplicate the inflections ("doramatikku na na" and "doramatikku ni ni", with twice "na" and twice "ni"), even though the Japanese forms are correct (ドラマティックな and ドラマティックに, with a single な [na] and a single に [ni]). The problem seems to come from the template. Can somebody please check? Thank you in advance. SenseiAC (talk) 12:27, 13 May 2024 (UTC)

 * @Theknightwho Could you take a look? This is caused by this diff you made last December. Benwing2 (talk) 20:55, 13 May 2024 (UTC)

Check for blacklisted images we're actually using
A while ago, a troll was adding 'bad' images to entries, so we (someone) copied Wikipedia's image blacklist over to MediaWiki:Bad image list. This included images that don't exist (deleted but never cleared out of WP's list; I cleared them out of ours), redirects (where if the troll wanted to use the image, they could, because only the redirect is on the list🙃), and images we're validly using which blacklisting broke. By chance, I've happened upon and been able to un-blacklist two (the nipple at nipple and swastika at Nazism); can someone check whether any other images on the "bad image list" are actually in use and thus need to be unblacklisted? - -sche (discuss) 06:56, 14 May 2024 (UTC)

 * File:Human buttocks.jpg is used on buttock. Binarystep (talk) 12:23, 14 May 2024 (UTC)
 * Anyone else find that image on buttock a bit glaring? I think the one at nipple is somewhat more tasteful. Benwing2 (talk) 06:46, 15 May 2024 (UTC)
 * Heads up that I replaced the latter with a crop. I don't think it changes your point, tho. —Justin ( koavf ) ❤T☮C☺M☯ 06:57, 15 May 2024 (UTC)

Template:Latn-def requires lowercase letter
and result in “The name of the Cyrillic script letter А.” and “The name of the Latin-script letter A/ .”, respectively, because  requires specifying the lowercase letter, whereas  does not; is this intentional? I noticed this issue in the Russian entry for И. J3133 (talk) 07:37, 14 May 2024 (UTC)

 * @J3133 It looks like User:Theknightwho did some hacking on the Cyrillic one in 2022, and part of that was changing it to not have a onecase flag to signal whether there's a lowercase equivalent, but rather checking the value itself. We should probably do the same for Latn-def. Benwing2 (talk) 06:48, 15 May 2024 (UTC)

Exporting Wiktionary's templates to another wiki
So I have my own local MediaWiki installation and I have a bit of a "dictionary" on it where I store words from my English idiolect and also my conlang. So far, it uses "approximations" of Wiktionary templates, not the full templates themselves, as I once tried to import all of Wiktionary's templates, but ran into issues, as the wiki itself has significant amounts of imported Wikipedia templates, and thus name conflicts arose.

Is there a page or guide somewhere about setting up your own Wiktionary? A diehard editor (talk) 02:40, 15 May 2024 (UTC)

 * @A diehard editor Almost certainly not. I've never heard of anyone doing this. Benwing2 (talk) 06:43, 15 May 2024 (UTC)
 * Well, I'm out of luck.
 * Anyways...
 * The only "Wiktionary for conlangs"-type site I've encountered looks to be Linguifex's Contionary, but they too take the same approach of approximating Wiktionary templates with markup - see Attian ethnema ("language"). Another entry even had a manually coded inflection table.
 * As for Wiktionary - adding support for another conlang should hopefully be easy. I know a little bit of lua, and when it comes to conlangs, Wiktionary's done it for Esperanto so it stands to reason I can do the same for my own conlang on my local instance.
 * I'm thinking I could possibly set up another MediaWiki instance and have the dictionary stuff over there. Maybe even make a "MediaWiki Conlang Starter Kit" that only has English in it and leave it up to the user to write their own Lua. Who knows? A diehard editor (talk) 07:55, 15 May 2024 (UTC)
 * Now that I think about it: the primary source of the difficulty is the immense amount of baggage Wiktionary templates have by having to support hundreds or thousands of natlangs whereas the typical conlanger would only need English support to start with and then a blank canvas to write Lua modules for their conlang. Perhaps conlangers are better off just writing the needed modules from scratch? A diehard editor (talk) 08:19, 15 May 2024 (UTC)
 * With no disrespect to your project intended, I hope you understand that we already stretched technovolunteers may not be able to spare the time to help you set up a hobby wiki on your own machine.
 * Having said that, new Wiktionaries do start up from time to time; just this year the Karakalpak Wiktionary started. I wonder if these communities would find it useful if we did have a guidance page (either here or on Meta-Wiki) on how to set up a basic infrastructure of templates. Otherwise they are expending what are probably limited technovolunteer resources to reinvent the wheel. This, that and the other (talk) 10:26, 15 May 2024 (UTC)
 * Do not worry, I do not expect any labor. I was only curious to see if there were already resources on how to do this. When I first installed MediaWiki back in February 2022, I did this with the knowledge that it'd be just me, the docs, and reverse-engineering Wikipedia templates that got me through.
 * I will forge ahead with my project by myself; implementing templates as needed. A diehard editor (talk) 15:21, 15 May 2024 (UTC)

Unsupported title issues
See, e.g., (the headword is “ : ”). An issue that may be related: ≯ shows the composition as “ >|> [U+003E] + ◌̸ [U+0338] ”. J3133 (talk) 14:02, 16 May 2024 (UTC)
 * Wow, so what it seems like is happening is that it's creating a link to a category, as you would like this: Category:Swedish lemmas to create Category:Swedish lemmas. What is really weird is that it isn't doing that for the Latin entry... These may need to be manually edited instead of using the templates in this instance. —Justin ( koavf ) ❤T☮C☺M☯ 20:53, 16 May 2024 (UTC)
 * Note that this issue occurs on ≭, ≮, etc. —Justin ( koavf ) ❤T☮C☺M☯ 20:55, 16 May 2024 (UTC)
 * There was another similar sortkey issue with unsupported titles above. Benwing2 (talk) 21:53, 16 May 2024 (UTC)
 * User:Theknightwho You might find this interesting. The issue is that is considered a diacritical mark to remove when sorting in Finnish, but not in Latin. I'm not sure why this is the case, but I added a hack in format_categories to fall back to  if the sort key ends up a blank string. Benwing2 (talk) 22:11, 16 May 2024 (UTC)
 * @J3133 not related to the issue with ≯. Benwing2 (talk) 22:13, 16 May 2024 (UTC)
 * @Benwing2 I assume it's because Finnish (and Swedish) use : as a suffix separator after abbreviations, in the same way English sometimes uses ' (e.g. see the declension table at ). Thanks for sorting it. Theknightwho (talk) 22:18, 16 May 2024 (UTC)
 * I see, makes sense. Benwing2 (talk) 22:24, 16 May 2024 (UTC)
 * The issue at ≯ looks to be a case of unsupported titles not being supported by character info. Theknightwho (talk) 22:25, 16 May 2024 (UTC)
 * Should be fixed. Benwing2 (talk) 04:14, 17 May 2024 (UTC)

Description of Category:Dialectal Southern Valley Yokuts
“Terms or senses in Southern Valley Yokuts as spoken in Dialectal.” J3133 (talk) 17:53, 16 May 2024 (UTC)

 * @J3133 Yeah it looks like User:TongcyDai used auto cat without checking to see if it produced sensible results. IMO in this case we don't need this category at all; just put the different regional varieties directly under Category:Regional Southern Valley Yokuts. Benwing2 (talk) 19:43, 16 May 2024 (UTC)
 * Sorry, I did not check carefully. Thank you for identifying this error. By the way, is the category "Dialectical XXX" used exclusively in Chinese? --TongcyDai (talk) 19:47, 16 May 2024 (UTC)
 * @TongcyDai Yes. It's a weird holdover, as we're currently double-categorizing some things under e.g. both Category:Mandarin lemmas and Category:Mandarin Chinese (the latter under Category:Dialectal Chinese). Benwing2 (talk) 19:57, 16 May 2024 (UTC)
 * May I assume that this category will be removed in the near future? TongcyDai (talk) 20:06, 16 May 2024 (UTC)
 * @TongcyDai At some point, yes; we're still figuring out how to get rid of it. Benwing2 (talk) 20:08, 16 May 2024 (UTC)
 * @Benwing2 Thank you, I'm really glad to hear that. TongcyDai (talk) 20:16, 16 May 2024 (UTC)

Template:CJKV and Template:ja-r
Hi can we please suppress the Japanese romanisation linking (Rōmaji) as in CJKV at and ?

It should just show "mendan", not "mendan" Anatoli T. (обсудить/вклад) 01:50, 17 May 2024 (UTC)

 * And why is that? We have romanji forms in the dictionary. Why wouldn't we link them? —Justin ( koavf ) ❤T☮C☺M☯ 01:58, 17 May 2024 (UTC)
 * @Koavf: Rōmaji spellings are not words, they are only a way to disambiguate homophones.
 * The only place Japanese and Mandarin romanisation are linked are language entries.
 * We don't link romanisations otherwise, including any automated ones in templates - Mandarin:, and Japanese . Anatoli T. (обсудить/вклад) 02:55, 17 May 2024 (UTC)
 * Are there other romanizations that we have as entries that are unlinked? —Justin ( koavf ) ❤T☮C☺M☯ 03:00, 17 May 2024 (UTC)
 * @Koavf: I have shown you, didn't I? or even the native template:  and . It's linked when you're linking, otherwise it's unlinked. The only romanisation I know, which is always linked is Gothic: . --Anatoli T. (обсудить/вклад) 06:38, 17 May 2024 (UTC)
 * I did not know that miàntán was an entry and sure enough, it is. If anything, I think that should be linked. Who is helped by having these romanizations not linked from the native script entry? I'm just struggling to understand why that's a better thing than including a link for the convenience. Do you think that we should have entries for these romanizations? If so, why is having them and not linking them a good thing? —Justin ( koavf ) ❤T☮C☺M☯ 06:42, 17 May 2024 (UTC)
 * Wait... When I go to 面談, miàntán is linked. Can you actually give me an example? —Justin ( koavf ) ❤T☮C☺M☯ 06:49, 17 May 2024 (UTC)
 * @Koavf: That's what I said originally. It's only linked in one place - the pronunciation section for Chinese Mandarin and headword for Japanese. Anatoli T. (обсудить/вклад) 06:52, 17 May 2024 (UTC)
 * So how does that answer my question? My question was: "Are there other romanizations that we have as entries that are unlinked?" and you gave me an example of one that's linked... In the past few comments you have written, "We don't link romanisations otherwise" and "It's ... linked". What am I missing here? —Justin ( koavf ) ❤T☮C☺M☯ 06:57, 17 May 2024 (UTC)
 * @Koavf The question is whether we have ones that are unlinked in link templates like l, which does apply to Chinese. Of course Chinese entries link to romanisations from the entries themselves, but that was always the case for Japanese as well. I doubt there are any languages that completely unlinked romanisations, which I wouldn't support, but no-one's advocating that for Japanese, so it's not relevant. Theknightwho (talk) 12:27, 17 May 2024 (UTC)
 * Addressing this specific question: "why is having them [romanizations] and not linking them a good thing?"
 * Romanized entries for languages that don't use the Latin script are, so far as I'm aware, pretty much always created as a kludge to get around defective search features in the MediaWiki platform we use. As the English Wiktionary, for input purposes, we can safely assume only that our users are easily able to input characters available on an English-language keyboard.  (There are obviously workarounds like individual glyph lookup and copy-paste, but these can hardly be called good usability.)  Entries like sakura only serve to direct readers to the native-script kana entries, and as such are only ever soft redirects.  These provide readers with basically no useful information, and as such, we do not link to romanized forms when using, , and other linking templates. ‑‑ Eiríkr Útlendi │Tala við mig 19:14, 17 May 2024 (UTC)

 * This change was recently introduced and is annoying. Could someone please pay attention and fix it? and our Lua editors @Benwing2, @Theknightwho. Anatoli T. (обсудить/вклад) 02:58, 17 May 2024 (UTC)

 * @Atitarev I've still not had time to look into this - sorry. I'll make it a priority. Theknightwho (talk) 12:11, 17 May 2024 (UTC)
 * @Theknightwho, @Benwing2: Hi. I read a lot of promises from you two regarding Asian language transliteration fixes.
 * The previous bug on the Japanese transliteration I reported was different: Grease_pit/2024/April.
 * I doubt anything gets fixed but I discovered that capitalisation no longer works either with "^" symbol . I doubt because it seems the modules have become so complicated that nobody, including creators or editors seem to be able to fix them, let alone enhance them any more. Anatoli T. (обсудить/вклад) 02:44, 27 May 2024 (UTC)
 * That's because you put it in the wrong place: 富士山 gives, as expected. Theknightwho (talk) 02:46, 27 May 2024 (UTC)
 * User:Theknightwho Can you give me and Anatoli a time by which you will look into this? If not, I will try to look into it but I have not touched this code in a long time. Benwing2 (talk) 02:49, 27 May 2024 (UTC)
 * @Benwing2 @Atitarev The next few days - I've not had a proper stretch of time to look at it properly, because it seems nontrivial. Theknightwho (talk) 02:51, 27 May 2024 (UTC)
 * @Theknightwho: You're right, thanks. My mistake. Just exposing romanisation is the problem and the previous bug on SoP translations. Anatoli T. (обсудить/вклад) 02:56, 27 May 2024 (UTC)

Headword links in Old English multiword reconstructions
Using ⟨*⟩ in Reconstruction:Old English/cattes minte and Reconstruction:Old English/Cristes mæsseæfen causes the headword to link to “Reconstruction:Old English/catt”, “Reconstruction:Old English/minte” and “Reconstruction:Old English/Crist”, “Reconstruction:Old English/mæsseǣfen”, respectively, and there seems to be no way to link to the unreconstructed entries instead (neither nor  works). J3133 (talk) 05:19, 17 May 2024 (UTC)

 * I found a workaround, it works if you type . Weylaway (talk) 20:40, 17 May 2024 (UTC)

How can I create a NavFrame which is open by default?
Ioaxxere (talk) 14:55, 17 May 2024 (UTC)

Adding a hotline for a citation
just tried to add a URL for a citation on a change I just made and it was flagged as harmful. Anything I am getting wrong? Galifrey1965 (talk) 21:44, 17 May 2024 (UTC)

 * @Galifrey1965 This filter prohibits adding external links for new users, which catches a lot of spambots creating accounts and then adding link spam. Benwing2 (talk) 21:48, 17 May 2024 (UTC)

Improving template for World Loanword Database (R:WOLD)
I'd like to add more references to the World Loanword Database to Swahili. There is a template already:. Currently the template only allows linking to all entries for a specific language, but I'd additionally like to link to a specific entry (e.g. https://wold.clld.org/word/72141734782825923). So I guess a #5 parameter could be added but I'm not sure about the best way to format the text.

Also, it seems the template parameters could be simplified great. We use  for Swahili. But really "sw" should be enough and the other parameters could be looked up in a table depending on the language (editor for this language, year, number to link to, e.g. "sw" is 1, "ro" is 8).

Can someone help me with this? tbm (talk) 07:06, 20 May 2024 (UTC)

Categories for terms with translations by languages
I'm wondering if there'd be use in having and its ilk categorize to "X language terms with Y language translations". Being able to watch a Recent Changes of that category would be quite useful for me, perhaps others. Would there be any technical issues with that? Vininn126 (talk) 08:58, 20 May 2024 (UTC)
 * - might be worth making them hidden, though, but I don't have strong feelings about it. Theknightwho (talk) 18:04, 20 May 2024 (UTC)
 * My only concern would be whether having 3000+ categories on a page like water/translations would cause issues. Benwing2 (talk) 21:04, 21 May 2024 (UTC)
 * @Benwing2 I believe a similar issue raised by @Catonif was that we have unsorted categories. A potential solution would be to make them hidden. Vininn126 (talk) 21:06, 21 May 2024 (UTC)
 * @Vininn126 My concern is more about whether this would put a significant load on some Lua restriction, even if they were hidden. Benwing2 (talk) 21:09, 21 May 2024 (UTC)
 * @Benwing2 That would be a bigger concern. Have we tested this directly? Vininn126 (talk) 21:11, 21 May 2024 (UTC)
 * @Benwing2 No, it wouldn't really. It's just a case of getting rid of the if-condition at Module:translations. That change adds 0.5MB of memory use and 0.6 seconds of loading time to water/translations, neither of which are particularly concerning given that it has 3 times as many translations as the page with the next-largest number, and about 20-30 times that of your average large translation section, so the difference on the vast majority of pages would be very small. Given that entries with hundreds of translations tend to have them split out to subpages anyway (which have more than enough buffer room to cope for the foreseeable future), I don't see this as being risky. Theknightwho (talk) 22:39, 21 May 2024 (UTC)
 * OK in that case I . Benwing2 (talk) 02:18, 22 May 2024 (UTC)
 * It's easy enough to find all translations for a given language using the regular search with  in the search box (here's a link to it that I have bookmarked). You can replace the "ang" with any language code. I got this originally from, and added a parameter to the linked version to list the most recently edited pages first. See Todo/Impossible translations for a page I'm developing that's based on it. Using this, I found bogus translations in an obscure Oscan Umbrian language added 9 years ago by a Malaysian IP (Special:Contributions/175.140.49.80), among other things. Chuck Entz (talk) 14:47, 22 May 2024 (UTC)
 * @Chuck Entz A proper regex would be quite a lot more complex (e.g. that one fails if someone's put ...), but these kinds of variations should be pretty rare. However, it's also not very user-friendly, whereas anyone can use categories. Theknightwho (talk) 14:54, 22 May 2024 (UTC)
 * @Chuck Entz I'm aware. I'm suggesting this for the potential of having a Recent Changes. Vininn126 (talk) 14:54, 22 May 2024 (UTC)
 * The "X" is not required, since all translations are of English terms. It would just be "Terms with Y language translations" or, perhaps clearer, "Terms with Y translations". (and of course they should be hidden.) This, that and the other (talk) 05:34, 23 May 2024 (UTC)
 * @This, that and the other That's not true. Interlingua has translation sections. Vininn126 (talk) 08:15, 23 May 2024 (UTC)
 * @Vininn126 WT:EL says that only English entries and Translingual taxonomic name entries may have translations. So Interlingua entries with translations should have those sections removed. I did a search for non-English, non-Translingual entries with translation sections and I only found palm (removed by me), Panda (malformed entry, needs fixing), ayran (removed by me) and Cardrona (tidied by me).
 * It's true that one might still wish to categorise translations from English separately from translations from Translingual, but this is complicated by the fact that the t template has no way of knowing what language section it is being used on. This, that and the other (talk) 09:51, 23 May 2024 (UTC)
 * Sorry, I didn't mean Interlingua, but I did mean Translingual. Vininn126 (talk) 09:54, 23 May 2024 (UTC)
 * Hah, I see! Makes much more sense now. This, that and the other (talk) 10:04, 23 May 2024 (UTC)
 * To be honest I don't really care if it's categorized by which language has the translation. It would be convenient if it weren't, actually. Vininn126 (talk) 10:19, 23 May 2024 (UTC)
 * @This, that and the other @Vininn126 I think it should just be "X translations", which we already have for maintenance purposes for four languages: see Category:Translations by language: English, Translingual and Undetermined should ideally be empty, whereas Min Nan is currently being split so this is a convenient way to track down any that need converting.
 * I don't see the point of distinguishing between translations on English or Translingual entries, really - the only reason any Translingual entries have translations at all is because they encompass English, meaning translations are useful. Theknightwho (talk) 19:45, 23 May 2024 (UTC)
 * So it seems the consensus is to not categorize by translated language, but to add categories, and make them hidden. Vininn126 (talk) 19:47, 23 May 2024 (UTC)
 * I'm not particularly in favour of "X translations". Our categories are mostly named so as to describe the entry or term itself, for example, "English eponyms" contains terms that are English eponyms, and "English transliterations of Mandarin terms" contains terms that are English transliterations of Mandarin terms. But the "X translations" category will not contain terms that are language X translations - it will contain (largely English) terms that contain language X translations. So it doesn't really fit the scheme. "Terms with X translations" seems to fit better. This, that and the other (talk) 02:30, 24 May 2024 (UTC)
 * Sounds fine to me. Vininn126 (talk) 09:09, 24 May 2024 (UTC)
 * Fine with me too. Benwing2 (talk) 18:45, 24 May 2024 (UTC)
 * If I'm being really pernickety it should be "Entries with X translations", but yeah, I agree with the overall logic of changing it from "X translations". Theknightwho (talk) 03:30, 25 May 2024 (UTC)
 * I settled on "Entries with translations of X terms" to be extra clear (e.g. Category:Entries with translations of Translingual terms). The four pre-existing "X translations" categories have now been changed over to the new format, but we should probably keep this thread open for comment for a bit longer before enabling it generally. Theknightwho (talk) 09:58, 25 May 2024 (UTC)
 * Thanks! Vininn126 (talk) 12:42, 25 May 2024 (UTC)
 * But I still think it'd be nice to have the translated language category, so I can keep an eye on Polish translations. Vininn126 (talk) 12:44, 25 May 2024 (UTC)
 * @Theknightwho I think I'm still a bit confused by this naming scheme. For example, dragon is in Cat:Entries with translations of Translingual terms, but it has a translation from English into Translingual - there is no "translation of a Translingual term" on that page. This, that and the other (talk) 23:08, 25 May 2024 (UTC)
 * @This, that and the other The entry itself is the translation, but it sounds like this doesn't clarify things as well as I thought, so I'll change it to "Entries with X translations". Theknightwho (talk) 18:01, 26 May 2024 (UTC)
 * I'm not sure I see the need for "Entries" vs. "Terms". The entry is the page; yes, it has a translation, but the translations are associated with individual English terms on the page. Benwing2 (talk) 18:18, 26 May 2024 (UTC)
 * @Benwing2 Generally speaking, I've thought of it as:
 * "Term" = the specific link/headword (e.g. Russian terms with redundant transliterations). In many cases, there might not be an entry for the language on the page.
 * "Entry" = the L2 section (e.g. English entries with incorrect language header). The issue relates to the entry as a whole, which applies here as it's the entry that has X translation (though it's a weird case, as it's really "[English] entries with X translations").
 * "Page" = the whole page (e.g. Pages with module errors).
 * We're definitely not consistent with it, though. Theknightwho (talk) 18:23, 26 May 2024 (UTC)
 * It seems this distinction is the one made in maintenance categories, but not elsewhere, where "terms" predominates over "entries" e.g. in etymology categories. In particular there are almost no categories beginning with "English entries ...". My thought here is that a given English L2 section may have several subsections for different POS's, etymologies, etc., and each one has a translation; the translation is not associated with the L2 section as a whole. Benwing2 (talk) 18:55, 26 May 2024 (UTC)
 * @Benwing2 These are maintenance categories, but that is a good point. Alright, let's make it "terms", especially if we're going to move them out of maintenance categories. Theknightwho (talk) 20:02, 26 May 2024 (UTC)
 * I'm a bit confused. Does this enable one to look at, say, "Entries with Polish translations"? Vininn126 (talk) 18:44, 26 May 2024 (UTC)
 * @Vininn126 Not yet - we were already categorising translations in English, Translingual and Undetermined for maintenance (as there shouldn't be any) and Min Nan (as it's being split, so they need to be converted), so I was changing those in advance. Theknightwho (talk) 19:07, 26 May 2024 (UTC)
 * Alright - given everyone seems at least weakly in support, I think we can probably enable this. Theknightwho (talk) 19:48, 28 May 2024 (UTC)
 * Okay, I'm going ahead with this. Theknightwho (talk) 11:33, 31 May 2024 (UTC)
 * Before I do this, would it please be possible for you to bot-create a load of categories in advance? That way, we can avoid spamming the category sections at the bottom of large pages, as they won't be moved to the hidden section until they've been created. If you cover all the languages on water/translations, woman/translations and man/translations that should cover most of them, and the rest can be swept up in the usual way. The format is "Category:Terms with X translations". Theknightwho (talk) 12:51, 31 May 2024 (UTC)
 * @Theknightwho This is running. There are about 3,500 categories to create and since I'm using the script I normally use to create categories in Special:WantedCategories, which expands auto cat on the page before creating it (to make sure there's no error), it's a bit slower than it could be (~ 3 seconds per category, vs. 1 second if I just created the categories without any checking). So it might be done in about 3 hours. Benwing2 (talk) 22:05, 31 May 2024 (UTC)
 * @Benwing2 Great - thanks. Theknightwho (talk) 22:05, 31 May 2024 (UTC)
 * Good news everyone! Vininn126 (talk) 22:06, 31 May 2024 (UTC)
 * FYI there are still several categories needing creating. I am doing all the categories found on any of the translation subpages; this adds about 380 more, let's see if that's enough. Benwing2 (talk) 02:44, 1 June 2024 (UTC)
 * This will be a great tool for me to monitor Polish even more. Vininn126 (talk) 10:31, 1 June 2024 (UTC)
 * This will be a great tool for me to monitor Polish even more. Vininn126 (talk) 10:31, 1 June 2024 (UTC)

WiktCountryFlag gadget not working on MonoBook
It seems to be working as intended on Vector Legacy skin, but not on MonoBook. Tested without any add-ons turned on, on Opera GX and Microsoft Edge. Olioliluaaa (talk) 19:46, 22 May 2024 (UTC)

Fix strange UI
This is something strange in your UI, a message box inside an error box:

I would advice removing the wrapping from MediaWiki:Abusefilter-warning-redirect to get this look: JWBTH (talk) 10:46, 23 May 2024 (UTC)

Polish inheritance/descendants
I have seen a number of Old Polish entries giving a Polish descendant with the linked Polish term not linking to Old Polish, or even Proto-Slavic entries linking directly to Polish when the Old Polish term linking to PS. Would it be possible to generate a list of terms in these languages so I can fix them? Vininn126 (talk) 11:43, 23 May 2024 (UTC)

 * @Vininn126 Don't quite understand what you're referring to, can you give an example? Benwing2 (talk) 19:35, 23 May 2024 (UTC)
 * @Benwing2 . You can see that the Old Polish entry had already existed, I believe even with a descendants section, but was not in the Polish etymology. Vininn126 (talk) 19:37, 23 May 2024 (UTC)
 * @Vininn126 That's something I wanted to do for other languages. Maybe I can start with Polish and expand it later. I'm fairly busy this coming week but I can do it in early June if nobody else has done it by then. tbm (talk) 05:14, 25 May 2024 (UTC)
 * @Tbm Let me know. Vininn126 (talk) 08:40, 25 May 2024 (UTC)
 * @Vininn126 sent, see Discord tbm (talk) 07:29, 6 June 2024 (UTC)
 * Cheers! Vininn126 (talk) 09:11, 6 June 2024 (UTC)

Alchemical symbols wrongly categorized as emojis
Latin words containing alchemical symbols (e.g., ) are being automatically categorized in Category:Latin terms spelled with emoji, although these symbols are not emojis. But this only happens to entries with multiple letters; if the entry is a single symbol (e.g. ), it doesn't get categorized at all.

An exception is, which is correctly categorized in Category:Latin terms spelled with ☽. But by itself remains uncategorized. Jcitawy (talk) 10:09, 24 May 2024 (UTC)

 * @Jcitawy Not categorizing single-symbol pages into terms spelled with emoji is intentional, but as for categorizing alchemical symbols, the list of emojis is in Module:headword/page and it just consists of a large range for plane 1, which includes lots of non-emoji symbols. It should be updated with the actual Unicode list, I think. Benwing2 (talk) 22:14, 25 May 2024 (UTC)

WT:ACCEL not working any more?
I don't seem to get the "green links" for accelerated plurals and inflections any more. Why is that? Equinox ◑ 20:20, 24 May 2024 (UTC)

 * Seems to be working for me, looking at Polish verbs. Vininn126 (talk) 21:55, 24 May 2024 (UTC)

 * How can I diagnose the issue that affects me but not you? Equinox ◑ 21:57, 24 May 2024 (UTC)
 * It's probably related to the headword, as something that's different between our situations. Vininn126 (talk) 21:58, 24 May 2024 (UTC)
 * @Equinox Can you give an example page where it's not working? Theknightwho (talk) 22:05, 24 May 2024 (UTC)

 * All of them: any noun or verb page with non-existent inflections that should be green. I don't have one to show right now because I've been creating them manually. Equinox ◑ 22:08, 24 May 2024 (UTC)

 * You can try (no plural yet). Equinox ◑ 22:10, 24 May 2024 (UTC)
 * It's green for me, and the clicked link generated an accelerated page. Vininn126 (talk) 22:11, 24 May 2024 (UTC)

 * In my browser logs I see: "Exception in module-execute in module ext.gadget.AcceleratedFormCreation: startup.js:319". Is this line number helpful? Equinox ◑ 22:14, 24 May 2024 (UTC)
 * @Equinox It's working for me, but I don't know if it's a browser issue (since acceleration relies on JS). What browser are you using? Theknightwho (talk) 22:15, 24 May 2024 (UTC)

 * Latest Chrome on Win10. The thing that shows the previous and next headwords above the entry ("aardvark - abacus - etc.") is also not working. Equinox ◑ 22:16, 24 May 2024 (UTC)

 * More: "Error: This entry seems to be formatted incorrectly. Does it have a language and part-of-speech header? at getPartOfSpeech (ext.gadget.AcceleratedFormCreation-script-0.js:78:10) at createAccelParam (ext.gadget.AcceleratedFormCreation-script-0.js:96:20) at storeAccelParam (ext.gadget.AcceleratedFormCreation-script-0.js:114:21) at HTMLAnchorElement.eval (ext.gadget.AcceleratedFormCreation-script-0.js:231:5) at Function.each (jquery.js:383:19) at jQuery.fn.init.each (jquery.js:205:17) at eval (ext.gadget.AcceleratedFormCreation-script-0.js:176:19) at fire (jquery.js:3223:31) at Object.add [as done] (jquery.js:3282:7) at css (ext.gadget.AcceleratedFormCreation-script-0.js:17:37)" Equinox ◑ 23:16, 24 May 2024 (UTC)
 * It seems to be working for me too. I just used it about an hour ago. — Sgconlaw (talk) 23:21, 24 May 2024 (UTC)

 * Why might the multiple scripts be broken only for me (several days now)? Equinox ◑ 00:29, 25 May 2024 (UTC)
 * I suspect something in your User:Equinox/monobook.js is the culprit. You can safely get rid of, as this has been superseded by a gadget that can be enabled in your Preferences. The same applies to  , although in that case you may need to turn the gadget on yourself after removing it from your monobook.js. There is also User:Equinox/common.js to consider, although the script being loaded here (which has also been superseded by a gadget and can be removed) seems less likely to be at fault. This, that and the other (talk) 00:44, 25 May 2024 (UTC)
 * And just to be sure, you are still using the Monobook skin? (*shudder*) This, that and the other (talk) 00:45, 25 May 2024 (UTC)
 * Yes, I was about to suggest that it could be that some combination of gadgets has started to cause an issue for some reason (that happens from time to time!), and I seem to recall that simultaneously loading a gadget both via Special:Preferences and via explicitly loading it in one's .js has caused issues before, if you're doing that with any gadgets. I don't have the "aardvark - abacus" gadget you mention, for example, so if that or some other gadget has started interacting badly with OrangeLinks for some reason, that could explain why you have the problem and I don't. One idea is to turn off all non-default gadgets, clear your cache, turn OrangeLinks back on and see if it works (and steadily turn gadgets back on to narrow down which one is causing failure, iff that's the issue). (You don't have any browser add-ons like NoScript that would be preventing javascript from running, do you? I recall certain antivirus software blocked various users including me from accessing Janus directly a while ago.) OrangeLinks is working for me, even on bungey, even in Chrome. - -sche (discuss) 00:49, 25 May 2024 (UTC)
 * I do think it's the usage of a different skin. I use Timeless, and it also doesn't work for me. (Also, Monobook is fine.) CitationsFreak (talk) 03:15, 25 May 2024 (UTC)
 * Oh, good point! I hadn't thought to actually check whether the WT:ACCEL script fails in Monobook. And for me it does fail. I've tried repairing it with this change., please try now. This, that and the other (talk) 04:25, 25 May 2024 (UTC)
 * It works for me. CitationsFreak (talk) 04:30, 25 May 2024 (UTC)

 * Thanks. I removed from my Monobook.js "User:Dixtosa/nearby.js" and "User:Conrad.Irwin/creation.js"; then in the gadget settings I observed that "Add accelerated creation links..." was already enabled, and then I enabled "Add links to nearby entries". Cleared cookies. Now the accelerated (green/orange) links are working again, though I still don't have the 'nearby' links for some reason. Equinox ◑ 09:52, 25 May 2024 (UTC)

 * So, ACCEL is fine now, but still a problem: can no longer see the "nearby" links (aardvark - abacus - ...). Adding Monobook.js "User:Dixtosa/nearby.js" does not help, and enabling "Add links to nearby entries" in preferences does not do anything. How to diagnose this issue please? Equinox ◑ 22:49, 25 May 2024 (UTC)
 * No doubt it is a similar problem with the Nearby script/gadget on Monobook. I will look at it later. In the meantime, can you verify it still works on Vector: https://en.wiktionary.org/wiki/aardvark?useskin=vector This, that and the other (talk) 03:50, 26 May 2024 (UTC)
 * : Wikipedia? Chuck Entz (talk) 04:32, 26 May 2024 (UTC)
 * Whoops, fixed. This, that and the other (talk) 09:38, 26 May 2024 (UTC)

 * Yep, works in Vector (but I don't much like that "skin" because it wastes space and hides some links behind dropdowns, requiring extra clicks and "where's it going to pop up" guesswork). Equinox ◑ 09:42, 26 May 2024 (UTC)
 * @Equinox try again now. Should be fixed after this. This, that and the other (talk) 22:47, 26 May 2024 (UTC)

TOC funny
At https://en.wiktionary.org/w/index.php?title=Wiktionary:Tea_room/2024/May&oldid=79423980, clicking "top" in the TOC actually takes you to the top of the page, not to the entry "top"! Mihia (talk) 19:47, 25 May 2024 (UTC)

 * Yes, this is a feature (or bug, if you prefer) of Mediawiki, the anchor #top or #Top takes you to the top of any wiki page (presumably it was designed with Wikipedia in mind, where the tops of articles don't have headers, and no section is likely to be titled "Top"). (BTW another thing I'd love people to learn not to use in section headers is unnecessary template markup, as it makes the section harder to reach, e.g. after you edit it, the software can't take you to the section so it just dumps you at the top of the page: try null-editing Grease_pit/2024/March, or indeed try clicking that link, which doesn't work.) - -sche (discuss) 20:42, 25 May 2024 (UTC)
 * @User:-sche Are you saying that for pages such as this one? DCDuring (talk) 02:06, 26 May 2024 (UTC)
 * Yes...? Any Wiktionary or Wikipedia page you navigate to the anchor #top of, you will be taken to the top of, even on e.g. ru.Wikt where "top" isn't a Russian word; it's a Mediawiki feature. (And any time you use == template syntax like this == in a header, it borks some of the usual linking/editing behavior, due to another characteristic of Mediawiki.) - -sche (discuss) 02:59, 26 May 2024 (UTC)
 * @-sche So MediaWiki does a pretty good job of stripping wikicode from headings when creating anchors, but the problem is that it does a bad job doing the same with links, which is where the mismatch creeps in. It's possible to work around it, but you generally need to do it via a template/module for it to be reliable. Theknightwho (talk) 21:02, 25 May 2024 (UTC)
 * Perhaps there's some way for the js to spot when a section title is identical to one of Wikimedia's user-interface anchors, and change the target to some kind of alias- maybe the thread id? as for the problem of template syntax in the headers: it could certainly be solved by an abuse filter that explains why that's a bad idea and how to do it correctly. The only problem is that it would be rather user-unfriendly and might discourage participation by less Wiki-savvy users. Chuck Entz (talk) 21:12, 25 May 2024 (UTC)
 * @Chuck Entz So this should be raised at the Phabricator, but I expect the best solution is to do something similar to what's done when multiple headings are the same, which is to give any subsequent anchors an index number (e.g. if "Heading" appears twice, the second one has the index "Heading_2"). In the case of "top", the software just needs to assume any page already has a heading called "top" at the start (i.e. it needs to start the index at 2).
 * I've noticed it's inconsistent, though: in my browser, if there's a heading called "top" in the TOC, clicking it works correctly, but that means that the implicit "top" anchor at the top of the page now no longer works. Either way, it's a problem. Theknightwho (talk) 19:01, 26 May 2024 (UTC)
 * I've noticed it's inconsistent, though: in my browser, if there's a heading called "top" in the TOC, clicking it works correctly, but that means that the implicit "top" anchor at the top of the page now no longer works. Either way, it's a problem. Theknightwho (talk) 19:01, 26 May 2024 (UTC)

Userspace pages in Category:Pages with ParserFunction errors
The page User:Santi2222/test is currently in CAT:PFE. Nothing unusual about that- there are certain userspace pages that pop up there all the time. The difference is that it only takes a null edit to put the others into Category:Pages with ParserFunction errors/hidden, but so far that doesn't work for this one.

I realize that it's much more complicated setting the categorization behavior for ParserFunctions than it is for Lua/Scribunto errors. I'm guessing that this particular error got missed when the relevant code was added to all the Mediawiki error-handling pages, or there's something that 's MW-error-handling template isn't dealing with right.

This isn't urgent, since there are very few userspace pages involved, but it could eventually lead to problems. Chuck Entz (talk) 22:52, 25 May 2024 (UTC)

 * @Chuck Entz This is related to the issue that came up in the last thread about this, where MediaWiki treats the pagename as "Special:BadTitle" when handling parser function errors unless a (non-parser function) error occurs somewhere further up the page (e.g. a Scribunto error). If I put a bad #invoke: at the top of the page, it starts categorising it correctly, for example (but not if I put it below).
 * We could make it so that the "Special" namespace is treated as hidden by default, but that's probably a bad idea, because then errors on mainspace pages that suffer from this issue will start going in the hidden category as well.
 * Until the error's fixed upstream in the software, there's nothing we can do, unfortunately; this problem affects all the magic words we were using with the old system as well, so it's not a consequence of the new Lua module. Theknightwho (talk) 22:58, 25 May 2024 (UTC)
 * Until the error's fixed upstream in the software, there's nothing we can do, unfortunately; this problem affects all the magic words we were using with the old system as well, so it's not a consequence of the new Lua module. Theknightwho (talk) 22:58, 25 May 2024 (UTC)
 * Until the error's fixed upstream in the software, there's nothing we can do, unfortunately; this problem affects all the magic words we were using with the old system as well, so it's not a consequence of the new Lua module. Theknightwho (talk) 22:58, 25 May 2024 (UTC)

Quotation templates always Wikipedifying author's names
What's the deal with this? I'd say more authors don't have 'pedia articles than do, so why is this on by default? Vininn126 (talk) 18:52, 27 May 2024 (UTC)

 * I had a discussion with about this (though not about whether it should be the default or not), which resulted in the ability to turn off the link using -. Actually, quotation templates are generally created for well-known authors, so it is probably more likely that they will have Wikipedia articles about them. Also, if we change the behaviour now we’ll have to go through all the quotation templates and check if the names need to be linked. Note that if one just uses, etc., there is no automatic linking. The linking only occurs when “Module:quote|call_quote_template” is used. — Sgconlaw (talk) 18:57, 27 May 2024 (UTC)
 * Turning them on automatically also means checking for any that are missing. Vininn126 (talk) 19:01, 27 May 2024 (UTC)
 * sorry, edit conflict. See my updated comment above. — Sgconlaw (talk) 19:04, 27 May 2024 (UTC)
 * Well I'm asking because I'm working with Old Polish/Polish quotation templates, which are very helpful for me to have. Using to turn it off defeats the purpose for me. Vininn126 (talk) 19:06, 27 May 2024 (UTC)
 * is this because the English Wikipedia's coverage of Polish authors isn't great? If there are articles on the Polish Wikipedia, you can link to them like this: pl:Aleksandra Ziółkowska-Boehm. — Sgconlaw (talk) 19:41, 27 May 2024 (UTC)
 * @Sgconlaw Partially, but many are fairly unknown authors whom we know just because they signed it, like for Old Polish. Vininn126 (talk) 19:42, 27 May 2024 (UTC)

 * I hope that this is not used at all for templates like quote-book. We already favor famous, older authors over those that speak and write the current English that our users probably want to know. DCDuring (talk) 12:30, 28 May 2024 (UTC)
 * I think (and would hope) the intention is to apply the module only to quotation templates, though I'm not sure as I didn't participate in a discussion about it. (Pinging who implemented this.) — Sgconlaw (talk) 21:47, 28 May 2024 (UTC)
 * I can only hope that it doesn't happen accidentally. DCDuring (talk) 23:16, 28 May 2024 (UTC)
 * This was a feature of Module:quote before I made any changes to that module, but I'm sure it became more visible after I converted many RQ: templates to use Module:quote. FWIW, @Ioaxxere recently removed it: . JeffDoozan (talk) 14:02, 1 June 2024 (UTC)

Tool to resync translations
Over time, translation headings get out of sync with the English definitions. They may be in the wrong order, or may no longer discernibly match English definitions. Where there are many definitions, perhaps dozens, it is a bit of a drag to fix these manually. And then if one makes more changes, especially reordering of definitions, one has to do it all over again. An automated tool to put translations in the correct order where they can be matched, and flag up those that cannot be matched, would be a time-saver. (The matching would have to be "intelligent" because the translation headings are often not word-for-word the same as the English, e.g. they may be shortened, retaining only the most important keywords.) I guess this is asking quite a lot, but just in case anyone has the time and interest ... Mihia (talk) 21:05, 27 May 2024 (UTC)

 * @Mihia I already have a script to reorder translations inside of translation sections, which I've run every so often. But I think it would be difficult to implement reordering of translation sections to match definitions. (Not necessarily impossible. For example, I have a script to convert synonyms in Synonyms sections into inline synonyms. When there are multiple definitions, the script requires that (a) each synonym have a sense tag; (b) all synonyms can be matched to exactly one definition; (c) no two synonyms match the same definition. The matching works by making sure that all works in the sense tag are present in the definition, in the same order (but possibly with additional words in between). This works pretty well because typically the sense tags are compressed versions of the definitions. But I'm not sure the same can be said for translation headings.) Benwing2 (talk) 02:13, 28 May 2024 (UTC)
 * Right, the matching would be the difficult part. Sometimes it is difficult even for humans to decide what is, or originally was, supposed to match to what. Mihia (talk) 13:15, 28 May 2024 (UTC)

 * FWIW, someone did in the past float the idea of putting translations under the relevant sense in the same way as inline synonyms, etc. The problem is of course that while this might make the displayed page easier to follow (if the translations were collapsed by default and so not spreading out the senses unless someone wanted them to, whereupon they'd be right next to the relevant sense) and would eliminate the possibility of the translation-table headers and definitions going out of sync, and might hopefully also reduce the chances of the ordering going out of sync, someone who was e.g. only trying to reword several definitions at once might feel that the wikitext was now harder to look over, because it'd put screens and screens of 'irrelevant' wikitext in between senses. (OTOH, it seems like it'd be pretty easy, looking at the wikitext, to see where one sense ends, if it ended with a translations table, as the wikitext of those is usually pretty distinctive, lots of short lines and often non-Latin characters... it might actually be easier than the current system where one sense can be separated from the text by screens and screens of quotations which look, in the wikitext, little-distinct from senses, meaning I often just search and highlight-all # to find where each definition is ... I'm actually less opposed to this idea the more I think about it...) - -sche (discuss) 14:12, 28 May 2024 (UTC)
 * I think it's a horrible idea. It would make editing horrible and more error prone. It might also deter people from making improvements to the English definitions by overtly forcing them at every turn to make decisions about what to do with translations, often without any knowledge of the foreign-language words involved. Also, I think the flexibility of NOT always requiring rigid one-to-one correspondence, e.g. allowing coarser-grained translations and finer-grained definitions, is beneficial. Mihia (talk) 14:42, 28 May 2024 (UTC)

Template:a now uses Module:labels internally
I have incorporated the accent qualifiers from Module:accent qualifier/data into the labels data and switched a to use Module:labels internally. This means that a functions very similarly to a non-categorizing lb, although a few labels display and/or link differently when invoked from a instead of lb. (For example, Egyptian-language labels like display as "reconstructed Old Egyptian" etc. instead of just "Old Egyptian"; English-language label  displays as "General Australian" instead of just "Australia", and links to Australian English phonology instead of Australian English; Latin-language label  displays as "modern Italianate Ecclesiastical" instead of just "Ecclesiastical Latin", and links to Latin phonology and orthography instead of Ecclesiastical Latin.) I considered using different labels instead of making the same labels display differently, but it seemed like it would be too confusing e.g. to have two different "Australia" labels, two different "Ecclesiastical Latin" labels, etc. (I am thinking of following the same approach to get rid of certain labels that are specific to spelling of such as / and /, in place of just  and  .) Please let me know if you see any problems. Benwing2 (talk) 23:41, 27 May 2024 (UTC)

 * @-sche Sorry to ping you yet another time. I'm wondering if you can help me here with / etc. I notice that we actually have three related labels, and ; similarly for ,  and  and ,  and , and four labels , ,  and . The  vs.  labels link and categorize the same, and the display only differs in that the  labels just display as "Foo" whereas the  labels display as "Foo spelling" (except for , which strangely displays as "US" instead of "American"). It would be nice to have only one "Canada", "Australia", etc. label instead of 3 or 4. The approach I took with labels like  was to allow the labels to specify separate links and display forms when invoked using a instead of lb, and the same approach could be used here. But ...
 * Do we actually want the separate categories Category:American English and Category:American English forms? Having these two categories would necessitate having at least two labels e.g. vs., since both can be used with lb or tlb. This seems a recipe for inconsistency. I gather the intent is that terms that are specific to American English (i.e. have no corresponding version in British English) like dude (vs. bloke), wrench (vs. spanner) or elevator (vs. lift) would go into Category:American English, while terms that differ only in spelling (like favor vs. favour, categorize vs. categorise) go in Category:American English forms. But I suspect this distinction is not that well maintained. In fact there are 11,000+ terms in Category:American English and only about 600 in Category:American English forms, and the former includes terms like abastardized and ammonium sulfate that belong in the latter.
 * If we were to maintain two labels e.g. and, I think one way to deal with the latter would be to make it display "Canadian spelling" when invoked using lb or tlb, but just "Canadian" when invoked using alternative form of, spelling of, etc. Then, the latter templates would add the word "form" or "spelling" to whatever the label displays. Does this make sense?
 * Any other thoughts/concerns?
 * Benwing2 (talk) 02:02, 28 May 2024 (UTC)
 * Yeah, if "alternative form of", "standard spelling of" et al can know to delete "spelling" from the display form of "British spelling" — so displays "British spelling of foo" instead of "British spelling spelling of foo" — "British form", "Canadian form" etc can be reduced to aliases of "British spelling" etc (or perhaps eliminated); the "...form" labels were a kludge to deal with the display issue. (We should check that they're not being (mis)used in unexpected places, though; see the recent edit history of from A to Zed for example.) The reason for separating "American English" and "American English forms" is as you suspect, that it'd be weird/wrong to say that something like "realize" is an America-specific dialectal word, when in fact it's perfectly well used in Britain too, not only in speech (obviously) but even in writing (in that z spelling sic!) by people who follow "Oxford" spelling standards. My initial inclination is to keep America-specific dialectal terms and American spellings of common words separate and not merge them into one category, but hopefully more people can comment. - -sche (discuss) 03:09, 28 May 2024 (UTC)
 * OK, I implemented this, including automatically dropping the word "spelling" when invoked from alt form, standard spelling of and the like. There was only one place that needed to have a special display setting for the form-of templates, which is, using "US" as the display form for the form-of templates (although I haven't yet made the changes to the labels data; I need to check for misuses, as you mention). Benwing2 (talk) 01:59, 29 May 2024 (UTC)
 * There are in fact some places that use in lb or tlb. They are from A to Zee (points to from A to Z), maid of honor tart (points to maids of honour tart), maid-of-honor tart (points to maids of honour tart) and troop the color (points to troop the colour). The last one is just a spelling difference, while the others are slightly more. Does it make sense to use standard spelling of for the last one and alternative form of for the remainder? And is it OK to replace  with  in all of them? I notice for example in your edit summary in from A to Zed you say the label  should probably not be used once  and  are aliased, but I don't understand the logic here. Benwing2 (talk) 02:09, 29 May 2024 (UTC)
 * FYI to see where a label is used, go to e.g. Special:WhatLinksHere/Wiktionary:Tracking/labels/label/American form. I just added per-"mode" tracking as well, so that e.g. you can distinguish uses of in lb vs. tlb vs. a vs. form-of templates by visiting Special:WhatLinksHere/Wiktionary:Tracking/labels/label/American form/MODE, where MODE is one of  (for lb),  (for tlb),  (for a) or  (for form-of templates). However, since I just added this, it may take a few days before all entries show up on the relevant tracking pages. Benwing2 (talk) 02:25, 29 May 2024 (UTC)
 * BTW I went ahead and made the cleanups/aliases to the form-of labels; only four languages were affected (ch = Chamorro, de, en and pt). is now aliased to, but the tracking categories still work and the tracking categories for  show only the uses of this particular label. Benwing2 (talk) 02:30, 29 May 2024 (UTC)

 * Oh, my comment at from A to Zed was that I don't think we'd want the label to be "(British spelling) alternative form of" . My feeling was that it would either make sense to say  (if we view it as being more than just a spelling issue: it uses what could be considered a different word, which in any case also has a different pronunciation), or (if we do consider it to be just a spelling difference) then  . Perhaps I am mistaken! Yes, I would change the tart/troop entries as you suggest, moving "American spelling" et al out of the label and into the from=. If we wanted to be precise, I might be inclined to make all the singular ones point to one singular (for example, giving maid of honor tart, maid-of-honor tart, and maid-of-honour tart as alt spellings of maid of honour tart), and then make maid of honour tart an alt form of maids of honour tart, but this would require people to go through more clicks unless we double the templates up, like "alternative spelling of foo: alternative form of bar", so just making them all point directly to the one 'lemma' entry seems fine. - -sche (discuss) 17:48, 29 May 2024 (UTC)

Module:documentation causing module errors
There is currently a module error at Module:labels, apparently caused by  becoming executable when copied from a comment in the module. Since comments are by definition never executed, shouldn't all executable syntax in them be escaped? Chuck Entz (talk) 01:51, 28 May 2024 (UTC)

 * @Chuck Entz This was done intentionally so that you can put stuff like links to terms using m, templates using tl, etc. in the doc comments and have them executed/expanded so you get links etc. Possibly this could be changed; but it would be a significant change (since a lot of comments currently rely on it), and require extra syntax to specify the use cases that are currently handled using template expansion, and you'd still probably need syntax to force expansion of a template invocation. In this case, the raw call to a should be changed to a. Benwing2 (talk) 02:21, 28 May 2024 (UTC)

Multiple RfVs on a page
If the are multiple invocations of rfv and rfv-quote meriting separate discussions, we can currently disambiguate them using fragment, though I think it needs more guidance at rfv and mentioning at rfv-quote. However, the anchors on the page with the challenged items doesn't provide different anchors. Someone please fix that. It's causing a problem at where there are unrelated challenges to a quotation for the adjective and to alleged senses for the masculine noun. --RichardW57m (talk) 15:48, 28 May 2024 (UTC)

Shaozhou Tuhua
(?) Can we specify a font for Shaozhou Tuhua (class=Nshu) so that e.g. 𛉄 can be displayed? Currently the font for Nshu is unspecified in MediaWiki:Gadget-LanguagesAndScripts.css. --kc_kennylau (talk) 16:22, 28 May 2024 (UTC)

 * @Kc kennylau What font should be specified? Benwing2 (talk) 19:18, 28 May 2024 (UTC)
 * @Benwing2 The font would be for the Nüshu script (currently only used by Shaozhou Tuhua). There aren't many fonts that support it, but there's Noto Sans Nüshu, Noto Traditional Nüshu (difference explained towards the bottom here), and Unicode Nushu. I'd suggest listing them in that order, personally, for the sake of readability. Theknightwho (talk) 19:26, 28 May 2024 (UTC)
 * I would also suggest increasing the font size (at least to 120% matching Chinese, if not to 150% matching various other scripts); I installed those fonts, and at current size, it's only barely legible. - -sche (discuss) 20:21, 28 May 2024 (UTC)
 * Agree with increasing font size. --kc_kennylau (talk) 21:31, 28 May 2024 (UTC)

 * I believe that any modern web browser should be smart enough to comb through fallback fonts available on a device and locate the Noto font on its own, and hence specifying it manually would be a waste of code. —Fish bowl (talk) 03:04, 29 May 2024 (UTC)
 * I don't know what "smart" web browser you're using but I'm using Chrome and it does not automatically use a Noto font. --kc_kennylau (talk) 09:06, 29 May 2024 (UTC)
 * Yes, my experience is the same. When I had no Nushu fonts installed, and we had (and still have) no fonts set in the Gadget, I just saw 𛉄 as a box. When I had only the two Noto Nushu fonts installed, I saw them when I used Firefox (when logged in), but not Chrome (nor Firefox when logged out), AFAICT because we don't specify them in the Gadget. (Most interesting to me would be to find out what happens if we do specify fonts in the gadget and I don't have them installed: does the gadget specifying them prompt any browser to fetch them webfonts-style? I seem to recall there was an effort [by WMF?] to make that happen, but I don't know what came of it.) Interestingly, when I briefly installed Unicode Nushu to check its legibility (poorest of the three fonts, I agree with TKW), the text here started displayed as a box again. (It's back to using Noto in Firefox but being a box in Chrome, now that I've uninstalled Unicode Nushu again.) Besides being necessary for that, I think specifying the fonts also has a few other purposes. One is if, as in this case, we don't want Noto to be the last-reached fallback font some browsers fall back on (and others don't) if they don't have e.g. Unicode Nushu, rather we want to be sure that Noto Sans to be the first font chosen because the others are less legible. (Another is: if the user doesn't have all or any of these fonts installed, they check the list to see what fonts we have deemed as most installation-and-use-worthy.) If a user has all the fonts for all the scripts installed and has a browser/system that selects them automatically without needing to be told to, such a user could just individually opt out of / turn off the entire gadget, no? (It does not seem like any one part of it wastes code; they either need the whole gadget or don't need it at all, no?) - -sche (discuss) 15:59, 29 May 2024 (UTC)
 * Yeah I'm using Firefox. I take it back; I had no idea Chrome was so weird lol. —Fish bowl (talk) 21:21, 29 May 2024 (UTC)

 * OK, I've added Nshu to the Gadget (with correct font names at 16:25), and can offer some more data on how quickly changes to site-wide CSS files take effect (something else which was discussed recently) : looking at this page and at the page title and headword line of 𛉄, all of it was displaying as a box in Chrome (whether I was logged in or out) and in Firefox (when I was logged out), whether I viewed the desktop version of the site or the mobile version, until 16:30, when the headword line of 𛉄 started to display correctly when I viewed the mobile version of the site in Chrome (logged in). The headword line started to display correctly also in the desktop version in Chrome (logged in or out) at 16:33. However, in Firefox, when I am logged out, it still displays as a box (whether I view the desktop or the mobile version of the site) even as of the minute I post this comment. (It also displays as a box when I use an actual mobile device, presumably because I don't have relevant fonts loaded on that device.) Also, even in Chrome (and in all of the other scenarios mentioned), the actual page title itself (at the top of the loaded page), as opposed to the headword, still displays as a box, which I think is because script classes aren't normally applied to page titles, so we probably want to do the same kind of thing we do to make e.g. Mongolian page titles display correctly. TBD: why is the headword line (and page title) of 𛉄 still a box in Firefox (on desktop and on mobile) when I view it logged out? Do we not load the Scripts Gadget for logged-out users? (If not, why not?) (When I'm logged in, on Firefox, the page title and headword line displayed correctly as soon as I installed the relevant fonts, even before I added anything to the Gadget.) - -sche (discuss) 16:58, 29 May 2024 (UTC)
 * @-sche Thanks for doing this. I think 150% might be a bit too big - it's now way taller than the surrounding Latin text with Noto Sans Nushu. I think 130% is probably about right. Also pinging @Kc kennylau @Benwing2 @Fish bowl for thoughts. Theknightwho (talk) 00:15, 30 May 2024 (UTC)
 * Do you have any examples of Shaozhou Tuhua sentences, esp. those with mixed Nüshu and Latin, so I can see how they look together? Also, how do Nüshu and Chinese characters compare in height? If they are similar, it's probably fine even if the height of the Nüshu characters is taller than the Latin characters (since there are so many more of them and they're generally more complex). Benwing2 (talk) 00:50, 30 May 2024 (UTC)
 * I pulled a randomish selection of characters from the Nushu block, including some simple and some complex ones, and put them at User:-sche/sandbox5. You can add this to your CSS to see the different sizes. (Possibly I could've set the sizes manually on that one page, but you'll notice the "100%" and "not tagged" text [which should also be 100%] show up slightly differently, so I wanted to be sure and get whatever effect was gotten by assigning the size specifically in CSS.) I see this if I view the page itself at 100% zoom and the different lines of text at the levels of zoom indicated. This is if I view the page at 150% zoom. TKW is probably right that we could get by with 130% — or maybe 140% as is used for Mongolian? — if people use Noto Sans Nushu. (If people use either of the others, they likely need bigger font size: here's Noto Traditional, viewing the page at 150%, and here's Unicode Nushu.) - -sche (discuss) 02:45, 30 May 2024 (UTC)
 * @-sche I installed Noto Sans Nushu, and at 150% it looks a bit big; but strangely, the default shows up only at 100%. This is on Chrome 124, Mac OS Ventura 13.6. Here is my view of your test page: Is there no way in CSS to control the scaling at a per-font level? Benwing2 (talk) 03:24, 30 May 2024 (UTC)
 * Re "the default shows up only at 100%", you're referring to the "Nushu with no script tagging" line? That line isn't tagged with anything, not even the "Nshu" class our site-wide CSS sets fonts and sizes for. Re font size, OK, I'll reduce it to 130% soon. Are you able to make the pagetitles of Nushu-script pages be tagged with the Nshu script code (like Mongolian-script pages' pagetitles are tagged with their script code)? Currently, when I use Chrome, only the headword on 𛉄 displays, the pagetitle/h1 is still tofu, which I think is because it isn't being tagged with a script code. (In Firefox, everything including the pagetitle displays correctly when I'm logged in, and nothing at all displays—it's all boxes—when I'm logged out. Do we not set fonts for logged out users? Is this a consequence of moving script codes out of Common.css? Do we need to move them back?) - -sche (discuss) 04:14, 30 May 2024 (UTC)
 * @-sche I'm not sure why the script code isn't correctly tagged on 𛉄; I'll have to take a look at the headword code. As for the logged-out issue, maybe User:This, that and the other and/or User:Ioaxxere can answer, who seem to know more about CSS than I do? Benwing2 (talk) 04:29, 30 May 2024 (UTC)
 * @Benwing2 The font declaration for  is being properly loaded when I load that page, whether logged in or logged-out, but that CSS class isn't applied to the page title. The page seems to need a DISPLAYTITLE: set. From my quick look it's not clear why things are working for -sche in some configurations but not others... This, that and the other (talk) 05:36, 30 May 2024 (UTC)
 * @This, that and the other I fixed the page title CSS issue; or at least, it works for me on Chrome on a Mac. What is your browser and OS? Benwing2 (talk) 05:49, 30 May 2024 (UTC)
 * Thanks for fixing the page title issue. :) On the second issue: I've now realized it's different/weirder than I thought. What I had been doing was looking at pages (while logged in) in a regular Firefox window, and checking how they looked when logged out by opening a Private Browsing window (and a Tor window) and looking at those. However, I now notice that if I log out and look at the site in a regular Firefox window, everything displays. Conversely, if I log in while using a Private Browsing window, it's still tofu, and I notice that Glagolitic fonts are only applied to the Glagolitic text in Glagolitic when I'm in a normal Firefox window, but not when I'm in a Private Browsing window. So the issue appears to be that Private Browsing windows (and Tor) don't ... support/access fonts? Which I guess might be an intentional privacy feature of those browsers...? (The text, in all cases, is tagged with the correct class when I look at the page source.) So I guess it's fine, or at least not a Wiktionary problem. (When we were testing the "big and green" class recently, it displayed even in Private Browsing windows, and the Glagolitic size increase displays: CSS classes that have to do with font size or color seem to be applied, just not fonts.) - -sche (discuss) 05:55, 30 May 2024 (UTC)
 * @Benwing2 Chrome on Windows. The  class is now correctly applied to the page title in Chrome and Firefox, logged in and logged out. This, that and the other (talk) 07:14, 30 May 2024 (UTC)

quyanaa
quyanaa I recently created this entry. I don’t know why, but it shows up, under categories, as a Greenlandic word of Proto-Eskimo origin. I did not create this an cannot edit it. It is an Alutiiq word.

Help. RangerRichard (talk) 02:15, 29 May 2024 (UTC)

 * @RangerRichard The category is being generated by the kl template, as this template is used to denote a Greenlandic word that is derived from Proto-Eskimo . According to WT:LOL, the correct code for Alutiiq is , so this needs to replace.
 * Note also that your entry must include a headword-line template. After the part-of-speech header, add ems. Thanks for your contributions! This, that and the other (talk) 04:38, 29 May 2024 (UTC)
 * Ahh okay I got it RangerRichard (talk) 01:26, 31 May 2024 (UTC)

Category:Theodore Roosevelt and Category:en:Theodore Roosevelt
Please add to Category tree, as subcat of Individuals and US politics (−) (±) (↓) (↑) Purplebackpack89 03:06, 29 May 2024 (UTC)

 * Another editor suggested I "make a case" for the category's existence. The Theodore Roosevelt category should exist because there are more than a dozen words about, created by, or popularized by him. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 16:22, 30 May 2024 (UTC)
 * @Purplebackpack89 A category like this would be for terms about Theodore Roosevelt, not things coined by him. We have coinage for the latter purpose. Benwing2 (talk) 01:01, 31 May 2024 (UTC)

Category:Wars and Category:en:Wars
Please add to Category tree, as subcat of List of name categories, Historical events and War <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 03:09, 29 May 2024 (UTC)
 * Please also move the following categories from War to Wars:
 * American Civil War/en:American Civil War
 * American Revolution/en:American Revolution
 * Napoleonic Wars/en:Napoleonic Wars
 * Trojan War/en:Trojan War
 * Vietnam War/en:Vietnam War
 * World War I/en:World War I
 * World War II/en:World War II

Another editor suggested I "make a case" for the category's existence. The Wars category should exist because there are quite a few proper nouns that are Wars and contain the word "War". <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 16:23, 30 May 2024 (UTC)

Language dump
@Psioter has asked me if we could generate a data dump of my work for Masurian (well, also KamiruPL's!) so he can make a database. I'm assuming this would include things like IPA, the very little declension I have, etymologies, etc. Also, information in CAT:Masovia Old Polish could be interesting, if a bit scarce at the moment, as well as scatted. Could someone help? Vininn126 (talk) 18:50, 29 May 2024 (UTC)

 * @Vininn126 Are you just looking for a textual dump of the contents of all the Masurian lemma and non-lemma pages? That is easy enough to produce. Benwing2 (talk) 21:23, 29 May 2024 (UTC)
 * @Benwing2 (Let me ask Piotr) Vininn126 (talk) 21:25, 29 May 2024 (UTC)
 * @Benwing2 Pure wikitext apparently is fine. Vininn126 (talk) 23:21, 29 May 2024 (UTC)
 * @Benwing2 Also, probably fine to just stick to Masurian, no need for stuff from Masovian Old Polish. Vininn126 (talk) 08:11, 31 May 2024 (UTC)
 * How do I get the file to you or Piotr? Benwing2 (talk) 08:13, 31 May 2024 (UTC)
 * You can send it to my admin email and I can get it to him from there. Vininn126 (talk) 08:14, 31 May 2024 (UTC)
 * OK well, it's only 355K so I put it here: User:Benwing2/masurian-lemmas-non-lemma-forms Benwing2 (talk) 08:16, 31 May 2024 (UTC)
 * @Benwing2 Thanks! Vininn126 (talk) 08:17, 31 May 2024 (UTC)
 * Also see User:Benwing2/masovia-old-polish. Benwing2 (talk) 08:19, 31 May 2024 (UTC)
 * Thanks again. I've sent it over to him. Vininn126 (talk) 08:21, 31 May 2024 (UTC)
 * You can also use the Kaikki JSON lines dump produced by the wiktextract project, downloadable here: https://kaikki.org/dictionary/Masurian/index.html MrBeef12 (talk) 09:25, 31 May 2024 (UTC)
 * Cool, thanks! Also sent. Vininn126 (talk) 09:26, 31 May 2024 (UTC)

Italics don't work in t= parameter of form-of templates
Not sure how long it has been this way, but, for whatever reason, italics have stopped working when used anywhere in the  parameter of form-of templates like  and. See for an example of italics failing. Module:form of is the module responsible, but does anyone know where in the module this is happening or how to fix it? — Vorziblix (talk · contribs) 13:08, 30 May 2024 (UTC)

 * @Vorziblix If you go to Special:ExpandTemplates and put in the call to alt form on wokiya, you can see that the double apostrophes are in the output, meaning this has nothing to do with Module:form of. The reason rather is that the value of the t param is wrapped in the CSS class, and you can see from MediaWiki:Common.css that this CSS gloss sets which apparently overrides the italics. I think the reason for this setting is that  is also used in things like m, and I think the intention is that if used inside of italic text, the gloss shows up in an upright font to distinguish it from the surrounding italic text. But I'm not completely sure. Maybe someone more familiar with the CSS, like User:Ioaxxere or User:This, that and the other, can comment. To fix this we'd either have to change the definition of the CSS class  or use a different CSS class without this property. Benwing2 (talk) 01:11, 31 May 2024 (UTC)

Using with id= results in many extraneous template invocations
It seems that using the template with the   parameter results in the page that calls  invoking every single template on the page that  links to, sometimes causing hundreds of superfluous template invocations. See Reconstruction:Proto-Slavic/(j)azъ, where the calling of makes Reconstruction:Proto-Slavic/(j)azъ call an enormous number of templates. This seems suboptimal and pollutes the transclusion list of templates. This does not happen with, only , and does not happen unless the  parameter is used. Is this fixable, or just something inherent to how and  work? — Vorziblix (talk · contribs) 21:23, 30 May 2024 (UTC)

 * @Vorziblix User:Theknightwho can you comment here? I think this is due to your changes to this module to use Module:template parser, which seems to expand every template while parsing the page, even though it doesn't seem necessary here. Should we set a flag to the call to in Module:descendants tree to tell it not to expand templates? Benwing2 (talk) 01:13, 31 May 2024 (UTC)
 * @Benwing2 I think we've spoken about this before: the solution is to make Module:descendants tree be more specific about which sections it parses, instead of putting the entire page contents through the template parser. I think I suggested using in Module:utilities.
 * @Vorziblix To be clear about why this is happening: Module:template parser is not expanding every template on the page (which would effectively double the page load), but it checks whether the raw template name is a redirect in order to normalise it to the canonical form (i.e. l is normalised to link etc etc); this seems to count as a transclusion. The actual load of doing this isn't very much, but obviously it's annoying that it pollutes the template transclusion list. Theknightwho (talk) 01:19, 31 May 2024 (UTC)
 * @Theknightwho Sorry, by "expand templates" I meant "check for redirects". But even if we make it smarter about which section to check, it will still cause transclusions of all templates in that section to be listed. What about a flag telling it not to check for redirects? Benwing2 (talk) 01:35, 31 May 2024 (UTC)
 * @Benwing2 We could, but any "Descendants" section will be >90% desc templates and the rest will probably be q, so it seems unnecessary. All we'd be doing is pushing work back into Module:descendants tree anyway, since it'd still need to check for redirects, which presents a maintenance issue. Theknightwho (talk) 01:40, 31 May 2024 (UTC)
 * @Benwing2 We could, but any "Descendants" section will be >90% desc templates and the rest will probably be q, so it seems unnecessary. All we'd be doing is pushing work back into Module:descendants tree anyway, since it'd still need to check for redirects, which presents a maintenance issue. Theknightwho (talk) 01:40, 31 May 2024 (UTC)

Unable to add 2 more synonyms for the word endonym
I was going to change from to but I got this message: ''This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: -vija''

What is -vija and can I add 2 more synonyms for that word? (・∀・)? 2402:800:63A8:A143:F015:F0F7:E1E7:4522 04:40, 31 May 2024 (UTC)

 * I changed my mind, I would add autoglossonym to "Related terms" section instead. 2402:800:63A8:A143:F015:F0F7:E1E7:4522 05:01, 31 May 2024 (UTC)
 * looking through the list of recent hits, I'm not sure this abuse filter is serving its purpose any longer. It does trap a bunch of idle vandalism but it doesn't look any different from what we'd get from any other IP range. Thoughts? This, that and the other (talk) 05:31, 31 May 2024 (UTC)
 * Procedural question: given that we're using an abuse filter to (try to) stop edits by this user, are we also blocking IPs which are known to be this user? If so, since the user is abusing multiple accounts/IPs, shouldn't the main account also be blocked? - -sche (discuss) 03:10, 3 June 2024 (UTC)
 * : They stated they were quitting and never edited from their account again, so the focus was on dealing with the IP edits that came later. The list of IP ranges in the filter are all from unmistakably characteristic bad edits being done in those ranges. They switched ranges often enough that blocking them in the usual way would have shut down edits from pretty much all of Vietnam, so the filter was created in order to limit the collateral damage. I never was that great with regexes, so it can probably be improved. Besides which, it's always possible that they've moved to another range not covered by the filter. Chuck Entz (talk) 03:37, 3 June 2024 (UTC)
 * @Chuck Entz thanks for that. However, I'm still unclear on whether, in your view, the filter is still actually catching and deflecting vandalism from the user who it was originally intended to catch. As I observed above, I wasn't able to spot any patterns emerging from the edits being disallowed. I think we should be proactive in disabling filters like this if the person they are targeting has given up and moved on. This, that and the other (talk) 06:04, 4 June 2024 (UTC)
 * But I see you significantly narrowed the filter, which would have allowed the OP's intended edit to . So perhaps no further action is needed? This, that and the other (talk) 06:05, 4 June 2024 (UTC)
 * I still can't make that edit now. It wouldn't happen if I create an account, right? 2402:800:62A7:CDA3:159F:C64E:7A78:C09A 03:49, 7 June 2024 (UTC)
 * It worked after I created an account. 2402:800:62A7:CDA3:159F:C64E:7A78:C09A 04:07, 7 June 2024 (UTC)

How do you propose users navigate large categories?
Starting on Category:Sino-Vietnamese_words how do you propose users get to the e.g., K's? Fiddling with the URL of course ("Go to the next 200, whereupon a pagefrom= URL parameter appears which the user can tinker with.") That isn't how a major website should treat users. Jidanni (talk) 14:59, 31 May 2024 (UTC)

 * Our categories are inconsistent in whether they have what I will for lack of a better word call 'navigation TOCs', and what level of detail the TOCs have. You are right that this is an issue. The category you link has no TOC; Category:Vietnamese nouns has 15,000 entries and the TOC is just "A Ă Â B C D Đ E Ê G H I K L M N O Ô Ơ P Q R S T U Ư V X Y", whereas Category:Latin nouns, also with 15,000 entries, has a whole "aa	ab	ac	ad	ae	af	ag	ah	ai	aj	ak	al	am..." thing going. - -sche (discuss) 17:29, 31 May 2024 (UTC)
 * @Jidanni @-sche All categories that are handled by the poscatboiler system have TOCs added automatically. Generally, if there are >= 200 and < 2500 entries, a single-level TOC is added if available (i.e. if one has been created for the language in question), and if there are >= 2500 entries, a two-level TOC is added if one has been created for the language in question. Latin has such a two-level TOC but Vietnamese doesn't. Generally, most languages have one-level TOCs but only some have two-level TOCs. Maybe we can/should fall back to a generic TOC based on the script of the language, so we get default two-level TOCs (or maybe in such a case we should display both a language-specific one-level TOC and a generic two-level TOC?). This particular category Category:Sino-Vietnamese words has no TOC because it doesn't go through the poscatboiler system (you can see that by the fact that it doesn't use auto cat). Let me see about adding it. Benwing2 (talk) 19:00, 31 May 2024 (UTC)
 * The Sino-Vietnamese and Sino-Korean categories are now in the poscatboiler system, and there is a TOC visible for them. Benwing2 (talk) 04:25, 1 June 2024 (UTC)

Japanese headword issues
For some reason, kana entries for Japanese na forms are displaying duplicate rōmaji in the headword template, resulting in broken links. Examples: ,,.

Similarly, verbs and adjectives now display single rōmaji links for multiword conjugations (such as suru and na forms), even though such entries would inherently be SOP. Examples:, ,. Binarystep (talk) 19:55, 31 May 2024 (UTC)

 * @Binarystep I'm working on this at the moment. Theknightwho (talk) 20:07, 31 May 2024 (UTC)

title: Wiktionary:Grease pit/2024/May