Wiktionary:Grease pit/2020/April

Could someone please fix the composed forms section in the conjugation template in stehen? The perfect should be ich habe gestanden resp. ich bin gestanden, the pluperfect ich hatte/war gestanden, the future II ich werde gestanden haben/sein. Thanks in advance. --Akletos (talk) 08:41, 2 April 2020 (UTC)

Fixed, looks like some anon edit broke it. If that's the case, it was broken for more than 4 years. :( – Jberkel 11:10, 2 April 2020 (UTC)

@Jberkel: The compounds with separable prefix don't have a zu-infinitive (aufzustehen) and there should be a space before the / in the subj II sections (ich stünde auf / ich stände auf) (The tables of the inseparable compounds don't have this issue). Could you correct those, too? --Akletos (talk) 14:22, 2 April 2020 (UTC)

Done, does it work as expected? – Jberkel 14:57, 2 April 2020 (UTC)

Works fine. Thanks a lot! --Akletos (talk) 15:06, 2 April 2020 (UTC)

Is anyone else noticing the Wiktionary font size recently varying slightly, seemingly at random, or is it something to do with my browser or local setup? Mihia (talk) 18:52, 2 April 2020 (UTC)

I have been wondering about my font sizes, which seem to vary oddly between scripts (e.g. Cyrillic rather small), though not within a single script, but thought that might be a consequence of using Gentium (via custom CSS). PJTraill (talk) 21:57, 2 April 2020 (UTC)

Just to clarify, I am talking about the same font/script appearing slightly larger or smaller, with no seeming explanation. Right now it looks slightly larger. This also happened a day or so ago, and then it went back to normal size, and now it's changed again, without me having (knowingly) done anything. Other websites seem unaffected. Mihia (talk) 22:28, 2 April 2020 (UTC)

Could you have accidentally zoomed in or out. I have occasionally done so in FF. DCDuring (talk) 23:20, 2 April 2020 (UTC)

No, I don't think so. Anyway, that would presumably affect all websites, which isn't what I see. Mihia (talk) 09:32, 3 April 2020 (UTC)

@Erutuon and I were discussing this yesterday. An update to the skin Vector was made which changed the base value of em, increasing it by roughly 123%. I'm not very happy about this change either. --{{victar|talk}} 19:05, 3 April 2020 (UTC)

Thanks, that would explain it. I suppose we'll get used to it. Mihia (talk) 00:06, 12 April 2020 (UTC)

I see that {{anagrams}} has an optional parameter |a= for the alphagram, which appears to do nothing at all. Does anyone know why or have any plans? Somebody attempted to use it, but that was quashed. PJTraill (talk) 22:04, 2 April 2020 (UTC)

You can search for anagrams like this, is one use. DTLHS (talk) 22:10, 2 April 2020 (UTC)

Yes, ordering the letters is a conventional way to look up anagrams in certain word books (Scrabble etc.). Why is it an extra parameter though? Couldn't the code work out what the alphagram is, on its own? Equinox ◑ 22:16, 2 April 2020 (UTC)

Then you wouldn't be able to search for it, unless it was actually displayed on the page. It also saves on Lua memory, probably. DTLHS (talk) 22:17, 2 April 2020 (UTC)

Thanks, that seems a reasonable answer, though it does rely on people filling it in (¡correctly!) PJTraill (talk) 22:42, 2 April 2020 (UTC)

It's updated by a bot periodically. DTLHS (talk) 22:45, 2 April 2020 (UTC)

The entries for lēod, ġelēod have in their declension templates a nom-acc plural ending in -as. The template used, Template:ang-decl-noun-i-m, should be returning a plural in -e. I checked the template and see nothing wrong. Can someone please investigate what is generating the -as ending ? Leasnam (talk) 14:22, 3 April 2020 (UTC)

NM, there actually was something coded in the template that should not have been there. I've updated it. Leasnam (talk) 14:25, 3 April 2020 (UTC)

I'd like to see how many of my audios I screwed up on, so I was thinking about putting something in Template:audio where if it produces a red link, it'll be categorised in Category:Audio screwups or something. I don't touch Modules, I still haven't learned them, sorry about that. And sorry if I make some errors, too. It is inevitable, with my amazing rate of productivity. Sometimes I clean up after myself, at times after others, at times people clean up after me, elsewhen nobody cleans up at all or other users clean up after other non-me entities. So, please make the category and give me another cleanup list to work on. --Gorgehater (talk) 18:23, 3 April 2020 (UTC)

FTR these show up in Category:Pages with broken file links. - -sche (discuss) 03:57, 23 April 2020 (UTC)

sragionare belongs to the category Category:Italian words prefixed with s-, but it's being sorted under A instead of R. The other pages under A that don't belong appear to be in both prefix and suffix categories. Ultimateria (talk) 19:31, 3 April 2020 (UTC)

@Ultimateria: Yeah, currently {{confix|it|s|ragione|are}} is adding the categories ]]. The prefix category is taking the suffix as its sortkey. Maybe instead the sortkey should be the base if it is present, or else the suffix. — Eru·tuon 02:18, 4 April 2020 (UTC)

Please change

	local hanzi = "^[⺀-⺙⺛-⻳⼀-⿕々〇〡-〩〸-〻㐀-䶵一-鿯"
		.. mw.ustring.char(0xF900) .. "-" .. mw.ustring.char(0xFA6D)
		.. mw.ustring.char(0xFA70) .. "-" .. mw.ustring.char(0xFAD9)
		.. "𠀀-𪛖𪜀-𫜴𫝀-𫠝𫠠-𬺡𬺰-𮯠" .. mw.ustring.char(0x2F800)
		.. "-" .. mw.ustring.char(0x2FA1D) .. "]$"

to

	local hanzi = "^[⺀-⺙⺛-⻳⼀-⿕々〇〡-〩〸-〻㐀-䶿一-鿼"
		.. mw.ustring.char(0xF900) .. "-" .. mw.ustring.char(0xFA6D)
		.. mw.ustring.char(0xFA70) .. "-" .. mw.ustring.char(0xFAD9)
		.. "𠀀-𪛝𪜀-𫜴𫝀-𫠝𫠠-𬺡𬺰-𮯠" .. mw.ustring.char(0x2F800)
		.. "-" .. mw.ustring.char(0x2FA1D) .. "𰀀-𱍊]$"

to provide support for Unicode 13.0. Thanks. --沈澄心✉ 03:22, 6 April 2020 (UTC)

@沈澄心:  Done. — Eru·tuon 08:34, 8 April 2020 (UTC)

The retraction diacritic of IPA is represented in Unicode as the subscript minus U+0320 (COMBINING MINUS SIGN BELOW). So, applied to a t, I expect to see t̠. But in the font used, which looks like Lucida to me, it renders as t̠, which (at least on my Mac) looks like a barbell (a vertically compressed H shape). This is utterly confusing. Would it be possible to convert this to standard underscoring as when using <u>...</u>, resulting in t?  --Lambiam 11:41, 7 April 2020 (UTC)

The rendering looks right to me, on Windows (both Firefox and Chrome), with no serifs on the diacritic as you describe. Rather than changing our rendering, maybe you could play with your common.css page to show IPA text in a font that works better? —Mahāgaja · talk 13:30, 7 April 2020 (UTC)

I don’t have a common.css page or for that matter any *.css page on Wiktionary, so this may be the default look for all Mac users. I now know what the barbell diacritic stand for, so for me personally the confusion is no longer an issue.  --Lambiam 07:50, 8 April 2020 (UTC)

Please change 锽 (simplified form) to 鍠 (traditional form). Thanks. --沈澄心✉ 11:56, 8 April 2020 (UTC)

And also 横 to 橫, thanks. --沈澄心✉ 05:45, 27 April 2020 (UTC)

Done. -- Huhu9001 (talk) 02:25, 2 May 2020 (UTC)

I tried to delink the headword line at Danish collateral damage, but it doesn't recognize |head=. Ultimateria (talk) 20:37, 9 April 2020 (UTC)

@Ultimateria: |da-noun= had |base= for this purpose, but that's not the standard name in headword-line templates so I've added |head= as an alternative. — Eru·tuon 20:47, 9 April 2020 (UTC)

@Benwing2: I have noticed that cc/England must be used with {{place}} for civil parishes. I tried a different approach with the large number of places named Ford, but no joy; I had to add the category manually. DonnanZ (talk) 23:28, 10 April 2020 (UTC)

@Benwing2 DonnanZ (talk) 19:57, 27 April 2020 (UTC)

@Donnanz Apologies. I will add functionality to {{place}} to include hidden holonyms. That should allow you to tag an entry with cc/England for categorization purposes but not have it display. Benwing2 (talk) 00:06, 28 April 2020 (UTC)

@Benwing2: Ah, OK, it's yet to be done? I tried it with Whittington, England is displaying. DonnanZ (talk) 09:56, 28 April 2020 (UTC)

@Benwing2: Civil parishes could be split into counties, although some counties, such as Greater London, may have none or very few. DonnanZ (talk) 14:24, 28 April 2020 (UTC)

@Donnanz I'll get to it today or tomorrow. It might be something like an ! at the beginning of a holonym to suppress its display. Benwing2 (talk) 15:11, 28 April 2020 (UTC)

Currently the template for serial semicolons, akin to serial commas, is located at Template:;. Unfortunately, trying to visit the page throws a "Bad title" error, making the code of the template and its documentation difficult to view. Given that, I propose renaming the template, what it should be renamed to I am undecided on. I am not really worried that such a renaming would cause any disruption because only 8 pages reference the template. In addition to being unsure what the template should be renamed to, I am unsure how to rename the page. When I go to the specific version of Special:MovePage that would normally be used in the renaming of the page an "No target" error appears. The alternative that comes to mind for me is deleting the page and then pasting its content at the new destination, but I have reservations about deleting the preexisting revision history, and therefore making it difficult to attribute who has contributed to the template. Any ideas, guidance, or advice would be appreciated. —The Editor's Apprentice (talk) 19:08, 12 April 2020 (UTC)

I've moved {{;}} with Pywikibot to {{serial semicolon}}, leaving a redirect. I think {{;}} should still be used because it's the more intuitive title since it's similar to {{,}}. It often can't be accessed due to a known server bug, but it still can be used as a template with no problem. — Eru·tuon 19:26, 12 April 2020 (UTC)

Awesome! Leaving Template:; is a smart solution. A specific and consistent bug makes sense. Thanks for the assistance. —The Editor's Apprentice (talk) 22:30, 12 April 2020 (UTC)

Is there a technical reason the documentation for this template is on the main page, as opposed to the documentation subpage? — surjection ⟨??⟩ 13:09, 14 April 2020 (UTC)

@Surjection: I don’t see any documentation for this template, either on the main page or on its documentation subpage. In fact, this is a documentation template, so what you probably think to be its documentation is the output of the template. —Tacsipacsi (talk) 00:08, 16 April 2020 (UTC)

The "non-gloss definition" template puts its argument in italics, but sometimes it would be desirable to be able to escape out the italics for certain words or elements. However, this kind of thing, which might be expected to work, actually does not:

{{n-g|Italic ''not italic''}}

The output remains all in italics.

Should this work? Would it be possible to make it work?

I think there are other templates with the same shortcoming, but offhand I can't remember what they are. Mihia (talk) 21:58, 14 April 2020 (UTC)

I think it is a product of modules ignoring the wikiformatting character " ' ' ", but it might be from CSS overriding such wikiformatting. It causes me aggravation with respect to generic and subgeneric taxonomic names, which are supposed to be in italics used in running text in a vernacular language, except when the running text is in italics when it is supposed to contrast typographically, ie, appear as non-italic characterss. Among the templates that suppress in-argument " ' ' " (but not bold " ' ' ' ") are {{ux}} and {{m}}. I wish these worked as {{lb}}, {{a}}, and {{q}} do. DCDuring (talk) 00:33, 15 April 2020 (UTC)

You can always do this: Italic not italic ({{n-g|Italic </span> not <span class<nowiki>=</nowiki>"use-with-mention">italic}}), but that's cheating and should never be used for real (it's never a good idea to write code that relies on how things currently happen to be implemented internally in someone else's code). Chuck Entz (talk) 02:20, 15 April 2020 (UTC)

I wonder why it would work in e.g. {{lb}} and not in e.g. {{n-g}}? Perhaps there is someone with the technical knowledge and inclination who could look at this and just do in the one what is done in the other? Mihia (talk) 19:50, 15 April 2020 (UTC)

@Mihia: {{n-g}} encloses the text in <span class="use-with-mention"></span> so '' isn't involved at all and the regular way of toggling italics doesn't work. MediaWiki:Common.css applies italic formatting to the use-with-mention class. I've added another rule that un-italicizes italics (<i> tags, generated by the '' syntax) within the use-with-mention class. This should fix the issue. — Eru·tuon 20:03, 15 April 2020 (UTC)

@Erutuon: Does it fix it with all the templates mentioned as having the problem of all templates that use "use-with-mention"? DCDuring (talk) 20:53, 15 April 2020 (UTC)

@DCDuring: No, but the same sort of rule fixes italics in {{m}} and {{ux}} (and other templates that use the mention class). I'll have to watch for any bad side-effects though. — Eru·tuon 21:12, 15 April 2020 (UTC)

@Erutuon: Aha! It now works in {{n-g}}! Thank you! Mihia (talk)

@Erutuon: Thanks. DCDuring (talk) 14:36, 16 April 2020 (UTC)

This function omits the sort key "if the final sort key ends up being identical to the page name". However, there are some cases where a sort key that is identical to the page name but differs from DEFAULTSORT is needed. Example: アイアイ. -- Huhu9001 (talk) 05:16, 15 April 2020 (UTC)

@Huhu9001: Good catch. If DEFAULTSORT is present and different from the page title, a sortkey identical to the page title will have an effect. Since Lua doesn't have a way to access the DEFAULTSORT value, I've made format_categories add the sortkey even if it's identical to the page title. — Eru·tuon 05:39, 15 April 2020 (UTC)

(@Sgconlaw, the author.) {{Template:RQ:Butler Hudibras}} displays a "republished in (Please provide a date or year)" note for the 1678 edition, which is not a republishing, but a first edition; my attempts to fix that have gotten me confused. I could use some help. grendel|khan 17:20, 15 April 2020 (UTC)

@Grendelkhan: OK, I think I've fixed it. Thanks for highlighting the error. — SGconlaw (talk) 17:36, 15 April 2020 (UTC)

@Sgconlaw: Ah! I didn't notice the double-pipes there; thank you for fixing that. grendel|khan 02:11, 16 April 2020 (UTC)

Belarusian nouns are not added to Category:Belarusian inanimate nouns or Category:Belarusian animate nouns, if the full gender is given like this: {{be-noun|g=m-in|head=крэ́мень}} with g=m-in at e.g. крэ́мень (krémjenʹ), it only understands if the animacy is specified with a=i or a=a.

Can this be fixed? --Anatoli T. ^{(обсудить}/^вклад) 12:10, 16 April 2020 (UTC)

Belarusian nouns, which use the method that works are added to the maintenance category Category:be-noun with a. --Anatoli T. ^{(обсудить}/^вклад) 00:19, 17 April 2020 (UTC)

@Atitarev Should be fixed. Benwing2 (talk) 19:13, 3 May 2020 (UTC)

@Benwing2: Thank you. More requests for fixing Belarusian are coming! --Anatoli T. ^{(обсудить}/^вклад) 22:55, 3 May 2020 (UTC)

Hello, I was using the visual editor to insert instances of Template:mention and continually noticed that the visual editor did not automatically provide the field for the term mentioned. This seemed odd to me because the documentation, where TemplateData is often stored, for the template is a redirect to Template:link/documentation and when I use Template:link with the visual editor the term field, along with many others, is automatically provided. I think this is because the TemplateData for Template:mention as viewed on the template page contains two TemplateData tables, one copied over from Template:link/documentation and another which is local to Template:mention. I personally think it would make the most sense to delete the local template data for Template:mention and leave the TemplateData from Template:link/documentation predominate, this is what is done for Template:l-self and Template:m-self. Any feedback on what might be a better way to resolve the issue would be appreciated. Also, please note that I myself cannot edit Template:mention since it can only be edited by administrators and template editors. Thanks. —The Editor's Apprentice (talk) 18:44, 16 April 2020 (UTC)

It has been over a month at the point since my original post, so I wanted to follow and be a little more decisive: The fact the Template:link/documentation contains TemplateData suggests to me that consensus was formed that all of the link templates should have the same TemplateData. With that, my request if for someone with template editor permissions to remove the TemplateData which is stored locally at Template:mention. Thanks. —The Editor's Apprentice (talk) 19:50, 25 May 2020 (UTC)

@The Editor's Apprentice: I've removed the template data from {{m}} because it and {{l}} use the same module function (l_term_t) in Module:links/templates with no separate logic. I don't know how template data works and don't use the Visual Editor myself, so please tell me whether the thing in the Visual Editor that uses template data still works after this change. — Eru·tuon 20:21, 25 May 2020 (UTC)

@Erutuon: Thanks much for the quick action and response! The function that uses TemplateData still works for Template:mention and now better than previously as it works as intented, that is in the same way as Template:link. —The Editor's Apprentice (talk) 20:34, 25 May 2020 (UTC)

I've just recently created {{quote-mailing list}} to point to mailing list archives. Some unknown number of quotations (example here) say "Usenet" but do not actually point to newsgroups, rather to mailing lists also archived on Google Groups. Is there a way to add a maintenance line or (preferably) a maintenance category for citations where the newsgroup parameter, for example, doesn't contain a dot? grendel|khan 19:54, 17 April 2020 (UTC)

@Grendelkhan: does this work? —Suzukaze-c◇◇ 02:09, 26 May 2020 (UTC)

@Suzukaze-c: That's perfect; thank you! grendel|khan 02:42, 26 May 2020 (UTC)

Is there any way I can change the output for female equivalents of Portuguese nouns to diff? I see that there was a subpage for Portuguese at the accel modules, but it was deleted to use the common framework. Related languages don't even have accelerated creation of these forms though. Ultimateria (talk) 17:26, 18 April 2020 (UTC)

Where we have grouped senses with nested numbering (using "##" syntax), the generated layout is presently like this:

1. ...

2. ...

1. ...

2. ...

3. ...

1. ...

2. ...

How feasible would it be to change this to:

1. ...

2. ...

2.1. ...

2.2. ...

3. ...

3.1. ...

3.2. ...

? Mihia (talk) 02:43, 19 April 2020 (UTC)

You can do this via CSS, using counters. Check out this StackOverflow answer for an example. - TheDaveRoss 12:09, 20 April 2020 (UTC)

@Mihia forgot to ping. - TheDaveRoss 12:11, 20 April 2020 (UTC)

@TheDaveRoss: Thanks. Could this be applied globally, so that everyone would by default see the nested numbering? Is this feasible? Mihia (talk) 17:36, 25 April 2020 (UTC)

Then, @TheDaveRoss, Mihia, why is the first version default and not vice versa? Default is supposed to be recommended by the designer. The second version looks much more logcial and preferable to me... ‑‑Sarri.greek ^♫ | 19:13, 26 April 2020 (UTC)

@Mihia, Sarri.greek The first style is the default for numbered lists on MediaWiki. The second could be made default by updating the common.css files, though I think a broader discussion ought to take place to change such a fundamental stylistic feature of the site. I think the second is preferable as well, I would support switching to it. - TheDaveRoss 20:44, 26 April 2020 (UTC)

(edit conflict) It's feasible, but it's probably a good idea to see what people think first. The style I use is decimal, lower-latin, lower-roman (top level, 1., 2., 3.; second level, a., b., c.; third level, i., ii., iii.). Not sure where I got it from. OED and LSJ and Lewis and Short use upper-roman, decimal, lower-latin (I., II., III.; 1., 2., 3.; a., b., c.), which would give Wiktionary an old-fashioned vibe. I'm not sure I like the decimal.decimal.decimal format because it's verbose and reminds me of academic papers... — Eru·tuon 20:57, 26 April 2020 (UTC)

Thanks. More comments are encouraged, in order to gauge what format people prefer. Mihia (talk) 02:14, 27 April 2020 (UTC)

I support 3.1, 3.2, ... style. -- Huhu9001 (talk) 02:04, 2 May 2020 (UTC)

I recognize this is probably seen as necro-ing a dead thread, but I thought it would be worth noting that I also support the decimal style being discussed/proposed being made the default. —The Editor's Apprentice (talk) 19:58, 25 May 2020 (UTC)

@Suzukaze-c, TAKASUGI Shinji, MiguelX413 I'm trying to make a conjugation table template set for Okinawan. My incomplete work so far is located at Template:ryu-conj-palatal, Template:ryu-verbconj-auto, and Template:ryu-verbconj-row, and its module backend is at Module:ryu. Currently I'm stuck with a romanization bug. As seen here, the template is currently outputting the correct kana form of the shuushikei むちゅん, but it is romanizing like junk; it coughed out "muchiュn", converting the small hiragana into a katakana instead of romanizing ちゅ = chu.

Other notes:

• Due to how Okinawan verbs work, verb lemmas end in a stem-final mora, followed by another kana, and a moraic nasal. Some forms (such as terminal かちゅん and perfective かちゃん) require only the latter two items to be deleted, and some others (like the mizenkei-based forms) require the deletion of all three of these items to attach an ending.
• Okinawan has more flexible syllable phonotactics than Japanese. Syllables like /t͡ɕe/ are very commonplace.
• Okinawan has no standardized orthography. Currently I'm using a phonemic hiragana method that uses a choonpu to mark long vowels.
• Many Okinawan verbs alternate between palatal stems and non-palatal stems.
• I wanted to also keep the number of verb conjugation templates to a minimum, so instead of making k-, g-, t-, d-stem templates separately I made Template:ryu-conj-palatal and used a bunch of switches instead.

Any help?

mellohi! (僕の乖離) 22:01, 19 April 2020 (UTC)

I’m not sure where the error occurs, but if むちゅん is romanized as muchiュn, that means むち and ゅん are romanized separately. — TAKASUGI Shinji (talk) 22:49, 19 April 2020 (UTC)

Yeah, I think that's caused by {{{kana|}}}}}.{{{1}}} in Template:ryu-verbconj-row. — Eru·tuon 22:52, 19 April 2020 (UTC)

Removed the periods, and the romanization is working properly. Cheers! mellohi! (僕の乖離) 23:17, 19 April 2020 (UTC)

@Mellohi! Sorry for the late reply, seems like you guys got everything figured out! I was also attempting to do so @User:MiguelX413/sandbox#Okinawan_Conjugation_Charts. MiguelX413 (talk) 15:36, 20 April 2020 (UTC)

I have come across a couple of cases where the links no longer work, where I get a "404 Word not Found" message; e.g. at bell punch. DonnanZ (talk) 23:04, 19 April 2020 (UTC)

I see that is an interesting situation, but I don't believe it is in error. Looking at a PDF of the dictionary apparently sourced from Project Gutenberg (WARNING: This file is very large (15,000+ pages), click at your own risk!) the term was in the dictionary, and is on page 1,255 of the PDF. The thing that tipped me off to why there is a problem was the fact that bell was a top level term under which bell punch was listed. What seems to be the case is that the person who organized the information for websters1913.com did it based off of the top level terms, a style that sticks with how the dictionary was designed. Thus, when searching for bell punch no entry is found. You can find the evidence for this at the bottom of websters1913.com's entry for bell, where the information on bell punch is. I would change Template:Webster 1913 so that it would process an optional parameter allowing a target other than the page name to be set, but the template is unfortunately protected in such a way that I can not. I would suggest asking a template editor your familiar with or the person who most recently edited Template:Webster 1913 to make the necessary change. —The Editor's Apprentice (talk) 04:52, 20 April 2020 (UTC)

@The Editor's Apprentice, Donnanz: Okay, parameter 1 in {{Webster 1913}} can now be used to specify the Webster entry to link to (diff). — Eru·tuon 06:09, 20 April 2020 (UTC)

Thanks, I hope there isn't too many cases like that, they may have to be found by trial and error. DonnanZ (talk) 08:46, 20 April 2020 (UTC)

User:Pinnerup reported that the links from {{he-defective spelling of}} were not clickable. After some testing, we figured that the problem is specific to Chrome/Chromium and that Chrome 80 is not affected, but 81 is, and I've confirmed that the latter is affected. It seems that with the current HTML structure,

<ol>
    <li>
        <span class="form-of-definition use-with-mention">
            defective spelling of 
            <span class="form-of-definition-link">
                <span class="form-of-definition-link">
                    <i class="Hebr mention" lang="he">
                        <a href="https://dictious.com/en/%D7%90%D7%95%D7%94%D7%9C#Hebrew" title="אוהל">אוהל</a>
                    </i>
                ‎</span>
            </span>
        </span>
     </li>
</ol>

all pointer events to the inner form-of-definition-link span are ignored, and trying to hover over the cursor over the link (even with DevTools) will only find the outer span.

Would it be possible to get rid of one of the two spans (since doing that manually fixes the link), or is this possibly a Chrome regression/bug that should be reported? Some other notes:

• having a link inside two spans works fine, so it's something more specific than that
• if only the HTML file (no assets) is saved, the link also works fine, so it has to be something more specific than even that

— surjection ⟨??⟩ 15:51, 21 April 2020 (UTC)

Hello everyone. Can anyone please fix the article 人? It looks horrible with so many "lua error"s. I don't know why. The error starts below Japanese section. Please fix that. Thank you. --Humberto del Torrejón (talk) 01:53, 22 April 2020 (UTC)

My suspicion is that there is something seriously wrong with this "lua" implementation, or parts thereof. Somewhere I think I saw mentioned that there should be 50MB of memory available. The entire source of this page is only about 63K, so on that basis it is needing 800 times the size of the entire source to process the page. That does not seem remotely right or reasonable to me. However, if there is some reasonable explanation for it then I am happy to be corrected. Mihia (talk) 00:13, 27 April 2020 (UTC)

And Wiktionary:Grease pit is currently 2,100 bytes. If you look at the stats, the post-expand include size is 1,077,361 bytes. There are approximately 157 modules called by the entry that fill in data, handle formatting, linking, language-specific markup, categories, etc. Without the modules there would be astronomical amounts of research and typing to do a page like this. Sure, there are inefficiencies that come from using general-purpose templates and modules that have code and data for things that aren't in the entry, but they do a lot of necessary things in millions of other entries- and only run out of memory in these 19 or so. We need to figure out how to fix this, but it's not the kind of problem you think it is. Chuck Entz (talk) 04:01, 27 April 2020 (UTC)

Obviously these two sites are unlikely to have an "English" section to target. I don't think it was always like this but I don't see any recent changes to the templates or to Module:wikipedia. DTLHS (talk) 23:53, 22 April 2020 (UTC)

@DTLHS: I'm not seeing the problem. Are you still experiencing it? Do you have any particular entry with the problem. DCDuring (talk) 06:04, 27 April 2020 (UTC)

All entries. For example hammerkop. DTLHS (talk) 16:11, 27 April 2020 (UTC)

Hi there, I couldn't see a better place to ask: does anyone know if there are any browser plug-ins that let a user do a tool tip Wiktionary look up? eg:

• user specifies in preferences look up language and Wiktionary language space, eg German, en.
• user browses page, eg https://de.wikipedia.orghttps://dictious.com/en/Heimat_(Filmreihe)
• user hovers over word (or indicates look up through a key combo), eg "Heimat"
• tool pulls up "en.wiktionary.orghttps://dictious.com/en/Heimat#German."
• tool presents relevant definition as a hover

If not somebody should write it! But the idea seems so blindingly obvious (as in, the pages are structured to facilitate things like this) I wondered if it had already been done.

JimKillock (talk) 09:29, 24 April 2020 (UTC)

Depending on your browser, you might have built-in lookup features that you can customise, usable from the address bar. See User:Equinox/How_to_be_fast#Custom_searches. Equinox ◑ 13:21, 24 April 2020 (UTC)

Looking back at how Safari works, you can do this with Wikipedia already (select / depress word, choose wikipedia from the lookup options.) I will take a look to see if that is customisable / customisable enough to get the relevant definition (it may not be) JimKillock (talk) 14:11, 24 April 2020 (UTC)

I think you mean m:Wiktionary/Look Up tool but it is not working anymore. You can try an add-on for Firefox. --Vriullop (talk) 17:19, 24 April 2020 (UTC)

Yes these are exactly the kind of tool I was hoping for. Shame the first isn't working. The developer of the second says he can only get the API to deliver definitions for English – this is a bit surprising, it would be handy to know if he has missed something, or else help him raise a ticket for new kinds of request to the API. JimKillock (talk) 16:43, 25 April 2020 (UTC)

See mw:Wikimedia Apps/Wiktionary definition popups in the Android Wikipedia app. It was experimental only developed for English. --Vriullop (talk) 19:17, 25 April 2020 (UTC)

See also dictionaries.io for MacOs / Win / Kindle; this repurposes Wiktionary data in exactly this way. Seems to do the job! JimKillock (talk) 18:04, 27 April 2020 (UTC)

Looking at Category:Latin words by suffix, I'm confused about why some of the nested categories, like "Latin words suffixed with -o (adverb)", appear only in the expandable/collapsible sublist under "Latin words suffixed with -o", but others, like "Latin words suffixed with -ies (adverb)", appear twice: once in the sublist for "Latin words suffixed with -ies" and once in the main, non-collapsible list. What affects the way these kinds of categories display? I assume it would be better for all of them to only appear once, in the collapsible lists.--Urszag (talk) 16:49, 24 April 2020 (UTC)

@Urszag: Actually, Category:Latin words suffixed with -o (adverb) is in Category:Latin words by suffix, but it's at the end under ō, not under o where it should be. Fixed. — Eru·tuon 18:30, 24 April 2020 (UTC)

Thanks. I'm not sure whether the current behavior is optimal: now all categories are showing up for me even when collapsed, and uncollapsing/expanding the blanket category displays an additional link to all of the subcategories. Shouldn't the subcategories instead be hidden when the blanket category is collapsed? At least it's consistent now, though.--Urszag (talk) 02:34, 30 April 2020 (UTC)

I think we mentioned this before, recently as well. On pirksts, the picture and labels are not very useful because you can only see half the letters in the words, and they're in the wrong place. WTF? --Vitoscots (talk) 14:54, 26 April 2020 (UTC)

I think at some point there must have been a change to something that has systematically broken these picture labels. It could be that the coordinates originally referred to the top left of the text, but now refer to the centre of the text, or something like that. This would shift all the labels to the left. Mihia (talk) 21:04, 26 April 2020 (UTC)

I don't think e.g. Everlark and Peeniss should link to the component words, since they are fictional names that would fail WT:FICTION. Can the template support this? How? Equinox ◑ 15:41, 26 April 2020 (UTC)

@Equinox: Sure, you can do that by changing {{blend|en|Everdeen|Mellark}} to {{blend|en|alt1=Everdeen|alt2=Mellark}}. Or maybe the components should link to Wikipedia. — Eru·tuon 21:00, 26 April 2020 (UTC)

When language code mul is used in etymology templates, it shows up as "Translingual" (capitalized as if it were a name, but it's not) and linking to w:Translingual language, which is a redlink. Can someone please fix these bugs?​—msh210℠ (talk) 13:15, 27 April 2020 (UTC)

@Msh210: To get what you want, you need to uncapitalize the word "Translingual" in Module:languages/data3/m, and add a correct wikipedia link to wikidata:Q20923490. -- Huhu9001 (talk) 15:43, 1 May 2020 (UTC)

@Msh210, Huhu9001: I've pointed the link to w:Translingualism. At first I also decapitalized "Translingual", but then I reverted myself because that changed the names of all the categories pertaining to mul, which is a more dramatic change than I feel like making at the moment, especially since I don't have a bot to clean it up. —Mahāgaja · talk 21:54, 1 May 2020 (UTC)

@Mahagaja: Well in this case, you can also get to "function export.format_etyl" in mod:etymology, and insert

elseif source:getCode() == "mul" then
		info = {
			display = "]",
			cat_name = "Translingual",
		}

. This hopefully will leave the category names unchanged. -- Huhu9001 (talk) 01:34, 2 May 2020 (UTC)

That prospect intimidates me too. @Daniel Carrero, Erutuon, PUC, y'all have edited that module the most; is one of you willing to make the above-mentioned edit? —Mahāgaja · talk 07:40, 2 May 2020 (UTC)

@Mahagaja: Done. I wish it could be done with the language data module, but I don't want to work that out right now. — Eru·tuon 06:36, 3 May 2020 (UTC)

There are a couple of templates -- https://en.wikipedia.orghttps://dictious.com/en/Template:Clarify and https://en.wikipedia.orghttps://dictious.com/en/Template:DISPLAYTITLE -- that I would like to have available in Wiktionary. Can I just copy and paste these and it will work, or is it more complicated than this? Mihia (talk) 17:12, 27 April 2020 (UTC)

Don't copy templates from Wikipedia. The primary reason for this is not technical, but out of respect for the fact that we are different wikis, and we generally have our own ways of handling things. We already have {{rfclarify}} for the former purpose, and the latter is not even a template, but rather a MediaWiki magic word, so it's already available here, as you'll see if you try to use it. —Μετάknowledge^{discuss/deeds} 17:28, 27 April 2020 (UTC)

OK thanks. Mihia (talk) 17:45, 27 April 2020 (UTC)

... however, {{rfclarify}} doesn't seem to be what I want. It says "Use this template in the definition line of a foreign word to request a clarification if the translation into English is ambiguous." I want something to put against an English definition of an English word, and also, ideally, to have a parameter for explaining the reason. Do you (or anyone) know of anything that would serve this purpose? Mihia (talk) 17:52, 27 April 2020 (UTC)

@Mihia: It is this template. The documentation restricts it to foreign words for no reason. Even if the claim that the template is but for foreign words is bolded and underlined (bad style on the web for something that is not a link) it still appears that people slept when making, maintaining and revamping this template and its documentation, which my mind is clear about because we made an overview of the request templates half a year ago. Fay Freak (talk) 18:04, 27 April 2020 (UTC)

OK thanks, I've used that. If anyone has an interest, the template could be generalised even more, e.g. to read just "clarification needed". It refers to "definition", but it needn't be a definition that needs clarifying (for example, it could be a reference). Also, ideally, there could be a parameter to explain in what way the thing needs clarifying; this could be visible by a click or mouseover. Mihia (talk) 19:41, 27 April 2020 (UTC)

Hmmm. It might be better to facilitate accurate categorization by having a separate template (redirect) for the most common types of requests for clarification, as well as an explicit cat= parameter. DCDuring (talk) 14:03, 30 April 2020 (UTC)

e.g. . Equinox ◑ 18:49, 29 April 2020 (UTC)

I was wondering that too. It's not only me then. —Rua (mew) 19:14, 29 April 2020 (UTC)

I suspect it's related to this. Chuck Entz (talk) 02:18, 30 April 2020 (UTC)

It was announced at Wiktionary:Wikimedia Tech News/2020#Tech News: 2020-17. Now it uses the same font as the edit area. You can change it in your preferences. --Vriullop (talk) 06:53, 30 April 2020 (UTC)

Except that it messes up combining diacritics. Not good. —Rua (mew) 15:34, 30 April 2020 (UTC)

Ya, combining diacritics appear over the following character instead of over the expected one. I tried Noto Mono on the theory that might be better, but I get the same behavior. Meanwhile, Consolas behaves correctly, putting the combining diacritics where they belong. ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:10, 30 April 2020 (UTC)

Everson Mono treats combining diacritics better, if you feel like installing it. I have it set as the font for pre and code tags, so it is used on Module, JavaScript, and CSS pages, and in the output of syntaxhighlight tags. However, the change to the diff font has apparently been at least temporarily reverted due to another bug. — Eru·tuon 18:50, 30 April 2020 (UTC)

I'm putting together {{RQ:Britannica 1911}} to link to the 1911 Britannica. (And will be adding a template for the 1889 Ninth Edition (there is some call for quotes from Macaulay's articles, for example). However, I'm unsure of how to link to given pages, as the Internet Archive's link numbers have a variable offset, depending on the number of unnumbered illustrated-plate images included up to that point. Should I just have the template take a URL as a parameter? It seems a bit clunky to do that. grendel|khan 02:21, 30 April 2020 (UTC)

Link to Wikisource. --Elvinrust (talk) 02:24, 30 April 2020 (UTC)

If the offset varies throughout each volume, then the only rigorous (though painful) way is to work out what all the different offsets are and program the template accordingly. A lazier way is to require editors to manually specify the URL. — SGconlaw (talk) 06:28, 1 May 2020 (UTC)

This was brought up in 2011 on the talk page for Template:prefix, but still hasn't been fixed. Entries using Template:prefix are currently alphabetized by the prefix on category pages, which is inconsistent with the behavior of Template:affix, which causes alphabetization by the base. As an example, see Category:Latin words prefixed with ob-, where words like obaemulor obliviscor obtrudo are listed under O when they should be listed under A, L and T respectively.--Urszag (talk) 02:43, 30 April 2020 (UTC)

@Urszag: This fixes it, I think. Now obaemulor has the sortkey aemulor as desired. — Eru·tuon 08:03, 30 April 2020 (UTC)

@Erutuon: Thanks for the quick fix! I assume it will just take some time for the rest of the pages in the category to update?--Urszag (talk) 08:30, 30 April 2020 (UTC)

@Urszag: Yeah. Hard to predict how long exactly. — Eru·tuon 08:42, 30 April 2020 (UTC)

@Erutuon: Thanks again; now all of the entries with the prefix template look like they are sorting correctly. I just noticed that a similar issue exists with Template:confix (examples: contumax sorting on -ax in Category:Latin_words_prefixed_with_con-, bicinctus sorting on -us in Category:Latin_words_prefixed_with_bi-): would you be able to edit the module to fix that also?--Urszag (talk) 21:59, 8 May 2020 (UTC)

@Urszag: Yep. This should do it. — Eru·tuon 01:18, 9 May 2020 (UTC)

Anyone know how to turn off notifications about Wikidata pages being linked to Commons categories? I turned off notifications here, at the Commons and at Wikidata using “Preferences” and I’m still getting the unwanted notifications. — SGconlaw (talk) 06:25, 1 May 2020 (UTC)

@Sgconlaw: Where do you get these notifications? At the top of the page, in your  notices? Or in your watchlist? Via email? Or maybe at some other place? —Tacsipacsi (talk) 18:24, 1 May 2020 (UTC)

Yes, in my notices at the top of my page. — SGconlaw (talk) 18:41, 1 May 2020 (UTC)

Can you show a screenshot of a such notification? If I’m right what kind of notification it is, it needs to be disabled on Commons, in the “Connection with Wikidata” row. —Tacsipacsi (talk) 23:29, 1 May 2020 (UTC)

@Tacsipacsi: that’s what is puzzling me. I disabled the “Connection with Wikidata” notifications not only at Commons but everywhere else (Wikidata, Wikipedia, and Wiktionary), and yet I’m still receiving them. — SGconlaw (talk) 06:43, 3 May 2020 (UTC)

OK, it looks like perhaps I forgot to save my change to the preferences at the Commons. I’ve now stopped receiving notifications, it seems. Thanks. — SGconlaw (talk) 04:17, 9 May 2020 (UTC)