Wiktionary:Grease pit/2022/July

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← June 2022 · July 2022 · August 2022 → · (current)

---

My new page just keeps showing as harmful

I’m completely new to this and don’t really have a clue what I’m doing. Does anyone have a template I could at least work from? — This unsigned comment was added by Oimatrixio (talk • contribs) at 00:11, 2 July 2022 (UTC).

@Oimatrixio: that's because self-promotional encyclopedia-style articles like you've been trying to create aren't allowed here. This is a dictionary, not a free hosting provider. The abuse filter is doing exactly what it was designed to do. Chuck Entz (talk) 02:06, 2 July 2022 (UTC)

Error in translation lists

When a Thai translation is included, it is placed in bold in the header of the translation template in addition to alphabetically in the list. It should only be in the latter. I've seen this on multiple pages. An example is at illegal. kwami (talk) 22:57, 2 July 2022 (UTC)

I don't see a problem with the Thai translation. On my screen, it is not rendered in the header of the translation template, nor is the font bold. (However, the font size of the Thai text is slightly larger than it would be by default due to the CSS here.) Could you provide a screenshot or browser details to reproduce? 98.170.164.88 23:11, 2 July 2022 (UTC)

I do, but not with its formatting. The transliteration given is according to ISO 11940 Part 1, which is not the Wiktionary scheme. The phrase used for translation looks like three words to me, and I would delete the first, the colloquial relative thingy. The next two might be an SoP, unless one can show that they are a single word. (What should I do there - create and RfD, or create and take it to the Tea Room?) --RichardW57m (talk) 09:51, 12 July 2022 (UTC)

Try visiting one of those pages using a different browser that you're not logged in on. I suspect that it's some kind of interaction with one or more gadgets you have enabled and/or your common.js. I've tried it with two different browsers and the mobile version (on my regular computer), and I see nothing wrong. Chuck Entz (talk) 05:01, 3 July 2022 (UTC)

Sounds like you might have selected Thai as a "targeted language" using the "select targeted languages" link at the top of the translation box. You can remove it by following the same procedure. This, that and the other (talk) 09:50, 3 July 2022 (UTC)

Yep, I tried it myself, this is it. Guess I never used that feature before. Seems pretty nice. 98.170.164.88 07:24, 4 July 2022 (UTC)

Accelerated creation of French feminine equivalents of nouns

Currently the code for the accelerated creation of French female noun equivalents (e.g. grogneuse) uses {{head|fr|noun}} as the headword template. I think this should be changed to {{fr-noun}} because the former does not generate a link to the plural of the feminine nouns. I hope someone who knows the code well enough to edit it will see this. Acolyte of Ice (talk) 12:25, 4 July 2022 (UTC)

@Acolyte of Ice Yup, I think I already fixed Spanish to do this. Benwing2 (talk) 05:01, 5 July 2022 (UTC)

i find the visual editor UI difficult but i want to switch because it's much easier to read

the visual editor seems only to appear for me when i press reply , which i thought at first was a bug, but i suppose that must just be the way it is right now.

but i find the UI very difficult to use. to insert a link, i cant just type [[ page ]] even if i know for absolute certain that i am typing the correct link. instead i have to type the link , then when the popup loads, type the pagename into the popup, then press tab (or click the insert button), and then press the right arrow twice to escape out of it, or else the UI will either delete the link or add every consecutive word that i type into the link. i find this very frustrating. however i dont want to say more if this feature is being developed at the MediaWiki level, as that would mean its essentially out of your hands to control how the UI works.

i do appreciate the larger font size however. do you know if it will ever be loaded into Wiktionary fully, such that i can edit outside of the '''reply''' function?

thank you for your time and advice,

—Soap— 01:50, 5 July 2022 (UTC)

When replying to a post, you can switch between Visual and Source modes using the buttons at the top-right of the Reply tool. Personally I still prefer Source mode, especially in our entries which are so template-heavy, but Visual mode is great for editing tables or other complex material where the wikitext formatting just gets in your way.

You can use VisualEditor (mw:VisualEditor) outside the reply tool by turning it on in your preferences, "Beta features" tab. After saving this preference, I recommend going back to your preferences on the "Editing" tab and changing "Editing mode:" to "Show me both editor tabs". This will give you full control over whether you edit a page with the visual editor or source editor. This, that and the other (talk) 05:19, 5 July 2022 (UTC)

Okay thank you. I enabled that and the other tool underneath it. It's still the same UI .... I get the bigger text but I also get the sense that the software is making it difficult on purpose for me to add links in what I write. I will just use bold text instead whenever possible and if I need to I can go back to source-code mode and press the link button there. —Soap— 21:51, 5 July 2022 (UTC)

Template not transcluded?

Why is the template that I return from Module:tr-verb_form_of not transcluded in [1]? — Fytcha〈 T | L | C 〉 00:06, 6 July 2022 (UTC)

Ok I figured it out. Apparently you have to call the form-of module directly. Is there no way to make the string returned by the module be transcluded again?

Also @Benwing2, I'm not sure what this terminfo_face does: Module:de-inflections#L-167 (I used this module as a model for my own.) — Fytcha〈 T | L | C 〉 01:17, 6 July 2022 (UTC)

@Fytcha The terminfo_face is the same as the second param to full_link() in Module:links. This should be documented better but it takes the value "term" to be italicized. Somewhere the doc page for Module:links it points you to Module:script utilities/data for the face values. As for returning templates, modules are invoked after template expansion so returning a template normally doesn't work. You can expand a single template invocation using frame:expandTemplate{ title = 'template', args = { 'arg1', 'arg2', name = 'arg3' } } which is similar to expanding {{template|arg1|arg2|name=arg3}}. It may be easier, however, to use frame:preprocess(string), which expands all templates in the string. The frame object is as passed into Lua; if you don't have access to it, you can retrieve it using mw.getCurrentFrame(). Benwing2 (talk) 02:41, 6 July 2022 (UTC)

Thank you a lot for the explanations @Benwing2. It all makes sense to me now. — Fytcha〈 T | L | C 〉 02:51, 6 July 2022 (UTC)

Stellar Wiktionary creation

Hello, I tried to create Stellars Wiktionary page, but it identified it as harmful, even though I'm just trying to create it. Any tips? — This unsigned comment was added by Moonpiano (talk • contribs) at 06:35, 7 July 2022 (UTC).

What makes you think whatever you tried to add is suitable for a dictionary? — SURJECTION ^{/ T / C / L /} 07:57, 7 July 2022 (UTC)

Because the filter is doing its job - don't make it. Vininn126 (talk) 09:21, 7 July 2022 (UTC)

Wiktionary does not aim to be an encyclopedia, and the relevant rules for creating entries for names can be found in WT:NSE. Although it is not mentioned explicitly (maybe we should change this), I think the consensus is that names of specific people should not be included because they do not add new meanings to the word. --kc_kennylau (talk) 00:41, 10 July 2022 (UTC)

While we shouldn't have any entry at Stellar that describes a specific person, we should have an entry at Stellar that describes the name itself -- derivation, pronunciation, variants, date of appearance, etc. The former content belongs in an encyclopedia, but the latter content is lexicography and belongs here. ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:06, 26 July 2022 (UTC)

Hebrew noun pos is unrecognized pos?

The page מושגים and other pages that transclude {{he-noun-form}} are categorized into Category:head tracking/unrecognized pos for some reason, and I don't understand why, since "noun form" should be a recognized pos. --kc_kennylau (talk) 00:35, 10 July 2022 (UTC)

I seem to have fixed it by removing a space. --kc_kennylau (talk) 00:45, 10 July 2022 (UTC)

@Kc kennylau: yes, but that caused it to produce "Category:Hebrew noun pluralforms". The problem seems to be that the ParserFunction strips leading and trailing whitespace from the parameter, so adding a space where it would make sense (at the end of "plural") doesn't work. I tried various fixes, and they just made things worse. Finally I used "plural%20". The categories come out okay, and the head template at least recognizes "noun form" as a valid POS, though "noun plural form" is still unrecognized. Better than it was, but still bad. Perhaps we should just have it use the whole expression in the switch: ["noun form" vs. "noun plural form"] instead of "noun" + [ø vs. "plural"] + "form". At any rate, I'm a bit tired and I've made enough of a mess of the revision history, so I'll leave it to others to fix. Chuck Entz (talk) 01:57, 10 July 2022 (UTC)

@Chuck Entz I hope I fixed it. --kc_kennylau (talk) 18:04, 10 July 2022 (UTC)

I took the liberty of renaming {{he-noun-form}} -> {{he-noun form}}; {{he-verb-form}} -> {{he-verb form}}; and {{he-adj-form}} -> {{he-adj form}}, using more standard naming. Benwing2 (talk) 05:44, 11 July 2022 (UTC)

@Benwing2 I don't understand why they are considered more standard naming. I have used AWB to generate the list of all the headword-line templates with "form", and 37 of those use hyphens while 38 of those do not. --kc_kennylau (talk) 22:11, 14 July 2022 (UTC)

@Benwing2, kc_kennylau Don't the forms with space follow the principle of making Wiktionary as difficult as possible? The sane solution is to use redirection so as to have both forms - is that too great a burden on bots and other parsers? --RichardW57m (talk) 09:06, 15 July 2022 (UTC)

@RichardW57m, kc_kennylau The reason they're more standard (in my view at least) is that they match the way the non-lemma forms appear in categories, {{head}}, etc. In all these places we have e.g. noun form and not noun-form, so IMO it makes the most sense to be consistent with this. Similarly we have {{given name}} (not {{given-name}}), {{archaic form of}} (rather than {{archaic-form-of}} or whatever), etc. Although I can see your point that currently we are not being consistent with naming of these templates. Benwing2 (talk) 09:11, 15 July 2022 (UTC)

@Benwing2: While I see your point, I think that the forms with hyphens look better just because there is already a hyphen after the language code, so it looks more consistent (at least in the name of that template) to have hyphens overall. --kc_kennylau (talk) 11:10, 15 July 2022 (UTC)

@Benwing2: And working with Pali, we typically use templates such as pi-decl-noun, and even though we've started using {{pi-noun form}} instead of {{head|pi|noun form|tr=-}}, I still find myself wanting to type pi-noun-form. I think it's the mix of hyphens and spaces which make the form you prefer more complicated. While references have spaces and colons, at least colons are also disjunctive, whilst hyphens are generally used for joining. That's probably why hyphens for glottal stops (as in Thai names) don't feel natural. Additionally, a hyphen is a tighter join than space, and 'noun' joins more tightly with 'form' than with the language. --RichardW57m (talk) 12:56, 15 July 2022 (UTC)

Search result ordering?

Discussion moved from Wiktionary:Beer_parlour/2022/July#Search_result_ordering?.

When I search for ちいさ, the entry ちいさい only shows up at around the 400th result. Before that, there are lots of results that spuriously contain the hiraganas ち, い and さ somewhere in the article but mostly not concatenated. Is there something we (as in: Wiktionary, without modifying Mediawiki) can do about that? If the search query occurs 1:1 (especially in the title), that result should obviously be somewhere to the top. — Fytcha〈 T | L | C 〉 19:17, 10 July 2022 (UTC)

The search for "ちいさ intitle:/ちいさ/" yields a much shorter list (3). (Using "intitle" alone may timeout before generating any useful response.) DCDuring (talk) 20:40, 10 July 2022 (UTC)

Searching for intitle:"ちいさ" [2] (non-regex) would easier in that case but that doesn't really solve the problem: users should get results ordered in a sensible manner even if they're not familiar with CirrusSearch. — Fytcha〈 T | L | C 〉 20:52, 10 July 2022 (UTC)

I thought it was a problem for you. Users are not often considered explicitly, so I applaud your concern. It does seem like a Grease Pit issue. DCDuring (talk) 00:02, 11 July 2022 (UTC)

Also, a bare intitle search does not timeout, at least in this case. DCDuring (talk) 00:05, 11 July 2022 (UTC)

@DCDuring: Makes sense, I've moved the discussion here. Also, notice the difference between your intitle:/ちいさ/ and my intitle:"ちいさ": yours is using regex, mine is a plain text search. The plain text title search never times out.

In case this cannot be solved here locally on Wiktionary, maybe a phabricator ticket will have to be opened. This is a pretty big usability issue in my opinion and one that can rather easily be fixed so it's definitely worth it. — Fytcha〈 T | L | C 〉 00:13, 11 July 2022 (UTC)

I think the basic issue is that they haven't considered that users might want to navigate through the results. Their main focus seems to be on putting what they consider the most relevant stuff up front where you can find it right away. Alphabetical ordering makes it easier to find things, but chronological and "relevance" order is supposed to make it so you don't have to look. Yeah, right! Chuck Entz (talk) 00:30, 11 July 2022 (UTC)

That, in turn, is due to the likely interest of normal users, who probably want the answer on the first screen, preferably without scrolling. Questions that can't be addressed that way probably aren't normal-user questions. People who want that kind of thing are supposed to learn how to use CirrusSearch, I suppose. DCDuring (talk) 01:29, 11 July 2022 (UTC)

The Search team have historically been pretty responsive to Phabricator tickets. I filed one a few years ago and they even wrote a blog post about it! This, that and the other (talk) 05:40, 11 July 2022 (UTC)

For Wiktionary, a really useful simple search would just look at headwords, displaying all and only entry titles that contain the search string. That search could be prominently offered if the exact-term search failed and more than, say, 20 entries had been offered. DCDuring (talk) 11:53, 11 July 2022 (UTC)

• @Fytcha, the 小さい entry is the top result for me -- which is indeed the lemma entry, including the string ちいさ as part of the results summary. That part, at least, seems to be as desired.

Agreed that search for Japanese kana otherwise is quite bizarrely implemented -- when searching for ちいさ, I really don't want to see results for pages that incidentally include these kana just anywhere in any order, such as the third hit あさいち (asaichi), or fourth hit いさちる (isachiru), or even missing part of the search string entirely as in fifth hit ください (kudasai). ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:50, 26 July 2022 (UTC)

@Eirikr: Sorry for the long delay. I wasn't ignoring you, I was going to come back to this eventually once the time is right (which it is right now). I went ahead and opened a Phabricator ticket just now: https://phabricator.wikimedia.org/T317476 If there's anything you want to add to that, please do so. — Fytcha〈 T | L | C 〉 15:48, 10 September 2022 (UTC)

Pseudo-acronyms

The description of Category:English pseudo-acronyms as "groups of words that used to represent an acronym but no longer do" seems overly narrow. It covers HSBC or GLAAD, but not examples like BBQ and K9, which represent the same things now that they originally did, and were never "acronyms" to begin with, in the way we define that term ("an abbreviation formed by the initial letters of other words" or "an abbreviation formed by the beginning letters or syllables of other words (as Benelux)", but were instead always abbreviations of a singular word each. It seems like the category description should be expanded to cover things which look like acronyms but are not (regardless of whether they formerly were). - -sche (discuss) 22:10, 11 July 2022 (UTC)

Unable to create article “行车” in Chinese Wiktionary

When “行车” is searched in Chinese Wiktionary, it is redirected to “行車”. But they are two different words, so their article should be seperate.

Since there’s no grease pit in Chinese Wiktionary, I can only state my problem here. Beefwiki (talk) 15:16, 12 July 2022 (UTC)

Try https://zh.wiktionary.org/wiki/行车?redirect=no. On Wiktionary, when there's no entry for the lowercase equivalent to an uppercase term, the system will autoredirect you to the uppercase term if you try to go to the lowercase one. Apparently zhwikt does the same thing with simplified vs. traditional characters.

The usual method of getting around that here won't work there: in our version of Special:Search, the results page gives you a redlink if it doesn't find an exact match. but zh:Special:Search doesn't. I'm sure someone decided to configure it that way sometime in the history of the project. They probably have their own way that wouldn't work here, but that's just a guess. Chuck Entz (talk) 04:02, 13 July 2022 (UTC)

(I forgot the ping:@Beefwiki). The other workaround is edit another page on zhwikt to add a wikilink, but without saving/publishing the edit. When you preview it, you should get a redlink. Chuck Entz (talk) 04:16, 13 July 2022 (UTC)

@Chuck Entz I have succeeded by using the method you have mentioned. Thanks for your help. Beefwiki (talk) 10:30, 13 July 2022 (UTC)

French: Displaying forms like pensè in the conjugation table

J3133 (talk • contribs) has requested the inclusion of forms like "pensè-je", "fussè-je", "puissè-je", "dussè-je", "eussè-je", "pussè-je" (possibly without the "je") in the conjugation table of their respective verbs. I agree with this. Would Benwing (talk • contribs) or anyone else like to implement it? --kc_kennylau (talk) 10:20, 17 July 2022 (UTC)

@J3133, Kc kennylau, PUC I have honestly never seen forms like this in my life, even after years of studying French. So I am reluctant to add what are clearly rare forms to the conjugation table, as I think it will just confuse matters. On top of this, per User:PUC we standardize on pre-1990 forms, and pensè appears to be post-1990. Furthermore, while I don't know the ins and outs of these particular forms, I suspect that in practice they occur only with certain verbs. I would like to hear from PUC or some other native French speaker about the prevalence of these forms and their utility in being added to the conjugation table. Benwing2 (talk) 00:18, 19 July 2022 (UTC)

PUC was pinged twice in the previous discussion but did not reply. @Nicodene also agreed with adding these forms. J3133 (talk) 08:30, 19 July 2022 (UTC)

The pre-1990 thing can be addressed by just using the -é spelling. Agreed that the phenomenon may be limited to certain verbs, at least when it comes to the subjunctive. Nicodene (talk) 08:33, 19 July 2022 (UTC)

@Nicodene, J3133, Benwing2, Kc_kennylau: Sorry for the late reply. I guess this was mentioned elsewhere, but these are regular indicative or subjunctive forms with a euphonic /e/. In my experience their use is indeed restricted to certain verbs, mainly to verba opinandī (penser, opiner, trouver, estimer, etc., even though I can't readily find occurrences for the latter two) in the present indicative, and to the auxiliary verbs mentioned above conjugated in the subjonctif imparfait. Their use is formal (as is, by the way, the use of the subjonctif imparfait in general). dussé-je is perhaps the most common. As for the question of pre-1990 - in this case -é - vs. post-1990 - -è - spellings, I indeed tend to lemmatise to pre-1990 spellings in general and would prefer to do so here as well (if we add them to the conjugation tables, which I think would be reasonable for the few verbs mentioned, much less so for every verb), but this is a personal preference more than anything else. PUC – 15:50, 19 July 2022 (UTC)

@Benwing2: As there is consensus, will you add the forms? J3133 (talk) 12:24, 31 July 2022 (UTC)

@Benwing2: See Special:Diff/68538246—when you can, implement a better solution. J3133 (talk) 01:49, 5 August 2022 (UTC)

@Benwing2 Have you read much literature in French? In my experience, it's not rare, it's just that it's a mainly literary form (like passé composé, though with fewer applications). You'd sound super pretentious if you used it in speech or a news article, for instance. Andrew Sheedy (talk) 04:45, 11 August 2022 (UTC)

Broken Russian headword output

See искра (iskra). 98.170.164.88 00:40, 19 July 2022 (UTC)

@98.170.164.88: Fixed. --kc_kennylau (talk) 09:02, 19 July 2022 (UTC)

Template:derogatory

Needs documentation on how to specify the date parameter. For example, why does {{derogatory|July 16, 2022}} work on Dominicoon but {{derogatory|June 23, 2022}} yield an error on Americoon? 98.170.164.88 22:36, 20 July 2022 (UTC)

Never mind, it was an annoying invisible character. Maybe it came from copying the date from the page history. I have also added documentation to the template. 98.170.164.88 22:50, 20 July 2022 (UTC)

Apparently I'm not the only one to run into this error, as Brittletheories introduced such an invisible character here and here. Maybe the template should somehow filter this character out of its input. 98.170.164.88 23:56, 1 August 2022 (UTC)

"False positive" blue links

I've had a look through the archived discussions but this doesn't seem to have been touched on before. Has anyone any ideas for how to get around the problem of false positive blue links caused by the presence of interlingual homographs (i.e. words spelled the same in different languages)? I thought maybe that appending #Language to the URL might alleviate this problem but it doesn't seem to (probably as that link will still open the page). For example, over at Wiktionary:Frequency lists/Icelandic wordlist we find the blue link 'Daniel', pointing to to Daniel#Icelandic, however the Daniel article doesn't actually contain an Icelandic entry but only entries under several other languages. Red-link hunting of frequency lists is obviously quite an effective method of identifying high priority articles, especially on projects with far fewer resources than we have here. However, this limitation seems to really compromise the utility of such an approach, especially for Western European languages which often share a large common wordstock. Any ideas/solutions out there? Cheers Helrasincke (talk) 13:48, 22 July 2022 (UTC)

There is a "yellow link" gadget. I have the occasional problem with it where it loads a link as yellow when it should be blue, but others say that hasn't been a problem. Vininn126 (talk) 13:51, 22 July 2022 (UTC)

I find the OrangeLinks gadget in preferences to be indispensable. I haven't noticed any problems. DCDuring (talk) 17:00, 22 July 2022 (UTC)

It's not perfect, as you'll still get false positives with unrelated senses and so on, but it is a big improvement. Theknightwho (talk) 21:00, 22 July 2022 (UTC)

Hi all, thank you - this is fantastic! Unless I am mistaken though, this unfortunately doesn't seem to have been implemented globally - I can get the orange links neither with interwiki links (which it actually says it doesn't do anyway) nor on many international projects, e.g. at da.wiktionary, where it doesn't even show as an option in user preferences. That wiktionary in particular has very few active members, so a big reconfig on their end seems unlikely... unless this could/should be done with outside help?. Or is there a less intrusive way/workaround? Helrasincke (talk) 02:53, 23 July 2022 (UTC)

@Helrasincke, the only other "workaround" I can think of is so much work that it's hardly a workaround, per se -- you'd have to massively reorganize the dataset, so that each language has its own dedicated page, perhaps something like side/da and side/en for the Danish and English entries, so that the side page just transcludes the individual languages for display purposes. That way, language-specific links like side are to a specific language-dedicated page, not just to a particular spelling that might be shared by umpteen different languages (such as the so-memory-intensive-it's-a-problem page at [[a]]). If the side/da page doesn't exist, you get an immediate and obvious redlink.

This kind of idea has come up from time to time here, but what with the huge amount of effort involved in moving things around and retooling our various templates and other infrastructure, I don't imagine that this will gain any traction in the foreseeable future.  :) ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:38, 26 July 2022 (UTC)

Should this be enabled by default? 98.170.164.88 21:07, 28 July 2022 (UTC)

Yes please! Vininn126 (talk) 21:18, 28 July 2022 (UTC)

Yes, I think that would make sense. Helrasincke (talk) 08:20, 4 August 2022 (UTC)

Absolutely. I did not even know it existed until stumbling across this thread. It has been very useful to have. Nicodene (talk) 10:28, 4 August 2022 (UTC)

You could copy the gadget over to other Wiktionaries and use it on your own Special:MyPage/common.js, if those Wiktionaries link to individual language sections of pages. (If all their links are off the form [[foobar]], it won't help.) - -sche (discuss) 20:58, 28 July 2022 (UTC)

Inline Collocations Minor Request

Would it be possible to get a button saying "show more" after, say, 3 inline collocations? Vininn126 (talk) 07:55, 26 July 2022 (UTC)

Finally killing off {{trans-mid}}

Let's finally kill off {{trans-mid}}, just as envisaged at WT:RFDO#Template:trans-mid and WT:Grease pit/2022/January#Translation column width implementation.

Instead of obstinately dividing translation tables into two manually-balanced halves, we can use CSS columns to adapt the columns to the size of the user's screen. This will also make translation tables much more usable on mobile devices. See a test implementation at User:This, that and the other/subject.

There will be three column widths to choose from:

• {{trans-top|width=default}} or just {{trans-top}} (for all but the widest words)
• {{trans-top|width=wide}} (for at least Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu and pneumonoultramicroscopicsilicovolcanoconiosis)
• {{trans-top|width=narrow}} (for words with many short translations, like water/translations)

The implementation steps needed are:

1. To replace {{trans-top}} with User:This, that and the other/trans-top-css-columns
2. To replace {{trans-mid}} with a blank template
3. To replace the .user-testing--this-that-and-the-other block in MediaWiki:common.css with the contents of User:This, that and the other/new-trans.css (this needs someone with interface-admin rights)
4. To update the translation-adder gadget by removing the entire function TranslationBalancer (lines 1388-1537) and the two-line if (!this.balancer) statement (lines 890-891).

I'm not an admin (although I reckon I'd be useful if I were one...) so I can't do this by myself. I'm pinging some interface-admins who might be able to pitch in: @Ruakh, Erutuon, Benwing2, Fytcha. Any assistance is welcomed! This, that and the other (talk) 10:33, 26 July 2022 (UTC)

Piggy-backing and just going to mentioned there are many translations sections with translations WITHOUT a box, so if we make any sweeping changes, we should make sure to hit those. Vininn126 (talk) 13:33, 27 July 2022 (UTC)

After a big cleanup by @Fytcha, there are only 113 translation sections as of 7/20 without a box (down from 1458 on 7/1) so we can probably ignore those for now when making any sweeping changes. I have a bot I can run to remove {{trans-mid}} and do some minor cleanup of the translations sections when {{trans-mid}} is finally defunct. JeffDoozan (talk) 16:57, 27 July 2022 (UTC)

@JeffDoozan: I can do another AWB sweep a bit later today. I have my regexes saved. — Fytcha〈 T | L | C 〉 09:58, 6 August 2022 (UTC)

@JeffDoozan: The list should again have become significantly shorter now. Most of the remaining ones are translingual taxonomic entries (added by @DCDuring) that contain a link to an external website. — Fytcha〈 T | L | C 〉 01:57, 7 August 2022 (UTC)

When this process is finally done, I might get around to adding translation sections to taxonomic and English vernacular name entries. The translation sections to be added would contain links to various external sites that provide translations for taxa, like Avibase, Fishbase, and GRIN. Should I enclose the link(s) in a special template to facilitate distinguishing such Translingual L2 sections from others with our own custom-rolled translation sections? I don't see much value in such a distinction now, but can someone see any value in it? DCDuring (talk) 18:59, 7 August 2022 (UTC)

@DCDuring I think a template would assist. It would help to (a) make sure the format is standardised across entries and (b) present a nicely formatted link to Special:WhatLinksHere rather than a raw link containing the special page name. Other than that, it doesn't need to look any different than it does now. This, that and the other (talk) 05:57, 9 August 2022 (UTC)

Sorry — I took a look a few months ago, and the implementation steps seemed wrong to me (they seemed to be in the wrong order, given that template changes take effect almost immediately whereas CSS changes can take a while), which led me to start diving into the details, but I didn't manage to make sense of all of them, so I ended up not taking any action just then. I'll try to make time within the next week or so to take another look, unless someone beats me to it. :-)   —Ruakh_TALK 05:42, 1 August 2022 (UTC)

If anyone is wondering: the implementation steps turned out to be in an OK order, because the changes to {{trans-top}} were mostly compatible with both the existing CSS (left over from This, that and the other (talk • contribs)'s original testing) and with the new CSS. It's not 100% perfect — with the existing CSS the columns are a bit wider than desired, and this approach required putting the user-testing--this-that-and-the-other bit in the actual template (for now) — but it's good enough. —Ruakh_TALK 02:11, 15 August 2022 (UTC)

@Ruakh Thanks so much for this! This is very exciting. It will make the experience much better for mobile users - and those who add translations, who no longer need to muck around with balancing! This, that and the other (talk) 02:24, 15 August 2022 (UTC)

OK, I've applied your changes now. Sorry that took so long, and thanks for your patience! (And, thanks again for your work on this!) —Ruakh_TALK 02:07, 15 August 2022 (UTC)

Hi. Thanks all for the work but it seems imperfect ATM. The alphabetic order is partially gone (e.g. culture#Translations and the split gradually disappears on zooming in. I am using Chrome on Windows. --Anatoli T. ^{(обсудить}/^вклад) 03:40, 15 August 2022 (UTC)

The split completely disappears on 200% zoom (the alphabetic order seems okay without the split). --Anatoli T. ^{(обсудить}/^вклад) 03:42, 15 August 2022 (UTC)

@This, that and the other: yes, I'm afraid the columns don't work for me either (see withdraw) – now all the translations appear in a single column, with an empty space on the right side. I am using the latest version of Mozilla Firefox at a 133% zoom. — Sgconlaw (talk) 18:22, 15 August 2022 (UTC)

What I'm seeing now is one-column layout if there is a long translation line in one or more languages for a given translation box, two-column if all of the translation lines are "short". DCDuring (talk) 18:57, 15 August 2022 (UTC)

@Ruakh, This, that and the other: oh, and for me changing the browser zoom (whether less than or greater than 100%) makes no difference at all. The translations only appear in the left column, and the right column is blank. — Sgconlaw (talk) 19:01, 15 August 2022 (UTC)

Citations: Accusations of Harmfulness to a Citation

My citation was from the Merriam-Webster's Unabridged Dictionary, I was trying to add a citation for "Otukian", a very unknown word meaning relating to any language family of the Brazilian tribe Bororo. The citation was " “Otukian.” Merriam-Webster's Unabridged Dictionary, Merriam-Webster, https://unabridged.merriam-webster.com/unabridged/Otukian. Accessed 27 Jul. 2022. " What should I do? Allan Polatcan (talk) 15:25, 27 July 2022 (UTC)

@Allan Polatcan: There are some filters in place meant to catch spammers, it looks like your attempted edit was flagged as possible spam. After a few days and a few edits you will be exempted from the filter, but until then I can add the reference if you would like. - TheDaveRoss 12:27, 28 July 2022 (UTC)

thx Allan Polatcan (talk) 17:18, 28 July 2022 (UTC)

Category:English female given names from constructed languages

The boilerplate reads "English female given names of constructed languages origin." For most languages, subbing in the name like this would work, but in this case it's awkward; can we tweak the template/module to produce something better in this case, like it produces at Category:English terms derived from constructed languages? - -sche (discuss) 18:35, 27 July 2022 (UTC)

This is a problem with all the subcategories for Category:English given names. Category:English given names from Austronesian languages, for instance, has a description saying "English given names of Austronesian languages origin." Binarystep (talk) 11:25, 31 July 2022 (UTC)

Sandboxes in CAT:E

There are a couple of pages in CAT:E because @Benwing2 got rid of a module required by Module:la-pronunc/sandbox. You would think that sandboxes and their subpages would categorize in Category:Pages with module errors/hidden instead of CAT:E, but apparently this is surprisingly difficult.

The relevant code at MediaWiki:Scribunto-common-error-category is limited to the native parser functions and magic words that are available to templates, and as far as I can tell, the variability of where the "sandbox" part is within the {{PAGENAME}} would require a massive set of nested {{#ifeq:}}s and {{#titleparts:}} to cover everything: {{SUBPAGENAME}}, {{ROOTPAGENAME}}, and {{#titleparts:|1|-1}} catch the most obvious variations, but people tack sandboxes onto all kinds of things, and they can have multiple layers of subpages. Of course, we would also have to filter for just the Wiktionary, Template and Module namespaces- if there's a module error at the entry for sandbox, we would want to know about it. Chuck Entz (talk) 03:44, 31 July 2022 (UTC)

Of course I'm not exactly an expert, so I'm hoping someone else can figure out a way that I've missed to keep sandboxes and their subpages out of CAT:E. Also pinging @Erutuon, who knows way more than I do about this. Chuck Entz (talk) 03:44, 31 July 2022 (UTC)

@Chuck Entz IMO the solution is simply to not have sandboxes in the main namespace. I create all my sandbox modules under Module:User:Benwing2/... and templates under User:Benwing2/..., and errors in either are automatically hidden. Having sandboxes under .../sandbox is inherently problematic because it allows for only one such sandbox, shared among all users. I propose simply deleting all mainspace sandboxes. Benwing2 (talk) 03:48, 31 July 2022 (UTC)

@Benwing2: When you say "the main namespace", you don't literally mean the main namespace (Namespace 0), right? Chuck Entz (talk) 04:23, 31 July 2022 (UTC)

@Chuck Entz I do mean Namespace 0, yes. For example, Module:la-verb/sandbox is recently the work of User:Theknightwho. Instead of using Module:la-verb/sandbox, they should put their code in Module:User:Theknightwho/la-verb. Benwing2 (talk) 04:28, 31 July 2022 (UTC)

(None of the aforementioned pages are actually in MediaWiki namespace 0 in the sense Chuck Entz meant, but I think your intention is clear now.) 98.170.164.88 04:36, 31 July 2022 (UTC)

Blah, you are right, I mean from production module/template space. Benwing2 (talk) 05:50, 31 July 2022 (UTC)

I went ahead and moved the offending sandbox modules to User:Theknightwho and User:Erutuon's user space. Benwing2 (talk) 17:17, 31 July 2022 (UTC)

On a side note, should we exclude Module:zh-dial-syn/check-presence too? It seems to always be in there. I guess its presence doesn't really hurt though. 98.170.164.88 03:58, 31 July 2022 (UTC)

That's an intermittent issue that depends on the vagaries of how much processor time it takes to access the wikitext for a whole bunch of entries. 9 times out of 10 it clears with a null edit. I go back and forth as to whether it's a brilliant idea or a boneheaded kludge that's just asking for trouble- I suspect it's both... — This unsigned comment was added by Chuck Entz (talk • contribs) at 04:17, 31 July 2022 (UTC).

Unsupported titles displaying incorrectly

The pages for [citation needed], :{, f##k, f##ked, f##king, f##ks, S:t Michel, and ﴾ ﴿ all display incorrect text as the title. The only thing these pages appear to have in common is that they were created in 2020 or later.

Additionally, Template:unsupported can't be used to link to f##k, f##ked, f##king, f##ks, eq #, hr #, or о./, since they all contain both lowercase letters and symbols that can't be used anywhere in the URL. It would be useful if there were a way to disable the template's automatic capitalization, as that would fix the issue entirely. Binarystep (talk) 11:22, 31 July 2022 (UTC)

Is the issue that people forgot to add them to MediaWiki:UnsupportedTitles.js or does it go beyond that? - -sche (discuss) 05:48, 2 August 2022 (UTC)

I'd assume so, but I can't edit that page, so... Binarystep (talk) 11:21, 2 August 2022 (UTC)

Ok, I've added the pages mentioned in your first paragraph to that .js, which has indeed fixed the display issue. I don't have time to investigate the linking issue, I'm sorry, so I leave that for someone else. - -sche (discuss) 05:40, 5 August 2022 (UTC)