Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:GP)
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and thesaurus and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, Toolforge, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of “all words in all languages”.

Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.

Grease pit archives edit

July 2022

My new page just keeps showing as harmful[edit]

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 (talkcontribs) at 00:11, 2 July 2022 (UTC).Reply[reply]

@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)Reply[reply]

Error in translation lists[edit]

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)Reply[reply]

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? 23:11, 2 July 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Yep, I tried it myself, this is it. Guess I never used that feature before. Seems pretty nice. 07:24, 4 July 2022 (UTC)Reply[reply]

Accelerated creation of French feminine equivalents of nouns[edit]

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)Reply[reply]

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

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

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

Template not transcluded?[edit]

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)Reply[reply]

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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]

Stellar Wiktionary creation[edit]

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 (talkcontribs) at 06:35, 7 July 2022 (UTC).Reply[reply]

What makes you think whatever you tried to add is suitable for a dictionary? — SURJECTION / T / C / L / 07:57, 7 July 2022 (UTC)Reply[reply]
Because the filter is doing its job - don't make it. Vininn126 (talk) 09:21, 7 July 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Hebrew noun pos is unrecognized pos?[edit]

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)Reply[reply]

I seem to have fixed it by removing a space. --kc_kennylau (talk) 00:45, 10 July 2022 (UTC)Reply[reply]
@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)Reply[reply]
@Chuck Entz I hope I fixed it. --kc_kennylau (talk) 18:04, 10 July 2022 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]

Search result ordering?[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Also, a bare intitle search does not timeout, at least in this case. DCDuring (talk) 00:05, 11 July 2022 (UTC)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
  • @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)Reply[reply]


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)Reply[reply]

Unable to create article “行车” in Chinese Wiktionary[edit]

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)Reply[reply]

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)Reply[reply]
(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)Reply[reply]
@Chuck Entz I have succeeded by using the method you have mentioned. Thanks for your help. Beefwiki (talk) 10:30, 13 July 2022 (UTC)Reply[reply]

French: Displaying forms like pensè in the conjugation table[edit]

J3133 (talkcontribs) 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 (talkcontribs) or anyone else like to implement it? --kc_kennylau (talk) 10:20, 17 July 2022 (UTC)Reply[reply]

@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@Benwing2: As there is consensus, will you add the forms? J3133 (talk) 12:24, 31 July 2022 (UTC)Reply[reply]
@Benwing2: See Special:Diff/68538246—when you can, implement a better solution. J3133 (talk) 01:49, 5 August 2022 (UTC)Reply[reply]
@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)Reply[reply]

Broken Russian headword output[edit]

See искра (iskra). 00:40, 19 July 2022 (UTC)Reply[reply]

@ Fixed. --kc_kennylau (talk) 09:02, 19 July 2022 (UTC)Reply[reply]


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? 22:36, 20 July 2022 (UTC)Reply[reply]

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. 22:50, 20 July 2022 (UTC)Reply[reply]
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. 23:56, 1 August 2022 (UTC)Reply[reply]

"False positive" blue links[edit]

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)Reply[reply]

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)Reply[reply]
I find the OrangeLinks gadget in preferences to be indispensable. I haven't noticed any problems. DCDuring (talk) 17:00, 22 July 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
Should this be enabled by default? 21:07, 28 July 2022 (UTC)Reply[reply]
Yes please! Vininn126 (talk) 21:18, 28 July 2022 (UTC)Reply[reply]
Yes, I think that would make sense. Helrasincke (talk) 08:20, 4 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Inline Collocations Minor Request[edit]

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

Finally killing off {{trans-mid}}[edit]

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:

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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. :-)   —RuakhTALK 05:42, 1 August 2022 (UTC)Reply[reply]
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 (talkcontribs)'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. —RuakhTALK 02:11, 15 August 2022 (UTC)Reply[reply]
@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)Reply[reply]
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!) —RuakhTALK 02:07, 15 August 2022 (UTC)Reply[reply]
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)Reply[reply]
The split completely disappears on 200% zoom (the alphabetic order seems okay without the split). --Anatoli T. (обсудить/вклад) 03:42, 15 August 2022 (UTC)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]

Citations: Accusations of Harmfulness to a Citation[edit]

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)Reply[reply]

@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)Reply[reply]
thx Allan Polatcan (talk) 17:18, 28 July 2022 (UTC)Reply[reply]

Category:English female given names from constructed languages[edit]

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)Reply[reply]

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)Reply[reply]

Sandboxes in CAT:E[edit]

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)Reply[reply]

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)Reply[reply]

@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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
(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.) 04:36, 31 July 2022 (UTC)Reply[reply]
Blah, you are right, I mean from production module/template space. Benwing2 (talk) 05:50, 31 July 2022 (UTC)Reply[reply]
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)Reply[reply]
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. 03:58, 31 July 2022 (UTC)Reply[reply]
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 (talkcontribs) at 04:17, 31 July 2022 (UTC).Reply[reply]

Unsupported titles displaying incorrectly[edit]

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)Reply[reply]

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)Reply[reply]
I'd assume so, but I can't edit that page, so... Binarystep (talk) 11:21, 2 August 2022 (UTC)Reply[reply]
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)Reply[reply]

August 2022

Automatic redirects when on an uncreated page[edit]

I was on this page after deleting it because I wanted to protect it when I was suddenly automatically redirected to wastage. Is there a way to disable this behavior? Automatic redirects are among the most annoying things on the internet. — Fytcha T | L | C 〉 10:07, 6 August 2022 (UTC)Reply[reply]

@Fytcha I don't know how to disable it, but adding &redirect=no to the url will prevent it while you're on that page. This is added automatically to redlinks, so clicking on any of the self-redlinks on that page or in the "redirected from" message will take you to a stable version. Chuck Entz (talk) 15:45, 6 August 2022 (UTC)Reply[reply]
Do we have a way of telling how many pageviews nonexistent pages get? I would expect that because other wikis are not case-sensitive, noobs end up on uppercase pages and are helped by the redirects, probably more often than adept editors like us are annoyed by them (and we know to look for and click the small link at the top of the page we're redirected to, to go back to the page we want, whereas a noob may not read the wall of text and see to go to the other page, and/or may create an entry at the capitalized page). But it'd be useful to have data. Perhaps someone could make an opt-in gadget to automatically add &redirect=no to URLs, for users who want to never be redirected? - -sche (discuss) 19:41, 6 August 2022 (UTC)Reply[reply]
There used to be preference for disabling automatic redirection, and if someone even mildly capable with JavaScript wanted to re-make that preference as a Gadget that would be welcome. I think it is literally just appending the string Chuck mentioned above to applicable links. - TheDaveRoss 13:02, 8 August 2022 (UTC)Reply[reply]
The redirect from Wastage to wastage is the "did you mean" redirect and it's handled by MediaWiki:Common.js. It's supposed to be possible to disable it by going to WT:PREFS and checking "Disable the javascript redirect between pages that differ only in case", but saving preferences on that page doesn't seem to work any longer. You can disable it with window.disableAutoRedirect = true; in your common.js instead. — Eru·tuon 21:50, 8 August 2022 (UTC)Reply[reply]
Thanks all, the JS solution works for me. — Fytcha T | L | C 〉 13:02, 9 August 2022 (UTC)Reply[reply]
@Erutuon: Speaking of WT:PREFS, I wonder if it is time to finally kill that page off. Is anyone still using them? If so, what features, and can those be moved to gadgets? - TheDaveRoss 13:34, 9 August 2022 (UTC)Reply[reply]

Bot request[edit]

I see 2547 Italian adjective forms using {{head|it|adjective form|}} and a 4th parameter used for gender but not starting with g=. The output looks weird and is inconsistent. Can someone add g= to any of these whose 4th parameter is a gender? Some also use e.g. |f|p}} and need to be corrected. Ultimateria (talk) 19:30, 6 August 2022 (UTC)Reply[reply]

Relevant search. 19:33, 6 August 2022 (UTC)Reply[reply]
@Benwing2 this was as the result of WingerBot's important (but evidently, in this case, flawed) work. This, that and the other (talk) 05:16, 8 August 2022 (UTC)Reply[reply]
@Ultimateria, This, that and the other In the process of fixing. Benwing2 (talk) 05:49, 8 August 2022 (UTC)Reply[reply]

Module:number list/data/en creates bad red links[edit]

e.g. the red link "five times" (sum of parts) appears at quintary. Can this be changed to not be a link please? Equinox 17:23, 7 August 2022 (UTC)Reply[reply]

@Equinox Fixed to use separate per-word links. Benwing2 (talk) 05:49, 8 August 2022 (UTC)Reply[reply]

Common Turkic declension[edit]

What I was doing was a template for the declension of Common Turkic words. When trying to publish, it says the page is harmful. What is happening? Is there a mistake on the template? 18:45, 7 August 2022 (UTC)Reply[reply]

Sound file question[edit]


How could I download sound files with English pronunciation?

I need it to build my own Anki database.

For example

There is a word 'car' with section 'pronunctiation'


It has 2 audio files

  • (file)
  • (file)

How can I build URL to download these these files?

Cheers GT Gt4dev (talk) 14:56, 8 August 2022 (UTC)Reply[reply]

You can find out more about the files, including the locations and URLs for downloading on the Commons description pages (e.g. https://commons.wikimedia.org/wiki/File:En-uk-a_car.ogg). - TheDaveRoss 15:34, 8 August 2022 (UTC)Reply[reply]

"Latina" (at "In other languages") vs. Latine[edit]

Like Wiktionary talk:Main Page#Čeština vs. český, compare Latinus#Usage notes. --Ufila (talk) 17:35, 8 August 2022 (UTC)Reply[reply]

Italics as alt in Greek[edit]

Problems for alternative output (bold or italics) for latin & other scripts (e.g. especially for greek) in various link-templates. Main problem: cannot write italics as in an alt= param.
@Benwing2 tells me, it has to do with sc (script) or languages like greek Grek and CSS here. Notifying @Erutuon
Control examples:

  • {l en / el {{l|en|word}} word {{l|el|λέξη}} λέξη (léxi) & grc λέξις (léxis)
  • {m en / el {{m|en|word}} word {{m|el|λέξη}} λέξη (léxi) & grc λέξις (léxis)
  • {w {{w|word}} word {{w|lang=el|λέξη}} λέξη
  • {head} oops _??1 why 2nd param required? {{head|en|head=word}} Lua error in Module:headword/templates at line 52: The parameter "2" is required.
    OK we can write 'PAGENAME', but perhaps we only need a gender {f} of something
    Or, a param |pos=-
    {head en / el (default bold, but not for other scripts?) {{head|en|head=word|noun}} word {{head|el|head=λέξη|noun}} λέξη (léxi)

Trying bold (I now observe at the examples, that fonts for greek are weird and have a very faded bold or no bold. _??2 Why special fonts for el Modern Greek? (ok, some other fonts for Ancient grc, but even there, bold has to be balanced)
_??3 Here, the transliterations are bold (I think they should not), but not the word - or is it some faded bold? I cannot tell. I presume that for some elaborate calligrpaphic scripts bold has to be changed a little bit, but GRek has no such problems).

  • {l en / el {{l|en|word|'''word'''}} word {{l|el|λέξη|'''λέξη'''}} λέξη (léxi) & grc λέξις (léxis) Try russian слово (slovo)
  • {m en / el {{m|en|word|'''word'''}} word {{m|el|λέξη|'''λέξη'''}} λέξη (léxi)
  • {w {{w|word|'''word'''}} word {{w|lang=el|λέξη|'''λέξη'''}} λέξη Here greek font & bold is correct.
  • try to unbold {{head|en|head='''word'''|noun}} word {{head|el|head='''λέξη'''|noun}} λέξη (léxi) Trying russian слово (slovo)

_??4 Trying italics For taxonomic species and genera we need italics (A side-problem: Please note, that apart from the transligual NewLatin terms, there are equivalent academic terms in other languages; Latin is not universal. {{taxon}} does not provide lang=. But never mind.)

  • by they way _??5 what is the template like {{title|italics}} Example at Homo sapiens
  • {l en / el {{l|en|word|''word''}} word {{l|el|λέξη|''λέξη''}} λέξη (léxi) Try russian слово (slovo)
  • {m en / el {{m|en|word|''word''}} word, not needed here, {{m|el|λέξη|''λέξη''}} λέξη (léxi)
  • {w {{w|word|''word''}} word {{w|lang=el|λέξη|''λέξη''}} λέξη
  • {head or alt=? {{head|en|head=''word''|noun}} word {{head|el|head=''λέξη''|noun}} λέξη (léxi)
    This is an extraordinary attempt by my administrator @Saltmarsh to help write italics at HEAD with
    ''''Κίτροι'''''{{head|el|proper noun form|g=f|head= |tr=Kítroi}}

It would be very nice, if all things were unified for all languages, and it would feel very comfortable for editors-not-so-able like myself, to know and trust that every time we use |alt= (hopefully also available along the positional parameter) we get the result we need at whatever Template. Thank you, and thank you Benwing2, for your effort to unify hundreds of templates, thanks.
PS, Benwing, could {l} and {m} give the name of the Languages like {{cog}} does? with some extra parameter? Something like {l|el|λέξη|lang=1} meaning showlanguage. It would be very handy at etymologies when we mention some word. ‑‑Sarri.greek  I 14:12, 9 August 2022 (UTC)Reply[reply]

@Erutuon The issue here is that there's CSS in MediaWiki:Common.css to disable italics and bold for Greek text wrapped in class=Grek; similarly for Russian and other languages. Do you know why this is there? If not, I will remove it. Benwing2 (talk) 02:44, 10 August 2022 (UTC)Reply[reply]
@Sarri.greek Check out {{m+}}, this does exactly what you are looking for in terms of something that works like {{m}} but includes the language name. Benwing2 (talk) 04:45, 10 August 2022 (UTC)Reply[reply]
It's because {{m}} uses <i> and we don't want it to italicize non-Latin scripts because they are already distinguished from English by not being in Latin script. '' also becomes <i>, so both end up not being italic. — Eru·tuon 05:56, 10 August 2022 (UTC)Reply[reply]
Thank you @Erutuon, Trying {{m+|el|λέξη}} Greek λέξη (léxi). {{m+|el|λέξη|''λέξη''}} Greek λέξη (léxi). Yok.
Why distinguish a script from English in matters of style? What is the wrong with the Grek script? or the Cyrillic? They are very normal scripts. They are not ideographic or something. ... I do not see why the discrimination. I do not know how many scripts are affected here.
If not possible, then, why not extract el from Gek script, Orrrrr add a script = Default and put us under there. Orrr, make a thing that says: #if el, then script = blah. Thank you. ‑‑Sarri.greek  I 10:59, 10 August 2022 (UTC)Reply[reply]
PS which is what we do at el.wikt for arabic etc., because we do NOT have scripts, or an interface administrator, we cannot change CSS, so we do all kinds of manoeuvres at Modules for {links} ‑‑Sarri.greek  I 11:01, 10 August 2022 (UTC)Reply[reply]
The matter here, is not what to call scripts linguistically (Grek, Cyrili etc). CSS does not care about that. But as fonts. So, wikt can call Xscripts the ones that need handling ? ‑‑Sarri.greek  I 11:18, 10 August 2022 (UTC)Reply[reply]
@Sarri.greek: yes, if you use {{head}} without a POS parameter, you'll get a module error. This is like flushing large objects down the toilet to show the mess that results. Would you be so kind as to fix it so we don't have this page in CAT:E for eternity? Chuck Entz (talk) 15:25, 10 August 2022 (UTC)Reply[reply]
@Erutuon Why don't we want <i> to italicize Greek? The logic here seems a bit strange. Benwing2 (talk) 01:45, 11 August 2022 (UTC)Reply[reply]
@Benwing2: To expand on what I said above, when mentioning Greek in English, we don't italicize because it's distinguished by script already. It's a Wikipedia convention as well (w:MOS:BADITALICS). Not sure if it's a convention in books. For Cyrillic, it actually makes the script hard to read for people who are only or mostly familiar with un-italicized Cyrillic (which includes me) because some letters dramatically change their shape when they are italicized (т becoming т for instance). I'm not familiar with the other uses of italics in Greek that User:sarri.greek is mentioning above, though. Maybe there is some way to accommodate them. — Eru·tuon 02:36, 11 August 2022 (UTC)Reply[reply]
@Erutuon I agree with you about Cyrillic; I also find italicized Cyrillic hard to read. But italicized Greek looks much like non-italicized Greek and if the community of regular editors in Greek prefers to allow italicized Greek, I'm not sure why we should prevent it. Benwing2 (talk) 02:39, 11 August 2022 (UTC)Reply[reply]
@Erutuon Likewise we are currently preventing bold Greek; not sure why. Benwing2 (talk) 02:40, 11 August 2022 (UTC)Reply[reply]
I should also add, the apparent point of the idea that foreign scripts are "sufficient unto themselves" in being distinguished presupposes that everything is normally written in Latin script. For Wikipedia this may make sense because all the articles are in English and text in foreign scripts is only found when interspersed in English text; but in Wiktionary this makes a lot less sense when all terms are written in their native scripts and may not be found near English text. Benwing2 (talk) 02:53, 11 August 2022 (UTC)Reply[reply]
I had always understood that the reason for italicising Latin-script words in this dictionary is to clearly distinguish mentions from uses. But because the dictionary is written in English, there should be no uses of non-Latin-script terms - they are all mentions. Therefore italic text in other scripts should, in theory, never be required. @Sarri.greek you say "It would be very handy at etymologies when we mention some word" - but the etymology is written in English, so I'm not sure if I understand the problem. Does the use of non-italic text in this situation look odd to a native Greek speaker? If you can explain (and demonstrate) more clearly what you're trying to do, it might be easier to imagine how to solve the problem. This, that and the other (talk) 09:45, 11 August 2022 (UTC)Reply[reply]
@This, that and the other:, this 'showing' was for 'showing names of languages', an extra-request. E.g. {{l|nl|xxx|lang=1}} coudld give: Dutch xxx.
Thank you @Benwing2, Erutuon, So, what i gather is that italicised is an option decided by the editor (easytype{{m}} exclusively for english editors), But all templates should have an option alt= in which all kinds of styles should be allowed, bold or italics if the editor chooses..
Most importantly, the transcriptions are affected (they become italics, or bold too; I think they should remain steady)?
Russians never write with italics? I didn't know that. Have we asked someone? OK. Then, a russian editor, would never choose to alt=xxx. Unless he is writing a toxonomic genus, there, he needs to italicise. It should be available.
As for bad outputs in certain scripts, e.g. also in Greek two ττ look like π. I would love if a hairspace was added between ττ. But it is something we live with, in greek internet, everybody knows what to read. Thank you ‑‑Sarri.greek  I 11:18, 11 August 2022 (UTC)Reply[reply]
PS, some thoughts while reading w:Use–mention distinction... The reason for electornic texts not using quotation marks as printed texts do, is when they are linked, and because they are blue already. What if they are not linked? The rules should apply there too, linked or no linked for the sake of uniformity.
So, a different marking was needed in electronic texts, and italics was chosen as a solution instead of quotation marks (because a text would look bad with quotations all over the place)? (in el.wikt we use quotation marks blah blah «mentionedword», or nothing: blah blah: mentionedword. If in English text, blah blah "mentionedword")
Two practices: A) when the mentioned.term is within a same.language.text. and B) when the mentioned.term does not belong to the language of the text. Further issue for A and for B: When the mentioned.word belongs to a different language but with similar script. And a 3rd issue for A and B, when it belongs to a non.greek.latin.cyrillic script like arabic, Han characters etc. Then, the native tradition sould be consulted. ‑‑Sarri.greek  I 11:56, 11 August 2022 (UTC)Reply[reply]
Hah, yes I see you were talking about language names, not italics, when you wrote the sentence about it being "very handy in etymologies". Sorry for the confusion!
Anyway, what I was trying to say is, let's see an example so that we can focus our thinking. I can see that not even {{quote}} allows italic Greek text, which is a problem if a book/journal quotation happens to contain an italic word. But can you provide an example of a scenario where it will be important to see {{m}} displaying a Greek word in italics? This, that and the other (talk) 13:51, 11 August 2022 (UTC)Reply[reply]
Maybe we can avoid changing the Greek-mentioned-in-English-text rule, but still accommodate italicization in quotations and taxonomic names with CSS rules? That is, make Greek italicized in cases where we should be following Greek style and not mentioned word style. It might be as simple as editing the CSS so that it only turns off Greek italicization when the class=mention is present along with class=Grek. That would target {{m}} (and other templates that use the same module code to format words, like {{der}}), but not '' or other cases of <i>. — Eru·tuon 22:11, 11 August 2022 (UTC)Reply[reply]
@Erutuon Seems reasonable to me. Italics should work in {{head}} as well. Benwing2 (talk) 06:55, 12 August 2022 (UTC)Reply[reply]
Regarding the .Grek font (Modern Greek), I'm not sure why we would want any special fonts (font families). Modern Greek is well supported by mainstream fonts. Ancient Greek (.polytonic) is the one that is best in New Athena Unicode so that the length-breathing-accent vowel letters (ᾱ̓́) are rendered correctly. Those combinations of diacritics probably aren't ever used in Modern Greek text on Wiktionary, even in polytonic orthography. If this is correct, I will change the CSS for that and if it causes any problems for individual languages, they can be switched to the polytonic script code. — Eru·tuon 22:34, 12 August 2022 (UTC)Reply[reply]
Okay, I made it so that Greek italics are only disabled at the top level of {{m}} and such (diff). In any other location, Greek should be able to be italicized. I'm not positive this is correct in all cases, so please describe any odd effects here. — Eru·tuon 22:47, 12 August 2022 (UTC)Reply[reply]

Small bot jobs[edit]

Would a bot owner be so kind as to perform a few bot jobs on Polish entries?

  1. I regret naming {{R:pl:SJPSBL}} that and would like to change it to {{R:pl:SJP1807}}, and we would need to change all instances of that on pages to the second template.
  2. Many pages have many instances of {{col3}}; this is because we separate them by part of speech. could we organize them by title alphabetically? So adjectives, then adverbs, etc. (there are also tons of pages where all the parts of speech are crammed into 1 col3, and I'd like to get those separated off, but that's most likely an issue for another day.)
  3. Could we standardize usage of {{wp}} on Polish pages so that if there is a pedia link, it's {{wp|lang=pl}} (plus any other parameters) and under the L2? Some are under further reading, but the vast majority are under the L2, and it would be nice to have that uniform. Vininn126 (talk) 09:18, 11 August 2022 (UTC)Reply[reply]
@Vininn126 First one is done. Benwing2 (talk) 03:42, 12 August 2022 (UTC)Reply[reply]
@Vininn126 Second one is running, with 8,791 pages to change. Note also, my script issued 4,406 warnings on {{col3|pl}} invocations without a title, probably too many to fix by hand. Benwing2 (talk) 06:42, 12 August 2022 (UTC)Reply[reply]
@Benwing2 Thanks for #1. As to #2 - yeah there are a lot. The only way I could see fixing it by bot is by having a bot check the POS of each word within the title, then creating a separate col3 for it. Vininn126 (talk) 08:39, 12 August 2022 (UTC)Reply[reply]

Quiet Quentin puts invalid language codes[edit]

As I noted in January, the Quiet Quentin gadget sometimes uses invalid (or incorrect) language codes, most recently pt-BR here. I assume it gets the codes from the Google Books metadata, so it'd probably be difficult to fix cases where the language is wrong (French mislabelled "en", etc), but it should be easier to fix the issue of invalid codes: where the language code fetched from Google is "pt-BR", always output "pt" instead, always replace "un" with "und", and probably we can find the full list of codes Google uses and identify others to replace. - -sche (discuss) 05:01, 12 August 2022 (UTC)Reply[reply]

T:en-plural noun with two singulars?[edit]

An IP has requested a sg2= (or whatever it should be called) parameter in T:en-plural noun for tranx (tranquilizers). But possibly it's better to either view trank and tranq as words for "tranquilizer" that are separate from (and not 'forms of') tranx (given the difference in spelling), or conversely to redefine tranx as a simple plural of one or both of those. - -sche (discuss) 21:03, 13 August 2022 (UTC)Reply[reply]

I added a |sg2= parameter if you (or the IP) want to use it. This, that and the other (talk) 12:18, 14 August 2022 (UTC)Reply[reply]

Preventing emoji display in titles[edit]

Since we generally do not want entries for emojis, is there a way of preventing emoji display for Unicode characters that have dual identity? The variation selector U+FE0E will force text display, for characters such as , and the signs of the zodiac, that may display as either text or emoji depending on which fonts the user has installed, or which OS they're using. DISPLAYTITLE doesn't seem to work with this though because it doesn't recognize the text variant as being the same character. kwami (talk) 03:52, 14 August 2022 (UTC)Reply[reply]

If we want to do this (I say if because we do have several entries for emojis), would it work to use the same method as in MediaWiki:UnsupportedTitles.js? Some tweaking might be needed, as I think it currently expects the pages it's changing to be subpages of Unsupported titles, whereas these could be at "regular" main-namespace locations, but it seems like it ought to work. - -sche (discuss) 05:36, 14 August 2022 (UTC)Reply[reply]
@-sche I think that should work just fine. For readers who see the characters in their text forms anyway, they wouldn't even notice the difference.
It would be most convenient if this were enabled as a stand-alone option, so we don't need to make a protected-edit request every time we notice a problem in an article title. But I imagine it should be functional to add a line to the js for e.g. '♉': '♉&#xFE0E;',.
I'm not opposed to articles for emojis that are notable in themselves. I'm thinking of articles that are intended to be text, but whose titles will display as emojis for some readers. For example, ♀︎ and ♂︎ have been used for centuries as text characters. That's the basic form. The emoji variants ♀️ and ♂️ are very recent and I've never seen them used in a biology or astronomy text. I think it's good to have the emojibox showing the two variants, but the reason for the articles is the original text characters.
For me, ♀︎ and ♂︎ display as text, so the emoji problem is not something I'm generally aware of. But the zodiac symbols do display as emojis on my system, e.g. ♉️ instead of ♉︎, and the majority of the time they shouldn't. The Wiktionary articles are not about these characters as emojis, but about their occurrence in the lit, which is almost entirely in their text form. kwami (talk) 21:23, 15 August 2022 (UTC)Reply[reply]
I don't think it can (or should) be un-protected, I think all MediaWiki: pages and especially .js pages are inherently restricted to being edited by admins or interface admins because the potential for vandalism is too vast.
As a test, I added '♉': '♉︎', but as I suspected it only works on Unsupported_titles/♉; someone with slightly more time than me will need to add a little code to let the script change the titles of main namespace pages and not just subpages of Unsupported titles, but I've given proof of concept. - -sche (discuss) 22:02, 15 August 2022 (UTC)Reply[reply]
Oh, I agree that the js probably shouldn't be unprotected. That's why I think that a stand-alone version would be best.
I created the page Unsupported_titles/♉ and it does indeed work with your addition to the js list. kwami (talk) 02:22, 16 August 2022 (UTC)Reply[reply]

Translation tables are gone haywire[edit]

{{trans-mid}} is no longer splitting the table in two. Anatoli T. (обсудить/вклад) 02:46, 15 August 2022 (UTC)Reply[reply]

See Wiktionary:News for editors#August 2022 for an explanation of what has changed. 02:54, 15 August 2022 (UTC)Reply[reply]
@Atitarev: see Wiktionary:Grease_pit/2022/July#Finally_killing_off_{{trans-mid}} Chuck Entz (talk) 03:06, 15 August 2022 (UTC)Reply[reply]
Oh, no!
A few questions:
  • Are you seeing any problems besides the table no longer being split in two?
  • If you "zoom out" in your browser (decreasing the text size), does the table eventually split? Or does it stay un-split even when the text is extremely tiny?
  • If you visit Special:Preferences#mw-prefsection-rendering, which 'skin' does it tell you you're using?
  • What browser and browser version are you using?
  • How big is your screen?
Thanks in advance!
RuakhTALK 03:32, 15 August 2022 (UTC)Reply[reply]
@Ruakh, Chuck Entz: I've got the same concerns as Ruakh. Also, it doesn't seem to follow alphabetical orders any more, e.g. "Catalan" follows "Oriya" in culture#Translations. Was it even tested before released?! --Anatoli T. (обсудить/вклад) 03:37, 15 August 2022 (UTC)Reply[reply]
@Ruakh, Chuck Entz, Atitarev The alphabetical order is now broken for me (Chrome 67.0.3396.87 on Mac OS). For example, on the link Anatoli posted above (culture#Translations), I see Afrikaans through Sanskrit in the left-hand column, and the right-hand column has Dhivehi through Latin, followed by a blank line, then Scots through Zhuang. If I make the text bigger, it switches to one column, which is alphabetized. If I make the text smaller, I have Afrikaans through Scots in the left-hand column and Dhivehi through Zhuang in the right-hand column. Benwing2 (talk)
@Ruakh, Chuck Entz, Atitarev Signature got messed up, not sure if the ping went through. Benwing2 (talk) 04:03, 15 August 2022 (UTC)Reply[reply]
@Ruakh My skin is Vector legacy (2010). Benwing2 (talk) 04:05, 15 August 2022 (UTC)Reply[reply]
@Ruakh To clarify what is happening, the text goes in alphabetical order halfway down the left column, then continues in the right column, then jumps down to the lower half of the left column, the continues in the lower half of the right column. Benwing2 (talk) 04:09, 15 August 2022 (UTC)Reply[reply]
@Ruakh Also, the CSS class user-testing--this-that-and-the-other does not sound like something that belongs in production code. Benwing2 (talk) 04:14, 15 August 2022 (UTC)Reply[reply]
Thanks! I understand the problem now; {{trans-mid}} doesn't add anything to the page, but merely *having* it there means that we have two separate lists (since {{trans-mid}} is on its own line in the wikitext, which becomes a blank line), and so each list gets column-ized. This seems fixable to me, but it'll require thought and testing. For now I'll revert the changes.
Re: the CSS class that mentions 'testing': Yeah, I just left it there for now because it provided a backward-compatibility bridge to the old CSS (since the CSS sometimes gets cached in browsers). I figured we could remove it eventually.
RuakhTALK 04:22, 15 August 2022 (UTC)Reply[reply]
@Ruakh, Benwing2 I'm really sorry about this; a bad oversight.
It looks like setting {{trans-mid}} to contain * on its own line might work? See my latest change to User:This, that and the other/subject: I inserted {{User:This, that and the other/trans-mid}} between French and Galician in the "in grammar" translation table, with no perceptible impact on the display of the translations.
Compare this to the "main topic" translation table, which contains a blank template (just like {{trans-mid}} was before the change was reverted) between Hindi and Hungarian. This messes with the order of translations. This, that and the other (talk) 04:50, 15 August 2022 (UTC)Reply[reply]
@This, that and the other The "in grammar" section looks good to me, while the "main topic" looks bad. If this is intended, then your fix should work. Benwing2 (talk) 06:00, 15 August 2022 (UTC)Reply[reply]
That's good to know. Yes, I made "main topic" look bad on purpose as a point of comparison. We should set {{trans-mid}} to * on a line by itself. This, that and the other (talk) 06:40, 15 August 2022 (UTC)Reply[reply]

Off-topic remark: I'm not sure what has ruined the translation tables of the Turkish and Armenian editions of Wiktionary. --Apisite (talk) 07:17, 15 August 2022 (UTC)Reply[reply]

tr:sulamak looks fine to me - in fact, it looks like they have got in ahead of us and implemented CSS columns already. I found it hard to locate a translation table on Armenian Wiktionary - can you point to an example? This, that and the other (talk) 08:57, 15 August 2022 (UTC)Reply[reply]

senseno not working in reconstructions[edit]

It is asking me to add * before the word, but we are not giving words in this template at all, it just links to senseid on the same page. Error:

Lua error in Module:links at line 56: The specified language Proto-Slavic is unattested, while the given word is not marked with '*' to indicate that it is reconstructed

Sławobóg (talk) 09:29, 15 August 2022 (UTC)Reply[reply]

Should work now. 14:07, 15 August 2022 (UTC)Reply[reply]
It is working now. However it is bugged in real time preview (pic). After saving, it works fine, but it might be worth fixing. t:reconstructed had the same problem. Sławobóg (talk) 14:22, 15 August 2022 (UTC)Reply[reply]
Impossible to fix given the way the module works: it reads the page content and scans for the relevant senses. If the senses aren't on the saved page yet, it has nothing to work with. It could be changed to output a less scary error message, I suppose. 14:34, 15 August 2022 (UTC)Reply[reply]
Maybe this helps. 14:54, 15 August 2022 (UTC)Reply[reply]
It's good now. IMO, it would be a good idea if the sense would highlight when you hover the cursor over senseno (clicking should still be possible). Sławobóg (talk) 15:00, 15 August 2022 (UTC)Reply[reply]
That would have to be done using JavaScript. The following snippet seems to do the job:
$("a[href^='#'][href*=':_']").hover(function(e) {
    document.getElementById(decodeURIComponent($(e.target).attr('href').substring(1))).style.backgroundColor = "#DEF";
  }, function(e) {
    document.getElementById(decodeURIComponent($(e.target).attr('href').substring(1))).style.backgroundColor = "";
}); 19:59, 15 August 2022 (UTC)Reply[reply]
(1) Where would this Javascript go? (2) What is the issue with Module:links that needs fixing? Your change to Module:senseno seems to be hacking around a bug elsewhere, which is bad coding practice; we should fix the bug at the source. (3) Please please create an account. There are several knowledgeable IP's around here and it's highly annoying dealing with them, as it's impossible for me to sort out how many of them there are or which ones are the same person as which other ones. If you're worried about anonymity, you surely know that accounts are more anonymous than IP's, since you can geolocate your IP address (in your case to St John's, Newfoundland). Benwing2 (talk) 04:40, 16 August 2022 (UTC)Reply[reply]
(1) MediaWiki:Common.js seems like it would work, I suppose, but I can't test that. The only issue I could foresee is that it requires jQuery to be loaded by ResourceLoader, but it looks like the code in Common.js already assumes it's loaded. The code basically just implements the feature Sławobóg requested where mousing over a senseno link highlights the sense, instead of having to click on it. I can't comment as to the desirability of the feature.
(2) The entry hobby horse is a good example. On this entry one of the senseids is {{senseid|en|child's toy}}. If you try to link to this sense using any of the linking templates, e.g. {{l|en|hobby horse|id=child's toy}}, it generates the link [[hobby horse#English:_child%27s toy]]. That looks reasonable, but when actually visiting the link the sense is not highlighted. This is because the anchor ID itself is already escaped as English:_child%27s_toy, implying that the correct link would have to be doubly escaped as [[hobby horse#English:_child%2527s_toy]]. 05:02, 16 August 2022 (UTC)Reply[reply]

Collation severely messing things up in Template:akk-sign values[edit]

Look at 𒊨#Sign values, ‘Phonetic values’ rubric. What’s happening there? Looking at the module code I reckon that collation is at fault. ―Biolongvistul (talk) 10:05, 17 August 2022 (UTC)Reply[reply]

What collocations even exist on the page? I can't read. Vininn126 (talk) 11:23, 17 August 2022 (UTC)Reply[reply]
@Biolongvistul: The template doesn't support qualifiers, so I don't know why you are expecting them to work. — Fenakhay (حيطي · مساهماتي) 11:32, 17 August 2022 (UTC)Reply[reply]
Well, 𒁲 is working just fine, how is that? --Biolongvistul (talk) 14:34, 17 August 2022 (UTC)Reply[reply]
@Biolongvistul: Working fine in some cases and being supported are two different things. The module wasn't intended to support qualifiers. I can see it is not working because you are passing multiple qualifiers (the extra |). I don't have time to add this feature at the moment. — Fenakhay (حيطي · مساهماتي) 14:43, 17 August 2022 (UTC)Reply[reply]
This issue arises because the module splits phonetic values at commas (Module:akk-sign_values#L-27), which are also used between multiple qualifiers. It would be possible to change the splitting to be more sophisticated, but I think it might be better to add separate qualifier parameters instead of trying to jam everything into one string which then has to be parsed. 15:04, 17 August 2022 (UTC)Reply[reply]
The module was only designed to display a list of text in an alphabetical order, as there was no need for qualifiers. And personally I don't know why we need them. If you want to add support for qualifiers, go ahead and implement it. — Fenakhay (حيطي · مساهماتي) 15:08, 17 August 2022 (UTC)Reply[reply]

Rhymes and Category:Rhymes[edit]

I noticed we have both Rhymes and Category:Rhymes pages here, which serve basically the same scope, the latter objectively more efficiently than the former. My experience with Rhymes pages has been either (1) it's a redlink or (2) it's a bluelink, but it has only a portion of the entries present in its Cat counterpart, and also might have some entries which in the meantime have become red or yellow links. In general the fact that rhymes must be inserted manually through a textbox in a project where everything is automated with templates and categories sounds a bit uncharacteristic.

It's true that Rhymes pages have some information that the Cat pages lack, like a Pronunciation section (for people who cant read the title of the page), Spelling section (for people who cant look at the entries contained in the Category), mergers information (probably the only useful thing), etc (?).

My proposal is thus:

  1. add the (valuable) information to the Cat pages (easily automated)
  2. make {{rhymes}} link to the Cat pages and not the Rhymes pages

We could probably also make good use of better subcategorizing, for example Category:Rhymes:Italian/ate could be a subcategory of Category:Rhymes:Italian/a–e, which would also contain Category:Rhymes:Italian/are and Category:Rhymes:Italian/arne, but that's a postponable proposal.

Catonif (talk) 15:10, 17 August 2022 (UTC)Reply[reply]

I think, or at least hope, this is the goal, to slowly move everything in Rhymes: to the categories. - -sche (discuss) 18:15, 17 August 2022 (UTC)Reply[reply]
That would be nice. Vininn126 (talk) 19:59, 17 August 2022 (UTC)Reply[reply]

The combining-diacritic section of the IPA/enPR character-input menu is borked[edit]

The Wiktionary character-input menu, with the borked combining diacritics indicated by the black arrow.

In the "IPA and enPR" edit-page character-input menu, the latter part of the diacritics section, containing combining diacritics, is borked and unusable, with the combining diacritics zalgoing on top of each other and unclickable (see first image to the right; you'll need to view the full-size image to see the problem clearly).

The Wikipedia character-input menu, with the combining diacritics, this time non-borked, indicated, again, by the black arrow.

This appears to be a Wiktionary-specific problem (rather than a bug with the MediaWiki software itself), as the combining-diacritic section of the Wikipedia IPA character-input menu is not borked (see second image to the right; again, you'll need to look at the full-size image to get a clear view of the situation there).

Could an interface admin please fix this? Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 17:25, 17 August 2022 (UTC)Reply[reply]

They display correctly for me in Firefox (whether I'm logged in or out), but display incorrectly in Chrome (whether logged in or out). There's been no change to MediaWiki:Edittools recently. Maybe Chrome has recently changed how it handles something we're doing; Wikipedia seems like it might be doing something different from us since their characters are all in their own boxes. - -sche (discuss) 18:11, 17 August 2022 (UTC)Reply[reply]
Looking at the source for the (working) Wikipedia edittools and comparing it to the source for our own (borked) edittools, I can only find two significant differences:
I have no idea if either of these could actually explain this problem (and the latter one, at least, seems a bit unlikely, given that combining-character-on-  works fine in, e.g., headword-line templates).
And it also turns out the problem is worse than I originally thought. Nearly all of the combining characters in out edittools are borked, not just the ones in the IPA menu. The only combining characters anywhere in our edittools that actually work at the moment, at least on Chrome, are the ones in the dedicated modifiers-and-combining-diacritics menu and in the Arabic, Cyrillic, Greek, and Hebrew menus (all of these menus, unlike the others, enclose their combining diacritics in their own individual span tags, interestingly enough), plus a few isolated examples from the other menus: the Myanmar nga-killer-virama complex (at least, that's what the codepoint readout says) from the Burmese menu, the candrabindu from the Devanagari menu, and the superscript alaph from the Syriac menu. This leaves the Burmese, Devanagari, and Syriac menus with almost all their combining characters borked, as well as every single combining character from the IPA/enPR, Khmer, Lao, and Sinhala menus. In addition, a number of spacing characters are also borked and unclickable in the edittools: the sof pasukh from the Hebrew menu, plus around half of the vowel nuclei from the Lao menu. Pardon my French, but merde. Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 19:41, 17 August 2022 (UTC)Reply[reply]
I use Firefox, but looked at the IPA diacritics in Chrome as well and the problem seems to be that MediaWiki:Gadget-Edittools.js replaces &nbsp; with ASCII space in the displayed text of combining characters in MediaWiki:Edittools, and ASCII space plus combining character isn't clickable in Chrome. No-break space plus combining character is clickable in my Chrome (though it's narrow), so editing the JavaScript should fix the problem. (In Firefox the ASCII space plus rhotic hook U+02DE is unclickable... not sure why.)
I think Chrome must have changed their font rendering because both Firefox and Chrome render the IPA diacritics in Arial, but they are unclickable in Chrome. — Eru·tuon 08:20, 18 August 2022 (UTC)Reply[reply]
I fixed the unclickable diacritics and made diacritics a bit wider so they are easier to click on. Unfortunately, this also increases the spacing between other characters in the Edittools and I don't know how to fix that. — Eru·tuon 22:53, 18 August 2022 (UTC)Reply[reply]

Something wrong with sections on mobile[edit]

Looks like there's been something going wrong with sections in mobile, which doesn't show contents when I tap to expand them. Temporary issue?-TagaSanPedroAko (talk) 19:05, 17 August 2022 (UTC)Reply[reply]

Oh, it just went back to normal. -TagaSanPedroAko (talk) 19:07, 17 August 2022 (UTC)Reply[reply]

Suddenly all section links deliver me to the top of the page[edit]

e.g. so#Spanish goes to the Spanish subheader for just a fraction of a second and then brings me back to the top of the page. Copy/pasting the URL also does that, and refreshing the page doesnt change anything either. Recent code update? Thanks, Soap 22:13, 18 August 2022 (UTC)Reply[reply]

It also happens on Wikipedia so this may be outside our purview but I want to leave this section up in case anyone else comes here to see whats going on. Hopefully it's fixed soon. Soap 22:14, 18 August 2022 (UTC)Reply[reply]
I'm experiencing this too, whether in Firefox or Chrome or Edge, whether logged in or out, and also if I type a section link into the search bar, or e.g. when I save an edit to this section of this page. Yesterday I was experiencing the page jumping, but not all the way to the top or bottom (I don't recall whether it was jumping up or down). - -sche (discuss) 22:44, 18 August 2022 (UTC)Reply[reply]
Yes, at el.wikt too! I thought i've done something very wrong!! ‑‑Sarri.greek  I 23:07, 18 August 2022 (UTC)Reply[reply]
Fixed !! ‑‑Sarri.greek  I 01:10, 19 August 2022 (UTC)Reply[reply]