Wiktionary:Grease pit/2025/June

If I go to a page, e.g. it, and click a "quotations" near the middle of the screen, it expands as expected: quotes appear and push the senses below them down (the sense the quotes apply to remains in the same place).
OTOH, if I scroll until a "quotations" button and the place the quotes will appear* is the first or second line of text (completely) visible on the screen (*i.e., there are no usexes) and click the button, then the sense below the quotations stays in the same place, while the quotes push the sense they apply to (and themselves) up and off-screen. I.e., if I scroll until the screen looks like A and click, the result is B.
The same thing occurs with other collapsed content, e.g. the conjugation table and derived terms in aller#French. This is true in both Chrome and Firefox. This isn't a big problem, but it's unexpected (to me) so I figured I'd report it! - -sche (discuss) 18:13, 1 June 2025 (UTC)Reply

Disclaimer: I have no coding background and do not know whether what I'm about to propose is even remotely doable or if someone has already done the proposing.

Could we automatize the creation of simple inflectional forms in existing pages when homographic forms are new-listed in tables or have their links be set to some new colour (as with OrangeLinks or green links) and allow accelerated editing to add said form to an already existing page that also already has an entry for the targeted language?

example: I just created septimus#Noun and would either like its ablative be automatically created on septimō or the septimō link in its inflection table be set to some colour to indicate that the form is indeed not present on the targeted page. Saumache (talk) 06:42, 2 June 2025 (UTC)Reply

That's actually rather an awkward example. There should be two entries for that form - one of the adjective, and one for the noun. The inflection tables for the two lemmas need to link to the correct one of these forms. One method of doing this is to use the etymid/senseid system, e.g. by giving the parent lemma and form the same ID and linking all the inflected forms in the table the same ID. Orangelinks would then usually show that no form of the word was linked to. There are several problems with this approach:

1. The vast majority of inflection tables do not propagate these IDs.
2. The scheme I suggested assumes that identical inflected forms will have the same entry. This could break down if the inflection table generated multiple parts of speech. This would happen with Latin amō - Latin amātō is both a verb form and a participle form, and have separate entries. By this process, amō, amātus and both instances of amātō would have the same ID to distinguish them from Latin homographs. If we extended IDs to indicate which form a word has, we would have to decide which forms should have the same ID. It may also make matters complicated for editors.
3. We would increasingly need a 'wordid' intermediate between etymid and senseid. One could abuse a senseid by using it as an entry ID.
4. We may need to give some etymologies or senses multiple IDs. I don't know if there are any bots set up to stop this happening.

I have been contemplating doing something like this for Pali inflection tables, but if it goes wrong, it could be very messy to sort out. --RichardW57 (talk) 23:28, 15 June 2025 (UTC)Reply

That's actually rather an awkward example. There should be two entries for that form - one of the adjective, and one for the noun. That's exactly my goal! if by entry you indeed mean headword.

Thanks for the insights, an automatized ID system seems promising, if it weren't for the shortcomings you stated. I'd really like to help somehow, this thing has bugged me since I joined WT. Saumache (talk) 05:08, 16 June 2025 (UTC)Reply

Conjugation tables for at least Polish verbs ending with -nić (wzmocnić, umocnić) contain wrong imperative forms (2nd singular, 1st & 2nd plural).

Instead of correct -nij, -ń is added: is wzmocń → should be wzmocnij; umocńcie → umocnijcie.

Other verbs, i.e. gnić have proper conjugation gnij. However, imperative form of some -nić verbs indeed has -ń (i.e. gonić -> goń) 188.33.22.169 17:07, 2 June 2025 (UTC)Reply

Updated. Vininn126 (talk) 17:13, 2 June 2025 (UTC)Reply

I've been trying to code a new module lately for the conjugation of Pannonian Rusyn verbs at Module:User:Insaneguy1083/rsk-verb, and for some reason I can have a function accept params (function(params)), I can have a function accept args (function(args)), but for some reason not both at the same time, at least not in the way of ... = function(args, params). The second thing passed in there is always treated as nil, as in the template returns the error message of attempt to index local 'params' (a nil value). Any help as to why params is nil would be appreciated. Insaneguy1083 (talk) 18:20, 2 June 2025 (UTC)Reply

Just FYI, I can very easily change the required arg into a param so the function works with only params, but I'm just wondering if it's possible to use both in the same function. Insaneguy1083 (talk) 18:26, 2 June 2025 (UTC)Reply

MediaWiki message delivery 23:55, 2 June 2025 (UTC)Reply

As mentioned in my previous post, I'm coding a Pannonian Rusyn verb conjugation module (honestly it's basically done), and since 1. Pannonian Rusyn and Slovak both descend from Old Slovak and share a lot of grammatical features and 2. I know next to nothing about coding in Lua, I decided to use the actual Slovak verb conjugation module as a starting point.

And that's great, and I've gotten done basically all I wanted to get done in terms of implementing verb conjugation classes, but now I've run into a problem. For most of the past tense forms, they are formed by adding the L-participle to a conjugated form of буц (buc, “to be”). As it stands, only the actual conjugated forms of the verb are displayed with their Latin transcriptions, while the буц (buc) forms are not. I know why they're not; they're implemented in the code with square brackets. But the l and m templates can't really be used in the Lua code. What's more, even if they were able to be used, the transcriptions of the two terms would be separated. In other words:

• Current display: могол (mohol) сом
• Display if l and m templates worked in Lua: могол (mohol) сом (som)
• Desired display: могол сом (mohol som)

You can see the current display in action here. This also applies to the other particles used in the template, like ше (še) and би (bi). So I would like to ask, given the current code, how much of a surgery would it be to end up with this final display that I'd like it to end up with? I suspect it's quite a lot. The problem is, I'm pretty sure this issue has never come up in Slavic verb conjugation templates. East Slavic, which uses Cyrillic, doesn't have these compound past tense forms; Serbo-Croatian, which does use Cyrillic and has these compound past tense forms, has separate displays and entire separate pages for the two scripts; and West Slavic, which does have the compound past tense forms, barring Pannonian Rusyn itself, doesn't use the Cyrillic script, thus this is AFAIK a uniquely Pannonian issue.

Any input would be appreciated. I don't know if other users have perms to change my module, but if you know anything about fixing the display, then feel free to do it yourself. Just let me know if you do anything major. Insaneguy1083 (talk) 00:09, 3 June 2025 (UTC)Reply

@Insaneguy1083 I'll take a look. Benwing2 (talk) 02:36, 4 June 2025 (UTC)Reply

@Benwing2: I think I've pretty much finished all I wanted to do in terms of pure functionality, so I think I'll now make this the official rsk-verb module and rsk-conj template, and you can check that out and change that instead. Are you cool with that?

P.S. I think the display stuff is mostly in the "create_composite" function. But there are a few other things, like the "ше" particle which is coded separately. Insaneguy1083 (talk) 14:28, 7 June 2025 (UTC)Reply

@Insaneguy1083 That's fine. I may end up rewriting your module the fit with the way that most other Slavic conjugation modules work, though. Benwing2 (talk) 17:58, 7 June 2025 (UTC)Reply

I get that the conjugation may look a little cumbersome, but these compound forms are literally the exact same ones as illustrated in Pannonian Rusyn grammar books. But just let me know if any drastic changes are planned. Insaneguy1083 (talk) 18:11, 7 June 2025 (UTC)Reply

@Insaneguy1083 I don't have any issue with the tables themselves other than the colors, which seem kind of gaudy. It's more that I'd like the syntax to follow that of e.g. {{uk-conj}} and {{be-conj}} and use a similar internal structure. Benwing2 (talk) 18:20, 7 June 2025 (UTC)Reply

BTW it looks like the Slovak module is based on the Russian module, which will eventually also be rewritten to follow the Ukrainian and Belarusian style. Benwing2 (talk) 18:21, 7 June 2025 (UTC)Reply

That's fine. Up to you what you'd like to change. I just boshed this together very slowly to meet the absolute minimum requirement of a working conjugation module anyway. Insaneguy1083 (talk) 18:42, 7 June 2025 (UTC)Reply

I went through and found all the topic categories that don't use {{auto cat}}. (This is not *all* such categories; the non-topic categories not using {{auto cat}} are much greater.) There are 663 of them. See User:Benwing2/categories-without-auto-cat-2025-06-05 for the list sorted normally, and User:Benwing2/categories-without-auto-cat-2025-06-05-from-right for the same list sorted from the right (meaning that the same topics in different languages are grouped). There are a combination of typos, intentional category redirects, and attempts to add random categories to the category tree without going through proper channels. Benwing2 (talk) 19:01, 6 June 2025 (UTC)Reply

A lot of these look like easy deletes. We don't need a bunch of category redirects. Saph (talk) 23:46, 12 June 2025 (UTC)Reply

Suddenly this afternoon the translation boxes, both on entry pages and on translation pages, stopped opening for me. The favourited languages still appear as normal, but the "show" arrow is gone. This is happening on Firefox both on PC and mobile, after restarting the machine and clearing my cache, but it worked on Edge. Not sure what to do about this, but thought someone here would know something. MrPritzel (talk) 00:12, 7 June 2025 (UTC)Reply

Fixed. — Fenakhay ^{(حيطي · مساهماتي)} 00:25, 7 June 2025 (UTC)Reply

I'm using wiktionary on an Android phone, either in the wiktionary app or in Firefox. Collapsed content isn't showing the "Show more" affordance, so there's no way for me to expand the content.

I notice that there is another issue this month related to collapsed content, namely https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2025/June&action=edit&section=new#c--sche-20250601181300-odd_effect_when_expanding_collapsed_content_near_top_of_screen . Perhaps changes made to address this issue are causing mine? Trekkieyk (talk) 00:15, 7 June 2025 (UTC)Reply

Fixed. Your assumptions were correct, I've reverted those edits. — Fenakhay ^{(حيطي · مساهماتي)} 00:26, 7 June 2025 (UTC)Reply

As reported at WT:RFC#企, some hanzi/kanji stroke-order SVGs have stopped displaying. Glrx identified the problem, a fix, and some ways such files might be systematically located, at c:Commons:Village pump/Technical#Kanji_stroke_order_SVGs_have_stopped_displaying (permalink). (The problem affects all kinds of SVGs, not just stroke-order ones.) (Notifying Fish bowl, Justinrleung, Geographyinitiative, 沈澄心): if any of you want to try to systematically locate other broken stroke-order files so they can be fixed. - -sche (discuss) 17:11, 7 June 2025 (UTC)Reply

This is the transliteration module that should be used for the Kaitag language. It needs to be switched on here: https://en.wiktionary.orghttps://dictious.com/en/Module:languages/data/3/x#L-468 Kaitag words (talk) 22:38, 7 June 2025 (UTC)Reply

Can somebody please assist? Kaitag words (talk) 12:29, 11 June 2025 (UTC)Reply

@Kaitag words: Currently, when I preview a Kaitag entry (бекӏ) using the new module, it gives an error in the transliteration. Could you try a number of testcases first? Thadh (talk) 12:33, 11 June 2025 (UTC)Reply

That is expected. Once you switch on the new module, I will move that entry to бекь. Kaitag words (talk) 15:31, 11 June 2025 (UTC)Reply

@Kaitag words So you want to force Alkaitagi's new alphabet after all? Has it been used anywhere outside his dictionary? Also, why are we keeping the charade? You are Alkaitagi, no? :-) Vahag (talk) 20:42, 12 June 2025 (UTC)Reply

I'm not Alkaitagi lol. Apply logic. Would Alkaitagi ever choose Make Dargwa great again as his nickname?

Yes, it's used in many places. Behold, Ehtnologue uses it. See also here . And most importantly, if you have an Android phone, go to keyboard settings, tap 'add a new language', and then type in "Kaitag"... you will be surprised Kaitag words (talk) 21:40, 12 June 2025 (UTC)Reply

@Kaitag words: Those are clueless, Westoid places easily swayed by Alkaitagi's activism. It appears that the relevant people — Kaitags themselves, other Dargins and Russians do not accept your system. {{R:xdq:Gasanova:2020}} too uses what you call the Soviet system, as do all the sources other than the Internet pdf {{R:xdq:Magomedov:2025}} made by Alkaitagi. Sorry, but Wiktionary is not your playground. Please do not use this experimental alphabet. The alphabet itself is very unusual for East Caucasian languages: кь is supposed to be an ejective, who does that? Vahag (talk) 10:04, 13 June 2025 (UTC)Reply

Dear Vahagn, it seems to me that you are excessively invested in an issue in which you need not be invested on an emotional level because you wish to uphold an image of being knowledgeable on everything that has to do with Caucasus - everyone is clueless except for you. It also seems that you have profoundly negative emotions connected to Alkaitagi, since every mentioning of him by you breathes disapproval (you use "language activist" as a negative thing - are we not all language activists, after all?). That is regrettable because those negative emotions are spilling over into unrelated matters and creating unnecessary obstacles for productive Wiktionary work. I really think it would be good if you could take a step back an reflect a little on whether you really need to be so emotionally invested into something that has nothing to do with you or with what you usually do on Wiktionary. Perhaps you can just let someone else handle this?

As to you arguments, Russians do accept the Kaitag alphabet devised by Alkaitagi, as you can se under one of the links above, and prof. Gasanova approves of it too (her phrasebook is from 2020). Kaitag words (talk) 11:16, 13 June 2025 (UTC)Reply

I have said on many occasions I know almost nothing about Caucasian linguistics. But I notice when highly-motivated minorities exploit the indifference/naivety of the majority.

Someone else can handle this, I don't mind. Vahag (talk) 12:37, 13 June 2025 (UTC)Reply

"Exploit" to do what exactly? These are two variants of the same script, with a few additions here, a few alternations there, for a largely unwritten language up in the mountains of Caucasus, of which there are many dozens others. I am curious, what hidden agendas and schemes is it that you see through, that the naive majority is deceived by? Sounds rather grandiose. Kaitag words (talk) 16:11, 13 June 2025 (UTC)Reply

To give you an official platform for popularizing your system.

The spellings in your system do not pass Wiktionary:Criteria for inclusion, by the way (see also Wiktionary:LDL). The only source that uses it – Template:R:xdq:Magomedov:2025 – is not durably archived. Kaitag is not written, but I can find Kaitag data attested in about a dozen scholarly works published in the USSR and Russia spanning more than 30 years, all in standard Dargwa orthography. You now want us to normalize this durably archived material into your (unattested) system. Your system may be superior, I don't know, but consider popularizing it in the real word first. Vahag (talk) 16:43, 13 June 2025 (UTC)Reply

@Vahagn Petrosyan: Just recently I saw a post about this in Telegram in Yuri Koryakov's channel. Apparently, Koryakov and Maisak support the ideas of the authors of the new alphabet. Although Mikhail Zhivlov expressed himself negatively in the comments, but Zhivlov is not a Caucasus expert. Personally, I do not accept these innovations until good, evidence-based sociolinguistic research(!) is presented. It seems that politics are also involved in this, it is surprising that the Russian Roskomnadzor missed this :D Lerman (talk) 20:48, 14 June 2025 (UTC)Reply

We can always bot-convert to the new alphabet in the future if it becomes popular. I don't think Wiktionary should be the polygon for testing/promoting it. Vahag (talk) 08:04, 15 June 2025 (UTC)Reply

I hope other people who read this can appreciate the absurdness of the situation, where one admin who admittedly "knows almost nothing" about the matter decides on 1) whether a language is a language, whether writing conventions should be accepted or not 2) dismisses presented evidence as "language activism" and "clueless Westoids" and 3) replaces project guidelines with own vaguely formulated standards ("come back when it's become popular") 4) seasons it all with legalese jargon ('your source isn't durably archived'). Kaitag words (talk) 09:09, 15 June 2025 (UTC)Reply

A couple of days ago, @Tokoss78 added a French usage example at moi consisting of:

{{ux|fr|{{w|L'État, c'est moi|L'État, c'est '''moi'''.}}|''I'' am the State.}}

Not that there's anything wrong with that: the phrase is probably the most famous of all quotes using the word, and Wikipedia does have an article about it.

The problem is that {{ux}} insists on converting the apostrophes into right single quotes even inside the link to Wikipedia, so it links to L’État, c’est moi instead of to L'État, c'est moi. I've tried hardcoding the apostrophes with %u27 and ', but the result is the same.

Of course, {{ux}} isn't designed to have embedded links, and the documentation says so. The old Henny Youngman joke comes to mind about a woman who says to her doctor "It hurts when I do <this>", to which the doctor replies: "don't do <this>". Still, I'd like to figure a way to get the formatting benefits of {{ux}}, but with a Wikipedia link that has apostrophes instead of single right quotes. Any ideas? Chuck Entz (talk) 06:24, 9 June 2025 (UTC)Reply

This was due to by User:Fenakhay (with no comment message whatsoever), which I have undone as I disagree with it. These sorts of changes hacking apostrophes for specific languages are undiscussed and (a) need BP consensus, (b) should either be done for all languages or none (I vote none) and (c) if done, should be done in a way that doesn't break Wikipedia links. Benwing2 (talk) 18:11, 9 June 2025 (UTC)Reply

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• The Trust and Safety Product team is finalizing work needed to roll out temporary accounts on large Wikipedias later this month. The team has worked with stewards and other users with extended rights to predict and address many use cases that may arise on larger wikis, so that community members can continue to effectively moderate and patrol temporary accounts. This will be the second of three phases of deployment – the last one will take place in September at the earliest. For more information about the recent developments on the project, see this update. If you have any comments or questions, write on the talk page, and join a CEE Catch Up this Tuesday.

Updates for editors

• The watchlist expiry feature allows editors to watch pages for a limited period of time. After that period, the page is automatically removed from your watchlist. Starting this week, you can set a preference for the default period of time to watch pages. The preferences also allow you to set different default watch periods for editing existing pages, pages you create, and when using rollback.

• The appearance of talk pages will change at almost all Wikipedias (some have already received this design change, a few will get these changes later). You can read details about the changes on Diff. It is possible to opt out of these changes in user preferences ("Show discussion activity").
• Users with specific extended rights (including administrators, bureaucrats, checkusers, oversighters, and stewards) can now have IP addresses of all temporary accounts revealed automatically during time-limited periods where they need to combat high-speed account-hopping vandalism. This feature was requested by stewards.
• This week, the Moderator Tools and Machine Learning teams will continue the rollout of a new filter to Recent Changes, releasing it to several more Wikipedias. This filter utilizes the Revert Risk model, which was created by the Research team, to highlight edits that are likely to be reverted and help Recent Changes patrollers identify potentially problematic contributions. The feature will be rolled out to the following Wikipedias: Afrikaans Wikipedia, Belarusian Wikipedia, Bengali Wikipedia, Welsh Wikipedia, Hawaiian Wikipedia, Icelandic Wikipedia, Kazakh Wikipedia, Simple English Wikipedia, Turkish Wikipedia. The rollout will continue in the coming weeks to include the rest of the Wikipedias in this project.
• View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

• AbuseFilter editors active on Meta-Wiki and large Wikipedias are kindly asked to update AbuseFilter to make it compatible with temporary accounts. A link to the instructions and the private lists of filters needing verification are available on Phabricator.
• Lua modules now have access to the name of a page's associated thumbnail image, and on some wikis to the WikiProject assessment information. This is possible using two new properties on mw.title objects, named pageImage and pageAssessments.
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 01:17, 10 June 2025 (UTC)Reply

For words like eggcellent, eggstraordinary, etc. Not sure if this is the right place to ask, but I know where else to go. Inpacod2 (talk) 11:51, 11 June 2025 (UTC)Reply

Doesn't seem like a very useful category. Why not just use the eggs category. 2A00:23C5:FE1C:3701:BCAE:C553:6E63:139D 12:02, 11 June 2025 (UTC)Reply

If there are only a handful, linking them is appropriate and a category is probably not necessary. —Justin (koavf)❤T☮C☺M☯ 12:25, 11 June 2025 (UTC)Reply

Is there a reason why Wiktionary templates use curly rather than straight quotes? Since most users default to straight quotes, the effect of this is that many entries contain a random mixture of both (see for example the walker entry, where the etymology section uses curly quotes, the usage notes use straight quotes, and the quotations use a mixture). Wikipedia has policies to prevent this kind of thing from happening. Zacwill (talk) 03:44, 12 June 2025 (UTC)Reply

This has generally been discussed several times with votes such as Wiktionary:Votes/pl-2008-12/curly quotes in WT:ELE, Wiktionary:Votes/2020-07/Converting policy and guide pages as for quotes and apostrophes, and Wiktionary:Votes/pl-2013-02/Disallow typographic punctuation in policies. One emergent policy that is relevant is Wiktionary:Quotations#Typography. —Justin (koavf)❤T☮C☺M☯ 03:55, 12 June 2025 (UTC)Reply

I believe glosses (such as the one in usage notes in your example) should be wrapped in {{m-g}}. We can decide which quotes to use later (and simply change the templates when that happens), but in any case they should be consistent between templates. – wpi (talk) 09:03, 12 June 2025 (UTC)Reply

I've started adding number boxes for Northern Thai, and I've hit a number of problem. The relevant facts are:

• Two scripts - Lanna (Tham) and Thai, with various writing systems for each, though one dominant system for each.
• Three or four systems of decimal digits - secular, religious, European and possibly Thai. There's also the system for numbering the pages of palm leaf manuscripts, unless that belongs in an encyclopaedia rather than a dictionary.

Should I separate the cardinals by script? If so, how do I do it?

The number box module won't accept tables for numerals. So how can I handle the multiple systems, and how should I? There's the added complication that the secular and religious systems are used in Burma, China and Thailand, with multiple native languages, and possibly also in Laos. (Notifying Noktonissian, Atitarev, Octahedron80): -- RichardW57 (talk) 10:27, 12 June 2025 (UTC)Reply

I had hoped for precedent from Lü, but that seems to only support the New Tai Lue script. (There are a few words on Wiktionary in the old (and still used) writing system.) --RichardW57 (talk) 10:27, 12 June 2025 (UTC)Reply

@RichardW57 there's general support in the number boxes for tags to identify different sets of numerals. These are used, for example, to distinguish the Welsh decimal from vigesimal numerals. You might use the same support for distinguishing the numeral sets in different scripts and digit systems. Take a look at Module:number list/data/cy and you might get some inspiration. Benwing2 (talk) 19:05, 15 June 2025 (UTC)Reply

@Benwing2: (Notifying Noktonissian, AryamanA, Kutchkutch, نعم البدل): @SarahFatimaK: What I was looking for was the documentation of the contents of the data modules, especially the optional items, such as the variable additional_number_types. Perhaps this documentation simply doesn't exist. On a more positive side, Japanese (ja), Korean (ko) and Modern (el) and Ancient (grc) Greek provide examples of what can and, perhaps what cannot, be done. Does Chinese do its own thing? Welsh is more of a messy fallback example, going beyond the example of Catalan. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

There don't seem to be any languages recorded here as having two numeral systems other than (Western) Arabic, which I presume is excluded because it acts as the index. It looks as though someone attempted to split Punjabi by script into 'pa' and 'pa-Arab' data files, but it looks as though this failed and functionality depends on the use of different language codes for different scripts. Such an approach wouldn't help much with the matter of numerals, as the Lanna script has separate decimal numerals for religious and secular purposes. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

I didn't find any answer to the issue of working with translingual numerals. The CJK numerals seem to be duplicated by language. Perhaps it is dealt with by numerals not being accessible from the number boxes. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

I haven't found any good terminological precedents for the numbering systems of ordered lists. English uses Western Arabic numerals, Roman numerals and often gets away with its alphabet, at least up to 'z'. I suppose '(f)' designates the item between '(e)' and '(g)' rather than the 6th item, so perhaps it shouldn't be tied to the number '6', whereas (vi) is expected to denote the 6th item. So perhaps alphabet-based page numbering should be handled independently of numbers. One also wants to avoid issues with different authors using different subsets of some larger ordered sets, as with Thai lists. (The prefatory matter of my copy of the Royal Institute Dictionary variously has zero, one and two items between items ค (kɔɔ) and ง (ngɔɔ)!) It's also bad enough when item '5a' is inserted between numbers 5 and 6, as often happens in amended Acts of Parliament. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

@RichardW57 additional_number_types is for types of numerals other than the built-in ones. You can see several examples in Module:number list/data/en, which goes a bit crazy in adding such additional types. My apologies that there isn't really proper documentation for the number list data modules; there's so much documentation to keep up with, and sometimes some of it gets lost by the wayside. I don't think there's support for multiple numeral systems for a single language; I would need to add it. Benwing2 (talk) 22:10, 15 June 2025 (UTC)Reply

@Benwing2:: I could add a numeral type 'numerals' with display text 'numeral' and tag the different system's numerals by the number system e,g, religious v. secular. I would rather keep the different scripts apart, so that one could only step from a Lanna script cardinal to another number's Lanna script cardinal, rather than having to always choose which script to step to. I could make different scripts' forms different 'types' to achieve this. --RichardW57 (talk) 23:52, 15 June 2025 (UTC)Reply

Yes, that sounds good. Benwing2 (talk) 00:42, 16 June 2025 (UTC)Reply

Whatever happened to etytree ? I can't remember ever using it, but can imagine how useful and desirable that might be. Compare the still functional (but no longer developed ) etygraph for another tree project, and even the fluffier android app that offers less for more. Etytree, on the other hand, once supported by Mediawiki, doesn't respond to queries on its toolforge subdomain. Why? Danny lost (talk) 16:46, 12 June 2025 (UTC)Reply

See {{etymon}} instead. There is a desire amongst some editors to change some of the functionality, and its not to be used everywhere. Vininn126 (talk) 17:02, 12 June 2025 (UTC)Reply

So the idea behind {{etymon}} is:

• To introduce yet another template, with unusual syntax, that depends specifically on other instances of the template in other pages (that is, not editable on a per-entry basis), in order to mirror some info already in the etymology sections?
• And then sometimes use it to present a tree and sometimes just have it hidden in the source for whatever later implementation might come?
• To introduce IDing senses (with a crude verbal gloss, that is easy to conflate with the lemmas around the tree, rather than some recognizable or automatic shortcut), but not attempt to hardlink the etymological prose itself to the sense IDs, nor split it so?
• Just to try and avoid the ambiguity of same-language homographs with distinct etymologies (even when, in some likelihood, they converge at somepoint)?
• While there are tools (graph-based) that already do decent job automatically extracting data from the usual etymological templates (especially when well formed), but WT/MW just don't adopt them?

What is the point?? This seems so clumsy, duplicative, and yet so limited in terms of presentation, manipulability and browsability (lateral, zoom out and in, cognate relations). And also like a way to override and dumb down what etymology sections already contain. No wonder you hardly ever see this type of tree. Danny lost (talk) 19:39, 12 June 2025 (UTC)Reply

etytree had a lot of bugs. if i remember right, it just lumped all homographs together, so it had "is" merging into "ice", for example, just because in Middle English spelled them both is. we could theoretically fix these bugs, but they're a lot easier to handle if the tool is within our project. —Soap— 03:00, 14 June 2025 (UTC)Reply

I'm not sure I get what you mean - it's based on ID's. Vininn126 (talk) 07:17, 14 June 2025 (UTC)Reply

i specifically remember seeing the etytree tool, at https://etytree.toolforge.org/, producing very poor output, including merging Modern English is and ice together, apparently because in Middle English both were spelled is and the tool has no way to tell them apart. As Danny says, the tool isn't functioning anymore. He even points out the same problem I remember. as for why? .... I don't think it ever had the ability to read templates such as {{etymid}}, but I suppose in theory it could be restored and re-coded to work with the new templates we've created. —Soap— 19:49, 14 June 2025 (UTC)Reply

I didn't say it reads etymid, I said it uses id's, and I don't know what you mean it doesn't work anymore. Recently I added it to several entries. Vininn126 (talk) 23:56, 14 June 2025 (UTC)Reply

@Vininn126: you two are talking past each other. The conversation has shifted back to etymtree, but you're still talking about etymon. Chuck Entz (talk) 01:04, 15 June 2025 (UTC)Reply

could someone fix the template error on 琉球 please? it's on my watchlist because i saw a similar template error somewhere else and wasnt able to fix it. it's linking to Okinawa| instead of Okinawa. also, the wording may be a problem, since it says the Okinawa ... islands. although i dont remmeber the page where i saw this last time, based on hte trouble i had there, this may be more complicated than it looks. thanks, —Soap— 02:58, 14 June 2025 (UTC)Reply

actually, i see my message on Talk:琉球 now, so maybe this was the page i saw, and i did my editing entirely in preview or in a sandbox and that is why i cant find it. —Soap— 03:28, 14 June 2025 (UTC)Reply

I'll investigate but I notice that it's completely misusing the {{place}} template params. If I fix it to use the right params the problem will probably disappear but I want to know why this is happening in the first place. Benwing2 (talk) 04:33, 14 June 2025 (UTC)Reply

It's because the code doesn't expect something with multiple internal links of the form ] ]. I'll make the code more robust but we also need to use the right syntax for {{place}}. Benwing2 (talk) 04:48, 14 June 2025 (UTC)Reply

Fixed. Benwing2 (talk) 04:59, 14 June 2025 (UTC)Reply

..."Community portal", "Requested entries". On the WT:Main Page side bar. How can we change this to sentence-case to match the other options, like on w:Main Page? (it's weird that the Wikipedia page is under that URL) Polomo47 (talk) 18:22, 15 June 2025 (UTC)Reply

Wanted to change India to add "or other South Asian countries". Rejected by an abuse filter called "sport". 2A00:23C5:FE1C:3701:DA1:7B6C:C597:1E84 20:05, 15 June 2025 (UTC)Reply

Fixed — SURJECTION ^{/ T / C / L /} 20:10, 15 June 2025 (UTC)Reply

MediaWiki message delivery 23:38, 16 June 2025 (UTC)Reply