I've been cleaning up some coding errors in Lithuanian entries, and I noticed that seven years ago @エリック・キィ had ineffectually added |sort=skesti to the headword line of Lithuanian skę̃sti? What problem was it hoped to address? The word currently gets sorted (except when separated from its tagging as Lithuanian between "ske" and "skė" and in particular before "ski"; it looks as though sorting was much worse when the entry was created. It's possible that the hope was that it would be sorted between Lithuanian skėrys and Lithuanian skėtis as would be done by Mimer SQL. (Notifying Agamemenon, Apisite, BigDom, GabeMoore, Insaneguy1083, Helrasincke, Hippietrail, RichardW57, Sławobóg, 70.175.192.217): . I have removed the ineffectual parameter from the page. RichardW57m (talk) 13:13, 1 May 2024 (UTC)[reply]
Where is the design rational for our current Lithuanian collation? As far as I can tell, if it was controlled from Module:languages/data/2, it was implemented on or after 2 December 2022, in Module:lt-sortkey, which was deleted on 7 January 2023. Essentially - why are secondary collation differences promoted to primary, whereas they are simply ditched in French, so sort French e, é, è and ê the same, but make Lithuanian e, ę and ė sort like completely different letters? Was it a conscious decision? I suspect the decision was taken by @Theknightwho, and it can always be justified by being better than what went before. --RichardW57m (talk) 17:25, 1 May 2024 (UTC)[reply]
@RichardW57m What do you mean by "problems with promoting secondary collating differences to primary differences"? Can you clarify? BTW I doubt User:Theknightwho intentionally made a decision to change Lithuanian sorting order. He did a lot of work restructuring the *handling* of sort keys, but AFAIK the intent was to preserve whatever sorting rules were already present. Benwing2 (talk) 23:58, 1 May 2024 (UTC)[reply]
@Benwing2 Richard is referring to the Unicode Collation Algorithm, which uses primary, secondary and tertiary weightings (secondary tiebreaks primary, and so on). While I'd very much like us to use the UCA, implementing it would be a lot of work, but it would be a big improvement over the crude sort methods we generally use at the moment.
I'm afraid Theknightwho's answer isn't an answer to my question. While our collations seem to be defined entirely by what the UCA would term primary keys, they tend to attempt to approximate the native sorting orders. It hasn't always been done - our Roman script Pali sorting bears no relationship to the usual sort order, for example, being mostly based on the foremost sorting order for each script. Someone should be making a decision on how to do the approximation - but they may not actually understand the subtlety of the secondary level. --RichardW57 (talk) 06:48, 2 May 2024 (UTC)[reply]
@RichardW57 There's only one edit to Module:lt-sortkey, when it was created on Dec 1 2022 by User:Theknightwho. It looks like prior to that there was no sorting algorithm defined for Lithuanian. The Lithuanian dictionary at [3] sorts ę as if it were e (e.g. gesti is directly followed by gęsti) but treats ė as a distinct letter, hence gežtis is directly followed by gėbelėti. I think you should figure out the correct sort order according to standard dictionaries, and then we can implement it. Benwing2 (talk) 07:07, 2 May 2024 (UTC)[reply]
{[re|Benwing2}} There had been a prior algorithm, but it was subsumed in the stripping of the three stress accents to generate page names. I haven't dug into the history of this stripping, but it may explain some of the oddities of Lithuanian templates if it was a later feature on Wiktionary.
Am I missing a trick with the LKZ web site? I can't see how to get a dictionary page from it, only dictionary entries. Short of ordering books, I could only find Lalis's dictionary and introductory pages. --RichardW57m (talk) 08:40, 2 May 2024 (UTC)[reply]
@RichardW57m You can e.g. type just g in the search box and hit enter, and down the left rail you'll see a list of all the entries starting with g, in sorted order. Benwing2 (talk) 08:56, 2 May 2024 (UTC)[reply]
@Benwing2: But remember Theknightwho's assessment above of the UCA (let alone the CLDR Collation Algorithm) being a lot of work. Last time I looked, the latter wasn't clearly defined. --RichardW57m (talk) 10:31, 2 May 2024 (UTC)[reply]
This LKZ list may not be reliably sorted. We have four consecutive items gabumas, gabūnas, gabuoti, gaburdalas, but the distinctly non-empty lists of words stating 'bub' and 'būb' do not overlap! Likewise for words starting gabu and gabū. At https://zodynas.vz.lt/terminaiRaidec.php, I found the index headings/links ABCČDEĖFGHIJKLMNOPRSŠTUŪVZŽ, but 'E' and 'Ė' and also 'U' and 'Ū' pointed to the same lists! Possibly that's a case of the author and the software having different ideas about Lithuanian sorting. The list for 'U' and 'Ū' contained examples of both as initial letter. --RichardW57m (talk) 13:10, 2 May 2024 (UTC)[reply]
@RichardW57m Implementing the UCA for general use on Wiktionary would be a lot of work because (a) it presents performance difficulties due to the size of the UCA dataset and complexity of tailorings, and (b) the sortkeys generated by the UCA aren't suitable as Wikimedia category sortkeys since they're numeric, which would mess up category headers. As such, any general implementation will need to solve that issue, too.
Implementing something something which emulates the UCA for one language is probably not too difficult, though (like our other sortkey algorithms) it would only support the relevant diacritics for the language. Theknightwho (talk) 15:17, 2 May 2024 (UTC)[reply]
Using the UCA doesn't force the use of the DUCET. To be honest, most of the CLDR tailorings don't look too wonderful when applied to characters not used outside the language's known character range. I suggest the keys be loaded as strings (which is what we do now). The UCA implementation notes admit that the DUCET values are unfit for any system that expect keys to be C strings, and explains how to convert them.
Even now, starting a category display of Lithuanian terms at 'Y' causes the first letter header to be shown as 'I'. I think that sort of thing is inevitable for any letter that sorts out of code point order. --RichardW57m (talk) 16:10, 2 May 2024 (UTC)[reply]
I finally found the demonstration of 'u' and 'ų' having the same primary key in the sequence 'skùsti', 'skų́sti', 'skų́stis', 'skùtas' on paɡe 440. Word internal 'ų' is inconveniently infrequent.--RichardW57 (talk) 21:21, 2 May 2024 (UTC)[reply]
The only CLDR collation for Lithuanian gives "Bronius Piesarkas: Lithuanian-English Dictionary ISBN 9986-465-56-7" as its source, and this collation defines ogonek on 'a', 'e', 'i' and 'u' not to make a difference in primary weight, 'e' and 'ė' not to differ in primary weight, 'i' and 'y' not to differ in primary weight, and 'u' and 'ū' not to differ in primary weight. The only weird thing about this collation is that it defines the accentuation marks (acute, grave and tilde) to make secondary differences, and thus be more significant than capitalisation, which I don't believe. It's also saying that, inter alia, a difference of accent on the first syllable would outweigh a difference between 'e' and 'ė' in a subsequent syllable. That's probably refutable. --RichardW57 (talk) 22:02, 2 May 2024 (UTC)[reply]
@RichardW57 I hope this might be what you're looking for (excerpted from Ambrazas et al):
In dictionaries and other lists of words arranged in alphabetical order, a and ą, e, ę and ė, i, y and į, u, ū and ų are treated as if they were identical letters, even though they represent different sounds. Therefore the following alphabetical order is customary: aržùs – ąsà – asamblė́ja, ẽsti – ė́sti – èstiškas, įkélti – ìkrai – ýla – ìlgas.[2]
The only question is whether this is what people would prefer, as opposed to government directive. I've been surprised by the evidence that some would prefer to treat 'e' v. 'ė' and 'u' v. 'ū' as primary differences. We did have someone object to the CLDR treating 'i' v. 'y' as a secondary difference. The objection was dismissed as being based on ignorance, but I can't help wondering if there is a folk collation. --RichardW57 (talk) 14:06, 5 May 2024 (UTC)[reply]
@RichardW57 That is an interesting find. To be honest, it seems like they're right insofar as y does immediately follow i (as opposed to preceding it), but only when all else is equal (see below, I presume this is the secondary collation in action, though I have to admit I'm still getting my head around primary vs. secondary). I've just checked the Lithuanian Root List and it has the following to say:
The morphemes in the root, prefix, and suffix lists are presented in Lithuanian alphabetical order. As in Lithuanian dictionaries, the letter y (designating long /i:/) is treated alphabetically as a variant of i, and in cases where otherwise identical roots differ only in initial letter i vs. y, the root with initial i is listed first (e.g., ir-1, yr-1 ‘come apart’)[4]
So on that front, Wissink & Kaplan do appear to get that detail quite wrong. Thus Vakareliyska gives: bur- — būr- — būrb- — burn-; drambl- — drąs- — drask-, ėd- — egl-, yd- — iešk- ... ir- — yr- — irz-; ūg- — ugd-. In this sense Ambrazas's statement (but not the examples) they are treated identically is also not entirely correct (or has perhaps been mistranslated). It appears the secondary order is: base letter > y/macron(?) > ogonek > dot. The only one I have my doubts about is the secondary order of y and į as well as ū and ų since Vakareliyska organises the heading on p.21 and p.56 respectively as "I, Į, Y" and "U, Ų, Ū" (compare "A, Ą" and "E, Ę, Ė") and I actually can't find any minimal examples to confirm or deny this, especially since from my understanding ų is quite rare outside of inflections. Helrasincke (talk) 21:19, 8 May 2024 (UTC) Helrasincke (talk) 21:19, 8 May 2024 (UTC)[reply]
The secondary order I find plausible is base, base + ogonek, base + length marking, which is consistent with the CLDR. The instances of base + length marking are 'ė', 'y' and 'ū'. That's also the ordering Wktionary currently promotes to primary, and the ordinary presented for longer versions of the alphabet. 'Dot above', except as part of ė, is probably less significant than capitalisation. --RichardW57 (talk) 07:22, 11 May 2024 (UTC)[reply]
I put out feeler about the reality of Lithuanian collation rules, and got an interesting indirect response from a Lithuanian. He said that the diacritics (and 'i' v. 'y'), other than those for accentuation), create what are treated as different letters and are sorted as such. When he then compared the system he described with a dictionary, he came back with the response that the ordering in the dictionary was 'weird'! (The intermediary was Bradn on the Zompist Bulletin Board.) On this basis, what we have at present is just fine! --RichardW57m (talk) 13:58, 15 May 2024 (UTC)[reply]
The translations for verb play, sense "deal with a situation in a diplomatic manner", display OK, as you will see. However, if everything else in the "translations" section is deleted, leaving only the "deal with a situation in a diplomatic manner" part, then the translations become corrupted with funny characters, stuff like "Finnish: ⦃⦃t+¦fi¦hoitaa¦¦¦¦¦¦¦¦¦⦄⦄"etc., as you can see here in a test edit that I have now reverted. (Of course, I do not actually want to delete everything else in the section. I wanted to make another edit, which went wrong for the same reason, and in trying to work out where the problem lay, I successively deleted other sections, until nothing else was left, to arrive at the minimal case that exhibited the problem.) Any ideas? Mihia (talk) 17:39, 1 May 2024 (UTC)[reply]
@Mihia This is not a bug. The {{tt}} and {{tt+}} templates need to be surrounded by {{multitrans}} in order for them to work and not display "funny characters" (as you say). If you delete the surrounding call to {{multitrans}}, you need to convert {{tt}} back to {{t}} and {{tt+}} back to {{t+}}. But a better solution is just to not do this. You can also put the call to {{multitrans}} around each translation section instead of once around all of them, but that will partly negate the memory-saving benefits of {{multitrans}}. Benwing2 (talk) 23:53, 1 May 2024 (UTC)[reply]
To expand on Ben's point: the reason we originally used {{multitrans}} was to avoid hitting the 50MB memory limit on large pages (which is no longer much of a concern since the limit got raised to 100MB a few months ago), but it's still very useful because it helps with page loading times as well. water/translations would be totally unusable without it, for example. Theknightwho (talk) 00:26, 2 May 2024 (UTC)[reply]
Thanks. The way this is presently laid out, the start of "multitrans" is embedded within one "trans" block, and the end of it, "}}", I think I can now see, is embedded within another, so I must say that it is non-obvious to editors what is going on. It looks "obviously" as if each block is self-sufficient, and, e.g. that they can be reordered, but of course when I moved one block to the end this actually took it out of "multitrans" and broke it. Is there any way to lay this out more clearly? E.g. can "multitrans" be started at the very top on a separate line, and ended at the very bottom on a separate line? Mihia (talk) 09:29, 2 May 2024 (UTC)[reply]
@Mihia That was a kludge because the translation-adder originally freaked out if you put the multitrans opening at the top, and no-one wanted to touch it if we didn't have to since the translation-adder's quite finicky. That bug's since been fixed, but lots of pages still do the original workaround as no-one's sent a bot round yet. It wasn't seen as a priority originally, since multitrans was only used on a handful of pages, but as memory issues became worse it eventually came to be deployed on hundreds of pages. Theknightwho (talk) 15:20, 2 May 2024 (UTC)[reply]
I guess I understand from "since been fixed", then, that it is OK now to wrap "multitrans" around the whole section? (I can see that this does seem to work, but I wouldn't necessarily know if it is achieving the full memory-saving benefits.) Anyway, I've done it now, so please let me know if it's a problem. Thanks. 17:32, 2 May 2024 (UTC) Mihia (talk) 17:32, 2 May 2024 (UTC)[reply]
I guess you could make {{oc-pp}} as a copy of {{ast-pp}} to start with, as that does not use Lua and should be easy to adapt. But I can see that Occitan morphology is not always as simple as adding letters onto a fixed stem. Ultimately what needs to be created is Module:oc-headword, as a copy (😢) of Module:ca-headword or similar, with changes to the Catalan-specific logic there. @Benwing2 is the expert here. This, that and the other (talk) 02:49, 2 May 2024 (UTC)[reply]
@This, that and the other Conceptually this is not so hard, but unfortunately I don't know that much about Occitan; and a complicating factor is the 6 or so different dialects, each of which (conceivably) forms its feminine and plural according to its own rules. Benwing2 (talk) 03:03, 2 May 2024 (UTC)[reply]
Looking at oc:parlar#Conjugason, dialectal differences may not be an issue for past participles (at least in these four dialects, and for regular first group verbs). I was going to say "I'm sure Flummont knows more", but it seems that this editor does not actually speak Occitan. This, that and the other (talk) 04:13, 2 May 2024 (UTC)[reply]
Several Lua Module have been "corrected" or modified and returned back to the Lua 5.0 old way of dealing with variable sized arguments. As Scribunto currently uses Lua 5.1 and efforts are ongoing that may update the Lua engine to new versions, I think we should stick to more modern ways to deal with varargs functions.
This is also important for me as I extract data from wiktionary and the Lua version I rely on does not understand this jargon anymore.
@Dodecaplex The instances where I’ve implemented this have been where it maximises performance, and I would not support changing that. The workaround that you suggest generates a performance hit, which is unacceptable for functions which are called many thousands of times, as happens with memoisation.
I really don’t see the point in caring about what is officially deprecated in Lua 5.1 while there is no chance of the functionality disappearing in the near future. I appreciate that it creates awkwardness for you, but the solution is for you to use a Lua 5.1 binary. Theknightwho (talk) 21:16, 3 May 2024 (UTC)[reply]
@Theknightwho As Lua 5.1 is used in Scribunto, then arg is already deprecated.
In Lua 5.1, using arg in the function WILL imply a new table creation which will have a cost.
While using ... will avoid the creation of the magic table named arg (which is always null in Lua 5.1 when varargs are to be used). See for instance this stackoverflow answer.
My suggested changes where just a workaround, but if you want to avoid performance hits, then directly use the ... which contains directly the args (no overhead for arg table creation:
select('#',...) instead of arg.n,
select(1,...) instead of arg[1],
select(2,...) instead of arg[2], etc. (well, it is not that easy as indeed select(2, ...) will give the unpacked table from position 2, see details in the cited question)
@Dodecaplex If you look at the instances where it's been used, a table has to be created anyway. It's possible to iterate with select, but that rapidly becomes much slower than iterating over a table. I appreciate it's deprecated in Lua 5.1, but that is a completely academic point, really - in practical terms, it just means it's not portable to Lua 5.2 or higher, but Wiktionary doesn't use 5.2 and there's no chance it will for the foreseeable future. If and when that changes, we can adapt the code. Theknightwho (talk) 23:16, 3 May 2024 (UTC)[reply]
Hello guys! I've been planning on expanding the cardinal box of the Vietnamese cardinal number entries by creating Module:number list/data/vi based on the data given in the English Wikipedia article Vietnamese numerals. Similar to Module:number list/data/ko, the number list should include both the native Vietnamese and Sino-Vietnamese transliterations. Does anyone here know how to do this? Thanks in advance! ChemPro (talk) 05:53, 4 May 2024 (UTC)[reply]
@ChemPro I can try to help you with that, but first you should try to make the module by copying the Korean one and filling in the corresponding Vietnamese forms. Benwing2 (talk) 18:48, 4 May 2024 (UTC)[reply]
@Benwing2 Hello, thanks for fixing the error. I have some remarks on what still needs to be improved or implemented:
For numbers which include the digit 1 from 21 to 91, the number 1 is pronounced as mốt.
Even though năm chục (50) is an alternative form to năm mươi, it is not used to construct numerals from 51 to 59 (the same principle applies to all the multiples of ten from 20 up to 90)
Wiktionary bot is preventing me from turning this page ناـ to a redirect to نا. Everytime I tried, it's being labeled as a potentially harmful action. The page formerly contained prefix entries for 4 languages. I appropriately moved them to نا. - Ash wki (talk) 10:08, 4 May 2024 (UTC)[reply]
@Ash wki: I have done the intended page for you, surely the filter distinguishes us by user rights. But I think admins should give you autopatroller, I have observed meticulously clean and reasonable edits in you. Note that according to the discussion Wiktionary:Beer parlour/2024/April § Arabic-script affixes @Benwing2 wanted to move affixes, probably to contain the character ـ, anyway, so you might want to put in your voice there. Fay Freak (talk) 11:35, 4 May 2024 (UTC)[reply]
@Aaron Liu Weird. When you log in, there's a button to remember the login for up to a month or so; do you have that checked? Also I've found that if you log out of any MediaWiki site, it logs you out of all of them. Benwing2 (talk) 18:46, 4 May 2024 (UTC)[reply]
I'm currently trying to improve the state of Polish dialects and subdialects, showing the hierarchy and what-not. Would {{dialect synonyms}} be the best option? The idea isn't exactly to show synonyms, but just different reflexes of the same word. Vininn126 (talk) 06:22, 5 May 2024 (UTC)[reply]
Synonyms, as I understand it, have different morphemes, alt forms don't; in short these would be alt forms. I'd be wary of placing dozens of these by village in a hard to structure alt forms section, it would be nice to organise subdialects by dialect and to be able to host many easily. But I'm wary as this seems to be for synonyms. Vininn126 (talk) 08:07, 5 May 2024 (UTC)[reply]
@Vininn126 This sounds like a job for Descendants. Can you not put them on the proto-page and direct other pages to that page? BTW this is related to my post (maybe in the BP) about creating a generalization of {{alt}}. We may need a generalization of {{desc}}/{{desctree}} as well for these purposes. In general I'm not a fan of the dialect synonyms approach of using a separate module for the actual synonyms/alt forms/etc.; that is the approach used by {{etymtree}} and it didn't work. Benwing2 (talk) 19:47, 5 May 2024 (UTC)[reply]
@Benwing2 They are indeed descendants. It could be possible to set up there, but there's also the issue of how to list them on the Polish page itself. The alternative forms section and {{alt}} might lead to a huge mess. Vininn126 (talk) 07:11, 6 May 2024 (UTC)[reply]
@Benwing2 That's not my intention. Dialectal forms would most definitely be listed on the Standard Polish reflex. My issue is how to do that. The forms themselves would also be soft redirects (although this also sometimes gives pause to wonder, as they often don't always have the same definitions. They don't have the same declensions either, but I can make templates for that). The issue is if I have for example lekarz (which it might have?) with 6-10 forms and labels, it might not sound that bad, but I think giving it more structure would aid the reader, i.e. being able to organize subdialects by dialect and also maybe even geographically. Vininn126 (talk) 07:23, 6 May 2024 (UTC)[reply]
@Vininn126 It does sound like you want a generalization of {{desc}}/{{desctree}} for use in Alternative forms or whatever. I think structuring it the way that Descendants sections do it would work well. Benwing2 (talk) 08:03, 6 May 2024 (UTC)[reply]
@Benwing2: have you tried clicking on the wikilink in the title? I suspect it has something to do with interaction between characters in the pagename and the wikitext generated by the modules for the categories, though I have no clue whether it's the modules or the js or both that's doing it. Chuck Entz (talk) 20:31, 5 May 2024 (UTC)[reply]
@Theknightwho Can you please take a look at this? This is happening in makeSortKey in Module:languages. The pagename passed in is < >, which is the actual pagename (rather than the "Unsupported titles" version), and line 1282 removes HTML tags, with the result that the sort key is an empty string, which is why the display shows garbled. I don't know why you are removing HTML tags but it clearly will interact badly with any pagename that looks like an HTML tag or contains HTML tags in it. Benwing2 (talk) 21:32, 5 May 2024 (UTC)[reply]
@Benwing2 Yes, this is something I’m aware of but a proper fix may not be straightforward, and may need to wait until the proper rewrite and disentanglement of the links and languages modules is ready. In the meantime, it should be possible to use the original input as a backup if the result is the empty string. Theknightwho (talk) 22:06, 5 May 2024 (UTC)[reply]
@Benwing2 The (short-term) solution was for format_categories in Module:utilities to use data.encoded_pagename from Module:headword/page as the sort base instead of data.pagename, as that effectively instructs :makeSortKey() in Module:languages to treat any formatting characters in the input as literal, which makes sense if they're included in the actual page title. This isn't ideal, though: I don't think Module:languages should be dealing with escapes or handling formatting characters at all, as they should only be dealt with by modules which handle raw inputs and final outputs. Theknightwho (talk) 18:12, 7 May 2024 (UTC)[reply]
@Theknightwho OK thanks! What you say makes sense; where would you move the makeSortKey() functionality that deals with escapes and formatting characters? Also under what circumstances can HTML end up in the sort key and need to be removed? Benwing2 (talk) 19:34, 7 May 2024 (UTC)[reply]
@Benwing2 If I remember correctly, the original reason I added this is because inputs like {{head|en|foo|head=<sup>bar</sup>}} would push <sup>bar</sup> through :makeSortKey(), but I don't know if that's still the case.
The ideal situation would be for the Module:languages functions like :makeSortKey(), :makeDisplayText() (etc.) to treat their inputs as literal, with any formatting issues being handled by Module:links, Module:usex (or whatever), but that's only feasible if we have a consistent way to handle raw inputs, since they're non-trivial to deal with. This is what the wikitext parser is supposed to do, because it generates a "wikitext object" which can be processed in whatever way is needed while retaining any formatting in the text. However, it's hard to do that while ensuring good enough performance, because it needs a custom regex engine if you want to have string function functionality.
For sortkeys specifically, the solution is just to convert the wikitext object into the display text as a string (i.e. raw input → wikitext object → display text), which effectively amounts to removing any formatting characters, but it doesn't make sense to add all the extra complexity of parsing wikitext just for that. Theknightwho (talk) 19:46, 7 May 2024 (UTC)[reply]
Enabling collapsed quotations on Appendix: and Reconstruction: pages
The issue is some of our reconstruction only languages actually have quotations, if I understand correctly... Which means they aren't reconstruction only. Vininn126 (talk) 17:00, 5 May 2024 (UTC)[reply]
Yeah this is related to the issue with Proto-West-Germanic kamb being attested, which still hasn't been resolved. Benwing2 (talk) 19:40, 5 May 2024 (UTC)[reply]
It's coming from MediaWiki updates, which are announced at WT:Wikimedia Tech News/2024 (we really should get Tech News sent to GP imo).
The look might take a bit of getting used to, but I can already see the benefits. For instance, being able to see at a glance how recently each discussion was contributed to, rather than trawling through signatures, is clearly useful – it's proven its value on Wiktionary's mobile view, where it has been visible for some time.
It really only helps in longer discussions and wastes space otherwise. In any event, the at-a-glance feature at watchlist is more useful and saves, rather than wastes space. 14:23, 7 May 2024 (UTC) — This unsigned comment was added by DCDuring (talk • contribs).
@This, that and the other BTW according the their Tech News 2024-18, they did a one-year A/B test of this feature and analyzed the outcome based on factors like how many replies they see and such. I'm impressed that they put the effort into doing this test (and one year is a very long time for an A/B test, but I understand that this may have been necessary to get statistical significance). Benwing2 (talk) 22:19, 7 May 2024 (UTC)[reply]
Yuck. They should have made a legacy toggle in the settings. If someone creates a CSS override that restores the original appearance, please ping me. -- Sokkjō04:18, 8 May 2024 (UTC)[reply]
I'm trying to contribute to wiktionary and would like to analyze the category links and make sure they are correct but I'm not able to manipulate the sql files. They are too large and my software crashes. How do you guys do it? This is the file I'm talking about
It is 5 gigs. I tried importing it into Navicat but it did not work. I even tried divided the files into a mere 1/50th of its size and that could not work either. Kylefoley202 (talk) 07:19, 8 May 2024 (UTC)[reply]
@Kylefoley202 These are certainly very large files. There are a few ways to proceed:
If you just want to issue SQL queries against the categorylinks table, use Quarry.
You could set up a local installation of the MariaDB database server on your computer and use the provided command line tools to run the SQL script against your local server.
Or else write a simple script (say in Python) to parse the SQL file character by character. Here's a rudimentary script I wrote a while ago that converts a different table's SQL script (pagelinks) to CSV:
More information
importsyswithopen(sys.argv[1])asfile:forlineinfile:prelude='INSERT INTO `pagelinks` VALUES 'ifnotline.startswith(prelude):continuepos=len(prelude)whileline[pos]=='(':lineToPrint=''keepThisLine=True# Opening bracketpos+=1# Page IDwhileline[pos]!=',':lineToPrint+=line[pos]pos+=1assertline[pos]==","lineToPrint+=','pos+=1# Target namespace - only allow ns0ifline[pos]!='0':keepThisLine=Falsewhileline[pos]!=',':lineToPrint+=line[pos]pos+=1assertline[pos]==","lineToPrint+=','pos+=1# Page nameassertline[pos]=="'"pos+=1whileline[pos]!="'":ifline[pos]=='\\':pos+=1lineToPrint+=line[pos]pos+=1assertline[pos]=="'"pos+=1assertline[pos]==","pos+=1# Source namespace - only allow ns0ifline[pos]!='0':keepThisLine=Falsewhileline[pos]!=')':pos+=1ifkeepThisLine:print(lineToPrint)assertline[pos]==")"pos+=1ifline[pos]==';':breakassertline[pos]==","pos+=1
Thanks, I already wrote a python script to parse the sql file and I am rolling and in action. I want to work on getting the IPA transcriptions of English words correct for the purposes of perfecting the rhymes categories. I'm a poet after all. I also want to build an app that both outputs sublemmas given a lemma and also output lemmas given sublemmas. I want to correct any mistakes I find in Wiktionary. I need to figure out how to quickly insert edits into wiktionary with software then upload them in a quick and painless manner. Kylefoley202 (talk) 19:50, 8 May 2024 (UTC)[reply]
@Kylefoley202 In terms of making changes to individual pages, you should use pywikibot, maybe in combination with mwparserfromhell to parse the wikitext. My bot scripts [6] do this, e.g. the find_regex.py script lets you download pages using various selectors, and push_find_regex_changes.py lets you upload pages after making changes in a text editor. Benwing2 (talk) 21:37, 8 May 2024 (UTC)[reply]
@Kylefoley202: Please read WT:BOT. Before you make mass changes to Wiktionary entries, you need to show the community that you know what you're doing and that you will edit according to Wiktionary standards. You should also be aware that Wiktionary has its own ways of doing IPA that have been developed through discussion and consensus, so you might unintentionally fix some things that aren't really broken. I'm just saying this for the record. I'm sure you're responsible and know what you're doing. Chuck Entz (talk) 14:29, 9 May 2024 (UTC)[reply]
Following up on TT&O's suggestion above: Apparently WT:Wikimedia Tech News/2024 often contains changes relevant to many of us. Would it make sense to post a link the section of the subpage that had the latest posting? The full text would not be necessary and would take up a lot of space. (There have been 19 postings (~weekly) so far this year!) Presumably, anything that someone objected to, didn't understand, etc. would be made a topic. DCDuring (talk) 17:53, 8 May 2024 (UTC)[reply]
Another approach would be for someone to red Tech News and try to anticipate which items would be of interest to our active users. DCDuring (talk) 17:58, 8 May 2024 (UTC)[reply]
One other idea: right now, and then once at the start of each year, briefly use the same round-robin-esque move technique that keeps each new month's GP on the watchlist of everyone who watchlisted the previous month's GP, to move the year's Tech News page to here so that everyone who watchlists the GP (and is presumably interested in technical matters) also has the Tech News page on their watchlist. If that page is only updated about once a week, compared to the GP being updated many times a day, it should not be a burdensome thing to have in one's watchlist. (There is, of course, also the option of just getting Tech News delivered here, as suggested in the section above and on several prior occasions when it's happened that people failed to notice something which was technically announced in Tech News. This...honestly might be the better idea, since again, one update a week probably won't make the GP so large as to cause problems.) - -sche(discuss)19:47, 8 May 2024 (UTC)[reply]
I want to go through all of the IPA transcriptions of words, check them and make sure they're correct, then correct the ones that are wrong. Is this possible to do with Quarry? I have already written some Python code, that goes through and sort of does that but of course it's not 100% accurate. I'm using one of the files uploaded here, I forget which one: https://dumps.wikimedia.org/enwiktionary/latest/
I realize I should have asked this question before I wrote the code, but, hey, live and learn. Also, I'm not very good with MySQL, in fact I just started learning it yesterday, so if you know of MySQL code that does this please post it.
I also have a similar ambition to link all of the sublemmas to their superlemma. Is that also possible? Kylefoley202 (talk) 04:47, 9 May 2024 (UTC)[reply]
Why does Wiktionary put all words in all_caps on this sheet? How does Wiktionary know how to input that line 1 into website 2? Kylefoley202 (talk) 06:56, 9 May 2024 (UTC)[reply]
@Kylefoley202 what you have found is the category sort key, which is capitalised because sorting is case-insensitive. What you have to do is look at the page ID (that number at the beginning) and cross-reference this with the "page" table. See the MediaWiki database schema for more details. (Hint - the table names in the database schema diagrams are links to pages with much more info about the table.) This, that and the other (talk) 10:57, 9 May 2024 (UTC)[reply]
@Kylefoley202 Just FYI, I would recommend not bothering with SQL but just directly reading the "pages-articles" file [7], which contains all the current content (as of the date of the dump) for all pages. It is pretty easy to parse, either using mwparserfromhell or just rolling your own parser. If e.g. you are interested in English IPA transcriptions, you just need to look for pages that have an {{IPA|en|...}} template in them and pull out the IPA content. Benwing2 (talk) 21:03, 13 May 2024 (UTC)[reply]
@Surjection My suspicion is that the "term" (i.e. what's normally the link target) is being treated as the empty string somewhere in the process, and this is what gets used as the sortkey, since that's what's causing the category target to fail. There's special handling for the link itself in situations like this, since the alt text gets displayed instead of a failed link to nowhere, but there needs to be something for the sortkey as well. @Benwing2 is much more familiar with the affix module(s) than I am. Theknightwho (talk) 14:09, 9 May 2024 (UTC)[reply]
@This, that and the other: It turns out that the desktop case isn't so pathological after all — on 𑀏𑀓𑁆𑀓, the floated number box is wide enough to consume the header even on desktop. I strongly recommend that you implement my original request. Also, that documentation is clearly wrong, as it claims that mobile view also doesn't load user-defined stylesheets. If that were the case, I wouldn't have been able to post those screenshots. Ioaxxere (talk) 13:29, 10 May 2024 (UTC)[reply]
It turns out that my change causes some problems with talk pages. Could you change the selector to h1, h2:not([data-mw-thread-id]), h3, h4, h5, h6? Ioaxxere (talk) 17:46, 10 May 2024 (UTC)[reply]
Regarding whether Common.css is loaded for mobile users: at least historically, it definitely wasn't, because over the years we've had to copy various bits of useful code from Common.css to Mobile.css because they were visibly not being loaded on mobile. (It would not surprise me if personal User/common.css pages function differently.) Surely we could just test this, though, e.g. by adding a test class to the main Common.css (but not Mobile.css) that makes things tagged with that class show up e.g. at 300% size and bright green, adding some text tagged with that test class to this discussion, waiting a while for caches to clear and such, and then seeing whether the text is in fact big and green on mobile. - -sche(discuss)15:26, 12 May 2024 (UTC)[reply]
@-sche I'm curious to find out as well. I've tagged this text with the class bigandgreen, so if it looks unusual on the mobile skin then we'll know for sure. Ioaxxere (talk) 19:46, 12 May 2024 (UTC)[reply]
I recall someone mentioning there was an unavoidable 5-minute delay before changes take visible effect: sure enough, for the first 5-7 minutes (both before and after clearing my cache) I was not seeing the text display any differently than normal on either Desktop or Mobile, logged in or logged out, on Firefox or Chrome. However, I do now see the big green text (and slightly more complex vertical and backgrounded/highlighted text) on Desktop, whether logged in or out, on Firefox or Chrome, as expected. I do not see any of that styling when I use the Mobile version of the site in Firefox or Chrome from my computer, nor when I use my actual mobile, so indeed it appears that only Mobile.css and not Common.css is loaded for mobile users (as expected). But I'll leave the test classes in place for another couple days in case it's a caching issue or anyone wants to test anything else, other browsers, etc. - -sche(discuss)05:34, 13 May 2024 (UTC)[reply]
Yeah I have run into that delay too. The message telling you to clear your cache is misleading and we should change it. Benwing2 (talk) 20:45, 13 May 2024 (UTC)[reply]
I've removed the test class, and can offer the following data about how soon changes take effect: I removed the "big and green"-ification text at 22:14, and the text above was still big and green (unchanged) at 22:15–22:18; the text changed back to normal when viewed via Tor at 22:19 (just five minutes), but was still unchanged when I viewed it from my 'usual' browser until 22:24 (ten minutes). (The difference is, I assume, to do with the fact that I had no 'cache' in Tor, but had the big green text in my cache in my usual browser.) - -sche(discuss)22:31, 17 May 2024 (UTC)[reply]
@This, that and the other: When I converted {{cite-book}} to use Module:quote, I made it automatically set |t=- if no translation is provided to suppress the "Please add a translation" message for compatibility with the original behavior of {{cite-book}}. I didn't realize that it was generating categories, too. I can add handling for |t=! to suppress the nag and suppress the categorization unless anyone has a better suggestion for handling this. JeffDoozan (talk) 01:12, 11 May 2024 (UTC)[reply]
@JeffDoozan This use of |t=! seems a bit hacky and will expose this to the end user (which might not be wanted). What I might do instead is set an additional flag in the call to format_usex() to suppress the request-for-translation category (note that the category is already suppressed if the language is English or Translingual). Benwing2 (talk) 22:03, 11 May 2024 (UTC)[reply]
While things are now better, how do I stop {{cite-journal}} with text being recorded as a quotation? The problem occurs in the use of {{Template:R:xsv:Zinkevičius85}}, which cites an article in Luthuanian that gives a Sudovian word list. Expanding |1=lt by adding |termlang=xsv switched the categorisation from terms with Lithuanian quotations to terms with Sudovian quotations, but these aren't quotations: they're mentions of Sudovian words. --RichardW57 (talk) 07:01, 14 May 2024 (UTC)[reply]
I did try both |brackets=1 and |brackets=on, but they seemed to leave it as being a quotation. Additionally, as it's a citation, the author came first, which caused a Wikimedia parsing problem because the author text is a Wikimedia link - the author has a Wikipedia article on the Lithuanian Wikipedia but not the English Wikipedia.
What should happen when |mention=1 is provided? Does it suppress all categories? Add them to a new category? Change the formatting? If it's just suppressing the categories, would using the existing |nocat=1 to suppress all categorization work? JeffDoozan (talk) 14:10, 14 May 2024 (UTC)[reply]
Early access to the dark mode (mobile web, logged-in)
Hi everyone, as announced in November, the Web team at the Wikimedia Foundation is working on dark (sometimes also called night) mode. Now, we have released the feature for logged-in users of advanced mobile mode across all wikis for testing purposes. But don't worry, the new feature is not disruptive! (See the "known limitations" section below.) It's just important for us to work together with you before we release this feature to a wider audience. Our goals for the early rollout are to:
Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
Get your help with flagging bugs, issues, and requests
Work with technical editors to adjust various templates and gadgets to the dark mode
Go to the project page and the FAQ page to see more information about the basics of this project.
Known limitations of the initial release
Currently, dark mode is only available on mobile, for logged-in users who have opted into advanced mode, as an opt-in feature.
Gadgets may initially not work well with dark mode and may have to be updated.
Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.
What we would like you to do (the broad community)
If you have questions - ask us! Also, where appropriate, consider linking to the Recommendations for dark mode compatibility on Wikimedia wikis on pages explaining how to define colors in code. Soon, this page will be marked for translation. We would like to emphasize that the recommendations may evolve. For this reason, we are not suggesting to create your local wiki copies of recommendations. At some point, the copy could become different from the original version.
What we would like you to do (template editors, interface admins, technical editors)
When most bugs are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. To make this happen, we need to work together with you on reporting and solving the problems.
To turn it on, use the mobile website and go to the settings part of your menu and opt into advanced mode, if you haven't already. Then, set the color to dark. (Later, we will be allowing the device preferences to set dark mode automatically).
Next, go to different articles and look for issues:
If you have noticed an issue with a template but do not know how to fix it
Exciting. I tried it just now and notice the following things: as you say, WT:SB reports that it is only available in light mode. On mainspace pages, the few things I could think of to check all worked just as well in dark mode as in light mode. MediaWiki:Gadget-OrangeLinks.js works (in both light and dark mode) to turn a link orange if it is specifically 'tagged' with a specific language which isn't present on the linked page; conversely, whereas on desktop bare [[wikilinks]] like that are sometimes colored orange when they are implied to be pointing to a section which isn't present, on mobile this is not the case (probably just because whatever local en.Wiktionary functionality turns such links orange on desktop has been deemed by us too large or complex to turn on for mobile). In other words, on desktop, both [[suadero]] and {{l|en|matambre}}in this revision of rose meat show up as orange (as neither page has an English section yet), but on mobile only {{l|en|matambre}} is orange (and it is orange in both light and dark view), whereas [[suadero]] is blue. - -sche(discuss)19:40, 10 May 2024 (UTC)[reply]
I guess I don't understand what the big deal is about dark mode. Back in the old old days of TRS-80's and such, "dark mode" was the only thing you got and people hated it, hence the switch to black-on-white text. Benwing2 (talk) 21:46, 11 May 2024 (UTC)[reply]
It's for people on phones or laptops in dark places, particularly to avoid eye strain or so as not to bother others. No, it's needless on desktops but can still be a personal preference. — LlywelynII22:05, 16 May 2024 (UTC)[reply]
Or married users who relax (and protect their IRL relationships) by correcting nameless strangers on the internet, don't have free time before the kids go to bed, and can't stand most of reddit. Lots of specific use cases. — LlywelynII02:20, 19 May 2024 (UTC)[reply]
Some issues I noticed at a cursory glance:
The coloured backgrounds for {{top3}} and friends need to be inverted. But the text is still perfectly legible.
Same for the coloured backgrounds of the content of collapsible boxes like {{trans-top}} and practically all our inflection templates. However, this is not a big deal, as (a) the text is still legible, and (b) the boxes are initially collapsed so do not really interfere with the overall "dark" look of the page.
Was just looking for this. I don't understand why it would only be enabled for mobile where the phone and apps themselves can already shunt everything to dark mode from it. Desktop/laptops are where it's actually needed on site. — LlywelynII22:05, 16 May 2024 (UTC)[reply]
Just like previously, when we were releasing it on mobile, this is still an early rollout. The goals are the same: both technical volunteers and the Web team need a lot of space for collaboration on the existing code before dark mode may become available for logged-out users. The limitations of our dark mode haven't changed much either: we're still focusing on the main namespace. Later, the feature will be available on other namespaces.
Finally, our requests to you are the same: we're inviting technical editors to make the main namespace dark mode-friendly, and if you have any questions, we welcome your questions. Check out the Accessibility for Reading project page and the FAQ page to see more information about this project. Thank you!
It needs Vector 2022? Eh, thanks but no thanks. I like having usable space on the page... But yeah, keep at it and thanks for your work. — LlywelynII02:23, 19 May 2024 (UTC)[reply]
This initially was for displaying bibliographic details and an optional first parameter for some unspecified text that was simply displayed if present. @Poketalker envisioned it as having an optional numeric first parameter for the volume number, and wrote the documentation that way. When @JeffDoozan converted it to use Module:quote, he assigned the first parameter to the |section= parameter.
The problem is that all but a couple of uses that had a first parameter had non-numeric text in it consisting of things like "Poem 1". When Poketalker added code to convert the section number in the first parameter to a section name, this caused ParserFunction errors in almost the entire transclusion list because the code did arithmetic on non-numeric text. I fixed a handful by adding a pipe to add empty first parameter, then got tired of it and posted on Poketalker's talk page to let them know about the problem. Their attempts at fixing the problem haven't been successful.
So, what can be done about this? After Poketalker's "fix" there are "only" 51 entries in Category:Pages with ParserFunction errors. That's unacceptable. I see a few potential ways out of this.
Restore the code to do arithmetic on the first parameter and have a bot add a pipe in front of all non-numeric first parameters
Figure out some way to check if the first parameter is numeric, and either apply the arithmetic selection code if it is or treat it the same way as the optional second parameter if it isn't.
Get rid of the whole volume number concept and code, since only a couple of entries actually use it.
A secondary question is whether this even needs to use a module. It looks like most of the usage is of this template followed by the actual quotes and their translations (on separate lines using other templates). The following lines could be converted into parameters for an improved template, but without that, the module contributes nothing.
Thanks to @Chuck Entz for bringing this up and @Benwing2 for fixing the issue. I think I remember bringing up concerns about using Lua for this template, as it was quite simple to begin with, and the module's behavior didn't seem compatible with how the template was actually used. Glad to hear it's been resolved. ‑‑ Eiríkr Útlendi │Tala við mig18:53, 17 May 2024 (UTC)[reply]
e.g. "Latest comment: 22 hours ago | 1 comment | 1 person in discussion | Subscribe". How to get rid of this and go back to normal? Equinox◑20:56, 10 May 2024 (UTC)[reply]
Having it give "Latest comment" information in diffs is just bizarre. Not only is there better and more accurate information in the diff header, it treats the diff as the latest comment, even if you're looking at very old diffs. While it's technically true that the diff was (by definition) the latest comment as of the time on the diff, it's utterly pointless and somewhat misleading. Chuck Entz (talk) 01:28, 11 May 2024 (UTC)[reply]
@Benwing2: The same place it does when you view a page the usual way. Under where it says "Wiktionary:Grease pit/2024/May: difference between revisions" is a link to the parent page "<Wiktionary:Grease pit". Below that is where the new system says something to the effect of "Latest comment [] hours ago by []". I've turned the new system off, so I can't give you specifics, but the number of hours ago and the author of the content apply to the diff being viewed, not the conversation as a whole. It kind of makes sense if you think of the diff being a snapshot of the state of the page as of the time of the edit, but it's redundant to the diff header:
Revision as of 14:44, May 11, 2024 edit undo thank
Benwing2 (talk | contribs)
(How to turn off the new thing on talk pages: Reply)
(Tag: Reply)
The above is the diff header for the edit I'm replying to, minus a couple of admin-only bits. I have a gadget enabled that adjusts time stamps to local time, so you'd have to add 7 hours to get the usual UTC. The new system would say something like "Latest comment 1 hour ago, by Benwing2", ignoring any later comments to the same topic. In this case there aren't any, but I seem to remember seeing a case where someone posted a reply, then someone else posted a reply, with only the first reply reflected when I viewed the diff for the first reply: i.e., if you posted a reply to a given topic, and Sgconlaw posted a reply to the same topic an hour later, it would say "Latest comment 2 hours ago by Benwing2" when I viewed the diff for your edit, but "Latest comment 1 hour ago by Sgconlaw" when I viewed the next diff. Chuck Entz (talk) 22:18, 11 May 2024 (UTC)[reply]
@Chuck Entz I see, now, yes. You have sharp eyes; I didn't even notice the "Latest comment" stuff at the very top of the page, only the one underneath individual section headers. Benwing2 (talk) 23:51, 11 May 2024 (UTC)[reply]
This is indeed bizarre and useless, from what I can see, which you and the site coders might be interested in due to my attention atypicalities. Not that I would pay attention to it. I was delighted when first seeing the new thing, while I also use Vector 2022 as the site skin. Fay Freak (talk) 23:29, 11 May 2024 (UTC)[reply]
Another problem: suppose I want to link to a specific section of a talk page. I think there used to be a table of contents, or a right-clickable link ("copy to clipboard") or something, but now I can't find a way to grab that section link. Equinox◑12:16, 12 May 2024 (UTC)[reply]
@Equinox: I do have the anchor symbol giving me the link due to a gadget. Preferences → Gadgets → User interface gadgets → ⚓: add copyable anchor links to sections Fay Freak (talk) 12:21, 12 May 2024 (UTC)[reply]
Well, you should wonder, you have habitually coded websites, I assume, this is one of the things one notices then. I don’t read hover texts much. How people of your branch are wont to respect the tooltips in xkcd comics, rather than continuing information being hidden in such a way discontenting them, is beyond me: this is how it always looks to me. It should have a text for text-based browsing I guess, now somebody has to find where to add the source line. Fay Freak (talk) 12:45, 12 May 2024 (UTC)[reply]
I hate doing Web sites. I still spell it "Web site" because I am a Victorian Charles Dickens. But nobody wants a bloody Windows desktop app any more. sigh sigh. Equinox◑19:52, 12 May 2024 (UTC)[reply]
What's weird is that it only does this with kyūjitai spellings. Other alternate forms, such as hiragana spellings, categorize correctly. Binarystep (talk) 05:05, 14 May 2024 (UTC)[reply]
I don't know if changes have been made in the hour or so since Binarystep Benwing posted, but the kyūjitai, kana, and kanjitab all appear blue to me. I'm using Firefox web browser on a Windows 11 computer, if that's any clue. Cnilep (talk) 06:20, 14 May 2024 (UTC)[reply]
@Cnilep They appear orange to me, too, after a couple of seconds for the OrangeLinks gadget to do its thing. Do you have that gadget enabled? Benwing2 (talk) 06:51, 14 May 2024 (UTC)[reply]
Given that kyūjitai spellings are the old, deprecated spellings, and that we put all the "main" info elsewhere, I think categorizing these as "non-lemmas" would probably be best. ‑‑ Eiríkr Útlendi │Tala við mig18:56, 17 May 2024 (UTC)[reply]
Yeah I think the precedent here would be to make them lemmas, although I would be supportive of User:Nicodene's and User:-sche's proposal to treat alternative forms as a third type of term, neither lemma nor non-lemma but "alternative form" (on a language-specific level, and not so much for one-off alternative forms like in English, but for languages with systematic alternative forms either due to a lack of standardization at the time or due to spelling reform, as in this case). Benwing2 (talk) 23:52, 17 May 2024 (UTC)[reply]
Hi, In the page ドラマティック, I have noted that the romaji transcription of the inflections wrongly duplicate the inflections ("doramatikku na na" and "doramatikku ni ni", with twice "na" and twice "ni"), even though the Japanese forms are correct (ドラマティックな and ドラマティックに, with a single な [na] and a single に [ni]). The problem seems to come from the template {{ja-adj|ドラマティック|infl=na}}. Can somebody please check? Thank you in advance. SenseiAC (talk) 12:27, 13 May 2024 (UTC)[reply]
A while ago, a troll was adding 'bad' images to entries, so we (someone) copied Wikipedia's image blacklist over to MediaWiki:Bad image list. This included images that don't exist (deleted but never cleared out of WP's list; I cleared them out of ours), redirects (where if the troll wanted to use the image, they could, because only the redirect is on the list🙃), and images we're validly using which blacklisting broke. By chance, I've happened upon and been able to un-blacklist two (the nipple at nipple and swastika at Nazism); can someone check whether any other images on the "bad image list" are actually in use and thus need to be unblacklisted? - -sche(discuss)06:56, 14 May 2024 (UTC)[reply]
{{Cyrl-def|ru|name|А}} and {{Latn-def|en|name|A}} result in “The name of the Cyrillic script letter А.” and “The name of the Latin-script letter A/[[{{{4}}}#English|{{{4}}}]].”, respectively, because {{Latn-def}} requires specifying the lowercase letter, whereas {{Cyrl-def}} does not; is this intentional? I noticed this issue in the Russian entry for И. J3133 (talk) 07:37, 14 May 2024 (UTC)[reply]
@J3133 It looks like User:Theknightwho did some hacking on the Cyrillic one in 2022, and part of that was changing it to not have a |onecase= flag to signal whether there's a lowercase equivalent, but rather checking the value itself. We should probably do the same for {{Latn-def}}. Benwing2 (talk) 06:48, 15 May 2024 (UTC)[reply]
So I have my own local MediaWiki installation and I have a bit of a "dictionary" on it where I store words from my English idiolect and also my conlang. So far, it uses "approximations" of Wiktionary templates, not the full templates themselves, as I once tried to import all of Wiktionary's templates, but ran into issues, as the wiki itself has significant amounts of imported Wikipedia templates, and thus name conflicts arose.
The only "Wiktionary for conlangs"-type site I've encountered looks to be Linguifex's Contionary, but they too take the same approach of approximating Wiktionary templates with markup - see Attian ethnema ("language"). Another entry even had a manually coded inflection table.
As for Wiktionary - adding support for another conlang should hopefully be easy. I know a little bit of lua, and when it comes to conlangs, Wiktionary's done it for Esperanto so it stands to reason I can do the same for my own conlang on my local instance.
I'm thinking I could possibly set up another MediaWiki instance and have the dictionary stuff over there. Maybe even make a "MediaWiki Conlang Starter Kit" that only has English in it and leave it up to the user to write their own Lua. Who knows? A diehard editor (talk) 07:55, 15 May 2024 (UTC)[reply]
Now that I think about it: the primary source of the difficulty is the immense amount of baggage Wiktionary templates have by having to support hundreds or thousands of natlangs whereas the typical conlanger would only need English support to start with and then a blank canvas to write Lua modules for their conlang. Perhaps conlangers are better off just writing the needed modules from scratch? A diehard editor (talk) 08:19, 15 May 2024 (UTC)[reply]
With no disrespect to your project intended, I hope you understand that we already stretched technovolunteers may not be able to spare the time to help you set up a hobby wiki on your own machine.
Having said that, new Wiktionaries do start up from time to time; just this year the Karakalpak Wiktionary started. I wonder if these communities would find it useful if we did have a guidance page (either here or on Meta-Wiki) on how to set up a basic infrastructure of templates. Otherwise they are expending what are probably limited technovolunteer resources to reinvent the wheel. This, that and the other (talk) 10:26, 15 May 2024 (UTC)[reply]
Do not worry, I do not expect any labor. I was only curious to see if there were already resources on how to do this. When I first installed MediaWiki back in February 2022, I did this with the knowledge that it'd be just me, the docs, and reverse-engineering Wikipedia templates that got me through.
Wow, so what it seems like is happening is that it's creating a link to a category, as you would like this: [[:Category:Swedish lemmas]] to create Category:Swedish lemmas. What is really weird is that it isn't doing that for the Latin entry... These may need to be manually edited instead of using the templates in this instance. —Justin (koavf)❤T☮C☺M☯20:53, 16 May 2024 (UTC)[reply]
User:Theknightwho You might find this interesting. The issue is that : is considered a diacritical mark to remove when sorting in Finnish, but not in Latin. I'm not sure why this is the case, but I added a hack in format_categories() to fall back to pagename_defaultsort if the sort key ends up a blank string. Benwing2 (talk) 22:11, 16 May 2024 (UTC)[reply]
@Benwing2 I assume it's because Finnish (and Swedish) use : as a suffix separator after abbreviations, in the same way English sometimes uses ' (e.g. see the declension table at Finnish CD). Thanks for sorting it. Theknightwho (talk) 22:18, 16 May 2024 (UTC)[reply]
Sorry, I did not check carefully. Thank you for identifying this error. By the way, is the category "Dialectical XXX" used exclusively in Chinese? --TongcyDai (talk) 19:47, 16 May 2024 (UTC)[reply]
I did not know that miàntán was an entry and sure enough, it is. If anything, I think that should be linked. Who is helped by having these romanizations not linked from the native script entry? I'm just struggling to understand why that's a better thing than including a link for the convenience. Do you think that we should have entries for these romanizations? If so, why is having them and not linking them a good thing? —Justin (koavf)❤T☮C☺M☯06:42, 17 May 2024 (UTC)[reply]
@Atitarev: So how does that answer my question? My question was: "Are there other romanizations that we have as entries that are unlinked?" and you gave me an example of one that's linked... In the past few comments you have written, "We don't link romanisations otherwise" and "It's ... linked". What am I missing here? —Justin (koavf)❤T☮C☺M☯06:57, 17 May 2024 (UTC)[reply]
@Koavf The question is whether we have ones that are unlinked in link templates like {{l}}, which does apply to Chinese. Of course Chinese entries link to romanisations from the entries themselves, but that was always the case for Japanese as well. I doubt there are any languages that completely unlinked romanisations, which I wouldn't support, but no-one's advocating that for Japanese, so it's not relevant. Theknightwho (talk) 12:27, 17 May 2024 (UTC)[reply]
Addressing this specific question: "why is having them [romanizations] and not linking them a good thing?"
Romanized entries for languages that don't use the Latin script are, so far as I'm aware, pretty much always created as a kludge to get around defective search features in the MediaWiki platform we use. As the English Wiktionary, for input purposes, we can safely assume only that our users are easily able to input characters available on an English-language keyboard. (There are obviously workarounds like individual glyph lookup and copy-paste, but these can hardly be called good usability.) Entries like sakura#Japanese only serve to direct readers to the native-script kana entries, and as such are only ever soft redirects. These provide readers with basically no useful information, and as such, we do not link to romanized forms when using {{m}}, {{l}}, and other linking templates. ‑‑ Eiríkr Útlendi │Tala við mig19:14, 17 May 2024 (UTC)[reply]
Input needed
This discussion needs further input in order to be successfully closed. Please take a look!
I doubt anything gets fixed but I discovered that capitalisation no longer works either with "^" symbol 富士山(fujisan). I doubt because it seems the modules have become so complicated that nobody, including creators or editors seem to be able to fix them, let alone enhance them any more. Anatoli T.(обсудить/вклад)02:44, 27 May 2024 (UTC)[reply]
I'd like to add more references to the World Loanword Database to Swahili. There is a template already: {{R:WOLD}}. Currently the template only allows linking to all entries for a specific language, but I'd additionally like to link to a specific entry (e.g. https://wold.clld.org/word/72141734782825923). So I guess a #5 parameter could be added but I'm not sure about the best way to format the text.
Also, it seems the template parameters could be simplified great. We use {{R:WOLD|sw|1|Schadeberg, T|2009}} for Swahili. But really "sw" should be enough and the other parameters could be looked up in a table depending on the language (editor for this language, year, number to link to, e.g. "sw" is 1, "ro" is 8).
I'm wondering if there'd be use in having {{t}} and its ilk categorize to "X language terms with Y language translations". Being able to watch a Recent Changes of that category would be quite useful for me, perhaps others. Would there be any technical issues with that? Vininn126 (talk) 08:58, 20 May 2024 (UTC)[reply]
@Benwing2 No, it wouldn't really. It's just a case of getting rid of the if-condition at Module:translations#L-103. That change adds 0.5MB of memory use and 0.6 seconds of loading time to water/translations, neither of which are particularly concerning given that it has 3 times as many translations as the page with the next-largest number, and about 20-30 times that of your average large translation section, so the difference on the vast majority of pages would be very small. Given that entries with hundreds of translations tend to have them split out to subpages anyway (which have more than enough buffer room to cope for the foreseeable future), I don't see this as being risky. Theknightwho (talk) 22:39, 21 May 2024 (UTC)[reply]
It's easy enough to find all translations for a given language using the regular search with insource:/\{t?t\+?\|ang\|/ in the search box (here's a link to it that I have bookmarked). You can replace the "ang" with any language code. I got this originally from @Fytcha, and added a parameter to the linked version to list the most recently edited pages first. See Wiktionary:Todo/Impossible translations for a page I'm developing that's based on it. Using this, I found bogus translations in an obscure Oscan Umbrian language added 9 years ago by a Malaysian IP (Special:Contributions/175.140.49.80), among other things. Chuck Entz (talk) 14:47, 22 May 2024 (UTC)[reply]
@Chuck Entz A proper regex would be quite a lot more complex (e.g. that one fails if someone's put {{ t|...}}), but these kinds of variations should be pretty rare. However, it's also not very user-friendly, whereas anyone can use categories. Theknightwho (talk) 14:54, 22 May 2024 (UTC)[reply]
The "X" is not required, since all translations are of English terms. It would just be "Terms with Y language translations" or, perhaps clearer, "Terms with Y translations". (and of course they should be hidden.) This, that and the other (talk) 05:34, 23 May 2024 (UTC)[reply]
@Vininn126WT:EL#Translations says that only English entries and Translingual taxonomic name entries may have translations. So Interlingua entries with translations should have those sections removed. I did a search for non-English, non-Translingual entries with translation sections and I only found palm#Dutch (removed by me), Panda#Latin (malformed entry, needs fixing), ayran#Turkish (removed by me) and Cardrona#Scots (tidied by me).
It's true that one might still wish to categorise translations from English separately from translations from Translingual, but this is complicated by the fact that the {{t}} template has no way of knowing what language section it is being used on. This, that and the other (talk) 09:51, 23 May 2024 (UTC)[reply]
To be honest I don't really care if it's categorized by which language has the translation. It would be convenient if it weren't, actually. Vininn126 (talk) 10:19, 23 May 2024 (UTC)[reply]
@This, that and the other @Vininn126 I think it should just be "X translations", which we already have for maintenance purposes for four languages: see Category:Translations by language: English, Translingual and Undetermined should ideally be empty, whereas Min Nan is currently being split so this is a convenient way to track down any that need converting.
I don't see the point of distinguishing between translations on English or Translingual entries, really - the only reason any Translingual entries have translations at all is because they encompass English, meaning translations are useful. Theknightwho (talk) 19:45, 23 May 2024 (UTC)[reply]
I'm not particularly in favour of "X translations". Our categories are mostly named so as to describe the entry or term itself, for example, "English eponyms" contains terms that are English eponyms, and "English transliterations of Mandarin terms" contains terms that are English transliterations of Mandarin terms. But the "X translations" category will not contain terms that are language X translations - it will contain (largely English) terms that contain language X translations. So it doesn't really fit the scheme. "Terms with X translations" seems to fit better. This, that and the other (talk) 02:30, 24 May 2024 (UTC)[reply]
If I'm being really pernickety it should be "Entries with X translations", but yeah, I agree with the overall logic of changing it from "X translations". Theknightwho (talk) 03:30, 25 May 2024 (UTC)[reply]
I'm not sure I see the need for "Entries" vs. "Terms". The entry is the page; yes, it has a translation, but the translations are associated with individual English terms on the page. Benwing2 (talk) 18:18, 26 May 2024 (UTC)[reply]
@Benwing2 Generally speaking, I've thought of it as:
"Term" = the specific link/headword (e.g. Russian terms with redundant transliterations). In many cases, there might not be an entry for the language on the page.
"Entry" = the L2 section (e.g. English entries with incorrect language header). The issue relates to the entry as a whole, which applies here as it's the entry that has X translation (though it's a weird case, as it's really "[English] entries with X translations").
"Page" = the whole page (e.g. Pages with module errors).
It seems this distinction is the one made in maintenance categories, but not elsewhere, where "terms" predominates over "entries" e.g. in etymology categories. In particular there are almost no categories beginning with "English entries ...". My thought here is that a given English L2 section may have several subsections for different POS's, etymologies, etc., and each one has a translation; the translation is not associated with the L2 section as a whole. Benwing2 (talk) 18:55, 26 May 2024 (UTC)[reply]
@Benwing2 These are maintenance categories, but that is a good point. Alright, let's make it "terms", especially if we're going to move them out of maintenance categories. Theknightwho (talk) 20:02, 26 May 2024 (UTC)[reply]
@Vininn126 Not yet - we were already categorising translations in English, Translingual and Undetermined for maintenance (as there shouldn't be any) and Min Nan (as it's being split, so they need to be converted), so I was changing those in advance. Theknightwho (talk) 19:07, 26 May 2024 (UTC)[reply]
@Benwing2 Before I do this, would it please be possible for you to bot-create a load of categories in advance? That way, we can avoid spamming the category sections at the bottom of large pages, as they won't be moved to the hidden section until they've been created. If you cover all the languages on water/translations, woman/translations and man/translations that should cover most of them, and the rest can be swept up in the usual way. The format is "Category:Terms with X translations". Theknightwho (talk) 12:51, 31 May 2024 (UTC)[reply]
@Theknightwho This is running. There are about 3,500 categories to create and since I'm using the script I normally use to create categories in Special:WantedCategories, which expands {{auto cat}} on the page before creating it (to make sure there's no error), it's a bit slower than it could be (~ 3 seconds per category, vs. 1 second if I just created the categories without any checking). So it might be done in about 3 hours. Benwing2 (talk) 22:05, 31 May 2024 (UTC)[reply]
FYI there are still several categories needing creating. I am doing all the categories found on any of the translation subpages; this adds about 380 more, let's see if that's enough. Benwing2 (talk) 02:44, 1 June 2024 (UTC)[reply]
It seems to be working as intended on Vector Legacy skin, but not on MonoBook. Tested without any add-ons turned on, on Opera GX and Microsoft Edge. Olioliluaaa (talk) 19:46, 22 May 2024 (UTC)[reply]
I have seen a number of Old Polish entries giving a Polish descendant with the linked Polish term not linking to Old Polish, or even Proto-Slavic entries linking directly to Polish when the Old Polish term linking to PS. Would it be possible to generate a list of terms in these languages so I can fix them? Vininn126 (talk) 11:43, 23 May 2024 (UTC)[reply]
@Vininn126 That's something I wanted to do for other languages. Maybe I can start with Polish and expand it later. I'm fairly busy this coming week but I can do it in early June if nobody else has done it by then. tbm (talk) 05:14, 25 May 2024 (UTC)[reply]
Latin words containing alchemical symbols (e.g. 🜍reus, 🝞atio) are being automatically categorized in Category:Latin terms spelled with emoji, although these symbols are not emojis. But this only happens to entries with multiple letters; if the entry is a single symbol (e.g. 🜄), it doesn't get categorized at all.
@Jcitawy Not categorizing single-symbol pages into terms spelled with emoji is intentional, but as for categorizing alchemical symbols, the list of emojis is in Module:headword/page and it just consists of a large range for plane 1, which includes lots of non-emoji symbols. It should be updated with the actual Unicode list, I think. Benwing2 (talk) 22:14, 25 May 2024 (UTC)[reply]
@Theknightwho: All of them: any noun or verb page with non-existent inflections that should be green. I don't have one to show right now because I've been creating them manually. Equinox◑22:08, 24 May 2024 (UTC)[reply]
In my browser logs I see: "Exception in module-execute in module ext.gadget.AcceleratedFormCreation: startup.js:319". Is this line number helpful? Equinox◑22:14, 24 May 2024 (UTC)[reply]
Latest Chrome on Win10. The thing that shows the previous and next headwords above the entry ("aardvark - abacus - etc.") is also not working. Equinox◑22:16, 24 May 2024 (UTC)[reply]
More: "Error: This entry seems to be formatted incorrectly. Does it have a language and part-of-speech header? at getPartOfSpeech (ext.gadget.AcceleratedFormCreation-script-0.js:78:10) at createAccelParam (ext.gadget.AcceleratedFormCreation-script-0.js:96:20) at storeAccelParam (ext.gadget.AcceleratedFormCreation-script-0.js:114:21) at HTMLAnchorElement.eval (ext.gadget.AcceleratedFormCreation-script-0.js:231:5) at Function.each (jquery.js:383:19) at jQuery.fn.init.each (jquery.js:205:17) at eval (ext.gadget.AcceleratedFormCreation-script-0.js:176:19) at fire (jquery.js:3223:31) at Object.add [as done] (jquery.js:3282:7) at css (ext.gadget.AcceleratedFormCreation-script-0.js:17:37)" Equinox◑23:16, 24 May 2024 (UTC)[reply]
@Equinox I suspect something in your User:Equinox/monobook.js is the culprit. You can safely get rid of User:Conrad.Irwin/creation.js, as this has been superseded by a gadget that can be enabled in your Preferences. The same applies to User:Dixtosa/nearby.js, although in that case you may need to turn the gadget on yourself after removing it from your monobook.js. There is also User:Equinox/common.js to consider, although the script being loaded here (which has also been superseded by a gadget and can be removed) seems less likely to be at fault. This, that and the other (talk) 00:44, 25 May 2024 (UTC)[reply]
Yes, I was about to suggest that it could be that some combination of gadgets has started to cause an issue for some reason (that happens from time to time!), and I seem to recall that simultaneously loading a gadget both via Special:Preferences and via explicitly loading it in one's .js has caused issues before, if you're doing that with any gadgets. I don't have the "aardvark - abacus" gadget you mention, for example, so if that or some other gadget has started interacting badly with OrangeLinks for some reason, that could explain why you have the problem and I don't. One idea is to turn off all non-default gadgets, clear your cache, turn OrangeLinks back on and see if it works (and steadily turn gadgets back on to narrow down which one is causing failure, iff that's the issue). (You don't have any browser add-ons like NoScript that would be preventing javascript from running, do you? I recall certain antivirus software blocked various users including me from accessing Janus directly a while ago.) OrangeLinks is working for me, even on bungey, even in Chrome. - -sche(discuss)00:49, 25 May 2024 (UTC)[reply]
Thanks. I removed from my Monobook.js "User:Dixtosa/nearby.js" and "User:Conrad.Irwin/creation.js"; then in the gadget settings I observed that "Add accelerated creation links..." was already enabled, and then I enabled "Add links to nearby entries". Cleared cookies. Now the accelerated (green/orange) links are working again, though I still don't have the 'nearby' links for some reason. Equinox◑09:52, 25 May 2024 (UTC)[reply]
So, ACCEL is fine now, but still a problem: can no longer see the "nearby" links (aardvark - abacus - ...). Adding Monobook.js "User:Dixtosa/nearby.js" does not help, and enabling "Add links to nearby entries" in preferences does not do anything. How to diagnose this issue please? Equinox◑22:49, 25 May 2024 (UTC)[reply]
Yep, works in Vector (but I don't much like that "skin" because it wastes space and hides some links behind dropdowns, requiring extra clicks and "where's it going to pop up" guesswork). Equinox◑09:42, 26 May 2024 (UTC)[reply]
Yes, this is a feature (or bug, if you prefer) of Mediawiki, the anchor #top or #Top takes you to the top of any wiki page (presumably it was designed with Wikipedia in mind, where the tops of articles don't have headers, and no section is likely to be titled "Top"). (BTW another thing I'd love people to learn not to use in section headers is unnecessary template markup, as it makes the section harder to reach, e.g. after you edit it, the software can't take you to the section so it just dumps you at the top of the page: try null-editing [[Wiktionary:Grease_pit/2024/March#Insertion_of_undocumented_{{auto_doc}}]], or indeed try clicking that link, which doesn't work.) - -sche(discuss)20:42, 25 May 2024 (UTC)[reply]
Yes...? Any Wiktionary or Wikipedia page you navigate to the anchor #top of, you will be taken to the top of, even on e.g. ru.Wikt where "top" isn't a Russian word; it's a Mediawiki feature. (And any time you use == {{template syntax like this}} == in a header, it borks some of the usual linking/editing behavior, due to another characteristic of Mediawiki.) - -sche(discuss)02:59, 26 May 2024 (UTC)[reply]
@-sche So MediaWiki does a pretty good job of stripping wikicode from headings when creating anchors, but the problem is that it does a bad job doing the same with links, which is where the mismatch creeps in. It's possible to work around it, but you generally need to do it via a template/module for it to be reliable. Theknightwho (talk) 21:02, 25 May 2024 (UTC)[reply]
Perhaps there's some way for the js to spot when a section title is identical to one of Wikimedia's user-interface anchors, and change the target to some kind of alias- maybe the thread id? as for the problem of template syntax in the headers: it could certainly be solved by an abuse filter that explains why that's a bad idea and how to do it correctly. The only problem is that it would be rather user-unfriendly and might discourage participation by less Wiki-savvy users. Chuck Entz (talk) 21:12, 25 May 2024 (UTC)[reply]
@Chuck Entz So this should be raised at the Phabricator, but I expect the best solution is to do something similar to what's done when multiple headings are the same, which is to give any subsequent anchors an index number (e.g. if "Heading" appears twice, the second one has the index "Heading_2"). In the case of "top", the software just needs to assume any page already has a heading called "top" at the start (i.e. it needs to start the index at 2).
I've noticed it's inconsistent, though: in my browser, if there's a heading called "top" in the TOC, clicking it works correctly, but that means that the implicit "top" anchor at the top of the page now no longer works. Either way, it's a problem. Theknightwho (talk) 19:01, 26 May 2024 (UTC)[reply]
The page User:Santi2222/test is currently in CAT:PFE. Nothing unusual about that- there are certain userspace pages that pop up there all the time. The difference is that it only takes a null edit to put the others into Category:Pages with ParserFunction errors/hidden, but so far that doesn't work for this one.
I realize that it's much more complicated setting the categorization behavior for ParserFunctions than it is for Lua/Scribunto errors. I'm guessing that this particular error got missed when the relevant code was added to all the Mediawiki error-handling pages, or there's something that @Theknightwho's MW-error-handling template isn't dealing with right.
@Chuck Entz This is related to the issue that came up in the last thread about this, where MediaWiki treats the pagename as "Special:BadTitle" when handling parser function errors unless a (non-parser function) error occurs somewhere further up the page (e.g. a Scribunto error). If I put a bad {{#invoke:}} at the top of the page, it starts categorising it correctly, for example (but not if I put it below).
We could make it so that the "Special" namespace is treated as hidden by default, but that's probably a bad idea, because then errors on mainspace pages that suffer from this issue will start going in the hidden category as well.
Until the error's fixed upstream in the software, there's nothing we can do, unfortunately; this problem affects all the magic words we were using with the old system as well, so it's not a consequence of the new Lua module. Theknightwho (talk) 22:58, 25 May 2024 (UTC)[reply]
@Vininn126: I had a discussion with @Benwing2 about this (though not about whether it should be the default or not), which resulted in the ability to turn off the link using |authorlink=-. Actually, quotation templates are generally created for well-known authors, so it is probably more likely that they will have Wikipedia articles about them. Also, if we change the behaviour now we’ll have to go through all the quotation templates and check if the names need to be linked. Note that if one just uses {{quote-book}}, etc., there is no automatic linking. The linking only occurs when “Module:quote|call_quote_template” is used. — Sgconlaw (talk) 18:57, 27 May 2024 (UTC)[reply]
Well I'm asking because I'm working with Old Polish/Polish quotation templates, which are very helpful for me to have. Using {{quote}} to turn it off defeats the purpose for me. Vininn126 (talk) 19:06, 27 May 2024 (UTC)[reply]
@Vininn126: is this because the English Wikipedia's coverage of Polish authors isn't great? If there are articles on the Polish Wikipedia, you can link to them like this: |author=pl:Aleksandra Ziółkowska-Boehm. — Sgconlaw (talk) 19:41, 27 May 2024 (UTC)[reply]
I hope that this is not used at all for templates like {{quote-book}}. We already favor famous, older authors over those that speak and write the current English that our users probably want to know. DCDuring (talk) 12:30, 28 May 2024 (UTC)[reply]
@DCDuring: I think (and would hope) the intention is to apply the module only to quotation templates, though I'm not sure as I didn't participate in a discussion about it. (Pinging @JeffDoozan who implemented this.) — Sgconlaw (talk) 21:47, 28 May 2024 (UTC)[reply]
This was a feature of Module:quote before I made any changes to that module, but I'm sure it became more visible after I converted many RQ: templates to use Module:quote. FWIW, @Ioaxxere recently removed it: diff. JeffDoozan (talk) 14:02, 1 June 2024 (UTC)[reply]
Over time, translation headings get out of sync with the English definitions. They may be in the wrong order, or may no longer discernibly match English definitions. Where there are many definitions, perhaps dozens, it is a bit of a drag to fix these manually. And then if one makes more changes, especially reordering of definitions, one has to do it all over again. An automated tool to put translations in the correct order where they can be matched, and flag up those that cannot be matched, would be a time-saver. (The matching would have to be "intelligent" because the translation headings are often not word-for-word the same as the English, e.g. they may be shortened, retaining only the most important keywords.) I guess this is asking quite a lot, but just in case anyone has the time and interest ... Mihia (talk) 21:05, 27 May 2024 (UTC)[reply]
@Mihia I already have a script to reorder translations inside of translation sections, which I've run every so often. But I think it would be difficult to implement reordering of translation sections to match definitions. (Not necessarily impossible. For example, I have a script to convert synonyms in Synonyms sections into inline synonyms. When there are multiple definitions, the script requires that (a) each synonym have a {{sense}} tag; (b) all synonyms can be matched to exactly one definition; (c) no two synonyms match the same definition. The matching works by making sure that all works in the {{sense}} tag are present in the definition, in the same order (but possibly with additional words in between). This works pretty well because typically the {{sense}} tags are compressed versions of the definitions. But I'm not sure the same can be said for translation headings.) Benwing2 (talk) 02:13, 28 May 2024 (UTC)[reply]
Right, the matching would be the difficult part. Sometimes it is difficult even for humans to decide what is, or originally was, supposed to match to what. Mihia (talk) 13:15, 28 May 2024 (UTC)[reply]
FWIW, someone did in the past float the idea of putting translations under the relevant sense in the same way as inline synonyms, etc. The problem is of course that while this might make the displayed page easier to follow (if the translations were collapsed by default and so not spreading out the senses unless someone wanted them to, whereupon they'd be right next to the relevant sense) and would eliminate the possibility of the translation-table headers and definitions going out of sync, and might hopefully also reduce the chances of the ordering going out of sync, someone who was e.g. only trying to reword several definitions at once might feel that the wikitext was now harder to look over, because it'd put screens and screens of 'irrelevant' wikitext in between senses. (OTOH, it seems like it'd be pretty easy, looking at the wikitext, to see where one sense ends, if it ended with a translations table, as the wikitext of those is usually pretty distinctive, lots of short lines and often non-Latin characters... it might actually be easier than the current system where one sense can be separated from the text by screens and screens of quotations which look, in the wikitext, little-distinct from senses, meaning I often just search and highlight-all # to find where each definition is ... I'm actually less opposed to this idea the more I think about it...) - -sche(discuss)14:12, 28 May 2024 (UTC)[reply]
I think it's a horrible idea. It would make editing horrible and more error prone. It might also deter people from making improvements to the English definitions by overtly forcing them at every turn to make decisions about what to do with translations, often without any knowledge of the foreign-language words involved. Also, I think the flexibility of NOT always requiring rigid one-to-one correspondence, e.g. allowing coarser-grained translations and finer-grained definitions, is beneficial. Mihia (talk) 14:42, 28 May 2024 (UTC)[reply]
I have incorporated the accent qualifiers from Module:accent qualifier/data into the labels data and switched {{a}} to use Module:labels internally. This means that {{a}} functions very similarly to a non-categorizing {{lb}}, although a few labels display and/or link differently when invoked from {{a}} instead of {{lb}}. (For example, Egyptian-language labels like Old Egyptian display as "reconstructed Old Egyptian" etc. instead of just "Old Egyptian"; English-language label Australia displays as "General Australian" instead of just "Australia", and links to
w:Australian English phonology instead of w:Australian English; Latin-language label Ecclesiastical Latin displays as "modern Italianate Ecclesiastical" instead of just "Ecclesiastical Latin", and links to w:Latin phonology and orthography#Ecclesiastical pronunciation instead of w:Ecclesiastical Latin.) I considered using different labels instead of making the same labels display differently, but it seemed like it would be too confusing e.g. to have two different "Australia" labels, two different "Ecclesiastical Latin" labels, etc. (I am thinking of following the same approach to get rid of certain labels that are specific to {{spelling of}} such as Canadian form/Canadian spelling and American form/American spelling, in place of just Canada and US .) Please let me know if you see any problems. Benwing2 (talk) 23:41, 27 May 2024 (UTC)[reply]
@-sche Sorry to ping you yet another time. I'm wondering if you can help me here with Canadian form/Canadian spelling etc. I notice that we actually have three related labels Canada, Canadian form and Canadian spelling; similarly for US, American form and American spelling and Australia, Australian form and Australian spelling, and four labels British, UK, British form and British spelling. The Foo form vs. Foo spelling labels link and categorize the same, and the display only differs in that the Foo form labels just display as "Foo" whereas the Foo spelling labels display as "Foo spelling" (except for American form, which strangely displays as "US" instead of "American"). It would be nice to have only one "Canada", "Australia", etc. label instead of 3 or 4. The approach I took with labels like Ecclesiastical Latin was to allow the labels to specify separate links and display forms when invoked using {{a}} instead of {{lb}}, and the same approach could be used here. But ...
If we were to maintain two labels e.g. Canada and Canadian spelling, I think one way to deal with the latter would be to make it display "Canadian spelling" when invoked using {{lb}} or {{tlb}}, but just "Canadian" when invoked using {{alternative form of}}, {{spelling of}}, etc. Then, the latter templates would add the word "form" or "spelling" to whatever the label displays. Does this make sense?
Yeah, if "alternative form of", "standard spelling of" et al can know to delete "spelling" from the display form of "British spelling" — so {{altspell|en|foo|from=British spelling}} displays "British spelling of foo" instead of "British spelling spelling of foo" — "British form", "Canadian form" etc can be reduced to aliases of "British spelling" etc (or perhaps eliminated); the "...form" labels were a kludge to deal with the display issue. (We should check that they're not being (mis)used in unexpected places, though; see the recent edit history of from A to Zed for example.) The reason for separating "American English" and "American English forms" is as you suspect, that it'd be weird/wrong to say that something like "realize" is an America-specific dialectal word, when in fact it's perfectly well used in Britain too, not only in speech (obviously) but even in writing (in that z spelling sic!) by people who follow "Oxford" spelling standards. My initial inclination is to keep America-specific dialectal terms and American spellings of common words separate and not merge them into one category, but hopefully more people can comment. - -sche(discuss)03:09, 28 May 2024 (UTC)[reply]
OK, I implemented this, including automatically dropping the word "spelling" when invoked from {{alt form}}, {{standard spelling of}} and the like. There was only one place that needed to have a special display setting for the form-of templates, which is American spelling, using "US" as the display form for the form-of templates (although I haven't yet made the changes to the labels data; I need to check for misuses, as you mention). Benwing2 (talk) 01:59, 29 May 2024 (UTC)[reply]
BTW I went ahead and made the cleanups/aliases to the form-of labels; only four languages were affected (ch = Chamorro, de, en and pt). American form is now aliased to American spelling, but the tracking categories still work and the tracking categories for American form show only the uses of this particular label. Benwing2 (talk) 02:30, 29 May 2024 (UTC)[reply]
Oh, my comment at from A to Zed was that I don't think we'd want the {{label}} to be "(British spelling) alternative form of" ({{lb|en|British spelling}} {{alternative form of|en|from A to Z}}). My feeling was that it would either make sense to say {{lb|en|British}} {{alternative form of|en|from A to Z}} (if we view it as being more than just a spelling issue: it uses what could be considered a different word, which in any case also has a different pronunciation), or (if we do consider it to be just a spelling difference) then {{alternative form of|en|from A to Z|from=British spelling}}. Perhaps I am mistaken! Yes, I would change the tart/troop entries as you suggest, moving "American spelling" et al out of the {{label}} and into the from=. If we wanted to be precise, I might be inclined to make all the singular ones point to one singular (for example, giving maid of honor tart, maid-of-honor tart, and maid-of-honour tart as alt spellings of maid of honour tart), and then make maid of honour tart an alt form of maids of honour tart, but this would require people to go through more clicks unless we double the templates up, like "alternative spelling offoo: alternative form ofbar", so just making them all point directly to the one 'lemma' entry seems fine. - -sche(discuss)17:48, 29 May 2024 (UTC)[reply]
There is currently a module error at Module:labels, apparently caused by {{a}} becoming executable when copied from a comment in the module. Since comments are by definition never executed, shouldn't all executable syntax in them be escaped? Chuck Entz (talk) 01:51, 28 May 2024 (UTC)[reply]
@Chuck Entz This was done intentionally so that you can put stuff like links to terms using {{m}}, templates using {{tl}}, etc. in the doc comments and have them executed/expanded so you get links etc. Possibly this could be changed; but it would be a significant change (since a lot of comments currently rely on it), and require extra syntax to specify the use cases that are currently handled using template expansion, and you'd still probably need syntax to force expansion of a template invocation. In this case, the raw call to {{a}} should be changed to {{tl|a}}. Benwing2 (talk) 02:21, 28 May 2024 (UTC)[reply]
If the are multiple invocations of {{rfv}} and {{rfv-quote}} meriting separate discussions, we can currently disambiguate them using |fragment=, though I think it needs more guidance at {{rfv}} and mentioning at {{rfv-quote}}. However, the anchors on the page with the challenged items doesn't provide different anchors. Someone please fix that. It's causing a problem at अमृत(amṛta) where there are unrelated challenges to a quotation for the adjective and to alleged senses for the masculine noun. --RichardW57m (talk) 15:48, 28 May 2024 (UTC)[reply]
@Benwing2 The font would be for the Nüshu script (currently only used by Shaozhou Tuhua). There aren't many fonts that support it, but there's Noto Sans Nüshu, Noto Traditional Nüshu (difference explained towards the bottom here), and Unicode Nushu. I'd suggest listing them in that order, personally, for the sake of readability. Theknightwho (talk) 19:26, 28 May 2024 (UTC)[reply]
I would also suggest increasing the font size (at least to 120% matching Chinese, if not to 150% matching various other scripts); I installed those fonts, and at current size, it's only barely legible. - -sche(discuss)20:21, 28 May 2024 (UTC)[reply]
I believe that any modern web browser should be smart enough to comb through fallback fonts available on a device and locate the Noto font on its own, and hence specifying it manually would be a waste of code. —Fish bowl (talk) 03:04, 29 May 2024 (UTC)[reply]
Yes, my experience is the same. When I had no Nushu fonts installed, and we had (and still have) no fonts set in the Gadget, I just saw 𛉄 as a box. When I had only the two Noto Nushu fonts installed, I saw them when I used Firefox (when logged in), but not Chrome (nor Firefox when logged out), AFAICT because we don't specify them in the Gadget. (Most interesting to me would be to find out what happens if we do specify fonts in the gadget and I don't have them installed: does the gadget specifying them prompt any browser to fetch them webfonts-style? I seem to recall there was an effort [by WMF?] to make that happen, but I don't know what came of it.) Interestingly, when I briefly installed Unicode Nushu to check its legibility (poorest of the three fonts, I agree with TKW), the text here started displayed as a box again. (It's back to using Noto in Firefox but being a box in Chrome, now that I've uninstalled Unicode Nushu again.) Besides being necessary for that, I think specifying the fonts also has a few other purposes. One is if, as in this case, we don't want Noto to be the last-reached fallback font some browsers fall back on (and others don't) if they don't have e.g. Unicode Nushu, rather we want to be sure that Noto Sans to be the first font chosen because the others are less legible. (Another is: if the user doesn't have all or any of these fonts installed, they check the list to see what fonts we have deemed as most installation-and-use-worthy.) If a user has all the fonts for all the scripts installed and has a browser/system that selects them automatically without needing to be told to, such a user could just individually opt out of / turn off the entire gadget, no? (It does not seem like any one part of it wastes code; they either need the whole gadget or don't need it at all, no?) - -sche(discuss)15:59, 29 May 2024 (UTC)[reply]
OK, I've added Nshu to the Gadget (with correct font names at 16:25), and can offer some more data on how quickly changes to site-wide CSS files take effect (something else which was discussed recently) : looking at this page and at the page title and headword line of 𛉄, all of it was displaying as a box in Chrome (whether I was logged in or out) and in Firefox (when I was logged out), whether I viewed the desktop version of the site or the mobile version, until 16:30, when the headword line of 𛉄 started to display correctly when I viewed the mobile version of the site in Chrome (logged in). The headword line started to display correctly also in the desktop version in Chrome (logged in or out) at 16:33. However, in Firefox, when I am logged out, it still displays as a box (whether I view the desktop or the mobile version of the site) even as of the minute I post this comment. (It also displays as a box when I use an actual mobile device, presumably because I don't have relevant fonts loaded on that device.) Also, even in Chrome (and in all of the other scenarios mentioned), the actual page title itself (at the top of the loaded page), as opposed to the headword, still displays as a box, which I think is because script classes aren't normally applied to page titles, so we probably want to do the same kind of thing we do to make e.g. Mongolian page titles display correctly. TBD: why is the headword line (and page title) of 𛉄 still a box in Firefox (on desktop and on mobile) when I view it logged out? Do we not load the Scripts Gadget for logged-out users? (If not, why not?) (When I'm logged in, on Firefox, the page title and headword line displayed correctly as soon as I installed the relevant fonts, even before I added anything to the Gadget.) - -sche(discuss)16:58, 29 May 2024 (UTC)[reply]
Do you have any examples of Shaozhou Tuhua sentences, esp. those with mixed Nüshu and Latin, so I can see how they look together? Also, how do Nüshu and Chinese characters compare in height? If they are similar, it's probably fine even if the height of the Nüshu characters is taller than the Latin characters (since there are so many more of them and they're generally more complex). Benwing2 (talk) 00:50, 30 May 2024 (UTC)[reply]
I pulled a randomish selection of characters from the Nushu block, including some simple and some complex ones, and put them at User:-sche/sandbox5. You can add this to your CSS to see the different sizes. (Possibly I could've set the sizes manually on that one page, but you'll notice the "100%" and "not tagged" text [which should also be 100%] show up slightly differently, so I wanted to be sure and get whatever effect was gotten by assigning the size specifically in CSS.) I see this if I view the page itself at 100% zoom and the different lines of text at the levels of zoom indicated. This is if I view the page at 150% zoom. TKW is probably right that we could get by with 130% — or maybe 140% as is used for Mongolian? — if people use Noto Sans Nushu. (If people use either of the others, they likely need bigger font size: here's Noto Traditional, viewing the page at 150%, and here's Unicode Nushu.) - -sche(discuss)02:45, 30 May 2024 (UTC)[reply]
@-sche I installed Noto Sans Nushu, and at 150% it looks a bit big; but strangely, the default shows up only at 100%. This is on Chrome 124, Mac OS Ventura 13.6. Here is my view of your test page: [10] Is there no way in CSS to control the scaling at a per-font level? Benwing2 (talk) 03:24, 30 May 2024 (UTC)[reply]
Re "the default shows up only at 100%", you're referring to the "Nushu with no script tagging" line? That line isn't tagged with anything, not even the "Nshu" class our site-wide CSS sets fonts and sizes for. Re font size, OK, I'll reduce it to 130% soon. Are you able to make the pagetitles of Nushu-script pages be tagged with the Nshu script code (like Mongolian-script pages' pagetitles are tagged with their script code)? Currently, when I use Chrome, only the headword on 𛉄 displays, the pagetitle/h1 is still tofu, which I think is because it isn't being tagged with a script code. (In Firefox, everything including the pagetitle displays correctly when I'm logged in, and nothing at all displays—it's all boxes—when I'm logged out. Do we not set fonts for logged out users? Is this a consequence of moving script codes out of Common.css? Do we need to move them back?) - -sche(discuss)04:14, 30 May 2024 (UTC)[reply]
@Benwing2 The font declaration for .Nshu is being properly loaded when I load that page, whether logged in or logged-out, but that CSS class isn't applied to the page title. The page seems to need a {{DISPLAYTITLE:}} set. From my quick look it's not clear why things are working for -sche in some configurations but not others... This, that and the other (talk) 05:36, 30 May 2024 (UTC)[reply]
Thanks for fixing the page title issue. :) On the second issue: I've now realized it's different/weirder than I thought. What I had been doing was looking at pages (while logged in) in a regular Firefox window, and checking how they looked when logged out by opening a Private Browsing window (and a Tor window) and looking at those. However, I now notice that if I log out and look at the site in a regular Firefox window, everything displays. Conversely, if I log in while using a Private Browsing window, it's still tofu, and I notice that Glagolitic fonts are only applied to the Glagolitic text in Glagolitic when I'm in a normal Firefox window, but not when I'm in a Private Browsing window. So the issue appears to be that Private Browsing windows (and Tor) don't ... support/access fonts? Which I guess might be an intentional privacy feature of those browsers...? (The text, in all cases, is tagged with the correct class when I look at the page source.) So I guess it's fine, or at least not a Wiktionary problem. (When we were testing the "big and green" class recently, it displayed even in Private Browsing windows, and the Glagolitic size increase displays: CSS classes that have to do with font size or color seem to be applied, just not fonts.) - -sche(discuss)05:55, 30 May 2024 (UTC)[reply]
quyanaa I recently created this entry. I don’t know why, but it shows up, under categories, as a Greenlandic word of Proto-Eskimo origin. I did not create this an cannot edit it. It is an Alutiiq word.
@RangerRichard The category is being generated by the {{der|kl|esx-esk-pro|...}} template, as this template is used to denote a Greenlandic (kl) word that is derived from Proto-Eskimo (esx-esk-pro). According to WT:LOL, the correct code for Alutiiq is ems, so this needs to replace kl.
Note also that your entry must include a headword-line template. After the part-of-speech header (===Interjection===), add {{head|ems|interjection}}. Thanks for your contributions! This, that and the other (talk) 04:38, 29 May 2024 (UTC)[reply]
Another editor suggested I "make a case" for the category's existence. The Theodore Roosevelt category should exist because there are more than a dozen words about, created by, or popularized by him. Purplebackpack8916:22, 30 May 2024 (UTC)[reply]
Please also move the following categories from War to Wars:
American Civil War/en:American Civil War
American Revolution/en:American Revolution
Napoleonic Wars/en:Napoleonic Wars
Trojan War/en:Trojan War
Vietnam War/en:Vietnam War
World War I/en:World War I
World War II/en:World War II
Another editor suggested I "make a case" for the category's existence. The Wars category should exist because there are quite a few proper nouns that are Wars and contain the word "War". Purplebackpack8916:23, 30 May 2024 (UTC)[reply]
@Psioter has asked me if we could generate a data dump of my work for Masurian (well, also KamiruPL's!) so he can make a database. I'm assuming this would include things like IPA, the very little declension I have, etymologies, etc. Also, information in CAT:Masovia Old Polish could be interesting, if a bit scarce at the moment, as well as scatted. Could someone help? Vininn126 (talk) 18:50, 29 May 2024 (UTC)[reply]
Not sure how long it has been this way, but, for whatever reason, italics have stopped working when used anywhere in the t= parameter of form-of templates like {{alt form}} and {{form of}}. See wokiya for an example of italics failing. Module:form of is the module responsible, but does anyone know where in the module this is happening or how to fix it? — Vorziblix (talk · contribs) 13:08, 30 May 2024 (UTC)[reply]
@Vorziblix If you go to Special:ExpandTemplates and put in the call to {{alt form}} on wokiya, you can see that the double apostrophes are in the output, meaning this has nothing to do with Module:form of. The reason rather is that the value of the |t= param is wrapped in the CSS class mention-gloss, and you can see from MediaWiki:Common.css that this CSS gloss sets font-style: normal; which apparently overrides the italics. I think the reason for this setting is that mention-gloss is also used in things like {{m}}, and I think the intention is that if used inside of italic text, the gloss shows up in an upright font to distinguish it from the surrounding italic text. But I'm not completely sure. Maybe someone more familiar with the CSS, like User:Ioaxxere or User:This, that and the other, can comment. To fix this we'd either have to change the definition of the CSS class mention-gloss or use a different CSS class without this property. Benwing2 (talk) 01:11, 31 May 2024 (UTC)[reply]
Using {{desctree}} with id= results in many extraneous template invocations
It seems that using the {{desctree}} template with the id= parameter results in the page that calls {{desctree}} invoking every single template on the page that {{desctree}} links to, sometimes causing hundreds of superfluous template invocations. See Reconstruction:Proto-Slavic/(j)azъ, where the calling of {{desctree|zlw-opl|ja|id=pronoun}} makes Reconstruction:Proto-Slavic/(j)azъ call an enormous number of templates. This seems suboptimal and pollutes the transclusion list of templates. This does not happen with {{desc}}, only {{desctree}}, and does not happen unless the id= parameter is used. Is this fixable, or just something inherent to how {{desctree}} and {{etymid}} work? — Vorziblix (talk · contribs) 21:23, 30 May 2024 (UTC)[reply]
@Benwing2 I think we've spoken about this before: the solution is to make Module:descendants tree be more specific about which sections it parses, instead of putting the entire page contents through the template parser. I think I suggested using get_section in Module:utilities.
@Vorziblix To be clear about why this is happening: Module:template parser is not expanding every template on the page (which would effectively double the page load), but it checks whether the raw template name is a redirect in order to normalise it to the canonical form (i.e. {{l}} is normalised to {{link}} etc etc); this seems to count as a transclusion. The actual load of doing this isn't very much, but obviously it's annoying that it pollutes the template transclusion list. Theknightwho (talk) 01:19, 31 May 2024 (UTC)[reply]
@Theknightwho Sorry, by "expand templates" I meant "check for redirects". But even if we make it smarter about which section to check, it will still cause transclusions of all templates in that section to be listed. What about a flag telling it not to check for redirects? Benwing2 (talk) 01:35, 31 May 2024 (UTC)[reply]
@Benwing2 We could, but any "Descendants" section will be >90% {{desc}} templates and the rest will probably be {{q}}, so it seems unnecessary. All we'd be doing is pushing work back into Module:descendants tree anyway, since it'd still need to check for redirects, which presents a maintenance issue. Theknightwho (talk) 01:40, 31 May 2024 (UTC)[reply]
Unable to add 2 more synonyms for the word endonym
but I got this message:
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: -vija
@Chuck Entz looking through the list of recent hits, I'm not sure this abuse filter is serving its purpose any longer. It does trap a bunch of idle vandalism but it doesn't look any different from what we'd get from any other IP range. Thoughts? This, that and the other (talk) 05:31, 31 May 2024 (UTC)[reply]
Procedural question: given that we're using an abuse filter to (try to) stop edits by this user, are we also blocking IPs which are known to be this user? If so, since the user is abusing multiple accounts/IPs, shouldn't the main account also be blocked? - -sche(discuss)03:10, 3 June 2024 (UTC)[reply]
@-sche: They stated they were quitting and never edited from their account again, so the focus was on dealing with the IP edits that came later. The list of IP ranges in the filter are all from unmistakably characteristic bad edits being done in those ranges. They switched ranges often enough that blocking them in the usual way would have shut down edits from pretty much all of Vietnam, so the filter was created in order to limit the collateral damage. I never was that great with regexes, so it can probably be improved. Besides which, it's always possible that they've moved to another range not covered by the filter. Chuck Entz (talk) 03:37, 3 June 2024 (UTC)[reply]
@Chuck Entz thanks for that. However, I'm still unclear on whether, in your view, the filter is still actually catching and deflecting vandalism from the user who it was originally intended to catch. As I observed above, I wasn't able to spot any patterns emerging from the edits being disallowed. I think we should be proactive in disabling filters like this if the person they are targeting has given up and moved on. This, that and the other (talk) 06:04, 4 June 2024 (UTC)[reply]
Starting on Category:Sino-Vietnamese_words how do you propose users get to the e.g., K's?
Fiddling with the URL of course ("Go to the next 200, whereupon a pagefrom= URL parameter appears which the user can tinker with.") That isn't how a major website should treat users. Jidanni (talk) 14:59, 31 May 2024 (UTC)[reply]
Our categories are inconsistent in whether they have what I will for lack of a better word call 'navigation TOCs', and what level of detail the TOCs have. You are right that this is an issue. The category you link has no TOC; Category:Vietnamese nouns has 15,000 entries and the TOC is just "A Ă Â B C D Đ E Ê G H I K L M N O Ô Ơ P Q R S T U Ư V X Y", whereas Category:Latin nouns, also with 15,000 entries, has a whole "aa ab ac ad ae af ag ah ai aj ak al am..." thing going. - -sche(discuss)17:29, 31 May 2024 (UTC)[reply]
@Jidanni @-sche All categories that are handled by the poscatboiler system have TOCs added automatically. Generally, if there are >= 200 and < 2500 entries, a single-level TOC is added if available (i.e. if one has been created for the language in question), and if there are >= 2500 entries, a two-level TOC is added if one has been created for the language in question. Latin has such a two-level TOC but Vietnamese doesn't. Generally, most languages have one-level TOCs but only some have two-level TOCs. Maybe we can/should fall back to a generic TOC based on the script of the language, so we get default two-level TOCs (or maybe in such a case we should display both a language-specific one-level TOC and a generic two-level TOC?). This particular category Category:Sino-Vietnamese words has no TOC because it doesn't go through the poscatboiler system (you can see that by the fact that it doesn't use {{auto cat}}). Let me see about adding it. Benwing2 (talk) 19:00, 31 May 2024 (UTC)[reply]
The Sino-Vietnamese and Sino-Korean categories are now in the poscatboiler system, and there is a TOC visible for them. Benwing2 (talk) 04:25, 1 June 2024 (UTC)[reply]
For some reason, kana entries for Japanese na forms are displaying duplicate rōmaji in the headword template, resulting in broken links. Examples: アウト ,すぐ, そう.
Similarly, verbs and adjectives now display single rōmaji links for multiword conjugations (such as suru and na forms), even though such entries would inherently be SOP. Examples: 丿乀, 匡救, 真っ直ぐ. @TheknightwhoBinarystep (talk) 19:55, 31 May 2024 (UTC)[reply]
Done This, that and the other (talk) 10:00, 6 May 2024 (UTC)
Support - might be worth making them hidden, though, but I don't have strong feelings about it. Theknightwho (talk) 18:04, 20 May 2024 (UTC)
