text:
Wiktionary:Grease pit/2021/June

Brahmi Transliteration

 * What was the rationale for forking Module:Brah-translit to yield Module:sa-Brah-translit rather than adding a few lines at the end to convert the transliteration to IAST for the languages that use it? I thought the rationale for having Module:translit-redirect was that a page would only need to load one Brahmi transliteration module.  As an example of a less elegant mechanism, Module:pi-translit (as of this morning not yet hooked into the transliteration system) invokes Module:Brah-translit and Module:si-translit and then converts their outputs to IAST.  I was planning, once Module:pi-translit is hooked in, to incorporate conversion code in the Brahmi and Sinhalese modules to convert transliteration of Pali and Sanskrit to IAST. --RichardW57m (talk) 12:21, 2 June 2021 (UTC)

 * The rationale for forking Module:Brah-translit to yield Module:sa-Brah-translit was that Module:Brah-translit wasn't working for Sanskrit as is, and I'm not proficient enough at coding to wiki of Module:Brah-translit. If you know how to modify Module:Brah-translit so that it can replace Module:sa-Brah-translit at Module:translit-redirect/data without changing the current arrangement for Sanskrit (or causing errors with the languages that currently use Module:Brah-translit), then please go ahead with your planning (notifying ). Kutchkutch (talk) 09:54, 3 June 2021 (UTC)
 * I know nothing/very little about module coding to be able to do this. 🔥 ಶಬ್ದಶೋಧಕ 🔥 10:50, 3 June 2021 (UTC)
 * I can make the changes. The hard bit will be extending the test cases, but I think I've worked out the key undocumented bit of the testcase utility Module:transliteration module testcases, namely that it will accept multiple languages as well as multiple scripts in a single call.  Did you,, have any Sanskrit test cases  in mind?  I'm planning to use my Brahmi testcases from Module:pi-translit/testcases.
 * : I've now made the changes, and while I was at it, added 6 more scripts to the list of those transliterated for Sanskrit: Burmese, Khmer, Lao, Sinhalese, Tai Tham and Thai. --RichardW57 (talk) 22:02, 5 June 2021 (UTC)
 * I made heavy weather of extending Module:Brah-translit/testcases, which uses Module:transliteration module testcases. I ended up extending it to Module:per lang transliteration module testcases by allowing a different language in each test case and adding an option func_with_link to allow the user to provide a function that does all the formatting of the 'example' column in the outputs.  That seems a lot of heavy work compared to the seemingly light coding in Module:si-translit/testcases, which also handles two different transliteration standards for one script.  My question now is whether I should integrate the enhancements back into Module:transliteration module testcases, or just convert the testcase module to work like the Sinhalese one.  I don't want the new support module to hang around for long.  --RichardW57 (talk) 22:02, 5 June 2021 (UTC)
 * If the enhancements don't necessitate any changes in the testcase modules that currently use Module:transliteration module testcases, I'd say go ahead. — Eru·tuon 22:35, 5 June 2021 (UTC)
 * Incorporated, tested and documented. --RichardW57 (talk) 12:23, 6 June 2021 (UTC)

Suffix Index
https://dixtosa.toolforge.org has stopped working with the error wiki. Is there a way to fix this or a workaround? Kutchkutch (talk) 10:02, 3 June 2021 (UTC)
 * I looked at the code for dixtosa through my Toolforge account. Yeah, it looks like it can be fixed. The tool uses a Toolforge database and the database setup has changed as described here, breaking the old code. The new directions are at wikitech:Help:Toolforge/Database. There is another change that I would make to the code, but User:Dixtosa would have to give me access. — Eru·tuon 18:18, 3 June 2021 (UTC)
 * Added you as a maintainer. Dixtosa (talk) 21:39, 4 June 2021 (UTC)
 * Thanks! After a bit of wrestling with PHP, I've gotten it working. Now it's also less vulnerable to SQL injection and you can search for words ending in if you want. — Eru·tuon 01:24, 5 June 2021 (UTC)
 * Thanks for fixing and improving the tool! Kutchkutch (talk) 09:09, 5 June 2021 (UTC)

Looking up templates and their attributes
I see a template use that has an attribute who's meaning is not obvious to me from the name. How do I lookup the attributes that a particular template supports and what they mean? - Dough34 (talk) 14:21, 3 June 2021 (UTC)
 * We call them parameters. The template ought to have documentation explaining what each of its parameters does, but alas very many templates here are lacking such documentation. Sometimes if you click "Edit" and view the source code you can figure it out: parameters are always enclosed in triple brackets. However, sometimes it still isn't clear, and of course a whole lot of our templates are dependent upon Modules, so viewing the template's source code is unhelpful. In that case, there's often nothing for it but either (1) to see what entries use the template (using Special:WhatLinksHere and see what that parameter does in the entries where it's used, or (2) ask the author of the template (if they're still around) or someone else. Which template and which parameter are you wondering about? —Mahāgaja · talk 19:11, 3 June 2021 (UTC)
 * The template plural of has a parameter nocat. How do I find the source code for plural of, or any other template? I'm looking at the page dead woman walking and clicked on the green undefined plural link. - Dough34 (talk) 19:34, 3 June 2021 (UTC)
 * nocat is a very common parameter used in a large number of templates. Setting 1 prevents the template from adding the term to the category that it otherwise would add the entry to. However, plural of doesn't actually categorize entries it's added to, so in that case, nocat isn't doing anything at all, which is presumably why the documentation for plural of doesn't mention it. The way to find the source code for a template is to click the Edit button. —Mahāgaja · talk 19:51, 3 June 2021 (UTC)
 * As the nocat parameter does not do anything, I requested it to not be added to plural forms automatically any more, which is yet to be done. J3133 (talk) 21:45, 4 June 2021 (UTC)
 * I will ping, who has edited the module. J3133 (talk) 21:56, 4 June 2021 (UTC)
 * I removed it myself (Special:Diff/62693241). J3133 (talk) 21:47, 7 June 2021 (UTC)

Edit request at MediaWiki:Newarticletext
Kindly change  to   and   to   to fix the obsolete tag --Minorax (talk) 10:31, 5 June 2021 (UTC)
 * Done! — Eru·tuon 20:39, 5 June 2021 (UTC)
 * Can you do the same for MediaWiki:Noarticletext? Thanks in advance. --Minorax (talk) 11:11, 6 June 2021 (UTC)
 * Yep, also done. And I think that's all the center tags in the MediaWiki namespace. — Eru·tuon 21:24, 6 June 2021 (UTC)

Links from categories
Hello, happy Sunday from el.wikt. I see that words in your Cateogires link precisely to their language section. Is this done with a module, or some other trick? Thank you ‑‑Sarri.greek ♫ | 05:26, 6 June 2021 (UTC)
 * Hello! What we do is insert the HTML code created by  into category pages, and then run MediaWiki:Gadget-catfix.js to transform the category links. The gadget is installed here so that it is loaded efficiently by the server. The catfix HTML is inserted either by calling the module function in the module functions that generate category descriptions (for instance in many categories that are added by ) or by using  in a page. So it's a combination of a module and a JavaScript gadget. — Eru·tuon 06:16, 6 June 2021 (UTC)
 * O!, thank you. You make it sound sooo easy :) I'll study it. ‑‑Sarri.greek ♫ | 06:18, 6 June 2021 (UTC)
 * Ο :( ‑‑Sarri.greek ♫ | 06:29, 6 June 2021 (UTC)

Automatic categorization of irregular plurals
Category:English irregular plurals is small considering Category:English nouns with irregular plurals has more than 14000 entries: it is not feasible for someone to categorize these manually. J3133 (talk) 19:43, 6 June 2021 (UTC)

Edit request: Module:bo-pron
Could if args["zeku"] or args["labrang"] then textHide = textHide .. "\n* Amdo" if args["zeku"] then textShow = textShow .. "\n* Zêkog: " .. ipaFormat(args["zeku"], true) textHide = textHide .. "\n** (Zêkog) " .. ipaFormat(args["zeku"]) end if args["labrang"] then textShow = textShow .. "\n* Bla-Brang: " .. ipaFormat(args["labrang"], true) textHide = textHide .. "\n** (Bla-Brang) " .. ipaFormat(args["labrang"]) end end be changed to	if args["zeku"] or args["labrang"] or args["arik"] then textHide = textHide .. "\n* Amdo" if args["zeku"] then textShow = textShow .. "\n* Zêkog: " .. ipaFormat(args["zeku"], true) textHide = textHide .. "\n** (Zêkog) " .. ipaFormat(args["zeku"]) end if args["labrang"] then textShow = textShow .. "\n* Bla-Brang: " .. ipaFormat(args["labrang"], true) textHide = textHide .. "\n** (Bla-Brang) " .. ipaFormat(args["labrang"]) end if args["arik"] then textShow = textShow .. "\n* Arik: " .. ipaFormat(args["arik"], true) textHide = textHide .. "\n** (Arik) " .. ipaFormat(args["arik"]) end end to add the Arik dialect of Amdo Tibetan? --沈澄心✉ 12:53, 9 June 2021 (UTC)
 * Done. — Fenakhay ( تكلم معاي · ما ساهمت ) 00:05, 10 June 2021 (UTC)

Do citations indicating the existence of a term or phrase that are for an inflected form go under the inflected form, or the base form?
(Sorry if this isn't the right area to bring this up in. I don't really bring this kind of matter up often, so I am not quite certain where it best belongs.)

I recently created entries for all bedlam breaks loose and all bedlam broke loose. Since all bedlam breaks loose is the base form, I put the citations under that form. However, the citations themselves are actually for all bedlam broke loose, not the base form.

Is it proper to put them under the base form, or is it preferred for them to be put under the inflected form? Tharthan (talk) 22:16, 9 June 2021 (UTC)
 * It's my understanding that you put them under the base form unless there's a reason to put them elsewhere. (I believe the correct place to go for this answer is Information_desk.) --Geographyinitiative (talk) 22:40, 9 June 2021 (UTC)
 * I agree. If there's nothing unusual or unexpected about the inflected form, put the cite at the lemma form. But if it's a rare/dialectal/nonstandard inflected form whose very existence some people might doubt, put the cite at the inflected form. See for an example. —Mahāgaja · talk 23:16, 9 June 2021 (UTC)

Why do I view modules like wikitext
Have i clicked something wrong? At the moment I view module sources as wikitext. Does it happen to anybody else? ‑‑Sarri.greek ♫ | 08:01, 10 June 2021 (UTC)
 * It's happening for everyone I think. User:Justinrleung pointed it out to me in Discord. It's a JavaScript bug. I posted about it in T284716. It looks really easy to fix (just change a variable name), so hopefully they'll fix it soon. — Eru·tuon 08:18, 10 June 2021 (UTC)
 * Fixed! Thank you for taking care of this! ‑‑Sarri.greek ♫ | 10:49, 10 June 2021 (UTC)

Kharosthi font support
Is there a font for the Kharosthi script that at least renders the text in a sensible way? According to the Wikipedia support page, the recommended font is Segoe UI Historic, but that seems to be specific to Windows 10.

On my system the word (wiki template for the text: ) displays as if it were "thavu" in the page (the vowel "u" as a little circle thingy on the bottom attaches to the hook-shaped letter for "V", rather than to the cross-shaped letter for "Th"), but it shows up fine in the editing area.

Is there a recommend font/setting/combo solution, preferably without switching to Windows 10? --Frigoris (talk) 17:16, 11 June 2021 (UTC)
 * There is a Noto font for it that you could install; search "Kharoshthi" in the Noto fonts page. (There might also be a full Noto fonts package for your operating system if you want to wipe out many non-displaying characters at once; Ubuntu has one for instance.) Then you might have to add some CSS to your common.css page to force this site to use the font: . — Eru·tuon 18:24, 11 June 2021 (UTC)
 * thank you! I think I have the Noto font installed, but I never knew you can do these CSS wizardry to apply the font everywhere. According to the Wikipedia page, it's not as good as Segoe, but let me see if it's better than the mojibake soup I'm seeing now... --Frigoris (talk) 09:57, 12 June 2021 (UTC)

Kharosthi transliteration with certain combining modifiers
Currently the transliteration module seems unable to deal with Kharosthi modifiers such as "bar above" (U+10A38) or "cauda" (U+10A39). The following texts generate zalgo text in transliteration:

 * - "bar above" attached to "ja"
 * - "cauda" attached to "ga"

It seems the Kharosthi combining modifiers are not transcribed and are just copied as-is into the Roman-alphabet transliteration, and gets combined to the text somehow. In the second case the "cauda" even combines to the closing parenthesis.

Unfortunately I don't know any Lua to improve the module. Could help? Thanks! --Frigoris (talk) 11:22, 14 June 2021 (UTC)
 * Do you have a reference for how these words should be transliterated? Is working out what should be done, as opposed to how to do it, part of the problem? --RichardW57m (talk) 12:02, 14 June 2021 (UTC)
 * The cauda mark added to a character is transliterated with an acute accent. I have created entries with cauda in the spelling (e.g.: 🇨🇬) which currently use manual translit.

 * If you review my antics at Module:Khar-translit, you'll find that I did try to address this issue a week ago. I added the combining cauda and added a combining acute accent for its transliterated countpart - I did manage to get it to work, but soon I realized that the functionality of the virama started getting affected. It would no longer transliterate the virama and I found that there were translit errors in Niya and Gandhari entries plus possible module errors in pages that used Module:inc-ash/dial (because   also uses Kharoshti). I had to rollback my own edits and reinstate a previous version of the page. I probably should have asked someone for help (e.g. ) but it didn't cross my mind then. -- 𝓑𝓱𝓪𝓰𝓪𝓭𝓪𝓽𝓽𝓪(𝓽𝓪𝓵𝓴)  13:26, 14 June 2021 (UTC)

 * Does this Unicode document help? Proposal for Kharoṣṭhī script. The "bar above" transliterates as a macron above the corresponding consonant letter in the Roman alphabet, and the "cauda" transliterates as an acute accent for any consonant that is not s or ś; for these latter two it is transliterated as s̱ and ś̱, with macron below the letter. However there are complications:
 * The conjunct consonant in 𐨐𐨿𐨮 = (in the sequence of bytes rather than display sequence) Khar. letter KA (U+10A10) + Kharosthi Virama (U+10A3F) + Khar. letter SSA (U+10A2E) -> transliteration kṣa. According to the doc, the Kharosthi "bar above" can modify this consonantal conjunct as a whole. So in that case, the transliteration should probably look like k͞ṣ = k + Unicode Combining Double Macron (U+035F) + ṣ. For the transliteration, at least this "letter + combining double macron + letter" sequence is what renders correctly on my system. Well, in summary, the sequence of Unicode characters
 * Khar. letter KA (U+10A10) + Kharosthi Virama (U+10A3F) + Khar. letter SSA (U+10A2E) + Khar. sign BAR ABOVE (U+10A38)
 * should transliterate to k͞ṣ followed by the correct vowel. This appears to be the only exceptional case with "bar above" based on my reading. A very complicated example is given on Page 4 of the Unicode document: there's a conjunct rj with "bar above", but since the "bar above" conceptionally modifies the Khar. letter JA instead of the whole conjunct, in the translit the macron is only placed above j.
 * Macron above ś or other letters with the acute accent (possibly caused by rendering a "cauda") - should it be like ś̄ or s̄́?
 * On typographical grounds, I'd go for the latter, which is common enough to often render well. For ś with cauda. I'd be tempted to use ḉ or go Hungarian with a double acute. Test cases?  What's current practice? --RichardW57m (talk) 12:47, 16 June 2021 (UTC)
 * The problem is that ḉ suggests something to do with c, which is not the case. Presumably the transliteration should convey the sense "this is based on ś, with modification", I think. --Frigoris (talk) 14:04, 18 June 2021 (UTC)
 * The writing ç is good old pre-IAST for ś. I haven't tracked down what ḉ is used for (and don't say a high-pitched syllabic sibilant).--RichardW57m (talk) 15:19, 18 June 2021 (UTC)
 * The Khar. "double ring below" -- this seems to be transliterated just as "double ring below", always combined to the vowel letter in the translit. I truly don't know how they mean it when it lists its transcription just as double ring below...
 * I don't see a problem. It just transliterates as U+035A COMBINING DOUBLE RING BELOW.  In the example, it applies to an implict vowel, which is par for the course.  (One gets some rich combinations of marks in the eastern foothills of the Himalayas.)--RichardW57m (talk) 12:47, 16 June 2021 (UTC)
 * Thanks, I never knew that one existed. --Frigoris (talk) 14:04, 18 June 2021 (UTC)
 * Borrowed from Kharoshthi in the 1920's. Only added to Unicode at the same time (or thereabouts) as Kharoshthi. --RichardW57m (talk) 15:19, 18 June 2021 (UTC)
 * The Khar. anusvara: In the doc it follows the IAST style and transliterates it as ṃ. Then it says the Khar. "dot below" combines to the Khar. character MA. This is obviously a conflict, which can be solved by using the ISO-style ṁ for the transliteration of the anusvara.
 * There may not be a conflict. They may occur in different contexts. --RichardW57m (talk) 11:39, 15 June 2021 (UTC)
 * Anyway, big thank you to all involved. Kharosthi seems the closest to an actual zalgo script among real-world scripts.. --Frigoris (talk) 15:28, 14 June 2021 (UTC)
 * The document, combined with the Unicode Character Database, certainly looks as though it should be enough. However, it would be good to have far more testcases - adding them to Module:Khar-translit/testcases should just be a case of monkey see, monkey do.  There are a lot more cases for Module:Brah-translit/testcases, and no serious complications were expected there. --RichardW57 (talk) 19:52, 14 June 2021 (UTC)
 * After studying the USE overrides for the script, I now know how to code the transliteration of renderable words, using the elements consonant+nukta+vowels, and intend to do so tonight. (I include virama as a vowel.)  As usual, visarga and anusvara can be dealt with afterwards.  As Wiktionary pages are stored in form NFC, that simple element expands to consonant+cauda?+(ZWJ?+virama)?+dot_below?+double_ring_below?+bar_above?+vowel_complex?.  Only one of 'ZWJ?+virama', 'dot_below' and 'vowel_complex' will be non-empty.  This may be overkill - do we get nukta + virama?  Have I spotted an earlier virama-related foul-up by Mark Davis?  We need the ZWJ for the sequence 𐨫‍𐨿𐨩 transliterated as 'lý'.  I've noticed Allon being published with kṣ̄ rather than k͞ṣ - have you actually seen the latter? --RichardW57m (talk) 15:19, 18 June 2021 (UTC)
 * The Kharoshthi side of transliteration now appears to be working. (In particular, the opening paragraph here has been dezalgoed.) We haven't any torture tests for the typographic niceties.  It can fail on a legitimate vowel sequence - up to two short vowels, a length mark and a double ring below.  It will paste up a visual warning for an unsupported legitimate vowel sequence when one previews the affected page.  The transliterations will need to be added if they're not already there.  (It currently supports a, e, i, o, u, ā, ai, ī, au, ū, a͚ and u͚.)  I haven't investigated the USE constraints on the combinations of short vowels, and I don't know what combinations occur. --RichardW57 (talk) 22:34, 18 June 2021 (UTC)
 * hey, that was amazing!
 * As for anusvara vs "M with dot-below", are we sure it's not a conflict? I can imagine it being problematic for reverse transliteration at least, if that's going to get implemented. For ś with bar-above (macron), it seems the Gandhari.org transcription scheme simply tacks a combining macron upon ś. OTOH their transcription is different from the Unicode doc's in other ways, e.g. they use "d with combining-macron-below" for Khar. "D with cauda", while the doc suggests d with acute accent. --Frigoris (talk) 07:59, 19 June 2021 (UTC)
 * , also, I haven't seen the "double macron" over kṣ, but that was how I read the Unicode doc. My interpretation could be inaccurate. --Frigoris (talk) 08:08, 19 June 2021 (UTC)
 * : It seems that it is time to start populating Appendix:Kharoshthi_script, which is currently a red link from Category:Kharoshthi script. I'm currently looking at the transliteration in Andrew Glass's 2000 MA thesis.  I think we may also have some encoding issues.  Is the conjunct V.HA distinct from the consonant VHA (new at Unicode 11.0)?  They're not canonically equivalent.  We have the conjunct at .  I think it's time to start cataloguing the consonant-nukta combinations and their transliterations.  I've a feeling the 'h' of aspirates shouldn't take the accents marking the nuktas, but that issue may not arise in practice. --RichardW57 (talk) 10:06, 19 June 2021 (UTC)
 * I read the proposal's remark about nuktas applying to a whole conjunct as referring to the Kharoshthi script, rather than the transliteration. It read to me as primarily rendering advice.  Additionally:
 * It may not be easy to apply a nukta to part of a conjunct rather than a whole conjunct.
 * Some conjuncts were probably perceived as unitary characters.
 * So far, in transliteration, I've only seen the diacritics on the final element of conjuncts. I'm still reading the MA thesis. --RichardW57 (talk) 10:06, 19 June 2021 (UTC)
 * I think I may have to strip out my cunning conversion of  to . The thesis seems to consistently write ɡ́̄ rather than ɡ̄́. --RichardW57 (talk) 10:06, 19 June 2021 (UTC).
 * As precedent, note that IAST dropped the distinction between the syllabic consonant and the retroflex lateral. --RichardW57 (talk) 10:06, 19 June 2021 (UTC)

Pali Transliteration Issues
Now that we finally have automatic Pali transliteration available, I am now hitting problems because of the range of writing systems seen in the wild. Specifically, issues are arising because of the following features: Consequently, the automatic transliteration (which would be correct for another writing system), correct transliteration (dependent on knowing the writing system) and Roman script equivalent may all be different. This is rare, but happens. --RichardW57m (talk) 13:02, 14 June 2021 (UTC)
 * There are two basic writing systems in the Thai and Lao scripts, one of which uses implicit vowels and the other which writes vowels explicitly. Occasionally a valid sequence of characters could be in either system, and the reading of the word depends upon which one it is.
 * The Roman script is one of the scripts used for Pali, and it has spelling rules. For example, one cannot use niggahita (=anusvara) for a homorganic nasal, so if the non-Roman script does, the transliterated form is not a correct Roman script spelling.
 * Not all the writing systems can make the distinctions normally made in the writing of Pali. This is most significantly true of most Lao script writing, but I strongly suspect it may also be true of some Tai Tham script writing systems.  Consequently, in some regions, two words may be written and pronounced the same, even though the correctly spelt Roman script spellings of the two wrods are distinct.  I presume that words that are written the same and pronounced the same should be transliterated the same.

I have been in the habit of using and  to simultaneously link to the word or stem both in the relevant non-Roman writing system and its equivalent in the IAST-based Roman script origin system. I have been using the transliteration output as the link. Now, if it were not for the issues above, setting the 'link_tr' property for Pali would give me exactly what I want. However, this would work incorrigibly badly when the correct transliteration and Roman script equivalent were different. Am I missing a bettwer way of simultaneously linking to non-Roman and Roman script forms of a word or stem? Would someone (e.g. ) be open to providing manual control of the link_tr behaviour? --RichardW57m (talk) 13:02, 14 June 2021 (UTC)

Now, I can, and before transliteration, had been, getting the equivalent of manual control by passing the manual transliteration in as the result of. However, this never matches the automatic transliteration, and, before I started implementing a work around, the category of pages with mismatching manual and automatic transliterations had reached the size of 360. I have been experimentally reducing these reports by using the as-yet undocumented template, which has some fairly dirty behaviour so that it can invoke. (Essentially, it has parameters tr to override transliteration and eqv to override the equivalent form in Roman script.) If I follow this approach, I will need a clutch of susbstitutes for other members of cat:Form-of templates and even. --RichardW57m (talk) 13:02, 14 June 2021 (UTC)

I have now created that clutch of replacements:

 * for
 * for
 * for
 * for
 * for
 * for
 * for
 * for

So far, I have documented the first four, except for the internal support template. --RichardW57 (talk) 01:26, 11 July 2021 (UTC)

Merriam-Webster Online template needs documentation, dating
Template:R:Merriam-Webster Online produces the text "(Please provide a date or year)". I cannot see, though, any way to add the date or year to uses of the template. The documentation only mentions,  , and. There also appears to be a, which I guess is for including quotations from the MWO entry. The documentation needs to be updated to describe how this template actually works currently. Perhaps someone wiser than me could also figure out what is causing that "Please provide date" warning. Cnilep (talk) 01:04, 15 June 2021 (UTC)
 * See . J3133 (talk) 01:16, 15 June 2021 (UTC)

Adding new pronunciation variants to Module:la-pronunc
Hi, I've been wanting to add some new traditional pronunciations to this module as well as make (see here) what's currently nebulously called "Vulgar" into a default concrete alternative pronunciation called "2nd CE Campanian" while also possibly having a specialized reconstructed proto-Romance (ideally just phonemic), but I'm coding-disabled. I know how to make the current Vulgar be displayed by default, but I'm not sure how to split an existing pronunciation into two, one of which would have to be enabled with the option  and automatically in the Reconstructed namespace, and the other would be default like current Classical. With Ecclesiastical, I just want to double, triple etc. the current automatic Ecclestiastical output - ideally under a drop-down menu like Ancient Greek (λόγος) and with the general title "Traditional". Starting at line 963 the module generates phonemic and phonetic transcriptions, and the Traditional ones need to output both in a new line, just like all three currently existing ones do.

Additionally, I'd like to be able to add automatic variant outputs to one variety, as with the different syllabification at or different pronunciations of  at  without having to manually specify it (alternative syllabification currently requires manual specification as  ). The second case does probably need qualifiers such as "older, hellenizing" instead of just being given inside the same line, but I'm not sure how to implement this either way. Since I'm not likely to suddenly evolve an understanding of Lua, I have to ask for some pointers if not outright for someone to implement it for me. Can I steal the code from somewhere? Which parts of the module do I need to copy-paste and what do I want to keep track of? Mentioning as having edited the module recently. I figured here is more visible than at the module's discussion page. Brutal Russian (talk) 15:03, 18 June 2021 (UTC)

Request for reference template: Franklin Edgerton's Buddhist Hybrid Sanskrit Dictionary
I feel that a reference template to Franklin Edgerton's Buddhist Hybrid Sanskrit Dictionary would be valuable for Sanskrit entries and perhaps also for languages that borrows heavily from BHS, such as Chinese. The dictionary is available from U. Köln's Sanskrit Lexicon website, which also hosts the dictionary, among others. Example PDF page output.

The BHS dictionary template would serve a purpose similar to that of the, by showing the headword and linking to the PDF server by page number. I can see several parameters in the MW template useful for this, too, such as the ones for resolving page/column.

The problem is that I don't have the skills with wiki templates and their testing & maintenance, even if I presume there's a lot to re-use from the MW template. I appreciate your help! Thank you! --Frigoris (talk) 15:35, 19 June 2021 (UTC)

 * Also, if I understand it correctly, the digital edition hosted by UKöln is licensed under Creative Commons by-nc-sa 3.0, according to this XML document.

Experience on mobile
Carried over from [[Wiktionary:Grease_pit/2021/March]]:

 We have reader complains that mobile pages are always expanded which make the pages hard to see. This becomes a serious problem on LongPages with a hundred entries. Especially that TOC does not appear in mobile view.

I have verified with mobile view that this is the case on WT. Section headings always appear expanded.

I also went to the other WikiMedia projects and their section headers are minimized (collapsed).

Anyone knows why the difference in behavior and how to fix it? Need to call in help from ?119.56.97.84 05:55, 30 March 2021 (UTC)
 * I will go look for a meta developer to see if I can get some opinions. 119.56.103.124 16:58, 31 March 2021 (UTC)
 * This is a global setting active on all Wiktionaries (but not on other Wikimedia projects). It was discussed in T63447, and while I’m also embarrassed by this setting when I read Wiktionary on mobile (as I do a lot), I also understand the reasoning there. —Tacsipacsi (talk) 19:46, 1 April 2021 (UTC)

From [[Wiktionary:Beer_parlour/2021/April]]:  I am bringing this up again for our attention. On mobile pages, language headers are overtly expanded which makes the pages very long to scroll through.

A 2014 change in phabricator was the cause of Wiktionary headers always being expanded. This is different from other Wikimedias which have collapsed headers, which makes it easy to go to header you want to. (shared by someone from the tech community).

I was not sure how much community agreement the change has.

One suggested solution is to set the headers to collapsed again.

A second proposal is to only collapse entries with more than, say, 5 language headers. Then, shorter pages with less than 5 headers will not be collapsed. This behavior is like the _TOC_ box which only appears when there are about 5 or more language headers in desktop view.

I wonder how many of us write on mobile, but increasing number of people use mobile view to visit Wiktionary. This means overly long pages which are difficult to read are driving away readers and potential contributors. So it is quite an important issue. 119.56.98.229 04:54, 4 April 2021 (UTC)

 * I was thinking how many pages and how many visitors are affected by this issue. We can have a look at the most visited pages, have a look using mobile view and imagine how it will look like on a phone/tablet. There should be a link to most visited at Special:Statistics119.56.96.203 06:41, 8 April 2021 (UTC)
 * Mobile page has been bad on WMF for a long time. Many current readers and editors still use desktop for full functionality, but it is a reality that more people are accessing the web through mobile. The subpar mobile experience has become such an impediment to wikiwork that complaints are filed with User_talk:Jimbo Wales.

119.56.97.153 19:00, 19 April 2021 (UTC)

 * Agreed that the mobile user experience is pretty awful. Sometimes pages load on mobile with all the L2 headers collapsed (user talk pages), which is preferable; sometimes they don't (our forum pages, like WT:TEA), and the page can quickly become unusably long.  I don't understand why the behavior is different; it comes across as shoddy programming.  ‑‑ Eiríkr Útlendi │Tala við mig 18:46, 20 April 2021 (UTC)
 * Someone from phabricator, which is WMF volunteer tech working group, complained that it is too much work on Wiktionary to open up the collasped headers when there are only a few headers on a non-talk page. So all the headers are now expanded by default to meet that guy's requirement.119.56.111.132 13:45, 20 June 2021 (UTC)
 * meta:Tech/Archives/2021See April.
 * Huh. So I was right -- it is shoddy programming.  What's worse, it's intentional.  :(
 * @Anon, thanks for the link. ‑‑ Eiríkr Útlendi │Tala við mig 19:08, 21 June 2021 (UTC)

From https://meta.wikimedia.org/wiki/Tech/Archives/2021#en.m.wiktionary_Header_sections_always_not_collapsed_and_always_expanded:  This is on one of the biggest and oldest projects on Wikimedia.

On mobile site, the header sections which are usually collapsed on other wikis, always appear expanded on this wiki.

Our readers are complaining about this issue. Sections can be very long and always-expanded sections are hard to read. Links to a section don't position correctly, because the link first goes to the section, then all sections expand after that which makes useless the positioning that happens just before.

Would like guidance on what is causing this, and what can be done to correct this behavior. 119.56.97.84 17:35, 31 March 2021 (UTC)

 * Answer at wikt:Wiktionary:Grease pit/2021/March (I’d appreciated if you’ve given the link, though). —Tacsipacsi (talk) 19:46, 1 April 2021 (UTC)

 * So it was a change on Phabricator. Thank you very much for getting the decision for us. And also for visiting our forum (sorry that I did not think to bring it back).

 * For us, would need a look on how many pages this seriously affects (as a percentage), to decide if something needs to be done. I do note that it affected your reading wikt.

 * Mobile view has been more neglected even though more people are reading on mobile. It is sad when many editors still stay with desktop view because mobile view is still difficult to use. 119.56.100.135 07:05, 2 April 2021 (UTC)
 * If there is community consensus to change an existing configuration setting for a Wikimedia website, then please see Requesting wiki configuration changes how to proceed (plus include a reference to T63447). Thanks! --AKlapper (WMF) (talk) 12:17, 2 April 2021 (UTC)

From MobileFrontend user experience on Wiktionary is rough, T63447 on Phabricator:  Authored By

MZMcBride Feb 16 2014, 9:25 PM

Screenshot of https://en.m.wiktionary.org/wiki/wildcard on an iPhone, 2014-02-16

The MobileFrontend + Wiktionary user experience is pretty rough. Screenshot of https://en.m.wiktionary.org/wiki/wildcard on an iPhone attached. The page almost looks broken. There's only a single language for this entry yet it's collapsed. Owww.

Given that MobileFrontend is the default for mobile devices, I think this is fairly high priority.

I get that it's inconvenient to have an entry with only one section, and that section is collapsed.

However, that is only an inconvenience -- a mild annoyance.

When browsing to a large page, and all the sections are expanded, the page can be unusable.

Trading a mild annoyance for page unusability is a bad trade.

I don't have time to dig, and all the related Phabricator issues I can find at the moment appear to be closed:

 * MobileFrontend user experience on Wiktionary is rough
 * [EPIC Improve Wiktionary experience on mobile (placeholder)]

Does anyone know where we could discuss this with the back-end maintainers? Or could we fix this somehow without them? ‑‑ Eiríkr Útlendi │Tala við mig 19:17, 21 June 2021 (UTC)

Modi Transliteration
Is there any reason to keep Module:sa-Modi-translit, for Sanskrit, and Module:Modi-translit, for Old Marathi, separate? There don't seem to be any conflicts yet, and if any arise they can probably be handled by a simple language-sensitive tweak as with Brahmi. Pinging recorded editors -. Silence is consent. --RichardW57m (talk) 12:35, 22 June 2021 (UTC)

 * The three languages that are currently defined as using the Modi script in Category:Modi script languages are Old Marathi, Sanskrit and (modern) Marathi. Since Old Marathi and Sanskrit are not modern languages, using the closest approximation to IAST using a single transliteration module is fine.

 * For some reason User:DerekWinters / User:Smettems preferred transliterating the anusvara as ṁ instead of ṃ. Tulpule's dictionary of Old Marathi has attempted to differentiate instances of the anusvara as either homorganic nasal consonants or nasalisation of the preceding vowel. Perhaps this attempt at making such a differentiation could be indicated with the ts parameter.

 * Although writing modern Marathi in the Modi script is rare and there is no coverage of it yet, the transliteration of modern Marathi in the Modi script may require a separate transliteration module to account for schwa-deletion and perhaps the phonological pronunciations of ज्ञ (dny) and ऋ (ru) depending on the outcomes of Wiktionary talk:About Hindi and Category talk:Konkani language.

 * Are you able to corroborate the claim that the Modi script is/was sometimes used for Konkani, Kannada, Telugu, etc. as it says on Wikipedia? Kutchkutch (talk) 12:19, 30 June 2021 (UTC)
 * This news article talks about how experts are trying to transliterate Kannada documents written in Modi. As for Konkani, it is likely that Konkani speakers in modern day Goa and Karnataka once used the Modi script. -- 𝓑𝓱𝓪𝓰𝓪𝓭𝓪𝓽𝓽𝓪(𝓽𝓪𝓵𝓴) 01:06, 4 July 2021 (UTC)

can't get to talk:; (semicolon)
the edit   history at    https://en.wiktionary.org/w/index.php?title=Talk:;&action=history   shows edits up to 2014, but the talk page is unviewable now. it just returns "Bad title" and behaves as if viewing the main page. Sure we can use talk:semicolon but i wonder if this is a bug that can be easily fixed. thanks, — Soap — 15:19, 27 June 2021 (UTC)

There are also seem to be problems with viewing the definition page ... I made an edit just now but can't get to it from my contribs page. — Soap — 15:23, 27 June 2021 (UTC)
 * See Phabricator (“Pages whose title ends with semicolon are intermittently inaccessible (likely due to ATS)”). Our temporary kludge is using redirects from “﹔” (e.g., in ). The other URL works (e.g., https://en.wiktionary.org/w/index.php?title=;). J3133 (talk) 15:44, 27 June 2021 (UTC)

Sorting in Pali Categories
Do we have control of the basic sorting rules in categories? Where do the basic sorting rules come from? They don't look like ICU/CLDR/DUCET to me.

If we have control, we need to sort out the sorting of: so that they sort near the corresponding 'Burmese' Burmese script characters. MON NGA does occur in Pali, even if it shouldn't. I think we should also accommodate just in case. I've seen MEDIAL MA in a Sanskritic spelling; I don't know which the language was. I don't have the privilege to edit the definition of the sort keys. --RichardW57 (talk) 04:14, 2 July 2021 (UTC)
 * U+1033 MYANMAR VOWEL SIGN MON II
 * 105A;MYANMAR LETTER MON NGA
 * 105B;MYANMAR LETTER MON JHA
 * 105E;MYANMAR CONSONANT SIGN MON MEDIAL NA
 * 105F;MYANMAR CONSONANT SIGN MON MEDIAL MA
 * 1060;MYANMAR CONSONANT SIGN MON MEDIAL LA

U+1028 MYANMAR LETTER MON E already sorts next to U+1027 MYANMAR LETTER E.

 * English Wiktionary is simply sorted by codepoint (character's binary value), because the community wants to be like that. So they have to override sorting algorithm on their own. On Thai Wiktionary, we use the defined Unicode collation so less problems occur. However, both methods are not the best for some individual languages that they do in real dictionaries. You can present new sort keys here to be reviewed and I hope it works when it is replaced. --Octahedron80 (talk) 06:02, 2 July 2021 (UTC)

title: Wiktionary:Grease pit/2021/June


text:
Wiktionary:Grease pit/2021/July

String alternatives in templates
I've just found myself writing the following, and I'm wondering if there's a better syntax:

It's simple meaning is the first non-empty (or non-blank - I don't care about the difference) value from:
 * Parameter 2
 * The result of a template call that depends on Lua
 * literal "unknown"

It bothers me because the template is called twice if Parameter 2 is empty, and I worry that so doing may increase the memory consumption. It's not impossible that there might be issues with execution time, though that looks unlikely. Fortunately, supplying Parameter 2 is not very tedious, and seems to be fairly resistant to typos, and the code above should not be invoked for a Roman script page. --RichardW57 (talk) 11:45, 3 July 2021 (UTC)
 * In this case I think using another template is appropriate. w:Template:If empty looks like it does what you want. (The module w:Module:If empty would need the weird backwards-compatibility stuff removed.) — Eru·tuon 00:22, 4 July 2021 (UTC)
 * That does the trick for readability. Unfortunately, it requires yet another module, so may use up even more memory from the Lua limit.  At present, parameter 2 is normally provided, so with any luck xlit is not invoked at all. --RichardW57 (talk) 02:19, 4 July 2021 (UTC)
 * Actually, now that I think of it, the that you need (with only one parameter) could just be implemented as  . The module is only needed to handle an unlimited number of parameters. (If parameter n is empty, show parameter n + 1, starting at n = 1, recursively.) — Eru·tuon 19:33, 26 July 2021 (UTC)

Further forms in default head template lack auto-translit
How come the forms given in 4, 6 and so on of  are not auto-transliterated when everything else is auto-transliterated for that language? E.g. Geʿez—for example —, not having its own modules for headers. With another script 🇨🇬. This is so for as long as I remember but seems an error. If one transcribes using f N tr entries get categorized as “terms with redundant transliterations”, for why should one even do it instead of it being auto-transcribed? Fay Freak (talk) 02:03, 4 July 2021 (UTC)
 * Editors in some languages seem to want auto-transliteration of inflections while editors in other languages don't. I had this argument with User:Rua awhile ago; I wanted auto-transliteration of inflections in Arabic. Greek and Russian editors specifically don't want this, it seems. There's actually support in Module:headword for auto-transliterating the inflections using the  setting, which is set by the Arabic modules; so for example  has the plurals transliterated. Note also, there's a comment in   in Module:headword around line 363 that says:
 * -- Don't show a transliteration here, the consensus seems to be not to
 * -- show them in headword lines to avoid clutter.
 * Unfortunately, the  setting isn't exposed to, so you can't currently set this unless you call Module:headword from Lua, but I will fix this. Benwing2 (talk) 04:36, 6 July 2021 (UTC)
 * Done; use autotrinfl to get all forms to include automatic transliteration, or fNautotr to get an individual set of forms to include automatic transliteration. See User:Benwing2/test-head-auto-translit for examples. Benwing2 (talk) 05:01, 6 July 2021 (UTC)

Template:cite-letter
It could be useful to have Template:cite-letter to, err, cite letters. TVdinnerless (talk) 08:34, 5 July 2021 (UTC)

Template:given_name's "A=" parameter
I asked this last December on this template's talk page, but I got no response.

What is the point of the  parameter? The main thing I see it used for is to override the default capitalization, so that e.g. "A female given name" is instead "a female given name". If leading with "A" is the preferred style, why does the Template not enforce it? If lowercase is the preferred style, why isn't it the Template's default?

173.72.124.108 02:52, 6 July 2021 (UTC)
 * It's partly historical. Some people use A to stick additional qualifiers before the text. IMO this isn't good practice, but it's been this way for a long time. Benwing2 (talk) 05:03, 6 July 2021 (UTC)

Template:doublet
Hi ! Would it be possible to have an optional argument to display the language added to this template ? E.g. would therefore display "Doublet of English " ? Leasnam (talk) 05:09, 6 July 2021 (UTC)
 * You can call the new arg anything else which you feel is more suitable and in line with current naming conventions. I just used 'showlang' as an example. Thanks ! Leasnam (talk) 05:10, 6 July 2021 (UTC)
 * It's certainly possible, but can you describe the purpose for future reference? In what contexts do you see this as useful? — Eru·tuon 20:32, 6 July 2021 (UTC)
 * The entry that uses the template must be already same language of the doublets. Is it necessary to show the language name twice? --Octahedron80 (talk) 00:06, 8 July 2021 (UTC)
 * Well, sometimes I would like to specify that a word is a doublet of a dialectal word, so manipulating the display text would be useful. For example: at I may want to show "Doublet of dialectal English " or "Doublet of Scottish " where 'Scottish' here represents 'Scottish English' not the language Scots. Leasnam (talk) 13:44, 6 August 2021 (UTC)

Template problem
Hey, I'm really inexperienced at creating lua templates and am unable to fix this issue. Can anybody modify this template so the first person singular row header displays properly?

template:tli-inalienable-noun-inflection

Thanks!! Hk5183 (talk) 16:46, 9 July 2021 (UTC)

 * That template doesn't include any Lua...???
 * By way of fix, is what you mean?  ‑‑ Eiríkr Útlendi │Tala við mig 17:10, 9 July 2021 (UTC)
 * By way of fix, is what you mean?  ‑‑ Eiríkr Útlendi │Tala við mig 17:10, 9 July 2021 (UTC)

 * Shows what I know! Yes, that is what I meant! Thank You!! Hk5183 (talk) 17:53, 9 July 2021 (UTC)
 * Shows what I know! Yes, that is what I meant! Thank You!! Hk5183 (talk) 17:53, 9 July 2021 (UTC)

 * No worries, we all start somewhere! FWIW,  is the scripting language used in our module infrastructure, things like Module:nyms, for instance.  Lua gets used in our templates by means of statements within the template like , as you can see over at the Template:synonyms template.
 * HTH! ‑‑ Eiríkr Útlendi │Tala við mig 17:58, 9 July 2021 (UTC)

Module:id-headword
Is there are anyone can help modify code about plural form? Probably to change to automatic for single word noun and not abbreviation. ―Rex Aurōrum｢Disputātiō｣ 04:26, 10 July 2021 (UTC)

Link colouring

 * Automatically inflection or 'transliteration' tables tend to link to words without checking whether they are recorded in Wiktionary for the relevant language. I am looking to fix the Pali tables so that the unlogged-in reader will not follow a blue link only to be directed to a different language.  I consider such misdirecting links a blemish on Wiktionary.  At present by default, there are two colouring schemes:

 * red if the target page does not exist, blue if it does
 * black if the target page does not exist, blue if it does

How is the colour scheme selected at the Lua level? I've looked, but not found it.

For logged-in users, there is a little known customisation that substitutes orange if the target page does exists, but the section for the language is not there. Is there any legal reason why we should not make orange the default colour in this case? (There are threatening-looking accessibility requirements around that may mean our defaults are driven by the needs of the colour-blind.)

I am contemplating using Lua function calls like lua to check for the existence of the target within pages, but I would like to play nicely with the existing system. Perhaps this enhancement is something to be incorporated in Module:links. --RichardW57 (talk) 10:35, 10 July 2021 (UTC)
 * See MediaWiki:Common.css. It makes some "redlinks" black when they are inside a HTML element with the  class.
 * I guess the "little known customization" is MediaWiki:Gadget-OrangeLinks.js? That colors links by getting a list of their categories from the MediaWiki API and looking for any that start with the language name. That doesn't increase the Lua memory or execution time.
 * We certainly can't color all links everywhere in Lua because it would be too expensive in memory and time on certain pages. It would be somewhat similar implementation-wise to our redlink categories, which we disable on certain pages using Template:redlink category and are planning to replace with jberkel's wanted lists because they cause out-of-memory errors. Maybe it wouldn't be too expensive to do that in particular inflection templates though. As a test of efficiency, one of us could extract the titles from an inflection table and write a module that looks for language headers on their pages. — Eru·tuon 04:47, 21 July 2021 (UTC)
 * Doesn't the use of Javascript require a logged in user's permission? I want the warning to be available to the unlogged in user.  Logged in users can enable orange links. --RichardW57m (talk) 13:37, 22 July 2021 (UTC)
 * I'm not quite sure what you mean by a test of efficency? Are you suggesting something like doing the checks for three different invocations of, which would check for the existence of specific fragments in about a hundred pages?  I presume the efficiency metric would be how much of the Lua limits it consumed.  The problem areas are  and , which point to the mostly automatically generated forms of a word in other scripts.  (Manual override is available.)  They cause a problem because attesting the word in another script can be hard, but a word of the same spelling may exist in another language.  The form in the other script usually probably exists, though there may be a valid doubt for a recently adopted writing system, and even some of the older writing systems may have problems with predicting the spelling.  For example, when is the consonant under a repha geminated?  The autogeneration I've seen assumes no automatic gemination.  It's an old habit that is currently out of favour.  For inflection tables, there is usually much less doubt.  It is only where the inflection tables are themselves in doubt that friction is risked when one just creates the entry to satisfy a false blue link.--RichardW57m (talk) 13:37, 22 July 2021 (UTC)
 * Yes, I mean, testing how much Lua memory or time is this going to use, and is it likely to put any pages beyond the Lua memory or time limits? It's an interesting idea, but we have been trying to avoid from wikitext parsing in modules to avoid having more out-of-memory errors. Errors aren't especially likely if this is only going to run in non-Latin-and-non-Han-script pages, but it is a good idea to test anyway. — Eru·tuon 20:14, 22 July 2021 (UTC)
 * Running the Orange Links gadget currently requires a user to be logged in, yes. We could make it run for all users, but that's inadvisable because it makes extra web requests and there would be no way to disable it if you weren't logged in. — Eru·tuon 20:22, 22 July 2021 (UTC)
 * Actually, it looks like logged out users can enable Orange Links at Preferences/V2. That seems to be something we made because I don't see it on Wikipedia. — Eru·tuon 20:27, 22 July 2021 (UTC)

 * I've just had a nasty thought. Would the content of page A depending on the content of page B and the content of page B depending on the content of page A automatically create a troublesome loop or perhaps disable page caching altogether?
 * Loops like that already exist (for instance, +1s -> 加一秒 -> +1s, not to mention pages transcluding themselves), so apparently it doesn't cause the server any problems. This would include things like a page getting its own wikitext in Lua with . — Eru·tuon 04:47, 21 July 2021 (UTC)

Feature request...partial pattern or terminations options in search...
On English Wikisource I recently encountered a word that was partly illegible due to a clipped scan, the ending of the word being -erty.

The page concerned being:- s:Page:New winter evening's companion, of fun, mirth, and frolic.pdf/11

Using a third party site, calling it's self a crossword dictionary I was able to do a pattern search for words that were possible candidates and was able to determine a specfifc candidate for the illegible word, it being liberty and accordingly I marked this using the s:Template:reconstruct which is used at English Wikisource.

I'd like to be able to do similar searches based on 'terminations', or partial patterns for words in Wiktionary directly, on a Special or Project Page if needed.

To some extent I could have implemented a regexp for this, but that would require some degree of technical expertise.

Would it be feasible to have a 'terminations' search option that generated a set of links to potential candidate words present in wikitonary?

More generally, I'd also be interested in seeing additional 'word-solver' pages at Wikitonary, examples being:
 * 'Wordsquare' solver - which is typically finding a specific word in a row of other text ( including it being potentially reversed.)
 * 'Anagram' finder

ShakespeareFan00 (talk) 08:31, 11 July 2021 (UTC)

Links with ć
In trying to reach https://en.wiktionary.org/wiki/re%C4%87i from https://en.wiktionary.org/wiki/tell#Translations, I noticed I was instead taken to https://en.wiktionary.org/wiki/reci#Serbo-Croatian, a completely different word. I could not fix this through editing, and wonder if support for links with ć has been removed. On confirming this, I noticed that the Translations part of "can" no longer leads to Serbo-Croatian "moći", but "moci", again a completely different word. This needs to be fixed.
 * I believe this is due to a recent edit that made to MOD:languages/data2. I'm reverting it for now, because each language should be checked before changing how diacritics are stripped. —Μετάknowledge discuss/deeds 20:36, 15 July 2021 (UTC)

Adding Wikisource functionality to Quiet Quentin
I would very much suggest that we take on the project to add functionality to search and cite from Wikisource texts to Quiet Quentin. Wikisource increases accessibility and searchability of specifically public-domain (and otherwise freely licensed) texts. Many of the works presented there are also scan-backed, meaning that they are produced alongside scans with the page numbers available so that readers may check the transcription against the original scanned text.

There's also a growing interest there of producing film transcripts which could theoretically be used for attestation of some words. There's been talk of including comic transcripts as well. Many of those would not otherwise have searchable transcripts even existing online.

Any thoughts? PseudoSkull (talk) 21:41, 15 July 2021 (UTC)
 * This would be great, and has been suggested a few times as community wishlist project, but nothing ever came out of it. What's missing for this to work? Is the search on Wikisource already providing all the necessary data?

Asturian frequency list
Can anyone generate a frequency list for Asturian? The best place to farm words is probably ast.wikipedia.org Emmett Lathrop Doc Brown (talk) 09:10, 16 July 2021 (UTC)
 * This is not so easy; to do a proper frequency list you need a morphological analyzer to convert words (especially verbs) to their lemma form. Just generating a raw frequency list won't be so helpful. Benwing2 (talk) 16:40, 18 July 2021 (UTC)
 * Plus, Wikipedias are an awful place to get usage. People routinely make up names for things so they can write about them, and there's no guarantee that anyone is a fluent speaker. On the whole, any wiki is a very artificial environment that should be the last place to look for evidence of usage patterns. Chuck Entz (talk) 19:22, 18 July 2021 (UTC)
 * Good replies, but I'd like one anyway, without having to learn coding to generate it :) Emmett Lathrop Doc Brown (talk) 22:04, 10 February 2023 (UTC)

Returning template-parsable text from modules
Whenever I return text from Lua that contains, for example,, it renders simply as the text instead of  (which is how I want it to). What can I do? Thanks a lot. Rishabhbhat (talk) 11:28, 17 July 2021 (UTC)
 * You need to invoke a special function for template expansion, namely frame:expandTemplate where 'frame' is a frame object. Documentation is available at https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Frame_object.  I've written a module that uses it, Module:RQ:pi:Sai_Kam_Mong.  It invokes an item-specific template to write the boilerplate for quoting from a durably archive item, and passes the selected text to it. --RichardW57 (talk)
 * Thanks a ton . Rishabhbhat (talk) 08:47, 18 July 2021 (UTC)

Category:Unami animals
I have forgotten how to fix this category.SemperBlotto (talk) 13:03, 17 July 2021 (UTC)
 * Fixed; the correct name is Category:unm:Animals. —Mahāgaja · talk 15:20, 17 July 2021 (UTC)

Lenape (Unami)
A relatively new user has been adding words in which the language is given as "Lenape (Unami)" but the words are in Category:Unami nouns &c. What language should be used? (An example is at mochipwis.) SemperBlotto (talk) 14:33, 17 July 2021 (UTC)
 * Unami (code ). Lenape (code  ) is a language family covering both Unami and Munsee ; per WT:LT, we only consider unm and umu canonical languages, not del. —Mahāgaja · talk 15:21, 17 July 2021 (UTC)
 * Exactly.  is a language family code for Lenape.  --  04:34, 18 July 2021 (UTC)
 * "del" is not a valid language code. SemperBlotto (talk) 05:35, 18 July 2021 (UTC)
 * “del” may not be a valid language code, but Lenape is a valid language with dialect variations just like French and it’s various patois. Declaring Lenape deprecated and raising Wënami and Munsee to canonical language status is a Wiktionary construct with potential political and cultural impact.Andreas.b.olsson (talk) 05:47, 29 July 2021 (UTC)

Please note that using Lenape (Unami) for the language title does not go against Wiktionary conventions about languages. If two “languages” cannot be distinguished by name, then location distinction in parentheses is the convention to use. Both Lenape groups – the Wënami now living in Oklahoma USA, and the Munsee in Moraviatown Canada – refer to their languages as Lenape. Andreas.b.olsson (talk) 06:43, 29 July 2021 (UTC) Also, I would not say “Munsee was once spoken in my hometown” (NYC). I would say “Lenape, an Algonquin language was once spoken here”.Andreas.b.olsson (talk) 06:49, 29 July 2021 (UTC)
 * It does go against Wiktionary conventions, because it's important that we remain consistent in how we refer to languages. If you want to change an existing practice, there needs to be a discussion that leads to changing it everywhere, consistently. (But it seems your issue is with our splitting, not our naming... maybe can weight in.) —Μετάknowledge discuss/deeds 06:53, 29 July 2021 (UTC)

 * Quoting from Languages"If languages cannot be distinguished by alternative names, the place where each language is spoken is appended in parentheses after its name, as in the case of 'Buli (Ghana)' (code: ) and 'Buli (Indonesia)' (code: ). If languages go by the same name and are spoken in the same place, they can be disambiguated by their linguistic families. For example, 'Mor (Austronesian)' (code:  ) and 'Mor (Papuan)' (code:  ), both of which are spoken in Indonesia."Andreas.b.olsson (talk) 12:52, 29 July 2021 (UTC)
 * It's not the parentheses per se that go against our convention, it's using specifically ==Lenape (Unami)== as an L2 header, because the result of the previous discussion was to use "Unami" as the canonical language name, and L2 headers always use canonical language names. The quote above is about two completely different languages that happen to share a name. Your argument is that Lenape is a single language with two dialects. If the request to merge them that you made at WT:RFM is successful, the language will presumably be named simply Lenape here, so we would use ==Lenape== as the L2 header on entries. We would then distinguish the dialects by means of the lb tag, writing del or del before the definition, and categorizing the words into categories named CAT:Unami Lenape and CAT:Munsee Lenape, which would be subcategories of CAT:Regional Lenape. That's how we treat dialects of other languages here, e.g. CAT:American English, CAT:Finland Swedish, CAT:Quebec French, CAT:Austrian German and so on. —Mahāgaja · talk 14:01, 29 July 2021 (UTC)
 * This misses the point that all human categorizations however useful are in the end artificial. To distinguish between two languages is partly – and very importantly – a sociopolitical act. Are Wënami and Munsee separate languages or dialects of one language? Yes and no. You cannot academically and neatly separate the issues of “naming” and “categorizing”, and isolate them from their sociopolitical effects. Languages are not structures in reality we can investigate academically without causing a deep effect on what we are investigating and cataloging. This is of special concern to languages spoken by few and in the process of revitalization. For Lënape, it would be best to retain some ambiguity in Wiktionary. That means reversing the arbitrary declaration in 2013 to consider them canonical languages (regardless of whether some linguist or other would academically consider them separate languages or dialects). Or, retaining the language codes for Wënami and Munsee but L2’ing the header as Lenape (…). The latter is a perfectly acceptable solution that recognizes the ambiguity of whether they are languages or dialects. Having learned some Lënape based on the Wënami branch I can tell you that I can begin to understand some Lënape as spoken by the Munsee tribe. Andreas.b.olsson (talk) 15:21, 29 July 2021 (UTC)
 * I'm aware that it isn't always obvious whether two lects are better considered different languages or dialects of the same language, and that any such decision has sociopolitical ramifications as well as sociolinguistic ones, but for the purposes of Wiktionary we do have to decide: Are we going to treat unm and umu as separate languages that belong to the family del, or are we going to treat del as one language with two dialects unm and umu (which we may or may not decide to treat as etymology-only codes, meaning that we can still separate CAT:English words derived from Unami from CAT:English words derived from Munsee even when treating them as dialects of the same language). We've made such decisions for other languages in the past, and sometimes people aren't happy with those decisions because they aren't clear-cut. For example, we treat Serbo-Croatian as a single language and consider Croatian, Serbian, Bosnian, and Montenegrin to be dialects of it. On the other hand, we treat Norwegian Bokmål and Norwegian Nynorsk as two separate languages. Both of those decisions are unpopular in certain quarters, but they're the decisions we reached by consensus. Likewise, 4 years ago we agreed to treat Unami and Munsee as two separate languages, and on your instigation we're having a discussion whether to treat them as a single language. I personally don't care one way or the other what we decide, I just want to make sure that our entries are formatted with correct codes and correct L2 headers that correspond to the current decision. If we change our minds over at WT:RFM, someone with a bot will change all the relevant entries and there will be a new status quo. That's fine with me too. —Mahāgaja · talk 19:37, 29 July 2021 (UTC)
 * Note here that it’s listed as “Norwegian Bokmål”, not simply “Bokmål”. There is no reason Lënape could not be treated the same: keep the canonical language distinction of <tt>unm</tt> and <tt>umu</tt>, but rename the headers to recognizing that both languages should be called Lënape. I hope the Nation of Delaware Indians and the Munsee of Moraviantown could be consulted on this since it should be recognized that I am not Lënape but merely an enthusiastic learner of their language and culture. Andreas.b.olsson (talk) 20:44, 29 July 2021 (UTC)

Descendants ()
First the section could only be emptied but not deleted as this message appeared:
 * "Please check Special:WhatLinksHere/pyriformis for any desctree templates linking to Descendants sections you have removed, and fix them."

After the empty section was saved, then in a 2nd edit the section could be removed. That's stupid and should be fixed. --Macopre (talk) 07:55, 20 July 2021 (UTC)
 * That wasn't actually necessary. You could have saved the deletion of the section simply by hitting "Publish changes" a second time. The warning message doesn't prevent the edit, it just makes you the button a second time after reading the message. —Mahāgaja · talk 09:42, 20 July 2021 (UTC)
 * Well, now that works. --Macopre (talk) 12:41, 20 July 2021 (UTC)

Template:taxlink giving weird stuff
For example, at thésium des Alpes, there's a random link to HOUSERATA. Queenofnortheast (talk) 12:19, 26 July 2021 (UTC)
 * OK, it was easily fixed by reverting. You probably want that template semi-protected, though, lest folks like random IPs and me should edit it. Queenofnortheast (talk) 12:21, 26 July 2021 (UTC)

DynamicPageList and category pages
It looks like DynamicPageList, which is used by Module:category_tree to produce "Recent additions to the category" on pages like Category:Japanese lemmas, might be removed soon because the tool is not well maintained and has caused major disruptions to servers: T287380. (Note: Phabricator is for technical discussion. More general comments can be made here.) Whym (talk) 10:07, 27 July 2021 (UTC)
 * That's a shame, it's a useful feature, I like Category:English citations of undefined terms. No replacement, "just use a bot" :/ – Jberkel 10:19, 27 July 2021 (UTC)
 * In some cases, you might be to able to use Special:RecentChangesLinked. It'll show every edit made to pages in a certain category. Edits that add entries to a category might get drowned out, though. — surjection ⟨<tt>??</tt>⟩ 11:27, 27 July 2021 (UTC)
 * On the other hand, I can't blame them for wanting to remove unmaintained duct-tape code which can blow up at any given moment. The other question is isolation, why do "local" deployments (in this case ru.wikinews) have such a disruptive effect on the whole WMF platform. – Jberkel 09:36, 28 July 2021 (UTC)
 * An alternative is an |timestamp&cmlimit=10&cmsort=timestamp&cmdir=desc&format=json API query. Is it possible to format this with Lua? Vriullop (talk) 06:01, 29 July 2021 (UTC)
 * Yes, but unfortunately Lua doesn't have access to the query API. For Lua to see the JSON, a bot would have to save it into a page periodically. That would require a lot of edits because there are about 400,000 category pages that use Module:category tree (which probably generates the majority of the DynamicPageLists). — Eru·tuon 06:35, 29 July 2021 (UTC)

Anomalous Display of URL
Hey- I made this edit and you can see that there's a problem on the page. Is there anything I can do to fix this? Thanks for any help. --Geographyinitiative (talk) 12:35, 27 July 2021 (UTC)
 * Most punctuation in URLs needs to be so the system knows that it's not wiki sytax. Chuck Entz (talk) 14:02, 27 July 2021 (UTC)

Sanskrit template adding entries to "nouns" categories
(Original at template talk page; moved here for exposure, also pining )

The template (which seems to use the   templates under the hood) appears to add entries to categories such as "Sanskrit X-stem nouns" (where X is stuff such as a, ā, i, etc. depending on the stem). This means pages such as are in Category:Sanskrit a-stem nouns and Category:Sanskrit ā-stem nouns even if there's no "Noun" header for the term. I wonder if this could be the intended behaviour at all. If not, is there a way to fix the underlying mechanisms?

Another example can be seen with ; the page uses the /f/n templates, and is added to the "a-stem nouns" and "ā-stem nouns" categories; even if the term is a pronoun.

Ideally the categorization should be decoupled from the actual engine generating the table; or perhaps with some "situation awareness" about whether the template is invoked under a Noun header.

Can this be done? Thanks! --Frigoris (talk) 17:08, 27 July 2021 (UTC)
 * Well, it is the intended behaviour of etc, but it's not beyond the wit of man to add a parameter nocat to suppress this behaviour.  It looks as though it will get passed down easily enough.  I'm not sure whether the code is deliberately obscurantist.  I'm not sure whether the Sanskritists believe in adjectives - it's conceivable that they believe an adjective is three nouns - it would be consonant with their hostility to Anglo-Saxon users.  (You're only allowed your script for Sanskrit if it's an Indic script.)  An obstacle to doing it is that one ought to document the templates while one's at it, which makes much more work.--RichardW57 (talk) 19:46, 27 July 2021 (UTC)
 * I think "nominals" is an umbrella term for adjectives, nouns, proper nouns, etc. (anything that is inflected like a noun). Dictionaries written by Sanskritists (such as Apte's Practical Sanskrit–English Dictionary) regularly use the term "adjective" (see external image; the page is full of the abbreviation a. for adjective).
 * I agree that in practice many adjectives can be used nominally, so the line may be blurred. Still it feels strange and arguably makes the "nouns" categories less useful.
 * In addition, consider the current page for . As I understand it, the page invokes the three noun-declension templates to automate the boring jobs of actually creating most of the inflected forms and putting them in a table. But by doing so the pronoun is nevertheless added to the noun categories. To me this looks more unsatisfactory than in the adjective case.
 * As for the technical part, I have zero expertise with that, but to me the idea about additional parameter sounds reasonable.
 * Overall I think the noun-declension templates are really brilliantly written and very useful. It's just a minor detail about how it interacts with the other features that's creating surprises and confusion. --Frigoris (talk) 07:32, 28 July 2021 (UTC)

Another issue is that the template doesn't allow for adjectives in -a with feminines in -ĩ, or for overrides in case forms. Doing a proper job will take much more work than you might think.--RichardW57 (talk) 19:46, 27 July 2021 (UTC)
 * I believe you can add the MFN stems separately as parameters, as in . The MFN stems could be anything spelled out in full. --Frigoris (talk) 07:32, 28 July 2021 (UTC)
 * @RichardW57, @Frigoris this template also doesnt have parameters like nom_s, etc, for manually entering the declension. and these declension templates needs more fixing. i got this message: Lua error in Module:sa-decl at line 218: No declension class could be detected. Please check the lemma form or specify the declension., when i tried using in the page भगवत्. another thing: using different words  all together for avoiding  ‘no declension class detected’ is not good, at in page सम्पद्, एतद्. can this ‘no declension class detected’ be corrected? and -t, -d, ending declensions are straightforward so why they cant appear automatically . <big style="font-family:Arial;font-variant:small-caps"><u style="color:orange">Svā <u style="color:blue">rt <u style="color:green">ava   • 10:36, 28 July 2021 (UTC)
 * But brute force like this gets the job done. In the case of Sanskrit, it may even work smoothly for its 32 (or whatever) scripts.  It gets a bit of a chore with Pali, whose inflection system I extended assuming that transliteration is inherently unreliable when dealing with multiple writing systems.  I am contemplating automatically transliterating Latin script form overrides for non-Latin stems to simplify the chore of irregular case forms in Pali. --RichardW57 (talk) 19:36, 28 July 2021 (UTC)
 * I think the first step is to document what we have. The obvious way forward for adjectival irregularities is to have m_loc_s etc. at the template level which then get used to derive loc_s at the next level.  For example, one could have loc_s= which would pass down, in order of preference, m_loc_s, mn_loc_s,  and nothing as the override for the locative singular of the masculine form.  The prefixes to the parameter names would be m_, f_, n_, mn_, mf_ and mfn_.  I'm not sure how to handle the cases of having two feminine stems.  Maybe the template would have to branch on whether there was a second feminine.  I intend to do something like this for Pali adjectives, though that is complicated by typically having multiple forms for each combination of gender, case and number. --RichardW57 (talk) 19:36, 28 July 2021 (UTC)
 * it seems the underlying Module:sa-decl/data has no handling for some of the consonant stems. It recognizes the vowel stems, vowel-s-stems, an-stem, in-stem, c/j-, and bh-stems, but nothing else. Since I have zero technical knowledge about properly coding it up, let me ping who have been working on it. --Frigoris (talk) 13:05, 28 July 2021 (UTC)
 * I don't think there's any deliberate attempt to be "anti-adjective" here, or any deliberate attempt to make the modules obscure. It's just that User:JohnC5 who wrote the original version of the modules never managed to finish them, and later users have accreted various things onto them without necessarily thinking through the module design as a whole, so they're currently in an imperfect state. It should be easy enough to pass the part of speech down into the module. A couple of months ago I rewrote Module:sa-decl/data entirely to make it much shorter, and had plans to fix some of the missing declensions (e.g. consonant declensions), but I don't know Sanskrit well at all and got daunted by the massive number of exceptions and complexities described in Whitney's Sanskrit grammar. User:SodhakSH tried to hack support for c/j/bh stems (which don't actually exist as such, they are just instances of consonant stems); this code doesn't work well so I may remove it. Benwing2 (talk) 03:14, 29 July 2021 (UTC)
 * Thanks for the input. I don't think we should worry about the irregulars or the perceived lack of Sanskrit knowledge. It's not as if any one of us were a native Sanskrit speaker anyway?
 * The module already handles the vast majority of possible words (vowel stems, in-stem, an-stem, etc.) It's mostly just the at-stems that needs to be tackled. It doesn't have to be prefect for everything. We can always manually override specific forms if something goes wrong, as I recently found out with, where you can use ins_s etc. for the exceptions. --Frigoris (talk) 08:55, 29 July 2021 (UTC)
 * It's not quite that simple, at the very least the module needs to be able to handle the numerous sandhi rules for consonant stems along with an extra param in cases where the underlying stem isn't completely derivable from the lemma (at least I think we need this) and definitely also an extra param to specify cases where the accent moves. If someone clearly enumerated all the rules and cases that need to be handled, it would make my life a lot easier; otherwise I have to parse through all the stuff in Whitney's grammar. I started to do that in the past but got lost in the details. I also need to figure out the existing code, which implements some but not all of the sandhi rules. Benwing2 (talk) 20:41, 31 July 2021 (UTC)
 * I think in the case of the "-at" nouns, the stems are all derivable from the given lemma. There are two main categories: present active participles and "noun" nouns. The participles needs special treatment with accents etc., while the "true" nouns are more simple, without shifting the accent. For the nouns, the vast majority of them are formed by the "-vat"/"-mat" (possessor) affixes in masculine and neuter. (The feminine is treated just like the ī-stem; the user can simply provide the correct feminine stem manually). The consonant sandhi relevant is the change from -t to -d when followed by bh-, in the ins/dat/abl of dual and plural. The rules are in this table of Whitney: table (here Whitney retains the -s final without having resolved them into the visarga -ḥ). The Vedic forms on top of this include 1) Vedic -ā for -āu in the masculine dual, and 2) Vedic -an for -as in the vocative of masculine single. The rest of Vedic exceptions on that page of Whitney aren't a priority.
 * There are of course exceptions, such as the word for "tooth" that's not from the "-vat"/"-mat" affix. These corner cases can always been treated specially by the user with manual overrides.
 * I understand this is much easier said than done; probably there are things we haven't thought of when referring to the table. It's also especially difficult when trying to understand someone else's work and improve on that. So far my wish list is just the "-vat"/"-mat" nouns, which "should" be the lowest hanging fruit, but I know it's easy to make wishes!
 * Then again, I can see how these more or less ad-hoc treatment can become a problem in the long term. Ideally, what we need is the "clean" solution, which I think was what you were thinking of, right? --Frigoris (talk) 15:08, 1 August 2021 (UTC)
 * Yes, I was trying for a clean solution, as you put it, otherwise we end up with lots of longer-term problems. I'm also trying to handle all consonant stems, not just those in -t. Benwing2 (talk) 23:37, 1 August 2021 (UTC)

Lists of non-existant pages and entries with missing information
Hello. Is there any way to generate a list of:

1. All links to non-existent pages within Macedonian entries, regardless of whether the link is marked as a Macedonian word or not (since many will not be marked in any way), but not within homographic entries in other languages that are displayed on the same page

2. All Macedonian entries lacking a pronunciation (not only those for which specific requests have been made)

3. All Macedonian entries lacking an etymology (idem)

I would like to have the first list so that I can quickly create entries for all Macedonian words that are referenced in existing entries without having to open all 25000+ entries individually and check whether they contain any red links or not. For example, links to non-existent "шмукне",  links to non-existent "лизне" and  links to non-existent "цуцне", but if I had not opened these entries individually today, I would not have known about the red links. Thus, I would like to see "шмукне", "лизне", "цуцне" and hundreds of others in the same place in order to start creating entries according to the list.

Similarly, I would like to have the second two lists in order to efficiently add pronunciations and etymologies where they are missing without having to open all 25000+ entries to see whether this information has already been included or not. For etymologies, this is not really an issue at the moment, since very few Macedonian entries have an etymology, and in most of those cases, serious improvements are needed, but for pronunciations, about a third of entries already have an IPA transcription, so clicking on every entry in a row would be inefficient.

I'm sorry if this has already been answered elsewhere: I searched for comparable queries on Google and found nothing relevant.

Thank you in advance Martin123xyz (talk) 11:52, 28 July 2021 (UTC)
 * The links to nonexistent Macedonian entries is kind of covered by User:Jberkel/lists/wanted/latest, though that only covers links in link templates, not bare links. (A Macedonian list is not currently generated, but the data is there in the  file and I've added Macedonian to the list of language codes, so it will be generated the next time.) — Eru·tuon 18:00, 28 July 2021 (UTC)
 * Thank you for the reply. Will the new list be generated on the 1st of August? Martin123xyz (talk) 06:26, 29 July 2021 (UTC)
 * Yes but usually a few days later than that, it takes some time before the database dump is ready to be used. – Jberkel 08:10, 29 July 2021 (UTC)

Category:Pages using DynamicPageList and Muak Sa-aak orange links
I notice a category Category:Pages using DynamicPageList that is now appearing on the vast majority of category pages (over 37000 currently). Any idea where this is coming from? Also, I notice that links on pages like Category:Muak Sa-aak lemmas are appearing in orange even though they exist in this language. Any idea what the issue is? Benwing2 (talk) 02:12, 29 July 2021 (UTC)
 * The category was apparently added by this commit or one like it listed in T287380, in preparation for getting rid of DynamicPageLists. See also the.
 * The Muak Sa-aak problem is because of line 147 of MediaWiki:Gadget-OrangeLinks.js, which is meant to deal with fragments in URLs. Here it's removing   from the language name and then on line 155 it's searching for   followed by a space and a lowercase character in the category names of the Muak Sa-aak lemma entries, which of course it doesn't find because the next character after   is always a hyphen. I knew the code wouldn't work for all languages, but didn't have a good solution. — Eru·tuon 02:44, 29 July 2021 (UTC)
 * Thanks for your quick response! IMO that's a really nasty hack in OrangeLinks. Can you not check to see whether the part with the supposed senseID is a canonical language name? I see in MediaWiki:UpdateLanguageNameAndCode.js that it's possible to invoke expandtemplates to expand a template, so you could always use this to check whether a given fragment is a language name; or look directly in Module:languages/code to canonical name or similar source to find the list of languages. If none of these possibilities work for whatever reason, we can hardcode the list of languages with hyphens in them somewhere (and even update it using MediaWiki:UpdateLanguageNameAndCode.js). Benwing2 (talk) 02:59, 29 July 2021 (UTC)
 * I'd like to see if we can use an automatically updated list of language names with hyphens in the gadget file so the server can make the least requests necessary. This gadget already makes lots of requests, so it'd be good not to add another. — Eru·tuon 03:14, 29 July 2021 (UTC)
 * Hmm, turns out a senseid doesn't always start with a lowercase letter (search query) as the script assumes. (I didn't read the whole note initially.) So it's not as simple as getting a list of names with a hyphen and a lowercase letter (which is manageable). And all names with hyphens joined by a pipe (for a regex) are 8872 bytes long (demo), which is a little much. It might be possible to compact them somewhat as a regex with something like this only translated to Lua or JavaScript. — Eru·tuon 04:15, 29 July 2021 (UTC)
 * A prefix-tree-based regex with all hyphenated language names is not much shorter than a naive regex... 7040 bytes. — Eru·tuon 04:55, 30 July 2021 (UTC)
 * The best solution would be to use some exotic character in the sense IDs, instead of a hyphen. Something that would never appear in a language name. Like  or  . [Edit: Or just a colon, which looks nicer:  .] But switching the character would inevitably break some links until all pages were updated. It would have been so much easier if the early Wiktionarians eleven years ago had thought about this. — Eru·tuon 06:45, 29 July 2021 (UTC)
 * Does the character only need to be valid in URLs as an anchor (or fragment identifier)? There should be plenty of ASCII characters to go around. — surjection ⟨<tt>??</tt>⟩ 14:15, 29 July 2021 (UTC)
 * How about <tt>@</tt>, <tt>~</tt>, <tt>=</tt> or <tt>+</tt>? — surjection ⟨<tt>??</tt>⟩ 14:28, 29 July 2021 (UTC)
 * Sure, any of those would work because they don't occur in language names. The only requirement for an  attribute is that it can't contain whitespace (ref). — Eru·tuon 20:24, 29 July 2021 (UTC)
 * (Another point: we'd mostly only have to change <tt>anchor</tt> under Module:senseid, as most well-behaved modules use that anyway). — surjection ⟨<tt>??</tt>⟩ 14:21, 29 July 2021 (UTC)
 * Looks like Module:links is currently using Module:utilities to make its sense IDs. Probably need to search for and switch all cases of bootlegged sense IDs to use Module:senseid. — Eru·tuon 20:24, 29 July 2021 (UTC)
 * You switched Module:utilities to use Module:senseid, and I switched Module:links and Module:script utilities to use Module:senseid directly because Module:utilities doesn't do anything extra. Now  is only used in sandbox modules and a sandbox template. — Eru·tuon 21:23, 29 July 2021 (UTC)
 * Module:links <tt>light_link</tt> doesn't use senseid yet, but it doesn't allow a trivial conversion either. — surjection ⟨<tt>??</tt>⟩ 23:05, 29 July 2021 (UTC)
 * Fortunately  is only used in sandbox templates according to this search. I suppose I added it because Module:links/sandbox didn't exist yet. It should probably be moved there and deleted from Module:links as a failed experiment. — Eru·tuon 00:58, 30 July 2021 (UTC)
 * I went through the remaining cases (all modules that do concatenation on both sides with a <tt>'-'</tt> and <tt>"-"</tt>) and couldn't find any more cases that manually construct sense ID anchors. — surjection ⟨<tt>??</tt>⟩ 22:37, 30 July 2021 (UTC)
 * I guess to change this we have to choose a new separator and accept that some links are going to be broken for a while. I'm partial to  as separator because it suggests what it is.   is   in the English section. A colon never appears in language names and is never likely to in the future. There might be languages that use a colon as a letter, but they should use a letter character, and the English name is likely to omit the colon anyway. This would lock us in to never having something with   or   in place of the language name in the sense IDs, which doesn't seem a problem to me. — Eru·tuon 19:10, 31 July 2021 (UTC)
 * Sounds good to me (and certainly better than the existing <tt>-</tt>) — surjection ⟨<tt>??</tt>⟩ 20:06, 31 July 2021 (UTC)
 * I'm fine with  or other separators that won't appear in language names. I think we should bite the bullet and go ahead and make the change. If I'm not mistaken, the worst that will happen is senseid links will break for awhile and you'll end up at the top of the page; we won't get page errors or anything. We can reduce the time by purging the pages that use  and those that use the id param or similar params like id2; we can search through the latest dump to find the latter set of pages. Benwing2 (talk) 20:32, 31 July 2021 (UTC)
 * If there are no objections, I'll change it soon-ish. — surjection ⟨<tt>??</tt>⟩ 21:14, 7 August 2021 (UTC)
 * Aren't there a whole bunch of links from other wikis to individual senseids? --Yair rand (talk) 00:40, 9 August 2021 (UTC)
 * I don't recall ever seeing any on English Wikipedia and w:Template:wikt-lang, which I made to link to English Wiktionary, doesn't have a sense ID parameter. (The iwlinks table doesn't contain link fragments, so no help there.) — Eru·tuon 01:11, 9 August 2021 (UTC)
 * The only test that I can think of is to expand the wikitext of some pages and then search it for links to Wiktionary sense IDs. Perhaps some pages on English Wikipedia with a particularly large number of Wiktionary links. English Wikisource links to Wiktionary fairly often as well. The lists of pages could be generated from the replica databases. I'm doubtful there are any because, before I came along, English Wikipedia didn't have any modules with Wiktionary language data and without that linking to sense IDs is hard to do. — Eru·tuon 01:47, 9 August 2021 (UTC)

 * FWIW I do recall seeing someone add either a senseid or anchor to a Wiktionary page with an edit summary indicating that it was so they could link to it from Wikipedia. I don't know how many Wikipedia pages would link to specific senses (whether via senseid or anchor) but I expect it is >0. I would think someone could search Wikipedia (using the search function? or at least searching a database dump) for links to Wiktionary that used the format senseid links use (e.g. wikt:foobar, where—especially if searching the database dump—you could ignore the text after # until and unless there was a hyphen before the ]] , and manually remove any specific languages whose names have hyphens if they turned out to be numerous), to find examples. I don't know that we should be beholden to not breaking such links, though; we're already breaking links (and can't easily track that) if we move a page to a different spelling, merge or split senses which have such links, reorder numbered etymology sections, etc. - -sche (discuss) 18:24, 10 August 2021 (UTC)

Lua errors
Does anyone else see all the 'Lua error: not enough memory. See ...' errors on the page ? Leasnam (talk) 06:17, 31 July 2021 (UTC)
 * Yep, everybody does around the world, and on several other pages in CAT:E. Unfortunately there's no immediate solution that we're aware of. See Lua memory errors. — Eru·tuon 06:56, 31 July 2021 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2021/July