Wiktionary:Grease pit/2023/February

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← January 2023 · February 2023 · March 2023 → · (current)

---

Zero-derived template

Would there be use in a zero-derived template? I see a lot of "the adjective is derived from the noun" in especially English etymologies, and I was wondering if there wouldn't be use for a category "X language Y part of speech zero derived from z part of speech", with a glossary link? Vininn126 (talk) 09:37, 1 February 2023 (UTC)

@Vininn126 In practice, this is what categories like CAT:Italian deverbals are for. For example, I use a template {{it-deverbal}} to put entries into this category when they are derived from verbs by adding only '-a', '-o' or '-e' to the verbal stem. We could maybe make that clearer in the description and/or category name. I'd be opposed to using an actual -ø- or similar suffix to denote this sort of derivation but not so much to a more generic naming. Benwing2 (talk) 18:18, 1 February 2023 (UTC)

I was imagining something more like {{zero derivation|en|noun|verb}} to print "The noun is {{glossary|zer derivation|zero derived}} from the verb." on e.g. "run" or something. I agree using -ø- is less than optimal. Vininn126 (talk) 18:21, 1 February 2023 (UTC)

At least for English entries, I'm not sure using a technical term like "zero derived" is particularly helpful for readers. However, one can have a template categorize an entry while keeping the displayed text simple. — Sgconlaw (talk) 21:22, 1 February 2023 (UTC)

That is why we have a glossary, and I don't see why we should avoid technical terms for one language. Vininn126 (talk) 07:30, 2 February 2023 (UTC)

I think we aim for a general readership and not linguists. Perhaps more technical language is fine for reconstructed terms, but I’d say not for general entries. However, feel free to raise the issue for wider discussion at the Beer Parlour. — Sgconlaw (talk) 11:52, 2 February 2023 (UTC)

Abuse filter triggered when trying to edit

The page "trans man" currently defines a trans man as "[...] i.e., a woman who was born female who self identifies as a man." Although calling a trans man a woman is incorrect and offensive, attempting to revert the page to "[...] i.e., a man who was assigned female at birth." results in an abuse filter disallowing it. Please fix this immediately. 14.238.83.194 04:27, 2 February 2023 (UTC)

I’m not sure why that happened, but I’ve fixed the incorrect edit by copying the text from an older version of the entry and pasting it into the current version. (Sense 2 was also removed without an explanation.) — Sgconlaw (talk) 04:56, 2 February 2023 (UTC)

Help! css for ol

Hello, I was looking in the wide internet, for a css to copypaste: nested ordered fully numbered lists with levels, and start= (#Jan.2023, contents with columns). I cannot find one, except partial bits. Trying here wikt:el:Template:test-ol, unsuccesfully :( If anyone knows a link somewhere, it would be very helpful, thank you ‑‑Sarri.greek ^♫ I 07:32, 2 February 2023 (UTC)
@Benwing2, i think, wikt:el:Template:test-ol is ok? I don't know if it works for other people's computers. Only problem, that space under col1.alone... I wish there were some module to read the sectiontitles automatically, but oh, well... ‑‑Sarri.greek ^♫ I 16:38, 4 February 2023 (UTC)

The adjectival ending -zki in Polish

Discussion moved to Wiktionary:Requests for deletion/Non-English.

Request: Filter to strip Unicode Paragraph Separator

Can we add a filter to strip U+2029? My bot just tripped over it at socker so I removed it there and from the three other pages where it appeared. It doesn't display on the page or in the edit window so it doesn't seem like it has any reason to be allowed. Are there other non-printable Unicode characters we should filter? JeffDoozan (talk) 15:37, 4 February 2023 (UTC)

As far as I know, we don't have any way to change wikitext like that. All we can do is flag or prevent an edit that contains the offending character(s). Chuck Entz (talk) 15:51, 4 February 2023 (UTC)

I think preventing edits that use it is a good idea - we already do this with a few characters, and there are various others that we probably want to do the same with. It might be worth giving each white space/invisible character that we filter their own edit filter, so that the message can specify exactly which one is causing the issue (and if possible, maybe giving some context, too, by using a regex that gives e.g. 10 characters on either side). They can be a pain to find, otherwise. Theknightwho (talk) 15:56, 4 February 2023 (UTC)

That would use a lot of processing power, though. Wouldnt it? Every edit filter runs on every single edit, and if only 0.01% of them are going to have these characters in them, it seems like a lot of slowdown for very little gain. (Unless things have changed; its been a while since I worked with edit filters.)

Since I know the nonprintable characters wont show up in an ordinary search, is it possible to use the API to do a "deep search" that will turn them up, and then have a bot go through and remove them from those pages? —Soap— 13:14, 5 February 2023 (UTC)

The difference would be completely negligible. Theknightwho (talk) 15:29, 5 February 2023 (UTC)

@Theknightwho: I think adding filters is an admin-only thing so I'll leave implementing this this to you. I believe the appropriate filter would be either

(page_namespace == 0) & (rcount("[\x{2029}]", added_lines))

or

(page_namespace == 0) & ("
" in added_lines)

with the latter likely being faster but less readable. JeffDoozan (talk) 17:39, 8 February 2023 (UTC)

TOC pushing the Faroese conjugation tables down

If the table of contents is placed to the right in Preferences, it pushes Faroese verbs' conjugation tables downwards and separates them from the "Conjugation" heading. -- Apisite (talk) 06:24, 5 February 2023 (UTC)

Yeah I think thats just an unfortunate side-effect. I use right-TOC as well because it saves space for the most part, but its just not Faroese ... I see that whitespace on a lot of other pages too. Im not complaining, because on balance, it still saves space by having the content at the beginning instead of having a TOC first and then the content. Also, the new Vector 2022 skin solves the problem by putting the TOC into the sidebar, away from the content. I have not yet switched to the new skin because I like some of the other features of the old skin, but ... yes, it solves the TOC problem once and for all. —Soap— 13:10, 5 February 2023 (UTC)

Egyptian hieroglyphs

Looks like they're broken: In entries, the hieroglyphs often don't show (jb, wsj), whereas in translations they break the assisted editing (heart/translations). I have no idea what causes the latter, but the former seems to be an issue with WikiHiero? Thadh (talk) 12:55, 5 February 2023 (UTC)

At jb, hieroglyphs show up in quotations and alternative forms, but not in the headword, even though all three of those use hiero tags: this makes me think the issue is not wikihiero, but some module used by the headword template. Perhaps a recent change has made it strip or ignore the brackets (and contents?) of the hiero tag? - -sche (discuss) 08:01, 6 February 2023 (UTC)

@-sche: in that case the problem lies in our headword template {{head}}, since {{egy-noun}} doesn't invoke anything. Thadh (talk) 09:15, 6 February 2023 (UTC)

I suspect that it's something to do with the formatting we apply to terms in a language (via Module:script utilities/Module:languages, etc.), because if you do {{head|egy|noun|head=<hiero>a</hiero>|<hiero>a</hiero>}}, then the first one doesn't display but the second one (which isn't formatted in that way) does. Also, it affects {{m}} too, not just {{head}}; see the etymology section of Jerusalem for an example. I haven't been able to figure out the exact issue though. A quick temporary workaround would be to make the Egyptian headword templates use {{head-lite}} instead, but that's not ideal. 70.172.194.25 09:27, 6 February 2023 (UTC)

I'm convinced that this edit broke it somehow, because if I revert Module:links to the revision just prior and preview, it displays correctly. 70.172.194.25 09:45, 6 February 2023 (UTC)

@Theknightwho. Thadh (talk) 09:46, 6 February 2023 (UTC)

@ThadhThis should be fixed. That edit is indeed what made it affect headwords, but it was actually this edit that was the underlying cause, because it was removing the strip markers that are generated for displaying hieroglyphs in the display form (which is also used for transliteration, where we definitely don't want them at all). They now get temporarily converted to something else to stop them interfering with the substitution process, and put back again after. Theknightwho (talk) 09:54, 6 February 2023 (UTC)

I guess all that remains is figuring out how to fix translation tables. Thadh (talk) 10:03, 6 February 2023 (UTC)

I will investigate. Theknightwho (talk) 10:42, 6 February 2023 (UTC)

@Thadh, Theknightwho: Special:Diff/71217363. 70.172.194.25 10:43, 6 February 2023 (UTC)

I still have issues with adding translations when Egyptian is present. Thadh (talk) 19:21, 8 February 2023 (UTC)

@Thadh: The diff above has not been incorporated into MediaWiki:Gadget-TranslationAdder.js. We need an interface admin for that. 70.172.194.25 19:23, 8 February 2023 (UTC)

Fixed. Thank you! In the future, please ping me or another interface admin if you need changes like this made, otherwise I may miss it. Benwing2 (talk) 22:47, 8 February 2023 (UTC)

citations for enchalupa

Can someone post this? This has way more steps than I thought. It said I couldn't post it, and to post it to the Grease pit instead, but this is the grease pit....

"This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: probably vandalism"

IguessIneedtodothis (talk) 23:26, 5 February 2023 (UTC)

Ok I cannot post the citations? I guess I have to wait 4 days to post anything? Why create an account at all? IguessIneedtodothis (talk) 23:29, 5 February 2023 (UTC)

You can do lots of things, but a new account adding lots of web links is usually a vandal or a spambot, which is why our filter looks for that. You then tripped another filter that looks for new accounts making lots of edits in a short time- another strategy more typical of vandals than regular editors. Rather than go into details that would tell real vandals how to get around the abuse filters, I just published your edit for you. At any rate, it's harder to meet our our attestation requirements with citations from random websites, so that may not be the best use of your time, but that's not for me to say. Sorry for the inconvenience and stress. Chuck Entz (talk) 23:59, 5 February 2023 (UTC)

Getting a list of topic categories that haven't been created yet in a language

Could someone help me get a list of the categories (maybe inserting it on their talk page for Hungarian) that haven't been created yet for Hungarian? I'd like to see which one could be created and populated, whether with existing entries or with new entries that should be created anyway. Thank you in advance! Adam78 (talk) 11:13, 6 February 2023 (UTC)

That reminds me, can someone fix Module:category tree/topic cat/hierarchy by adding ["LABELS"] at the end of the require() line? It's currently broken and not displaying anything; not sure for how long it has been that way. 70.172.194.25 11:50, 6 February 2023 (UTC)

This has been fixed by Fenakhay; thanks. 70.172.194.25 19:54, 8 February 2023 (UTC)

Have you looked at Special:WantedCategories? It looks like Category:hu:Blind is the only topical category for Hungarian that is missing and has any members. WantedCategories is periodically refreshed, last time two days ago. DCDuring (talk) 16:19, 6 February 2023 (UTC)

@DCDuring Thank you; this category is not actually a regular one as it's not included among those that {{auto cat}} can handle; the only entry linked there belonged to the existing categories of Category:hu:Disability and Category:hu:Vision, which I've just fixed. However, I still don't know what those topic categories are that are part of the pre-set hierarchy (that {{auto cat}} can handle and which are populated for some other languages) but which hasn't been created for Hungarian (i.e., they aren't even linked yet, so Wanted categories doesn't really help here).

To be more specific, Category:hu:List of topics has 891 subcategories while Category:en:List of topics has 2,444 (Category:List of topics having 4,470). Their difference is 1,553 (for Category:List of topics, 3,579), so apparently these are the ones that could be created, and this is what I'd like to know specifically without having to compare their contents one by one. Some might be less known regions or other fairly obscure topics, but there must be ones that are important and which possibly have thematically related entries already, without being categorized yet. Adam78 (talk) 18:42, 6 February 2023 (UTC)

I think the idea is to have L2 sections that need categories before creating the categories. I'm not sure, but I believe that empty categories are deleted. DCDuring (talk) 18:49, 6 February 2023 (UTC)

Adam's point was that the "L2 sections" may already exist, but not be categorized yet. 70.172.194.25 18:51, 6 February 2023 (UTC)

How would that happen for more than the latency period of the Special page? DCDuring (talk) 21:18, 6 February 2023 (UTC)

Let me try to rephrase this. They want to find a list of topical categories that don't yet exist for Hungarian, so that they can create and populate them, by tagging the appropriate (already existing, but uncategorized) entries as belonging to that category. 70.172.194.25 21:22, 6 February 2023 (UTC)

@Adam78: Did you see what I added to Category talk:hu:All topics? 70.172.194.25 18:50, 6 February 2023 (UTC)

@70.172.194.25 I'm absolutely impressed! Thank you very much! – As a test, I've created and populated one category that already had related entries. Adam78 (talk) 19:57, 6 February 2023 (UTC)

@70.172.194.25 Thank you once again for the improvement with the related English-language links. Adam78 (talk) 21:34, 6 February 2023 (UTC)

Which one? DCDuring (talk) 21:19, 6 February 2023 (UTC)

@DCDuring Category:hu:Publishing. Adam78 (talk) 21:34, 6 February 2023 (UTC)

I feared you were going to be adding empty categories. DCDuring (talk) 21:38, 6 February 2023 (UTC)

@DCDuring I wrote "populated" in my very first sentence above. Adam78 (talk) 21:45, 6 February 2023 (UTC)

My fear was fed by "created" preceding "populated". DCDuring (talk) 21:48, 6 February 2023 (UTC)

I look forward to Category:hu:Pirkanmaa, Finland being filled up. Celui qui crée ébauches de football anglais (talk) 21:22, 6 February 2023 (UTC)

Bad MHG links

E.g. in Mücke: "Middle High German mücke, mügge, mucke, mugge". The ü terms link to u entries, but Umlaute are part of MHG, not normalised or dictionary stuff (like macra in Latin), hence proper places are e.g. mügge. — This unsigned comment was added by 93.221.41.136 (talk) at 15:50, 6 February 2023 (UTC).

I've fixed this. Theknightwho (talk) 20:55, 6 February 2023 (UTC)

Could someone generate a list of entries that are unlinkable because of entry name normalization, i.e. mainspace pages where {{l|[language code]|[raw page title]}} generates a link to a different page? mügge would have been an example of such a page, prior to the fix. We could even add an automatic check for this to {{head}} potentially. 70.172.194.25 20:58, 6 February 2023 (UTC)

With some work I could probably do this from the dump. I have code for generating entry names for toolforge:enwikt-translations and code to extract language headers. I'm not sure if it should be done in {{head}}, but that's certainly possible too. — Eru·tuon 01:48, 7 February 2023 (UTC)

Should that include discouraged sequences? These will mostly be Tamil and Malayalam. --RichardW57m (talk) 10:18, 7 February 2023 (UTC)

They’ll be covered anyway, I imagine. Theknightwho (talk) 15:35, 7 February 2023 (UTC)

ē#Slovene is another example of an unlinkable entry (along with other diacritic variants listed under "See also"). Noticed because of this edit. 70.172.194.25 05:08, 8 February 2023 (UTC)

I found another example in the wild while looking up etymologies: Reconstruction:Proto-Slavic/śědъ. I was surprised to see the red link *śědъ on the entry šedý so investigated, and was amazed that it was an entry name normalization issue! 70.172.194.25 08:16, 8 February 2023 (UTC)

Quotations data small?

Would en.wiktionary consider making the data for quotations small size? Chronology would be fine as normal, but description is sometimes too long. Thank you. ‑‑Sarri.greek ^♫ I 09:03, 7 February 2023 (UTC)

Can you link to one example? DCDuring (talk) 13:21, 7 February 2023 (UTC)

{{RQ:Sidney Arcadia}} 70.172.194.25 15:47, 7 February 2023 (UTC)

Sarri.greek: Examples, assuming #visibility-quotations. Quotations are found

• Α) in lemma Cat.English terms with quotations

  abacinate, abbess I cannot tell easily which is text and which is description. abash, definition, synonyms, quotation-text, quotation-data difficult to distinguisth. Other: ἀνδρεία (andreía)

  Sometimes, the quotation-data is short, and there is not text ἀθλητής (athlētḗs)

• B) in Citation pages Category:English_citations
  • It happened that the first page i saw was Citations:abate, Citations:διαιρέω
  • Then, I saw others (more common), which do not have templates, but only a link to author & work: Citations:about Sometimes, repeating definitions: Citations:abate

I was wondering if a unified 'small font size for data' could be default. Apart from the visual issue, because the data part is not an integral part of the lemma content. Thank you 70.172.., DCDuring, ‑‑Sarri.greek ^♫ I 16:29, 7 February 2023 (UTC)

Comments:

• I don't personally see anything wrong with abacinate, it seems very normal to me. But I'm so used to Wiktionary's design and interface that I might overlook usability issues for readers.
• I think abash would benefit greatly from moving the synonyms and antonyms off to separate thesaurus pages, but the quotations themselves don't seem particularly problematic (granted that the Macaulay quotation metadata is slightly on the long side, but not unreasonably so, and has a "please specify |volume=" message).
• The Ancient Greek entries that only give the work metadata and not the actual text are non-ideal, but at least many of them have links to Wikisource, often to the specific section that is being quoted. The issue is even worse in Sanskrit entries imported from Monier-Williams that only give source abbreviations, no Wikisource links, and take non-trivial effort to track down (e.g. विधान (vidhāna)). Having too much quotation metadata is a much better problem to have than having too little.
• Styling just the quotation metadata or text is possible (at least for quotation templates that use {{cite-meta}}) For example:

  .cited-source { font-size: 85%; } /* quotation metadata */
  .h-quotation { color: green; /* arbitrary example */ } /* quotation text */
  

  To get this to work with raw quotations that don't use the templates (e.g., on mindquake) would take a bit more targeting but should still be feasible in principle. Maybe something like:

  ul > li { font-size: 85%; } /* quotation metadata */
  ul > li > dl { font-size: 120%; } /* quotation text */
  

70.172.194.25 16:53, 7 February 2023 (UTC)

I find some citations, especially those using some of the RQ templates, 1., include much too much information about the publisher and/or, 2., have excessively long titles. Neither are helpful in locating the context of the word at least 99.9% of cases. The indispensable information is the date of the earliest edition in which the passage cited occurs, the author, and the title of the work, perhaps the volume. If the work is not available online, then chapter, page, etc. become more important. The long titles of some older works include what we might now call subtitles. They remind me of publisher's blurbs on a dustjacket, which we certainly would never include. Few readers call Tom Jones by its full title, The History of Tom Jones, a Foundling, even though that full title is brief compared to some in our RQ templates. It might be useful to have in some appendix or even yet another namespace the lengthy publication details now cluttering our citations to which we could link from the citation or RQ template. DCDuring (talk) 00:40, 8 February 2023 (UTC)

Consider the following text generated by an RQ template {{Template:RQ:Scott Tales of My Landlord 2}}, taken from the nearly 6,000 RQ templates that we have:

1818 July 25, Jedadiah Cleishbotham [pseudonym; Walter Scott], (The Heart of Mid-Lothian), volume (please specify |volume=I, II, III, or IV), Edinburgh: […] [James Ballantyne and Co.] for Archibald Constable and Company, OCLC 819902302:

I would argue that, if we are dealing with the original publications, we need much less:

1818, Walter Scott, The Heart of Mid-Lothian, volume 2[?], page xx^[pageurl]

There are cases where we need to identify the edition, as where it is not the original edition that is being cited.

I don't think that we ever have need for much of the detail now provided. Moreover, I believe that it is off-putting for normal users, even for those who want to see usage examples and/or citations. DCDuring (talk) 00:56, 8 February 2023 (UTC)

I think we should be accurate when it comes to identifying the edition quoted from, and that means providing full imprint information. Sometimes the true first edition of a work isn’t available online, and it needs to be clarified that a first edition published in a different country, another edition, or a later facsimile or republication is being used. Users have the option of hiding quotations if they don’t wish to view them. — Sgconlaw (talk) 01:49, 8 February 2023 (UTC)

The issue of some users actually AFAICT just one user, Sgconlaw, including excessive information in quotation templates has been discussed before (e.g. May 2018). I understand the competing desires to have concise presentation vs to have as much information as possible. Could we take inspiration from how other dictionaries cite works in an abbreviated way in the body of the dictionary and then have a bibliography at the start or end with all the details, and present just the date, author, work and page number in the entry, with a parenthetical "(more details)" that would link to the quotation template (or an appendix) where the full bibliographic information like "[James Ballantyne and Co.] for Archibald Constable and Company, OCLC 819902302" was displayed? We could even make hovering over "more details" display the extended text, similar to how {{...}} does, so users who can hover don't even have to click the link (but users e.g. on mobile who can't necessarily hover can click the link). - -sche (discuss) 22:01, 8 February 2023 (UTC)

I like the hovering idea  :-)

—DIV (1.145.64.48 11:50, 23 February 2023 (UTC))

Asking for help from volunteer programmers for TOC

Hello from el.wiktionary. For some time now, I thought that the ToC (Table of Contents) does not have parameters needed to serve better the needs of dictionaries. I know nothing about computers, so, I am asking for help of volunteer programmers.
My understanding of a ToC, whether it may some day also appear at a side menu (as we learn, by WMF) or not, is that it is under the responsibility and discretion of editors to formate, not the 'typographer' (the skin) who may add it also somewhere outside. That is: it belongs to the body of the page. Which is why, there is a toclimit choice, a choice to place it right (TOC right or left, at some projects, etc). We assume that full numbering (1.2.1, 1.2.2.,...) is in place, and no hidden titles, as certain wiktionaries use under + or arrows.
There are thousands of wikt.pages, where a horizontal presentation by language would be more suitable than vertical. Pages with 2-5 languages, or as the editor or administrators see fit. Also, when toclimit2, a horizontal presentation (example).
In my naïveté and "pure ignorance" I tried to see how it might look at wikt:el:Template:test-ol, and wrote the way i think of it at a plan-test. I do not know how to ask a module to 'read' the page, find the titles, and put them in a row (arrary is the word?). A module, because we do not have 'interface administrators' to edit common CSSes and place gadgets. But if possible, a standalone way to do it.
If you know someone, from any project, that might help us, it would be great! Thank you so much, for your much appreciated support to small wiktionaries. —(Central)‑‑Sarri.greek ^♫ I 08:20, 8 February 2023 (UTC)

User:Erutuon or IP 70.* can you help? I agree a horizontal TOC would be a much better use of space but I don't know much about CSS styling. Benwing2 (talk) 19:20, 8 February 2023 (UTC)

Thank you @Benwing2. I do not mean for every page. But there are many pages that could be presented in this way. As an experiment.

I hope the numbering of headings with the css is correct at wikt:el:Template:test-ol ? it took me hours. But I cannot make the computer 'read' the headings. I still have to write them by hand...:( ‑‑Sarri.greek ^♫ I 19:35, 8 February 2023 (UTC)

I don't know much about CSS either, but I might be able to help through a combination of looking stuff up and trial-and-error, if there's a specific question. 70.172.194.25 19:51, 8 February 2023 (UTC)

Is your current issue how to access the list of sections in a page using Lua? Maybe something like this:

local content = "\n" .. mw.title.new("title"):getContent()
local match = content:gmatch("\n==([^\n]+)")
while true do
  local header = match()
  if not header then break end
  -- do work here
end

If you want I can flesh this out even more in a module on el.wiktionary. However, I'm not sure that trying to generate a TOC via Lua is really the best way to go about this, as I can imagine situations where it might break (for example, if the heading is added by a template [but maybe preprocessing would resolve that]). It might work in the majority of cases at least. 70.172.194.25 19:50, 8 February 2023 (UTC)

Ω, great, 70.172. I will try it. The simpler the better. Thank you. ‑‑Sarri.greek ^♫ I 20:01, 8 February 2023 (UTC)

@sarri.greek: Here is an example of generating a nested list from headers.

If you want nested numbers before the list items, you can use CSS like this from a StackOverflow answer, either putting it in MediaWiki:Common.css or in a TemplateStyles page (which would typically be named or ) that is transcluded by the template:

.your-class-name ol { counter-reset: item }
.your-class-name li { display: block }
.your-class-name li:before { content: counters(item, ".") " "; counter-increment: item }

Oh, actually you have TemplateStyles CSS that works already, though it's slightly different. It only needs to be restricted to the TOC by adding class="your-class-name" or class="other-classes-here your-class-name" somewhere around the list of headers (for instance, you could use {| class="mw-collapsible your-class-name" in the current code of wikt:el:Template:test-ol if there are no other ol elements besides the header names). your-class-name should be replaced with whatever class name you want to use for your custom ToC.

Not sure how to do the horizontal layout. You can do .your-class-name ol { column-width: 10em; }, but that probably doesn't make sure that each language is in its own column. I could write Lua code to split each language section and its headers into a separate list if that would help. — Eru·tuon 21:46, 8 February 2023 (UTC)

A, I cannot, I do not unerstand what to write. I am not so clever to do it. :( Erutuon, how can there be a list of all 'header = match()'. Would they be numbered #1, 2, 3, 4, 5, 6 as they are found? So that I could extract from each kind, its output.text I managed only the first one. ‑‑Sarri.greek ^♫ I 16:50, 10 February 2023 (UTC)

@sarri.greek: I put in the code that I linked to in my previous message with some modifications. I don't know if it does exactly what you want it to but it does make the template print the headers. — Eru·tuon 02:34, 11 February 2023 (UTC)

@Erutuon:, you are so kind! Thank you so much. It would be wonderful to have these horizontal tocs ! ‑‑Sarri.greek ^♫ I 02:37, 11 February 2023 (UTC)

@Erutuon, Could you possibly (at some time in the future) make a version, stripping all style from the 'table' or 'list' for wikt:el:Template:toc-test.
Like: start_level .. header .. end_level ==header== to become <li id=2>header</li>
I see now that the whole thing is complicated (just stripping the array of any styles). Thank you, I appreciate your help very much. ‑‑Sarri.greek ^♫ I 15:01, 16 February 2023 (UTC)

I don't understand, stripping style from which table? I'm confused because there are so many things on el:Πρότυπο:toc-test and don't know which one you are currently working on. — Eru·tuon 06:02, 20 February 2023 (UTC)

ΟΚ, thank you @Erutuon, you have already helped so much! ‑‑Sarri.greek ^♫ I 08:36, 20 February 2023 (UTC)

One problem at wikt:el:Module:toc-test, is the repetition of headers in a page e.g. Noun, Noun, Noun. Their heading-links would become: Noun, Noun_2, Noun_3. It is a pity that it is too late for me to learn Lua... (I made a manual sample of what these TOCs would look like at wikt:el:θωριά). ‑‑Sarri.greek ^♫ I 23:06, 24 February 2023 (UTC)

@Sarri.greek: Edited the Greek Wiktionary module to fix this. 70.172.194.25 23:28, 24 February 2023 (UTC)

ping 70.172!!! thank you thank you thank you. :) ‑‑Sarri.greek ^♫ I 23:29, 24 February 2023 (UTC)

Slower?

I have been experiencing more delay lately in getting the entirety of long pages. Also, I have notes that the "thank" option in entry history has not appeared, at least not during the time I was willing to wait for it. Has there been some change, whether in our control or not, that is causing this? Or should I be looking closer to home (IP provider, Wifi, my PCs)? DCDuring (talk) 16:48, 8 February 2023 (UTC)

Have you noticed the same change on other WMF sites (or even non-WMF sites), or only English Wiktionary? And could you give some examples of long pages that seem slow to load? (This would help narrow down whether certain template or module changes are responsible.) 70.172.194.25 19:22, 8 February 2023 (UTC)

I haven't noticed either slow loading or missing "thanks" for diffs on WP or on Wikispecies (but most Species pages are small). I created a 65K user page with no templates which loads quite quickly. I don't seem to be having the problem at all now. I was even able to load [[a]] and its edit window rather quickly. When it occurred it seemed to be on large discussion pages.

Are there any particular pages that are a good stress test for loading time?

It may have been a transient problem, on my PC, my ISP, or on the WM servers. DCDuring (talk) 22:21, 8 February 2023 (UTC)

@DCDuring Yeah, large discussion pages are slow-loading and become unusable at a certain point. Benwing2 (talk) 22:28, 8 February 2023 (UTC)

But even that loading-time problem has gone away. DCDuring (talk) 22:43, 8 February 2023 (UTC)

If there were such a change in Wiktionary it would probably be a Wikimedia bug; unlikely anything under our control. But it could be your browser or ISP or whatever ... I haven't noticed an obvious slowdown. Benwing2 (talk) 19:22, 8 February 2023 (UTC)

FWIW I haven't noticed an obvious difference either. 70.172.194.25 19:25, 8 February 2023 (UTC)

The only thing I can think of is that the lite templates pay for their memory savings by increasing various other page stats - one of which is an increase in load time. A couple of pages are at the 9 second mark because of this, but there’s not really much we can do about it. Theknightwho (talk) 21:17, 8 February 2023 (UTC)

Linking words with multiple etymologies and senses

I want to make clear links between Sanskrit verbs वृणोति (vṛṇoti), or rather its two etymologies, which appear to have highly relevant by-forms वरति (varati) and *वरति (varati), and the Pali verb varati and its two etymologies. My first thought is to use the support supplied by {{senseid}}, but etymology 1 currently has 3 senses in Pali and 8 in Sanskrit. How do I fashion the links between etymologies rather than senses? Do I just use the etymology ID as I would use the sense ID? The documentation for {{inh}}, for example, only mentions sense IDs, not etymology IDs. --RichardW57m (talk) 12:57, 9 February 2023 (UTC)

@RichardW57m User:Surjection created {{etymid}} I think for this exact purpose; they can comment more. Benwing2 (talk) 23:42, 9 February 2023 (UTC)

You can use etymology IDs in linking templates (including etymology templates) in exactly the same way as you would use sense IDs. 70.172.194.25 23:54, 9 February 2023 (UTC)

Split auto-translit of comma-separated terms for Tajik in Template:fa-regional

Is there a way to fix the display for multiple values as in {{fa-regional|انگلیسی|انگلیسی|англисӣ, инглисӣ}} see انگلیسی (engelisi):

• Current: англисӣ, инглисӣ (anglisī, inglisī)
• Desired: англисӣ (anglisī), инглисӣ (inglisī)

@Erutuon, Fish bowl, Benwing2. Anatoli T. ^{(обсудить}/^вклад) 06:12, 10 February 2023 (UTC)

@Atitarev {{fa-regional}} needs to be changed to take separate translit params for each term. Benwing2 (talk) 06:18, 10 February 2023 (UTC)

@Benwing2: If it's the only way, I am fine. Thanks for that. Anatoli T. ^{(обсудить}/^вклад) 06:21, 10 February 2023 (UTC)

@Atitarev, Benwing2: I added |tg2= for the second Tajik term. This fixes the display and I think that's how the parameter would be named in a typical Lua-based template. — Eru·tuon 04:32, 11 February 2023 (UTC)

Does {{#len:}} actually work on Wiktionary?

I tried to use the {{#len:}} parser function in a template to use different font sizes depending on whether a parameter is 2 or 3 letters, and it looks like this function doesn't work/is disabled. Example: {{#len:abcde}} - this should be the number 5. Tweenk (talk) 04:08, 11 February 2023 (UTC)

mw:Extension:ParserFunctions lists a setting $wgPFEnableStringFunctions that controls whether string functions, including {{#len:}}, are enabled. Since we have ParserFunctions version 1.6.0 according to Special:Version#mw-version-ext-parserhook-ParserFunctions and {{#len:}} was added in version 1.2.0 according to mw:Help:Extension:ParserFunctions#len, this setting must be off because {{#len:}} doesn't work. — Eru·tuon 04:25, 11 February 2023 (UTC)

No, string ParserFunctions aren't enabled on any Wikimedia project as far as I know. The WMF devs explicitly ruled that out even before Lua/Scribunto became available a decade ago. Chuck Entz (talk) 04:53, 11 February 2023 (UTC)

Use function len from Module:string. Vriullop (talk) 19:41, 11 February 2023 (UTC)

Prettier userbox templates for scripts

I've improved the appearance of Babel userbox templates for scripts a bit:

Ж Cyrl This user's native script is the Cyrillic alphabet.

A Latn-0 This user cannot read the Latin alphabet.

繁 Hant-1 This user has a basic understanding of Traditional Chinese.

ש Hebr-2 This user has an intermediate understanding of the Hebrew script.

द Deva-3 This user has an advanced understanding of Devanagari.

か Hira-4 This user has a near-native understanding of Hiragana.

The ISO script name is now small enough to fit on one line, and the vertical spacing between the example character and the script ID looks nicer. Let me know if there are any unforeseen rendering issues. Tweenk (talk) 04:17, 11 February 2023 (UTC)

@Tweenk Thank you! Theknightwho (talk) 13:46, 11 February 2023 (UTC)

Specifying alternative forms in a single link

I just wanted to flag up that it's now possible to specify alternative forms in a single link by using the // delimiter. For example: {{m|en|color//colour}} will produce color／colour. The primary impetus for this was to lay the groundwork for displaying traditional/simplified Chinese with the standard link templates (which will mostly be automatic, but a manual delimiter is necessary for exceptions). However, I didn't see any reason not to enable this for all languages. It works in all link templates.

It supports multiple scripts (e.g. толь／ᠲᠣᠯᠢ (tolʹ)), though I haven't yet enabled multiple transliterations. There's also no limit on how many forms you can specify: a／b／c／d／e／f／g. If you want to use alt display text, then it works in the same way: {{l|en|color//colour|colorized//colourised}} will give colorized／colourised. If you only want to specify alt text for the first form, then just put {{l|en|color//colour|colorized}} (colorized／colour); if you only want to specify it for the second, then just put {{l|en|color//colour|//colourised}} (color／colourised), and so on. If you want to use [[]] links, then those work as well: {{m|en|he [[has]]//he [[hath]]}} (he has／he hath).

There is also a method for generating these automatically via a module (which is where this really comes into its own), but it's turned off for the moment. Theknightwho (talk) 08:08, 11 February 2023 (UTC)

So is it time to retire {{he-l}}? ―Biolongvistul (talk) 10:13, 11 February 2023 (UTC)

Like it in principle though the giant slash seems a bit OTT to me. —Al-Muqanna المقنع (talk) 11:23, 11 February 2023 (UTC)

In some browsers the slash is normal, in others it is very big and doesn't look good at all. Gorec (talk) 12:16, 11 February 2023 (UTC)

Yeah I can see it looks normal in Firefox, in Chrome/Opera and Edge it extends well beyond the line. The regular / or full-width solidus ／ might be preferable depending on script. —Al-Muqanna المقنع (talk) 12:30, 11 February 2023 (UTC)

@Al-Muqanna @Горец I didn't realise the slash would look so different between browsers. I've swapped it out for a bold, full-width solidus (which you should be able to see now). @Biolongvistul - that's the idea. It would be good to get more integration, because etymology sections can sometimes be a challenge when there's a large mix of templates. Theknightwho (talk) 13:34, 11 February 2023 (UTC)

@Theknightwho It looks nice now, but I noticed another problem. It is showing the transliteration of the 1st term only, for languages using the Cyrillic alphabet. Gorec (talk) 20:07, 11 February 2023 (UTC)

@Горец Yes - I haven't implemented that yet. The main concern I have is that it's not clear which of these layouts we should follow, as they each have advantages/disadvantages:

• толь (tolʹ)／ᠲᠣᠯᠢ (toli)
• толь／ᠲᠣᠯᠢ (tolʹ／toli)

Theknightwho (talk) 20:18, 11 February 2023 (UTC)

@Theknightwho I think the first layout is the better option. Gorec (talk) 21:04, 11 February 2023 (UTC)

I like the new functionality, I'm neutral on the ／ and I'm intrigued by the new // syntax. Are you familiar with the <key:value> notation that User:Benwing2 added to some templates like {{syn}}? I think both your // and his <> notations stem from the same limitations of the native template parameters, namely that {{tl|1|2|3|a1=|a2=|b2=|c3=}} gets complex when there are multiple keys with multiple possible attributes. It seems like <> is the most readable way of making sure keyX is easily identified as an attribute of numbered parameter X while // is a good way of putting multiple values in a numbered parameter. Combining both the // and the <> syntax you'd end up with something like {{l|en|color<alt:colorized>//colour<alt:colourised>}}. JeffDoozan (talk) 20:01, 11 February 2023 (UTC)

@JeffDoozan, Theknightwho I agree with Jeff here, once you've added the ability to specify multiple terms in a single link you have to worry about how to add manual transliterations, transcriptions, alt forms, sense ID's, etc. etc. to each term separately. You could potentially specify them the way you did with alt forms but IMO it's better to use the <...> syntax. This can be done fairly easily using the parse_inline_modifiers function in Module:parse utilities (or you could write your own function to parse the modifiers, see Module:columns for an early (and still working) implementation of this). Benwing2 (talk) 20:17, 11 February 2023 (UTC)

@JeffDoozan @Benwing2 I completely agree - the syntax Jeff suggests is much more intuitive. Later this evening, I'll put something on the BP about enabling automatic simplification + pinyin for Chinese using this method (as they're ready to go, but deprecating {{zh-l}} will need to be done with care). I'll tackle this once we know where we are with that. Theknightwho (talk) 20:24, 11 February 2023 (UTC)

@JeffDoozan @Benwing2 I haven't done the above suggestion yet, but on a related note I've introduced \ as an escape character. For example, {{l|zh|\// \//}} produces // //. In addition to any future feature involving < and >, there are two further features which I think should be escaped in a similar fashion:

1. ^, which capitalises the relevant letter in transliterations of scripts which don't have capitalisation (e.g. {{l|hi|^अंटार्कटिका}} gives अंटार्कटिका (Aṇṭārkaṭikā), {{l|hi|अंटा^र्कटिका}} gives अंटार्कटिका (aṇṭāRkaṭikā) etc.). This generally makes sense to use with proper nouns, and is a minor feature of {{zh-l}} that I felt was worth porting over (and which I extended to work in any position).
2. Using : at the start of a link currently prevents the removal of diacritics (because it forces the template to treat it as a raw link), which is necessary for entries like Latin &̄. It's also possible to do interwiki links, too (e.g. {{l|en|w:Germany}} gives Germany). Currently, this is disabled for a specified list of entries which start with a colon, but I think it'd be better to just use \ as an escape character, as there's every chance that list is out of date, and it means that links to entries with colons in the non-initial position won't get mucked up. I don't imagine these are common, but they are plausible. Theknightwho (talk) 21:34, 12 February 2023 (UTC)

Missing "term?" in der template output

A {{der}} invocation with missing source language term used to generate "[Term?]" in the output, but today I see only a space after the language name. "{{der|ota|fa}}. -> "From Persian .". If this was an intentional change the space needs to be suppressed. Vox Sciurorum (talk) 10:51, 11 February 2023 (UTC)

@Vox Sciurorum This was a bug caused by the the alternative forms feature in the section above. It's now fixed. Theknightwho (talk) 13:35, 11 February 2023 (UTC)

Pali Link Templates

Over in the Beer Parlour, in the section entitled "Deprecating_{{zh-l}}", @Theknightwho said, "Overall, though, it would be really good to start sweeping away these sorts of language-specific templates wherever possible, because they're often not written very well, and they lead to walled gardens of badly written modules that end up being massively inefficient and incompatible with everything else". While I've eschewed modules for fear of hitting memory limits, I fear I have ended up creating such a walled garden of templates for non-Roman script Pali.

For Wiktionary, the main writing system of Pali is the Roman script, in that the bulk of the information is stored under the Roman script, which is treated as a full writing system, befitting its status as the main script nowadays for the language. However, for some writing systems, this leads to a tension between transliteration and Roman script equivalence, most notably the Lao script system almost limited to the modern alphabetic repertoire for Lao. This leads to unique ambiguities, such as the identically spelt ທັມມະ (damma ⇨ dhamma, “dharma”) and ທັມມະ (damma, “in need of training”). There are also local spelling idiosyncrasies not generally reflected in Roman script Pali, such as the Burmese Pali သံဃ (saṃgha ⇨ saṅgha, “sangha”) and the more systematic Northern Thai Pali ᨾᩘᩈ (maṅsa ⇨ maṃsa, “flesh”).

When it is appropriate to reference Pali words in non-Roman forms, it would generally be nice to simultaneously link to the standard Roman script form. Now, there is a language setting that will make transliterations into links, but because of cases like these, I need an ability to switch such a link off in individual cases, and ideally to provide an alternative (as the bespoke Pali family does with |eqv=, which the reader can see as such. Adding such a facility to the standard family of linking templates and modules myself risks widespread corruption of the display of many pages, and I currently lack permission to make such fraught changes.

The most heavily used of these templates is {{pi-nr-inflection_of}}. An example of its use can be found in ວະລັງ#noun, where the headword line takes the form {{pi-noun form|tr=}} to force the display of the transliteration.

Does anyone feel up to implementing selective linking of transliterations and even redirection? Notifying @Benwing2, Octahedron80, Theknightwho. If it gets done, someone will need to tweak some of the Lao script inflection tables, initially perhaps just using the off-switch |showtr=none already provided in {{pi-decl-noun}} and {{pi-conj-special}}. --RichardW57 (talk) 10:38, 12 February 2023 (UTC)

accel-gender and accel-form

Hello! What is the proper way to implement the gender code "|accel-gender="?
I can't figure out which template it should be put in and where exactly. As an example, {{mk-decl-noun-m}} is the inflection template for masculine nouns, and {{mk-decl-noun-table}} is the main noun table template. Thank you in advance! Gorec (talk) 17:40, 13 February 2023 (UTC)

Also, none of the things I tried in {{Module:mk-headword}}, adding form = "comd" and form = "supd", create green links in the headword line for the comparative and superlative forms of Macedonian adverbs. Gorec (talk) 21:37, 13 February 2023 (UTC)

Pinging: @Benwing2, Rua, Theknightwho, Atitarev, JeffDoozan, Fenakhay, Chuck Entz, Erutuon, 70.172.194.25 Gorec (talk) 21:58, 13 February 2023 (UTC)

@Горец You should follow the example of another module that has accelerators in it, e.g. Module:es-headword. In your case you have to say something like comp.accel = {form = "comparative"} and sup.accel = {form = "superlative"} since there's special support for comparatives and superlatives in Module:accel. As for |accel-gender=, it needs to go in the link template. Benwing2 (talk) 23:45, 13 February 2023 (UTC)

@Benwing2 Thanks! I tried to find similar modules, but I didn't check the Spanish module. I have to use "comd" and "supd" because they generate {{head|mk|adverb form}}. For some reason "comparative" and "superlative" generate {{head|mk|comparative adverb}} and {{head|mk|superlative adverb}} respectively. Gorec (talk) 01:21, 14 February 2023 (UTC)

@Горец I think "comparative adverb" and "superlative adverb" should be correct; this is what we use for Russian, for example. Benwing2 (talk) 02:24, 14 February 2023 (UTC)

@Benwing2 I see. Then we can use that for Macedonian too. The definition line will be something like {{comparative of|mk|xxx|POS=adverb}}, right? I tested it, see "побогато", but there appeared some hidden category "comparative of/without nocat". Is this okay? Gorec (talk) 20:52, 14 February 2023 (UTC)

@Горец I removed those hidden categories; they were left over from some tracking long ago and aren't useful. Benwing2 (talk) 22:26, 15 February 2023 (UTC)

@Benwing2 Thanks. Superlative of/without nocat's categories should be removed too. Gorec (talk) 10:56, 16 February 2023 (UTC)

@Горец Removed. Benwing2 (talk) 03:29, 18 February 2023 (UTC)

Is there a way to add numbered footnotes to Latin declension tables?

It occurred to me that it would make sense for the footnotes in the Declension section of -a to have corresponding superscript numbers in the table itself (in the genitive plural, dative plural and ablative plural boxes). This is a feature supported by Module:la-nominal (as shown by e.g. the note at genius) but I'm not sure if there's any way to do it by passing parameters to the la-ndecl template ... I just see a single footnote parameter, but no option to add numbered footnotes that way. I know it's possible to put information in Module:la-noun/data, but is that a good idea in this case, or a hack to be avoided? Urszag (talk) 00:52, 15 February 2023 (UTC)

@Urszag I'm 99% sure this is possible. Let me take a look at the code. Benwing2 (talk) 22:24, 15 February 2023 (UTC)

Korean_terms_with_long_vowels_in_the_first_syllable

Terms are added to this category, even if the long vowel is on the first syllable. See Module_talk:ko-pron#Category:Korean_terms_with_long_vowels_in_the_first_syllable. Also Talk:원피스. Anatoli T. ^{(обсудить}/^вклад) 05:45, 15 February 2023 (UTC)

Emoticon problems

• ^_^: the alternative forms “^^” and “^.^” display as “[[#Translingual|]]” and “[[.#Translingual|.]]”.
• ^_^ and ( ͡° ͜ʖ ͡°) are sorted in Category:Translingual lemmas under “ ” (space) instead of “^” and “(”.
• (╯°□°）╯︵ ┻━┻ has a warning regarding the display title.
• @Theknightwho recently removed head and sort parameters from {{mul-symbol}} in emoticon entries. The problem is that, for example at Unsupported_titles/:-(, the head is “-(” (missing “:”) and it is sorted as “UNSUPPORTED TITLES/:-” (should be “:-(”).
• A related problem: the translingual usage example at Unsupported titles/Left curly bracket (sense 3) is, for some reason, in a different font.

J3133 (talk) 10:44, 15 February 2023 (UTC)

@J3133 This seems to have been an unexpected bug caused by some of the changes I made yesterday to Module:languages - I’m looking into it. Theknightwho (talk) 19:23, 15 February 2023 (UTC)

This is partially solved. Some of these are caused by the fact that certain script-specific characters are inappropriately triggering the use of certain script codes in Translingual (which is what was happening at (╯°□°）╯︵ ┻━┻, for instance). I suspect something similar is happening with the usage example at {. In those cases, they need to be overridden with sc=Zsym, though in the case of the usage example we may not want to do that, as it would affect the Latin text as well. Theknightwho (talk) 21:29, 15 February 2023 (UTC)

@Theknightwho: The head of Unsupported_titles/:-) is still “-)”. J3133 (talk) 09:08, 26 February 2023 (UTC)

List of provinces of Iran

This exists on some pages including Iranian provinces, like Semnan, but not all of them - in fact entries for some of the 31 provinces don't exist yet. I would like to edit it, as there are at least two spelling errors in it, but I can't find the source of the list. DonnanZ (talk) 10:36, 16 February 2023 (UTC)

@Donnanz See Template:list:provinces of Iran/en. Benwing2 (talk) 02:00, 17 February 2023 (UTC)

@Benwing2: Ah, a template. User:Atitarev got there first and made the corrections I wanted to make. Cheers. DonnanZ (talk) 10:15, 17 February 2023 (UTC)

Module Errors in Pali Inflection

@Chuck Entz Now that the Chakma script has been moved from experimental to supported for Pali, at least as defined by Module:languages/data2 (I haven't found the discussion yet), please hold off on hiding module errors in the Pali testcases. It may take a few hours to add full inflection support, and the test cases don't readily understand partial support for paradigm detection. --RichardW57m (talk) 15:55, 17 February 2023 (UTC)

@RichardW57m This may have been me jumping the gun. I made a start on migrating the data in Module:translit-redirect/data into the main language data modules yesterday (as the redirect module is no longer necessary, so is now just wasteful overhead). While doing this, I noticed that a Chakma transliteration module was defined for Pali, even though Chakma wasn’t listed as one of its scripts. I assumed that the latter was just an oversight, so added it to the list. Theknightwho (talk) 16:15, 17 February 2023 (UTC)

Well, I've now added two new pages in Module space (test module and its 'documentation' page) and three new autocatted categories. Not bad for a writing system for which we have two lemmas and one non-lemma, all in support of one prima facie word, tatrāyam. --RichardW57 (talk) 05:47, 18 February 2023 (UTC)

Full support for inflection has now been added for Chakma, at least for the spelling attested on one page of one book. I had some trouble with spelling the endings that needed recognising. --RichardW57m (talk) 09:35, 20 February 2023 (UTC)

No appropriate template for Declension of Unmarked Masculine Nouns for Gujarati?

I'm trying to add a declension table on the entry for ઘર, which is an unmarked masculine noun. I found these templates for Gujarati noun declensions: Category:Gujarati_noun_inflection-table_templates. I'm seeing templates for feminine words (-f), masculine words ending in a consonant or vowel (-m-c, -m-v), and neuter words ending in C/V (-n-c, -n-v). The other templates don't appear to be working.

However, all of those 5 templates appear to be for marked nouns, as they add the singular and plural markings which is not correct for ઘર. Compare with કૂતરો, which is a marked masculine noun and so the declension table on that page has the correct endings. Does anybody know if a correct template for unmarked nouns exists?

Alternatively, are there any resources that I could read if I wanted to create my own templates? How does somebody learn to do that?

Thank you! – Guitarmankev1 ^(talk) 21:58, 17 February 2023 (UTC)

Unfortunately, the user who created most of these templates (DerekWinters) hasn't edited in years. I don't think anyone who frequents this page is highly familiar with Gujarati. User:AryamanA and User:Svartava both claim some familiarity with either the Gujarati language or script on their respective user pages, and have edited these templates, so I'll ping them.

Anyway, it's quite possible that there just isn't a template for this declension class yet. If you want to make your own template, it would probably be a good idea to look at whichever existing template is closest, copy the code, and modify it as needed. People here can certainly help with that if you get stuck. 70.172.194.25 02:42, 18 February 2023 (UTC)

Just FYI, I created Module:hi-noun for Hindi noun declensions (and similarly Module:hi-verb and Module:hi-adjective). I think User:AryamanA's plan was to use this to create similar modules for other Indo-Aryan languages. I know he did this for Panjabi verbs (see Module:pa-verb). I don't know much at all about Gujarati but it shouldn't be all that hard to do this if you're fluent in Lua. Benwing2 (talk) 20:28, 18 February 2023 (UTC)

Cool, I'll see if I can copy one of the existing templates for marked nouns and modify it for unmarked nouns. At a brief glance that doesn't look too difficult. Although I'm still a little confused with Template pages in general - they seem to be laid out a little differently from normal entry pages. Sometimes when I navigate to one such as Template:cy-verb I'm not sure where to find the actual code, which makes me wonder if I'm really looking in the right spot on other templates which seem more obvious like Template:gu-noun-m-v. Maybe I'll take a read though Wiktionary:Templates first... Thanks! – Guitarmankev1 ^(talk) 15:15, 20 February 2023 (UTC)

Collapsing sections on the mobile site

@Vuccala, Surjection. This is a followup to Wiktionary:Information_desk/2023/February#Mobile_view_-_collapse_languages_by_default?, and probably a more appropriate venue.

I think the following, when added to MediaWiki:Mobile.js, might accomplish the goal of collapsing sections on entries with multiple languages:

mw.loader.using('skins.minerva.scripts', function() {
  if (mw.config.get('wgNamespaceNumber') === 0 && mw.config.get('wgAction') === 'view' && $('h2.collapsible-heading').length > 1) {
    $('h2.collapsible-heading').click();
  }
});

Unfortunately, I don't know how to test this to make sure the code will run at the right time (after the skin is loaded), so maybe someone could add this to their Special:MyPage/minerva.js, and then load a long page like o. If it doesn't work we'll have to come up with another hook to use. 70.172.194.25 00:40, 18 February 2023 (UTC)

It works! Thank you so much! – Vuccala ✿  21:03, 18 February 2023 (UTC)

@Benwing2, Surjection, Vuccala: Does this seem worth adding to MediaWiki:Mobile.js, so all our mobile users can benefit from it, and not just those who read this page? Also, if you have any suggestions for improvement, e.g. an alternative threshold for when to auto-collapse sections, let me know. (If this is added to MediaWiki:Mobile.js, Vuccala might have to remove it from their personal minerva.js, as the current implementation toggles the state.) 70.172.194.25 02:34, 20 February 2023 (UTC)

I don't use Wiktionary on mobile but anything to make the mobile experience suck less is worth it IMO. I'll wait a day and if no one objects I'll stick it in. Benwing2 (talk) 03:07, 20 February 2023 (UTC)

The snippet isn't good enough because it collapses all sections, even the section that is in the URL. For instance if you go to word#English, the English section is collapsed; and if you go to word#Etymology 1, the Etymology 1 section isn't visible. (At least some of the time. It seems like the code runs either before or after the code that snaps to the correct section and opens sections up. If it runs before, the sections are open; if it runs after, they are closed. At least this is my guess based on clicking a few links on my phone.) For language sections, it would be as simple as not collapsing the section heading if it matches the bit after # in the URL (in JavaScript, new URL(document.URL).hash.substring(1)). For sections nested underneath language sections, I'm not sure how to do it in a reasonable way. It might be best to post a Phabricator request and see if Wikimedia developers know how to fix it. — Eru·tuon 03:50, 20 February 2023 (UTC)

@Erutuon Great point, thanks for catching it. You’re right about how to proceed in cases where the URL hash matches an h2 heading. I think we could still work around other cases, though, by finding the element whose ID matches the URL hash, and excluding whichever h2 is found immediately before.

I suggested posting the original issue to Phabricator (see the ID thread). Apparently the WMF devs are already aware that the mobile experience is lacking, but they don’t care enough to invest resources in Wiktionary. 70.172.194.25 06:00, 20 February 2023 (UTC)

I agree that the devs don't invest that much effort in Wiktionary, but nobody proposed collapsing all but the active (or first, or user-selected) section in those issues, and so I think it's worth posting a request if we can agree on what we want. — Eru·tuon 06:16, 20 February 2023 (UTC)

Fair enough. In the meantime, I've implemented a workaround that seems to work (feel free to test further). 70.172.194.25 06:44, 20 February 2023 (UTC)

New code that addresses Erutuon's issue:

Extended content

mw.loader.using('skins.minerva.scripts', function() { if (mw.config.get('wgNamespaceNumber') === 0 && mw.config.get('wgAction') === 'view' && $('h2.collapsible-heading').length > 1) { var hash = location.hash.substring(1); if (hash) { var el = document.getElementById(hash); var all = $('*'); var index = all.index($(el)); var headers = $('h2.collapsible-heading'); for (var i = 0; i < headers.length; i++) { if (all.index($(headers[i])) < index && (i === headers.length-1 || all.index($(headers[i+1])) > index)) { // pass } else { $(headers[i]).click(); } } // https://stackoverflow.com/a/36033643 window.location.hash = ""; window.location.hash = hash; } else { $('h2.collapsible-heading').click(); } } });

70.172.194.25 06:44, 20 February 2023 (UTC)

The new version is even better, I'd be all for seeing it added to MediaWiki:Mobile.js to improve the mobile experience for everyone. One further idea: perhaps the English and Translingual definitions could always get opened by default so that the most-likely definition the average English-Wiktionary user came looking for is immediately readable without requiring any additional clicks. – Vuccala ✿  15:21, 23 February 2023 (UTC)

That would be simple to implement. Another idea could be to keep track of what languages the user has expanded using a cookie, and then keep those expanded by default in the future. If they collapse a section, it gets removed from their list of preferred languages. (English and Translingual could be the defaults.) What do you think of that? This idea might be overcomplicating things, but on the other hand it might actually be useful. 70.172.194.25 01:16, 24 February 2023 (UTC)

@Vuccala: Try this, maybe.

Extended content

mw.loader.using('skins.minerva.scripts', function() { if (mw.config.get('wgNamespaceNumber') !== 0 || mw.config.get('wgAction') !== 'view') { return; } var expandedLanguages = mw.storage.getObject('expandedLanguages') || { 'English': 1, 'Translingual': 1 }; $('h2.collapsible-heading').on('click', function() { var lang = $(this).find('.mw-headline').text(); if ($(this).hasClass('open-block')) { expandedLanguages[lang] = 1; } else { delete expandedLanguages[lang]; } mw.storage.setObject('expandedLanguages', expandedLanguages); }); if ($('h2.collapsible-heading').length <= 1) { return; } var hash = location.hash.substring(1); if (hash) { var el = document.getElementById(hash); var all = $('*'); var index = all.index($(el)); } var headers = $('h2.collapsible-heading'); for (var i = 0; i < headers.length; i++) { var lang = $(headers[i]).find('.mw-headline').text(); if (expandedLanguages.hasOwnProperty(lang)) { // pass } else if (hash && all.index($(headers[i])) < index && (i === headers.length - 1 || all.index($(headers[i + 1])) > index)) { // pass } else { $(headers[i]).click(); } } if (hash) { // https://stackoverflow.com/a/36033643 window.location.hash = ''; window.location.hash = hash; } });

70.172.194.25 05:41, 24 February 2023 (UTC)

The new addition of keeping track of which languages the user expands improves the mobile experience even more. Thank you! – Vuccala ✿  12:58, 24 February 2023 (UTC)

I'll put this code in, but first it should have a comment. IP 70.* can you write the appropriate comment at the top of the code explaining what it does? Benwing2 (talk) 02:12, 25 February 2023 (UTC)

zh-dial synonym box heading

On 字, the heading of the dialectal synonym box is "Dialectal synonyms of [[#Chinese|]]", i.e. the link is broken. 70.172.194.25 03:32, 20 February 2023 (UTC)

The link is generated at Module:zh-dial-syn#L-67, which uses full_link in Module:links. @theknightwho might know the reason behind this. – Wpi31 (talk) 07:44, 20 February 2023 (UTC)

@Wpi31 This was down to the strange decision to store a lack of information as an empty string in the synonym data modules. I've now accounted for that in Module:zh-dial-syn. Theknightwho (talk) 08:08, 20 February 2023 (UTC)

Gadget or plugin to make links in diffs clickable

On Wikipedia, whenever I view a diff, every link beginning with [ or [[, and every template beginning with {{ is a clickable link that will take me directly to whatever is on the left side of the link. I've never been able to do that here, and it surprises me that there isn't an obvious way to add that functionality to the diff view. To be honest, Im not sure what I did to get it working on Wikipedia, since there is nothing in my Preferences section that explicitly mentions making diff links clickable ... I can only say that it isnt WikEd or WikEdDiff, which would be the most obvious candidates, since even with WikEd turned off I still have clickable diff links.

Have people here just been copy-pasting all this time, or is there an easier way? Even if I have to load a plugin that does other things besides making the links clickable, I'd be willing to do it since I'm tired of the extra work. Thanks, —Soap— 07:33, 20 February 2023 (UTC)

@Soap: Can you send the full list of gadgets you have enabled on the English Wikipedia? 70.172.194.25 22:51, 23 February 2023 (UTC)

Yes, thanks.

• Require confirmation before performing rollback on mobile devices
• Navigation popups: article previews and editing functions pop up when hovering over links
• revisionjumper: quickly navigate between page revisions
• wikEd: alternative full-featured integrated text editor for Firefox, Safari, and Google Chrome (documentation)
• Add an [edit] link for the lead section of a page
• Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page (documentation)
• Display an assessment of an article's quality in its page header (documentation)
• SidebarTranslate: display sidebar language links in English
• Add a toolbox link to reload the current page with the system message names exposed
• Allow /16, /24 and /27 – /32 CIDR ranges on Special:Contributions forms, as well as wildcard prefix searches (e.g., "Splark*")

I skipped the ones with (D) next to the description because those are enabled for all users by default and can't be the reason why diffs are interactable. The obvious answer is that it's WikEd that's doing this, but I confirmed that the diffs are still clickable even after turning off WikEd. Popups is another obvious choice, and perhaps even though I also have popups enabled here some of the functions only work on Wikipedia. I suppose what I need to do is to go through each gadget manually turning them off one by one and see which one causes the behavior to stop working. I will post here after I do that. If none of them is the cause, then I'm confused but perhaps I have a snippet of code somewhere in my CSS or even JS file thats been there so long that I wouldn't recognize it. Thanks, —Soap— 07:16, 24 February 2023 (UTC)

Replying to confirm that after turning off WikEd, popups, and revisionjumper, I still have clickable diff links. I admit I didnt check the others, as I dont see how they could possibly be the answer. —Soap— 07:47, 24 February 2023 (UTC)

Another idea would be to disable all the gadgets at once and see if you still have it. If it goes away, then you can try checking them one by one.

I don't see anything obvious in your userspace JS pages that would definitively be the cause. Well, to be fair, you do have a copy of wikEd in your own userspace under the title wikBill.js, but it doesn't seem to be loaded from your skin.js or common.js files. You could try blanking that page and seeing if the behavior goes away. You don't happen to be using Tampermonkey/Greasemonkey or anything?

I also checked your userspace on Meta, but didn't see a global.js page (or any other JS page, for that matter). 70.172.194.25 21:20, 24 February 2023 (UTC)

Could someone explain the purpose of MediaWiki:Gadget-CodeLinks.js? I've had it enabled for a while now, but it doesn't do anything. Is there a way to use CodeLinks to make clickable links in diffs? If not, where are there supposed to be clickable links? Since it doesn't do anything in the edit window, nor on the live page, from what I can see. —Soap— 08:59, 24 February 2023 (UTC)

Did you read the documentation at the top? It adds links to syntax highlighted code. — Eru·tuon 09:06, 24 February 2023 (UTC)

Yes I did read the documentation, and i also read the announcement back in 2019 when the gadget was introduced. I simply dont understand it, since I dont see any screen in which the gadget actually turns on ... neither when viewing a live page, nor when editing, nor when viewing diffs. —Soap— 10:17, 24 February 2023 (UTC)

Actually, I see it now .... the gadget works on Module:zh but not on Module:zh/data/glosses. I dont know the pattern, but Im sure there's a switch somewhere that turns on "code view" that makes the gadget work on some pages and not others. At least I know what it looks like now. In theory this could be retooled in order to work on diff view as well, right? But it's beyond my skill level. And Im still surprised that given all the people who work with templates here, every single one of them is just manually copypasting everything every time. Unless there's something else entirely different that I dont know about, maybe an external editor of some sort. —Soap— 10:42, 24 February 2023 (UTC)

That's because the MediaWiki software decides not to syntax-highlight Module:zh/data/glosses (because it's too big or syntax highlighting timed out or something). The gadget only works on syntax-highlighted code. — Eru·tuon 05:39, 26 February 2023 (UTC)

I am sitll interested in this, but i mostly use the monthly pages for browsing the discussion forums, so i keep forgetting this exists. Im still puzzled that we're all wasting so much time by manually typing in the links and template names, or even copy-pasting, instead of just clicking them from the source and diff views. I havent done the experiment involving disablijng all the plugins at once on Wikipedia because I dont see how it would behave differently than disabling them one at a time, but i will get to that when i have free time. i just need ot screenshot the display windows first so i know what to re-enable later. —Soap— 09:21, 10 March 2023 (UTC)

Im not skilled with code, but I guess Im just going to figure this out myself, and maybe once i figure it out someone will actually start using the code i find. —Soap— 10:29, 11 March 2023 (UTC)

It might be w:User:Cacycle/diff.js, which is related to WikEd, but not part of WikEd specifically. But as you pointed out above, I dont actually have a custom .JS page, so it must be running itself through WikEd, yet somehow it still works even when WikEd is off. Im still puzzled, but not giving up. —Soap— 20:43, 17 March 2023 (UTC)

Problem with Tagalog headwords

@Theknightwho there seems to be some issue with Tagalog headwords. if it has multiple words, there are no longer any spaces. seems to be due to some recent module edit: tried to trace it to the main Tagalog headword template, but seems to be some module edit elsewhere. TagaSanPedroAko (talk) 18:50, 20 February 2023 (UTC)

looks like it's now fixed, see apo sa tuhod and sa kabilang banda.

TagaSanPedroAko (talk) 18:52, 20 February 2023 (UTC)

Small addition to MediaWiki:Common.css

The stylesheet includes "Hirmos Unicode TT" for Old Cyrillic (line 1122). Can "Ponomar Unicode TT", the newer name for the same font, also be added? Biolongvistul (talk) 08:55, 22 February 2023 (UTC)

Category:LANG gerunds

@Benwing2, (Notifying AryamanA, Bhagadatta, Svartava, JohnC5, Kutchkutch, Inqilābī, Getsnoopy, Rishabhbhat): Is there any way to make the description of this type of category significantly sensitive to the language? The current description, "LANG verbs that are conjugated to indicate ongoing events at unspecified moments", while close to appropriate for a Slavic language, is quite wrong for both English and Sanskrit. In English, a gerund may naturally be the key element of a of a noun phrase, whereas in Sanskrit it is the key element of a clause, as in Slavic. In both English and Sanskrit, the 'gerund' can refer to punctual events. --RichardW57 (talk) 18:20, 22 February 2023 (UTC)

@RichardW57 I added support to the poscatboiler system so the description (and other strings) can be made per-language by using a function in place of a raw string. Can you give me appropriate text to use for the various languages (e.g. "language X, Y, Z [or all languages in such-and-such a family, or whatever] should read 'foo'; language A, B, C, D should read 'bar'; otherwise 'baz'" or similar). Benwing2 (talk) 21:10, 22 February 2023 (UTC)

I'll work on a first draft, but we should probably allow editor communities (or the sole concerned editor, as appropriate) to easily refine them. It's clear that not all languages with gerunds are currently categorising them as such - I can think of multiple reasons:

• They simply haven't happened to emerge from inflection tables;
• They're also called something else, e.g. 'absolutive' for Pali, a synonym also used in Sanskrit grammars, and 'adverbial participles' for Russian;
• A delusion* that it is better to use {{inflection of}} than more bespoke form-of templates

I'm not sure that the concepts are sufficiently basic for there to be a few 'universal' descriptions. Accordingly, we probably need some sort of edit button to ease amendment of the definition.

*Or are definitions such as "{{inflection of|...}}, which is {{inflection of|...}}" deprecated? Some languages have inflected gerunds. I worry about being able to train myself to only use the categorising form in place of the first occurrence of {{inflection of}}. --RichardW57m (talk) 11:40, 23 February 2023 (UTC)

Albanian, Northern Kurdish, Livonian, Germanic (family) and Italic (family, including Romance) should have,

"LANG forms that generally act as a noun denoting the action denoted by the verb they are formed from."

Sanskrit and Pali should have,

"LANG verb forms used in a clause to indicate a prior action by the subject of the sentence."

The current default seems to be more or less OK for Cebuano, and I cannot find any information on Avar or Farefare. @Ayindolmah, M. Omarius.

"Prior" can encompass concepts of necessity, as in working in order to eat. --RichardW57m (talk) 14:48, 23 February 2023 (UTC)

These descriptions should all be easy for editors to improve. --RichardW57m (talk) 14:48, 23 February 2023 (UTC)

I've implemented these changes (with some slight improvements to the descriptive text) in Module:category tree/poscatboiler/data/non-lemma forms. --RichardW57 (talk) 03:01, 24 February 2023 (UTC)

@RichardW57 Thanks. I updated the function to handle Category:Gerunds by language (where 'data.lang' is nil) and use some new functions I just wrote in Module:language-like to simplify looking for families. Benwing2 (talk) 03:54, 24 February 2023 (UTC)

I'm a bit uneasy about having the selection of the description in code rather than tables. We may come to have problems with the wrong condition being the first one satisfied. One thing I liked about my code was that the wording for the smallest including family with wording would be selected. --RichardW57m (talk) 12:38, 24 February 2023 (UTC)

Can there any any valid categories besides Category:Gerunds by language for which data.lang may be nil? The wording for this umbrella(?) category should be closer to the glossary text (Appendix:Glossary#gerund), but that text is not really appropriate for any specific language. --RichardW57m (talk) 12:38, 24 February 2023 (UTC)

@RichardW57 data.lang is nil only for the umbrella category Category:Gerunds by language. Feel free to rewrite the code however you want. Benwing2 (talk) 02:08, 25 February 2023 (UTC)

Table width

Probably a noob question, but I’ve never been good at formatting tables in Wiki code. So I copy-pasted most of the code of the {{sw-conj}} table infrastructure to create a new version, see here, but for some reason the tables insist on being as wide as the screen. In the old version that was okay, as that was often still too narrow for all the forms, but in the new version that’s overkill and leads to tons of useless whitespace. How do I let the tables just have the width needed to show the content and no wider? Thanks! MuDavid 栘𩿠 (talk) 02:47, 23 February 2023 (UTC)

Fenakhay already proposed a solution, which makes the tables fixed-width. It’s good enough, so I’m going to roll out the new tables, but I’m left wondering why the tables can’t be just wide enough for their content, as for example Dutch verb conjugation tables. MuDavid 栘𩿠 (talk) 02:21, 1 March 2023 (UTC)

Edit incorrectly identified as harmful.

Tried to add a citation to the Citations page at uttering, following the guidelines (albeit with manual styling, rather than a template.

EDIT:

1. • 1875, George Hayter Chubb, Protection from fire and thieves including the construction of locks, safes, strong-rooms, and fireproof buildings : burglary, and the means of preventing it; fire, its detection, prevention, and extinction; etc. : also a complete list of patents for locks and safes, [1], page 23:

     A man named Edward Agar was convicted in October 1855 of uttering a forged cheque, and sentenced to be transported for life.

EDIT SUMMARY:
Putting into circulation —DIV

—DIV (1.145.64.48 11:26, 23 February 2023 (UTC))

The initial 'warning' said it was autodetected as harmful, but if incorrectly then

1. report it to Grease Pit, and
2. resubmit.

Having done these things (without making any amendment), I got a new 'warning':

This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: various specific spammer habits

I am rather surprised about this because:

• the link is to a well known legitimate source;
• I added very similar content without any problem to the Citations page at trumpery; and
• I followed the instruction in the original 'warning'.

Note: I was originally going to add the citation to the Citations page at utter, but then decided uttering was most apt.

—DIV (1.145.64.48 11:32, 23 February 2023 (UTC))

I added it for you - I added it for - I'm fairly certain it's because you are an IP trying to add a link. Vininn126 (talk) 11:34, 23 February 2023 (UTC)

Thanks for adding it.

That idea about using an IP 'account' is a good suggestion, but I doubt that it is the full explanation. I always use an IP address to edit, and after — I guess — hundreds of (smallish) edits I almost never have any problem. Moreover, it didn't pose any problem in the case of trumpery. (Admittedly, it was a different IP address, but I doubt that was the issue — it's certainly not the inference I take from the 'warning' message.

Speculation: maybe spammers often use people's names in their fake citations?

For example, I can well imagine that entries like arsehole would attract spam edits like "Mr. Croberz from Springfeel High School is an arsehole" (fictional names!).

—DIV (1.145.64.48 11:41, 23 February 2023 (UTC))

Post script...

I notice you added to the entry for uttering itself, rather than the Citations page (as I was trying to do). My inclination was driven by hesitation to edit the article unnecessarily, probably wrongly swayed by seeing that utter already had several quotations within the entry (and, besides which, I would have guessed that the article would be a much bigger target for spammers because — realistically — who really looks at the Citations pages anyway?!), but upon review of the entry I agree that it was appropriate to add it directly there.

Thanks again,

DIV 1.145.64.48 11:47, 23 February 2023 (UTC)

Incidentally, I think the quotation is actually for the verb utter and not strictly speaking the noun uttering, due to the presence of a direct object. 70.172.194.25 22:38, 23 February 2023 (UTC)

Yes, I agree. This issue of verb versus noun appears to have been fixed in the meanwhile. —DIV (1.145.32.254 13:02, 6 March 2023 (UTC))

Gujarati templates requiring cleanup

A number of the Gujarati templates need cleanup. Some like {{gu-decl-noun-m}} are unused and were admitted to be made by mistake by their creator back in 2016.

Others like {{gu-noun-m-v}} are for marked masculine noun roots ending with vowels, which doesn't seem possible since all marked noun roots end in consonants. This means that {{gu-noun-m-c}} could be simplified to just {{gu-noun-m}}.

Also, for some reason the {{gu-noun-f}} template takes the entire word as an argument instead of just the root (which is the case for the equivalent -m, -n templates). This is probably because the feminine ending appears in all endings, but it's still incongruent with the other gender templates. That is, છોકરો (chokro), છોકરી (chokrī), and છોકરું (chokrũ) are all the same root word with 3 different gender endings, so ideally their templates should all take the same root as an argument.– Guitarmankev1 ^(talk) 15:37, 23 February 2023 (UTC)

Do attempt to discuss this with other editors first. I can see a conflicting improvement of {{gu-noun-f}} - replace {{{1}}} by {{{1|{{PAGENAME}}}}}. One can then mostly simplify invocations such as {{gu-noun-f|...}} to {{gu-noun-f}}. Also, how would your proposal work with ઊધઈ (ūdhaī) and જીવનસંધ્યા (jīvansandhyā)? --RichardW57m (talk) 16:49, 23 February 2023 (UTC)

Hi @RichardW57m, thanks for the response. I definitely want to discuss before making any major changes. I like your idea to use the pagename reference in {{gu-noun-f}}, since all existing pages which include the argument will be left unaffected. It still feels strange having one of the three marked noun templates working differently from the others, but it might be preferable to have a template not require an argument where possible...?

As for ઊધઈ (ūdhaī) and જીવનસંધ્યા (jīvansandhyā), I'd suggest those entries should use the {{gu-noun-um-v}} template, since they are unmarked nouns ending in vowels, like ભાષા (bhāṣā). I see now that the declension tables for marked feminine nouns and unmarked nouns ending in vowels actually turn out the same, but wouldn't it be confusing if they were to be called the same thing? જીવનસંધ્યા (jīvansandhyā) isn't feminine, so it might seem strange to use the {{gu-noun-f}} template. Would it be preferable to have only 1 template, or two similar templates clearly titled for their context? For clarity, I want to mention that the table for unmarked nouns ending in consonants would not be identical to the table for marked feminine nouns, since different symbols would be used. Hopefully I'm not being too confusing, I can go into more detail here if I need to.

Additionally, I'm also noticing that the current naming conventions somewhat violate what is laid out in WT:Templates, but I don't know how strictly that must be adhered to... I just want to limit the confusion of that other people looking at this in the future. – Guitarmankev1 ^(talk) 18:47, 23 February 2023 (UTC)

I would be inclined to have two different templates for use on main space pages, and then have one invoke the other. I work with a different system, rooted in {{pi-decl-noun}}, which starts with citation forms (which are stems) and then uses modules written in Lua to remove final vowels to make way for endings. A data file for the declensions can be seen at Module:pi-decl/noun/Latn. This system has been adopted for Prakrit. Sanskrit declension uses a more complex system also written in Lua - it has to deal with strong and weak stems, and assimilations at a distance. RichardW57m (talk) 13:14, 24 February 2023 (UTC)

I like that idea of one template invoking the other. Do you have links to those modules? That might make things much more simplified for the Gujarati marked masc/neut noun templates, removing the need to place the root in the argument, instead just referencing the pagename and removing the predictable ending. – Guitarmankev1 ^(talk) 15:02, 24 February 2023 (UTC)

Pali: {{pi-decl-noun}} and Module:pi-decl/noun.

Prakrit: {{pmh-decl-noun}} and friends and Module:pra-decl/noun.

Sanskrit: {{sa-decl-noun-m}} and friends and Module:sa-decl.

Most of the template families are best found by starting at category LANG templates and working down the template hierarchy, e.g. to Category:Prakrit inflection-table templates. There is clutter of old, very simple templates that don't use modules. --RichardW57 (talk) 09:02, 25 February 2023 (UTC)

Also circling back to another point, I'm still unsure the best way to resolve the template names... The title for {{gu-noun-f}} makes it look like a headword template, and should probably instead be titled {{gu-decl-noun-f}}. However the {{gu-decl-noun-f}} that already exists is a table template and should be titled {{gu-decl-noun-table-f}} or something like that. There are quite a few templates (almost all of them) have these problems. The ideal state of the Guju template titles isn't too difficult to figure out per WT:Templates, but I'm not sure what the best pathway there is. Any thoughts on that? – Guitarmankev1 ^(talk) 15:02, 24 February 2023 (UTC)

At the moment I've identified 5 templates which should be removed, 3 templates with titles that should be changed, and 1 template I want to change how it works. And I've only started taking a look at these and I haven't looked at other parts of speech yet so there's a good chance there will be more to uncover. Is it possible for me to remove unused templates and rename poorly-named existing templates? Some of those existng templates are used in quite a few entries, but I'm not sure how to make a bot to do all that automatically - that would be super helpful so I don't have to go through >300 entries manually. Would I be able to make a bot to do changes like that? I think all that requires special permissions... Thanks! – Guitarmankev1 ^(talk) 15:37, 23 February 2023 (UTC)

For renaming, one can just rename, making sure the documentation pages also get renamed. The old template page will then automatically redirect, the pages remain current, and other editors don't have to learn new names immediately. --RichardW57m (talk) 16:49, 23 February 2023 (UTC)

Thanks, that's good to know. – Guitarmankev1 ^(talk) 18:51, 23 February 2023 (UTC)

ancient greek pronunciation template

hi there is a problem with the ancient greek pronunciation template/box all entries containing ζητα are have [z] as the 5th century BC pronunciation instead of the reconstructed [zd] how can this be fixed??? its as if by some glitch every single entry with a ζητα has had its IPA pronunciation changed. ζητα intervocalically must be divided between syllables but only in the 5th century attic pronunciation, not later pronunciations, it is impossible to edit any page to correct this as it always results in the incorrect koine and medieval greek pronunciation. what happened? L0ngh3nry89 (talk) 19:41, 23 February 2023 (UTC)

Don't know enough to comment on the topic but this was introduced by @Ἀττικός at diff; @Mahagaja reverted some of those changes but not this particular one. —Al-Muqanna المقنع (talk) 20:18, 23 February 2023 (UTC)

this is immensely frustrating as it looks like this user took it upon himself/herself to edit the entire template - with erroneous results. a single user should not have this power L0ngh3nry89 (talk) 20:43, 23 February 2023 (UTC)

I don't know if the change is correct, but it was proposed in this discussion on Module talk:grc-pronunciation and it would be best to discuss it there. — Eru·tuon 21:20, 23 February 2023 (UTC)

Translation adder bugfixes

The translation adder gadget can now find the correct table in most cases even when the targeted translations gadget puts some of the translations in the header. The gadget was using the text of the header to get the gloss, and then searched for a {{trans-top}} template in the wikitext that contains that gloss. The gloss didn't match the wikitext because it contained the  -  that the targeted translations gadget added. Now the gadget uses the data-gloss="..." attribute in the translation table (see the source code of {{trans-top}}), which is not changed by the targeted translations gadget and should match the wikitext in most cases.

I also fixed the bug where {{multitrans|data={{trans-top|...}} would prevent the gadget from finding the translation table gloss in the wikitext. It was finding the {{ and skipping immediately to the }} at the end of the {{trans-top}}, which made it skip over the gloss. Now it does the skipping with most templates, but not {{multitrans}}. So {{trans-top|...}}{{multitrans|data= can be changed to {{multitrans|data={{trans-top|...}} without breaking the gadget. — Eru·tuon 08:46, 26 February 2023 (UTC)

@Erutuon: thanks! Any chance you can update the adder so that (1) it’s possible to indicate “?” when the gender of a term is unknown, and (2) the literal meaning of a term can be added (equivalent to adding |lit= to the template)? — Sgconlaw (talk) 13:03, 26 February 2023 (UTC)

If the capability to specify unknown gender is added, this needs to be handled with great care. Many users will assume that it is an option they should select if they don't know the gender of the translation, when it really should only be used in the very rare instance that nobody knows the gender of the translation. @Sgconlaw surely unknown-gender translations are exceedingly rare? Wouldn't the time spent cleaning up after the misuse of such an option outweigh any time savings gained by its correct use? This, that and the other (talk) 05:45, 28 February 2023 (UTC)

@Sgconlaw: I've added the literal translation, if I did it right. I'm not familiar with the rationale for adding the ? gender to translations. It would need to be added to [MediaWiki:Gadget-TranslationAdder.js]] and to the gender list for specific languages in MediaWiki:Gadget-TranslationAdder-Data.js. If people agree on which languages should have this gender, I could work on adding it. — Eru·tuon 07:07, 28 February 2023 (UTC)

@Erutuon: thanks! The “?” is for indicating that the gender of a word is currently unknown so that other editors who are familiar with the language can add it. I don’t know how useful it is, but I have encountered one incident where another editor said I should use this parameter value. However, it’s inconvenient to add at the moment because it can’t be inserted using the adder but has to be inserted manually. (Also, you have to know whether the language in question has gendered nouns, which is another problem altogether …) — Sgconlaw (talk) 20:07, 28 February 2023 (UTC)

@This, that and the other: ah, I’ve just seen your comment which I missed just now. Looks like I (and that other editor) both misunderstood what the “?” parameter value is for. In my defence, though, neither “Wiktionary:Translations” nor {{t}} explains its use. — Sgconlaw (talk) 20:15, 28 February 2023 (UTC)

@Sgconlaw, This, that and the other: It looks like Sgconlaw was right because Module:gender and number/data says "gender incomplete" for ?. ?! is "gender unattested", which sounds more like what TTATO is describing. I guess ? could be added to all the languages that have any genders in MediaWiki:Gadget-TranslationAdder-Data.js, and the translation adder should not add both ? and another gender. — Eru·tuon 21:20, 28 February 2023 (UTC)

Ah, OK, so maybe I wasn't wrong. In any case, we should document the meaning of "?" and "?!" somewhere, perhaps at both "Wiktionary:Translations" and at {{t}}, {{t+}}, and {{t-needed}}. — Sgconlaw (talk) 22:22, 28 February 2023 (UTC)

The ?! option was a very recent addition FWIW. —Al-Muqanna المقنع (talk) 22:41, 28 February 2023 (UTC)

@Sgconlaw, @Erutuon whoops! Sorry for the confusion. Yes, we shouldn't have to look in a data module to understand what these flags mean. It should be documented at least at {{g}}, and maybe {{t}} and friends too. This, that and the other (talk) 00:15, 1 March 2023 (UTC)

What there is of documentation is in Module:gender and number/data and in the tooltip when you use the code. I guess it would be useful to print it out somewhere. — Eru·tuon 22:15, 1 March 2023 (UTC)

@Sgconlaw, Erutuon, This, that and the other, Al-Muqanna I added full documentation of the current gender/number codes and categories to Module:gender and number/documentation. Feel free to refer the documentation of any template with a gender/number param to Module:gender and number. Benwing2 (talk) 01:30, 4 March 2023 (UTC)

Thanks! — Sgconlaw (talk) 04:44, 4 March 2023 (UTC)

Template:trans-top-also stopped working

Error: Could not find translation table for ****. Glosses should be unique. Anatoli T. ^{(обсудить}/^вклад) 11:45, 26 February 2023 (UTC)

It's working on my side, but I've been getting this error message now and then when trying to add translations with the translation adder. PUC – 11:48, 26 February 2023 (UTC)

@Atitarev: Can you tell me which translation table on which page gave you this error? I clicked "preview translation" in the "to disclaim and expel from family" {{trans-top-also}} box and it successfully popped up the "page editing" box with no errors. — Eru·tuon 19:56, 26 February 2023 (UTC)

@Erutuon: diff. PUC – 20:15, 26 February 2023 (UTC)

Thanks. I looked at my JavaScript setup and found I was running an old version of the gadget. The latest version doesn't find the translation table in cube sugar when I click "Preview translation". — Eru·tuon 21:06, 26 February 2023 (UTC)

It should be fixed now. I broke the (unclear and weird) way in which the gadget used to find glosses in {{trans-top-also}}. It used to basically delete the template syntax around the gloss in the line of wikitext containing {{trans-top}}, but not delete it in {{trans-top-also}}. The new version grabs the parameters inside any template starting with trans-top. Not perfect, but hopefully it works in most cases. Maybe it needs testing by grabbing all {{trans-top}} and {{trans-top-also}} and running the code on them and seeing if it works. — Eru·tuon 21:36, 26 February 2023 (UTC)

Belarusian in Roman script is being transliterated again (it shouldn't)

E.g. Bieraście at Brest#Etymology_2. Anatoli T. ^{(обсудить}/^вклад) 11:47, 26 February 2023 (UTC)

@Atitarev Belarusian didn't have Latin listed as one of its scripts - it now does, which has solved the issue. Nevertheless, it shouldn't have been returning a transliteration anyway, so I'll investigate. Theknightwho (talk) 12:40, 26 February 2023 (UTC)

Going forward, this is solved. Languages won't try to transliterate terms that are in scripts that they don't have (whether it's Latin or anything else). Previously, languages with only 1 script would always assume terms were in that script no matter what, which meant that "Bieraście" was being wrongly recognised as Cyrillic (and therefore got passed onto the transliteration module). Theknightwho (talk) 13:05, 26 February 2023 (UTC)

Does this mean we no longer have a half-way house, whereby we can transliterate a script for a language without treating it as one of the languages of the script? I'm not sure it won't break the incremental support of an additional script, either. --RichardW57m (talk) 16:00, 28 February 2023 (UTC)

I’m not sure it makes sense for a language to be able to transliterate scripts it doesn’t have. Any testing should be done in a testing environment before being rolled out in mainspace. Theknightwho (talk) 16:40, 28 February 2023 (UTC)

As a matter of principle then, please add Arabic to the scripts of Russian. --RichardW57 (talk) 08:41, 1 March 2023 (UTC)

@RichardW57: Re: "please add Arabic to the scripts of Russian". Was this a joke? I don't get it. Anatoli T. ^{(обсудить}/^вклад) 05:27, 2 March 2023 (UTC)

Some group of Turks switched to speaking Russian, but continued to write using the Arabic script. It was presented as a language identification challenge in a game on the Zompist Bulletin Board. Documents from this hybrid stage survive. I am not in any hurry to start documenting their words, but someone may do so some day. --RichardW57 (talk) 08:23, 2 March 2023 (UTC)

@RichardW57: I see what you mean. You're opposing the use of Latin script for Belarusian. It's attested but not heavily. The site with poems in Belarusian in dual script (Cyrillic and Roman) seems to be broken - [2].

łacinka examples: https://m.nashaniva.com/be_latn/articles/307551/comments/ Anatoli T. ^{(обсудить}/^вклад) 10:42, 2 March 2023 (UTC)

@RichardW57: This is a better example - the same text in both scripts:

• łacinka (Latin): https://lacinka.teksty.seveleu.com/post/рабіна/
• кірыліца (Cyrillic): https://teksty.seveleu.com/post/рабіна/

You can click and view many more. Anatoli T. ^{(обсудить}/^вклад) 10:47, 2 March 2023 (UTC)

Hmm, I just noticed the last site I mentioned is not a traditional łacinka (the one before, is). These texts are based on standard (i.e. government) Belarusian romanisation, similar but not the same. In any case, I am not suggesting to make entry romanised Belarusian. --Anatoli T. ^{(обсудить}/^вклад) 10:54, 2 March 2023 (UTC)

Arabic script for Belarussian should be legit, but only for the Tatar dialect. It is the script of the old books of the Lithuanian Tatars from Belarussia, who used a dialectal variation of Belarussian (or Russian?), and a special spelling. Anyway, there are some very old (I mean, dead) guys who came with a definition of that language as a variant of Belarussian, not Russian and not a separate language. (I remember only name of Сержпутовский, but he was not alone on this question) Tollef Salemann (talk) 06:05, 3 March 2023 (UTC)

@RichardW57: someone may do so some day - yes, I actually had a plan to do it some day with the Tatar Arabic Belarussian, but I need to find some more reliable sources and learn me some better arabic letters. Anyway, it's weird to use Arabic for Belarussian, so I ain't sure if it is a good idea at all (maybe someone gonna be against it). Tollef Salemann (talk) 06:18, 3 March 2023 (UTC)

Adding a script can result in a large set of modules to roll out at one time. Most Sanskrit scripts aren't fully supported - I as yet haven't seen any non-Roman non-Devanagari inflexion tables for Sanskrit. --RichardW57 (talk) 08:41, 1 March 2023 (UTC)

@RichardW57 Why would adding a script require a large number of modules? That suggests a lot of unnecessary duplication is involved, and has never been necessary in my experience.

If you want to add the Arabic script for Russian, then I suggest you bring that up in the Beer Parlour. I imagine a number of editors will want to comment on that. Theknightwho (talk) 04:33, 2 March 2023 (UTC)

A quick list of what would probably need changing for Pali:

1. Module:languages/data/2
2. Some to Roman transliteration module (e.g. Module:si-translit)
3. Its testcases
4. Module:pi-Latn-translit
5. Module:pi-Latn-translit/testcases
6. Module:pi-decl/noun
7. Module:pi-decl/noun/testcases
8. Module:pi-decl/noun/testcases/documentation
9. Module:pi-conj/verb
10. Module:pi-conj/verb/testcases/documentation
11. Template:pi-sc

New items:

1. Analogue of Module:pi-decl/noun/Cakm/testcases
2. Analogue of Module:pi-decl/noun/Cakm/testcases/documentation
3. Analogue of Module:pi-conj/verb/testcases/Cakm
4. Analogue of Module:pi-conj/verb/testcases/Cakm/documentation
5. Analogue of Module:pi-decl/noun/Cakm (Might be able to eliminate this trivial module, though its probably not worth the effort.)

RichardW57 (talk) 06:19, 2 March 2023 (UTC)

@RichardW57: What do you mean by incremental support of an additional script? — Eru·tuon 22:11, 1 March 2023 (UTC)

In Pali, there are several steps to adding a script:

1. Automatic transliteration from it (historically, this was the last of these added to Pali).
2. Conversion from Roman script to the script, used by {{pi-alt}} to generate a list of forms in non-Roman scripts, in verb inflection, and optionally (but my preference) in noun inflection.
3. Recognition and labelling of a script - {{pi-sc}}, which was largely automated by Svartava, but which Octahedron80 wants to complicate so as to record the writing system, which is beyond the generic automation tools.
4. Generation of inflection tables. Transliteration both ways can do most of the heavy work if transliteration each way has been added, but there can be complications each way if there are multiple writing systems in a script, as for the Thai, Lao and Burmese scripts. Automatic recognition of endings is added manually.
5. Sorting properties

These can be added one by one, without breaking other functionality and without bots. For some writing systems, some of these features are currently significantly dependent on manual overrides. --RichardW57 (talk) 05:17, 2 March 2023 (UTC)

@RichardW57 Which are currently dependent on manual overrides? Those should be avoided, as they are liable to cause issues if they're dependent on something in the main modules that then changes. That's why centralisation is so important with things like this. Theknightwho (talk) 05:23, 2 March 2023 (UTC)

1. Automatic transliteration cannot resolve ambiguous forms, which occur in the Thai and Lao scripts, the poster example being สุตวา (sutavā), which in the alphabetic writing system is actually sutvā, a different form from the same verb. If the transliterator can't detect the writing system, it defaults to the abugidic writing system. In inflection tables, the transliterator is told the writing system selections passed to the table generator, and I've only had to use manual transliteration override (|subst=) in inflection tables for the grossly irregular ᨾᩉᩣᨻ᩠ᨵᩮᩥᩣ (mahābodhi).
   1. Some Lao writing systems are themselves ambiguous as to what the corresponding Roman form is, for which the poster example is ທັມມະ (damma), which corresponds to both damma and dhamma.
   2. There are also forms where the transliteration and standard Roman form are at variance, for example သံဃ (saṃgha ⇨ saṅgha) and ᨾᩘᩈ (maṅsa ⇨ maṃsa).
2. Conversion to non-Roman scripts runs the risk of over-generation. We lack sound knowledge of the allowed combinations for the various schemes for writing <p>, <bb>, <mm>, <ṃ> and <ā> in the Lanna script, but stick to well-known combinations and add other variants as we encounter them. The same applies to Lao, but I intend to automate the Lao repertoire Lao script writing systems.
3. Script recognition works. Writing system recognition has not been implemented, and I prefer not to bother with tagging terms for writing system. There is no community consensus on whether to do it, and the Lao writing systems are a mess.
4. Inflection tables need a manual override for exceptions. Morphologically, Pali has a been described as a language of exceptions. We currently treat ablative singulars in -to as exceptions, but some grammars treat them as regular. Lao repertoire Lao script forms with consonant clusters are currently done manually; I intend to implement their automatic inclusion. The selection of writing systems for automated Lao script inflection is currently done manually. The selection of round v. tall <ā> for Tai Tham inflections is currently often done manually using |aa=. --RichardW57 (talk) 08:09, 2 March 2023 (UTC)

   Myanmar script minority Pali systems need further work on their declension, though I feel we really ought to have some decent samples from these systems before implementing them. (We have contradictory information on how -iṃ is written in Mon Pali.)

   1. Mon Pali:
      1. Mon Pali needs manual overrides for the plural of masculine and neuter i-stems.
      2. Mon Pali feminine i-stems can be implemented by declining them as ī-stems and overriding the nominative and accusative singular, e.g. အင်္ဂုလိ (aṅguli).
      3. Mon Pali in-stems need to be declined as ī-stems (this uses |stem= and |label=).
      4. Thai Mon Pali needs manual overrides for the genitive and dative singular of masculine and neuter nouns.
   2. Shan Pali:
      1. Shan Pali needs manual override for every ending in ā except for the feminines in -ā. On the other hand, I don't think we have any Pali terms with an explicitly Shan spelling.
      2. Genitive and dative singulars of masculine and neuter Shan Pali nouns and 2s imperative middles of Shan Pali verbs need a manual override and sometimes a new Unicode character 'MYANMAR LETTER SHAN PALI GREAT SA'.

   I can see how to implement all these, but the main hurdle is getting consensus on the template parameters - I favour adding the possibilities |aa=shan, |ii=mon/maj and |ss=maj/stack/shan/....

   There's reported one Shan version of Pali that uses MYANMAR LETTER SHAN KA for <kh> rather than <k>. That usage is going to need overrides for transliteration. --RichardW57m (talk) 12:30, 2 March 2023 (UTC)

Two new issues with translation adder

1. No automatic conversion to {{t+}} when an interwiki link exists. E.g. αυστραλοπίθηκος (el) (afstralopíthikos), instead of αυστραλοπίθηκος (afstralopíthikos), a Greek translation on australopith.
2. Korean translations don't get added. The tool hangs showing "Loading..." for ever.

Anatoli T. ^{(обсудить}/^вклад) 02:54, 28 February 2023 (UTC)

Ah, so the issue with adding Korean translations is real. I was wondering if it was just a problem with the Internet connection. — Sgconlaw (talk) 05:07, 28 February 2023 (UTC)

Korean was failing because of a JavaScript error that made the script crash. I think it's fixed now, but I don't understand why Korean failed but other languages worked. I'm going to look into the interwiki problem. — Eru·tuon 06:14, 28 February 2023 (UTC)

Interwiki problem fixed. I broke that in a previous edit and the same edit caused the Korean problem. — Eru·tuon 06:30, 28 February 2023 (UTC)

@Erutuon: Thanks for the fixes! --Anatoli T. ^{(обсудить}/^вклад) 10:46, 28 February 2023 (UTC)

Add text option to Unicode appendices?

In blocks such as Appendix:Unicode/Miscellaneous Symbols and Pictographs, it would presumably be best to display the characters as text, so that they display as blue or red links depending on whether an article is present. (The emoji forms would still be displayed via the images.) Could we add that option to Module:character list? I think all we'd need to do is, if "text" is entered as a parameter, append &#xFE0E; to each linked character, as with {{emojibox}}. kwami (talk) 06:09, 28 February 2023 (UTC)

Collapsible sections for use in different wiki

I want to be able to collapse specific sections (containing just text) in a different wiki following the style of "Translations" section in wiktionary, (ie https://en.wiktionary.org/wiki/desert) and adding the "Show/Hide translations" toggles in the left bar menu (so that once clicked, that option sticks for all other pages). I am guessing that NavFrame is used (https://en.wikipedia.org/wiki/Wikipedia:NavFrame) but it appears that the required js and css are not available in the referenced pages. Is there someone with the technical knowledge to elucidate? Spiros71 (talk) 12:45, 28 February 2023 (UTC)

bot removal of obsolete "confer" from etymologies

What bot can be used to replace the apparently widespread use of obsolete "confer" in the sense of "compare" with that word? I thought this was a rare weirdness produced by a non native editor or a snob showing off knowledge of Latin, but i keep bumping into it, f.ex. in arid. Espoo (talk) 14:42, 28 February 2023 (UTC)

All of the ones I've checked, including arid, were added by (various) non-native speakers so I think it is a non-native false friend thing. I wouldn't be opposed to a bot job replacing it with "compare" if there's some way to manually double-check before applying the edit, since "confer" can (theoretically) be used legitimately in an etymology section. —Al-Muqanna المقنع (talk) 14:51, 28 February 2023 (UTC)

Would it be enough to block the replacement in any etymologies of words related to Latin confero?

I found the addition to arid manually. How can one find such a change nonmanually? --Espoo (talk) 15:06, 28 February 2023 (UTC)

@Espoo See User:Benwing2/confer-etymology. I generated this by searching through the Feb 20 dump. There are 482 pages listed in this file; if you can go through and remove the false positive entries, I will do a bot run to replace all remaining occurrences of 'confer'/'Confer' with 'compare'/'Compare'. Benwing2 (talk) 00:57, 1 March 2023 (UTC)

I've removed the false positives I could find. —Al-Muqanna المقنع (talk) 01:22, 1 March 2023 (UTC)

@Espoo, Al-Muqanna Changes made. Benwing2 (talk) 02:08, 1 March 2023 (UTC)

Thanks! --Espoo (talk) 16:32, 1 March 2023 (UTC)

• How do we feel about cf. in our entries? Is the obsolescence of confer not relevant to the abbreviation? To me it seems objectionable, but less so than confer. DCDuring (talk) 18:03, 1 March 2023 (UTC)

I don't think it's relevant, given that as Nicodene points out nobody (nowadays) writes "exempli gratia" or "id est" either but I doubt many would object to "e.g." or "i.e." —Al-Muqanna المقنع (talk) 20:41, 1 March 2023 (UTC)

I'm OK with keeping it. For the longest time I had no idea that it was an abbreviation for confer. I treated it as if it was the same as v., vide, see, thinking that there might be some subtle scholarly distinctions, but not finding reason enough to investigate. DCDuring (talk) 22:34, 2 March 2023 (UTC)

Also, I noticed instances of confer in definitions, in translation tables, and in usage notes. It seemingly could be anywhere. DCDuring (talk) 18:07, 1 March 2023 (UTC)

Even many educated native speakers confuse e.g. and i.e., but the refusal to use f.ex. or even not consider it illiterate is about as strong and widespread as the refusal to accept at least small steps towards the inevitable spelling reform that will come crashing down on English in a chaotic CUL8er way because all rational plans keep getting rejected. The situation with cf. is worse because many or perhaps most native speakers no longer know what it means. Wiktionary could lead the way by replacing all use of at least confusing Latin abbreviations with "for example, in other words, compare" [but] "etc." --Espoo (talk) 18:25, 1 March 2023 (UTC)

That would be rather quixotic. —Al-Muqanna المقنع (talk) 20:41, 1 March 2023 (UTC)

I'm not sure you understood what i meant, in other words, i'm not sure i expressed myself clearly enough. What i suggested was to replace all use of i.e. and e.g. and other abbreviations that many/most people misuse, confuse, misunderstand, or don't understand with "in other words", "for example", etc. What would be quixotic about that? Much more quixotic is an electronic dictionary that continues to use confusing Latin abbreviations invented to save paper.

Most people have stopped using dictionaries, even those who used to, and instead use Google, which fortunately started to often place the OUP/OED result first a while ago. If we want to prevent the entire Wiktionary project from becoming a mindbogglingly quixotic exercise in futility from the point of view of the generations that have never opened /will never open a paper or electronic dictionary, we should at least stop doing completely unnecessary and annoying stuff like using abbreviations young people don't use/know and listing obsolete meanings first (and other outdated/broken dictionary habits inherited from medieval upper class usage). Espoo (talk) 07:31, 2 March 2023 (UTC)

Could we use the same combination of automation and manual checking to get rid of "confer" elsewhere? --Espoo (talk) 18:30, 1 March 2023 (UTC)

I thought it was just cf. spelt out since we shan’t use abbreviations that much, for we have space, like vide instead of v. and many such others typical for bibliographic reference; it cannot be a “false friend” in as much as it is less English but Latin, or perhaps a heterogram. This is what likely happened in the minds of most editors who used it. It is staggering though if it has to be assessed that “most native speakers no longer know what [the abbreviation stands for]”. A bit like with those organization names however whose abbreviation names are better known than the full names, but pedantic reference work editor are not wrong to write these out anyway, and in some cases, similarly to the situation of a heterogram, an abbreviation is maintained for a new full name, as in GRU. Fay Freak (talk) 20:12, 1 March 2023 (UTC)

I'd wager that the vast majority of English speakers who use cf., e.g., or i.e. are unaware of the full Latin versions. Nicodene (talk) 20:18, 1 March 2023 (UTC)

It's just language development. FWIW in my experience people often read out cf. as "compare". —Al-Muqanna المقنع (talk) 20:41, 1 March 2023 (UTC)

Yes, I mention this in support of removing 'confer' (or other full versions) while retaining the abbreviations. Nicodene (talk) 20:53, 1 March 2023 (UTC)

Yeah I don't have an issue with 'cf.' either. As for removing 'confer' in definitions, usage notes, etc. we can do the same thing that I did for etymologies, it's just that there may be more false positives. Benwing2 (talk) 22:29, 1 March 2023 (UTC)

See User:Benwing2/confer-everywhere. After editing out some garbage, there are 753 entries needing reviewing for false positives (which should be removed). Benwing2 (talk) 22:55, 1 March 2023 (UTC)

BTW User:GianWiki please use "compare" not "confer" in etymologies. Thanks! Benwing2 (talk) 22:57, 1 March 2023 (UTC)

Ok, thanks for the heads-up. — GianWiki (talk) 04:24, 2 March 2023 (UTC)