Wiktionary:Grease pit/2023/February

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I like the hovering idea  :-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Горец 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)[reply]

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

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

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

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

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

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

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

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

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

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

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

@Горец 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)[reply]

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

@Горец 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)[reply]

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

@Горец 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)[reply]

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

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

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

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

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

• ^_^: 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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

New code that addresses Erutuon's issue:

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

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

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

@Vuccala: Try this, maybe.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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