Wiktionary:Grease pit/2024/May

From Wiktionary, the free dictionary
Jump to navigation Jump to search

Lithuanian collation[edit]

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

And we can find successive dictionary entries Lithuanian skersvėjis, Lithuanian skėsti, skęsti, sketera,[1] showing the problems with promoting secondary collating differences to primary differences. --RichardW57m (talk) 14:50, 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.
To answer @RichardW57m's question: the current sortkey isn't based on the UCA - with a handful of exceptions, our sortkey algorithms are very simple. Theknightwho (talk) 00:23, 2 May 2024 (UTC)Reply
@Benwing2, Theknightwho: Well, someone made a change between 28 November 2022 and 15 December 2022 (see [2]), but the history is hidden in the now deleted Module:lt-sortkey. Was it perhaps @Octahedron80? --RichardW57 (talk) 06:48, 2 May 2024 (UTC)Reply
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: Thanks. Curious. The 'standard' Lithuanian collation as defined by CLDR and demonstrated (today) at [4] has gėbelėti before gežtis. --RichardW57m (talk) 10:19, 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
@Benwing2:, (Notifying Agamemenon, Apisite, BigDom, GabeMoore, Insaneguy1083, Helrasincke, Hippietrail, RichardW57, Sławobóg, 70.175.192.217): I will need some help assessing what is a 'standard' Lithuanian dictionary. I've now found what looks like one at https://archive.org/details/lyberis-sinonimu-zodynas-2002/page/106/mode/2up; (Sinonimų Žodynas = "Dictionary of Synonyms") the page linked to makes it rather obvious that 'e', 'ę' and 'ė' are the same in some sense, and page 128 shows the intermingling of the three. Page 244 shows that 'u' and 'ū' have the same primary weight. Page 252 shows sameness for 'a' and 'ą'. Page 147 proclaims sameness for 'i', 'į' and 'y'. Page 528 proclaims the sameness of 'u', 'ų' and 'ū', though a demonstration for u ogonek will need more searching. --RichardW57m (talk) 15:00, 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]
This appears to be confirmed by, for example, the Lyberis Lithuanian-Russian dictionary where gadýnė is followed by gadìnimas, gabėndinti is followed gabẽnimas (under which we find e.g. gabénti, gabéntis).[3] Helrasincke (talk) 22:15, 4 May 2024 (UTC) Helrasincke (talk) 22:15, 4 May 2024 (UTC)Reply
@Helrasincke @RichardW57 Yeah, this is easy enough to implement, if no one objects I'll go ahead and do that. Benwing2 (talk) 00:19, 5 May 2024 (UTC)Reply
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
Curiously enough, Cathy Wissink and Micha Kaplan get Lithuanian 'i' v. 'y' wrong on p11 of https://www.infitt.org/ti2002/papers/03WISSIN.PDF - carelessness, ignorance or misinformation? --RichardW57 (talk) 14:35, 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

References[edit]

  1. ^
    1915, Antanas Lalis, A Dictionary of the Lithuanian and English Languages[1], Chicago, page 325
  2. ^ Vytautas Ambrazas et al (2006) [1997] Lithuanian grammar, 2nd edition, pages 15-16
  3. ^ Antonas Lyberis (2005) Lietuvių-rusų kalbų žodynas [Lithuanian Russian Dictionary], page 182
  4. ^ Cynthia M. Vakareliyska (2015) A Lithuanian Root List, page 6

--RichardW57m (talk) 14:50, 1 May 2024 (UTC)Reply

Strange behaviour of translation template[edit]

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
@Mihia Yes, AFAIK what you are suggesting is completely OK now. Benwing2 (talk) 18:58, 2 May 2024 (UTC)Reply

Occitan template requests[edit]

Can anyone create Occitan past participle template and other essential templates?. other Romance languages such as Asturian, Catalan, French, Galician, Italian, Portuguese, Spanish have already had past participle template. Thank you in advance. Flummont (talk) 02:06, 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
I took a look at the conjugations there. Unfortunately they only have Lengadocian conjugations for -ir/-er/-re verbs but the regular ones seem to be like parlar. However, the irregular ones (e.g. oc:Template:Conjugason/oc/leng/-odre-t, oc:Template:Conjugason/oc/leng/-dire) look to be more complex and probably differ dialect-to-dialect. Benwing2 (talk) 04:24, 2 May 2024 (UTC)Reply

Two issues with transliteration categories[edit]

This, that and the other (talk) 02:32, 2 May 2024 (UTC)Reply

@This, that and the other I agree with your first statement. I'll have to look into what's going on with honey. Benwing2 (talk) 03:08, 2 May 2024 (UTC)Reply
@Benwing2 I guess the hidden cat issue could be fixed by changing Module:category tree/poscatboiler#L-448 to return false, but I don't really understand the logic here. Umbrella categories don't contain entries, so why would they ever need to be hidden? This, that and the other (talk) 04:06, 2 May 2024 (UTC)Reply
@This, that and the other I think I wrote that code more or less mechanically. But in this case making that change wouldn't fix the issue because the 'Requests for ...' categories are all raw, so the first arm of the if-statement would apply. We need to make a change somewhere in Module:category tree/poscatboiler/data/entry maintenance, which generates its own umbrella categories, to not hide such categories. Benwing2 (talk) 04:16, 2 May 2024 (UTC)Reply
Maybe [5] will fix it. This, that and the other (talk) 04:40, 2 May 2024 (UTC)Reply
@This, that and the other Looks good to me. Benwing2 (talk) 04:58, 2 May 2024 (UTC)Reply

Lua Modules variable sized arguments and the arg magic variable[edit]

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.

@Theknightwho Module:languages now uses the (soon obsolete) arg var in :

function export.addDefaultTypes(data, regular, ...)
	local n = arg.n
	local types = n > 0 and concat(arg, ",") or ""

Please, could you change it to :

function export.addDefaultTypes(data, regular, ...)
   local arg = {...}
   local n = select( '#', ... )

As a quick fix ?

The same goes on with Module:scripts which has been "corrected" recently and introduced the same problem:

for i = 1, arg.n do
    if not types[arg[i]] then 

from the more modern (older) version:

for _, type in ipairs{...} do
   if not self._type[type] then

Also please consider modernizing the Module:tables function:

function export.append(...)
	local ret, n = {}, 0
	for i = 1, arg.n do
		for _, v in ipairs(arg[i]) do

Thanks in advance, Dodecaplex (talk) 21:14, 3 May 2024 (UTC)Reply

@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)
This will have a better performance impact and will last longer in the long term... Dodecaplex (talk) 21:57, 3 May 2024 (UTC)Reply
@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

Need help with creating Module:number list/data/vi[edit]

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 Done! --ChemPro (talk) 08:04, 5 May 2024 (UTC)Reply
@ChemPro What you did was about half done, but I tried to fix it up. It still needs some work. Benwing2 (talk) 00:11, 6 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)
  • When the number 5 appears after 10 in the unit digit, the pronunciation changes from năm to lăm --ChemPro (talk) 07:42, 6 May 2024 (UTC)Reply
  • When the number 4 appears after 20 in the unit digit, pronunciation changes from bốn to --ChemPro (talk) 07:52, 6 May 2024 (UTC)Reply
    @ChemPro OK, thanks. I'll get to this tomorrow, going to sleep now :) ... Benwing2 (talk) 08:01, 6 May 2024 (UTC)Reply
Some additional informations to the rules mentioned above:
  • Exceptions to the rule of changing the pronunciation from năm to lăm are numbers ending in 05 (such as 105, 605, 9405, 39605).
  • In some Vietnamese dialects, the number seven (bảy) it also read as bẩy. I tried to implement it, but it somehow caused an error. --ChemPro (talk) 08:36, 6 May 2024 (UTC)Reply

Bot preventing the creation of a redirect[edit]

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

@Fay Freak Thanks a lot. I'll look into the discussion, thanks. Ash wki (talk) 11:44, 4 May 2024 (UTC)Reply

MY PAGE WONT UPLOAD[edit]

I WAS ONLY GIVING THE LINK TO MY WIKIPEDIA PAGE!!!! Lilly is cool (talk) 17:42, 4 May 2024 (UTC)Reply

@Lilly is cool: that’s exactly why … — Sgconlaw (talk) 17:47, 4 May 2024 (UTC)Reply
If you make it a wikilink, as in [[w:User:Lilly is cool]], the abuse filter won't think you're just linking to some random website. Chuck Entz (talk) 17:57, 4 May 2024 (UTC)Reply

I keep getting logged out[edit]

Ever since I cleared my site data for Wiktionary to fix the translation-adder, I have to log in again on my PC every day. However, my other devices don't have this issue. Any ideas? Aaron Liu (talk) 18:31, 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’ve had the same issue today, so it might be a server problem. Theknightwho (talk) 19:05, 4 May 2024 (UTC)Reply
I didn't log out before clearing the data, and I have no problem at all staying logged in on my iPad. Aaron Liu (talk) 19:15, 4 May 2024 (UTC)Reply
@Benwing2 I am still logged in on other wikis, so logging in is instant. I'll try logging out and back in again, thanks. Aaron Liu (talk) 20:46, 5 May 2024 (UTC)Reply

Dialectal variation[edit]

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

What is the difference between what you're describing and an altform? Nicodene (talk) 07:08, 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
Soft redirect? Do we need to list every dialectal form on every page? Benwing2 (talk) 07:17, 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
I suppose I'll try that once I've done more work on the actual subdialects themselves. Vininn126 (talk) 08:05, 6 May 2024 (UTC)Reply

< > (Unsupported titles/`lt` `gt`): broken labels[edit]

{{lb|mul|Internet slang}} results in “(Internet slang[[Category:Translingual internet slang|]])”. J3133 (talk) 15:27, 5 May 2024 (UTC)Reply

@J3133 On which page? I tried this on a test page and it displays correctly. Benwing2 (talk) 19:42, 5 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
@Chuck Entz Thanks, I see it now. Benwing2 (talk) 21:10, 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
@Theknightwho Can you code this up? Benwing2 (talk) 22:25, 5 May 2024 (UTC)Reply
Sure. Theknightwho (talk) 00:46, 7 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[edit]

I've already gone through every page in the Appendix and Reconstruction namespaces to remove bad uses of #*. Could one of our interface administrators change MediaWiki:Gadget-defaultVisibilityToggles.js#L-435 to include namespaces 100 (Appendix) and 118 (Reconstruction) so that quotations can display properly? (Before anyone asks, there are legitimate quotations on reconstructed entries, such as Reconstruction:Proto-Germanic/Harigastiz). Ioaxxere (talk) 16:55, 5 May 2024 (UTC)Reply

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
 Done This, that and the other (talk) 10:00, 6 May 2024 (UTC)Reply

"SORRY" abbreviations[edit]

Moved to Wiktionary:Tea room/2024/May#"SORRY" abbreviations

Why additional line under headings in discussion pages?[edit]

Was this announced? Voted on? Imposed by MediaWiki? Or by someone else? DCDuring (talk) 00:43, 7 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.
In any event, the announcement advises that you can turn the new look off in the Editing tab of your preferences. This, that and the other (talk) 01:20, 7 May 2024 (UTC)Reply
@DCDuring Personally I think its usefulness outweighs any possible space wastage. Benwing2 (talk) 19:35, 7 May 2024 (UTC)Reply
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 (talkcontribs).
Anything I can turn off is OK with me. DCDuring (talk) 20:19, 7 May 2024 (UTC)Reply
@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
@Sokkjo, you can turn it off by unticking "Show discussion activity" at the bottom of the "Editing" tab of Special:Preferences. - -sche (discuss) 15:48, 8 May 2024 (UTC)Reply
@-sche: <3 -- Sokkjō 16:50, 8 May 2024 (UTC)Reply
It looks like the stats on how many days or months since the last edit are wrong- late December isn't "4 months ago". Chuck Entz (talk) 15:01, 8 May 2024 (UTC)Reply
@Chuck Entz Late December is between 4 and 4.5 months ago, no? Benwing2 (talk) 21:00, 8 May 2024 (UTC)Reply

I cannot execute a sql file wiktionary dump[edit]

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

enwiktionary-latest-categorylinks.sql.gz

located here:

https://dumps.wikimedia.org/enwiktionary/latest/

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:
I hope this helps. If you want more advice, tell us what it is you want to do with the file. This, that and the other (talk) 11:57, 8 May 2024 (UTC)Reply
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
Also, I can't tell whom I'm talking to, that would help. Kylefoley202 (talk) 19:51, 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
This script seems like an incredibly convoluted way of implementing a regex. Ioaxxere (talk) 16:26, 9 May 2024 (UTC)Reply

Periodically post link to appropriate section of WT:Wikimedia Tech News?[edit]

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 think just having the Tech News delivered to the Grease pit would be fine. Benwing2 (talk) 21:38, 8 May 2024 (UTC)Reply

Is it possible to output all of the IPA transcriptions of words with Quarry?[edit]

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

@Kylefoley202 The IPA transcriptions are contained in the page content itself, which is inside the "pages-articles" dump. This is an XML file. Parsing this content is something a lot of people have spent time thinking about! You might like to explore https://github.com/tatuylonen/wiktextract for instance. This, that and the other (talk) 10:49, 9 May 2024 (UTC)Reply

In SQL Wiktionary category file, all words are in caps and does not distinguish between gas and GAs[edit]

In looping over this SQL file

enwiktionary-latest-categorylinks.sql.gz located here: https://dumps.wikimedia.org/enwiktionary/latest/

in Python (I can't figure out how to use this software  https://quarry.wmcloud.org/) I find the line: 

1. "129690,'English_non-lemma_forms','GAS\\nGAS','2022-12-18 20:54:34','GAS','uppercase','page'"

But you would think that 'gas' is a lemma, not a non-lemmas but then you realize that they are referring to this entry:

2. https://en.wiktionary.org/wiki/GAs

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
Cool, thanks for the reply. Kylefoley202 (talk) 06:32, 10 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
Also, because the file is big, you should use the XML SAX parser that's built into Python (import xml.sax). Benwing2 (talk) 21:04, 13 May 2024 (UTC)Reply

Template:pre categorization is broken when the second component is unlinked[edit]

See Ylimarkku for an example. The category link markup shows up as plaintext. — SURJECTION / T / C / L / 11:22, 9 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
@Surjection@Theknightwho Should be fixed; let me know if you see any more issues with the affix code. Benwing2 (talk) 23:52, 11 May 2024 (UTC)Reply

Edit request to MediaWiki:Common.css[edit]

Add a new line in between lines 27 and 28: min-width: fit-content;, which fixes an issue where headings are cut off or compressed on narrow screens. Maybe @This, that and the other, Benwing2 Ioaxxere (talk) 15:41, 9 May 2024 (UTC)Reply

@Ioaxxere can you share some screenshots or generally be more specific about what the problem is? If it's a MediaWiki issue it should be reported on Phabricator. This, that and the other (talk) 23:58, 9 May 2024 (UTC)Reply
@This, that and the other: See https://imgur.com/a/GT6DE58. I don't think this is a Mediawiki issue as it seems that all the CSS is working as intended. Ioaxxere (talk) 02:32, 10 May 2024 (UTC)Reply
@Ioaxxere Thanks for that. The issue looks to be specific to mobile (see phab:T316670 where a min-width solution is suggested). Note that Common.css is not loaded on mobile, so we have to modify MediaWiki:Mobile.css instead.  Done in [8]. This, that and the other (talk) 04:15, 10 May 2024 (UTC)Reply
@This, that and the other: Something similar happens on desktop when the viewport is extremely narrow: https://imgur.com/a/jWznzhF. Since this admittedly represents an extreme case, your solution is probably good enough (although I think it's better to have fewer lines of code). Also, what makes you say that common.css isn't loaded on mobile? I was able to change the mobile CSS with User:Ioaxxere/common.css. Ioaxxere (talk) 04:31, 10 May 2024 (UTC)Reply
@Ioaxxere The issue on desktop looks different, as the letters don't spill down the page one by one like they do on mobile. In any event it's an extreme case as you say, since narrow viewports are pathological on desktop. As for the non-loading of MediaWiki:Common.css on mobile, see mw:Extension:MobileFrontend#CSS styling. This, that and the other (talk) 05:38, 10 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
@Ioaxxere  Done. This, that and the other (talk) 07:00, 11 May 2024 (UTC)Reply
@This, that and the other: The talk page problem hasn't been fixed since MediaWiki:Mobile.css still has the original selector. If Common.css is in fact loaded on mobile, then the Mobile.css code can be safely removed. Otherwise, it should be the same as in Common.css. Ioaxxere (talk) 18:54, 11 May 2024 (UTC)Reply
@Ioaxxere  Done that. This, that and the other (talk) 11:44, 12 May 2024 (UTC)Reply
Thank you! I think everything looks good now. Ioaxxere (talk) 19:46, 12 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
OK, and here's some text tagged with more complex styling. - -sche (discuss) 05:16, 13 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
OK, I changed it. Benwing2 (talk) 20:48, 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

Wrong categorisation of cites with an untranslated passage[edit]

{{cite-book|en|passage=bla}} puts the page into Category:English quotations with omitted translation, and {{cite-book|fr|passage=bla}} puts the page into Category:French quotations with omitted translation. This is wrong, because these cites do not have an explicitly omitted translation (see the description of the category). Moreover, the first case is doubly wrong, because the passage is English so it does not require a translation. This, that and the other (talk) 05:49, 10 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
It's causing a similar problem for 'Lithuanian' - Untranslated citing of a journal. --RichardW57m (talk) 11:21, 13 May 2024 (UTC)Reply
@JeffDoozan Are you able to take a look at this in the next couple of days? Benwing2 (talk) 20:43, 13 May 2024 (UTC)Reply
This should be fixed now. I added a 'noreq' param to format_usex() to suppress the request for translation. JeffDoozan (talk) 21:31, 13 May 2024 (UTC)Reply
@JeffDoozan Thanks! Benwing2 (talk) 21:36, 13 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

@JeffDoozan I think we need an extra cite-specific parameter for this; maybe |noquote=1 or |mention=1 or something. Benwing2 (talk) 07:20, 14 May 2024 (UTC)Reply
Should cites normally be treated as quotations? The term might not appear in the quoted citation at all! --RichardW57m (talk) 13:13, 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.
When we come up with a solution, it also needs applying to the reference at panedielis. --RichardW57m (talk) 13:37, 14 May 2024 (UTC)Reply
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)[edit]

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.

  1. 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).
  2. 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
      1. Go to the recommendations page and find a relevant example
      2. If no relevant example is available or you're not sure of the fix, contact us
    • If you want to debug many templates in dark mode
      1. Go to https://night-mode-checker.wmcloud.org/ and identify templates that need to be fixed. The tool flags the top 100 most read articles.
      2. Go to the recommendations page and find a relevant example
      3. If no relevant example is available or you're not sure of the fix, contact us
    • If you want to identify problems beyond the top 100 articles.
      1. Install the WCAG color contrast browser extension (Chrome, Firefox) and visit some articles. Use it to identify problems
      2. Go to the recommendations page and find relevant examples
      3. If no relevant example is available or you're not sure of the fix, contact us
    • If you have a bug report for dark mode that is not related to templates
      1. Take a screenshot of what you are observing.
      2. Contact us. If possible, please write down your browser version and operating system version.

Thank you. We're looking forward to your opinions and comments! SGrabarczuk (WMF) (talk) 15:29, 10 May 2024 (UTC)Reply

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
Me neither … — Sgconlaw (talk) 21:48, 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. — LlywelynII 22:05, 16 May 2024 (UTC)Reply
Right, so like “I’m in the middle of a movie but gotta find out the meaning of the word insufferable!” Ha ha, OK. — Sgconlaw (talk) 17:49, 17 May 2024 (UTC)Reply
Well it can also be useful for people with particular neurologies. 'Sides, don't need to understand it to have it. Vininn126 (talk) 17:51, 17 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. — LlywelynII 02: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.
This, that and the other (talk) 11:41, 12 May 2024 (UTC)Reply
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. — LlywelynII 22:05, 16 May 2024 (UTC)Reply
Hey everyone, I have an update: dark mode is now available in Vector 2022 as a beta feature: Accessibility for Reading (Vector 2022).
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!
(@LlywelynII, you're right, the mobile rollout was just the first step. Eventually, dark mode will be available for both logged-in and logged-out users on mobile and desktop.) SGrabarczuk (WMF) (talk) 17:13, 17 May 2024 (UTC)Reply
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. — LlywelynII 02:23, 19 May 2024 (UTC)Reply

Help needed with Template:RQ:Kojiki[edit]

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.

  1. 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
  2. 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.
  3. 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.

Also pinging @Eirikr, who originally created the template. Chuck Entz (talk) 17:38, 10 May 2024 (UTC)Reply

Appears to have been resolved by Benwing2. — Sgconlaw (talk) 17:51, 17 May 2024 (UTC)Reply
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ð mig 18:53, 17 May 2024 (UTC)Reply
For reference, here's the earlier thread:
  • Wiktionary:Grease_pit/2024/January#Lua-fication_of_simple_reference_templates_--_rationale?
It seems that sparked a longer technical discussion than I was aware of earlier (things IRL have kept me from spending much time here lately). ‑‑ Eiríkr Útlendi │Tala við mig 19:02, 17 May 2024 (UTC)Reply

How to turn off the new thing on talk pages[edit]

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

In "Preferences". I just turned off loads of features, including the crap you mentioned P. Sovjunk (talk) 21:45, 10 May 2024 (UTC)Reply
Specifically, untick "Show discussion activity" at the bottom of the "Editing" tab of Special:Preferences, see above. - -sche (discuss) 22:47, 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
@Chuck Entz Where does it give "Latest comment" info in diffs? Can you elaborate? Benwing2 (talk) 21:44, 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
Neat. I wonder why it says "undefined" when you hover the mouse pointer over the anchor icon! Equinox 12:23, 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

Proper nouns, def=1 but where it's optional[edit]

See Talk:Leopards Eating People's Faces Party, latest thread by @J3133. Sometimes we want to specify "the" (def=1 parameter) but it's optional, not mandatory. Equinox 12:15, 12 May 2024 (UTC)Reply

The quotations without "the" look like broken English to me. Ioaxxere (talk) 19:48, 12 May 2024 (UTC)Reply
Okay but I have definitely seen "optional the" cases other than this one. Equinox 19:51, 12 May 2024 (UTC)Reply
@Equinox @Ioaxxere Use |the=~; it should be documented on the {{en-noun}} page. Benwing2 (talk) 19:55, 12 May 2024 (UTC)Reply

Kyūjitai spellings displaying as orange links[edit]

It seems that MediaWiki:Gadget-OrangeLinks.js is incompatible with {{ja-see}}, as the "Alternative spelling" box on Japanese kanji entries is displaying kyūjitai spellings as orange links despite the Japanese L2 header being present. See 嘘だろ and 尽くした. Binarystep (talk) 01:29, 13 May 2024 (UTC)Reply

I suspect this is happening because those forms aren't categorized as either lemmas or non-lemma forms. Benwing2 (talk) 20:57, 13 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
@Binarystep I think to fix this we should make kyūjitai spellings be either lemmas or non-lemmas. I notice for example that romaji spellings are considered non-lemmas and hiragana spellings are considered lemmas. Pinging Japanese editors: (Notifying Eirikr, TAKASUGI Shinji, Atitarev, Fish bowl, Poketalker, Cnilep, Marlin Setia1, 荒巻モロゾフ, Shen233, Cpt.Guapo, Sartma, Lugria, LittleWhole, Chuterix, Mcph2): . Benwing2 (talk) 05:23, 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
Still orange for me. I'm using Chrome on Windows 10, if that's relevant. Binarystep (talk) 06:23, 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
Oh, no, sorry, my mistake. I don't have the gadget turned on. Cnilep (talk) 07:01, 14 May 2024 (UTC)Reply
I'm seeing orange links as well.
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ð mig 18:56, 17 May 2024 (UTC)Reply
That's not really how we treat non-lemmas in general, though. Theknightwho (talk) 23:49, 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

Inflections wrongly doubled[edit]

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

@Theknightwho Could you take a look? This is caused by this diff [9] you made last December. Benwing2 (talk) 20:55, 13 May 2024 (UTC)Reply

Check for blacklisted images we're actually using[edit]

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

@-sche File:Human buttocks.jpg is used on buttock. Binarystep (talk) 12:23, 14 May 2024 (UTC)Reply
Anyone else find that image on buttock a bit glaring? I think the one at nipple is somewhat more tasteful. Benwing2 (talk) 06:46, 15 May 2024 (UTC)Reply
Heads up that I replaced the latter with a crop. I don't think it changes your point, tho. —Justin (koavf)TCM 06:57, 15 May 2024 (UTC)Reply

Template:Latn-def requires lowercase letter[edit]

{{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

Exporting Wiktionary's templates to another wiki[edit]

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.

Is there a page or guide somewhere about setting up your own Wiktionary? A diehard editor (talk) 02:40, 15 May 2024 (UTC)Reply

@A diehard editor Almost certainly not. I've never heard of anyone doing this. Benwing2 (talk) 06:43, 15 May 2024 (UTC)Reply
Well, I'm out of luck.
Anyways...
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.
I will forge ahead with my project by myself; implementing templates as needed. A diehard editor (talk) 15:21, 15 May 2024 (UTC)Reply

Unsupported title issues[edit]

See, e.g., Unsupported titles/: § Finnish (the headword is “:[[Category:Finnish lemmas|]][[Category:Finnish punctuation marks|]]”). An issue that may be related: shows the composition as “[[>|> [U+003E]]] + ◌̸ [U+0338]”. J3133 (talk) 14:02, 16 May 2024 (UTC)Reply

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)TCM 20:53, 16 May 2024 (UTC)Reply
Note that this issue occurs on , , etc. —Justin (koavf)TCM 20:55, 16 May 2024 (UTC)Reply
There was another similar sortkey issue with unsupported titles above. Benwing2 (talk) 21: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
@J3133 not related to the issue with . Benwing2 (talk) 22:13, 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
I see, makes sense. Benwing2 (talk) 22:24, 16 May 2024 (UTC)Reply
The issue at looks to be a case of unsupported titles not being supported by {{character info}}. Theknightwho (talk) 22:25, 16 May 2024 (UTC)Reply
Should be fixed. Benwing2 (talk) 04:14, 17 May 2024 (UTC)Reply

Description of Category:Dialectal Southern Valley Yokuts[edit]

“Terms or senses in Southern Valley Yokuts as spoken in Dialectal.” J3133 (talk) 17:53, 16 May 2024 (UTC)Reply

@J3133 Yeah it looks like User:TongcyDai used {{auto cat|dialect=1}} without checking to see if it produced sensible results. IMO in this case we don't need this category at all; just put the different regional varieties directly under Category:Regional Southern Valley Yokuts. Benwing2 (talk) 19:43, 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
@TongcyDai Yes. It's a weird holdover, as we're currently double-categorizing some things under e.g. both Category:Mandarin lemmas and Category:Mandarin Chinese (the latter under Category:Dialectal Chinese). Benwing2 (talk) 19:57, 16 May 2024 (UTC)Reply
May I assume that this category will be removed in the near future? TongcyDai (talk) 20:06, 16 May 2024 (UTC)Reply
@TongcyDai At some point, yes; we're still figuring out how to get rid of it. Benwing2 (talk) 20:08, 16 May 2024 (UTC)Reply
@Benwing2 Thank you, I'm really glad to hear that. TongcyDai (talk) 20:16, 16 May 2024 (UTC)Reply

Template:CJKV and Template:ja-r[edit]

Hi can we please suppress the Japanese romanisation linking (Rōmaji) as in {{CJKV||めんだん|면담}} at 面談面谈 (miàntán) and 面談(めんだん) (mendan)?

It should just show "mendan", not "mendan" Anatoli T. (обсудить/вклад) 01:50, 17 May 2024 (UTC)Reply

And why is that? We have romanji forms in the dictionary. Why wouldn't we link them? —Justin (koavf)TCM 01:58, 17 May 2024 (UTC)Reply
@Koavf: Rōmaji spellings are not words, they are only a way to disambiguate homophones.
The only place Japanese and Mandarin romanisation are linked are language entries.
We don't link romanisations otherwise, including any automated ones in templates - Mandarin: 面談面谈 (miàntán), 面談面谈 (zh) (miàntán) and Japanese 面談 (めんだん, mendan). Anatoli T. (обсудить/вклад) 02:55, 17 May 2024 (UTC)Reply
Are there other romanizations that we have as entries that are unlinked? —Justin (koavf)TCM 03:00, 17 May 2024 (UTC)Reply
@Koavf: I have shown you, didn't I? 面談面谈 (zh) (miàntán) or even the native template: 面談面谈 (miàntán) and 面談 (ja) (めんだん, mendan). It's linked when you're linking, otherwise it's unlinked. The only romanisation I know, which is always linked is Gothic: 𐌰𐌽𐌳𐌰𐍅𐌹𐌶𐌽𐍃 (andawizns). --Anatoli T. (обсудить/вклад) 06:38, 17 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)TCM 06:42, 17 May 2024 (UTC)Reply
@Atitarev: Wait... When I go to 面談, miàntán is linked. Can you actually give me an example? —Justin (koavf)TCM 06:49, 17 May 2024 (UTC)Reply
@Koavf: That's what I said originally. It's only linked in one place - the pronunciation section for Chinese Mandarin and headword for Japanese. Anatoli T. (обсудить/вклад) 06:52, 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)TCM 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ð mig 19:14, 17 May 2024 (UTC)Reply
Input needed
This discussion needs further input in order to be successfully closed. Please take a look!
This change was recently introduced and is annoying. Could someone please pay attention and fix it? (Notifying Eirikr, TAKASUGI Shinji, Fish bowl, Poketalker, Cnilep, Marlin Setia1, 荒巻モロゾフ, Shen233, Cpt.Guapo, Sartma, Lugria, LittleWhole, Chuterix, Mcph2): and our Lua editors @Benwing2, @Theknightwho. Anatoli T. (обсудить/вклад) 02:58, 17 May 2024 (UTC)Reply
@Atitarev I've still not had time to look into this - sorry. I'll make it a priority. Theknightwho (talk) 12:11, 17 May 2024 (UTC)Reply
@Theknightwho, @Benwing2: Hi. I read a lot of promises from you two regarding Asian language transliteration fixes.
The previous bug on the Japanese transliteration I reported was different: Wiktionary:Grease_pit/2024/April#Strange_unwanted_linking_of_Japanese_transliterations.
I doubt anything gets fixed but I discovered that capitalisation no longer works either with "^" symbol 富士山(ふ​じさん) (fu​jisan). 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
@Atitarev That's because you put it in the wrong place: {{ja-r|富士山|^ふ​じさん}} gives 富士山(ふ​じさん) (Fu​jisan), as expected. Theknightwho (talk) 02:46, 27 May 2024 (UTC)Reply
User:Theknightwho Can you give me and Anatoli a time by which you will look into this? If not, I will try to look into it but I have not touched this code in a long time. Benwing2 (talk) 02:49, 27 May 2024 (UTC)Reply
@Benwing2 @Atitarev The next few days - I've not had a proper stretch of time to look at it properly, because it seems nontrivial. Theknightwho (talk) 02:51, 27 May 2024 (UTC)Reply
@Theknightwho: You're right, thanks. My mistake. Just exposing romanisation is the problem and the previous bug on SoP translations. Anatoli T. (обсудить/вклад) 02:56, 27 May 2024 (UTC)Reply

Headword links in Old English multiword reconstructions[edit]

Using ⟨*⟩ in Reconstruction:Old English/cattes minte and Reconstruction:Old English/Cristes mæsseæfen causes the headword to link to “Reconstruction:Old English/catt”, “Reconstruction:Old English/minte” and “Reconstruction:Old English/Crist”, “Reconstruction:Old English/mæsseǣfen”, respectively, and there seems to be no way to link to the unreconstructed entries instead (neither {{l|ang|<term>}} nor [[<term>#Old English]] works). J3133 (talk) 05:19, 17 May 2024 (UTC)Reply

I found a workaround, it works if you type <nowiki>*</nowiki>. Weylaway (talk) 20:40, 17 May 2024 (UTC)Reply

How can I create a NavFrame which is open by default?[edit]

Ioaxxere (talk) 14:55, 17 May 2024 (UTC)Reply

Adding a hotline for a citation[edit]

just tried to add a URL for a citation on a change I just made and it was flagged as harmful. Anything I am getting wrong? Galifrey1965 (talk) 21:44, 17 May 2024 (UTC)Reply

@Galifrey1965 This filter prohibits adding external links for new users, which catches a lot of spambots creating accounts and then adding link spam. Benwing2 (talk) 21:48, 17 May 2024 (UTC)Reply

Improving template for World Loanword Database (R:WOLD)[edit]

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).

Can someone help me with this? tbm (talk) 07:06, 20 May 2024 (UTC)Reply

Categories for terms with translations by languages[edit]

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

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)Reply
My only concern would be whether having 3000+ categories on a page like water/translations would cause issues. Benwing2 (talk) 21:04, 21 May 2024 (UTC)Reply
@Benwing2 I believe a similar issue raised by @Catonif was that we have unsorted categories. A potential solution would be to make them hidden. Vininn126 (talk) 21:06, 21 May 2024 (UTC)Reply
@Vininn126 My concern is more about whether this would put a significant load on some Lua restriction, even if they were hidden. Benwing2 (talk) 21:09, 21 May 2024 (UTC)Reply
@Benwing2 That would be a bigger concern. Have we tested this directly? Vininn126 (talk) 21:11, 21 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
OK in that case I Support. Benwing2 (talk) 02:18, 22 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
@Chuck Entz I'm aware. I'm suggesting this for the potential of having a Recent Changes. Vininn126 (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
@This, that and the other That's not true. Interlingua has translation sections. Vininn126 (talk) 08:15, 23 May 2024 (UTC)Reply
@Vininn126 WT: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
Sorry, I didn't mean Interlingua, but I did mean Translingual. Vininn126 (talk) 09:54, 23 May 2024 (UTC)Reply
Hah, I see! Makes much more sense now. This, that and the other (talk) 10:04, 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
So it seems the consensus is to not categorize by translated language, but to add categories, and make them hidden. Vininn126 (talk) 19:47, 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
Sounds fine to me. Vininn126 (talk) 09:09, 24 May 2024 (UTC)Reply
Fine with me too. Benwing2 (talk) 18:45, 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 settled on "Entries with translations of X terms‎" to be extra clear (e.g. Category:Entries with translations of Translingual terms). The four pre-existing "X translations" categories have now been changed over to the new format, but we should probably keep this thread open for comment for a bit longer before enabling it generally. Theknightwho (talk) 09:58, 25 May 2024 (UTC)Reply
Thanks! Vininn126 (talk) 12:42, 25 May 2024 (UTC)Reply
But I still think it'd be nice to have the translated language category, so I can keep an eye on Polish translations. Vininn126 (talk) 12:44, 25 May 2024 (UTC)Reply
@Theknightwho I think I'm still a bit confused by this naming scheme. For example, dragon is in Cat:Entries with translations of Translingual terms, but it has a translation from English into Translingual - there is no "translation of a Translingual term" on that page. This, that and the other (talk) 23:08, 25 May 2024 (UTC)Reply
@This, that and the other The entry itself is the translation, but it sounds like this doesn't clarify things as well as I thought, so I'll change it to "Entries with X translations". Theknightwho (talk) 18:01, 26 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).
We're definitely not consistent with it, though. Theknightwho (talk) 18:23, 26 May 2024 (UTC)Reply
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
I'm a bit confused. Does this enable one to look at, say, "Entries with Polish translations"? Vininn126 (talk) 18:44, 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
Alright - given everyone seems at least weakly in support, I think we can probably enable this. Theknightwho (talk) 19:48, 28 May 2024 (UTC)Reply

WiktCountryFlag gadget not working on MonoBook[edit]

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

Fix strange UI[edit]

This is something strange in your UI, a message box inside an error box:

I would advice removing the wrapping {{notice}} from MediaWiki:Abusefilter-warning-redirect to get this look:

JWBTH (talk) 10:46, 23 May 2024 (UTC)Reply

Polish inheritance/descendants[edit]

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 Don't quite understand what you're referring to, can you give an example? Benwing2 (talk) 19:35, 23 May 2024 (UTC)Reply
@Benwing2 diff. You can see that the Old Polish entry had already existed, I believe even with a descendants section, but was not in the Polish etymology. Vininn126 (talk) 19:37, 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
@Tbm Let me know. Vininn126 (talk) 08:40, 25 May 2024 (UTC)Reply

Alchemical symbols wrongly categorized as emojis[edit]

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.

An exception is ☽tum, which is correctly categorized in Category:Latin terms spelled with ☽. But by itself remains uncategorized. Jcitawy (talk) 10:09, 24 May 2024 (UTC)Reply

@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

WT:ACCEL not working any more?[edit]

I don't seem to get the "green links" for accelerated plurals and inflections any more. Why is that? Equinox 20:20, 24 May 2024 (UTC)Reply

Seems to be working for me, looking at Polish verbs. Vininn126 (talk) 21:55, 24 May 2024 (UTC)Reply
How can I diagnose the issue that affects me but not you? Equinox 21:57, 24 May 2024 (UTC)Reply
It's probably related to the headword, as something that's different between our situations. Vininn126 (talk) 21:58, 24 May 2024 (UTC)Reply
@Equinox Can you give an example page where it's not working? Theknightwho (talk) 22:05, 24 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
You can try bungey (no plural yet). Equinox 22:10, 24 May 2024 (UTC)Reply
It's green for me, and the clicked link generated an accelerated page. Vininn126 (talk) 22:11, 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
@Equinox It's working for me, but I don't know if it's a browser issue (since acceleration relies on JS). What browser are you using? Theknightwho (talk) 22:15, 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
It seems to be working for me too. I just used it about an hour ago. — Sgconlaw (talk) 23:21, 24 May 2024 (UTC)Reply
@Erutuon @Benwing Why might the multiple scripts be broken only for me (several days now)? Equinox 00:29, 25 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
And just to be sure, you are still using the Monobook skin? (*shudder*) This, that and the other (talk) 00:45, 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
I do think it's the usage of a different skin. I use Timeless, and it also doesn't work for me. (Also, Monobook is fine.) CitationsFreak (talk) 03:15, 25 May 2024 (UTC)Reply
Oh, good point! I hadn't thought to actually check whether the WT:ACCEL script fails in Monobook. And for me it does fail. I've tried repairing it with this change. Equinox, please try now. This, that and the other (talk) 04:25, 25 May 2024 (UTC)Reply
It works for me. CitationsFreak (talk) 04:30, 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
No doubt it is a similar problem with the Nearby script/gadget on Monobook. I will look at it later. In the meantime, can you verify it still works on Vector: https://en.wiktionary.org/wiki/aardvark?useskin=vector This, that and the other (talk) 03:50, 26 May 2024 (UTC)Reply
@This, that and the other: Wikipedia? Chuck Entz (talk) 04:32, 26 May 2024 (UTC)Reply
Whoops, fixed. This, that and the other (talk) 09:38, 26 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
@Equinox try again now. Should be fixed after this. This, that and the other (talk) 22:47, 26 May 2024 (UTC)Reply

TOC funny[edit]

At https://en.wiktionary.org/w/index.php?title=Wiktionary:Tea_room/2024/May&oldid=79423980, clicking "top" in the TOC actually takes you to the top of the page, not to the entry "top"! Mihia (talk) 19:47, 25 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
@User:-sche Are you saying that for pages such as this one? DCDuring (talk) 02:06, 26 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

Userspace pages in Category:Pages with ParserFunction errors[edit]

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.

This isn't urgent, since there are very few userspace pages involved, but it could eventually lead to problems. Chuck Entz (talk) 22:52, 25 May 2024 (UTC)Reply

@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

Quotation templates always Wikipedifying author's names[edit]

What's the deal with this? I'd say more authors don't have 'pedia articles than do, so why is this on by default? Vininn126 (talk) 18:52, 27 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
Turning them on automatically also means checking for any that are missing. Vininn126 (talk) 19:01, 27 May 2024 (UTC)Reply
@Vininn126: sorry, edit conflict. See my updated comment above. — Sgconlaw (talk) 19:04, 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
@Sgconlaw Partially, but many are fairly unknown authors whom we know just because they signed it, like for Old Polish. Vininn126 (talk) 19:42, 27 May 2024 (UTC)Reply

Tool to resync translations[edit]

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

Template:a now uses Module:labels internally[edit]

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 ...
  1. Do we actually want the separate categories Category:American English and Category:American English forms? Having these two categories would necessitate having at least two labels e.g. US vs. American spelling, since both can be used with {{lb}} or {{tlb}}. This seems a recipe for inconsistency. I gather the intent is that terms that are specific to American English (i.e. have no corresponding version in British English) like dude (vs. bloke), wrench (vs. spanner) or elevator (vs. lift) would go into Category:American English, while terms that differ only in spelling (like favor vs. favour, categorize vs. categorise) go in Category:American English forms. But I suspect this distinction is not that well maintained. In fact there are 11,000+ terms in Category:American English and only about 600 in Category:American English forms, and the former includes terms like abastardized and ammonium sulfate that belong in the latter.
  2. 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?
  3. Any other thoughts/concerns?
Benwing2 (talk) 02:02, 28 May 2024 (UTC)Reply
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
There are in fact some places that use American form in {{lb}} or {{tlb}}. They are from A to Zee (points to from A to Z), maid of honor tart (points to maids of honour tart), maid-of-honor tart (points to maids of honour tart) and troop the color (points to troop the colour). The last one is just a spelling difference, while the others are slightly more. Does it make sense to use {{standard spelling of}} for the last one and {{alternative form of}} for the remainder? And is it OK to replace American form with American spelling in all of them? I notice for example in your edit summary in from A to Zed you say the label British spelling should probably not be used once British form and British spelling are aliased, but I don't understand the logic here. Benwing2 (talk) 02:09, 29 May 2024 (UTC)Reply
FYI to see where a label is used, go to e.g. Special:WhatLinksHere/Wiktionary:Tracking/labels/label/American form. I just added per-"mode" tracking as well, so that e.g. you can distinguish uses of American form in {{lb}} vs. {{tlb}} vs. {{a}} vs. form-of templates by visiting Special:WhatLinksHere/Wiktionary:Tracking/labels/label/American form/MODE, where MODE is one of label (for {{lb}}), term-label (for {{tlb}}), accent (for {{a}}) or form-of (for form-of templates). However, since I just added this, it may take a few days before all entries show up on the relevant tracking pages. Benwing2 (talk) 02:25, 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 of foo: alternative form of bar", so just making them all point directly to the one 'lemma' entry seems fine. - -sche (discuss) 17:48, 29 May 2024 (UTC)Reply

Module:documentation causing module errors[edit]

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

Multiple RfVs on a page[edit]

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

Shaozhou Tuhua[edit]

(@Erutuon?) Can we specify a font for Shaozhou Tuhua (class=Nshu) so that e.g. 𛉄 can be displayed? Currently the font for Nshu is unspecified in MediaWiki:Gadget-LanguagesAndScripts.css. --kc_kennylau (talk) 16:22, 28 May 2024 (UTC)Reply

@Kc kennylau What font should be specified? Benwing2 (talk) 19:18, 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
Agree with increasing font size. --kc_kennylau (talk) 21:31, 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
@Fish bowl: I don't know what "smart" web browser you're using but I'm using Chrome and it does not automatically use a Noto font. --kc_kennylau (talk) 09:06, 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
Yeah I'm using Firefox. I take it back; I had no idea Chrome was so weird lol. —Fish bowl (talk) 21:21, 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
@-sche Thanks for doing this. I think 150% might be a bit too big - it's now way taller than the surrounding Latin text with Noto Sans Nushu. I think 130% is probably about right. Also pinging @Kc kennylau @Benwing2 @Fish bowl for thoughts. Theknightwho (talk) 00:15, 30 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
@-sche I'm not sure why the script code isn't correctly tagged on 𛉄; I'll have to take a look at the headword code. As for the logged-out issue, maybe User:This, that and the other and/or User:Ioaxxere can answer, who seem to know more about CSS than I do? Benwing2 (talk) 04:29, 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
@This, that and the other I fixed the page title CSS issue; or at least, it works for me on Chrome on a Mac. What is your browser and OS? Benwing2 (talk) 05:49, 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
@Benwing2 Chrome on Windows. The Nshu class is now correctly applied to the page title in Chrome and Firefox, logged in and logged out. This, that and the other (talk) 07:14, 30 May 2024 (UTC)Reply

quyanaa[edit]

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.

Help. RangerRichard (talk) 02:15, 29 May 2024 (UTC)Reply

@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
Ahh okay I got it RangerRichard (talk) 01:26, 31 May 2024 (UTC)Reply

Category:Theodore Roosevelt and Category:en:Theodore Roosevelt[edit]

Please add to Category tree, as subcat of Individuals and US politics (−) (±) (↓) (↑) Purplebackpack89 03:06, 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. Purplebackpack89 16:22, 30 May 2024 (UTC)Reply
@Purplebackpack89 A category like this would be for terms about Theodore Roosevelt, not things coined by him. We have {{coinage}} for the latter purpose. Benwing2 (talk) 01:01, 31 May 2024 (UTC)Reply

Category:Wars and Category:en:Wars[edit]

Please add to Category tree, as subcat of List of name categories, Historical events and War Purplebackpack89 03:09, 29 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 I‎I/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". Purplebackpack89 16:23, 30 May 2024 (UTC)Reply

Language dump[edit]

@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

@Vininn126 Are you just looking for a textual dump of the contents of all the Masurian lemma and non-lemma pages? That is easy enough to produce. Benwing2 (talk) 21:23, 29 May 2024 (UTC)Reply
@Benwing2 (Let me ask Piotr) Vininn126 (talk) 21:25, 29 May 2024 (UTC)Reply
@Benwing2 Pure wikitext apparently is fine. Vininn126 (talk) 23:21, 29 May 2024 (UTC)Reply

Italics don't work in t= parameter of form-of templates[edit]

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[edit]

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

@Vorziblix User:Theknightwho can you comment here? I think this is due to your changes to this module to use Module:template parser, which seems to expand every template while parsing the page, even though it doesn't seem necessary here. Should we set a flag to the call to findTemplates in Module:descendants tree to tell it not to expand templates? Benwing2 (talk) 01:13, 31 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